Notes: Making content mobile

I attended Nad Rosenberg's fine webinar on "Making Your Content Mobile", which focused on how to make content accessible to users on any mobile device, including technical issues, usability, and legibility. Following are my rough take-aways.

Mobile apps fall into one of three camps:

1. Native apps: tied to hardware, very fast, phone-specific, usually C++/Java
2. Mobile websites: run on any device, but need internet connection and are slower
3. Hybrids: typically, apps run locally but stream content from internet

(1) HTML content's design issues 

• SIZE: must support a crazy range of resolutions and aspect ratios
• "NOT A PC": all-new TOUCH (not mouse) gestures: 
  • tap, flick, double-tap, pinch (zoom), shake (undo)
• NAV NEEDS TO GROW! tap region must be large enough (see Apple standards), must add white space between links for accurate tapping
• Streamline! test loading speed, remove eye-candy graphics, merge/flatten content to avoid links (every link is a download)
• SCROLL: get rid of excessive tabs, but okay to scroll vertically; must test extensively
• Testing trick: while you happen to be in a phone store (ahem), pull up your mobile site
• FAST FOOD: Mobile content is consumed on the go, so design for speed: less reading + less typing; simplify everything

(2) PDF documents 

• PDF on MOBILE (bad)- loading reader is a drag, content is laid out for print, too small to read; wasteful margins and page breaks; enlarging makes for annoying horizontal scroll; bad page flow

(3) WebHelp 

• Best practice: default page = TOC w/ search box, not links to TOC, Index, Search

(4) e-books 

• Evidence of growth: NYT bestsellers, FAA allows pilots to bring iPads; SKorea, all textbooks as ebooks
• Benefits: great at reflowing text, use on treadmills, no pg gaps (but no pg nos.), low-light features, progress bar
• Can build you own epub (open source, xhtml, zip of all needed files)
• Other formats: mobi, prc, azw
• DIY: html + conversion software: Calibre w/ Sigil, Adobe InDesign
• But, best results w/ plain text flows, not complex/diagrammatic/table-intensive content

(5) e-learning courses

• Disruption = fate of Flash! Apple won keeping off phones, so HTML5 porting seems inevitable
• Note: HTML5 standard not until 2014
• Choices:
  
  • swf > MP4, but no interaction
  • swf > HTML5, but still cooking
  • stay with swf and wait for conversion tools to catch up
• Despite format, tutorials will have to be redone because of size, captions, large touch controls, scale back content
• Recommendation: focus on performance support, quickest aid: short, easy, accessible. 

Resources:

• TechWRITE's blog
• Webinar recording
• Webinar slides (pptx)
• The webinar Q&A document (pdf)
• Webinar recording: "Going Mobile With Flare: So How Do I Use Flare To Go Mobile?"
• Blog post on Converting WebHelp Mobile output to a Mobile Performance Support Application
• More free webinars  

Comments

[farook]

I don’t think Flash is the one that requires a lot of computing power, it’s the fact of decompressing and decoding a very complex data in real time called “Digital Video”, Flash makes transparent the hardware calls implementation for the developers, with swf to html5 converter you will need to deal with conversion of flash to html5 players by rendering a lot of hardware engines, then multi-platform apps will be a true headache for the developers, the same problem than always: HTML hacks for each browser but with a more complex technology: HTML5

[mobile phone insurance]

good information thanks for sharing..!!