1209870 - [Settings] The "configure" activity should use a "x" button instead of a "<" button

Status: RESOLVED WONTFIX

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

Description

[Julien Wajsberg [:julienw]]

STR:
1. Open the SMS app.
2. Press the top-right button to show the menu, then press "Settings".

=> The Settings panel opens, but has a "<" back button. It should be a "x" back button according to the general UX for inline activities.

Comment 1

[Ken Chang[:kenkai]]

Fred, do we implement this in purpose? And is it a regression?

Comment 2

[[e-mail]]

I think julien is right. But let's ask UX to confirm the interaction.

Comment 3

[[e-mail]]

And it's not a regression since we just haven't implement that...

Comment 4

[Morpheus Chen [:morpheus] UX]

Hi Julien,

Per talked with Harly, "<" and "x" are specifically for different use cases instead of using "x" on all inline activities. For example, the inline settings in Message contains many toggles, and they will be active once toggled on, so it's strange to put "x" for user to cancel all changes within this page. Besides, it seems there is no general UX for this item, could you give us your reference document so that we can make sure no misunderstanding? Thanks.

Comment 5

[Julien Wajsberg [:julienw]]

Hey Katie, I think the question is more for you.

I understand what Morpheus is saying, maybe we should have "<" for some panels and "x" for other panels.

Comment 6

[katieC]

Hey Julien and Morpheus,

I think we're talking about 2 different things using the same activity?
1) Morpheus: "...settings in Message contains many toggles," this refers specifically to the Messages App Settings. This uses an in-app configure activity. 
2) the spec (see below) we're referring an activity that opens General Settings » Application Storage (from outside of the app). In Application Storage, there are no toggles, no controls. It is informative only - no user settings to change & save. Julien, can this be a different activity type, with an 'x' close button?

Please see spec: https://mozilla.box.com/s/bfrwwxdaz1o646h8tmmnlq61lv92sy3f
Specifically page: 10

Morpheus, perhaps you can talk with Harly again about this. I was recently on an email thread with Francis and Rob about 'overlays' (or inline activities) and using a 'x' close,'<' back, 'Done' button (for more clarity when user makes changes to toggles/settings) in the upper left in headers. My understanding is that depending on the function of the overlay, different variations exist & have been implemented (inconsistently perhaps). 

[For the record, using the '<' back button for configure activity, doesn't make sense to me. As a user, if I change settings (toggles/controls), then I expect to see Save (or Done). I'd argue that '<' back can suggest undo. I'm assuming the '<' and 'x' options were chosen for localization ease. I'll follow up with the UX Frameworks team, suggesting they do a review of the various scenarios within the OS and update patterns consistently across apps.]

Comment 7

[Julien Wajsberg [:julienw]]

> Julien, can this be a different activity type, with an 'x' close button?

What I'm suggesting in comment 5 is that, when in the "inline" activity, some panels could have the "x" button (like this one), other panels could have the "<" button. For sure this is more work than simply having the "x" button everywhere, though...

> [For the record, using the '<' back button for configure activity, doesn't
> make sense to me. As a user, if I change settings (toggles/controls), then I
> expect to see Save (or Done). I'd argue that '<' back can suggest undo. I'm
> assuming the '<' and 'x' options were chosen for localization ease. I'll
> follow up with the UX Frameworks team, suggesting they do a review of the
> various scenarios within the OS and update patterns consistently across
> apps.]

The issue is that the setting is changed as soon as the user changes something. We're not waiting for "done" or exiting the panel before changing something. I think that's good, but as a result it's difficult to find the proper UI or words on these panels.

In my mind, neither the "x" button nor the "<" button imply an "undo" action. The "done" button could imply that it's applied only when we tap on it, but there is no way to "cancel" anyway... but the user could think that killing the app would be a way to prevent the setting from being applied, which is untrue. So I don't really like the "done" button in the end. But maybe that's just me.
Maybe we need to make it somehow clearer that the settings are changed as soon as the input is changed.

Comment 8

[Julien Wajsberg [:julienw]]

To finish exposing what I have in my mind: because neither the "x" button nor the "<" button imply an "undo" action for me, I'd rather have a "x" for dialog-like panels, and "<" for in-app panels.

Comment 9

[katieC]

> Maybe we need to make it somehow clearer that the settings are changed as soon as the input is changed.
yes, agreed.

> have a "x" for dialog-like panels, and "<" for in-app panels.
yes. Though I don't fully understand what you mean by dialog-like (information/read-only?) panel, vs in-app (what defines this?) panel.

I did reach out to the UX Frameworks team, asking for more information about the rules/patterns for various inline activities, specifically the 3 left-most header buttons: '<', 'x', and 'done'. I'll be sure to share their input.

Comment 10

[Morpheus Chen [:morpheus] UX]

I had a discussion with Harly and Francis, and we have a basic conclusion so far. However, we want to make sure everything is consistent, so Harly will make this issue as an agenda in UX Frameworks team's next meeting.

Comment 11

[Julien Wajsberg [:julienw]]

(In reply to katieC from comment #9)
> > Maybe we need to make it somehow clearer that the settings are changed as soon as the input is changed.
> yes, agreed.
> 
> > have a "x" for dialog-like panels, and "<" for in-app panels.
> yes. Though I don't fully understand what you mean by dialog-like
> (information/read-only?) panel, vs in-app (what defines this?) panel.

In my mind, "dialog-like" means things that will (logically) go on top of an existing initial view, and when dismissing it we come back at the view. It's logically bound to the underlying panel. In the SMS app this is the case of looking at a report for a message.
"in-app panel" means when we navigate within an app. It's logically different enough to other panels.

But the difference can be small in some cases. And that's why the "<" icon for the Messaging Settings we trigger from the SMS app is OK to me. But in the case of the activity triggered from the System app, it's weird.

So from what I say here, it looks like the caller should be able to decide which icon it wants :)

Comment 12

[Mahendra Potharaju [:mahe]]

Shouldn't block the release for this fix. Its definitely good to have it land for 2.5

Comment 13

[BMO Automation]

Firefox OS is not being worked on