832269 - [Calendar UX VD] Creating an event needs revised implementation

Status: RESOLVED FIXED

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

Description

[Victoria Gerchinhoren [:vicky]]

Attachment: Shows correct design compared with current implementation

When creating an event, the first screen has bad implementation. Every component should be a building block. 

All buttons that brings up an overlay with value selection should be a grey button with the arrow in the corner, giving the user a hint of the consequent action.
See attachment for reference.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

This has some l10n implications due to spacing of the characters in the drop down.

Having something like this may cause some languages to have characters extend beyond the drop down.  We will need to check for this as QA/L10n.

Adding Stas and Pike.

Comment 2

[Jason Smith [:jsmith]]

This totally isn't a critical UX issue. I'm pulling the nom here and disagreeing here.

Please remind our partners that crying wolf on bugs to indicate criticality on bugs that are non-critical creates noise, puts risk for regressions, and dilutes focus on the right bugs.

Comment 3

[Jason Smith [:jsmith]]

Per talking with Josh, he wants this back to UX-P? cause this was incorrectly marked as a P1.

Comment 4

[Jason Smith [:jsmith]]

I'll let it still go through triage, but I really don't agree here.

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

This bug is too vague, and does not propose actual fixes to aspects of the implementation.  Please get UX and product to weigh in the level of effort here.  We suspect there is more to be done here than can be done by next Friday when tef+ bugs are to be fixed by.

Comment 6

[David Scravaglieri [:scravag]]

Victoria, Daniel, could you move forward on this issue, Lukas is right, this is not an actionable item for developers to work on it.

Comment 7

[Victoria Gerchinhoren [:vicky]]

(In reply to Lukas Blakk [:lsblakk] from comment #5)
> This bug is too vague, and does not propose actual fixes to aspects of the
> implementation.  Please get UX and product to weigh in the level of effort
> here.  We suspect there is more to be done here than can be done by next
> Friday when tef+ bugs are to be fixed by.

Hi Lukas,
What do you mean by vague? I think providing a mockup solution and explaining the difference by highlighting both visually and verbaly is pretty specific.

The imput text should not trigger an overlay, is a very incorrect behaviour that missleads the user. They should be value selectors. 

Also, the Calendar selector has a ridiculous tiny hint space that makes it really unusable, have you tried to select a calendar without hinting the input field below it?

If you need further clarification on this, please do not hesitate.

Comment 8

[Kevin Grandon :kgrandon]

I can work on this one.

Comment 9

[Kevin Grandon :kgrandon]

Attachment: Implemented Add Event Screen

Comment 10

[Kevin Grandon :kgrandon]

Attachment: Implemented Modify Event Screen

Note: The "calendar" selection box is disabled in this state. I'm going to verify that this is the same style we have in building blocks for disabled states.

Comment 11

[Kevin Grandon :kgrandon]

Attachment: Implemented Modify Event Screen

This uses the proper building block for disabled icon-dialog buttons.

Comment 12

[Kevin Grandon :kgrandon]

Victoria - Please take a look at the attached screenshots to see if you are happy with the implementation. I tried to use the default building block styles as much as possible.

If you are happy with the screens, I will open a pull request with the changes: https://github.com/KevinGrandon/gaia/compare/bug_832269_create_event_ui

Thanks!

Comment 13

[Victoria Gerchinhoren [:vicky]]

Kevin, 
Everything looks OK now. Thanks!

Comment 14

[Kevin Grandon :kgrandon]

Attachment: Github pull request pointer

Comment 15

[Kevin Grandon :kgrandon]

Comment on attachment 712927 [details]
Github pull request pointer

Pavel - Looking for someone who can review this mainly building blocks change. Let me know if you think someone else should do it. Thanks!

Comment 16

[Kevin Grandon :kgrandon]

Comment on attachment 712927 [details]
Github pull request pointer

Talked to basiclines about this already - assigning to him for review, thanks!

Comment 17

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

I'm ok with this patch :) Nice work Kevin :)

Comment 19

[Kevin Grandon :kgrandon]

This has landed in master: This has been landed in master: https://github.com/mozilla-b2g/gaia/commit/4a19eb0c1b1ab1d72d082ab45415c56577a725a3

Comment 20

[Maria Angeles Oteo (:oteo)]

(In reply to Kevin Grandon from comment #19)
> This has landed in master: This has been landed in master:
> https://github.com/mozilla-b2g/gaia/commit/
> 4a19eb0c1b1ab1d72d082ab45415c56577a725a3

Hi Kevin, could you please asf for gaia-approval-v1? flag. This patch is required by Telefonica to be landed in v1.0.1 relase.
Thanks!!

Comment 21

[Kevin Grandon :kgrandon]

Comment on attachment 712927 [details]
Github pull request pointer

Requesting approval for V1 landing, as this is needed for Telefonica.

User impact if declined: Ugly add/modify event screens.
Testing completed: Manual testing for add/modify event.
Risk to taking this patch (and alternatives if risky): Regressions in calendar add/modify event screens. Shared CSS was modified, but only new classes added.
String or UUID changes made by this patch: (See pull request)

Comment 22

[Jason Smith [:jsmith]]

comment 21 reads off that this might not be safe to take into the v1.01 branch, as there's potential risk for regressions on the create/modify event screen. Is my understanding correct?

Comment 23

[Kevin Grandon :kgrandon]

Oh maybe I worded that wrong. Lots of manual testing was completed - all regressions would be unforseen, I just wanted to highlight the part of the codebase that was changed.

Comment 24

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 712927 [details]
Github pull request pointer

The patch seems relatively safe to me. Mostly html+css changes only.

Comment 25

[John Ford [:jhford] CET/CEST Berlin Time]

v1-train@806f7f9f8a82838ea2e90637657f2eaa6cd4e4ed