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.