STARTING OUT

 

Do go back and look at the original intro movies, the ads, and the Apple site demos.  Study carefully the size of rows, and what does what.  In our case, especially look at the way Safari moves its address and menu bars into view on any navigation (reducing your window size) and out of the way when you scroll.  (Wonder if JS scrolling one pixel down might automatically make the bars go away?)

  

What NOT to do with your 2" x 3" space (this pic resized to those specs):

 

 

GENERAL LAYOUT RULES

 

 

Don't design like today on browsers for mouse usage.  The buttons above are way too tiny to be used by fingertips.  It would be far better to split the table into two or more columns, with more square buttons.

 

Buttons should be a minimum of 1/2"" tall and wide, preferably with at least 1/8"" free space around them.

 

Make sure your app looks good in both portrait and landscape modes (see below).   For that matter, try to make it look fairly decent even if expanded beyond the current 320x480 or 480x320 iPhone screens.  That could change in the future and you don't want to have to rewrite things, if possible.

 

Any top menu should stay in place, so a person doesn't have to scroll to top to see it. Apple screwed up making a person scroll up to see their address bar again. They should've had it come up with a long tap, or bottom menu button or anything.  Perhaps they do, we just haven't seen it.

 

The "back" button should always match the title of the previous page. Otherwise the user gets mentally lost since titles don't match up.   So if you have a screen titled "Girlfriends", and you click on someone in the list to go to a page on that person, the "back" button should be at the upper left and have "Girlfriends" as its text.  

 

 

REWATCH THE ORIGINAL INTRO AND LATER ADS, TO DISSECT THE INTERNAL APPS

 

http://www.apple.com/quicktime/qtv/mwsf07/

 

http://www.apple.com/iphone/

 

http://www.apple.com/iphone/ads/

• Menu buttons at bottom if possible.  Data entry at top.
• Cancel button should be first from bottom in dialogs.
• Look at phone call overlay and main menu for button sizes.
• Common dialogs fly up from bottom (eg keyboard, calendar input, etc)
• Documents zoom open.
• Selections slide in from right.
• If it scrolls up and down, then selecting is the only option.

STUDY THE APPLE LDAP DEMO

 

http://zdnet.com.com/1606-2_2-6190224.html

 

Notice that they were too lazy to add special sliding effects to their own example web page.  Also use this demo to do the following:

 

WATCH WHAT SAFARI DOES

 

• Address and navigation bars appear on each navigation and when scroll to top.
  Disappears as you scroll down or zoom.  Perhaps can autoscroll a pixel to turn off?
• Accidental double-tap zoom could be very annoying. Wonder if can capture them?

DEVELOPMENT ENVIRONMENT

 

Of course, we’ll need a version without scrolling for the real iPhone, since it’ll handle that, the address bar, etc. 

 

We need a Safari test harness.  Similar to current demos with app inside iframe of iPhone picture.  Harness should have the ability to add scrolling code, do a history.back() and other Safari-like actions.

 

TOUCHSCREEN RULES

 

Beware designing for mouse use. Touchscreen buttons should be minimum 1/2? high x 1/2? wide, with 1/8? between them. For the iPhone, that means never more than four buttons across. Always leave about 8 pixels space from screen edges for input as well.

 

HANDHELD SCREEN RULES

 

• In general, you Do NOT want to use zoom.   Other browsers have that feature too, and it's not great for most apps:  http://www.s60.com/business/productinfo/builtinapplications/webrowser/
• NEVER hardcode sizes if possible.  Use percentages instead.
• NEVER hardcode a graphic width.  For example, banners should always be split into pieces, the middle one being a * percentage.  Most of the websites of people reading this probably break this rule.  Size your browser down and see if your site always looks good with no horizontal scroll bars.
• Vertical scrolling is okay.  Horizontal scrolling, even by finger, is usually a bad idea, as users can get lost.  So try to keep the content within the screen width.

• Okay, even though I said vertical scrolling is okay, try to hold down any scrolling.  Try to plan your pages so that a person has to do the least finger movement.

  
  

SCREEN ORIENTATION ISSUES

 

Since you can't control the browser's automatic page rotation, make sure your page looks good in both portrait and landscape mode.

 

That means, as mentioned above, making sure your banners are made of three pieces (left, center, right), with the center usually being the expandable piece.

 

If the browser acts correctly, then your page can receive a Resize event when the page rotates.  In some cases, you might want to reshuffle the content.

 

For example, if you have several buttons at the bottom of a screen, it often makes sense to move them to one side on a page rotation.   We do this with our field applications on handheld devices.   Essentially the page goes from one column to two.

 

LOCAL STORAGE ISSUES

 

Need to test max cookie size.  Most browsers limit to 4K *total* per path, with up to 20 subnames.  Go over, and some browser truncate, others "disappear" the whole cookie.

 

Trick for have more data: bring in multple iframes, each with cookies set for its path, for each 4K you need.  You can also pass data to another page by setting cookies in one page with the path of the target page.  This does not take away from the originating page's cookie space.

 

 

CONNECTION ISSUES

 

One difference between normal apps and browser apps, is that usually if comms fail you don't lose your entire page.   For example, in many web apps if you POST or GET another page but comms are down, you get a failed page... and the requesting page and its data are now gone.

 

Normally for web-based apps, developers write a custom browser shell that checks for connections before fulfilling a navigation request.  Unfrotunately, we can't do that.   Asking the user to go on/offline isn't nice either.

 

Two methods around that.  First, can use HttpRequests so that failure can be contained.  Or can display response in an iframe.

 

 

BANDWIDTH ISSUES
 

Similar to days of 56K modems, if person downloading over EDGE network.

 

Try to avoid large downloads, especially of large Javascript libraries if you're only using a few functions. 

 

This includes pre-sizing and optimizing graphics.

 

If you have access to server, set cache headers appropriately.

 

What we could do is determine / create a good set of libraries, and then download into cache for all apps to use.  Cross site security in this case requires that all apps be accessed via a common domain for this to work.  Not sure authors okay with this.  Just a thought.

 

 

-end-