Mobile UI

Project Goal

Design a standalone application optimized for accessing and sharing content inside MindTouch Deki through a mobile interface specifically for RIMM Blackberry and AAPL iPhone. This is different than supporting a mobile-friendly skin inside Deki, since we will optimize the read/share content use cases instead of the edit/collaborate use cases (which the main application does).

This project will also be a more self-contained example of how to utilize MindTouch Deki's API to rapidly deploy alternate entrypoints to Deki content.

devs: irenev, jroeckel, royk, guerric, fallonc

Related links

Mobile UI from Blue Flavor - A little old (2006), but still good info

iPhone Web Apps Guidelines

Small Surfaces - all about mobile UI; seems like a good resource, but I've only skimmed it

Blackberry Resources - developer labs, journals, tools

W3C Mobile Phone Best Practices - as of Nov 2006

Key points from iPhone UI guidelines

Here are some key points from the iPhone UI Guidelines that I feel are worth noting. Some might be obvious, but just wanted to make sure we're all on the same page:

• use typography to show hierarchy and importance
• avoid any purely decorative elements (creates clutter)
• minimize required input (consider cookies for storing info, or use lists since it's easier for users to select from a list than to type words)
• provide fingertip-sized targets (44 x 44 pixels) -- iPhone only
• keep in mind that users on a mobile device will most often be in environments filled with distractions (so keep things simple and provide contrasting, bold elements to grab attention where necessary)
• users have a more personal relationship with their mobile device than with their computer (they bring it with them wherever they go) so your site/app must be streamlined and inviting
• content must be designed to work well at slow connection speeds
• text blocks spanning the entire width of the device are difficult to read...

• ...so present text in relatively small, easily digestable blocks (think newspaper layouts) to avoid panning back and forth
• use user-centric terminology
• provide feedback when necessary (ie. when communication with the server or downloading its resources, provide some sort of progress indicator)
• keep the design consistent with the other mobile apps -- don't make the user learn anything new
• make sure your content can handle frequent interruptions (ie. taking a call)
  
• when appropriate, think about including links that allow users to make a phone call, open mail, look at Google maps or view videos

More key points from other sources on the web:

• bright background colors/patterns can hide glare and fingerprints (but let's not get too carried away here...we don't want to blind our users)
• ambidextrous design must be considered for layout and placement of buttons (option to flip layout? although if the layout is designed correctly, this shouldn't need to be an option)
• tables & frames = bad. just say no.
• provide a text equivalent for every non-text element
• do not use pixels or absolute units for measurement -- use percentage and relative measures (ie. em, larger, bolder, thick)
• provide easy navigation away from error messages (don't rely on every device having a built in "Back" button)

Whenever considering including something in the design, make sure you ask this question first:

Is this critical information or functionality users need right now?

Safari vs. Safari on iPhone

Safari on iPhone supports:

• Safari supports cookies on both
• Safari on iPhone allows up to 8 user initiated browser pages to be open at once.
• Default user preference is set to block pop-up windows.
• Safari on iPhone supports many MIME types and rich media, including PDF and media file types
• Images: Safari supports .gif, .jpg, .png, and .tiff
• Fonts: The iPhone comes with American Typewriter, Arial, Arial Rounded MT Bold, Courier, Courier New,Georgia, Helvetica, Helvetica New, Marker Felt, Times New Roman, Trebuchet MS, Verdana, and Zapfino
• Other than the :hover pseudoclass which isn’t supported on the iPhone since mouseover effects aren’t supported, Safari on the iPhone supports CSS1, CSS2 and several selectors and attributes of CSS3

Safari on iPhone does not support:

• Events: mouseover and mouseout, including :hover styles and tool tips, (but it does support onclick and event listeners). Safari on the iPhone does not support the document events of onkeydown, onkeypress and onkeyup, the form-field events of ondblclick, onmouseenter, onmouseleave, onmousemove, and onSelect, and the window events of onresize and onScroll. This is not an exhaustive list, so test your event handlers before listening to me.
• window.showModalDialog()
• Plug-ins: Flash or Java, and plug-in installations. Do not ask users to download Flash.
• File-size: Non-streaming files of over 10MB. CSS, JavaScript and HTML files are limited to 10MB per file. JavaScript is limited to 5 seconds of execution time. Safari for the iPhone does support gzip compression, so compress!
• The iPhone does not support gifs, png or tiffs over 8 MB and jpgs over 128 MB (but does support larger streaming media files).
• You can use iFrames, but avoid framesets.

(from http://www.evotech.net/blog/2007/07/...or-the-iphone/)

http://www.youtube.com/watch?v=sdUUx5FdySs

The iPhone Blog

Future Features

• Recent changes
• "Sent from my iPhone" to be displayed in Notes/Share page messages
• Notes being able to keep track of new notes (like Apple Mail) and count down when a note is checked