Closed Bug 1210290 Opened 8 years ago Closed 7 years ago

Add option to open homepage on new tabs

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1293713

People

(Reporter: antlam, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

prev_set_dialog2.png
218.78 KB, image/png
Details
Attached image prev_set_page2.png (obsolete) — 
I'd like to see if these UX updates help solve some concerns we have around the "Set a Homepage" feature, namely:

 - 1) Loading a set URL for every new tab
 - 2) Possibly being unclear how to disable this feature 

So, I propose changing to a full page settings UI [1] (rather than a dialog), and adding an option to not do this for every new tab.

Switching to a full page UI is not a must. But it gives us more space to address 2) and room to explain further messaging. It still follows Google's design guidelines as well so I don't foresee it being an issue.

In the same breath here, I think we can remove the "Use current tab" option that was not a requirement in the beginning anyways. That cleans up the interaction model to be less confusing and more straight forward.

Thoughts?

[1] https://www.google.com/design/spec/patterns/settings.html#settings-labels-secondary-text
Blocks: homepage
See Also: 1201181 → 
Would love to get your guys feedback on this!
Flags: needinfo?(mark.finkle)
Flags: needinfo?(krudnitski)
note: copy TBD
Just a heads-up: SwitchPreference is API level 14 (Android 4+).
Yes, copy definitely TBD !

Although providing this extra level of control creates more complexity to what is likely a simple action, I think giving users the chance to customize to this extent is fine for now.

I'd want to see this defaulted as 'on', and we can monitor (via telemetry if we land the right probes) to see how many people turn that 'off'. The setting will be apparent when the user goes in to set the home page in the first place, so I'm not worried about discovery.

Adding Barbara for visibility and her htoughts.
Flags: needinfo?(krudnitski) → needinfo?(bbermes)
Alright, here my thoughts:

- copy TBD - yes
- choice of opening it in new tab - great. Let's start with defaulting the open in new tab to ON, as Karen said, get some data around it, if we notice more people turning it off, let's say after 1-2 months of data collection, we know they don't want it, and we can default it to Off, i.e. nothing is set in stone.
- Mark, if you still have major concerns, would you like to run an A/B test on on/off by default?
Flags: needinfo?(bbermes)
I do still have concerns:
1. I don't see people asking for showing a homepage when adding a new tab.
2. I don't see other browsers showing a homepage when adding a new tab. I looked at chrome, dolphin and opera.
3. I wonder what we'll do for adding a private tab? We currently show the about:privatebrowsing page.
4. The new design seems complicated for something as simple as a homepage.
5. I really don't like enabling the "newtab" behavior by default. That seems to only be good for partners, but would likely hurt our retention with people.

I would suggest shipping the current state and looking to see if anyone is asking for more. I'd rather ship something simple and need to add more later, than shipping too much now and need to remove it later.
Flags: needinfo?(mark.finkle)
Switching to a full page UI is not a must. 

We could just replace the "Use current tab" check box with a "Open on new tab" check box. (copy tbd)
(In reply to Anthony Lam (:antlam) from comment #7)

> We could just replace the "Use current tab" check box with a "Open on new
> tab" check box. (copy tbd)

+1 let's do this. I don't think the "Use current tab" check box provides good UX, since it's hard to remember what tab you were even on by the time you get this deep in settings.

Morphing this bug to be about adding this "Open on new tab" functionality. This will require more than just settings work, since we'll need to actually support opening this page on new tabs.
Summary: Update "Set a Homepage" settings options → Add option to open homepage on new tabs
Attached image prev_set_dialog2.png — 
Here's the modal dialog UX option. This would be the our first version.

Copy tbd
Attachment #8668268 - Attachment is obsolete: true
(In reply to :Margaret Leibovic from comment #8)
> (In reply to Anthony Lam (:antlam) from comment #7)
> 
> > We could just replace the "Use current tab" check box with a "Open on new
> > tab" check box. (copy tbd)
> 
> +1 let's do this. I don't think the "Use current tab" check box provides
> good UX, since it's hard to remember what tab you were even on by the time
> you get this deep in settings.

Why are we doing this? Last I heard we were waiting for some indication that people actually wanted to see the homepage when adding a new tab.
(In reply to Mark Finkle (:mfinkle) from comment #10)
> (In reply to :Margaret Leibovic from comment #8)
> > (In reply to Anthony Lam (:antlam) from comment #7)
> > 
> > > We could just replace the "Use current tab" check box with a "Open on new
> > > tab" check box. (copy tbd)
> > 
> > +1 let's do this. I don't think the "Use current tab" check box provides
> > good UX, since it's hard to remember what tab you were even on by the time
> > you get this deep in settings.
> 
> Why are we doing this? Last I heard we were waiting for some indication that
> people actually wanted to see the homepage when adding a new tab.

I was under the impression that we did hear people wanted to see the homepage when adding a new tab, but we don't want to make that the default behavior.

I believe Roland has been trying to reach out to users who have complained about this on SUMO, but hasn't had much luck in the way of responses. We've been waiting on that feedback before deciding to ship something, but I think we've waited long enough, and we should just ship what we suspect people will like, then listen for feedback on beta/release.

I seem to recall evidence that some other browsers have this functionality, but looking quickly at Chrome and Dolhpin, I don't see this. Given that, I would be fine with us shipping the home page feature without this "also in new tab" option, then waiting for responses to users on beta/release.
I know we had this discussion before, and we all were hoping to get some users to tell us exactly what they want :(

I think we are clear on shipping "set a homepage" as people did ask for this.

What is still unclear is if they would like the option "open on a new tab" as well. We don't have any data that indicates that yet, hence my suggestion, we will replace it with "use current tab" and do not have it checked by default. We will put a probe in it to check who sets it (option A).

Option B: Otherwise we could ship without "open new tab" and collect feedback via SUMO etc. if people say they like it but need that specific addition as well, we could add it.

We can also vote if you like.

Nevertheless, we should ship it soon.
Attached image Screen Shot 2015-11-12 at 1.39.41 PM.png (obsolete) — 
Barbara, Margaret, and I talked about possibly using the checkbox as a "use the default homepage" option. This would be checked and disable a "custom homepage" by default, thereby telling the user they can set one, or use ours. 

We could go with something like this if we decide to not ship "set for new tab" as an option right now.
Anthony, what issue are we trying to solve with this latest mock? To tell the user they can change it?
I think I forgot how the UX will work, is it that people can only change the text field if they uncheck the "use default homepage"?

For later, have we ever considered adding a item in the menu, "set current page as homepage", this would help cases where the URL is too long, e.g. a faculty page or something for a professor (just making something up here)., or maybe a website that requires specific params in the URL.
Flags: needinfo?(alam)
(In reply to Barbara Bermes [:barbara] from comment #14)
> Anthony, what issue are we trying to solve with this latest mock? To tell
> the user they can change it?

The goal is just to be more obvious about what our options are so users will have less chance of not knowing what to do.
  A. use about:home (default)
  B. use a URL you choose

> I think I forgot how the UX will work, is it that people can only change the
> text field if they uncheck the "use default homepage"?

Yep! Uncheck it to use the input field, but when you change your mind, just check it "ON" to reset to default. 

> For later, have we ever considered adding a item in the menu, "set current
> page as homepage", this would help cases where the URL is too long, e.g. a
> faculty page or something for a professor (just making something up here).,
> or maybe a website that requires specific params in the URL.

Yeah, that was the original mock but then we decided to use it for "Also set for new tabs".

For simplicity sake, I think this mock (comment 13) is a good V1. Then we can go from there.
Flags: needinfo?(alam)
I think this discussion should be happening over in bug 1224214... this bug is about the option to open the homepage in a new tab, which isn't covered in these mocks.
Attachment #8686792 - Attachment is obsolete: true
I don't think people want showing a homepage when adding a new tab, and this homepage is a web page.
I think we just need an entry point for users, like attachments on bug1206155 and bug1243244.
In China, Homepage means more information and content in it. There is no need to load them every time. You know, not all the places where the Internet is fast.
I profoundly agree with “add option to open homepage”, but not open it in a new tab.
And another question, if users open the homepage in a new tab, how they can visit history or bookmarks?
Is there any chance to add option to "Show home icon in address bar"?
(In reply to DongShengXue from comment #18)
> Is there any chance to add option to "Show home icon in address bar"?

We've debated this previously, and I'm not sure exactly where that discussion landed. I think it's just a difficult situation that we don't have much space in the toolbar, even if we only showed this button for users who had a homepage set.

Additionally, if we only conditionally show this button, we're setting ourselves up for a maintenance burden, and we need to make sure it's worth it.
Flags: needinfo?(bbermes)
(In reply to :Margaret Leibovic from comment #19)
> 
> Additionally, if we only conditionally show this button, we're setting
> ourselves up for a maintenance burden, and we need to make sure it's worth
> it.

For reference， we found an addon named "Home Button for firefox on android", we think it is very good with the Chinese user's habits.
(In reply to DongShengXue from comment #20)
> (In reply to :Margaret Leibovic from comment #19)
> > 
> > Additionally, if we only conditionally show this button, we're setting
> > ourselves up for a maintenance burden, and we need to make sure it's worth
> > it.
> 
> For reference， we found an addon named "Home Button for firefox on android",
> we think it is very good with the Chinese user's habits.

If there is an add-on that meets your need, I think that's a great solution. We could always bundle this add-on if we make a Chinese distribution build.
(In reply to :Margaret Leibovic from comment #21)
> If there is an add-on that meets your need, I think that's a great solution.
> We could always bundle this add-on if we make a Chinese distribution build.

The add-on has almost met our requirements. But the design of the interface is not enough in appearance, and some functionality is conflict with ours(custom home page feature). I think ours is good enough, so we just hope we can add the small feature to ours.

BTW, now we already can bundle the add-on in the build?
(In reply to DongShengXue from comment #22)
> (In reply to :Margaret Leibovic from comment #21)
> > If there is an add-on that meets your need, I think that's a great solution.
> > We could always bundle this add-on if we make a Chinese distribution build.
> 
> The add-on has almost met our requirements. But the design of the interface
> is not enough in appearance, and some functionality is conflict with
> ours(custom home page feature). I think ours is good enough, so we just hope
> we can add the small feature to ours.
> 
> BTW, now we already can bundle the add-on in the build?

If you are using a distribution customization, you can include add-ons by following these direstions:
https://wiki.mozilla.org/Mobile/Distribution_Files#Add-ons

Ideally the Mozilla China build would be a distribution build instead of a fork of the mozilla-central repo. Although there are still some local changes you want to maintain yourself, maybe you can start to move those customization to a distribution, so that there is less and less to maintain in the fork (and hopefully eventually there would be no fork).
(In reply to :Margaret Leibovic from comment #23)
> Ideally the Mozilla China build would be a distribution build instead of a
> fork of the mozilla-central repo. Although there are still some local
> changes you want to maintain yourself, maybe you can start to move those
> customization to a distribution, so that there is less and less to maintain
> in the fork (and hopefully eventually there would be no fork).

Yes, your are right. We also hope we can do that, and I will try it on the next. I think we need your help in many ways.
Flags: needinfo?(bbermes)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.