In this post, I want to discuss the process of making Marx.js: reasons for the plugin, developing and planning, keeping on track and meeting deadlines, launching and marketing. Please keep in mind this is the first time I’ve ever done this on my own and it is still early, but so far things have been going smoothly. I have been a part of this process a few times with my job, so I feel I can speak some-what intelligently about it.
Why Marx js?
As I mentioned in an earlier post, I was building a rails app at work with incredibly long forms and got extremely tired of having to fill out the whole thing over and over again. I have the Web Developer Chrome extension but it left much to be desired. This is the key to having a worthwhile product, make sure it is something that will truly benefit your audience.
The best way to make sure your idea is something others will use is to make sure it is something you will use. Marx.js met that requirement.
Planning & Development
Luckily for me, I knew exactly what I wanted from Marx.js and I knew how to build it. The hard part was staying on task. When working on an app or product that is intended to replace something that is already out there, it’s easy to get caught up in “What else can I add to this?”
I’m not trying to say that additional ideas or features are bad, but there’s a time and place. The most important thing to focus on is the core reason for your product. Using Marx.js as an example, the whole point was to make a plugin for populating forms while adding more readability and randomization that was easier to use than the Web Developer extension. So often I found myself starting to think, “wouldn’t it be cool if…” before the core functionality was complete.
This is the “Danger Zone” I’m warning against. When you get excited about “what else” before the core of the project is complete, then you are likely to lose focus and the project will suffer on a whole. Suddenly you’re starting the new feature and when you return to the core of the project, will you remember everything? Will you remember the bug that needs fixed? Or the method you were going write better? What if you are pulled away from the project entirely for a while? Now, you have essentially two lumps of code to get familiar with again instead of the one.
I’m not saying to ignore any good ideas that you have just because the core of the project isn’t ready, but rather jot the ideas down with any notes, and save them for later. Keep all your ideas together and order them as you wish by importance, difficulty, or number of requests from users. The big thing is make sure that these ideas do not sidetrack you from the main purpose of your app or product.
Once the core of the project is done, the next step is testing, and then testing, and lastly testing. Moral of the story is that you are releasing this to the world and there are two key factors:
You know how it’s supposed to work
As you’re building, you develop exactly how it should be used but will probably lose sight of how others may mistakenly use it. Basically you work out all the bugs in the perfect workflow, missing the bugs if someone accidentally clicks where they shouldn’t.
Your audience includes the lowest denominator.
When I was a youngster, first working on computers, I remember having to learn how to use applications and the computer. When something wasn’t working, it was because I was doing something wrong and had to learn the right way. These days everyone knows best and they don’t use anything the wrong way. It’s the application that’s wrong.
As much as that sucks, that’s the mentality of a lot of users now that computers, tablets and smart phones are accessible to everyone. We, the developers, need to think about how non-computer people are going to break our product. We aIso need to make sure they use our product as intended. Usually this is best accomplished through proper and simple UIs.
So what’s next? Adding those wonderful additions you came up with while building your core application, one at a time with crazy amounts of testing before moving to the next. Lather, rinse, repeat.
The Alpha and the Beta
So you have a product now, huh? Ready for the world, right? Wrong! Even if you have tested it every way from Sunday, you could still be missing something glaringly obvious to everyone else. Your head has been stuck in code and workflows for weeks now and you need an outside perspective.
This is where Alpha and/or Beta releases come into play. Marx.js is currently in Beta and though I am tweeting about it constantly, I am still finding bugs and getting feedback from people. Right now, I am not getting too much traffic from outside of people I know and that is perfectly fine by me. I’d much rather have five people I know tell me something is wrong, then 1000s of people I don’t know not telling me what’s wrong.
Before I even had the public site for Marx.js, I had a demo setup online and was showing it to colleagues and friends. I wanted to get any ideas they had on the plugin, any issues they found and just opinions on the website I was planning to use to promote it.
Access to Your Product
This may not apply to you depending on your product, but for Marx.js this is another aspect that I am pushing. So what do I mean “Access to my product?”
For example, right now you can download the file as I mentioned or if you’re developing in Ruby on Rails, you can use the gem I made. The RubyGem is the same product, it’s just a Ruby container that makes installing and managing the plugin easier than just the straight download.
I am also currently working on a Google Chrome extension for Marx.js and hope to find time to create a npm and/or bower package for it as well. Not only are these good ways to make your product more accessible, but they also help with getting your name out there.
I have to be honest, I am currently learning as I go here with marketing, but I’m getting some relative success by pushing this blog on Twitter and Google+ and I feel like I can at least give a little advice.
I am promoting sparkmasterflex.com only using social media and 6 months into it I have been starting to get some steady traffic. With the addition of some basic SEO (Search Engine Optimization) work and focusing on a specific niche, my blog has been steadily getting more hits. This is what I am currently doing with marxjs.com.
Tweeting and posting to Google+ about features of Marx.js, writing a blog post and having a weekly Marx quote going out, have been my main strides to date. I have a Twitter (@marxscript) and Google+ account for Marx.js, where I post new versions of the plugin. I find that (and many others will agree) the right use of social media can get you some serious attention.
Maintaining Your Product
Unfortunately this, as well, is an area that I am diving into the deep end with. Currently I have the code for the plugin and the RubyGem on gitHub and am maintaining and adding to it by myself. But I have hopes that as people begin to use it, I’ll not only get feedback and pull requests but maybe find a developer or two who will want to help keep the project going. That’s the beauty of the open-source world, you are never truly alone.
So Let’s Recap
- Make sure there’s a market for your product/idea
- Find the main purpose for your product
- Complete the core before moving to the additions
- Test, test and test again
- Get others to try out, test and critique
- Marketing — start small, start free
- Use gitHub, ask the community for help
Again, all of this is still a work in process and also a learning experience for me. Though I have to say that I feel like I’m on the right path. I hope that I have been some-what insightful and perhaps provided some good tips on building, marketing and maintaining an open source project.