914093 - Make Gaia Keyboard settings page have a back button to go back to Settings app

Status: RESOLVED FIXED

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

Description

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

+++ This bug was initially created as a clone of Bug #906598 +++

We have a spec update for IME v1.2,
https://mozilla.app.box.com/system/1/867862120/10261164859/1

and this is a strong UX requirement that we can go back to settings app from keyboard settings page.
See page 14 of the above spec.

Comment 1

[Jan Jongboom [:janjongboom] (inactive)]

The email team also has this problem, they are changing the way how window.close could work, maybe can abuse that. Otherwise do the activities thing?

Comment 2

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Sorry that did not make this clear from the bug description.
I guess for now, we can do a app-to-app transition just like camera app <-> gallery app, and that should leverage activity as you said.

For this case, we can make built-in keyboard app to invoke a activity of settings, so that we can get back to settings app.

Makes sense?

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

So it looks like bug 909255 has landed already, so you should be able to go back to your window via activities already.

Comment 4

[Ivan Tsay (:ITsay)]

Hi Rudy,

I just correct the dependency between this one and 906598 according to the comment from Jan. After the correction, it seems we can close this bug as well. Can you confirm?

Comment 5

[Jan Jongboom [:janjongboom] (inactive)]

No we cannot. Now that bug 906598 is landed we can tackle this, but it's not fixed yet.

Comment 7

[Jan Jongboom [:janjongboom] (inactive)]

Attachment: Github PR

I'm using inline activities, window doesn't look good. The other issue was only about activities so wouldn't work in the app.launch() scenario so had to change it to activities unfortunately...

Comment 8

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

I am not comfortable to make a final call about if we could use inline activity here.
I'd like to see the opinion of Gaia system peers about this.

Alive,

Could you help take a look and help us to see this is a reasonable use case for inline activity?
Thanks.

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Jan Jongboom [:janjongboom] from comment #7)
> Created attachment 803583 [details] [review]
> Github PR
> 
> I'm using inline activities, window doesn't look good. 

What does 'window doesn't look good' mean?

> The other issue was
> only about activities so wouldn't work in the app.launch() scenario so had
> to change it to activities unfortunately...

I suggest do not use app.launch() for any reason if we do have alternative way.

Comment 10

[Jan Jongboom [:janjongboom] (inactive)]

(In reply to Alive Kuo [:alive] from comment #9)
> (In reply to Jan Jongboom [:janjongboom] from comment #7)
> > Created attachment 803583 [details] [review]
> > Github PR
> > 
> > I'm using inline activities, window doesn't look good. 
> 
> What does 'window doesn't look good' mean?
For back button behavior app switching doesn't look like the proper animation. Inline is better.
> 
> > The other issue was
> > only about activities so wouldn't work in the app.launch() scenario so had
> > to change it to activities unfortunately...
> 
> I suggest do not use app.launch() for any reason if we do have alternative
> way.
Good, but is this a valid alternative?

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Jan Jongboom [:janjongboom] from comment #10)
> (In reply to Alive Kuo [:alive] from comment #9)
> > (In reply to Jan Jongboom [:janjongboom] from comment #7)
> > > Created attachment 803583 [details] [review]
> > > Github PR
> > > 
> > > I'm using inline activities, window doesn't look good. 
> > 
> > What does 'window doesn't look good' mean?
> For back button behavior app switching doesn't look like the proper
> animation. Inline is better.

I think this is a pure UX quest. Now it's using app2app transition. We could change all kind of 'window disposition back transition' at the same time.
(Note: it's a system-wide modification).

> > 
> > > The other issue was
> > > only about activities so wouldn't work in the app.launch() scenario so had
> > > to change it to activities unfortunately...
> > 
> > I suggest do not use app.launch() for any reason if we do have alternative
> > way.
> Good, but is this a valid alternative?

Doesn't window/inline disposition work for you? I don't see app.launch in your patch.

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Push to v1.3 coz due to complexity.

Comment 13

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 803583 [details] [review]
Github PR

Clear the review flag here first since we don't have priority for this bug.

Comment 15

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Re-nominate this as koi+ according to:
https://bugzilla.mozilla.org/show_bug.cgi?id=925704#c2

==
This must be a koi blocker. It is absolutely unacceptable for the user to be trapped while trying to set the settings.
==

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Rudy Lu [:rudyl] from comment #15)
> Re-nominate this as koi+ according to:
> https://bugzilla.mozilla.org/show_bug.cgi?id=925704#c2
> 
> ==
> This must be a koi blocker. It is absolutely unacceptable for the user to be
> trapped while trying to set the settings.
> ==

The problem is I don't think abusing inline web activity is the way to solve this issue. We must choose something that is less harmful for the time being and I choose not to break the designed intention of Web Activities.

I think this issue will solve itself once we moved to Haida model, where user could simply swipe left to go back regardless how we launch the app frame/sheet.

If :djf could, in written here, saying that (ab)using web activities is a good idea in our case here I will certainly happy to see this gets resolved in v1.2.

Comment 17

[David Flanagan [:djf]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #16)
>
> 
> The problem is I don't think abusing inline web activity is the way to solve
> this issue. We must choose something that is less harmful for the time being
> and I choose not to break the designed intention of Web Activities.
> 

I know nothing at all about this. I assumed you were using web activities all along here. How would using web activities be an abuse, or against the intent of the API?

> I think this issue will solve itself once we moved to Haida model, where
> user could simply swipe left to go back regardless how we launch the app
> frame/sheet.
> 

In the meantime, we have a completely broken UX that seems unshippable to me. When the user tries to set keyboard settings, they should believe that they are still in the settings app, and need a way to get back there. It isn't okay to trap them in a keyboard settings panel and make them tap the home key to return to the home screen.

The framework should not have landed without this issue being thought through. But it has landed, and we have to fix it ASAP.  In any case, are there any alternatives to using web activities here? (In comment 1, Jan mentioned window.close().  What happens in the current model if we call window.close()?  Does that do anything? Does it go back to settings, or just to homescreen?)

> If :djf could, in written here, saying that (ab)using web activities is a
> good idea in our case here I will certainly happy to see this gets resolved
> in v1.2.

I was surprised to find out that the settings panel is actually the main entry point for keyboard apps. That seems more contorted than using a web activity here.

I think that using an inline web activity for keyboard settings is fine, except that 3rd party apps could spoof the process and offer to handle the activity themselves, forcing the user to explicitly choose the activity they want.  It would be weird to click on the button for the System Keyboard Settings and then have to choose between "System Keyboard" and "Random Non-Keyboard App".

On the other hand, we could finesse this by making the keyboard choice part of the activity chooser menu.  In the settings app, have only a single button for "keyboard settings".  When the user clicks it, initiate a "configure-keyboard-settings" activity. Have every keyboard app handle this activity. If there is more than one keyboard app installed, the user will see a choice: "System Keyboard", "Test Keyboard App", etc. They'll see the choice in the system activity menu rather than in the settings app, but it will be the same choice they currently have.

With this system if a non keyboard app implements a handler for "configure-keyboard-settings" the user will see "System Keyboard", "Test Keyboard", "Random Non-Keyboard" and will be confused, but not as badly as if they had already clicked on a "System Keyboard" button. 

(I suppose we could also try to modify the web activities protocol to allow activity requests to restrict handlers by the manifest "type" and "role" properties, so they could request only role=keyboard or only type=certified.  That might be a nice feature in general.  Or we could modify the activities api so that the app that initiates the activity could specify the domain of the allowed handler app. But modifications to the Web Activities API are obviously out of scope for koi+ bugs)

I will also note that now that keyboards are handling their own settings, there is no need for the system keyboard app to actually use the settings db, right?  The keyboard could just use shared/js/async_storage.js to store its settings. 

3rd party keyboards (non-certified) will not be able to read or write the settings db and will have to use their own storage for settings. And I suppose that we might as well do this for the system keyboard as well.

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to David Flanagan [:djf] from comment #17)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #16)
> >
> > 
> > The problem is I don't think abusing inline web activity is the way to solve
> > this issue. We must choose something that is less harmful for the time being
> > and I choose not to break the designed intention of Web Activities.
> > 
> 
> I know nothing at all about this. I assumed you were using web activities
> all along here. How would using web activities be an abuse, or against the
> intent of the API?
> 

Web Activities by definition should not be used to target specific application, which is exactly what we would need to do here.

> > I think this issue will solve itself once we moved to Haida model, where
> > user could simply swipe left to go back regardless how we launch the app
> > frame/sheet.
> > 
> 
> In the meantime, we have a completely broken UX that seems unshippable to
> me. When the user tries to set keyboard settings, they should believe that
> they are still in the settings app, and need a way to get back there. It
> isn't okay to trap them in a keyboard settings panel and make them tap the
> home key to return to the home screen.
> 
> The framework should not have landed without this issue being thought
> through. But it has landed, and we have to fix it ASAP.  In any case, are
> there any alternatives to using web activities here? (In comment 1, Jan
> mentioned window.close().  What happens in the current model if we call
> window.close()?  Does that do anything? Does it go back to settings, or just
> to homescreen?)

It would just go back to home screen.

> 
> > If :djf could, in written here, saying that (ab)using web activities is a
> > good idea in our case here I will certainly happy to see this gets resolved
> > in v1.2.
> 
> I was surprised to find out that the settings panel is actually the main
> entry point for keyboard apps. That seems more contorted than using a web
> activity here.

Why is it "more contorted"? We indeed launch a specific app with app.launch()...


> 
> I think that using an inline web activity for keyboard settings is fine,
> except that 3rd party apps could spoof the process and offer to handle the
> activity themselves, forcing the user to explicitly choose the activity they
> want.  It would be weird to click on the button for the System Keyboard
> Settings and then have to choose between "System Keyboard" and "Random
> Non-Keyboard App".
> 
> On the other hand, we could finesse this by making the keyboard choice part
> of the activity chooser menu.  In the settings app, have only a single
> button for "keyboard settings".  When the user clicks it, initiate a
> "configure-keyboard-settings" activity. Have every keyboard app handle this
> activity. If there is more than one keyboard app installed, the user will
> see a choice: "System Keyboard", "Test Keyboard App", etc. They'll see the
> choice in the system activity menu rather than in the settings app, but it
> will be the same choice they currently have.
> 
> With this system if a non keyboard app implements a handler for
> "configure-keyboard-settings" the user will see "System Keyboard", "Test
> Keyboard", "Random Non-Keyboard" and will be confused, but not as badly as
> if they had already clicked on a "System Keyboard" button. 

All of these seems to be an attempt to expand Web Activity use case. Again, I am not convinced at all that we should be using web activities (or, to explain it in an alternative way, asking 3rd-party keyboard to specify their settings page path with web activities).

Is there any other supporting theories on using web activities here? I am more than happy to be convinced given the fact I am responsible for koi scheduling here.

> 
> (I suppose we could also try to modify the web activities protocol to allow
> activity requests to restrict handlers by the manifest "type" and "role"
> properties, so they could request only role=keyboard or only type=certified.
> That might be a nice feature in general.  Or we could modify the activities
> api so that the app that initiates the activity could specify the domain of
> the allowed handler app. But modifications to the Web Activities API are
> obviously out of scope for koi+ bugs)
> 
> I will also note that now that keyboards are handling their own settings,
> there is no need for the system keyboard app to actually use the settings
> db, right?  The keyboard could just use shared/js/async_storage.js to store
> its settings. 
> 
> 3rd party keyboards (non-certified) will not be able to read or write the
> settings db and will have to use their own storage for settings. And I
> suppose that we might as well do this for the system keyboard as well.

Yes, that's a bug, feel free to file it and fix it, though we still need to migrate the settings for the user.

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Maybe UX could give some input on this: weigh in the complexity of the fix, does UX think we should block product on the lack of back key here?

Comment 20

[David Flanagan [:djf]]

Tim,

I really don't have a problem using web activities here.  Maybe we can do something better later.  Like maybe the Apps api needs an alternative to launch(). Maybe something like app.launchAsDialog() would capture what we want here.  But it would also be fine with me if we explicitly expanded the activities API to allow the explicit specification of the domain of the target app.

I think we already use activities to invoke the settings app (from the "quick settings" in the notification tray).  I suppose we could do that here.  Have settings invoke the keyboard settings panel with app.launch() and then have the keyboard return to the settings app with an activity request.  But that still uses settings and probably gives a different animation that what we want.

Comment 21

[David Flanagan [:djf]]

Another possiblity here would be to revert the settings app so that system keyboard settings were still hardcoded in the settings app.

Then, until we resolve the issues here, 3rd party keyboard would not be represented in the settings app and would have to manage their own settings UI and display a gear icon somewhere on the keyboard if they needed that.

If this part of the 3rd party keyboard framework isn't ready yet, maybe we can just back this one part out.

Comment 22

[Stephany Wilkes]

I don't understand the UX flag here: as Rudy notes in his initial comment, the spec is clear on this point. There should be a Back button. 

Anything further regarding third-party keyboard and what can/cannot be backed out should first go through Bruce, as he understands the release requirements best.

If there are other UX issues that need clarification, please list them and re-flag us.

Comment 23

[Stephany Wilkes]

And... under normal circumstances, I would koi? this as something not implemented to spec/missing functionality. I know that there are important partner considerations here, though, which is why I'd let Bruce's call trump mine on whether or not to block here.

Comment 24

[Preeti Raghunath(:Preeti)]

Moving to 1.3 not a blocker for 1.2

Comment 25

[David Flanagan [:djf]]

How is this not a blocker? It is a huge regression. If the user tries to change keyboard settings, they will become trapped and will have to return to the homescreen. They will have no idea whether their setting changes were successful or not.  Has anyone actually tried this out?

I thought that there was a firm policy that UX deadends like this were forbidden!

If we don't make this a blocker now, I'm pretty confident that one of our partners will block on it and we'll have less time to fix it.

There is a patch attached to this bug. I think it uses inline activities. I think that would be a fine solution for 1.2.

Or, there is the suggestion in comment 21: we could make 3rd party keyboards manage their own settings. And have the settings app only manage settings for the system keyboard. It is not ideal, but could be good enough for 1.2.

We don't have to wait for a gecko change to fix this perfectly. We can fix this for 1.2.  And I'm shocked that we're even considering not fixing it.

This isn't a last minute thing. We've known about this problem for over 2 months. And there is a patch attached to the bug!

Comment 26

[Alfredos-Panagiotis Damkalis [:fredy]]

I agree that this can confuse the user.

I use firefox os as my daily phone the last months and I barely thought of hitting home button in order to go back, I was searching for a back or ok/done button.

Comment 27

[Jan Jongboom [:janjongboom] (inactive)]

I fully agree with David.

The downside is that if we change it in 1.3 3rd party keyboards should change their behavior too.

Comment 28

[Bruce Huang [:bhuang] (inactive)]

I agree that we should have a way to back out of the settings, even if it is a short term fix.  Given the time we have left, what is the safest solution?  Can we navigate back to settings using the same method that got us to keyboard settings?

Comment 29

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Bruce Huang (:bhuang) from comment #28)
> I agree that we should have a way to back out of the settings, even if it is
> a short term fix.  Given the time we have left, what is the safest solution?
> Can we navigate back to settings using the same method that got us to
> keyboard settings?

Yes. I will personally provide a fix in this approach.

Comment 30

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 803583 [details] [review]
Github PR

I don't agree with the inline activity approach. We need a better one and maintain the manifest spec.

Comment 31

[Mozilla Shepherd (This account is used for automation and doesn't receive bugmail)]

Attachment: mozilla-b2g:master PR#13570

Comment 32

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 830095 [details] [review]
mozilla-b2g:master PR#13570

This patch introduce a back button with building block style. When tapped, it introduce an activity (same as Quick Settings) to bring back the Settings app.

Comment 33

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 830095 [details] [review]
mozilla-b2g:master PR#13570

The patch is simple and good.
Tim, thanks for your help.

Comment 34

[Peter Dolanjski [:pdol]]

(In reply to Rudy Lu [:rudyl] from comment #15)
> This must be a koi blocker. It is absolutely unacceptable for the user to be
> trapped while trying to set the settings.

Agreed.  Not having a back button and trapping the user constitutes a blocker.

Comment 35

[Tim Guan-tin Chien [:timdream] (please needinfo)]

master: https://github.com/mozilla-b2g/gaia/commit/9abc79e45a7283a557f177a3f9b54bec2668a2b8

Comment 36

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

Uplifted 9abc79e45a7283a557f177a3f9b54bec2668a2b8 to:
v1.2: 829c9fcf2bef8957d830c886e886dc6dbdd0fdbc