Status & Team

See: B2G - Project tracking spreadsheet

Install

Background

Apps can come from two sources:

• Trusted
• Untrusted

Requirements

• User can identify source URL
• User can review app permissions
• User can view app icon
• User can view app author
• User can initiate install
• User can track installation progress

Design Spec

For the latest UX specifications, please visit https://mozilla.box.com/system and/or https://mozilla.box.com/applications

Permissions

. . .

Management

Requirements

• User can organize installed apps
• User can delete installed apps
• User can reinstall apps
• User can review & edit app permissions
• User can review & edit app notification settings
• User can review app power consumption
• User can review app data consumption
• User can edit app settings
• User can specify default apps for actions (eg: Gallery is default app for adding image attachments)
• User can differentiate between installed apps, and installed bookmarks.\
• User can review app update history
• User can rollback app updates
• User can clear app cache data

Errors

Design Specs

Interaction

• Gaia UX Errors, v1 (PDF): Josh, Sunday Aug 23
• Process crash animation (MOV): Josh, Monday July 23

Updates

Background

In traditional mobile OS app paradigms, apps live on the device, and _may_ have a remote component. On B2G, it's reversed. Apps live on the web, and _may_ have local component. The only data they are _required_ to store locally are a manifest and icon. Taken to it's extreme, in this model the mobile device becomes a mere window on an external world, and icons are akin to bookmarks: pointers to an external location.

This new technological architecture presents opportunities to rethink existing mobile app paradigms. Updates are one example. What is "updating" when apps are inherently remote? Do we still require user authorization to update, or do we follow a more web-centric approach, and update the user's local cache without their explicit permission? How do we marry this web-centric approach with the mobile context (user sovereignty, app economic model, etc)?

Here are some models for application updates:

• Require user to manually apply. Inform user that update is available, and make it easy to apply.
  • Force immediate update (eg: some modern video game systems require user to apply updates immediately before they can use device, and only allow user to "apply now" or "shutdown".
  • Update later. This is the approach most mobile OS take, wherein the user is informed of an available update in some fashion, and it is left to their own discretion when (if ever!) to update.
• Auto update in background
  • The OS quietly pulls down an update in the background. Could be subjected to certain conditions (eg: only download over wifi,

The appopriate policy may vary depending on the type of app:

• Offline-mode compatible?
• Large or small file size?
• A game, a utility, a media player?
• Purchased, rented, subscribed to?
• Frequently or rarely updated?
• Requires permissions?

Requirements

Baseline

• Apps can be kept up-to-date.
• User can review app update history
• User can rollback app updates

Potential models

The "manual update" model:

• User is made aware of update
• User can decline update ("Skip")
• User can defer update ("Remind me later")
• User can initiate update ("Update")
• User can review new permissions before install
• User can grant or deny new permissions on first run
• User is prompted when their installed app is out of sync, no longer support, etc.
• User can opt into "automatic updates"

The "automatic update" model:

• User can review installed updates
• User can specify conditions under which silent updates are allowed to occur:
  • Data connection
  • Battery conditions
  • Time of day
• User can grant or deny new permissions on first run

Uninstall

Requirements

• User can uninstall apps
• User can reinstall apps