803249 - The agenda portion of the month view isn't showing the day that the events reference

Status: VERIFIED FIXED

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

Description

[Jason Smith [:jsmith]]

Build:

Device: Otoro
Hashes:

  <project name="gaia" path="gaia" remote="b2g" revision="e3efbd0411218762cf9a62278bf58ee513ff331f"/>
  <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="38c06c8b4f8f8a6a513a66ab62c9421835017c9f"/>

Steps:

1. Select some of the days in the month view

Expected:

The day should be shown in the agenda portion of the calendar.

Actual:

No day is seen. Currently you get something like:

Monday October 2012

But there's no day. This can be a bit haphazard for a user if I say, select a day, then switch to the next month, cause how exactly am I going to know what day that agenda view is tied to if I'm not in that month?

Comment 1

[Jason Smith [:jsmith]]

Noming mainly cause this actually strangely enough, confused me when I first looked at it after switching to a different month. Seems like a quick fix too that has high value.

Comment 2

[James Lal [:lightsofapollo]]

We have the room to add the date here anyway I think that is the best solution.

"Monday 12th October 2012"

Comment 3

[Jason Smith [:jsmith]]

Needs context as to why this does not block.

Comment 4

[Jason Smith [:jsmith]]

Oh and I'm renoming for the same reason in comment 1 and saying that leaving behind some of these bugs like this one is setting the quality bar way too low. I don't want so squashing of quality going on here for ship.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

This is a "nice to have". If a patch appears very soon, we'd allow it. The caldenar feature works without needing this fix though. Does not block.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Mark Finkle (:mfinkle) from comment #5)
> This is a "nice to have". If a patch appears very soon, we'd allow it. The
> caldenar feature works without needing this fix though. Does not block.

I don't agree this is a nice to have. A calendar's primary use case is viewing of event data in an easy, readable form - it's the big selling point why we use them in the first place. This is probably one the web apps that I think is more critical to get the UI right rather than others. Otherwise, the calendar loses it's primary usefulness for why we use them in the first place.

Personally on this one though - I think it's less worthy actually arguing over this one, as the time to fix it will probably be quicker than the time to actually argue over it.

Comment 7

[Jason Smith [:jsmith]]

I'll hold on this one to renom until I get an opinion from James. James - What do you think?

Comment 8

[James Lal [:lightsofapollo]]

As this I believe a 4 char patch with no risk regardless of the status I would submit a patch. The visual design omits both the year and date. During my own usage I find this a bit counter-intuitive. That said you can also see the date by looking at the month view.

Comment 9

[Jason Smith [:jsmith]]

(In reply to James Lal [:lightsofapollo] from comment #8)
> As this I believe a 4 char patch with no risk regardless of the status I
> would submit a patch. The visual design omits both the year and date. During
> my own usage I find this a bit counter-intuitive. That said you can also see
> the date by looking at the month view.

Hmm...in that case, I probably won't renom again mainly since a work-around (though not great exists), but I'll definitely push back from gaia approval for this one if it's incredibly low risk, high value.

Comment 10

[Jason Smith [:jsmith]]

(In reply to James Lal [:lightsofapollo] from comment #8)
> As this I believe a 4 char patch with no risk regardless of the status I
> would submit a patch. The visual design omits both the year and date. During
> my own usage I find this a bit counter-intuitive. That said you can also see
> the date by looking at the month view.

I actually checked the visual/UX design in dropbox - looks like it was inconsistently present (some UXs showed it, others did not). Probably an error in the specs.

I'm rethinking what I said in comment 9 now, as this feels like this stands out too obviously to someone who picked up and used the calendar (it would be equivalent of a severity of using the wrong branding on a product). I'm renoming again - this is too obvious of an error to not fix.

Comment 11

[Jason Smith [:jsmith]]

Actually, forget my comment.

Comment 14

[James Lal [:lightsofapollo]]

https://github.com/mozilla-b2g/gaia/commit/eb3b9aaea8ba3ec614339716a5c711158042da81

Comment 15

[Mila Davydova]

This issue does not reproduce with Unagi, build ID: 2013112070202
Unable to verify with Otoro device.

Comment 16

[Jason Smith [:jsmith]]

(In reply to Mila Davydova from comment #15)
> This issue does not reproduce with Unagi, build ID: 2013112070202
> Unable to verify with Otoro device.

No need to test on Otoro. Only one device is needed for testing this.