• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Finally, you can manage your Google Docs, uploads, and email attachments (plus Dropbox and Slack files) in one convenient place. Claim a free account, and in less than 2 minutes, Dokkio (from the makers of PBworks) can automatically organize your content for you.

View
 

Mobile

Page history last edited by Todd Parker 10 years, 5 months ago

Planning for jQuery Mobile

 

The primary focus of this effort is to design a cross-platform mobile UI system for jQuery. That being said, we believe that a shared design language and underlying code across all devices -- desktop, tablet, smartphone -- is going to result in a stronger design system and more maintainable development approach. Our initial explorations consider all three major form factors. Instead of simply tweaking the existing jQuery UI widgets to work on mobile, we're using this opportunity to take a step back and take a fresh look at what jQuery UI could evolve into in the future. Please consider these to be early future-state concepts that may change significantly over the coming weeks and do not represent a specific release. Feel free to let us know what you think in the comments.

 

Initial design explorations - July 21, 2010

Below is a set of proposed mobile widgets and layouts followed by a few samples of specific elements that may be a bit different on a tablet or desktop device. As a proof of concept, we've taken the new UI elements and shown how they could be assembled to build an email app appropriate for each class of device. You can see that there is more in common than differences and most of the adjustments have to do with optimizing screen real estate. That being said, a handful of widgets will have different designs and interactions -- for example, we're proposing a spinner design that uses a thumbwheel-like design for a touch device vs. traditional up/down arrows on a desktop. The designs cover the following topics:

 

  • Smartphone UI elements
  • Tablet UI elements
  • Desktop UI elements 
  • E-mail application example: Smartphone, Tablet, Desktop comparison using the same core UI elements 

 

Refined designs - July 22, 2010

We made some design tweaks based on feedback:

 

  • Buttons now have a bit more vertical padding, even more in the confirmation overlays for smartphone & tablet
  • Switch to a simple right arrow for drilldown rows
  • Revised disconnected tab strip
  • Depressed looking blue down state for tabs and buttons throughout 
  • Breakdown of various list view content variations and states including sortable and row delete interactions
  • Swapped cancel button style and position for smartphone edit header 
  • New menu button design
  • New tooltip design 
  • New split menu button (desktop)
  • New tree design (desktop)
  • New custom file input widget (desktop) 

 

 

To-do in the next iteration

 

  • Look at icon sizes/styles and work out a clear system
  • Color picker? (desktop) 
 

 

Download the Illustrator source file 

mobile-ui-22jul2010.ai (requires Adobe CS5) 

 

 

 

 

 

 

 

 

 

 

And finally, an example of how these same theme styles could potentially be applied to a corporate website. Now that the themes have more levers, it's possible to make a site that is workable with ThemeRoller:

 

 

ThemeRoller Impact

To make these designs work with ThemeRoller, we'd need to more than double the number of levers to give it enough visual texture to build complete UIs. The current ThemeRoller has just one header + content block + button (with states), while these designs use two of these lever sets (black + light gray) plus an accent button (blue) and uses lots of new CSS3 styling with text and box shadow so we will need to expand ThemeRoller  to support a more robust design system. In addition, we should add levers for a pressed (down) state, a body/base page content style, a secondary content style for things like striped table rows among others to make ThemeRoller really comprehensive. Once the designs are in good shape, one task we need to do is catalog the proposed ThemeRoller additions and migration path.

 

Visual design best practice research

The goal is develop a mobile-friendly design system that is ThemeRoller-ready and incorporates best practices gleaned from all mobile platforms instead of being an exact copy of a particular OS. 
These are screenshots of many of the popular mobile OS's for review:

 

 

 

 

Comments (19)

Jörn Zaefferer said

at 11:51 am on Jun 25, 2010

Getting jQuery UI running on Mobile Safari is a rather small challenge. Paul ported his mouse code to latest jQuery UI: http://github.com/pbakaus/jquery-ui/tree/touchready
I tested that on an iPhone 3GS with iOS 4: http://github.com/pbakaus/jquery-ui/commit/31bc28dffb811a35c9999d06238503821e5f196a#commitcomment-99313

A quicktest on Android 2.1 (HTC Desire) shows that both Draggable and Sortable are working fairly well.

wycats@... said

at 1:09 am on Jul 22, 2010

This is definitely a nice start. A few things I would like to see addressed:

* The pill style for buttons makes them seem like smaller targets than they actually are. Take a look at iOS and
Android. There are many more squarish buttons, which feel like more substantial targets.
* I would like to see a landcape version of these designs. In particular, when switching to landscape mode,
iOS makes the top and bottom UI elements narrower, to accomodate more space in the center.
* We should give a little thought to the choice of display font.
* I can't exactly tell what's going on in the disconnected tab style. The affordance for selection is kind of
weak. Similarly, I'm not sure that the connected tab style is a good metaphor for mobile. I haven't seen
it used in iOS, I think because sliding tabs (dot style) is more appropriate.
* iOS also provides segmented controls for tabs
* The only right-arrow style in list view is "detail disclosure" style. For navigation, standard disclosure
style can be extremely helpful.
* There's a bit too much usage of desktop metaphors which have been abandoned by mainstream mobile OSes
* Checkboxes and radio buttons don't work well on phones
* Date pickers present targets that are too small to hit reliably
* Drop-downs require fixed positions, because the typical solution (presented here) can only handle
a few elements on the screen, and larger lists (10+ items) are common

Todd Parker said

at 7:34 am on Jul 22, 2010

All really great feedback, thanks!

* Pill shaped buttons do have a slightly smaller target but are used in Palm Web OS without an issue so I think it's somewhat of a design preference. Corner radius will be controlled by the theme so a person can tweak the button style from square to pill and anywhere in between in ThemeRoller.

* Having a tighter set of UI elements in landscape mode is a really cool idea since it's mostly a tweak to padding - we should add that to the list of things to work out in detail

* Fonts are tricky because we're limited by what's installed on the OS. After some research, I went with straight Helvetica for the comps which is what's installed on all iOS devices and Macs. On Windows, this would fall back to Arial and on Android it would be Droid Sans, etc. The base font for the UI is another ThemeRoller lever so people should be able to define their preferred font stacks and the UI elements should adapt gracefully.

* The disconnected tabs are my least favorite element and we need to reconcile the style between the larger icon + text stack tabs with the simple text or icon only tabs -- right now, they are slightly different styles. Maybe Doug has some ideas on how to tighten this up?

Todd Parker said

at 7:35 am on Jul 22, 2010

(continued)

* Connected tabs, accordions, collapsible panels, radiobuttons, and checkboxes aren't used as commonly on mobile devices (namely iOS) but others do use these elements so in the spirit of being comprehensive and covering all the common UI elements (esp. those included in HTML), I think we should have a design for them and these all feel pretty usable to me with touch input on a small screen. I'm focusing on a more universal system that will work on desktop, tablet, and mobile so even though you don't have the screen for an accordion on an iPhone, you may want to use this on a tablet or desktop experience. Hopefully, we can create a really rich set of UI elements that are somewhat universal and leave it up to the individual designers discretion of how and where to use them. That's why you're seeing more desktop widgets here than in a strict smartphone OS design.

* The right-arrow probably should be the simple gray arrow, I was trying to be too fancy. I went with the gray arrow for cases where a click on the row will drill you down (navigation list), but the arrow really should look independently clickable and the gray arrow still does.

Todd Parker said

at 7:35 am on Jul 22, 2010

(last bit)

* Completely agree that dropdown/popup menus will only gracefully handle a small number of items but I think it's worth having as an option because it feels faster and more responsive than navigating into another page to make a selection. Think of it as a good solution for 3-5 items that you would normally use a segmented toggle for but the names of the values are too long to fit. The "drill menu" above the popup menu is meant to be the typical iOS style interaction where you drill into a full screen list view that supports scrolling to pick an item. We can also have an option for the menu to simply open the native select control when clicked so you can style the feedback portion but just let the picker part be whatever the OS decides. We need to look into this a bit more to figure out how many types we want to support.

* The datepicker control is modelled after the iOS/Palm WebOS calendar which feels comfortable for accurate selection. Is the Android version not easy to use? I'm just not a big fan of the iOS jackpot machine spinners for date selection because they seem so fiddly. Being able to surface the default OS datepicker control (if available) might be a good option to offer. Not sure if it's possible.

Keep the feedback coming. This is a great conversation.

wycats@... said

at 11:32 am on Jul 22, 2010

webOS' pills are rounder than iOS, but definitely less round (especially for buttons) than the mockups here. In particular, compare the bottom-of-screen edit buttons in the mockups with the edit button shown in your webOS research image under "Text Field".

I'm not so much concerned with the idea of using a pill in general, but think that the one shown above is a bit too skinny (in feeling and in practice). Thoughts?

Todd Parker said

at 3:02 pm on Jul 22, 2010

Gotcha. I think the solution is to make these buttons a bit taller. The wide stacked buttons used on the confirmations could use a fair amount more vertical padding to feel balanced but we could bump these up overall.

Anthony Hand said

at 10:11 am on Jul 28, 2010

I'm a UI designer at a large American handset manufacturer working on Android apps. How can I help?

I've also designed experiences for all of the major smartphone platforms. I see this project as key to helping me rapidly prototype client software experiences. (Though others may use this project to design web-based or web-packed-as-native-apps types of experiences.) So there are a few features I'd like to see in this UI component library -- and some potentially missing UI components.

Chief among the missing ones are the UI components which would help us design & build UIs like the fantastic new YouTube mobile site for iPhone and Android. Go to: http://m.youtube.com

Similar to those UI components, the new Twitter app for Android is really cool. It would be great to see these UI components also built into the framework. (Some of the UI components are also included in the YouTube mobile site.)

Please contact me offline -- I'd like to help work on this project!

shmerl said

at 11:36 am on Jul 28, 2010

This is nice. Do you have plans to implement Fennec (Mobile Firefox) support? It uses different touchscreen events model comparing to WebKit based mobile browsers. jQtouch library for example is not supporting Fennec, and it limits its usage on different platforms.

Ralph Whitbeck said

at 11:41 am on Jul 28, 2010

Yes we are planning to support Fennec browsers as an A-Grade browser.

shmerl said

at 11:45 am on Jul 28, 2010

Thanks, it's great.

dilip said

at 3:37 am on Aug 15, 2010

It's Really Good. Thanks

Rob Sterner said

at 7:24 am on Aug 17, 2010

This is great news! I'm curious if there's any alpha/beta period planned, I'd love to be a part of it.

sosensible said

at 8:46 am on Aug 17, 2010

Ditto on the alpha/beta. We (my company) is creating an integration library for ColdFusion developers and would love to jump in on this also. This fits in perfectly with one of our major intiatives.

sosensible said

at 8:46 am on Aug 17, 2010

Ditto on the alpha/beta. We (my company) is creating an integration library for ColdFusion developers and would love to jump in on this also. This fits in perfectly with one of our major intiatives.

manickum said

at 2:06 am on Aug 18, 2010

Will this be implemented with a library which will determine if the device supports JavaScript or not ? (E.g. WURFL)

maccman@... said

at 3:48 am on Aug 20, 2010

Great designs so far. One tip, remove any inset text-shadow - you can't do that with CSS.

David Muir said

at 10:34 pm on Oct 11, 2010

What's being used to actually detect mobile browsers?

You don't have permission to comment on this page.