Closed Bug 1121152 Opened 10 years ago Closed 6 years ago

[UX][PP] Guided Tour screen slide with sliding UI buttons looks

Categories

(Firefox OS Graveyard :: Gaia, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: zbraniecki, Unassigned, NeedInfo)

References

Details

(Keywords: privacy)

This may be INVALID/WONTFIX depending on FxOS UX team decision.

When the user is going through the Guided Tour slideshow in Privacy Panel the Chrome of the slideshow (buttons Back/Next and the dotted progress bar) are sliding together with each slide.

I personally find it confusing and inconsistent because:

a) no other wizard or guided tour (like FTU) slide
b) no other wizard or guided tour I know make UI buttons slide in/out.

That causes bugs like bug 1115218 and make the UI less predictable.

I guess that wizard sheets sliding in and out are not that uncommon, but the chrome of the slide tour should not be part of the slide animation.

Current result:
 - Sliding App Chrome makes the interaction harder and UX paradigm confusing

Expected result:
 - Either FTU like fade in/out for cards or at least chrome UI not sliding with the content sheets
Summary: [UX] Guided Tour screen slide with sliding UI buttons looks → [UX][PP] Guided Tour screen slide with sliding UI buttons looks
Marta: Can you NI in this bug the person leading PP UX effort?
Flags: needinfo?(marta)
NI Juwei - she r+ the UX.
Flags: needinfo?(marta) → needinfo?(jhuang)
Hi,
From FxOS UX, we don't have specific definition on the transition of screens.
I would suggest that using "fade in/out" rather than "slide in/out"
Thank you!
Flags: needinfo?(jhuang)
Marta,

what is the next step here?
Flags: needinfo?(marta)
Adding privacy keyword.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: privacy
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
I'm trying to figure out how to fix it without rewriting the whole GT. Any ideas?
Flags: needinfo?(marta)
(In reply to marta from comment #6)
> I'm trying to figure out how to fix it without rewriting the whole GT. Any
> ideas?

Umm... I don't understand. The recommendation from UX is to use fade-in/fade-out instead of sliding to minimize the movement of UI buttons on the screen.

That feels like a mostly CSS change.

What am I missing?
I think Zibi is right. It seems like we should use the same controls as what FTU is using. This does sound like an enhancement, but is probably the correct fix for bugs like bug 1115218.
Flags: needinfo?(marta)
Hi Marta,
Could you help to check whether comment 7 and comment 8 helps?
Thanks!
So, this bug has not seen any update from the module owner (?) in 23 days. 

Who, except of Marta is working on PP and can be NI'ed here? It feels like a simple, fairly visible UX bug will stay in production FxOS 2.2.
(In reply to Zibi Braniecki [:gandalf] from comment #10)
> Who, except of Marta is working on PP and can be NI'ed here? It feels like a
> simple, fairly visible UX bug will stay in production FxOS 2.2.

I'm not sure, but I saw some commits from Kaze recently. Kaze - are you doing privacy panel work?
Flags: needinfo?(fabien)
Hi, I was on holidays. Have a patch that needs testing, give me a couple of days.
Flags: needinfo?(marta)
Ok, I totally give up. I have been trying to change it but somehow cannot succeed. Kevin can you suggest anything?
Flags: needinfo?(kgrandon)
Yeah, this seems like a pretty big feature to implement, and it appears to not be blocking 2.2. I unfortunately wont' be able to look at this for a while.

My recommendation is to work with :sfoster on seeing if we can abstract the navigation from FTU into some common pattern for reuse. It could be nice to have some library or web component that we include in both places.
Flags: needinfo?(kgrandon)
Sam, per comment #14, could you advise what to do here?
Flags: needinfo?(sfoster)
(In reply to marta from comment #15)
> Sam, per comment #14, could you advise what to do here?

Some kind of shared web-component for this kind of navigation would be great, but for the short-term (2.2) it sounds like we need an intermediate fix that brings the PP panels closer to the implementation in FTU. That exercise will inform how we design a future component to fill this role . I'm not at all familiar with the PP and how it is structured, but I can take a look later this week? Marta, if you want to attach or send me your work-in-progress patch I'm happy to look at it.
Flags: needinfo?(sfoster)
In the FTU we have a single footer with the back/next buttons that is shared across screens. Each time we navigate, those buttons' state and values are updated. The transition between screens is just the area between the header and footer. We may want to do something similar for PP, but its a bit fiddly and will require changes to every panel, and careful testing to ensure we don't regress functionality and accessibility. 
Its possible there's a quick fix in adjusting the CSS to only animate the content div and flip/flop the navigation buttons - to get the same visual effect. I started prototyping this and will update here if I can get it to work.

In the medium term, both FTU and PP would benefit from a custom element with a clear and flexible way represent the sequence of screens and the logic the drives that sequence.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.