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

← Older edit

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

Revision as of 22:58, 11 December 2008

4,941 bytes added , 11 December 2008

no edit summary

Madhava

Confirmed users

1,492

edits

@@ Line 38: / Line 38: @@
 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.
+. 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.
+. 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
+. Overlays - as in Android, where +/- controls show up over content.  This has the disadvantage of only controlling zoom level, not location.
+. 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 ===
@@ Line 100: / Line 149: @@
 ===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]]
@@ Line 163: / Line 224: @@
 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===
@@ Line 173: / Line 249: @@
 Also see:  http://madhava.com/egotism/archive/005024.html
+===Context-sensitive Menus (CSM)===
+See here [[Mobile/UI/Designs/TouchScreen/workingUI/CSM]] (work in progress)
@@ Line 178: / Line 259: @@
 Working here:  [[Mobile/UI/Designs/TouchScreen/workingUI/desktop_integration]]
 ==Working Mockups - small-format screen (e.g. windows mobile)==
-* [[Mobile/UI/Designs/TouchScreen/workingUI/small-format]]
+Working here: [[Mobile/UI/Designs/TouchScreen/workingUI/small-format]]