Haida

[Vivien Nicolas]

Hello Gaia folks,

Remember this funny thread, a few months ago, about refactoring some of
our apps, splitting them into multiple web pages and using more
<iframe>s ? It has ended up into a pretty funny discussion!

It has been written with Haida in mind, but sadly at this time, the
Haida proposal was not very well communicated and most didn't know about
it. And still, many has discovered it during the Oslo work week (which
is still ongoing while I'm writing this).

For those of you that have not heard about it, or that have not seen it,
there is a very early stage prototype used to explore things, discover
blockers and do user testing located in the |content| branch on a github
repository - http://github.com/vingtetun/gaia. Most of the work have
been done by others but it lives here for historical purpose right now.
I encourage you to play with it and provide feedbacks. It's buggy, it's
flashy, but you may like it! If you don't patches are welcome!

Tonight some asked for a demo on Friday. Not sure it will happen but it
should be fairly trivial to convinced Etienne ;)

For those that does not have the chance to participate to this work
week, someone should volunteer to create a wiki page.


One of the goal of Haida is to take advantages of our webbish nature and
of the strenght of our implementation. Beside that there is also a new
navigation model, a revamped UI, an omniscient urlbar, new various
platform features, etc.

But honestly and this is how I tend to consider it, it is a milestone.
And some features like Nuwa, application async pan/zoom improvement, an
aggressive cache strategy, better devtools, ... are part of this milestone.

This milestone would slip onto 3 cycles, so basically 1.3, 1.4, 1.5
(~june 2014). It would also be huge if it can be demonstrated at MWC
next year (~February 2014).

To achieve that the current roadmap proposal that is beeing worked on
right now is intended is the following (and it is intended to be start
by next monday).

--------

Version 1.3:
- Left/Right edge gestures to switch apps.
- Better integration of the system app, the browser app and
homescreen bookmarks.
- Migrate bookmarks, smart collection, facebook contacts to datastore.
- Platform support for Shared Workers
- A revamped Window Manager
- Deeper e.me integration in the homescreen
- Apps refactoring to separate the application logic from the actual
output. This does not involved UI changes at that point, and the Tablet
work may benefit from this work for 1.4 if we commit to that.


Version 1.4:
- Apps refactoring to separate the application logic from the actual
output. This does not involved UI changes at that point, and the Tablet
work may benefit from this work for 1.4 if we commit to that.
- Omnipotent url bar to search into browser history, apps, bookmarks,
smart collection, contacts, sms, discoverable content, etc..
- Notifications will be dancing around. Could be an additional edge
gesture.
- Likely more UI changes for the unified bookmarks/browser.
- IndexedDB into Shared Worker. Maybe Datastore. Potentially device
storage as well.
- A revamped Task Manager
- Activate a few sheets where it makes sense in order to start having
some feedbacks about it.

Version 1.5:
- UI UI UI.
- Finalize apps.
- Enhanced replaceble lockscreen.
- Enhanced replaceble homescreen.
- More sheets enabled.
- Left/Right gestures to switch between sheets.
- Have fun and be proud.

--------

Many things does not appears in this roadmap, like all the features,
bugs, personal projects, many unknowns areas, ...
But those things should definitively be part of your backlogs. For
example if there is no 'apps refactoring for beeing sheets ready'
discussed into your planning session, it would be hard to achieve that.
Sometimes this is just a miscommunication issue, so don't hesitate to
raise your hand.

And if you think a better phone can be built and you want to be deeply
involved, please step up. We succeed at making a few phones, which is
incredible if you think about it, let's succeed at making a better phone
and let's ship it again.

Vivien.

[Josh Carpenter]

Hi everyone,

To provide a bit more background, Haida is what we're calling the next major version of the Firefox OS user experience. With v1 of FFOS we laid a foundation and showed the world that it was possible to build a smartphone on top of web technologies. With Haida our goal is to now blow the doors off. Why adopt the patterns of other platforms when we have our own DNA, and our own values? Why not instead create something uniquely, truly web? That's the high level goal of Haida.

Haida will effect most of the FFOS operating system, but areas of heaviest focus will be:
Interface (interaction and visual design)
Content (content model, discovery, consumption)
Customization (for partners and users)
Lots more details to come (see #3 below). In the interim here are a few important points (to build on Vivien's outline):

1) Vingtetun/gaia is a subset of the full Haida vision. It includes work-in-progress prototypes of several interface elements, but it does not include updated apps, visual design, discovery improvements, etc. Those will come later.

2) It is still early and the pieces are shifting. We have many variations on the interaction models that we are prototyping and testing, for example. That means the build you grab on any given day may be very different the next. Iteration and testing is crucial to validating our hypotheses.

3) We're currently presenting Haida concepts to partners and Mozillians, and are keen to start posting details publicly as we nail things down. If you haven't seen anything on Haida yet and would like to, let our Product team (or for partners, your Moz contacts) know and we will be happy to make arrangements.

Thanks everyone. Let's drink some coffee. It's going to be a pretty awesome year! :)

—
Josh Carpenter
UX Lead, Firefox OS
Mozilla

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Julien Wajsberg]

Le 13/09/2013 03:50, Vivien Nicolas a écrit :
>
> For those of you that have not heard about it, or that have not seen
> it, there is a very early stage prototype used to explore things,
> discover blockers and do user testing located in the |content| branch
> on a github repository - http://github.com/vingtetun/gaia. Most of the
> work have been done by others but it lives here for historical purpose
> right now. I encourage you to play with it and provide feedbacks.
> It's buggy, it's flashy, but you may like it! If you don't patches are
> welcome!

https://github.com/vingtetun/gaia/compare/content

please have a look to the awesome work that they've done since July: 226
commits, *984 changed files* with *35,684 additions* and *27,683 deletions*.

--
Julien

[Alive]

Julien Wajsberg <jwaj...@mozilla.com> 於 2013/9/13 上午11:00 寫道：
>
> https://github.com/vingtetun/gaia/compare/content
>
> please have a look to the awesome work that they've done since July: 226
> commits, *984 changed files* with *35,684 additions* and *27,683 deletions*.

\O/
I hope I could rush window management rewrite like this way but indeed I couldn't. *sad*

> --
> Julien

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

--
Alive C. Kuo, Front-end Engineer, FirefoxOS, MoCo. Taiwan, Taipei office.
al...@mozilla.com

[Sergi Mansilla]

Impressive! Thanks for your effort :)

[Olav Nymoen]

I love the rocketbar!

But it's living in system app space .. Making homescreen pluggable on one
side, but moving the core of it into the system app sort of
makes it unpluggable again.


On Fri, Sep 13, 2013 at 11:25 AM, Sergi Mansilla
<sergi.m...@gmail.com>wrote:

[Fabrice Desre]

On 09/13/2013 03:18 AM, Olav Nymoen wrote:
> I love the rocketbar!

>
> But it's living in system app space .. Making homescreen pluggable on one
> side, but moving the core of it into the system app sort of
> makes it unpluggable again.

That's a valid concern. I would love to have as little ui as possible in
the system app itself.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Vivien Nicolas]

On 13/09/2013 12:43, Fabrice Desre wrote:
> On 09/13/2013 03:18 AM, Olav Nymoen wrote:
>> I love the rocketbar!
>
>>
>> But it's living in system app space .. Making homescreen pluggable on one
>> side, but moving the core of it into the system app sort of
>> makes it unpluggable again.
>
> That's a valid concern. I would love to have as little ui as possible in
> the system app itself.
>

One ultimate goal would be to have no UI at all in the system app. But
let's not be macho for the coming releases and let's still go forward.

> Fabrice
>

[Josh Carpenter]

Hi Olava,

We agree; we don't want system UI elements in the Home app. But we do want a prominent access point for RocketBar in the defaul Firefox OS home app. So our thinking is:
No actual RocketBar code lives in the Home app.
The RocketBar you see in the Home app is just a dumb link.
When tapped it invokes the actual system RocketBar via an "open RocketBar, please" API.
Branded Firefox OS releases may be required to include a link to RocketBar in their home apps, while third parties may not be. Emphasis on the "may", since this gets into complicated branding and product coherency issues. So if you wanted to create a home app for an elderly parent, for example, and you didn't want them accidentally triggering an advanced feature like RocketBar, you could leave out the link.
I of course defer to my engineering colleagues on specifics, but this is the high level thinking we've kicked around with Tim, Vivien et al.

—
Josh Carpenter
UX Lead, Firefox OS
Mozilla

On Sep 13, 2013, at 3:18 AM, Olav Nymoen <ol...@comoyo.com> wrote:

> I love the rocketbar!
>
> But it's living in system app space .. Making homescreen pluggable on one
> side, but moving the core of it into the system app sort of
> makes it unpluggable again.
>
>

> On Fri, Sep 13, 2013 at 11:25 AM, Sergi Mansilla
> <sergi.m...@gmail.com>wrote:
>

[Olav Nymoen]

Fully agree! The easy availability is what makes the rocketbar so awesome!

I looked a little into handling the rocketbar the same way the keyboard is
handled (a keyboard app put in an iframe in the system app dom and having
the lifecycle handled by the system app). I didn't get very far and I
assume having third party rocketbars give Paul Theriault even less chrome
to put security warnings in :) Still, any obvious blockers to such an
approach?

Olavio

On Thu, Sep 19, 2013 at 12:59 AM, Josh Carpenter <jcarp...@mozilla.com>wrote:

> Hi Olava,
>
> We agree; we don't want system UI elements in the Home app. But we do want
> a prominent access point for RocketBar in the defaul Firefox OS home app.
> So our thinking is:
>

> - No actual RocketBar code lives in the Home app.
> - The RocketBar you see in the Home app is just a dumb link.
> - When tapped it invokes the actual system RocketBar via an "open
> RocketBar, please" API.
> - Branded Firefox OS releases may be required to include a link to

> RocketBar in their home apps, while third parties may not be. Emphasis on
> the "may", since this gets into complicated branding and product coherency
> issues. So if you wanted to create a home app for an elderly parent, for
> example, and you didn't want them accidentally triggering an advanced
> feature like RocketBar, you could leave out the link.
>
> I of course defer to my engineering colleagues on specifics, but this is
> the high level thinking we've kicked around with Tim, Vivien et al.
>
> —
> Josh Carpenter
> UX Lead, Firefox OS
> Mozilla
>
> On Sep 13, 2013, at 3:18 AM, Olav Nymoen <ol...@comoyo.com> wrote:
>
> I love the rocketbar!
>
> But it's living in system app space .. Making homescreen pluggable on one
> side, but moving the core of it into the system app sort of
> makes it unpluggable again.
>
>
> On Fri, Sep 13, 2013 at 11:25 AM, Sergi Mansilla
> <sergi.m...@gmail.com>wrote:
>

[Ben Francis]

Note that the system app is not the same thing as the home app, the
Rocketbar would live in the system app, the home app gets loaded inside a
frame in the system app (as it always has) and can have a way to make the
Rocketbar appear.

I actually think that with cutomizable homescreens and lockscreens, the
Rocketbar should be the one thing that *isn't* customisable and is
recognisably Firefox OS across all (branded) devices.

Technically speaking we could eventually move the rocketbar UI into a
separate app/frame as well if the long term goal is to have no UI in the
system app. But for branded devices I think it would be nice to insist on a
consistent Rocketbar UX so that the Rocketbar is the one piece of
recognisable Firefox OS "chrome" you can always trust to be there.

Ben

[Andreas Gal]

For performance and responsiveness and memory reasons you definitely want to move the rocket bar and as much UI as possible out of the system app. Its already way too fat :)

Andreas

[James Burke]

On Thu, Sep 12, 2013 at 6:50 PM, Vivien Nicolas <vnic...@mozilla.com> wrote:
> One of the goal of Haida is to take advantages of our webbish nature and of
> the strenght of our implementation. Beside that there is also a new
> navigation model, a revamped UI, an omniscient urlbar, new various platform
> features, etc.

Thanks for sharing this. For those of us on the app development side,
I got the impression the move to sheets was coming more quickly,
particularly when I saw bugs like 922653 filed. That made me nervous,
as there is still a lot of uncertainty about the dev structure.

However, after re-reading this note's likely targets for each release
and talking to Josh at the Summit, the actual dev changes for sheets
seems to be a few trains in the future, particularly since more UX
work needs to go into how running sheets/apps are grouped for user
navigation.

Until there is more UX work to define some of those things, here are
some notes on some technology pieces that may worth investigating in
the meantime.

I do not expect that we should discuss these items further here on
this thread now, just want to plant some seeds for people doing the
technical investigation for Haida:

I would really like to see us do a deep dive into using Service
Workers[1], as I believe it will help improve a few things for us.
First, a quick summary of a Service Worker: think of it as a local
HTTP server/proxy server, but instead of using network connections, it
uses a JS event API to receive "requests" for resources. It is
currently specified as a shared worker too.

Possible uses for Service Workers in the context of Gaia:

1) For app startup, since the app gets a chance to run JS before any
HTML parsing is done (once the Service Worker is installed), it means
that we can blast in an optimized HTML that is specific to the startup
request. For email, this means we could serve HTML that already shows
the message list before any app wiring for user interaction is done.
This would be a nice, formal replacement for the cookie hack we use
now, and avoids browser content paints from getting in the way of app
startup.

2) Most of the examples for Service Workers are in the context of a
better AppCache, but it does specify that a "method" on the request is
supported. If we can be sure to get good POST method support in, this
could be a better way to support app startup triggers that pass data.
So, alert, notification and web activity startups of an app.

Right now in email, we need to check for
navigator.mozHasPendingMessage() to decide what startup path to take,
then wait for our listener on navigator.mozSetMessageHandler() to be
called to finish startup work.

If we knew from the data in the incoming request immediately what the
app trigger was, we could get optimized HTML returned much faster for
initial paint, and avoid some event loop passes that could contain
unhelpful paints.

If each of those app triggers came in a POST to the Service Worker, it
may mean that we do not need mozSetMessageHandler or
mozHasPendingMessage, and may affect how activities are done.

3) Make sure main thread JS can get a handle on the shared worker used
for the Service Worker. Then we could use the Service Worker for the
"model" cases that Vivien wanted shared workers to do.

While a Service Worker, and any shared worker, should expect to be as
stateless as possible, for email I can see us keeping a local
in-memory cache in the Service Worker for some things, like account
info, since we need it for startup cases anyway. Similar to memcached
uses in traditional web servers. So I would want to use the Service
Worker as the shared worker mentioned in previous Haida
communications.

4) Make sure the Service Worker has a postMessage channel to any
existing window that may be the target for the Service Worker request.
Also an indication if that window already has a page loaded. This
allows the worker the ability to just poke the existing window's HTML
to do a small DOM change instead of serve back a full HTML page.

In summary, go Service Workers!

Related to previous tech discussion about possibly using a separate
HTML page for each "sheet" or card in an app UI:

I expect that to be less feasible from a UX visualization perspective
(showing a long list of every sheet clouds inter-apps nav) and there
are many card navigations that are not strictly "forward" in a card
stack.

Additionally, it does not translate at all to other web platforms. So
the story for web app developers about developing for a common stack
is a much harder sell. Doing a page refresh in those other web
platforms degrades the experience there.

One selling point for the "one window/HTML page per card" was to
improve on memory cleanup. I would rather see work done on diagnostic
tools for those cases, as there are use cases like games, and how the
web containers on other platforms work, where identifying memory
problems for long running UI will be generally useful. The startup
cost for a new window object in the "page per card" approach seems
much more expensive that adding some HTML to an existing page too.

However, that technical exploration does bring out some important
characteristics that make sense to pursue generally, and speak to the
goal of keeping apps web-like:

1) Apps should support having a URL structure that allows addressing
any card in their flow. This is important for app triggers like
notifications, alerts, activities. By using the history API, it also
works well in traditional browser containers that could have the "back
button" in the browser chrome.

2) Be able to support an app UX flow that does not have an explicit
back button, but rather depends on on gestures for back/forward
navigation control.

3) Allow for multiple app windows, particularly for app startup
triggers like notifications, alerts, activities. Once the app window
starts up, it may use its own history API approach and HTML fragment
navigation in a given window (not a page refresh or new window per
card), but the app should not expect that there is only one app window
on the platform for its UI.

For some web platforms (like native iOS/Android wrappers), a single
app window may be the use case, but it may not be on others (Firefox
OS, traditional desktop web browsers). See Service Worker item 4 for
something useful for the app to determine what path to take across web
platforms.

So I would be interested to see some JS helper scripts around history
API and gesture-based transitions, as well as animation primitives for
card navigations, all that could be used in an app.

For apps that did want to explore a separate HTML page per card
though, Service Workers seem to help that case. I just expect it to be
harder dev approach to justify for people making web apps to deploy
across web platforms besides just Firefox OS.

The above pathways are the ones I want to investigate for the email
app, and subject to my team's existing Gaia priorities, I am willing
to do some branches of the email app if, for example, there are
platform people putting in Service Workers and they want a larger
sized app to take it for a test drive.

[1] https://github.com/slightlyoff/ServiceWorker
but see this for an intro:
https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md

James