Apps in the Cloud will provide a list of apps and we need a Firefox dashboard that will display your installed and available apps. The dashboard needs to be able to compare your installed apps to the list of all of your apps and make it obvious which ones are installed on your current machine and which ones are not installed on this machine. Clicking a not installed on this machine app should install it.

This sounds kind of similar to bug 702363, though that work is not quite as comprehensive and meant to be temporary, AIUI.

Gavin, thanks for linking that up. We need to decide which one to pursue for kilimanjaro.

An interesting point that came out of a UX discussion for this area was that the "critical path" for what a user may determine to be a dashboard is their native apps themselves on the native device. In other words, this refers to the actual native machine desktop shortcuts on Windows or apps in the applications directory on Mac. In that meeting, an open question still exists on whether the critical path includes a firefox dashboard with apps, as we have yet to find an appropriate use case for that. I almost wonder if an implementation approach for AITC front-end would be something like the following, if we deem the native machine shortcuts as the dashboard: 1. I login into the browser 2. Select Sync Apps Now 3. All apps not installed on the native machine are installed to the user's machine This follows a pull philosophy for consistency of apps. This is up to debate though, as there's UX open questions on what the user sees value for in AITC.

In response to comment #3: this bug more fits bug 746386 for discovery and re-engagement of apps. This work is being done by using persona.org and looking at how to integrate it into the new tab. See bug 748962. The more likely place a user will go to find apps in the Kilimanjaro timeframe is either their native desktop to find the apps they installed and launch them or they would head back to the Marketplace to see the apps they installed. +dils for more info if necessary.

(In reply to Jennifer Arguello :ticachica from comment #4) > In response to comment #3: this bug more fits bug 746386 for discovery and > re-engagement of apps. This work is being done by using persona.org and > looking at how to integrate it into the new tab. See bug 748962. Err...I don't think that makes sense? There was a separate comment in the past that described that as not being a good idea at all involving linking to a remote dashboard within firefox directly (https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c33). I'd suggest re-thinking this, as the point made there is valid. > > The more likely place a user will go to find apps in the Kilimanjaro > timeframe is either their native desktop to find the apps they installed > and launch them or they would head back to the Marketplace to see the apps > they installed. > > +dils for more info if necessary. I agree on the first point, disagree on the second. I don't think marketplace is a place users are highly likely to go to look at their history (they will do it, but probably less likely). Marketplace is likely a place where a user is desiring find a particular app and get it installed on their machine (the critical path) for a consumer.

(In reply to Jason Smith [:jsmith] from comment #5) > (In reply to Jennifer Arguello :ticachica from comment #4) > > In response to comment #3: this bug more fits bug 746386 for discovery and > > re-engagement of apps. This work is being done by using persona.org and > > looking at how to integrate it into the new tab. See bug 748962. > > Err...I don't think that makes sense? There was a separate comment in the > past that described that as not being a good idea at all involving linking > to a remote dashboard within firefox directly > (https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c33). I'd suggest > re-thinking this, as the point made there is valid. > > > re: https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c33 was made in regards to an online only dashboard. If you see in https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c38 I agree and say the requirement is that the dashboard has to work offline. So we're not disagreeing here. The dashboard has to work offline. > > The more likely place a user will go to find apps in the Kilimanjaro > > timeframe is either their native desktop to find the apps they installed > > and launch them or they would head back to the Marketplace to see the apps > > they installed. > > > > +dils for more info if necessary. > > I agree on the first point, disagree on the second. I don't think > marketplace is a place users are highly likely to go to look at their > history (they will do it, but probably less likely). Marketplace is likely a > place where a user is desiring find a particular app and get it installed on > their machine (the critical path) for a consumer. I do not understand. The marketplace is the only place a user can go to look at their history at the time of Kilimanjaro's release. Even if there is an HTML5 dashboard, it will not show purchase history. The reason I am refuting that this dashboard will be used as is described in comment #3 is because that use case does not exist yet. I do not know the whole log into the browser flow. https://bugzilla.mozilla.org/show_bug.cgi?id=749070#c1 asks for a new bug for the discovery of the ID enabled services. It would be helpful to flesh out this discovery flow because it will help inform what needs to be done in this bug. If the bug with this flow is out there would someone put it in here please?

Just want to say if the user behavior is not clear we have a great UR team ready to help us gather more info.

(In reply to Jennifer Arguello :ticachica from comment #6) > re: https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c33 was made in > regards to an online only dashboard. If you see in > https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c38 I agree and say the > requirement is that the dashboard has to work offline. So we're not > disagreeing here. The dashboard has to work offline. I'd like to add that hosting a dashboard at a URL like myapps or persona is not synonymous with "won't work offline". We're trying to convince developers to build apps that work offline for our marketplace based on this fact, we should eat our own dogfood! What it does mean, though, is that the user has to be online the very first time they visit the dashboard on any new machine (it's the equivalent of downloading and installing the dashboard "app"). This is very likely because visiting the dashboard implies that the user might have just bought an app, which you can't do offline. We also rely on "online" content in the current Firefox home page, with the optimization that if you're offline when you visit about:home, we simply load the previously cached version; something we could certainly do for the dashboard as well. However, if this behavior is not acceptable (since it's not 100% bullet proof), I am totally on board with having an about:apps fallback that is always guaranteed to work offline 100% of the time. An online dashboard has it's own advantages though, it might be best to simply have both.

(In reply to Jennifer Arguello :ticachica from comment #6) > (In reply to Jason Smith [:jsmith] from comment #5) > > (In reply to Jennifer Arguello :ticachica from comment #4) > > > In response to comment #3: this bug more fits bug 746386 for discovery and > > > re-engagement of apps. This work is being done by using persona.org and > > > looking at how to integrate it into the new tab. See bug 748962. > > > > Err...I don't think that makes sense? There was a separate comment in the > > past that described that as not being a good idea at all involving linking > > to a remote dashboard within firefox directly > > (https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c33). I'd suggest > > re-thinking this, as the point made there is valid. > > > > > > re: https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c33 was made in > regards to an online only dashboard. If you see in > https://bugzilla.mozilla.org/show_bug.cgi?id=702363#c38 I agree and say the > requirement is that the dashboard has to work offline. So we're not > disagreeing here. The dashboard has to work offline. > > > > The more likely place a user will go to find apps in the Kilimanjaro > > > timeframe is either their native desktop to find the apps they installed > > > and launch them or they would head back to the Marketplace to see the apps > > > they installed. > > > > > > +dils for more info if necessary. > > > > I agree on the first point, disagree on the second. I don't think > > marketplace is a place users are highly likely to go to look at their > > history (they will do it, but probably less likely). Marketplace is likely a > > place where a user is desiring find a particular app and get it installed on > > their machine (the critical path) for a consumer. > > I do not understand. The marketplace is the only place a user can go to look > at their history at the time of Kilimanjaro's release. Even if there is an > HTML5 dashboard, it will not show purchase history. > App management history is exists in the marketplace (for apps purchased there) and the mgmt API. The use of this API on a dashboard supercedes the need to use the marketplace purchase history as the primary use case, as the mgmt API covers more use cases and integrates more seamlessly into a dashboard design (that's what done previously on myapps.mozillalabs.com). I also still don't see why a user would go to purchase history for their dashboard (it feels awkward). My suggestion - I'd propose a couple of ideas and flows, usability test it, and re-evaluate. The one thing I don't understand is we say "need a firefox dashboard for apps in the cloud" - why couldn't just reuse the proposed new tab page also as the dashboard? Redundancy to promote apps is good, but too much bloat could create confusion. As for direct integration into persona.org, before that idea goes forward, I'd run that by someone on the firefox desktop UX team to see what their opinion. Gavin - Who's someone from the firefox desktop UX team that would be good to answer a UX question such as this? (In reply to Jennifer Arguello :ticachica from comment #7) > Just want to say if the user behavior is not clear we have a great UR team > ready to help us gather more info. That would be very helpful. Flagging urwanted. (In reply to Anant Narayanan [:anant] from comment #8) > However, if this behavior is not acceptable (since it's not 100% bullet > proof), I am totally on board with having an about:apps fallback that is > always guaranteed to work offline 100% of the time. An online dashboard has > it's own advantages though, it might be best to simply have both. Hmm, I'd be curious to analyze the tradeoffs a bit more between having a local dashboard built into firefox vs. an online dashboard we integrate into that support offline mode. I'd be curious to hear someone's opinion from the desktop firefox team on this though.

To bring a discussion point brought up on a separate bug: We need to make sure that the user clearly understands where the apps are coming from when presenting this dashboard. Does app 1 come from persona 1? persona 2? What about app 2? Users need to understand where their data is deriving from and when and how they are modifying it. The use case being thought about here is when a user has managing multiple apps across multiple personas. The URWanted flag though still makes sense here btw - I think we need to make sure we understand how users discover apps stored in the cloud, how do they know when they are modifying them, how do they know which app is tied to which persona, etc. The discoverability piece addressed earlier I'm still concerned about, given that the definition of how a user discovers persona.org from firefox I don't think has been addressed if that intends to be the AITC location. New tab implementation underway (which I think UX is working on) could also affect this decision as well.

Flipping the keyword - realized the points I'm bringing up are UX questions, not UR questions.

How does this relate to the Chrome App Launcher?