This is the third post in a series about working on my side project: Indie Aisle. The previous covered design and development. Originally this article was going to be about specific techniques I’ve used to market the Indie Aisle web app. But there is a critical aspect I missed that makes the results on those techniques inconclusive: tracking their outcomes. I’ll talk more about it in a bit.

The first big thing I’ve learned about marketing a web app (or marketing anything really) is to have a clear, focused message. It sounds basic, but it can be the most difficult thing to get right and I’m still not sure I’ve gotten the hang of it for Indie Aisle. Getting the message figured out has not only allowed me to write better content for the site, but as the message is part of the brand and permeates throughout every aspect of the product, it also becomes a part of every marketing campaign. Here are a few campaigns that have yielded some results for me as I tried to pay attention to the message:

• Blog – helped develop the message with every post, having regular posts was helpful as well
• Twitter – worked for figuring out who my audience was and understanding their experiences
• Newsletter – good for some feedback and keeping interested users updated, including blog posts or tweets was a good way to reuse some content
• Adwords – measuring/tracking is key, once you have that, you can start to properly drive traffic you pay for and figure out how to better focus your efforts

So, tracking is where I went wrong when it came to ads I ran (the most being through Google’s Adwords). I essentially spent way too much on ads this past year and at the end of it all was not able to identify the specific results that showed if the product was successful. I essentially got carried away looking at traffic numbers and sign ups as they went up while blindly overlooking the fact that they did not lead to the most important figure: paying customers. The only way to really know if someone is using your product, this making it successful, is if they are happily paying for it!

I also realized that by not tracking results based on conversions (the connection between a click and a sale), it also lead to incorrect customer targeting which is also an important aspect of marketing. I didn’t know if the audience I was pushing to the site was in fact the right audience for the app because I didn’t know to what extent they were using it. And in hindsight, I now see that this also made it difficult to know how to continue developing the app.

Tracking every marketing effort and getting paying customers is what ties together the idea from being conceptual to knowing if it works in practice, as a concrete product. And as I’ll cover in my next post, not having a good understanding of this can ultimately lead to a failed product.

As I’ve been reflecting on this past year, get ready for the new one I’ve been thinking about some of the projects I’ve worked on in the past. One of projects that came to mind was my own take on a content management system which I worked over two and a half years ago.

At the time, I had worked with many websites along with a few content management systems, enough to where I had some ideas of how I would build my own if I had the opportunity. In my pursuit of the ultimate content management system for clients, I came across an interesting one called Injader. It was a project developed by primarily one guy, Ben Barden who used it for some of his own websites. What got my attention was how lightweight it was, at least compared to the behemoth WordPress was turning into.

After setting it up and testing it out for a pet project I was working on, I decided to contact Ben about helping out with further development of the system by taking on the interface design end. Five months of working on it on the side along with our day jobs, we decided to call it quits. We both had other projects we were pursuing (it was around the time I started Indie Aisle) and this one didn’t seem to work out for us. One thing I realized is that what started out to be a simple tool quickly turned into something rather complex and may have been too ambitious in the end.

I thought I’d share a few screens and describe what the design concepts behind them were (as I remember them). Maybe it’ll provide inspiration for the content management system you may work on someday! The CSS/HTML was completely built so you can click on the screenshots to explore the mockups as they were when I sent them over to Ben.

Sitemap – This is how pages were organized, the unique approach was that it did three things in one: built the navigation structure for the site, gave an overview of the entire structure of the site, and defined Content Types for the kind of information on the site, either info pages, blog posts, forums, or portfolio galleries. It also shows widgets attached to each page which I’ll explain in the next screen.

Widgets – The idea with Widgets was based on three types: Layout which required special CSS/HTML formatting, Data which incorporated database data, and Web which was essentially embed code from other sites. Each would be inserted into a page with template code snippets, in any part of the site.

Tools – Similar to WordPress’s plugins, but mainly focused on behind-the-scenes management which is why it was separate from the content side along with the Themes editor, Settings and user Access options.

Access – A complete user system with custom roles options.

So as always, a failure is also a good learning experience. I got a chance to experiment with some new interface techniques and improve my CSS skills. And the overall experience gave me a different perspective on how I built websites with a content management system.

A few months I made a list of what I wanted in a new phone as my two-year contract with my Droid was almost up. Last week I looked at the options available and went back to my original list. I mainly looked at what Apple announced for its iPhone 4S and what Android announced for its upcoming Android 4 device, the Samsung Galaxy Nexus.

• Good web browser – responsive and doesn’t crash like it does on my Droid; both iPhone and Android look to have done a good job with the latest versions
• Fast internet – 4G sounded like the way to go at this point, but after seeing what problems my brother has had with the 4G phone he got a few months ago, it doesn’t seem to me like the network’s ready
• Good music player – the Android music player I’ve been using leaves much to be desired and the new one does look better, but still limited; having iTunes to sync music from my computer seems like a better approach, especially now that it’s via wifi
• Space for music – I originally wanted to be able to fit all the music I had on my computer, but I’ve realized that I don’t listen to all of it and find myself having to skip through songs a lot on my phone, so as long as I can easily sync, I’m okay with picking and choosing music I’ll actually listen to
• Syncing for Gmail – this includes Calendar and Contacts; Gmail makes it more seamless on Android for obvious reasons, but I can get the same capabilities on the iPhone too
• Reasonable screen size – I’m tired of so many phones that are supposed to be portable coming out with bigger and bigger screens; my brother has one that’s 4.3 inches and it just looks ridiculous; having an iPod Touch for almost a year now, I like its screen size and am glad the iPhone 4S decided to stick to the same size
• Great camera – the one on my Droid has been disappointing and I wanted something that would be good enough to replace my digital camera; as I’ve been keeping my eye on reviews that compare phone cameras, all the ones I’ve read come to the conclusion that for overall photo and video quality, there is no better option than the iPhone

You can probably tell by my responses that I’m leaning towards the iPhone. And it is in fact what I went with. It wasn’t an easy decision since I’ve had a pretty decent Android device for the last two years and the latest Android update looks promising. But besides the features above, there are two main reasons why I ultimately decided to go with the iPhone:

Android’s philosophy doesn’t seem to work

The philosophy of  ’openness’ and ‘choice’ was the first thing I bought into when getting the Droid. After two years, while it still sounds like a nice idea, it doesn’t seem to actually work when put into action and instead seems to have caused an unintended consequence, fragmentation: devices are not getting the updates needed, showing a lack of support for customers but also slowing down improvements for the platform as developers turn away because they don’t want to deal with making their apps compatible for so many different versions. I’m not saying the open concept doesn’t work, it’s just that at it’s not showing any real benefits over the alternatives.

Better apps are on the platform that has incentives to create better apps

Android being open source doesn’t make a difference when developing apps since it’s ultimately just another platform to develop on. However, when you look at compare iPhone apps with Android, it’s clear that developers prefer to develop on the iPhone. Besides the fragmentation issue with Android, innovation seems to spur further innovation and the iPhone continues to keep that momentum going for its developers.

On a related note, I designed my own app for Android that kept track of pages I wanted to look at a later time. I outsourced a developer to program it and the experience didn’t go so well. Besides the fact that it took two months to get its basic functionality working correctly, it only lasted for another two months before something changed in the way it tied into Google Bookmarks and is now completely broken.

I have hope for the Android platform, but I’m willing to wait and see where things are two years from now when I look for my next phone. The phone and mobile device market is a very interesting point, who knows how things will be two years from now.

Here are the slides from my Desert Code Camp presentation. A big part of the presentation was just looking through the HTML/CSS code which you can refer to by just going to the links in the demo slides and going to your browser’s ‘View Source’.

To view the notes for some of the slides which include links to examples, click ‘Open in a new window’ button and go to ‘Actions’ at the bottom and then ‘Show speaker notes’.

My side project, Indie Aisle has been online for a few months now and as I did with designing the web app, I’d like to share my thoughts about the development process.

Layout and structure

I first started coding the HTML and CSS of the design. I used the opportunity to do some experimenting with the latest HTML5 and CSS3 techniques. The biggest part that came out of this was developing the layout to work across mobile devices using CSS3 Media Queries. I cover the results of the approach in a presentation I gave at Desert Code Camp.

Figuring out what language to develop with

As I was continued to code the front end HTML and CSS for the site, I also spent some time trying to figure what backend programming language I should go with. Should I stick with PHP since I had been using it for so many years and was most familiar with the way it worked? Or should I try a different, potentially more beneficial approach by using Ruby on Rails.

What I liked the most about Ruby on Rails was its framework concept. But I realized PHP had its own Model View Controller (MVC) frameworks as well. I decided to try using CodeIgniter to get a good feel for how the programming methodology worked. I went as far as setting up a couple dynamic pages that pulled in different sample data from a database. This gave me a better understanding of the dev process and even influenced the design since it was the first time I went through actual user scenarios.

After doing further research comparing Ruby on Rails to PHP and CodeIgniter and even to Python and Django, I ended up deciding to go with Ruby on Rails. While all had their pluses and minuses, Rails seemed to have the best collection of components which I figured would make the initial version quicker and more cost-effective to program.

Finding a good developer

By the time I got to this point, I happened to come across just the right article for my situation, “How to hire a programmer to make your ideas happen” by Derek Sivers, the founder of CDBaby. It helped me break down the development process and find a developer using online freelancing sites Elance and oDesk.

From using Elance in the past on client projects, the biggest lesson I learned from the experience is that communication is key. It’s important to find someone who clearly understands what’s required of the project and is able to discuss their approach to getting it done.

While I was already developing the front end code for some screens for the app, I realized how there were certain aspects I still hadn’t fully worked out. There were also all these features I had in mind to include but hadn’t really prioritized them based on what was important to get out initially, in a ‘version 1.0′. So just the exercise of thinking about every part of the interaction process and describing the functionality to someone who had to make sense of how to develop it was helpful in figuring out exactly how the final app would work.

Releasing a version 1.0

The developer I worked with on Elance for the first milestone did a great job and I ended up hiring him to develop the full initial release. By this point I already had the project broken down and most of the frontend code for all the screens, so I setup a Basecamp project and we were on our way. About two months later, a final product was coming together.

Before release, I had managed to gather some interest in the project and was able to do a short beta testing period. It helped with bug fixes and gave me a good look at areas that were unclear to users.

Indie Aisle finally went live in November and exciting as it was, the work was far from over. Having it out there meant getting some real feedback and seeing how people were using it. So based on that feedback, there was a lot of needed revising to do. Not only in code and functionality, but also in design and business strategy. There was so much time spent on how things should work from a technical standpoint during development, that the business side, the purpose of the site and its customers, seemed to get lost.

And that’s where I am with things today. We recently released a final piece of the puzzle to the overall concept, at least at this stage. Which means there’s another aspect I need to focus attention on: Marketing. I’ll cover that in the next installment.