Java ME is Dead, Long Live Java ME !
No sooner had the words slipped from James Gosling's lips than programmer friends were emailing me with "I told you so" messages. Later clarifications will no doubt do little to rein in the idea that Java ME is on the way out, to be supplanted by JavaFX Mobile. Yet for all the good it will do to protest that the latter is merely a layer atop the former (well, more or less) it must be acknowledged that JavaFX has made mobile Java development seem somewhat sexy (again?)
There used to be an old programming motto, "every program expands until it can send mail." A modern equivalent might be "every user interface gets prettier until it requires 3D graphics hardware." If the iPhone has proven anything, it's that the mobile space has outgrown the functional card-based UI's of MIDP's LCDUI, and ventured into the glossy world of tilt sensors and swishy transition animations. And the public are clearly all too willing to get excited about a product merely on the basis of tilt sensors and swishy transitions — because, let's face it, sans UI gimmicky the iPhone is actually a decidedly under-achieving phone.
If nothing else there is one strong factor qualifying Java ME's continued existence: no matter how small the gap between the silicon in your hand and on your desktop, ultimately hand helds are, erm well, hand held! Take for example Sony's Playstation Portable. Whether you're a fan of the brand or not, one has to admit that for a box of that size the PSP delivers quite a solid CPU and graphics punch. Yet the PSP's XrossMediaBar (XMB) navigation is a far cry from what one would normally expect on a desktop application, combining simplicity and clarity with just a hint of bling.
Clearly, sitting somewhere between the uninspiring card UI's of MIDP and the rich keyboard/mouse driven UI's of the desktop, there exists a middle ground. A place where simplicity is paramount, and intuitive-ness (new word!) is king; where developers lack the luxury of a desktop screen/keyboard/mouse, nor can they expect users to lug around a 400+ page user manual. With room to show only one aspect of an application at a time, UI designers must work harder to provide a sense of how all the components fit together. Powerful yet simple navigation is the key: where am I?, how do I get where I want to go?, and how might I get back again once I'm finished?
This is fertile ground into which a rejuvenated Java ME can grow...Early graphical OS's ran on screen resolutions not too distant from those which mobile devices are now starting to reach, yet some of those early GUI stalwarts were incredibly wasteful of display real estate. With large displays and unrestricted input devices it was possible to get a little sloppy — if you needed more space just use a scrollpane or open another window.
A few years back I had a go at seeing if I could tame some of the more wasteful components. The slider/scrollbar has always seemed to me to be the worst offender, with 'shafts' often dominating the design of any interface hosting them. I've always found working these components into a balanced UI very hard. Their long thin shape is awkward to work with, meaning all too often the shaft gets crushed at the expense of precision. Yet I'm not sure there was a much demand for the popup variant I developed (which admittedly was a direct steal from an old Amiga component library.) Sliders are infrequently used in interfaces, perhaps precisely because of their footprint problems, so a more compact alternative was maybe not considered so urgent.
Yet with small screen devices like the iPhone and PSP could we see a renewed demand for footprint friendly components like the JPopupSlider? I suspect we might.
Certainly Java ME developers do need some kind of new component library, breaking free from the blandness of LCDUI's cards, but not assuming the sumptuous screen size and input options which Swing apps take for granted. And so, taking my lead from Sony's XMB, I decided to knock up a rough prototype to tackle one component which presents particular problems in a limited display/input environment, yet could prove incredibly useful to any mobile UI designer: namely the tab pane.
The problem with the tab pane is two fold. Firstly, even on desktop displays the simultaneous appearance of more than half a dozen tabs often leads to an unreadable clutter. Secondly, the tab component is usually employed to break up large complex interfaces (like configuration UI's) which generally demand frequent flipping between pages — yet continually needing to navigate off the current panel to the tabs without the aid of a pointing device (aka, a mouse/stylus) is likely to be painful.
What we're after is something...
- Easy to invoke.
- Demanding minimal input control.
- Clear to read, even with dozens of options.
- Visually quite cool.
After a fair amount of messing about, experimentation, and blind alley backtracking, I eventually settled on what I call (rather unimaginatively) the XBar Navigator. It's a menu with vertical and horizontal overlapping rings, sitting within the glass pane, and appearing only when certain control keys are held. Up/down arrows are used to spin the vertical ring to a main category, while right/left arrows select a sub option from the corresponding horizontal ring. It may not be the most original design in history, but then originality was not the aim of the exercise.
As perhaps evident from the screen shot, I was too lazy to create dozens of mock UI panels, so instead I wrote a crude image viewer to serve as the test harness for the component. The vertical ring controls the categories (mapped to directories) and the horizontal selects individual images. Left CTRL+ALT are used to activate the control.
Curious readers can download the rough-cut demo here (925k), complete with (mostly public domain) test images.
XBar is far from a finished component. Indeed if anyone wants to actually use the XBar themselves I'd suggest they scratch the current source base and start over. The rough prototype is just that: rough and unpolished. Its animation may glitch (particularly on Linux) and it doesn't handle losing window focus all too well. Also, I'm sure you can imagine the effect so much trial'n'error had on the code itself! Sure, XBar could be better, but it proves a point: with a bit of invention one can tame even tricky desktop UI components and make them accessible to devices with limited displays and input.
I know some of you might be asking "could this new library not be developed under JavaFX Script?" Well, JFX Script is good at manipulating existing components, but my experiments thus far with creating components from scratch leaves a lot to be desired. I suspect the intention was always that JFX would merely add a rapid data binding and animation layer onto UI components written in 'native' Java. Certainly this is the impression I get.
The true home for any new component library would be in Java ME's LCDUI package, or a 'Mark II' enhancement thereof. Reports of Java ME's death are therefore greatly exaggerated. Indeed far from dying it needs to grow to meet the needs of a new and more sophisticated class of device. The Swing and Java ME communities must to work together, inventing new Swing Mobile components which creatively meet the challenges these new devices present, ready for FX developers to pluck 'off the shelf' for maximum visual effect and user interface efficiency.