FirefoxMobile-SmartTabs: Difference between revisions

From Medien Wiki
No edit summary
No edit summary
Line 66: Line 66:
*Contra: Takes valuable screen real estate.
*Contra: Takes valuable screen real estate.


===Preview pages while finger down, open when up===
===Preview pages while finger down, open when up (deferred)===
*Pro: Very fast preview, since one could just go over many tabs in one move. Even very shortly displayed content is recognized (siehe: Processing Speed In Cerebral Cortext– Rolls Tovee – 94) It could be triggered with long-tap too: It would trigger a kind of preview overlay and moving to another tab while down whould trigger its preview to occur than.
*Pro: Very fast preview, since one could just go over many tabs in one move. Even very shortly displayed content is recognized (siehe: Processing Speed In Cerebral Cortext– Rolls Tovee – 94) It could be triggered with long-tap too: It would trigger a kind of preview overlay and moving to another tab while down whould trigger its preview to occur than.


*Contra: Could get in the way of future attempts to make tab-resorting possible. (not applying to long-tab-triggering or a drag in one of the modes in vertical direction first) May confuse users (?)  
*Contra: Could get in the way of future attempts to make tab-resorting possible. (not applying to long-tab-triggering or a drag in one of the modes in vertical direction first) May confuse users (?)  
*'''Prototyping results''': It works not faster than tapping the pages. This is due to the fact that one can distinguish no more than ~10 tabs (more are unlikely on a mobile device) usually easily. If not, the amount of tabs will be low enough to invoke them by tapping.
But try for yourself: [[File:SmartTabsRapidViewing.swf‎]]
I think that this approach is not bad but it will start to perform good with greater item quantities.


==Wireframes==
==Wireframes==

Revision as of 14:54, 2 May 2010

Smart Tabs for Mozilla Mobile

Project by Jan Dittrich

"How can the way we make the tabs better representing the pages?"
Goals: make tabs better representing the pages.
No-Goals: Change the general model of interaction with tabs, Use signficant more screen real estate.

Current Situation

MozillaMobile 1-1 Tabs.png

MozillaMobile TabClosingActiveAreaHas57pxWidth.png

Functions: Tapping on non-framed part of the image makes the respective page appear. Tapping on the area enclosed by the red frame causes the tab to close. This area has currently (1.1 alpha) a width of 57px which makes e.g. 6mm on a N800 or 9mm on an iPhone (on which FF Mobile not runs!).


Ideas for Improvement

Make Closing Botton Less Obstrusive

Relocate Button Wireframe

Make Button Smaller

  • Pro: Less space is taken from the image. Button is close to screen edge
  • Contra:
    • Relevant part of the image not entirely free.
    • The Button is harder to see.

Move button to the right edge

  • Pro: The more relevant left edge is free.
  • Contra:
    • The left side is closer to the edge which means the area can be touched easier since one does not care about tapping a close object on the left side.
    • When dragging the Bar in, one sees just the Buttons at first.



MozillaMobile pageCrop.png

Smarter Page Crop

Concept: ???

  • Pro: Choosing a more representative part of the page means better recognition and more differenciation between similar pages.
  • Contra: ---


MozillaMobile addFavicon.png

Adding Favicon

  • Pro: Visual grouping of same Domain-Pages. Recognize logos of commonly used webpages.
  • Contra: Could be mistaken for a button if not carefully integrated.

Note:It is likely that the favicon itself is hard to recall for non-frequently used pages. But it often gives color clues for the page. (Further research is needed)

Better rendering quality

MozillaMobile betterTabImageRendering.png
  • Pro: A better rendering of the tabs will improve the recognition.
  • Contra: Performance issues. Could possibly be solved by rendering low-Fi first and when e.g. the user reads the page, the hi-fi Tabs are renderend.

Retrive closed Tabs easier

  • Pro: Provide a button or overlay-button for retreiving an accidentally closed Tab.
  • Contra: Takes valuable screen real estate.

Preview pages while finger down, open when up (deferred)

  • Pro: Very fast preview, since one could just go over many tabs in one move. Even very shortly displayed content is recognized (siehe: Processing Speed In Cerebral Cortext– Rolls Tovee – 94) It could be triggered with long-tap too: It would trigger a kind of preview overlay and moving to another tab while down whould trigger its preview to occur than.
  • Contra: Could get in the way of future attempts to make tab-resorting possible. (not applying to long-tab-triggering or a drag in one of the modes in vertical direction first) May confuse users (?)
  • Prototyping results: It works not faster than tapping the pages. This is due to the fact that one can distinguish no more than ~10 tabs (more are unlikely on a mobile device) usually easily. If not, the amount of tabs will be low enough to invoke them by tapping.

But try for yourself: File:SmartTabsRapidViewing.swf

I think that this approach is not bad but it will start to perform good with greater item quantities.

Wireframes

Study 1: What do people recall about webpages

Conducted by Bastian Bügler and Jan Dittrich

Goal

...is to find out what people can recall about websites they visited previously (about 2-10 Minutes ago)

Methods

Participants had do do simple tasks on several webpages. After a masking time of a couple of minutes filled with other tasks, they had to tell about the features that they link with the webpages.

Results