889284 - [Calendar] Menu icon layout differs for calendar and E-Mail

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Calendar, defect, P2)

Description

[Leo]

Attachment: Difference in the menu icon layout for calendar and Email

STR:
  1. Check the settings icon present for calendar and E-Mail

Expected:
  The UX should be Unique.

Actual:
  Both of them have different UX layout for Menu icon.

Revision: Gaia/Master

Comment 1

[Jason Smith [:jsmith]]

I don't follow the expected vs. actual you are saying here, but I think you are meaning to say that the icon layout should be consistent for the expected results. I thought there was building blocks work going on for this. I know this is the same layout we've had since the calendar started, so this has been around for a while in this design.

This is a minor bug, however.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

It looks like the Calendar UI regressed, as I think calendar had the button not looking weird before e-mail did.

In any event, bug 809791 was the most recent fix to e-mail's behaviour was, and per https://bugzilla.mozilla.org/show_bug.cgi?id=809791#c16 and the linked graphic design image of https://www.dropbox.com/s/ww9fjv19csjn5md/04%20Email_Drawer.png e-mail looks approximately right.  It looks like we might be missing a gradient there?

Comment 3

[Jason Smith [:jsmith]]

I don't think this is calendar UI regression. This UI has been around since the very early stages of development on Firefox OS. I haven't seen changes to that menu button.

Comment 4

[Leo]

Jason, Please check bug 809791, where a screenshot for calendar is shown. E-mail layout was changed to follow the layout of calendar. But calendar layout also got changed after that.

Comment 5

[Jason Smith [:jsmith]]

Okay. Hmm...there was a lot of UX updates done in some 1.1 VD patches in the FIXED bug query. Let me get UX's view here on what we should do here.

Comment 6

[Stephany Wilkes]

Assigning to Rob since this involves calendar and email.

Comment 7

[Leo]

Attachment: Patch which was used for th old calendar menu icon layout

This was the code used for the old settings icon layout.

Comment 8

[Leo]

Attachment: Screenshot for the old settings icon layout

This is a screenshot for the old settings icon layout.

Comment 9

[Jason Smith [:jsmith]]

Note that this was working on a 7/1 build. So something regressed from 7/1 to 7/2 then.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Blocking on reverting to consisten layout from 7/1.

Comment 11

[Rob MacDonald [:robmac]]

The current style guidelines for drawer are located here:

http://buildingfirefoxos.com/building-blocks/drawer.html#drawer

So it does appear this bug is valid. I'll add a needsinfo for Przemek in visual design for final confirmation.

- Rob

Comment 12

[Przemek Abratowski [:przemek] UX]

Vicky, is this the intended design for this calendar screen? This was created before I came on board.

Comment 13

[Victoria Gerchinhoren [:vicky]]

HI, 
None of the two is completely correct. The correct one is this one: http://buildingfirefoxos.github.io/Building-Blocks/app.html#drawer

You can see that the menu icon bleeds in the idle screen and when the drawer is displayed, it shows the whole shape growing the header in width so it takes more space, as it is shown in the Email capture you attached. But the email capture lacks the drop shadow, very important to create the sensation of underlaying menu. PLease use the link above for reference.

Thanks!

Comment 14

[Rob MacDonald [:robmac]]

I just talked to Gareth and we had a sense that we may be talking about a few different issues on this bug. With regards to the original post, my understanding of the bug is as follows:

Looking at attachment 770105 [details], the toolbar at the bottom of the email app (on the right) extends across the full width of the screen. In Calendar, this toolbar does not extend the full width, which appears to be inconsistent. Assuming I'm referring to the correct issue, this is actually not a bug as the app is displaying as intended. The email app toolbar only appears full width because the Inbox (on the right pane) uses the same toolbar. Whereas Calendar (on the left) uses filters. So, from the UX perspective, this wouldn't be considered a bug. Please flag UX if I'm misunderstanding the issue.

This, however, revealed a couple of other issues that Victoria highlighted in Comment 13. From a UX perspective, these are bugs as the Email drawer shown in the attachment (770105) lacks a drop shadow and the Calendar drawer is showing the menu icon incorrectly.

Assuming my understanding of the bug is correct then, we can either open separate bugs or just re-purpose this one as an "inconsistent drawer implementation" bug. And, if my understanding of the bug is incorrect, please flag UX.

Thanks!
Rob

Comment 15

[Leo]

The issue i was trying to project was that the menu icon is all together different for calendar and Email. In  attachment 773109 [details], the menu icon was like the one discussed in comment #13.

As victoria highlighted there seems to be another problem with the shadow.

Guess this will help to channel this Bug.

Comment 16

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

Attachment: First steps to building blocks drawer enlightenment

Comment 17

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

So I chatted with James and Dylan and I think that given that

1. we've reduced this to a UX only issue with the menu icon in calendar and
2. moving over to use the drawer css introduces more risk for regressions

I feel we should push this to 1.2. Thoughts?

Comment 18

[Jason Smith [:jsmith]]

(In reply to gaye from comment #17)
> So I chatted with James and Dylan and I think that given that
> 
> 1. we've reduced this to a UX only issue with the menu icon in calendar and
> 2. moving over to use the drawer css introduces more risk for regressions
> 
> I feel we should push this to 1.2. Thoughts?

+1. I'm in favor of punting this.

Can you explain though why this is a regression? What caused us to lose the building blocks on the Calendar app?

Comment 19

[Dylan Oliver [:doliver]]

Sending back to triage -- there is no functional breakage here; it would be better to take this on for 1.2 instead.

Comment 20

[James Lal [:lightsofapollo]]

Comment on attachment 778549 [details]
First steps to building blocks drawer enlightenment

the approach is fine but it looks bad as is we need to do more work before we could land something like this.

Comment 21

[Wayne Chang [:wchang]]

(In reply to Dylan Oliver [:doliver] from comment #19)
> Sending back to triage -- there is no functional breakage here; it would be
> better to take this on for 1.2 instead.

Partner triage also agrees to put this to 1.2.

Comment 23

[Dylan Oliver [:doliver]]

Triage: This bug has been added to the v1.2 backlog but is not blocking release

Comment 24

[Dylan Oliver [:doliver]]

Tagging this bug to put it in the productivity backlog

Comment 25

[Miller Medeiros [:millermedeiros]]

this was fixed by the visual refresh. see Bug 940512