mozilla
The "set-as-default" landing page isn't clear enough about what the user should do
Description
The page https://www.mozilla.org/en-US/firefox/set-as-default/thanks/ , when viewed in Firefox on Android, isn't clear enough about what to actually do to set-as-default. (This matters because we have "Set Firefox as your default browser" links that point at this page, on other properties, e.g. this one just under "Firefox is made in part by lots of real-life, tired yet strangely optimistic parents".)
Steps to reproduce
- Open Firefox (or Firefox beta, or Nightly) on Android.
- Visit https://www.mozilla.org/en-US/firefox/set-as-default/thanks/
Expected result
Ideally: clear instructions on how to set as default. Or failing that: a link that takes me to instructions, with it being obvious-from-context that I should click that link.
Actual result
The page says:
Here's everything you need to know about setting your default browser on Android devices.
To me, this "Here's..." sounds like the information will be directly below this introduction, but in fact there's no set-to-default information that follows. In fact, the instructions are actually hiding behind the link "Android devices", but that's not clear from context. I don't intuitively expect that clicking a link titled "Android devices" will take me to Firefox-set-to-default instructions.
Environment
Pixel 8, running Android 14
Here's how this page looks in context:
When a user lands here after having just clicked a link on another page which was labeled "Set firefox as your default browser", they expect to see what-they-need-to-do. They don't expect to be implicitly nudged to click another link labeled "Android devices".
I don't assign tickets here, but I don't think so; I think this needs attention from someone involved with designing/maintaining this flow.
The issue here is that the link is part of an i10n string, so any change to it will trigger the need to re-translate from all the localisers:/
Here’s everything you need to know about setting your default browser on <a href="{ $android }">Android devices</a>
Otherwise I'd just suggest to wrap the whole sentence in the link, like:
<a href="{ $android }">Here’s everything you need to know about setting your default browser on Android devices</a> (the same is for iOS right below)
— or in this case move the HTML anchor out of the Fluent string and put it straight into the template — but even such change would mean new translations:/
I know @dholbert you'd like to land on the KB page directly, but that's probably not possible in the current logic, where all inbound links go to set-as-default or set-as-default/thanks — where the browser and platform are checked first etc. and only then the instructions are displayed.
I'll look into the js bundle firefox-default-thanks if there's place where maybe with picking the right thanks-state-not-default-* callout a window.location redirection could be injected to skip the additional click…
Nope, the conditional callouts are picked via CSS: https://github.com/mozilla/bedrock/blob/929ad7d84c433a7d37ac623a2912cff0f6fc87cc/media/css/firefox/set-as-default/thanks.scss#L60-L68
In that case I'd suggest a new string to make the CTA more obvious, instead of
Here’s everything you need to know about setting your default browser on Android devices.
something like: (wording taken from the KB article, if it sounds repetitive feel free to suggest better copy)
"You can set Firefox as your default browser on your Android device in Settings, see our help article for step-by-step instructions with screen shots."
(wherever that is, be it app settings or system settings, depending on OS version; that's covered in depth in the KB article and this makes it more OS-agnostic… the same copy is true for iOS too so that can be used in both cases.)
@dholbert That string migration nonetheless means work from i10n teams, but if you think it's worth it I can PR the change. (In that case please take the opportunity to fine-tune the copy as it will have to change anyways…)
@dholbert @janbrasna If i can add my 2 pence in here: I agree that the wording could be better. But i also don't think it's confusing to the extent that the existing string is likely to be causing any major issues. We should weigh up making this change against the effort it puts on localizers to re-translate the string.
IMHO this is a nice-to-have, and not really a priority. It could be a wontfix.
I think the existing wording is ~fine, but would ideally love to see "Here's everything you need to know" be the linkified phrase, rather than "Android devices". That makes it intuitively clearer where the instructions are (inside the "Here" link-tunnel), and what will happen if you click the link (you'll arrive at "everything you need to know").
Or, linkifying the whole sentence would be fine too (if a bit extra-colorful :) ).
The current situation (where "Android devices" is the only linkified text) is just confusing at first glance, since it intuitively feels like a linkified term "Android devices" in the middle of a sentence will just take you to a list of devices that fall under that term, or a definition of the term, or something like that.
But anyway, if that change would result in a substantial burden for our localizers -- and it sounds like it might -- then feel free to wontfix. I agree that the benefit here is marginal. This is more of a papercut than a full-on discoverability issue.
I think we can at least keep this issue open. If a time comes in the near future when we need to make more wholesale string updates to this page, then we can bundle this issue in along with those.