Closed Bug 806425 Opened 8 years ago Closed 8 years ago
[System app][Trustworthy UI] Implement animations
355 bytes, text/html
We have to implement trusted UI once we have a final UX design.
(In reply to Fernando Jiménez Moreno [:ferjm] from comment #0) > We have to implement trusted UI once we have a final UX design. I meant trusted UI animations.
P1 nomination - required for payments v1 feature as part of the UX spec.
blocking-basecamp: --- → ?
Priority: -- → P1
This will probably get asked in triage, but clarity - is this bug basically tracking - "Whatever pieces of the trusted UI final UX that isn't implemented yet for v1, implement it"
Josh - Can you give the run down of what's needed here and what must be done for v1?
Waiting to make a final decision on Josh's response here.
Over to Casey while Josh is on PTO.
Flags: needinfo?(jcarpenter) → needinfo?(kyee)
This bug pertains to the Trusted UI animations for situations including: * Open new Trusted UI flow * Close a Trusted UI flow * Switch to Task Manager from a Trusted UI flow * Switch to a Trusted UI flow from Task Manager * Incoming call receive during a Trusted UI flow ...etc. I spoke w/ TEF UX about this in London last week but was unable to capture our discussion points into doc before leaving for PTO. I'm back now, and will discuss directly with Alberto tomorrow (Friday Nov 2), in advance of next week's SF Work Week.
:clee please make a product call here as well. this sounds like a feature which hasn't been implemented yet.
blocking-basecamp: ? → -
I thought we decided yesterday that this was necessary when I talked with various parties. Don't understand why this was marked with a minus. If more info is needed to make a call, please flag needsinfo.
blocking-basecamp: - → ?
If I understand the intention of this bug, this is basically implement the UX spec changes required for trustworthy UI, as the current implementation just implemented trustworthy UI pieces to be enough to get the pieces up and running. Is my understanding correct?
Josh, do you mind posting the spec and let's plan to discuss this on Mon in SF. I'm marking this back to a nom and then we can make a call.
blocking-basecamp: + → ?
The feature has been implemented but is awaiting final UX. Either way this is blocking because we need the spec to understand how close we may or may not be.
Alberto and I met on this today in SF. We'll confer with Chris Lee to determine blocking +/-.
I don't follow the minus here. Comment 11 implies that we should leave this nomed. Am I misreading something here?
Lucas: please help determine if this needs to be included to support the Payments/Id work.
blocking-basecamp: - → ?
(In reply to Caitlin Galimidi from comment #15) > Lucas: please help determine if this needs to be included to support the > Payments/Id work. Right. This is planned to be talked about at 12pm tomorrow. I'll see if I get a vidyo session up and running in the hotel in case other folks not at the work week want to attend.
This is blocking insofar UX needs to provide the authoritative flow for transitions/animations. It may be exactly what we already have, but either way we need it.
Spoke with Chris on this - this falls in alignment with what Lucas has stated above. We may not need all of the animations flow Josh has specified (depending on what gets called in vs out of scope), but no matter what, we're going to need something. Therefore, this is a blocker, as we're going to something here no matter what (even if it's small).
Per talking with a few people also this apparently isn't a feature, it's a user perception problem of understanding of a trusted context.
Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known P2 bugs found before or during C1".
Target Milestone: --- → B2G C2 (20nov-10dec)
Pointer to Github pull-request
Comment on attachment 681627 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6410 Thanks Alberto! Great work! r=me,basiclines with the comments that Ismael and me left in the PR addressed, please.
Attachment #681627 - Flags: review?(ferjmoreno) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Assignee: nobody → alberto.pastor
QA Contact: jsmith
Finished testing this with a basic functional test pass, with the exception of testing keyboard input within a trusted context - which I'll take care of when I test identity integration. Bugs are filed and linked to this bug for followups. Marking as verified.
Status: RESOLVED → VERIFIED
The change in cards view make me confused. What's the detail spec about * Switch to Task Manager from a Trusted UI flow * Switch to a Trusted UI flow from Task Manager We are going to develop task manager to replace cardsview in 2.0 but this old code have something broken like bug 995039. We need detail spec to fix it or redesign it for 2.0 task manager.
Flagging Francis for starters as this affects Task Manager.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(fdjabri)
This seems more like questions the Trusted UI owner should answer. Stephany, who owns this?
Flags: needinfo?(fdjabri) → needinfo?(swilkes)
Neither I nor Jaime know. Flagging Mike to double check. Seems like Omega or Harly could tackle this until we get someone assigned officially for the next release.
Flags: needinfo?(swilkes) → needinfo?(mtsai)
Since I have no previous knowledge of Trusted UI, here is what we proposed based on what we have observed: - Trusted UI should be full screen instead of a dialog - Placed Cancel & Continue button on the header - Should use the same animation as activity - Switch to task manager should still display Trusted UI screen - Tap Trusted UI from task manager should go to Trusted UI screen
You need to log in before you can comment on or make changes to this bug.