See #22

Implementation of initial apps view as per mockups:
https://redpen.io/p/fg6854135873dfca94

Because the publishing flow will not be implemented until a future SOW, the only section that is relevant for this milestone is, "Apps I've Installed".

See #23

Need to define how user will choose colors.

Bricks applied to:
• Text (changing text color)
• Header (changing header color)

Minimum Requirement:
• Ability to select from pre-defined palette of colors

Can haz labelz?

Proposal (Please Comment)

Background

We need a basic CLI tool that will create an appcache manifest for a given directory. The tool should walk the directory tree to form a complete manifest and then generate a checksum comment to force expire existing caches.

Basic Use

[sudo] npm install -g appcachify

appcachify ./my/build/dir

CACHE MANIFEST
# Checksum 68e2b731ac1486dff1a2c583eb7c4780

index.html
index.js

./icons/activity.svg
./icons/apps.svg
./icons/discover.svg
./icons/me.svg

./styles/common.css
./styles/normalize.css

NETWORK:
*
http://*
https://*

Options

--fallback [string] Specify fallback asset(s)
--network [string] Specify network location(s)
--hidden Includes hidden files (like .DS_Store, .gitignore, etc.)

https://bugzilla.mozilla.org/show_bug.cgi?id=1046752

Will need to use UA as to handle offline events tracking via the measurement protocol:
https://developers.google.com/analytics/devguides/collection/protocol/v1/devguide
https://developers.google.com/analytics/devguides/collection/protocol/v1/reference

Add view transitions via the v-transition API:
http://vuejs.org/guide/transitions.html

Document the places in which push notifications will be used throughout the app and how they relate to the core user experience as both an author (productive) and user (consumptive).

Implementation of the first time use experience screens as per mockups:
https://redpen.io/p/fg6854135873dfca94

We're using js routing, push state, etc., which means we can't refresh a page, or go directly to urls like http://localhost:8080/apps. Let's build a tiny node app to point (properly MIME'd) requests at index.html.

Makes created within the application should be installed local to the app and only optionly added to the home-screen. This requires quite a few design changes, but ultimately simplifies quite a bit of the technical implementation as well as makes the process of porting to Android / iOS much more straightforward.

Need to design a simple empty state for the "Apps" section that guides users towards "Discover" if they have not installed or made any apps yet.

Scenario: while discovering content, user finds something shocking. How do they tell us about it?

http://mozilla.github.io/makerstrap/demo/#/

The Marketplace team may have country specific processes in place already. General question is whether the review/takedown/DMCA process is roughly right.

Design example application to be used for Data Collection. Possible personas: teacher, aid worker.

See existing workflows in Webmaker:
https://github.com/mozilla/node-webmaker-i18n

Design a simple profile screen

MUP (Minimum Useful Product) Requirements for the Hello World prototype (Due: Friday, August 8th)
• Ability to view name
• Ability to view location
• Ability to add/edit name
• Ability to add/edit location

Requirements for profile page beyond Hello World:
• Ability to view profile image
• Ability to add/edit profile image (profile image could be auto-generated avatar)
• List of apps the user has created
• Option to add occupation/short bio

Edit mode compliment to the player view. See:
#43
https://redpen.io/p/fg6854135873dfca94

We are leaning towards hosted, but are there any "gotchas" that could necessitate a packaged / privileged application. Possibilities: push notifications, device access, etc.

Initial sketches:

Top navigation bar that supports optional "back" button for window.history.back();. See:
https://redpen.io/zrbe1c8207d37fae5f

Since we need to compile Less as well, let's do this

The architecture suggested by @andreasgal (as transcribed by me) is to make a thin, hardened packaged app, with minimal UI apart from maybe a splash screen, whose job is to load the last-downloaded version of the app assets and start the app, and start async worker threads to fetch any newer version of the app. Minimally, the app will then update on next start-after-kill, assuming the new version of the app has been completely downloaded. In the future, the app could offer "A new version of the app is available, want to reload?" .

The advantages from this approach are:

a) we can update the content, UI, etc. just by pushing a new version of those assets to a (versioned) URL, out of sync with the update/release schedule of the packaged app.

b) the packaged app + initial version of the hosted-bits can be reviewed whenever the operator or whoever needs to decide whether to pre-install the app, and fixes etc. can happen after that.

c) this is a generic mechanism which many other apps could benefit from.

d) if we want to allow for a no-network-hit initial use, the build script can pre-load the indexeddb DB with the version of the hosted apps available at build time.

The primary reason for having the pre-installed app be privileged is so that if we need the app to be whitelisted or have elevated privileges (e.g. for FxA auth), that can happen at that layer of app origin.

@thisandagain and I were talking about a wrapper around XHR that was designed to deal with network challenges (connections dropping, low bandwidth, etc). This would be useful here.

Other notes:

• Downloaded assets should be stored in IndexedDB, along w/ any state representing the state of the upgrade.
• Once version N+1 has been downloaded, version N-1 should be removed from the local storage.

As agal pointed out, the code in this shim isn't huge, but it has to be solid. We should spec it out soon.

Design example application to be used for the sharing of content (Blog). Possible personas: citizen journalist, community organizer.

Redesign of navigation to accommodate bricks that make use of persistent storage such as forms and messaging. This includes:

• In-app navigation for non-owners (signed-in)
• In-app navigation for non-owners (not signed-in)
• In-app navigation for owners

Implementation of initial discover view as per mockups:
https://redpen.io/p/fg6854135873dfca94

This first "hello world" implementation of the discover view will be based on static placeholder personas that are embedded into the application itself (as to work offline).

Design example application to be used for commerce. Possible personas: vendors, couriers, VARs.

Implementation of initial profile view as per mockups:
https://redpen.io/p/fg6854135873dfca94

This initial execution is local to the application (no integration with authentication provider) until the we hit the "publishing" scope of work.

Will the fix for issue https://bugzilla.mozilla.org/show_bug.cgi?id=778277 land prior to our scheduled release date?

What is the established tooling and approach for i18n in FFOS?

Design example application to be used for interest-driven communities (forums / BB). Possible personas: community organizer, youth.

When a link is shared w/ someone, it will be an https:// URL -- to what? What happens when the recipient clicks on that link in the following scenarios:

• recipient has a FirefoxOS phone with the appmaker app installed
• recipient has an Android phone w/ the appmaker app installed
• recipient has a FFOS/android phone w/o the app installed
• recipient is on iOS
• recipient is on a desktop computer

This is particularly important to get right given that the sharing messages are the 'viral' vector for the app.

Leaning towards 1-App as per Android / iOS

Need to design the header brick and how it will be editable.

Minimum Requirements for "Hello World":
• Ability to edit name of app (Header name = app name)
• Ability to change color of the header

Other Requirements:
• Ability to change color of app name text in header
• Ability to change font of app name text in header
• Ability to change background color of entire app

View that loads an application JSON blob and renders it using bricks that are local to the application

Bricks for this first SOW:
#22
#23

Tabbed navigation component that switches between views as per:
https://redpen.io/cge8491250a40dfa03

Explore a design for the publishing flow that is non-linear and centered around the customization of pre-populated (derived and randomized) choices. For example, generate an icon, name, and location (?) for the user and allow them to change it vs. forcing them to embark on a long linear flow. This should help reduce friction while also providing a meaningful context for the information that we are requesting.

(cc @mhanratty @xmatthewx @iamjessklein)

https://intranet.mozilla.org/Program_Management/Firefox_OS/Devices#FxOS_devices_specification

Attaching to the Design milestone, but ok to push back to the work week if needed for scheduling.

Store user location state via IndexedDB and restore on app launch via the page.js API.