Of products and projects

There are several approaches, when starting your own startup.
Most startups these days are using the approach of 'we build a great product, and users will come'. They begin with a vision, or a problem that needs a solution, and then build their service.
Some startups, however, take a different approach. These startups work mostly in the enterprise (B2B) arena. They actually begin as a one project company, and build their product for one customer. Then they refine, it as more customers come in.

The product approach is more common, because you don't have to do much as an entrepreneur - Just explain your vision, and if it makes sense (And you have some connections), you'll get some funding to begin. You can sprint your product, and then launch, and hope (Or use PR/ Community managers/ Marketing) to generate buzz and acquire users. Sometimes (Like, um, a lot of successful social companies) the product becomes a hit, and then you worry (Or not... Like Instagram) about monetizing it.

The project approach is harder. You need to partner with one (Or few more) customers, which will also pay you for your service (That doesn't necessarily exist yet). And then you have to deal with them, and all the growing pains of sorting out the problems. However, you might not need funding at all - This means, with current valuations and VCs pressing entrepreneurs desperate to keep their dream alive, that you might not need that phase at all. After you gain enough customers, you'll have a sense of what the market needs, and you can actually build a working product.

And then there's another approach.
Find a targeted person (Or small audience) for your idea, and build the product for him. (Or her... I'm using male for comfort reasons only) Treat him as a paying customer. Each one of your audience should be treated as a 'project'. Then you can actually get the real sense of what your product should be. 

Finally, here's a great product that succeeded mostly because the developers that built it did it for a great audience: Themselves. I wrote about MongoDB in previous posts, here's an explanation of what makes this product so popular:
http://blog.mongolab.com/2012/08/why-is-mongodb-wildly-popular/

The Microsoft manoeuvre

Well... October is here, and the three big ones (Google/ Apple/ Microsoft) are rolling new devices, just in time for the holidays.
And while Apple and Google try to kip the lid on official announcements (But most of us already know what's in store...), Microsoft has been all out, revealing everything they've got months ago.
I wonder how it will play out, but the most obvious question for me, having moved in the past years from Microsoft environment (Developing enterprise applications and servers using C++) to Apple and open source environment (Developing web applications, web services and mobile apps), is: What would make me move back to Microsoft environment.

And, seriously, right now - The only answer is 'opportunity'. The fact that not too many people are going to make the switch back, and if you're the first one posting a product to a platform that will reach tens of millions of users (And it will), then there's money in it.

I'm going to see Steve Balmer speak at think next. It will be interesting to see how this evolves.

If a tree falls...

In the forest, and no one is around to hear it does it make a sound?
If an independent developer publishes an app in the play store, and no one knows about it, will anyone download it?
Apparently, no.
And not only that, but when you search the app by exact name (No parenthesis), it would still appear 10th in search results.
This one's only regarding the play store, as the iTunes works differently.

Why is that? Could it be that Google promotes whoever pays them? I'll try to find out in the coming weeks. 
The first step would be publishing a link to the app from this blog. (And if you want to teach your kid English letters, you should try this... It's free.)

Let's see how it does soon.

https://play.google.com/store/apps/details?id=com.myartichoke.youngletters

Android app published... Some impressions.

After sorting out all the issues, along with some GUI tweaks, I finally got around to publish the application at the play store. (Get it here!)

Publishing process was a breeze - Compile the code in release mode, create a signing key, sign the app, upload (Along with promotional graphics), click publish, and that's it!

Seems like Google has the policy of 'garbage in/ garbage out', which means that rather than testing your app thoroughly (Like Apple do), which makes the whole publishing process take ~8-10 days, your app gets published instantly.

Which means that if an app sucks, Google counts on the crowd to rate the app accordingly. If it crashes a lot, or dead on arrival, you receive reports via the developer console, and can also 'unpublish' the app, update it as much as you want to etc.

Though I prefer the Apple way, which means that even if the app sucks, it still passes the bare minimum for usability, but I'm quite sure that this process helped android catch up the gap in 'total number of apps in the market' with iOS...

Young Letters - Tales of the Android project.

I've started working on the Android version for my young letters application.
Because I'm working with phonegap, I was quite sure that Android porting would work seamlessly, and boy was I wrong...

Getting started was easy. Download Eclipse, Android plugin and SDKs, define the project and setup the phonegap plugin was quick and painless.

However, my code didn't work.
First off, the newest version of phonegap (2.0.0) has some bugs. Seems like after the major overhaul from 1.x, several things (Like playing sound...) were left undone. So I've decided to revert to the same phonegap version I'm using in iOS (1.8.1), which solved the problem.

Some code issues, like resource file paths (Base path on android is different) and HTML5 canvas behaving differently than iOS webview were solved.

Orientation handling is also different than iOS: With Android, it's harder to define orientation changes behaviours (Young Letters is only landscape, for now). In iOS it's a breeze, just select the supported orientations, and you're good to go.

And then I was left with one major issue, which I'm handling now: The variety of android devices and viewports. With iOS, there's only one variation of a screen. The width/ height ratios stay the same between iPhone versions (iPhone 5 supports that ratio as well by framing the extra inch), but with android devices, you have to implement an adaptive HTML view.

Though it was solved in the native environment, the major lesson I've learned was to use percentages and dynamic placements of buttons, rather than set layout (Like I'm doing on iOS).

Then I need to test it with several devices, and see that it works.

Finally there's the whole publishing process in the Google Play store, but we'll get to that once the app is ready!

Updates, new app, new gadget

A month and a half after I've decided to go for it, young letters hebrew is available.
The whole process was quite easy and smooth, though I've had one rejection due to iPad 2x mode compatibility.
Currently app has no analytics connected to it (Next month probably, along with feedback and some UI changes), and now let's see how it catches on.

http://itunes.apple.com/us/app/young-letters-hebrew/id552401430?ls=1&mt=8

English app version will follow up.

You might also see some new recommendations content gadget on my blog: My friends at engageya are providing these, which are very useful in driving more traffic to your (As well as other) blogs.

My other friends in dSero have a great solution for surpassing ad blockers, which is also crucial for the blogging community - Seems like there's a lot of new cool initiatives regarding the blogging community, which, in some ways, has replaced editorial journalism.

As for this blog, other than testing purposes, no commercials are expected in the near future.

Click like an end user

I've recently had an emotional debate with developers about a design for a new content authoring product.
While we were building the UX and user flows, the developers have modeled their entities and data hierarchy, and wanted to propose a UX design that would parallel their data model and data flow.

That model, built like a nice view stack (Android style), meant that each entity would open a new view in order to be edited (With a 'back' button and a bread crumbs navigation), all due to the complexity of implementing an 'edit in place' editor for these entities.

While this solution has a very short time to market, scales well to new entity types, and looks cool, the argument that closed the debate was that the developers were not thinking like the end user.

As the end user edits hundreds of entities a day, 66% more clicks per entity and two more transitions (From one view down the stack and back up) would mean a lot more clicks and view changes, as well as would make work a lot more repetitive and tedious.

You can even describe the process, back to back:

Developer suggestion:
"Add entity, click to edit, view opens, edit, go back to view" (Repeat)
UX design:
"Add entity, click to edit (In place), edit" (Repeat)

Now multiply that by 1000s, and the difference is clear.

So next time developers come to you with the brilliant idea that might make the code be more maintainable and scalable, think about the end user as well... The last thing you'd want is that your version would be delivered in time and quality measures, but the users would hate it.