MozillaWiki

Mobile/UI/Designs/TouchScreen/workingUI: Difference between revisions

Page Discussion

Mobile/UI/Designs/TouchScreen/workingUI (view source)

Revision as of 22:58, 11 December 2008

10,573 bytes added ,  11 December 2008
no edit summary
No edit summary
 
(41 intermediate revisions by the same user not shown)
Line 3: Line 3:
[http://people.mozilla.com/~csejersen/fennec/req.html fennec requirements document]
[http://people.mozilla.com/~csejersen/fennec/req.html fennec requirements document]


* navigation screen (integration with search) -- tentatively done
The UI checklist/progress document is now here:
* bow
[http://spreadsheets.google.com/pub?key=p2tjDbTybTBrG9uAjuSPTZQ UI Checklist]
** 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 and task flows==
Line 34: Line 12:
* please add!
* please add!


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


=== Note on the mockups ===
=== Note on the mockups ===
Line 42: Line 20:


=== Basic Usage ===
=== Basic Usage ===
On initial load (if, in this case, nytimes.com is the start page):
On initial load (in this case, nytimes.com is the start page):
 
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/basic1.png
 
 
The user can scroll down the page while it is loading, in which case titlebar remains overlaid until page loading is complete.
 
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/basic2.png
 
 
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.
 
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/basic3.png
 
 
If the user scrolls back to the top of the page, though, the titlebar is there, fixed to the top of the page.
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/basic4.png
 
=== 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:
 
http://people.mozilla.com/~madhava/files/mobile/zooming/dialing_to_zoom.png
 
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.
 
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/controls_progression_final.png
 
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:
 
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/controls1.png
 
 
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.  [http://azarask.in/blog/post/firefox-mobile-concept-video Aza's prototype] demonstrates a version of this behaviour.
 
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/controls2.png
 


http://people.mozilla.com/~madhava/files/mobile/2008-06-04/1.png
(Control stip alternates considered:  
[[Mobile/UI/Designs/TouchScreen/workingUI/sidecontrols]])


=== Navigation to a new page ===


Beginning to scroll down the page while the page is loading.  The titlebar remains overlaid until page loading is complete.
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:
http://people.mozilla.com/~madhava/files/mobile/2008-06-04/2.png


Page load complete. UI is fully out of the way.
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/nav1.png


http://people.mozilla.com/~madhava/files/mobile/2008-06-04/3.png
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).


A user brings up the primary UI (bow and titlebar) by tapping/touching one of the lower corners.   
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 [http://wiki.mozilla.org/Mobile/User_Experience/scenarios#quick_lookup Quick Lookup] set of usage scenarios)


'''Button set and arrangement TBD.'''
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.


http://people.mozilla.com/~madhava/files/mobile/2008-06-04/4.png
=== Tabs ===


=== Page Edge control strip ===
'''updated!'''


This is an alternate design to the bow:
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.
[[Mobile/UI/Designs/TouchScreen/workingUI/sidecontrols]]


=== Going to a new page===
If the user is at the top of the page:


The user starts a new navigation task (going somewhere new or searching for something). He or she is presented with an entry field, and we also put up some awesomebar-sourced suggestions before anything has been entered.
http://people.mozilla.com/~madhava/files/mobile/2008-07-07/tabs_left_topofpage.png


http://people.mozilla.com/~madhava/files/mobile/2008-06-04/5.png


If the user is anywhere further down the page:


When the user begins to type, the suggestions update, awesomebar-style, and we also reveal buttons to immediately send the entered text to a search engine. 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.
http://people.mozilla.com/~madhava/files/mobile/2008-07-07/tabs_left_midpage.png


http://people.mozilla.com/~madhava/files/mobile/2008-06-04/6.png


===Tabs===
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).
Spatial work documented here: [[Mobile/UI/Designs/TouchScreen/Spatial]]




'''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.  [http://people.mozilla.com/~madhava/files/mobile/2008-06-26/tabs1.png mockup]


===Bookmarks===
===Bookmarks===


Spatial design documented here: [[Mobile/UI/Designs/TouchScreen/Spatial#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===
===Notifications===


====concept 1 - notifications attached to the titlebar====
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:


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.
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/notification1.png
 
 
This method can be styled as appropriate for varying severity of messages:
 
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/notification2.png
 
 
Here, shown borrowing from [http://azarask.in/blog/post/firefox-geolocation-js-library/ Aza's great suggested geolocation prompt UI]:
 
http://people.mozilla.com/~madhava/files/mobile/2008-06-26/notification3-geolocation.png
 
 
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?)
 
http://people.mozilla.com/~madhava/files/mobile/2008-07-07/save_file.png
 
 
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."
 
http://people.mozilla.com/~madhava/files/mobile/2008-07-07/progress.png
 
 
Eventually, a user gets notified that the download is complete:
 
http://people.mozilla.com/~madhava/files/mobile/2008-07-07/download_complete.png
 
 
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:
 
http://people.mozilla.com/~madhava/files/mobile/2008-07-07/dismiss_notification.png
 
 
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).
 
http://people.mozilla.com/~madhava/files/mobile/2008-07-07/control.png


http://people.mozilla.com/~madhava/files/mobile/2008-06-04/notification_concept1.png
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===
===Add-ons===
Draft:  https://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI/add-ons_concepts (WIP)


===Actions===
===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 ===
http://people.mozilla.com/~madhava/files/mobile/2008-11-18/site_button.png
==== Authentication ====
===== Client Certificates =====
http://people.mozilla.com/~madhava/files/mobile/2008-11-18/certificate.png
===== Username/Password=====
http://people.mozilla.com/~madhava/files/mobile/2008-11-18/userpass.png
===Preferences===
http://people.mozilla.com/~madhava/files/mobile/2008-08-28/prefs1.png
'''note''': there's a bit more off the end of this next mockup -->
http://people.mozilla.com/~madhava/files/mobile/2008-08-28/prefs2.png
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)
Madhava
Confirmed users
1,492

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/96629...120444"