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

VERIFIED FIXED

Status

Firefox OS
Gaia::Calendar
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: jsmith, Assigned: lightsofapollo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: interaction, UX-P2, BerlinWW)

(Reporter)

Description

5 years ago
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?
(Reporter)

Comment 1

5 years ago
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.
blocking-basecamp: --- → ?
(Assignee)

Comment 2

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

"Monday 12th October 2012"
blocking-basecamp: ? → -
(Reporter)

Comment 3

5 years ago
Needs context as to why this does not block.
(Reporter)

Comment 4

5 years ago
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.
blocking-basecamp: - → ?
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.
blocking-basecamp: ? → -
(Reporter)

Comment 6

5 years ago
(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.
(Reporter)

Comment 7

5 years ago
I'll hold on this one to renom until I get an opinion from James. James - What do you think?
Flags: needinfo?(jlal)
(Assignee)

Comment 8

5 years ago
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.
Flags: needinfo?(jlal)
(Reporter)

Comment 9

5 years ago
(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.
(Reporter)

Comment 10

5 years ago
(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.
blocking-basecamp: - → ?
(Reporter)

Comment 11

5 years ago
Actually, forget my comment.
blocking-basecamp: ? → ---

Updated

5 years ago
Priority: -- → P1
Whiteboard: [interaction]
Priority: P1 → --
Whiteboard: [interaction] → interaction, UX-P1
Whiteboard: interaction, UX-P1 → interaction, UX-P2
(Reporter)

Updated

5 years ago
Duplicate of this bug: 819135
(Reporter)

Updated

5 years ago
Duplicate of this bug: 823307
Assignee: nobody → smithan
Whiteboard: interaction, UX-P2 → interaction, UX-P2, BerlinWW
(Assignee)

Comment 14

5 years ago
https://github.com/mozilla-b2g/gaia/commit/eb3b9aaea8ba3ec614339716a5c711158042da81
Assignee: smithan → jlal
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 15

5 years ago
This issue does not reproduce with Unagi, build ID: 2013112070202
Unable to verify with Otoro device.
Whiteboard: interaction, UX-P2, BerlinWW → interaction, UX-P2, BerlinWW, QARegressExclude
(Reporter)

Comment 16

5 years ago
(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.
Status: RESOLVED → VERIFIED
Whiteboard: interaction, UX-P2, BerlinWW, QARegressExclude → interaction, UX-P2, BerlinWW
You need to log in before you can comment on or make changes to this bug.