Mobile/UI/Designs/TouchScreen/workingUI

UI to-do list

fennec requirements document

• navigation screen (integration with search) -- tentatively done
• bow
  • final list and layout of buttons -- in progress
  • site button? -- in progress
• what kind of bar at the top
  • URL/title bar -- tentatively done
  • permanent bar for system information -- for discussion
• page identity UI
• add-ons UI
• notifications UI -- in progress
  • • pop-up blocking
    • password manager
    • page trying to install a file
• actions UI
• Downloads (manager vs. low-touch progress indication)

• tabs switching (spatial) -- in progress
• bookmarks page (list or spatial) -- in progress
• find in page
• context menu (tap and hold)
  • Example: on a tel: - regular click to call, context menu includes add to address book
  • Example: hold on a link to sms/email/bookmark

• Preferences

Usage Scenarios and task flows

Usage scenarios: Mobile/User_Experience/scenarios

• please add!

Working Mockups

Note on the mockups

• these mockups are intended to describe interaction-flows and layout rather than pixel-perfect screens. Colors, branding, and icons are all just placeholders.

Basic Usage

On initial load (in this case, nytimes.com is the start page):

The user can scroll down the page while it is loading, in which case titlebar remains overlaid until page loading is complete.

When the page load is complete, if the user is mid-page, the titlebar disappears - all UI but for the permanent system bar is now out of the way.

If the user scrolls back to the top of the page, though, the titlebar is there, fixed to the top of the page.

Controls

Dragging horizontally beyond the page edge reveals the control strip.

When panning around a webpage by dragging, the user will often drag past the page edge. When this happens, the page should elastically snap back into place, but, in doing this, the user should start to notice that there are controls beyond the edge. When enough of the control strip has been revealed (when the page has been pulled past it's elastic breaking point), the control strip should snap into place when the page is released -- the exact point at which this should happen will take some iteration.

If the user is at the top of the page, such that the titlebar is still visible, the page slides horizontally under it to reveal the control strip:

If the user is further down a page, such that the titlebar is not on the screen, a titlebar should fade into view when a user drags the control strip in. Aza's prototype demonstrates a version of this behaviour.

(Control stip alternates considered: Mobile/UI/Designs/TouchScreen/workingUI/sidecontrols)

Navigation to a new page

The user starts a new navigation task (going somewhere new or searching for something) by tapping on the title "field" in the titlebar. The titlebar then grows out to reveal the following UI:

The user can type over or edit the currently highlighted URL, or choose from the set of awesomebar-sourced suggestions before anything has been entered. If the user begins to type, the suggestions update, awesomebar-style.

Note on awesomebar results: Awesomebar results are shown in a compacted form, meaning that the screen is less cluttered with small text, and allowing more tappable area per result. We can do this be only showing the title or URL that contains matching text (if both contain matches, we'd display the title).

Also shown are direct search buttons for a set of engines. In this way, the user can do quick lookups (facts, phone numbers, movie times etc.) without having to first navigate to the site in question. (see the Quick Lookup set of usage scenarios)

The UI as shown here leaves room for a soft-keyboard. On a device with a physical keyboard, we should take up the screen, giving us more room for suggestions and/or search engines.

Tabs

updated!

The user switches between tabs by dragging past the left page edge (i.e. - the side other than the one with the control strip). The area snaps into place in the same manner as the control strip.

If the user is at the top of the page:

If the user is anywhere further down the page:

The user taps on the wanted tab to bring it to the forefront (transition effect TBD). There is a "new tab" ghost tab or button that (a) creates a new blank tab and (b) brings up the navigation UI on top of it (see that section, further up the page).

Older, replaced design:

A user switches between tabs by dragging further out past the control strip to the tab area. This area snaps into place in the same manner as the control strip. mockup

Notifications

It makes sense to have notifications associated (a) with site identity, currently relayed through the title bar, and (b) associated with the other UI element that appears on its own (also the titlebar) and can linger, superimposed, while the user scrolls along the page. Also, a number of these notifications comes up at time of initial page load (pop-ups blocked, sites trying to install software, etc.), which is when the title bar is on the screen.

Two variants on layouts - there are trade-offs to do with ideal button size vs. amount of the screen consumed:

This method can be styled as appropriate for varying severity of messages:

Here, shown borrowing from Aza's great suggested geolocation prompt UI:

We could, optionally, have the whole assemblage fade from view if the user isn't interested in dealing with it and taps on the webpage beneath this. It could still be there, though, when the user goes back up to the permanent title bar at the top of the page, or when the control strip is dragged in.

Downloads

After clicking on a link, users get some form of save dialog (get this from platfom or design our own?)

When a download (or multiple downloads) are in progress, users get a lightweight progress indicator. This is a different kind of notification than the ones connected to the titlebar, which is appropriate -- these are meant to be more transient, for one, but also are browser notifications not affiliated with a specific page or site rather than a notification about the particular site you're on (this being part of why they're not attached to the titlebar). These ones, in addition for use in downloads, are used for messages like "Add-on installed" or "Update available."

Eventually, a user gets notified that the download is complete:

When these indicators are dismissed or dismiss themselves, they slide of the screen in the direction of the control strip, and aligned with the button that will let people get at download information:

Users dragging the page over to see where the notification went find a button. We can apply an effect to the button when there's something new to see (ie. download complete).

Very early layout idea for the "further information" screens:

Older working mockups

• Mobile/UI/Designs/TouchScreen/workingUI-old(bow) (replaced 2008-06-26)