The iPhone, while simplifying some user interactions, actually complicates others.
This is something that really would not be possible without Ajax. Pretty much every input component could be made to simplify its rendering, visually, while not actively being used to input data. Another example of this would be text entry on the iPhone, with the popup keyboard. In a way, exhibits some of the first strategy already, by adapting between the two modes of displaying and entering data. But, where necessary, we'll have to detect when rendering to a mobile browser, and adjust accordingly. Where possible we'd like to keep the HTML markup the same, and simply be more mobile browser friendly. Probably the biggest TODO item in supporting mobile devices, for the component team, is simply rendering differently for mobile devices. 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. So, showing a date is best accomplished as text, and entered via a calendar. Plus, there's the whole issue of date format validation, whether they enter "January 16, 2008" or "6" or "", etc.
The text field will be smaller, and fit on a mobile screen easier, but will probably be more cumbersome for actual date entry. Perhaps a better example is with date selection, where we could use a calendar or a text field. Just looking at the versus list of components, we can see that there are several ways of accomplishing the same goal, but with implications for mobile applications. Some components might be able to accomplish the same tasks, where one would be richer than the other, or have other trade-offs. This is quite simple to do at the application level. Or, better yet, you can use several 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. And the switching will be done via Ajax, without disturbing the rest of the display. For example, you could use an component, or an in conjunction with an to create sub-panels, where only one will be shown at a time.
The problems is that you then have to have parallel page hierarchies, which have to be kept in sync as your application evolves.Īnother 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. 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. So, I'm going to look at ways of addressing this, from a component writer's perspective.Ī few differences between desktop and mobile web applications are:Ĭomplexity of the user interfaceShowing the user less information, and asking them to do less work, at a time. 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. 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. If you have a large screen, then you'll want to make more of the interface available to the user at a glance. 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. And that led me to think about some other articles I've read, including one by Ted, a co-worker of mine. 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.
0 kommentar(er)
