I was reading this guy's article, and more importantly the readers' comments, about writing JSF applications for mobile applications, and thinking about what ideas best fit with ICEfaces. And that led me to think about some other articles I've read, including one by Ted, a co-worker of mine.
http://blog.icefaces.org/blojsom/blog/default/2007/09/07/Ajax-on-the-iPhone-with-ICEfaces/
The problem is that you can't really write once and run anywhere a web application, with a sophisticated user interface, simply due to screen real-estate trade-offs. If you have a large screen, then you'll want to make more of the interface available to the user at a glance. There's a psychological limit to that though, creating an upper-bound on what you can have in a web page, even on a 30" display. Unfortunately, there's a lower-bound as well, so we can't just target mobile browsers with small screens, and expect desktop users to be happy. So, I'm going to look at ways of addressing this, from a component writer's perspective.
A few differences between desktop and mobile web applications are:
Complexity of the user interface
Showing the user less information, and asking them to do less work, at a time. This can be accomplished by breaking that page into several pages, like a wizard, or by relying more on drill-down detail pages to show successively more detail.The problems is that you then have to have parallel page hierarchies, which have to be kept in sync as your application evolves.
Another approach is to remain with the single large page, but use intra-page data hiding, so that all of the data is on that one page, just not necessarily at the same time. For example, you could use an <ice:panelTabSet> component, or an <ice:menuBar> in conjunction with an <ice:panelStack> to create sub-panels, where only one will be shown at a time. And the switching will be done via Ajax, without disturbing the rest of the display. Or, better yet, you can use several <ice:panelCollapsible> components, where all of them could be expanded at once, for the desktop user's benefit, or only one at a time be expanded, for mobile users. This is quite simple to do at the application level.
Functionally equivalent components
Some components might be able to accomplish the same tasks, where one would be richer than the other, or have other trade-offs. Just looking at the <ice:panelTabSet> versus list of <ice:panelCollapsible> components, we can see that there are several ways of accomplishing the same goal, but with implications for mobile applications. Perhaps a better example is with date selection, where we could use a calendar or a text field. The text field will be smaller, and fit on a mobile screen easier, but will probably be more cumbersome for actual date entry. Plus, there's the whole issue of date format validation, whether they enter "January 16, 2008" or "2008/01/16" or "01/16/2008", etc. So, showing a date is best accomplished as text, and entered via a calendar. In that case, one would use <ice:selectInputDate renderAsPopup="true"/>.Still, in the immediate-term, it will undoubtedly be necessary for some applications to use lowest-common-denominator components, or different pages with different components, for mobile versus desktop interactions.
Device aware component rendering
Probably the biggest TODO item in supporting mobile devices, for the component team, is simply rendering differently for mobile devices. Where possible we'd like to keep the HTML markup the same, and simply be more mobile browser friendly. But, where necessary, we'll have to detect when rendering to a mobile browser, and adjust accordingly.In a way, <ice:selectInputDate renderAsPopup="true"/> exhibits some of the first strategy already, by adapting between the two modes of displaying and entering data. Another example of this would be text entry on the iPhone, with the popup keyboard. Pretty much every input component could be made to simplify its rendering, visually, while not actively being used to input data. This is something that really would not be possible without Ajax.
The iPhone, while simplifying some user interactions, actually complicates others. For example, how does one do Drag and Drop, when finger dragging has been re-appropriated to mean scrolling? Will we simply not support Drag and Drop, or will we have to render some WebKit specific markup? Or, since the iPhone uses a special interface for menu selection, how can we adapt <ice:selectInputText> to benefit from that, if at all possible?
The main example of a component that already renders itself differently, depending on the user's browser, is <ice:outputStyle>, which will output a link for a main CSS file, as well as one that is specific to the user's browser, thereby allowing for CSS work-arounds for web browsers' idiosyncrasies.
CSS styling
Which brings us to CSS, and styling web pages differently for desktop versus mobile browsers. Currently, <ice:outputStyle> can differentiate between:- Internet Explorer 6.x and below
- Internet Explorer 7
- Safari
- Safari on the iPhone
- Opera
- Opera Mobile
As you can see, you can serve out different CSS files for the main mobile browsers, automatically, without any application level coding. Over time, the default CSS styles for our components, for the mobile browsers, will get more and more refined. But, the beauty of targeting feature-complete mobile browsers, like Safari and Opera, is that few changes need to be made to styling.
