1039386 - [Epic] Allow users to set a default application for an action

Status: RESOLVED WONTFIX

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

Description

[Marcelino Veiga Tuimil [:sonmarce]]

See description in User Story field

Comment 1

[Jenny Lee]

Attachment: [Settings] Default launch app v1.0.pdf

Hello, please take a look at the initial draft for this feature. Thanks!

Comment 2

[Guillermo López :willyaranda (probably SLOW response)]

Working on this.

Comment 3

[David Garcia [:davidg][retired]]

Stealing this from Willy

Comment 4

[Guillermo López :willyaranda (probably SLOW response)]

WIPs on this branch: https://github.com/willyaranda/gaia/commits/1039386-2

Comment 5

[David Garcia [:davidg][retired]]

Attachment: Set as default combobox in activity seleciton screenshot

Hi Jenny,
This is a screenshot of how the "Set as default" option would look inside the activity selection menu.
What do you think?

Comment 6

[Jenny Lee]

Comment on attachment 8498163 [details]
Set as default combobox in activity seleciton screenshot

Hi David, the string "set as default action" is not as specified in spec. 
I understand that we might not follow through the spec entirely at this trial stage, do you have a patch ready so that I can take a look? Thanks!

Comment 7

[David Garcia [:davidg][retired]]

Jenny,
You are right about the string. I changed it to match the spec.
You can find a patch for this part of the feature in bug 1073495 (I still need to add tests). Just bear in mind that the settings part is not ready yet, so once you save a default app, you will not be able to choose again. For the settings part I opened bug 1076777.

One comment about the spec, that we were discussing here internally, is that activities currently are pretty generic. Activities are like; 'open', 'share', 'pick' and things like that.

So if a go to gallery, open an image and tap on share button, then I get the menu to select which application I want to use to share the image. If I check 'Use from now on' and select SMS application for example, we will store that the default application for 'share' is SMS. It doesn't matter what are you trying to share, it will always try to use SMS application from that point on. For activities like 'open' it can be a bit strange, because you will have a default application for 'open', no matter what you are trying to open. This is the way it is done in the patch.

We were thinking about different ways of trying to be more clever about this, using the filters that applications define on their manifests. For example Gallery can say that it can manage the 'open' activity, but only if the type of the file is 'img/jpeg' or 'img/png'. But then the settings part could be more difficult, and also is hard to say when the user selects 'Use from now on' what she really means by that. She means anytime I try to open a jpeg image use this application... or anytime I try to open an image no matter the type... or just anytime I open something.

I think we can implement it the simple way, just based on the type of activity on try to be more clever later, or maybe change the way activities are defined currently.
What do you think?

Comment 8

[Jenny Lee]

Hi David,

The design you see in spec comes with limitations. We had a mail thread before discussing the problem you pointed out here, this is what UX proposed: 

1) We will support "setting default app" for a specific groups of "activity+type" combination and predefine the activity name shown on UI. ex. For activity+type(s): "view+URL", map it with the name "Open URL". Note that at this point, we don't have a list of "action+type(s)" that we know we want to support yet, the goal is to support only the basic/essential ones like access mail, open URL, take photo/videotaping. This way, we can control what we're showing in settings > application manager > default launch app.

2) We will not support "setting default app" if no type is defined for an activity initiated.

3) We will not support "setting default app" if the activity+type doesn't match any of the ones we have in our database. From what I know, the activities defined in our database should cover most of the actions an app would initiate. If a 3rd party app creates an arbitrary activity name that is not recognizable, we shall let the app handle the activity itself. (FFOS Web activity list: https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities)  
  
Additionally, we will not support "setting default app" for a certain kinds of activity. ex. share, when sharing, it's rare that user would always share via the same app, thus no need to allow user to choose a default. For activities like this, user will have to select an app to carry on the action each time the activity is initiated.

Let me know if this makes sense to you. Thanks! :)

Comment 9

[David Garcia [:davidg][retired]]

Hi Jenny,

I'm implementing this based on your comments. There is going to be a predefined list of activity+type pairs, for which the default action is going to be supported.
Do you have the list of which ones do you want to support? If not I will just add some of them for time being.

Thanks

Comment 10

[Jenny Lee]

(In reply to David Garcia [:davidg] from comment #9)
> Hi Jenny,
> 
> I'm implementing this based on your comments. There is going to be a
> predefined list of activity+type pairs, for which the default action is
> going to be supported.
> Do you have the list of which ones do you want to support? If not I will
> just add some of them for time being.
> 
> Thanks

Hello David,
Right now we don't have a final list of actions to support yet. I'll try to provide you the list as soon as possible (hopefully next week), thanks!

Comment 11

[Jenny Lee]

Attachment: [Settings] Default launch app v1.1.pdf

Hello, see attached for updated spec including list of activity + type supported. Thank you!

Comment 12

[Marcelino Veiga Tuimil [:sonmarce]]

David and I were reviewing the new UX spec, and it is not clear for us the way to implement the case of "view" activity for browser & email URL. First of all, we have to expose "url" field to Gaia (now we only expose "type" field), but not a problem. The question is that "url" field is a regular expression, so we are not sure they should be compared. We can think in several options, like having predefined constants for web & email urls or specific types like "web-url" or "email-url", but we need your feedback to proceed with the implementation.

Jenny, we propose to create an separate bug for this case, to work on it we decide the way to implement it, and meanwhile continuing with remaining case. Do you agree?

Jonas, what do you think about the possible options to implement this case?

Comment 13

[Jenny Lee]

(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #12)
> 
> Jenny, we propose to create an separate bug for this case, to work on it we
> decide the way to implement it, and meanwhile continuing with remaining
> case. Do you agree?
> 
Sure! Let's bring the discussion to another bug.

Comment 14

[Marcelino Veiga Tuimil [:sonmarce]]

I have created bug 1100965 for implementing url filters when we have a technical decision

Comment 15

[Marcelino Veiga Tuimil [:sonmarce]]

We have another question regarding latest UX spec, what happens if we install an e-mail app providing "new" activity and not providing "view" activity? For example, in a case like following one:
1. Install MyNewEmail e-mail app
2. Open an app trying to send an e-mail opening "new" activity
3. Select MyNewEmail app as default one (it can only be done for "new" activity, as MyNewEmail app does not provide "view" activity)
4. Open an app trying to create an e-mail with "view" activity (no way to use MyNewEmail app, as it does not provide "view" activity)

Comment 16

[Jenny Lee]

Ahhh I should've added a rule about the issue you mentioned.. In the dialog, we will only show the apps that support both "new" and "open" email. So if MyNewEmail only supports "new" activity, it will not be listed in the set as default dialog. This goes the same for "new", "open" and "update" contact. 
(Note that in the spec I've specified a similar rule for media related action, see p. 10 description)
Thanks!

Comment 17

[David Garcia [:davidg][retired]]

Hi Jenny,

The problem I see with that is, you force applications to implement all the activities we are grouping together for an action, even when it doesn't make sense for that app. 

For example, if there is an application that it is just a contact viewer (doesn't allow creation), then it will only implement the 'open' activity, but the user will never be able to use it, because only applications implementing all 'open', 'new', 'update' will be shown in the menu.

The current implementation in bug 1073495, works as following:
* If I select an application as default for 'new' 'webcontact', that application will be set as default for 'update' and 'open' too.
* If an 'update' activity is initiated, and the application that was set as default doesn't support 'update', it will show the menu so the user can select another app.

I created a follow up bug 1101425, to deal with this problem.

Comment 18

[Jenny Lee]

Hi David,
See comments below!

(In reply to David Garcia [:davidg] from comment #17)
> Hi Jenny,
> 
> The problem I see with that is, you force applications to implement all the
> activities we are grouping together for an action, even when it doesn't make
> sense for that app. 
> 
> For example, if there is an application that it is just a contact viewer
> (doesn't allow creation), then it will only implement the 'open' activity,
> but the user will never be able to use it, because only applications
> implementing all 'open', 'new', 'update' will be shown in the menu.
> 
The reason why UX decided to show only the apps that support all action+type is to reduce the number of default app that can be setup. Imagine if user can set up default app for update, view and open contact separately..there will be 2 more items related to contact showing up in Settings (on spec p.9 screen 1), also user will potentially be asked 3 times for setting up contact related apps, this can be confusing as user won't necessarily notice the difference between the three action+type combinations. 
Another example would be image related apps, it doesn't really make sense to allow user to set up default app to open jpeg, png, gif and bmp file separately, not to mention this would create 3 more items in Settings. 

I understand your concern, but the current design seems to be a more reasonable choice as opposed to providing more flexibility.

> The current implementation in bug 1073495, works as following:
> * If I select an application as default for 'new' 'webcontact', that
> application will be set as default for 'update' and 'open' too.
Yes, and we make sure the chosen app will also be able to do 'update' and 'open'.

> * If an 'update' activity is initiated, and the application that was set as
> default doesn't support 'update', it will show the menu so the user can
> select another app.
This shouldn't happen.
> 
> I created a follow up bug 1101425, to deal with this problem.

Let me know what you think, thanks!

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #12)
> Jonas, what do you think about the possible options to implement this case?

I've had discussions with the UX team before about this problem. I don't see a way that we can build a UI which shows the user which default choices they have made, and allows them to modify those. The only thing I could think of implementing is the ability for the user to have a "remember this as default" and then have the ability to reset all defaults (or all defaults that involve a particular app).

At least with the WebActivities API the way it currently works.

But we can certainly look at simplifying the WebActivities API so that we can build a better UI for handling defaults.

Comment 20

[BMO Automation]

Firefox OS is not being worked on