Closed Bug 741472 Opened 10 years ago Closed 9 years ago

Make about:apps a menu item in Fennec Native

Categories

(Firefox for Android Graveyard :: Web Apps (PWAs), defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox16 verified)

VERIFIED FIXED
Firefox 16
Tracking Status
firefox16 --- verified

People

(Reporter: jsmith, Assigned: wesj)

Details

Attachments

(1 file, 3 obsolete files)

Fennec native currently does not provide any context to the user that about:apps even exists, especially during installation of apps. Without knowledge of about:apps, users will not know some of app features we will be providing, such as the about:apps dashboard, adding to homescreen, etc. We need to provide a more clearer connection between the fennec native experience to the apps experience, including about:apps, in order to encourage users to use this feature. UX needs to provide feedback to determine the best workflow.

Device: Samsung Galaxy Nexus
OS: Android 4.02
Build: Fennec Native Nightly
Whiteboard: [WebRT]
Component: General → Web Apps
Assignee: nobody → bdils.mozilla
QA Contact: general → web-apps
Whiteboard: [WebRT]
Blocks: 738546
No longer blocks: 738546
Whiteboard: [marketplace-beta?]
Whiteboard: [marketplace-beta?]
Ideas to consider here:

- Include it as a permanent bookmark (same as about:home being a permanent bookmark)
- Upon clicking the location bar, about:apps is listed near the top (same as about:home) for top sites and/or bookmarks
- Include a link to about:apps on about:home
- In the persistent menu, include an option called "Your Apps" that redirects you to about:apps
Whiteboard: [Phase1]
Nominating for k9o, as this relates to discoverability of your web apps on the android web runtime. This bug is similar to equilvalent user story for desktop firefox in relation to apps discoverability (https://wiki.mozilla.org/Kilimanjaro/ProductDraft#Desktop_Firefox_will_help_you_discover_Firefox_mobile.2C_apps_and_ID.).
blocking-kilimanjaro: --- → ?
Unless something changes, this is not a user facing feature.
blocking-kilimanjaro: ? → -
To add more information to this bug. about:apps was built as a temporary place for developers to work with apps as they built them, tested them, etc.   The Kilimanjaro user story for desktop (I need to add the bug to this bug) has a user going to the "Purchase History" in the Marketplace to see all their apps and then there will be a link in that page to go to the global dashboard, which could be about:apps or another landing page like persona.org. 

Per the engineering status meeting this morning the UX for mobile has not been worked out completely. So this bug will stay on the radar as something that needs to be ironed out.
(In reply to Jennifer Arguello :ticachica from comment #4)
> To add more information to this bug. about:apps was built as a temporary
> place for developers to work with apps as they built them, tested them, etc.
> The Kilimanjaro user story for desktop (I need to add the bug to this bug)
> has a user going to the "Purchase History" in the Marketplace to see all
> their apps and then there will be a link in that page to go to the global
> dashboard, which could be about:apps or another landing page like
> persona.org. 

I don't think that's correct - see https://wiki.mozilla.org/Kilimanjaro/ProductDraft#Desktop_Firefox_will_help_you_discover_Firefox_mobile.2C_apps_and_ID. There's no mention of persona.org or purchase history in the marketplace at all in that draft.

> 
> Per the engineering status meeting this morning the UX for mobile has not
> been worked out completely. So this bug will stay on the radar as something
> that needs to be ironed out.


Right. We need to iron this out, especially in reference to k9o UX for android web runtime.
Bug blocked on figuring out the apps management UX.
Keywords: uiwanted
I think I have a simple proposal to fix this problem - let's add a reference on about:home to about:apps that stands out enough that a user would be interested in enough to click this.
Sounds like this should be a blocker for a 1st release to make a decision here if about:apps intends to be the location of your apps for now. This problem could be solved probably by a combination of comment 7 plus listing about:apps on a top sites page when typing a URL in fennec native (there's other ideas to think about here though maybe, so leaving uiwanted).
Whiteboard: [Phase1]
Happy to add as a default bookmark as well.
(In reply to Wesley Johnston (:wesj) from comment #9)
> Happy to add as a default bookmark as well.

That works. Modifying the bug as such that, as its not a bad solution for now. I have a followup idea to add this to about:home, but I'll track that in a separate bug.
Summary: Fennec Native Provides No Context to Send the User to about:apps unless they explicit know it from documentation → Make about:apps a default bookmark in Fennec Native
Keywords: uiwanted
Assignee: bdils.mozilla → nobody
Component: Web Apps → General
QA Contact: web-apps → general
Attached patch Patch (obsolete) — Splinter Review
Asking for review, but this shouldn't land until we're ready for it to be exposed to a "larger" audience I guess.
Assignee: nobody → wjohnston
Attachment #634663 - Flags: review?(mark.finkle)
Comment on attachment 634663 [details] [diff] [review]
Patch

You have some DoorHangerPopup mixed in with this patch
Attached patch Patch (obsolete) — Splinter Review
Whoops. that's not the right link. That's just what's convenient to me right now. :)

I'm actually not sure how I feel about having this link in here. We often try to trick people into thinking these things (Download, Addons) are not "pages". This does the opposite.
Attachment #634663 - Attachment is obsolete: true
Attachment #634663 - Flags: review?(mark.finkle)
Attachment #634664 - Flags: review?(mark.finkle)
Attached patch Patch (obsolete) — Splinter Review
Grr. Collision.
Attachment #634664 - Attachment is obsolete: true
Attachment #634664 - Flags: review?(mark.finkle)
Attachment #634665 - Flags: review?(mark.finkle)
Is a bookmark really appropriate for in-product functionality? It seems like there's potential for accidental removal, possible discoverability issue after a bookmark migration, etc.
(In reply to Aaron Train [:aaronmt] from comment #15)
> Is a bookmark really appropriate for in-product functionality? It seems like
> there's potential for accidental removal, possible discoverability issue
> after a bookmark migration, etc.

What other ideas could work then? Would built-in chrome to access one's apps be a better approach? Or would throwing out the default bookmark be better?

Was trying to figure out some way to increase discoverability of about:apps.
(In reply to Jason Smith [:jsmith] from comment #16)
> (In reply to Aaron Train [:aaronmt] from comment #15)
> What other ideas could work then? Would built-in chrome to access one's apps
> be a better approach? Or would throwing out the default bookmark be better?
> 
> Was trying to figure out some way to increase discoverability of about:apps.

Well, your comment #1 suggests a menu item and I don't see that ruled out here in this bug. Wouldn't that work? (Thinking out-loud, for future use, maybe 'Add-ons' can become 'Add-ons and Web Apps' and have a tabbed interface switching between 'Add-ons' and 'Web Apps'.
(In reply to Aaron Train [:aaronmt] from comment #17)
> (In reply to Jason Smith [:jsmith] from comment #16)
> > (In reply to Aaron Train [:aaronmt] from comment #15)
> > What other ideas could work then? Would built-in chrome to access one's apps
> > be a better approach? Or would throwing out the default bookmark be better?
> > 
> > Was trying to figure out some way to increase discoverability of about:apps.
> 
> Well, your comment #1 suggests a menu item and I don't see that ruled out
> here in this bug. Wouldn't that work? (Thinking out-loud, for future use,
> maybe 'Add-ons' can become 'Add-ons and Web Apps' and have a tabbed
> interface switching between 'Add-ons' and 'Web Apps'.

Technically that works also, although I'm wondering how much work that would be.
Mark - What are you thoughts on this?

I think Aaron's points are valid, although would it necessarily hurt to not add this as a default bookmark?
(In reply to Jason Smith [:jsmith] from comment #19)
> Mark - What are you thoughts on this?
> 
> I think Aaron's points are valid, although would it necessarily hurt to not
> add this as a default bookmark?

Aaron's right with respect to about:addons ("Add-ons" menu) and about:downloads ("Downloads" menu). I think about:apps is closer to those in-content UI's than to about:home (has a bookmark). Let's get a patch for a menu and get Ian Barlow to weigh in as well.
Comment on attachment 634665 [details] [diff] [review]
Patch

Putting this patch on hold and moving ahead with a menu instead.
Attachment #634665 - Flags: review?(mark.finkle) → review-
Summary: Make about:apps a default bookmark in Fennec Native → Make about:apps a menu item in Fennec Native
> Technically that works also, although I'm wondering how much work that would be.

For future reference, Super easy!

Our menu is just too full as is. This will not help it.
Attached patch PatchSplinter Review
Adds a menu item labeled "Apps" to match the "Your Apps" strings in about:apps.
Attachment #634665 - Attachment is obsolete: true
Attachment #635097 - Flags: review?(mark.finkle)
Attachment #635097 - Flags: review?(mark.finkle) → review+
Component: General → Web Apps
QA Contact: general → web-apps
Flags: in-moztrap?(aaron.train)
Whiteboard: [qa+]
Re-noming for k9o - this looks like the direction we're heading for apps management UX on Android. Although that's subject to the opinion of the product team.
blocking-kilimanjaro: - → ?
https://hg.mozilla.org/mozilla-central/rev/e4f82be09302
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 16
https://moztrap.mozilla.org/manage/case/699/
Status: RESOLVED → VERIFIED
blocking-kilimanjaro: ? → ---
Flags: in-moztrap?(aaron.train) → in-moztrap+
No longer blocks: Blocking-FFA-WebRT1+
Whiteboard: [qa+]
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.