Closed Bug 921926 Opened 11 years ago Closed 3 years ago

PageAction UI evolution


(Firefox for Android Graveyard :: General, defect, P5)



(Not tracked)



(Reporter: rnewman, Unassigned)



(Keywords: uiwanted)

Follow-on from Bug 899376.

Firstly, minor note: we should always display an informative icon, never the Android icon. (That's my "2b" in that bug.)  If we don't have an informative icon, don't show a page action.

Secondly, the broader thrust: in order for this feature to be discoverable and non-scary ("what happens if I tap this? maybe it'll break something!"), we need to evolve the UI.


* Put it in the menu alongside Share and Save -- keep the URL bar for page-related things that will stay within Firefox. (I also see the counter-argument for this -- pure ideation here!)

* Combine it with Share.

* More fully develop the concept of "things you need to know or can do with this page", which we currently (on desktop and mobile) hackily throw together with doorhangers and URL bar icons:

  * This page isn't secure; add an exception?
  * This page uses plugins; turn them on?
  * This page uses mixed content; block it?
  * This page looks like an article; read it in Reader Mode?
  * >> This page can be opened by Jumping Dog; open it?
  * This tab is making noise. Mute it?
  * This page started a download…
  * …

There are a bunch of ways we can make these available: a "flipside" (iOS-style); a single 'info' doorhanger, etc.

The value of doing this is that once a user discovers or is trained that this place exists, we have the real estate to add things to it without having to re-teach.

And it might solve future difficulties around per-site prefs, control of media functionality, connecting to task continuity apps, whatever.

There are probably plenty of other options -- Ian?
TBH, I think that the current UI (if it always worked right, which Samsung's video player is working to fight), is fairly inviting most of the time. "Hey I wonder what that means?" Tap it. "Now I know!". But we did talk at one point about showing the app logo here if there was only one app that could open the url. We've also talked about using some sort of arrow that was a bit more self explanatory.

Just my thoughts, we intentionally kept this out of menus. They're cluttered and this item would only show up randomly on certain pages. i.e. Users would likely not find it. I wouldn't mind moving security or some other things that might fall under "page actions" to the right side of the urlbar though (site specific prefs might be nice, but also would probably be annoying when they're seldom used, and I think might better just fit in our normal Preferences screen). Doorhanger could certainly point to this area of the screen...
I agree that we need a new "system" for teaching users about features. I don't think we can use existing systems:
* Doorhangers are not designed to teach. They are designed to be unobtrusive prompts. They might succeed at that, but I don't think they are the best choice for "first-time" teaching prompts
* Menus are too cluttered as it is and they still require the user explore.
* Toasts don't associate the text with the UI well enough

Maybe we could use:
* Tweak the doorhanger code to be a generic arrow-popup. Chrome seems to use that (or did) for some first-run discovery aids.
* Use a semi-transparent full screen overlay that has lots of space for images and text, associated with the UI feature.
Keywords: uiwanted
I'm hearing 3 different conversations in this bug, all very important. 

1. Kill the "Placeholder" PageAction icon.
2. Define a clearer purpose for what PageActions are for.
3. Design a strategy / UI framework for talking to our users about new features / advanced tips.


1. I think we should just do this. If no icon is available, don't show anything. If multiple options are available, show the dropdown arrow from the original design spec.

2. I look at this as (perhaps incorrectly) the "Open In..." prompt. Open in Reader. Open in Google Maps. Open in CatMail. etc. I don't know if that helps, but it could be one way of making its purpose a little easier to understand.

3. I 100% want this, and unfortunately the UX work here has been deprioritized for other projects over the last little while. Bits and pieces are beginning to emerge (the Search tip in settings, the empty Reading List tip in the Awesomescreen), but we still need a high level set of guidelines to help us decide how, when, and with what frequency we should be interrupting a user's task to tell them something about how to use Firefox. Let's try to find a place for this in our nearer term roadmap if we can.
To clarify ian, are you suggesting

1.) If there's only one app available for this url, show the app icon. We need a patch from bug 914740.
2.) If there's more than one app available, show a dropdown arrow. When its clicked show a list of apps?

We already do something "like" 2 right now, although its through this android icon and an intent chooser dialog (that I'm rewriting right now :) ).
Wes, yep that's what I meant thanks
Review time … how much of this bug 921926 is superseded by other bugs?
Re-triaging per

Needinfo :susheel if you think this bug should be re-triaged.
Priority: -- → P5
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly]( an issue can be reported at the [Fenix GitHub project]( If you want to discuss your report please use [Mozilla's chat]( server and join the [#fenix]( channel.
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.