[Calendar UX VD] Creating an event needs revised implementation

RESOLVED FIXED

Status

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

People

(Reporter: vicky, Assigned: kgrandon)

Tracking

unspecified
x86
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:-, b2g18 fixed)

Details

(Whiteboard: interaction [UX-P?], [TEF_REQ], PRODUCT-CONSISTENCY, [TEF UX Critical])

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 703855 [details]
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.
(Reporter)

Updated

5 years ago
Assignee: nobody → jlal
Whiteboard: ineraction, UX P2

Updated

5 years ago
Whiteboard: ineraction, UX P2 → ineraction, UX-P2
Assignee: jlal → nobody
(Reporter)

Updated

5 years ago
Whiteboard: ineraction, UX-P2 → interaction [UX-P1], [TEF_REQ]

Updated

5 years ago
Whiteboard: interaction [UX-P1], [TEF_REQ] → interaction [UX-P1], [TEF_REQ], PRODUCT-CONSISTENCY
blocking-b2g: --- → tef?
Whiteboard: interaction [UX-P1], [TEF_REQ], PRODUCT-CONSISTENCY → interaction [UX-P1], [TEF_REQ], PRODUCT-CONSISTENCY, [TEF UX Critical]
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.
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.
blocking-b2g: tef? → ---

Updated

5 years ago
Whiteboard: interaction [UX-P1], [TEF_REQ], PRODUCT-CONSISTENCY, [TEF UX Critical] → interaction [UX-P1], [TEF_REQ], PRODUCT-CONSISTENCY
Per talking with Josh, he wants this back to UX-P? cause this was incorrectly marked as a P1.
Whiteboard: interaction [UX-P1], [TEF_REQ], PRODUCT-CONSISTENCY → interaction [UX-P?], [TEF_REQ], PRODUCT-CONSISTENCY
I'll let it still go through triage, but I really don't agree here.
blocking-b2g: --- → tef?

Updated

5 years ago
Whiteboard: interaction [UX-P?], [TEF_REQ], PRODUCT-CONSISTENCY → interaction [UX-P?], [TEF_REQ], PRODUCT-CONSISTENCY, [TEF UX Critical]
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.
blocking-b2g: tef? → -
Victoria, Daniel, could you move forward on this issue, Lukas is right, this is not an actionable item for developers to work on it.
Flags: needinfo?(vpg)
Flags: needinfo?(dcoloma)
(Reporter)

Comment 7

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

Comment 8

5 years ago
I can work on this one.
Assignee: nobody → kgrandon
(Assignee)

Comment 9

5 years ago
Created attachment 712647 [details]
Implemented Add Event Screen
(Assignee)

Comment 10

5 years ago
Created attachment 712649 [details]
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.
(Assignee)

Comment 11

5 years ago
Created attachment 712673 [details]
Implemented Modify Event Screen

This uses the proper building block for disabled icon-dialog buttons.
Attachment #712649 - Attachment is obsolete: true
(Assignee)

Comment 12

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

Comment 13

5 years ago
Kevin, 
Everything looks OK now. Thanks!
Flags: needinfo?(vpg)
(Assignee)

Comment 14

5 years ago
Created attachment 712927 [details]
Github pull request pointer
(Assignee)

Comment 15

5 years ago
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!
Attachment #712927 - Flags: review?(pivanov)
(Assignee)

Comment 16

5 years ago
Comment on attachment 712927 [details]
Github pull request pointer

Talked to basiclines about this already - assigning to him for review, thanks!
Attachment #712927 - Flags: review?(pivanov) → review?(igonzaleznicolas)
Attachment #712927 - Flags: review?(igonzaleznicolas) → review+
I'm ok with this patch :) Nice work Kevin :)
(Assignee)

Updated

5 years ago
Duplicate of this bug: 810774
(Assignee)

Updated

5 years ago
Blocks: 810774
(Assignee)

Updated

5 years ago
Blocks: 799870
(Assignee)

Comment 19

5 years ago
This has landed in master: This has been landed in master: https://github.com/mozilla-b2g/gaia/commit/4a19eb0c1b1ab1d72d082ab45415c56577a725a3
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Flags: needinfo?(dcoloma)
(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!!
(Assignee)

Comment 21

5 years ago
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)
Attachment #712927 - Flags: approval-gaia-v1?(21)
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?
(Assignee)

Comment 23

5 years ago
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 on attachment 712927 [details]
Github pull request pointer

The patch seems relatively safe to me. Mostly html+css changes only.
Attachment #712927 - Flags: approval-gaia-v1?(21) → approval-gaia-v1+
v1-train@806f7f9f8a82838ea2e90637657f2eaa6cd4e4ed
status-b2g18: --- → fixed
You need to log in before you can comment on or make changes to this bug.