http://theoatmeal.com/blog/apps

I do question whether this was a metric that developers found easy to manipulate in the early days of app stores that may not necessarily hold true in the longer term, a great comment I once read stated

” 3/10 cent a gallon for water delivered straight to the home.
$1.50 gallon for a jug in isle 13 at your super market
or $1.75 for a 20oz bottle at the checkout counter.
Are these all the same product? Do they even compete?”

This statement lead me to read the great book Positioning The Battle for your mind by Al Ries and Jack Trout, whilst on the face of it, it is all common sense I do wonder how much is being applied to the current mobile app stores and the shovelware mentality of ship it and they will come

I have long been the advocate of the difference between $ 0.99 and $1.99 is nowhere near as vast as the chasm between free and $0.99. If you can convince your users to pay for your product are you really going to put off 50% of these people for the sake of $1?

Romain Nurik posted an excellent article today on why you need to hand edit layouts for Android rather than using a WYSIWIG tool

First off, there will be some obvious bias in this post. I have been very fortunate in my working career to work with some truly great product managers, designers and artists on mobile applications and so for the benefit of the app consuming public none of my frankly brilliant crap UIs have ever seen the light of day. I do however still look forward to the day where by I can put a cheat mode into one of our own applications that resorts to developer place holder graphics! Some great examples of what games look like before an artist breathes on them can be found on this thread at Toucharcade

If you take the same view point as me, that to make a truly decent user experience for a given platform especially on mobile,  then you need to understand the technicalities and nuances of developing for that platform. A great example of this would be the difference in the back metaphor on various devices,  on Blackberry and Android you have a dedicated back button, iOS the use of UINavigationController and for Java mobile devices the use of soft keys and context menus.

Knowing these interface cues is why there needs to be a close interaction between developer and designer. It makes sense if a fast utility application is required to make  sure standardised controls of the platform are used where possible  (ie ContextMenus on Android vs UIActionSheet on iOS vs Softkey driven menus on Java based devices) otherwise a lot of development time can be expended on making custom UI controls that may or may not be necessary, if all stakeholders are aware of what components are available on a given platform. For this reason alone it is worth at least having a WYSIWIG  editor so that designers who may be new to a platform (Java MIDP2 is younger than publishing to the web, and Android, iOS, WebOS are relatively new, let alone the even newer platforms mobile designers will have to contend with in the future ie Meego, Bada etc etc) have the ability to experiment with the UI widgets that are available for a platform and produce mockup guis that a developer can then bring to life!

The other area where at least having a fast preview of changes to the UI code is where a WYSIWIG editor can really help, or at the very least a very fast way of previewing on a decent simulator, in fact it has to be said MicroEmu perhaps leads the way here when it comes to very rapidly changing screen sizes

Where both Android and iOS have succeeded in my view is that they have made the information on what designers have to work with is far more readabily accesible. A simple Google search for icon design guidelines for three popular platforms will tell you a lot, bearing in mind with the current trend of app stores the icon is the first piece of information that you are likely to convey to your user therefore it pays to have the perfect dimensions. For example try the following searches

“Blackberry icon sizes”

“iOS icon sizes”

“Android icon sizes”

“Nokia icon sizes”

Having to dig for this sort of information is what in the future will infuriate both developers and designers as new devices, screen sizes and user interactions are released into the market

Therefore until Android becomes as set in stone as HTML/CSS I don’t believe many designers have the time to teach themselves another XML based layout manager and need to work closely with developers and hopefully have some sort of ability to experiment with UI metaphors without a developers assistance. This is something which a WYSIWYG tool whilst most likely constrained to a single resolution at least provides. Once this point is reached, much like a sane server admin will never let a developer loose on production infrastructure without supervision, a designer will not let the developers near the UI without their guiding light

However until that day I concur with Roman a hand coded UI will be superior this is still true even with WYSIWIG tools such as Interface builder on iOS

• Icon.png – Home screen icon for iPhone 3 (57×57)
• Icon@2x.png – Home screen icon for iPhone 4 (114×114)
• Icon-72.png – Home screen icon for iPad (72×72)

• Icon-Small.png - Settings/Spotlight icon for iPhone 3 (29×29)
• Icon-Small@2x.png – Settings/Spotlight icon for iPhone 4 (58×58)
• Icon-Small-50.png – Spotlight icon for iPad (50×50)

• iTunesArtwork – Icon for iTunes AdHoc distribution (512×512)

http://android-developers.blogspot.com/2010/06/future-proofing-your-app.html

The aapt tip for dumping out what features your app requires was certainly new to me!

For anyone who is not aware or newer to Android, I always feel the need to highlight the Draw 9-patch technique as something that  will help immensely when dealing with differing screensizes, and I am sure those that are using vanilla UIImage on iOS devices will come to envy in the future when supporting multiple screen sizes in an easy way that does not require code changes.

The following session video from Google IO on supporting multiple handsets almost goes into far too much detail and makes this problem space seem much harder than it actually is! However I and as am sure many, fully appreciate the highlighting of potential pitfalls that we may run into, rather than having to discover some of these hazards at some point through the development cycle of an application!

For those envious iPhone developers of NinePatch images you may wish to check out the following project http://blog.tortuga22.com/2010/05/31/announcing-tortuga-22-ninepatch/

Steve if you believe replied to emails sent stating

“We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”

Far greater than how something has been written is the problem of shovelware, whilst it allows the store to quote very large numbers of applications compared to the competitors of the app store, how many companies are submitting multiple applications every day of debatable quality or at least that could be combined together. Some of the worst offending companies have been removed from the developer program

So ignoring the arguments on whether what Apple is doing with the new terms in the sdk agreement is right or wrong and what effect it has on native cross platform app development. I was thinking what else they could do for the submission process for their platform if the stated aim is simply to raise the standard of apps, regardless of how they are produced.

One of the reasons for me that the app store has been a success for developers, has been how much easier it is to make an application available to the paid market globally, unfortunately this has meant the friction barrier is so low, that it allows for shovelware to be a positive revenue generating tatic. Thankfully this is actually quite an easy one to stop by implementing a cost barrier like Palm have on their app catalog, quite simply if you wish to make an application available there is a $50 cost. This simple barrier to entry means if the developer doesn’t believe their application is going to return at least $50 they will be unlikely to submit it or burn through cash and be stopped that way.

Theres a great set of videos explaining buffer overflow attacks starting here
with a hands on demo of return to libc hacks here

Available on iTunes:

http://bit.ly/knowcolor

Amazing how after a few days away from the computer at Xmas can lead to inspiration for a small game, so after I had decided it had been too long since I had made a little fun game and as I wanted to play this myself! I got started, a few days later Know Color was born!

Subsequent posts will show the early stages of this game before there was any artwork and it looked very very different, and some notes on porting this game concept to other platforms.

The app store approval time was truly amazing, with this game being made available for sale 24 hours after submission, so thank you Apple!

For now though here is an app description and some visuals of the game:

Prove you’re smart and know color. Can you beat the Professor and your friends?

A game of speed and skill where you have to select the correct option matching the Professor’s instructions as quickly and accurately as you can. Post your high score to Facebook and Twitter and dare your friends to beat you! Who is the smartest of you all?

In 50 seconds score as high you can, you score one point for each correct answer but will lose 3 points if you answer incorrectly so be careful!

View a video on YouTube:

You can find some images of the game here

Andrew Girow has kindly made his lightweight implementation freely available http://tinyline.com/utils/index.html