Closed Bug 821673 Opened 7 years ago Closed 6 years ago

Redesign back, menu and close buttons

Categories

(Firefox OS Graveyard :: Gaia, defect)

defect
Not set

Tracking

(blocking-b2g:koi+, blocking-basecamp:-, b2g-v1.2 verified)

VERIFIED FIXED
blocking-b2g koi+
blocking-basecamp -
Tracking Status
b2g-v1.2 --- verified

People

(Reporter: Nukeador, Assigned: arnau)

References

Details

(Whiteboard: ux-tracking, ux-priority1.2)

Attachments

(7 files, 1 obsolete file)

Attached image Wifi settings
Hi,

From my point of view the back/close and other top left side button are extremely narrow and I guess some people with big fingers will have problems clicking just on their area.

Also is inconsistent with for example the + or wheel buttons on Contact app, where the images have a lot more space on the sides.
Attached image Contacts app
Ping, any feedback on this?

Willy, do you know who is charge of reviewing this kind of bugs?
Flags: needinfo?
blocking-basecamp: --- → ?
blocking-basecamp: ? → -
Keywords: polish
I'm having bad times trying to test my changes on b2g-desktop, but just a few work should be done in headers.css. The problem is that it seems edit_mode.css and building_blocks.css have also duplicate information about buttons on headers that other apps use like calendar or settings (is this intended or a bug?).

For example, headers.css changes would be something like this increasing a bit the width and margin:

diff --git a/shared/style/headers.css b/shared/style/headers.css
index 72af154..cb0c46c 100644
--- a/shared/style/headers.css
+++ b/shared/style/headers.css
@@ -32,7 +32,7 @@ section[role="region"] > header:first-child h1 {
   text-overflow: ellipsis;
   display: block;
   overflow: hidden;
-  margin: 0 0 0 3rem;
+  margin: 0 0 0 4rem;
   height: 100%
 }
 
@@ -45,7 +45,7 @@ section[role="region"] > header:first-child form {
   overflow: hidden;
   position: relative;
   padding: 1rem 1rem 0 0.5rem ;
-  margin-left: 2.5rem;
+  margin-left: 3.5rem;
 }
 
 section[role="region"] > header:first-child input[type="text"] {
@@ -221,7 +221,7 @@ section[role="region"] > header:first-child > a {
   left: 0;
   width: 5rem;
   height: 5rem;
-  background: url(headers/images/ui/separator-large.png) no-repeat 2rem center;
+  background: url(headers/images/ui/separator-large.png) no-repeat 3rem center;
   overflow: hidden;
 }
 
@@ -234,7 +234,7 @@ section[role="region"] > header:first-child > button .icon,
 section[role="region"] > header:first-child > a .icon {
   position: static;
   display: block;
-  width: 2rem;
+  width: 3rem;
   height: 4.9rem;
   margin: 0;
   overflow: visible;
@@ -248,7 +248,7 @@ section[role="region"] > header:first-child > a .icon:after {
   left: 0;
   top: 0;
   z-index: -1;
-  width: 2rem;
+  width: 3rem;
   height: 4.9rem;
   background: #9d3d26 url(headers/images/ui/negative.png) repeat-x 0 0;
 }
Flags: needinfo?
Doogfooding the device, I've noticed that most people (myself included) tend to tap on the very left border of the screen to try to hit the tiny button. 

Very usually you have to tap 3 times to get it.
Flags: needinfo?(jcarpenter)
Strongly agree :) We'll be revisiting this in future versions, but for 1.0.1 and 1.1 the decision is probably fixed. cc'ing Visual so we remind ourselves to fix this in the next release.
Flags: needinfo?(jcarpenter) → needinfo?(padamczyk)
Renaming bug for clarity.
Keywords: polish
Summary: Top left side icons are too narrow → Redesign back buttons
Whiteboard: u=user c=system s=ux-most-wanted, interaction
Ruben, that to me sounds like a touch target issue. Is this a regression or the bug fix hasn't made it into the release you're testing?
Flags: needinfo?(padamczyk)
This is not just a problem with tapping, it's mainly a visual one.

The button is completely different in size than others (see my attachment on comment #1 and #2) feels wrong and sometimes complicated to tap.

I've seen this problem in every Firefox OS build I've tested since the gaia redesign and in different devices (otoro, unagi, keon...) which all have a very small screen.

The funny thing is that the anchor element is wider than the button, specifically as wider as the button should be to feels right and consistent ;)
Whiteboard: u=user c=system s=ux-most-wanted, interaction → ux-tracking
Whiteboard: ux-tracking → ux-tracking, ux-priority1.2
Note: this bug will become the meta bug for implementing new back, menu and close buttons.
Summary: Redesign back buttons → Redesign back, menu and close buttons
Depends on: 904567
Depends on: 904570
Depends on: 904573
Depends on: 904578
Depends on: 904580
Depends on: 904581
Depends on: 904583
Depends on: 904587
Depends on: 904595
Depends on: 904596
Depends on: 904597
IMHO we should be really careful when we redesign the back button. It's not just about making the button visually bigger. All the content is left aligned with the header title, if we make the button wider, we will need to move the title and the layout of all apps containing a header may look a little bit weird. Furthermore, having the header title left aligned, and not centered, is a distinctive visual design decission we made on purpose which differentiates FxOS from all other major mobile operating systems, so we'd like to keep something from that.

That said, i totally agree with you the back button is too small and doesn't work te way it is designed. My concern was more about this is not an "assets" issue, but a visual redesign in order to keep the visual language o the system while improving the affordance of the back button.
Yes, what Sergi is commenting is just what we have talked among the visual design team. When we first proposed the left alignment of the title, all the content was laid out to reinforce the editorial style we mean to have with the structure and the plainness of the visual language. 

One important thing to understand regarding the buttons, is that the left (back, close and drawer buttons) are very different items, they have navigational purposes and sit alone, while the ones placed in the right hand side of the header can be two and are action icons. So they are meant to look different.

With that said, I understand that the narrowness of the back button is an issue to solve, but I don't think it is a matter of making it as big as the ones in the right of the header. I disagree on just having the header centered. 

I am working on a solution to this issue trying not to throw all the layout and style proposed so far where the header is a strong characteristic.
Just adding some additional notes of the work that is being done by UX on this particular issue:

- We are exploring options for larger back-button designs with the visual design team.   
- Made some quick changes here: https://github.com/caseyyee/gaia/tree/bug-821673
to test the usability of these changes and evaluate technically how much effort is going to be required for some of the proposed designs.
Just a reminder, 1.2 is almost done. Given how much people complain about the current back buttons, I think a not-so-perfect solution in 1.2 is better than nothing in 1.2 because we're waiting on a perfect implementation.

Can we try to expand the visible size of the button without moving the title?
Attached image Current button
Attached image With simple patch
Here's my try on this. I removed the separator and expanded the visible area to 26 pixels (a 30% increase! ;) ).

You can see the changes for this quick test in https://github.com/Rik/gaia/tree/proposition-back-button-821673.

Would that be ok?
Hi everyone,
Attached is the visual design direction for the improved and larger back-button design.

The visual design only differs slightly from what we have already with a few notable changes:
- No background shading on button.
- Drawer icon is no longer cut-off.
- Revised alignment and margins (to accommodate larger button)

Besides this, the hit target sizing will remain the same (at 50px).

Flagging visual design to provide final assets for:
- Back ( < ), Close ( X ), Drawer icons.
- Light (orange) and dark (gray) coloration.
- Active hit-state (blue) of each button.
Flags: needinfo?(vpg)
Attached image backbutton-option2.jpg
Visual design as per comment #16
Hi Casey, 
Based on this final decision around the header, we only need the drawer icon asset. The rest are the same we already have with different position. This is mainly a layout change in the Headers Building Block, so I am asking Arnau to implement it, I will supervise the layout.
Flags: needinfo?(vpg) → needinfo?(arnau)
Assignee: nobody → arnau
Flags: needinfo?(arnau)
Thanks Victoria, I figured that.
Attached patch patch in github (obsolete) — Splinter Review
Attachment #797790 - Flags: review?(igonzaleznicolas)
Attached file patch in github
Attachment #797790 - Attachment is obsolete: true
Attachment #797790 - Flags: review?(igonzaleznicolas)
Attachment #797791 - Flags: review?(igonzaleznicolas)
Comment on attachment 797791 [details]
patch in github

Everything seems right to me, my only concern is about the tricky extra "touchable area" that we added in the previous version to fix the usability issue.
Now we have a formal approach to fix this issue, is really needed to keep a transparent touch area from the right edge of the back button to the first letter of the header title?
Just asking. Anyway everything seems r+ to me.
Attachment #797791 - Flags: feedback?(vpg)
Attachment #797791 - Flags: review?(igonzaleznicolas) → review+
Isma, unfortunately our minimum touch area is 50px, we could only fix the absolute position trick for the button if the left margin in the Title was at least 50px, in the current design is 40px :(
Attached image patches.png
Screenshots of the initial patch, and adding Patryk's feedback: When there is no left button, we keep current left alignment (30px), so header is still aligned with the rest of the content.
Flags: needinfo?(padamczyk)
Comment on attachment 804481 [details]
patches.png

Looks good to me.  I would double check that we don't ellipse text anywhere that is not expected.
(In reply to Ismael Gonzalez [:basiclines] from comment #22)
> Comment on attachment 797791 [details]
> patch in github
> 
> Everything seems right to me, my only concern is about the tricky extra
> "touchable area" that we added in the previous version to fix the usability
> issue.

Because the actual button is still smaller than the touch area (50px), I think we should maintain the larger touchable area.
Looks good to me. If you need any graphics support Eric or Victoria should be able to execute that request
Flags: needinfo?(padamczyk)
We have an issue with this design implementation. This PR is coded to show the header's title 30px left, if there is no left button and 40px if we have it. The thing is some apps have the button, but is hidden and it's only shown when needed. Any idea how to solve that?
Flags: needinfo?(igonzaleznicolas)
I think it would be nice to keep it, even though we already expanded it visually, having a greater hit area would make the experience better.

 (In reply to Ismael Gonzalez [:basiclines] from comment #22)
> Comment on attachment 797791 [details]
> patch in github
> 
> Everything seems right to me, my only concern is about the tricky extra
> "touchable area" that we added in the previous version to fix the usability
> issue.
> Now we have a formal approach to fix this issue, is really needed to keep a
> transparent touch area from the right edge of the back button to the first
> letter of the header title?
> Just asking. Anyway everything seems r+ to me.
(In reply to Arnau March from comment #28)
> We have an issue with this design implementation. This PR is coded to show
> the header's title 30px left, if there is no left button and 40px if we have
> it. The thing is some apps have the button, but is hidden and it's only
> shown when needed. Any idea how to solve that?

We should unify these sizes in order to achieve a consitent implementation as we can't control different ways to hide that buttons.
Also it will work better with in-content components that will be aligned always to the same edge margin.
Flags: needinfo?(igonzaleznicolas)
Thanks for your feedback Isma, I think we now have a more stable header, getting rid of absolute positioning in elements.
Duplicate of this bug: 913357
Merged: f576c1289c2fe78cebaafd12f22cc26edcd23f3e
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Duplicate of this bug: 908113
Asking for koi+ since this is one of the most reported problem from users.
blocking-b2g: --- → koi?
Duplicate of this bug: 908114
Duplicate of this bug: 907044
The number of duplicates adds some weight to the nomination request in comment 35. We'll need good QA though :)
Spoke with :rik offline on the risk of the patch and he said this is low enough and has baked on central. Given the dup's and user feedback and keeping in mind this is ready lets land this on 1.2.

Requesting QA to verify this bug especially trying the menu's,back button's on popular application's to see if anything was broken.

In addition this could easily be backed out if the regressions are worse and this patch does not benefit.
blocking-b2g: koi? → koi+
Keywords: verifyme
Uplifted f576c1289c2fe78cebaafd12f22cc26edcd23f3e to:
v1.2: 762f6f806e255045731871cb1703678f9ce55fc9
Verified fixed.

Have tested new resized buttons (back, close and drawer) throughout all the apps they are in – Messages, Contacts, Settings, Calendar, Email, Music, Video, Dialer, Usage, Clock – looks like a very good improvement, no broken functionalities, easier to tap, cleaner and nicer look, no ellipses in the headers, no issues to report so far!

Build ID: 20131002004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/b955a00f4167
Gaia: def8e152db6a317162c03a316f68c409f3af3979
Platform Version: 26.0a2

Build ID: 20131002040206
Gecko: http://hg.mozilla.org/mozilla-central/rev/e3c84e9f2490
Gaia: 73a64d360f0ed135fcca205c6292e9219e085413
Platform Version: 27.0a1
Status: RESOLVED → VERIFIED
Keywords: verifyme
Attachment #804481 - Flags: feedback?(kyee)
Duplicate of this bug: 904573
Attachment #797791 - Flags: feedback?(vpg) → feedback+
You need to log in before you can comment on or make changes to this bug.