mozilla / webmaker-android Goto Github PK
View Code? Open in Web Editor NEWWebmaker for Android
Home Page: https://play.google.com/store/apps/details?id=org.mozilla.webmaker
License: Mozilla Public License 2.0
Webmaker for Android
Home Page: https://play.google.com/store/apps/details?id=org.mozilla.webmaker
License: Mozilla Public License 2.0
Design example application to be used for interest-driven communities (forums / BB). Possible personas: community organizer, youth.
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
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:
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
Edit mode compliment to the player view. See:
#43
https://redpen.io/p/fg6854135873dfca94
Design example application to be used for commerce. Possible personas: vendors, couriers, VARs.
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.
[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://*
--fallback [string] Specify fallback asset(s)
--network [string] Specify network location(s)
--hidden Includes hidden files (like .DS_Store, .gitignore, etc.)
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
Implementation of the first time use experience screens as per mockups:
https://redpen.io/p/fg6854135873dfca94
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
We are leaning towards hosted, but are there any "gotchas" that could necessitate a packaged / privileged application. Possibilities: push notifications, device access, etc.
Can haz labelz?
Redesign of navigation to accommodate bricks that make use of persistent storage such as forms and messaging. This includes:
Attaching to the Design milestone, but ok to push back to the work week if needed for scheduling.
Top navigation bar that supports optional "back" button for window.history.back();
. See:
https://redpen.io/zrbe1c8207d37fae5f
What is the established tooling and approach for i18n in FFOS?
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).
Will the fix for issue https://bugzilla.mozilla.org/show_bug.cgi?id=778277 land prior to our scheduled release date?
Scenario: while discovering content, user finds something shocking. How do they tell us about it?
Tabbed navigation component that switches between views as per:
https://redpen.io/cge8491250a40dfa03
Since we need to compile Less as well, let's do this
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.
Add view transitions via the v-transition
API:
http://vuejs.org/guide/transitions.html
See #23
Store user location state via IndexedDB and restore on app launch via the page.js
API.
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".
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
.
The Marketplace team may have country specific processes in place already. General question is whether the review/takedown/DMCA process is roughly right.
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).
See #22
Design example application to be used for Data Collection. Possible personas: teacher, aid worker.
Design example application to be used for the sharing of content (Blog). Possible personas: citizen journalist, community organizer.
See existing workflows in Webmaker:
https://github.com/mozilla/node-webmaker-i18n
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.
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.
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:
As agal pointed out, the code in this shim isn't huge, but it has to be solid. We should spec it out soon.
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.