Last Comment Bug 503889 - Investigate usable sizes and target areas for touch interactions
: Investigate usable sizes and target areas for touch interactions
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Theme (show other bugs)
: Trunk
: x86 Windows 7
-- normal (vote)
: Firefox 3.6b1
Assigned To: :Felipe Gomes (needinfo me!)
:
: Dão Gottwald [:dao]
Mentors:
Depends on: 503042 503541
Blocks: 548100
  Show dependency treegraph
 
Reported: 2009-07-13 10:34 PDT by :Felipe Gomes (needinfo me!)
Modified: 2010-02-23 14:01 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Main browser area - rev1 (7.62 KB, patch)
2009-07-16 14:28 PDT, :Felipe Gomes (needinfo me!)
no flags Details | Diff | Splinter Review
Main browser area - rev2 (6.91 KB, patch)
2009-07-17 15:20 PDT, :Felipe Gomes (needinfo me!)
no flags Details | Diff | Splinter Review
Main browser area - rev3 (5.34 KB, patch)
2009-07-22 16:03 PDT, :Felipe Gomes (needinfo me!)
no flags Details | Diff | Splinter Review
Main browser area - rev4 (5.92 KB, patch)
2009-07-23 01:07 PDT, :Felipe Gomes (needinfo me!)
no flags Details | Diff | Splinter Review
Main browser area - rev5 (5.76 KB, patch)
2009-07-24 10:33 PDT, :Felipe Gomes (needinfo me!)
dao+bmo: review+
Details | Diff | Splinter Review
Main browser area - rev6 (5.31 KB, patch)
2009-07-24 13:48 PDT, :Felipe Gomes (needinfo me!)
felipc: review+
Details | Diff | Splinter Review

Description User image :Felipe Gomes (needinfo me!) 2009-07-13 10:34:58 PDT
This bug is to track the testing I've been doing on using the Firefox UI with a touch device, and where the sizes/positioning of the elements makes it extra-hard to work.
Comment 1 User image :Felipe Gomes (needinfo me!) 2009-07-16 14:23:43 PDT
Boriss suggested me an improvement for the menu interaction as being able to only tap once and then dragging down to open the menu and releasing the finger on the item chosen. This already works if done by the mouse (click and hold), so this will come as a nice gift from bug 503541.
Comment 2 User image :Felipe Gomes (needinfo me!) 2009-07-16 14:28:06 PDT
Created attachment 389003 [details] [diff] [review]
Main browser area - rev1

These are some changes as per investigation of the main browser area (toolbar, menubar, tab strip). All the changes don't modify the current CSS, just add some more using the new :-moz-system-metric selector for touch-enabled, so the changes are non-destructive and have no impact at all on the regular theme.

Here is a run down of each change and an argument for each of them:

menu drag down

* back/forward controls:
  - pushed +8px from the window edge (from 2px to 10px), makes clicking on the back button very comfortable
  
* awesomebar:
  - drop-marker is too tiny, increasing width from 16px to 24px
  - adding 1px margin between elements helps to avoid wrong taps
  - increasing padding-left and padding-right to 3px increases hit area

* searchbar
  - splitter +2px wide makes it slightly better (its not bad as it is now)
  - pushing +2px from window edge
  - making the Search button more wide via bigger padding to increase hit area
  
* tab strip
  - -1px on margin-tops on everything with no visual difference
  - new tab, all tabs and scrollup/down tabs buttons with width and padding enlarged (they are chalenging to click sometimes for  being on the edges)
  - new tab button: extra width
  - close button: wider and higher, it was one of the trickiest to tap. I'd say it works reasonably well with this patch.
Comment 3 User image :Felipe Gomes (needinfo me!) 2009-07-16 14:35:00 PDT
And some observations of other areas analyzed that didn't receive changes

* back/forward controls
  - drop-marker is actually a target with enough size, but its inset appearance gives the illusion of being very hard to hit.
  
* awesomebar
  - larry is clickable, not _so_  awesomely clickable but not changing it yet

* search bar
  - search bar engine button is very good as is
  
* menubar
  - works good as it is (height = 19px), although it appears as a little short.

* tab strip
  - there is still room for improvement if we could get the 2px of space between the toolbar and the tab strip to be part of the hit area.. but it doesn't look possible because they are margins, and changing to paddings change the appearance
  - not sure but it seems that it still possible to get a few more pixels of height in the close button, changing some paddings to heights. I'll investigate it.
Comment 4 User image Alex Faaborg [:faaborg] (Firefox UX) 2009-07-17 00:10:11 PDT
We should probably file a follow up bug to attempt to find out the physical size of the screen. This information in conjunction with the actual resolution and data on the average human finger size would enable us to make sure that targets are always easily touchable.
Comment 5 User image :Felipe Gomes (needinfo me!) 2009-07-17 15:20:35 PDT
Created attachment 389212 [details] [diff] [review]
Main browser area - rev2

Hey Dao, could you take a look at this patch? It makes some small changes on the UI which applies only for touch-enabled devices to increase the sizes and hit areas of some of the main UI elements. I've ran all these changes by Alex, and the changes in this patch are listed in comment #2, except from the back-forward button which is no longer changed because it didn't look so good.

Note that to actually see the changes you'd need the patch from bug 503042 applied which implements the :-moz-system-metric(touch-enabled) pseudo-selector.
Comment 6 User image Dão Gottwald [:dao] 2009-07-17 18:05:45 PDT
Comment on attachment 389212 [details] [diff] [review]
Main browser area - rev2

>+.urlbar-icon:-moz-system-metric(touch-enabled) {
>+  -moz-margin-end: 1px !important;
>+  padding: 0 3px !important;
>+}

Instead of styling all the icons individually in the non-touch-enabled case, we should make use of .urlbar-icon there as well. Would you mind fixing this here?

>+.tabbrowser-tab:-moz-system-metric(touch-enabled) {
>+  margin-top: 2px;
>+}

>+.tabbrowser-tab:not([selected="true"]):hover:-moz-system-metric(touch-enabled) {
>+  margin-top: 1px;
>+}

>+.tabbrowser-tab[selected="true"]:-moz-system-metric(touch-enabled) {
>+  margin-top: 1px;
>+}

I dislike this, as it will be hairy to maintain. What exactly are you trying to achieve?

>+.tab-close-button:-moz-system-metric(touch-enabled) {
>+  -moz-margin-end: 3px;
>+  height: 19px;
>+  padding: 0 5px;
>+}

I don't think we should make the close button bigger without adjusting the icon accordingly.
Comment 7 User image Dão Gottwald [:dao] 2009-07-19 05:14:07 PDT
Comment on attachment 389212 [details] [diff] [review]
Main browser area - rev2

> #urlbar-search-splitter {
>   min-width: 8px;
>   -moz-margin-start: -4px;
>   border: none;
>   background: transparent;
> }
> 
>+#urlbar-search-splitter:-moz-system-metric(touch-enabled) {
>+  min-width: 10px;
>+}

Do the extra 2px really make a difference in terms of making it a usable target for touch interactions?
Comment 8 User image :Felipe Gomes (needinfo me!) 2009-07-20 11:52:49 PDT
(In reply to comment #6)
> (From update of attachment 389212 [details] [diff] [review])
> >+.urlbar-icon:-moz-system-metric(touch-enabled) {
> >+  -moz-margin-end: 1px !important;
> >+  padding: 0 3px !important;
> >+}
> 
> Instead of styling all the icons individually in the non-touch-enabled case, we
> should make use of .urlbar-icon there as well. Would you mind fixing this here?

I didn't quite understand what you suggest here. Do you mean .urlbar-icons instead of .urlbar-icon

> 
> >+.tabbrowser-tab:-moz-system-metric(touch-enabled) {
> >+  margin-top: 2px;
> >+}
> 
> >+.tabbrowser-tab:not([selected="true"]):hover:-moz-system-metric(touch-enabled) {
> >+  margin-top: 1px;
> >+}
> 
> >+.tabbrowser-tab[selected="true"]:-moz-system-metric(touch-enabled) {
> >+  margin-top: 1px;
> >+}
> 
> I dislike this, as it will be hairy to maintain. What exactly are you trying to
> achieve?

I tried to to squeeze 1 extra pixel in the height of the tabs in the "more pixels, the better" approach, but the +1px probably won't be worth it if it will be a problem to maintain later.

> >+.tab-close-button:-moz-system-metric(touch-enabled) {
> >+  -moz-margin-end: 3px;
> >+  height: 19px;
> >+  padding: 0 5px;
> >+}
> 
> I don't think we should make the close button bigger without adjusting the icon
> accordingly.

The idea was to expand the hit area of the close button without visually changing it, so the user can touch nearby it and the click still computes, since the close button is currently too tiny.

(In reply to comment #7)
> Do the extra 2px really make a difference in terms of making it a usable target
> for touch interactions?

I tested for a while and it seemed to make some difference, but I'll do some qualitative analysis. Since we have physical units in inches or centimeters, I'll follow Faaborg suggestion and see how the sizes compare to the human finger in the typical notebook screen DPI, following a usability guideline that madhava pointed me to. (https://help.ubuntu.com/community/UMEGuide/DesigningForFingerUIs)
Comment 9 User image Dão Gottwald [:dao] 2009-07-20 12:03:35 PDT
(In reply to comment #8)
> > Instead of styling all the icons individually in the non-touch-enabled case, we
> > should make use of .urlbar-icon there as well. Would you mind fixing this here?
> 
> I didn't quite understand what you suggest here. Do you mean .urlbar-icons
> instead of .urlbar-icon

Right, I meant urlbar-icons.

> I tried to to squeeze 1 extra pixel in the height of the tabs in the "more
> pixels, the better" approach, but the +1px probably won't be worth it if it
> will be a problem to maintain later.

There's probably a better way to do that, I'll test something.

> The idea was to expand the hit area of the close button without visually
> changing it, so the user can touch nearby it and the click still computes,
> since the close button is currently too tiny.

I understand, but the user might as well try to hit the tab. A invisible hit area for a close button doesn't seem wise.
Comment 10 User image Dão Gottwald [:dao] 2009-07-20 12:12:10 PDT
> > I tried to to squeeze 1 extra pixel in the height of the tabs in the "more
> > pixels, the better" approach, but the +1px probably won't be worth it if it
> > will be a problem to maintain later.
> 
> There's probably a better way to do that, I'll test something.

So just setting a (physical?) min-height on .tabbrowser-tabs will do the trick, I think.

Regarding the close button, how about using something like -moz-transform: scale(1.25)?
Comment 11 User image Alex Faaborg [:faaborg] (Firefox UX) 2009-07-20 21:49:19 PDT
>I understand, but the user might as well try to hit the tab. A invisible hit
>area for a close button doesn't seem wise.

This seemed to work reasonably well when using the device in that your finger ends up covering so much of the area that you can't really tell if you are exactly hitting the close button or not.  Overall I agree that we should probably try to get the visual size and target size to match we we work on new icons.  In the meantime I think the change is important because otherwise hitting the close button with your finger is actually really difficult.
Comment 12 User image :Felipe Gomes (needinfo me!) 2009-07-22 16:03:49 PDT
Created attachment 390103 [details] [diff] [review]
Main browser area - rev3

Here is a better patch, using physical dimensions wherever possible.

Regarding the splitter between the awesomebar and searchbar, I removed the change, because there weren't any reasonable value to put there and make a real difference in usability without making them too far apart which was just ugly. The use case of resizing that is probably only ever once or twice so it shouldn't be a problem.

> So just setting a (physical?) min-height on .tabbrowser-tabs will do the trick, I think.

Done, using a physical value .32in, which translates to 31px in a traditional 96dpi screen.

> Regarding the close button, how about using something like -moz-transform:
scale(1.25)?

Did that and I liked the result. Although the icon rendering doesn't look so great. I'll show this to Alex later and see what he thinks is the best. 

> Right, I meant urlbar-icons

I tried using #urlbar-icons but I want to increase the spacing between each icon, so it didn't do the trick.  Did you think of something like #urlbar-icons > * ?    I'm keeping .urlbar-icon for now because I think it's less intrusive.

Let me know what you think
Comment 13 User image Alex Faaborg [:faaborg] (Firefox UX) 2009-07-22 18:56:05 PDT
>Done, using a physical value .32in, which translates to 31px in a traditional
>96dpi screen.

Madhava: do you have an statistics on the average human finger width?  I remember hearing some figures on this during a presentation of touch screen interface design, but I can't remember what the exact values (or original sources) were.
Comment 14 User image :Felipe Gomes (needinfo me!) 2009-07-22 19:08:45 PDT
Faaborg: I asked Madhava about this on IRC, here is the link: https://help.ubuntu.com/community/UMEGuide/DesigningForFingerUIs

This link says the average human finger is about .4in and the info source is a research paper from MIT.

With this changes the new tab button end up with .32in x .4in, which seemed pretty reasonable on my testing.
Comment 15 User image Dão Gottwald [:dao] 2009-07-22 23:14:59 PDT
(In reply to comment #12)
> Created an attachment (id=390103) [details]
> Main browser area - rev3
> 
> Here is a better patch, using physical dimensions wherever possible.

Could you please use metric units? :)

> > Regarding the close button, how about using something like -moz-transform:
> scale(1.25)?
> 
> Did that and I liked the result. Although the icon rendering doesn't look so
> great. I'll show this to Alex later and see what he thinks is the best.

The rendering would probably look better with 1.25.

> > Right, I meant urlbar-icons

Sorry, I did mean .urlbar-icon. Simplified:

> #feed-button {
>   padding: 0 2px !important;
> }
> #star-button {
>   padding: 0 2px;
> }
> #go-button {
>   padding: 0 2px;
> }
> .urlbar-icon:-moz-system-metric(touch-enabled) {
>   padding: 0 3px !important;
> }

Should be this instead:

> .urlbar-icon {
>   padding: 0 2px !important;
> }
> .urlbar-icon:-moz-system-metric(touch-enabled) {
>   padding: 0 3px !important;
> }
Comment 16 User image Dão Gottwald [:dao] 2009-07-22 23:17:40 PDT
Comment on attachment 390103 [details] [diff] [review]
Main browser area - rev3

>+.search-go-button:-moz-system-metric(touch-enabled) {
>+  padding: 0 3px 0 5px;
>+}

this should use -moz-padding-start and -moz-padding-end
Comment 17 User image Alex Faaborg [:faaborg] (Firefox UX) 2009-07-22 23:18:53 PDT
>Could you please use metric units? :)

it doesn't get more English system then "1 finger width" :)
Comment 18 User image :Felipe Gomes (needinfo me!) 2009-07-23 01:07:36 PDT
Created attachment 390171 [details] [diff] [review]
Main browser area - rev4

(In reply to comment #15)
> Could you please use metric units? :)

Sure :)

> The rendering would probably look better with 1.25.

I tried both and none looked particularly different, so I just used the bigger one

> Sorry, I did mean .urlbar-icon. Simplified:
> Should be this instead:
> 
> > .urlbar-icon {
> >   padding: 0 2px !important;
> > }
> > .urlbar-icon:-moz-system-metric(touch-enabled) {
> >   padding: 0 3px !important;
> > }

Ah Ok, I see what you mean now. You suggested fixing the original code since it was using specific CSS for each icon. Sorry for the confusion :) Done now.

(In reply to comment #16)
> >+.search-go-button:-moz-system-metric(touch-enabled) {
> >+  padding: 0 3px 0 5px;
> >+}
> 
> this should use -moz-padding-start and -moz-padding-end

Done as well.
Comment 19 User image Dão Gottwald [:dao] 2009-07-23 02:19:18 PDT
(In reply to comment #18)
> > The rendering would probably look better with 1.25.
> 
> I tried both and none looked particularly different, so I just used the bigger
> one

I tried 1.2 originally, and I thought 1.25 looked better, but there doesn't seem to be such a difference between 1.25 and 1.3 indeed.
Comment 20 User image Dão Gottwald [:dao] 2009-07-23 02:20:57 PDT
Comment on attachment 390171 [details] [diff] [review]
Main browser area - rev4

> .search-go-button {
>   padding: 2px;
>   list-style-image: url("chrome://global/skin/icons/Search-glass.png");
>   -moz-image-region: rect(0px 16px 16px 0px);
> }
> 
>+.search-go-button:-moz-system-metric(touch-enabled) {
>+  padding: 0;
>+  -moz-padding-start: 5px;
>+  -moz-padding-end: 3px;
>+}

Why are you reducing the vertical padding?
Comment 21 User image Dão Gottwald [:dao] 2009-07-23 02:49:29 PDT
Comment on attachment 390171 [details] [diff] [review]
Main browser area - rev4

>   border-bottom: none;
>   -moz-border-radius-topleft: 2px;
>   -moz-border-radius-topright: 2px;
>   -moz-border-top-colors: ThreeDShadow rgba(255,255,255,.3);
>   -moz-border-right-colors: rgba(0,0,0,.1);
>   -moz-border-left-colors: ThreeDShadow rgba(255,255,255,.3);
> }
> 
>+.tabbrowser-tabs:-moz-system-metric(touch-enabled) {
>+  min-height: .81cm;
>+}

This seems to be in an odd position. Please move it up to the other .tabbrowser-tabs rule.
Comment 22 User image :Felipe Gomes (needinfo me!) 2009-07-23 02:51:56 PDT
(In reply to comment #20) 
> Why are you reducing the vertical padding?

Oops my mistake. I was originally reducing margins elsewhere and didn't realize that was a padding. That line shouldn't exist.
Comment 23 User image Dão Gottwald [:dao] 2009-07-24 00:14:01 PDT
Felipe, can you please fix that along with comment 21 in a new patch?
Comment 24 User image :Felipe Gomes (needinfo me!) 2009-07-24 10:33:02 PDT
Created attachment 390499 [details] [diff] [review]
Main browser area - rev5

Sure! I wasn't sure if I should post a new patch or not. Here it is, addressing comment 21 and comment 22.
Comment 25 User image Dão Gottwald [:dao] 2009-07-24 11:02:12 PDT
Comment on attachment 390499 [details] [diff] [review]
Main browser area - rev5

> .tabbrowser-arrowscrollbox > .tabs-newtab-button {
>   width: 31px;
>   -moz-border-radius-topright: 2px;
>   -moz-border-radius-topleft: 2px;
> }
> 
>+.tabs-newtab-button:-moz-system-metric(touch-enabled) {
>+  width: 1cm;
>+}

You've already defined a width for .tabs-newtab-button before. Did you mean .tabbrowser-arrowscrollbox > .tabs-newtab-button here?

I haven't tested it, but you should probably use min-width everywhere you used width.
Comment 26 User image :Felipe Gomes (needinfo me!) 2009-07-24 13:48:44 PDT
Created attachment 390534 [details] [diff] [review]
Main browser area - rev6

Carrying forward dao's r+

> You've already defined a width for .tabs-newtab-button before. Did you mean
> .tabbrowser-arrowscrollbox > .tabs-newtab-button here?

No, I had kept the tabs-newtab-button previous definition just so the selector was the same as the non-touch-enabled case right above it. But now I moved this one closer as well and remove the redundancy.
I didn't use the  | .tabbrowser-arrowscrollbox > |  selector because I wanted this to match after the newtab button is repositioned on the rightmost side as well.

> 
> I haven't tested it, but you should probably use min-width everywhere you used
> width.

Tested it with both, all worked ok, so I'll keep min-width per your suggestion.
Comment 27 User image Robert Strong [:rstrong] (use needinfo to contact me) 2009-08-10 20:03:40 PDT
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/61e4d2ca4e3e

Note You need to log in before you can comment on or make changes to this bug.