834718 - No visual feedback on which of the views is selected at bottom of screen (tabs)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Music, defect)

Description

[Pablo Sanchez [:pabloUX]]

Please take as reference the Building Block for tabs:
http://mozilla-b2g.github.com/Gaia-UI-Building-Blocks/index.html#widgets/tabs/

Comment 1

[Casey Yee]

cc. Rob Macdonald

We'll need to standardize tab behavior in patterns and BB

Comment 2

[Rob MacDonald [:robmac]]

Attachment: music player tabs

Screen grab from Music Player - active tab should be shown.

Comment 3

[Rob MacDonald [:robmac]]

Attachment: Example of android tab implementation

Android uses color and an indicator to show the active tab.

Comment 4

[Rob MacDonald [:robmac]]

Hi Pablo... 

I'm a new UX designer on the project. I just wanted to clarify this bug as there may be a couple of separate issues here... 

First, in some apps (such as Music), the active tab item is not highlighted as spec'd in the building blocks. See https://wiki.mozilla.org/Gaia/Design/BuildingBlocks#Tabs to see the proposed implementation. I've also attached a sample music player screenshot to illustrate.

Second, even if implemented according to the guidelines, there may also be an issue of being able to differentiate the active tab from the other tabs... especially if only two tab items are visible. I've attached an example of how android uses an active tab indicator in addition to colors.

When reporting this bug, were you referring to one of the above issues? Or have I completely missed the mark? :)

- Rob

Comment 5

[Daniel Coloma:dcoloma]

(In reply to Rob MacDonald from comment #4)
> Hi Pablo... 
> 
> I'm a new UX designer on the project. I just wanted to clarify this bug as
> there may be a couple of separate issues here... 
> 
> First, in some apps (such as Music), the active tab item is not highlighted
> as spec'd in the building blocks. See
> https://wiki.mozilla.org/Gaia/Design/BuildingBlocks#Tabs to see the proposed
> implementation. I've also attached a sample music player screenshot to
> illustrate.
> 
> Second, even if implemented according to the guidelines, there may also be
> an issue of being able to differentiate the active tab from the other
> tabs... especially if only two tab items are visible. I've attached an
> example of how android uses an active tab indicator in addition to colors.
> 
> When reporting this bug, were you referring to one of the above issues? Or
> have I completely missed the mark? :)
> 
> - Rob

Pablo was referring only to using colour to indicate the active tab as it is done, for instance, in the dialer.

Comment 6

[Pablo Sanchez [:pabloUX]]

Hi Rob!

All tabs should have the visual aspect and behavior specified in the BBs you said before in order to maintain the experience in the whole system.

The bug is about active state, because currently is visually equal than normal state.

Cheers

Comment 7

[Eric Pang [:epang] UX]

Attachment: Active Tab Mock Ups

Hi Rob,

I've been working with Peter to create mock ups for the active state of tabs.  Here's our proposed solution.

We wanted the active tabs to be slightly inset.  When pressed the tab is highlighted in blue with a 1px line on the right side (that's a lighter shade).  The icons also have a bevel when active. 

Also, note in the call log mock up I've lightened the line under the "all" tab.  The idea is that the line will be lighter on whichever side is selected connecting it with the content more.

Let me know if you have any thoughts and feedback :). 

Thanks!
Eric

Comment 8

[Casey Yee]

Ah much better!  :)

Comment 9

[Rob MacDonald [:robmac]]

Yes - that looks fantastic. I also noticed that the pressed state is slightly lighter so it should work well. I'll update the ux guidelines accordingly. Thanks!

Comment 10

[Victoria Gerchinhoren [:vicky]]

Hi All,

I think there's a confusion on the elements that are being unified. Tabs are not the same thing as the tool bars and they behave differently. That's why right now we have tabs in one place (like uppper in call log) and tool bars in others. 

In the case of Calendar, the black tabs are not making sense since they are very inset navigation, where the screen is light and the "Today" element is not a tab but a button to locate today's date in any of the other views.

Also, the subtle decoration in elements across the UI is to represent affordance so the user  has a hint where to tap without having an excess of it (decoration), that is so far the reason why the whole UI is plain, pure and elegant.

Please, do not make a change until we discuss the better way to integrate this active state you are proposing.

Comment 11

[Daniel Coloma:dcoloma]

Can we use this bug to implement the already agreed Building Block (add the indicator) and open a follow-up bug to discuss changes on the Building Block itself? Thanks!

Comment 12

[Rob MacDonald [:robmac]]

Victoria, I think you raise some key issues with regards to calendar and I agree the tabs in calendar are confusing considering the "today" label represents a button whereas the others are tabs. We need a way to differentiate the button within the UI and let's raise this as a separate follow-up bug as suggested by Daniel.

For the purposes of this bug, where we use the existing black tabs, I think Eric's proposed solution does a good job making the active tab more visible and usable.

Assuming we all agree on this change, my next question is, are we able to implement this consistently to all of the dark tabs across the entire UI? We don't want to see different implementations across the device.

Comment 13

[Victoria Gerchinhoren [:vicky]]

Rob, 

Yes, there are some other issues raised after looking at the solution proposed by Eric, but I think this are not good solutions yet. 

We clearly have dark and light screens through the system and we should look after both, taking into account that the dark ones are only for media. I do not agree on carrying on with this solution before being agreed by Steve and Patryk, this is a component used in other places that the ones showed in the attached image cases, tabs can be just below the header as they are in the search screens and call log. 
Also it seems pretty odd having a secondary color as that dark turquoise / blue present at all time, I think a more subtle solution would be more kean.

Resuming, we need to audit all cases and go for a solution that includes all scenarios succesfully before changing it.

@Peter @Eric Do you think we can get a solution that involves all the cases?

Thanks!

Comment 14

[Peter La]

Eric could spend more time on this, but first I'd like clarification on the core issue with this bug.

This bug's original description is a bit vague.  It doesn't really specify which cases are affected.  From what I can tell, the only case that is broken is in Music.  So the minimum solution is to fix the behaviour in Music to align with the building blocks, ie. make it the same as what happens in Call Log.

Does this solve our main problem for this bug?  Am I missing something?

Everything else can probably be moved to a new bug (ie. a system-wide improvement design pass)?

Casey/Rob/Vicky, please advise. :)

Comment 15

[Victoria Gerchinhoren [:vicky]]

Peter,
Yes, this bug intends to ask for the correct use of BBs, please, if any other need let's move it to another bug.

Comment 16

[Eric Pang [:epang] UX]

Attachment: Music Tabs Mock Up (Highlighted)

Using the same styling for the dialer from the BB here is a mock up of the highlight state of the music tabs

Comment 17

[Eric Pang [:epang] UX]

Attachment: Music Tabs Mock Up (Selected)

Mock up of selected state of music tab.

Comment 18

[Eric Pang [:epang] UX]

Attachment: Music Filter Icons

Created Music Tab Icons to match the style of the dialer icons.

Comment 19

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

(In reply to Eric Pang [:epang] from comment #18)
> Created attachment 714512 [details]
> Music Filter Icons
> 
> Created Music Tab Icons to match the style of the dialer icons.

Eric, can you also add the @2x icons? The zip only contains the regular (i.e. small screens) size icons. Thanks!

Comment 20

[Eric Pang [:epang] UX]

Attachment: Music Filter Icons@2x

Mahai, here are the filter icons sized at @2x. Let me know if there's anything else that's needed.  Thanks!

Comment 21

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Attachment: Pull Request #9491 - Add visual feedback for views

Implementation of the design shown in comment 17.

Comment 22

[Dominic Kuo [:dkuo]]

Comment on attachment 743864 [details]
Pull Request #9491 - Add visual feedback for views

Mihai,

I am not sure if you know about the building blocks(BB) in gaia, actually there are rules in BB we can follow to apply the styles on the nav tabs, please see:

https://wiki.mozilla.org/Gaia/Design/BuildingBlocks#Tabs

I think the communications app already used the BB and follow the rules on its tabs, maybe you can refer to it and see how it implemented. The main ideas should be using the pseudo-classes of :target and :active to apply dynamic styles on the tabs without JS involved, this might not be the best way to do it, but I guess we can have a pure CSS and HTML modified patch, and will have less chances to break some logic in current JS code.

I am cancelling the review request first and after you updated the patch, feel free to re-assign to me, and any question is welcome, thanks.

Comment 23

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Comment on attachment 743864 [details]
Pull Request #9491 - Add visual feedback for views

Thanks for pointing this out Dominic, I was not aware of the building blocks standardization :)

I updated the patch to use only BB.

Comment 24

[Dominic Kuo [:dkuo]]

Comment on attachment 743864 [details]
Pull Request #9491 - Add visual feedback for views

Mihai,

After I pulled your patch and tested it in detail, I have found some noticeable issues that are caused by this patch. The first one is the mix tab should be highlighted at startup, and the second one is the background of the tabs should contains opacity. Since this is a polish work so it will be better to get everything done at a time. Please address those issue on github comments and after that you can re-assign to me for reviewing again, thanks.

Comment 25

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Comment on attachment 743864 [details]
Pull Request #9491 - Add visual feedback for views

Dominic, thanks for pointing those things out, I updated the pull request with your suggestions. Let me know if everything looks good now.

Comment 26

[Dominic Kuo [:dkuo]]

Comment on attachment 743864 [details]
Pull Request #9491 - Add visual feedback for views

Mihai,

The revised patch looks good to me, and we have a patch that modified no JS code. I think it's safe to land this and also after this is landed, it should be easy to get a approval‑gaia‑v1 because it's a low risk patch.

r+ on commit: 73e2900f546842fbd159fdf4656911e1b4dc7b83

Comment 27

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Thanks Dominic, landed on master:
https://github.com/mozilla-b2g/gaia/commit/c4ebcc10a3b3097b5245cd826599788d3b56bb7e

Comment 28

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Comment on attachment 743864 [details]
Pull Request #9491 - Add visual feedback for views

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Music tab bar highlighting
User impact if declined: Low -- tabs corresponding to different view panels will not be highlighted according to the current view
Testing completed: Yes
Risk to taking this patch (and alternatives if risky): Low/None -- no JS changes
String or UUID changes made by this patch: No

Comment 29

[Gareth Aye [:gaye] (back from PTO)]

I was not able to uplift this bug to v1-train.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1-train
  git cherry-pick -x -m1 c4ebcc10a3b3097b5245cd826599788d3b56bb7e
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 30

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

(In reply to gaye from comment #29)
> I was not able to uplift this bug to v1-train.  If this bug has dependencies
> which are not marked in this bug, please comment on this bug.  If this bug
> depends on patches that aren't approved for v1-train, we need to re-evaluate
> the approval.  Otherwise, if this is just a merge conflict, you might be
> able to resolve it with:
> 
>   git checkout v1-train
>   git cherry-pick -x -m1 c4ebcc10a3b3097b5245cd826599788d3b56bb7e
>   <RESOLVE MERGE CONFLICTS>
>   git commit

The bug doesn't depend on other patches, I fixed the merge conflicts and submitted a new pull request for v1-train (https://github.com/mozilla-b2g/gaia/pull/9929).

Dominic, can you have a look at it and confirm it achieves the desired fix on v1-train, too? Thanks!

Comment 31

[Dominic Kuo [:dkuo]]

Mihai, the new pull request which resolves the conflicts looks good! sorry for keeping you waiting and I am landing this on v1-train.

Comment 32

[Dominic Kuo [:dkuo]]

Uplifted commit c4ebcc10a3b3097b5245cd826599788d3b56bb7e as:
v1-train: 337674ef250cc8a05358b873b0fdbb2e73b49224

Comment 33

[Josh Schmitt [Joshs]]

The issue is no longer occurring and is working correctly in the music player on Buri v1.2 and Master 1.3

Changing to verified.

Buri 1.2
Environmental Variables
Device: Buri v1.2 COM RIL
Build ID: 20131204004003
Gecko: 758f3fb32dda
Gaia: 8d762f3376318fd6be390432db750ae4904c9ab6
Platform Version: 26.0
RIL Version: 01.02.00.019.102 
Firmware Version: v1.2_20131115

Master:
Environmental Variables
Device: Buri 1.3 Moz
Build ID: 20131203040236
Gecko: 8648aa476eef
Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b
Platform Version: 28.0a1
RIL Version: 01.02.00.019.102 
Firmware Version: v1.2_20131115

Comment 34

[Josh Schmitt [Joshs]]

Changed the b2g18 status to verified as it does not repo on Leo 1.1

Leo v1.1
Environmental Variables
Device: Leo v1.1 Mozilla RIL
Build ID: 20131203041431
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/617eb9d9bcc2
Gaia: 19c9ff3a46a4389e40253c97b359763243af4531
Platform Version: 18.1
Firmware Version: lge_default