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

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

Thankfully we do seem to be leaving the dark days of fragmentation in the Java mobile world behind us, it is fairly easy to get lulled into a false sense of security.

Shai’s closing comment on the article highlights the sort of “discovery” that device specific information, when not in the public domain, may cause many developers to burn time.

To quote Shai:

Applications are expected to explicitly declare their support for touch to utilize the full screen of the device. This is done using the following Jad flags:

Navi-Key-Hidden: true
Nokia-MIDlet-On-Screen-Keypad: no
MIDlet-Touch-Support: true

Notice that the last entry (MIDlet-Touch-Support) is required by current/older Samsung/LG devices but is illegal by the MIDP specification hence fails on Nokia etc. so for support on these devices you would need a copy of your JAD (only the jad) with this attribute added.

Read Shai’s full article, which includes some good tips on using LWUIT on touch devices http://lwuit.blogspot.com/2009/11/optimized-for-touch.html#ixzz0VvlYKZXm

For those of your that want Simonmaddoxs 0870 application for your Blackberry, Samsung, Nokia or LG Java enabled phone using LWUIT, this was put together during the night, so might be a little rough round the edges, so would welcome feedback via comments please

You can download it here with your phones browser http://kgutteridge.co.uk/0870.jad

If you want to just bluetooth it onto your phone http://kgutteridge.co.uk/0870.jar, Blackberry users please use your browser though

Have fun!

iPhone Video

Android Video

One thing that strikes me as a little odd though is the amount of coverage this application is getting, if I want a DRM music solution for a mobile phone there is another option, Nokia comes with Music which wont cost £120 a year…..

Maybe the catalogue is much better on Spotify this is obviously enough of a draw, I have been pleased with Spotify and even paid for a few day passes, so would be tempted to purchase a subscription to utilize this on my G1 if it had a standard headphone socket (I seem to consume ear buds in my sleep) or if the iPhone if it could play in the background, as the times I am listening to music on my iPhone is usually on the train when I like to clear email etc.
Maybe this has all come down to clever marketing on the part of Spotify compared to a seemingly more complex solution even though it is easier Comes With Music solution

Sonys Walkman phones would be a seemingly obvious addition as well going back to one of my earlier posts!

These thoughts are from an ex Sony handset user, my last four handsets have been as follows W800 -> K800 -> iPhone 2G -> iPhone 3G and when developing for J2ME the Sonys are always my reference device of choice (Since Jp3 and the K700)

I agree with Eriks comments that actually for a specific phone (especially a Sony JP8) its perfectly possible, with the utilization of modern libraries such as LWUIT to achieve an application that is as rich as the iPhone, especially for something like Spotify.

The problem here is that most people when they request a Java application, do not want a specific phone (iPhone) or family of phones (Sony JP8, Series 40 feature pack 3 etc), this is when fragmentation rears its ugly head and things get a little more difficult for people newer to mobile, as the write once run anyway promise breaks down rapidly.

The points Erik raises that are causing the headache for J2ME user experience right now can be broken down into certain areas

• Signing

The fact that the alerts that pop up and alert the user for things such as http connection and saving to the file system are irritating, however the majority can be removed by self signing the application with a Verisign/Thawte certificate (however the root cert might or might not be present on a given phone) , submitting the application through the Java Verified process, this certificate is on the majority of MIDP2 phones but not all.

In the case of messaging however, you would need your application to be signed either with the handset manufacturer or operators certificate, the problem with the operators certificate is for the people who have transferred network or have purchased an open market phone, They will not have the operators root certificate present and therefore the application will be unable to be installed.

• Discovery of application to install

Assuming you have managed to install the application, where has it gone? Apple really got this process spot on. After the user chooses to install something from the app store, the user then sees where the application will live, whilst it is installing, contrast this to the Nokia S60 experience and you can see the problem!

Then you run into the other problems that Apple have made easier for a third party developer

1. Worldwide Distribution
2. Favourable revenue share
3. Payment handled for the developer by Apple
4. Payment does not matter whether the user is accessing on WIFI or their cellular radio
5. Update process (achievable in J2ME but has to be coded into the application from the start and is not as pleasant)
6. Discovery of application
7. Device with a large screen, fast and plenty of heap memory
8. Educated users who know their phone is able to run applications
9. Trusting users who are happy to consume applications

Spotify should run well on Sonys and their developer program has long provided the following document which at least shows the promise of what a Java solution can enable if tailored for the Sonys, rather than employing the lcd approach to J2ME development. The problem of course then is there is a lot of handset groupings out there and tailoring an application for each platform needs to be done for a reason and unless the user experience is there for them to find the application once installed on their phone are they going to use it?

One thing is for certain though as the Java platform is open and you can self distribute, you can at least guarantee the application will be able to be placed upon the device it was developed for.

Spotify may say no to J2ME but Apple might say no to Spotify! (hopefully not)

information is here and Samsungs developer portal for Java is here

For those of us that are experienced at dealing with the Samsungs this is great news. However if Samsung are hoping to stimulate applications on their platform, specific information on the APIs and any device specific nuances that are implemented in their phones would be very useful. Simple information such as maximum jar size for a given phone is absolutely vital for any would be developer and is sadly lacking at the moment on Samsungs developer portal.

Ideally any handset manufacturer should provide device groupings like Sony Ericsson do, this would enable developers to have an understanding of what phones their application might run on and therefore allow them to support more phones, which benefits the would be end user, the developer and the handset manufacturer if they wish to encourage the eco system.

However as this and other recent entrants to the current app store craze, Should take notes it has not just been the application store distribution model that made Apples app store a success…

select
menu
cancel
ok
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday