Mobile/UI/Designs/TouchScreen/workingUI

UI to-do list

fennec requirements document

The UI checklist/progress document is now here: UI Checklist

Usage Scenarios and task flows

Usage scenarios: Mobile/User_Experience/scenarios

• please add!

Working Mockups - large-format screen (e.g. n810, android, iphone)

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.

Panning and Zooming

Panning

Panning, on a touchscreen device, is achieved through direct manipulation -- a finger placed on the screen and "dragging" what's visible as if it were a continuous plane.

Some details:

• linear panning when the user is in contact with the screen
• when the user "flicks" or "swipes" the screen pans kinetically
  • distance and speed traveled corresponds to the vigor of the flick
  • a flick at the most-vigorous end of the spectrum should allow the user to reach the left or right side of the page in one flick
  • when the page is scrolling by with the user _not_ in contact with the screen (ie. during a flick), the user should be able to stop page movement by tapping the screen (pinning the page down, essentially)
• we should constrain movement so that minor variances from an otherwise straight-line pan do not cause much jitter

Zooming

Structured Zoom

The primary zooming mechanism is double-tapping on a page element (column, image, other area) and having the page zoom to fit that particular element. This will involve some rules for different circumstances -- for example, the appropriate zoomed-in level for an image is probably to do a best fit, horizontally and vertically, so that the _whole_ image is as large as it can be on the screen; in contrast, the best zoomed-in level for a column of text is probably to fit horizontally only. Double-tapping again should zoom the user back out to the original page overview zoom level.

This is the primary scheme because it takes advantage of the fact that, generally, webpages have structure that corresponds to what a user is likely interested in. Structured zoom will be more often useful than arbitrary zoom.

That said, some mechanism for arbitrary zoom is still necessary for cases where this breaks down (e.g. zooming within an image).

Arbitrary Zoom

Arbitrary zoom is the case where the user wants to zoom in to a level that is not related to the edges of an element.

There are two parts to the information that a user has to provide in this case -- (1) how much to zoom in (or out) and (2) where to zoom in to (i.e. what is the centre of the zoom). Some interaction mechanisms let the user communicate both at the same time (the pinch gesture in a multitouch environment), others don't (choosing a zoom percentage from a list). One that addresses both would be better for Fennec.

1. Multitouch

• The pinching mechanism, as on the iphone another other multitouch devices, works very well but requires a mutlitouch device. Most devices on the market, at least at the moment, don't have this capability.

2. Successive touch (pseudo-multitouch) -- i.e. defining corners of a desired range with two fingers tapped in quick succession.

• Worth thinking about, but I think it will be too abstract for most users

3. Overlays - as in Android, where +/- controls show up over content. This has the disadvantage of only controlling zoom level, not location.

4. Gestural

• Tracing the area to which you'd like to zoom
• "Dialing" to zoom: clockwise to zoom in, counterclockwise to zoom out - like this:

There's an example of this in use here: http://socialhelix.com/ In that example, the gesture conveys only the zoom level, but we could make it also convey zoom location. The area circled, when dialing in, could be the area to zoom to -- this allows correction as you go in, by refining the encircled position. This gesture also has the benefit of being continuous -- you can just keep dialing until you're at the right level of zoom.

This last one is what I think we should try out.

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

Bookmarks

Designs here:

Mobile/UI/Designs/TouchScreen/workingUI/bookmark_management

History

The primary access to history, other than going back or forward a single page through the back and forward buttons, is via the awesomebar. For the key use case of going somewhere you've been before, using the awesomebar is the primary mechanism.

That said, there's also a use case wherein the user wants to go back a few page (often while avoiding loading the intervening pages) -- e.g. to get back to the front page of an online newspaper after finishing reading a multi-page article. In this case, being able to see a list of recent history is very useful. UI for that usecase is explored here:

Mobile/UI/Designs/TouchScreen/workingUI/visual_history

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).

For a draft of a downloads list (i.e. "download manager"), see here: https://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI/downloads_concepts

Add-ons

Draft: https://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI/add-ons_concepts (WIP)

Actions

Identity

Two concepts here: Mobile/UI/Designs/TouchScreen/workingUI/identity_concepts

Leaning towards the notification bar approach (alternative 2) at the moment, in the name of not having yet another means of displaying information about a page.

Extended Site Button

Authentication

Client Certificates

Username/Password

Preferences

note: there's a bit more off the end of this next mockup -->

Also see: http://madhava.com/egotism/archive/005024.html

Context-sensitive Menus (CSM)

See here Mobile/UI/Designs/TouchScreen/workingUI/CSM (work in progress)

Desktop Integration (weave)

Working here: Mobile/UI/Designs/TouchScreen/workingUI/desktop_integration

Working Mockups - small-format screen (e.g. windows mobile)

Working here: Mobile/UI/Designs/TouchScreen/workingUI/small-format

Older working mockups

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