Universal Navigation for Web Apps

[Ben Francis]

The back button is fundamental to how people browse the web today and a lot
of effort has gone into encouraging web developers not to break the back
button (and forward button) when building single page web apps with lots of
AJAX (this is what parts of HTML5's history API are designed to help with).

In B2G we have full screen web apps without any browser chrome at all and
this means no back button. Some mobile devices will have a hardware back
button, but others will not.

A discussion has re-surfaced in a Gaia bug (
https://github.com/andreasgal/gaia/issues/616) about how we should deal
with this. In addition to the back button there's the issue of a contextual
menu button which is another common hardware button on mobile devices. This
slightly overlaps with the other thread about UI consistency
https://groups.google.com/d/topic/mozilla.dev.b2g/V5-lLuov-0o/discussion

I won't try to summarise the subtle points already made by other people in
the bug linked to above, so feel free to repeat yourself here.

My view is that where there is a hardware back button it should basically
do the same thing that the back button does in Firefox' browser chrome
(this is not simple, not least because we have iframes nested in iframes)
and should navigate through the app's history until the history runs out.

Where there is no hardware back button the situation is more complicated.
I'm not sure that just expecting all web apps to include their own back
buttons on every screen is necessarily a good enough solution because it's
possible for the user to get trapped at a certain point along their
browsing history (if the developer forgets to put a back button on a
particular screen or even if the user hits a 404 page). One possibility is
for the homescreen to have universal back and menu buttons to control web
apps, but this requires special permissions over the iframes in which the
apps are loaded and there are times when these software buttons should not
be displayed. A particularly hard aspect of this is how web apps can adapt
to devices with hardware buttons and those without.

HTML5 has declaritive desktop toolbar/contextual menu type features which
could be re-used creatively for a "menu" button, but how should we do this?

One thing to bear in mind when discussing this is that we're not just
talking about Gaia apps or B2G apps here, these are web apps which should
ideally be adaptable enough to run on any platform - be that a desktop PC,
a smart TV or a fridge!

Ben

--
Ben Francis
http://tola.me.uk

[Dean Landolt]

Would it be wrong to have some kind of gecko chrome that can be reliable
dialed up with a specific (perhaps hardware-specific) gesture or physical
input? There could be any number of unforeseen situations that may trap a
user in a broken fullscreen app. There has to be some kind of escape hatch,
right? Even if just to kill a unresponsive tab or, in this case, force a
back button press.

[Vivien]

On 06/03/2012 00:15, Dean Landolt wrote:
>
> Would it be wrong to have some kind of gecko chrome that can be reliable
> dialed up with a specific (perhaps hardware-specific) gesture or physical
> input? There could be any number of unforeseen situations that may trap a
> user in a broken fullscreen app. There has to be some kind of escape hatch,
> right? Even if just to kill a unresponsive tab or, in this case, force a
> back button press.

In any case pressing the 'home' button bring you back to the homescreen
and from here you can manage your applications.

Vivien.

[Josh Carpenter]

> Where there is no hardware back button the situation is more complicated.
> I'm not sure that just expecting all web apps to include their own back
> buttons on every screen is necessarily a good enough solution because it's
> possible for the user to get trapped at a certain point along their
> browsing history (if the developer forgets to put a back button on a
> particular screen or even if the user hits a 404 page).

Then the developer should get his/her _expletive_ act together. :) We
have to be comfortable setting certain UX requirements. We can haggle
over where those bars are, but we're not going to start building in
Buttons for Edge Cases & Incompetence. :) That way lies madness.

I'd say: you ship for B2G, you're expected to include in-app UI
navigation. Just like you're expected to obey permissions models, and
you're expected not to crash after 5 seconds.

On Mar 6, 3:48 am, Vivien <2...@vingtetun.org> wrote:
> In any case pressing the 'home' button bring you back to the homescreen
> and from here you can manage your applications.

Egg-zactly. The clarity of a single button.

[Ben Francis]

On Tue, Mar 13, 2012 at 6:10 AM, Josh Carpenter <jcarp...@mozilla.com>wrote:

> > Where there is no hardware back button the situation is more complicated.
> > I'm not sure that just expecting all web apps to include their own back
> > buttons on every screen is necessarily a good enough solution because
> it's
> > possible for the user to get trapped at a certain point along their
> > browsing history (if the developer forgets to put a back button on a
> > particular screen or even if the user hits a 404 page).
>
> Then the developer should get his/her _expletive_ act together. :) We
> have to be comfortable setting certain UX requirements. We can haggle
> over where those bars are, but we're not going to start building in
> Buttons for Edge Cases & Incompetence. :) That way lies madness.
>

OK, yes, that's a bad reason.

>
> I'd say: you ship for B2G, you're expected to include in-app UI
> navigation. Just like you're expected to obey permissions models, and
> you're expected not to crash after 5 seconds.
>

Ah, now your language here concerns me. I don't expect any app to ever
"ship for B2G", they will ship for the web.

One of the design constraints the open web platform has that proprietary
platforms don't have (at least not to the same extent), is that the open
web platform has (by definition) multiple implementations and a diverse
range of form factors. I think it's worth repeating that any app for B2G
should also run on any other web platform on mobile, desktop, TV etc.

> On Mar 6, 3:48 am, Vivien <2...@vingtetun.org> wrote:

> > In any case pressing the 'home' button bring you back to the homescreen
> > and from here you can manage your applications.
>

> Egg-zactly. The clarity of a single button.
>

I actually really like the purity of a single hardware button and no
chrome. I just want to be clear that we're not just designing the UX for
B2G here, we're setting a precedent for how web apps might be used on other
platforms too. Currently many web apps make the assumption that a chrome or
hardware back button is present. We're saying that sometimes that won't be
the case, which is not just something which effects Gaia apps on B2G, but
all web apps on all platforms.

I don't have a problem with having no persistent back button outside of app
iframes in Gaia, as long as Gaia apps still behave as the user would expect
on other platforms, like not breaking the back button on desktop Firefox
for example. The downside of this is that on platforms that *do* have a
chrome or hardware back or menu button, you're duplicating user interface
elements. There's no API that I know of to find out whether the user agent
has a back button or not... maybe this could be part of the device
capabilities API?

[Matthew Phillips]

I don't think B2G should be opinionated on UI conventions. Gaia, however,
should. And manufacturers shipping Gaia devices should obey those
conventions.

So I think the decision should be made whether Gaia has back buttons or
not. If so we should only fallback on software buttons when not present on
the device, preferably in the same location where hardware buttons are
typical.

> > > In any case pressing the 'home' button bring you back to the homescreen
> > > and from here you can manage your applications.
> >

> > Egg-zactly. The clarity of a single button.
> >
>
> I actually really like the purity of a single hardware button and no
> chrome. I just want to be clear that we're not just designing the UX for
> B2G here, we're setting a precedent for how web apps might be used on other
> platforms too. Currently many web apps make the assumption that a chrome or
> hardware back button is present. We're saying that sometimes that won't be
> the case, which is not just something which effects Gaia apps on B2G, but
> all web apps on all platforms.
>
> I don't have a problem with having no persistent back button outside of app
> iframes in Gaia, as long as Gaia apps still behave as the user would expect
> on other platforms, like not breaking the back button on desktop Firefox
> for example. The downside of this is that on platforms that *do* have a
> chrome or hardware back or menu button, you're duplicating user interface
> elements. There's no API that I know of to find out whether the user agent
> has a back button or not... maybe this could be part of the device
> capabilities API?
>
> Ben
>
> --
> Ben Francis
> http://tola.me.uk

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

[Jim Straus]

Hello Ben -
I agree that it would be nice to assume no chrome and single button on B2G. On other devices (desktops), no chrome and just click out of the window to switch away, close the window with the window buttons. If web apps are to be first class citizens on the desktop, they should look like native applications and live within the normal desktop window with no other UI. And this flows to B2G in favor of not having chrome. If a developer of a web app doesn't provide navigation controls, they're just creating unusable apps. Web pages can still assume chrome, both on the desktop and B2G. This is why we have a browser app.
Letting the app know what extra navigation hardware is available (hard back button, hard menu button, up/down/left/right buttons, joystick, etc., is also good. And we should probably document standards of what those buttons do so apps can be consistent in their use of them.
-Jim Straus

[Josh Carpenter]

Hi guys, really good comments. By way of follow up, I connected with
the Apps team today, and my understanding it that they're also saying
"you can't count on a back button" for their Open Web Apps. Desktop
WebRT implementations are chromeless, and as such, devs will have to
implement their own navigation interfaces. Along the lines of Jim's
comment: "If web apps are to be first class citizens on the desktop,

they should look like native applications and live within the normal
desktop window with no other UI."

Ben, to your comments:

> I don't have a problem with having no persistent back button outside of app frames in Gaia, as long as Gaia apps still behave as the user would expect on other platforms, like not breaking the back button on desktop Firefox for example.

Okay, so my gut reaction here: forget desktop, tablets, and fridges.
All we care about is making Gaia apps insanely awesome on phones. If
Edge Case Edward (amazing) wants to install the dialer on their
dual-24" setup, they can. It'll work, it won't break back button, etc.
But we're not going to expend one drop of energy actually designing,
developing, and testing for that odd situation. We just don't have the
bandwidth. Trying to create beautiful apps that effectively flex from
3.5—5.5" screen sizes and 160—340ppi is bad enough. God forbid we have
to then design that same app for the fridge's 17" touch panel.

Sorry if I'm misunderstanding. I'm enormously appreciative of you
taking me to school on this stuff (so much to learn, so little time).
Does that make sense?

> The downside of this is that on platforms that *do* have a chrome or hardware back or menu button, you're duplicating user interface elements. There's no API that I know of to find out whether the user agent has a back button or not... maybe this could be part of the device capabilities API?

Not super-concerned with duplicated UI. It'll be pretty uncommon
(especially if we do indeed have influence on hardware spec). That
situation actually happens on my Galaxy Nexus, with it's fixed back
button, and the top-left UI back buttons ICM implements.

[Ben Francis]

On Wed, Mar 14, 2012 at 9:05 AM, Josh Carpenter <jcarp...@mozilla.com>wrote:

> I connected with
> the Apps team today, and my understanding it that they're also saying
> "you can't count on a back button" for their Open Web Apps. Desktop
> WebRT implementations are chromeless, and as such, devs will have to
> implement their own navigation interfaces.

That's great, good to know that we're presenting a consistent message
across form factors and that someone is connecting the dots! This helps to
differentiate "web apps" from "web sites" in Firefox too. That doesn't mean
that these web apps won't be used in other user agents that do provide
additional hardware or chrome though, so we could still add in support for
the back button etc. where they are present. I don't think this is really a
big problem.

> > I don't have a problem with having no persistent back button outside of

> app frames in Gaia, as long as Gaia apps still behave as the user would

> expect on other platforms, like not breaking the back button on desktop
> Firefox for example.
>

> Okay, so my gut reaction here: forget desktop, tablets, and fridges.
> All we care about is making Gaia apps insanely awesome on phones. If
> Edge Case Edward (amazing) wants to install the dialer on their
> dual-24" setup, they can. It'll work, it won't break back button, etc.
> But we're not going to expend one drop of energy actually designing,
> developing, and testing for that odd situation. We just don't have the
> bandwidth. Trying to create beautiful apps that effectively flex from
> 3.5—5.5" screen sizes and 160—340ppi is bad enough. God forbid we have
> to then design that same app for the fridge's 17" touch panel.
>

I completely agree that for apps like the dialer and SMS there's really
little point in expending the effort, they're useless on a device with no
SIM card. But for apps like the gallery, music and video players I would
absolutely expect an app I install from the Mozilla Marketplace to work
well in Mozilla Firefox on the desktop as well as Mozilla B2G, and
eventually Chrome, IE and Opera as well! For me that's fundamental to the
value proposition we're making to users.

I'm not saying that we can solve this huge problem from day one, but I do
think it helps our credibility (and that of the web as a universal app
platform) if we can lead the way with web apps that work on multiple form
factors, this is just good practice.

> Not super-concerned with duplicated UI. It'll be pretty uncommon
> (especially if we do indeed have influence on hardware spec). That
> situation actually happens on my Galaxy Nexus, with it's fixed back
> button, and the top-left UI back buttons ICM implements.
>

I agree this isn't something we should lose any sleep over, it's just a
messy detail that would nice to fix one day. But remember our influence
over hardware specs only extends to B2G devices, and even then only the
one's we're very actively involved in. The world wild web is rich and
diverse landscape :)

[Justin D'Arcangelo]

A few thoughts. First off, I agree that the existence of these
hardware buttons needs to be something that can be queried by a
capabilities API. That would just ensure that devs are not backed into
a corner and having to resort to terrible practices such as UA
sniffing in the future. The other thing that Ben touched on that is
really important is that there needs to be a differentiation between
web sites and web *apps*. So, a web app should (in my opinion) build
navigation in that makes the app flow naturally. That could be a
navbar with a back button, tabs, or something completely new. The
point is, the user shouldn't have a concept of the traditional
back/forward unless the *app* conveys that there is a page/view stack.
With a plain old web site, the opposite couldn't be more the truth. In
that scenario, you NEED at the very least a back button and possibly a
way to go forward. These are two very contradictory concepts and the
fact that the hardware might not always have a hardware back button
makes this more complicated. So, going back to the first thing, we
need an API to detect the presence of hardware buttons. We should also
consider creating a lower button bar that emulates the hardware
buttons that can be shown conditionally. For a true web *app*, we
probably don't need to show this button bar, but maybe for a full
screen web site we do. Come to think of it, a *really* interesting
idea might be if there was a way in the app manifest to indicate
whether or not these buttons are *required*! If they are and the
device doesn't have them physically, we could show the emulated button
bar at the bottom. For web *sites* that wouldn't have an app manifest
file, it should probably be implied that the buttons are required and
show them.

-Justin

On Mar 14, 2012, at 8:01 AM, Ben Francis <b...@krellian.com> wrote:

> On Wed, Mar 14, 2012 at 9:05 AM, Josh Carpenter <jcarp...@mozilla.com>wrote:
>
>> I connected with
>> the Apps team today, and my understanding it that they're also saying
>> "you can't count on a back button" for their Open Web Apps. Desktop
>> WebRT implementations are chromeless, and as such, devs will have to
>> implement their own navigation interfaces.
>
>
> That's great, good to know that we're presenting a consistent message
> across form factors and that someone is connecting the dots! This helps to
> differentiate "web apps" from "web sites" in Firefox too. That doesn't mean
> that these web apps won't be used in other user agents that do provide
> additional hardware or chrome though, so we could still add in support for
> the back button etc. where they are present. I don't think this is really a
> big problem.
>
>

>>> I don't have a problem with having no persistent back button outside of

>> app frames in Gaia, as long as Gaia apps still behave as the user would

>> expect on other platforms, like not breaking the back button on desktop
>> Firefox for example.
>>

[Matthew Phillips]

Forgot to include the list, see below.

On Wed, Mar 14, 2012 at 6:32 PM, Matthew Phillips
<mat...@phillipsoft.biz>wrote:

> Justin, I think a "back-button exists" api is unnecessary. Apps should
> always include navigation.
>
> Look on the desktop today; every web browser has a back button. I can't
> think of too many apps that use it as a crutch though.
>
> I also disagree that there needs to be a distinction between websites and
> web apps. It bothers me a little every time I read it on this list. The web
> is the web. Some websites contain no js, some contain just a little, some
> contain a whole lot. The user doesn't know or care about these things. I
> don't think it's a browser's job to categorize the types of webapps/sites
> that exist. I think we would do the user a disservice if we change UI or
> add/limit functionality based on arbitrary classifications.

>> >>> I don't have a problem with having no persistent back button outside
>> of

>> >> app frames in Gaia, as long as Gaia apps still behave as the user would

>> >> expect on other platforms, like not breaking the back button on desktop
>> >> Firefox for example.
>> >>

[Josh Carpenter]

> Justin, I think a "back-button exists" api is unnecessary. Apps should
> always include navigation.

Completely agree. Apps should handle their own nav and never assume
device will provide. If device _does_ provide HW button, the worst
that happens is you have duplicate HW and SW navigation. Again, see
Ice Cream Sandwich. Same situation.

> I also disagree that there needs to be a distinction between websites and
> web apps.

Disagree with this, though. They may share the same DNA, but they are
very different breeds. Each with their own real-world pros and cons.

- Apps have to define own navigation (no chrome = no buttons)
- "In-browser web content" doesn't have to (browser chrome = back &
refresh buttons)

- Apps are commonly acquired through curated "stores" (ala: retail
channels). They download, install, and live on your device. They are
the DVD's on your shelf.
- "In-browser web content" is accessed via browsers, and skimmed,
usually in and out very quickly. There is no install necessary. They
are the channels on your TV.

Very different ergonomics. It gets gray, of course. "In-browser web
apps" for example. Or installing a shortcut to a URL on your home
screen, ala: iOS. But those are in-between edge cases. The two
categories above represent the paradigm mobile OS's have settled on.

... Not to say we couldn't innovate a bit, of course ;D

[Justin D'Arcangelo]

See, I also think there is definitely a distinction between a web app
and a web site that simply gets bookmarked to the home screen. A web
site wouldn't have an app manifest to indicate its icons, etc. On iOS,
a special META tag is needed to specify that a page is an app. An
interesting thing happens when you "bookmark" a site to the home
screen on iOS: if the "app" META tag exists, the app runs full-screen
(chromeless), however, if there is nothing to specify that a page is
an "app", it simply opens the site up in the browser with the chrome.
This is absolutely necessary to solve the navigation problem. iOS is
an interesting case because it *IS* a device with no hardware back
button. I think this is probably the very reason why they introduced
the META tag for differentiating between a site and an app because an
app would (should) already include all necessary navigation.

-Justin

On Mar 14, 2012, at 7:22 PM, Josh Carpenter <jcarp...@mozilla.com> wrote:

>> Justin, I think a "back-button exists" api is unnecessary. Apps should
>> always include navigation.
>

> Completely agree. Apps should handle their own nav and never assume
> device will provide. If device _does_ provide HW button, the worst
> that happens is you have duplicate HW and SW navigation. Again, see
> Ice Cream Sandwich. Same situation.
>

>> I also disagree that there needs to be a distinction between websites and
>> web apps.
>

> Disagree with this, though. They may share the same DNA, but they are
> very different breeds. Each with their own real-world pros and cons.
>
> - Apps have to define own navigation (no chrome = no buttons)
> - "In-browser web content" doesn't have to (browser chrome = back &
> refresh buttons)
>
> - Apps are commonly acquired through curated "stores" (ala: retail
> channels). They download, install, and live on your device. They are
> the DVD's on your shelf.
> - "In-browser web content" is accessed via browsers, and skimmed,
> usually in and out very quickly. There is no install necessary. They
> are the channels on your TV.
>
> Very different ergonomics. It gets gray, of course. "In-browser web
> apps" for example. Or installing a shortcut to a URL on your home
> screen, ala: iOS. But those are in-between edge cases. The two
> categories above represent the paradigm mobile OS's have settled on.
>
> ... Not to say we couldn't innovate a bit, of course ;D

[Josh Carpenter]

If we choose to provide this functionality in B2G (present bookmarks as apps), then I totally agree: iOS nailed it, and it's a good model to reference. This would probably be fairly low-priority, though. Chris, what do you think?

--
Josh Carpenter
UX Designer
Mozilla Corporation

On Mar 14, 2012, at 5:07 PM, Justin D'Arcangelo wrote:

> See, I also think there is definitely a distinction between a web app
> and a web site that simply gets bookmarked to the home screen. A web
> site wouldn't have an app manifest to indicate its icons, etc. On iOS,
> a special META tag is needed to specify that a page is an app. An
> interesting thing happens when you "bookmark" a site to the home
> screen on iOS: if the "app" META tag exists, the app runs full-screen
> (chromeless), however, if there is nothing to specify that a page is
> an "app", it simply opens the site up in the browser with the chrome.
> This is absolutely necessary to solve the navigation problem. iOS is
> an interesting case because it *IS* a device with no hardware back
> button. I think this is probably the very reason why they introduced
> the META tag for differentiating between a site and an app because an
> app would (should) already include all necessary navigation.
>

> -Justin
>
>
> On Mar 14, 2012, at 7:22 PM, Josh Carpenter <jcarp...@mozilla.com> wrote:
>
>>> Justin, I think a "back-button exists" api is unnecessary. Apps should
>>> always include navigation.
>>

>> Completely agree. Apps should handle their own nav and never assume
>> device will provide. If device _does_ provide HW button, the worst
>> that happens is you have duplicate HW and SW navigation. Again, see
>> Ice Cream Sandwich. Same situation.
>>

>>> I also disagree that there needs to be a distinction between websites and
>>> web apps.
>>

>> Disagree with this, though. They may share the same DNA, but they are
>> very different breeds. Each with their own real-world pros and cons.
>>
>> - Apps have to define own navigation (no chrome = no buttons)
>> - "In-browser web content" doesn't have to (browser chrome = back &
>> refresh buttons)
>>
>> - Apps are commonly acquired through curated "stores" (ala: retail
>> channels). They download, install, and live on your device. They are
>> the DVD's on your shelf.
>> - "In-browser web content" is accessed via browsers, and skimmed,
>> usually in and out very quickly. There is no install necessary. They
>> are the channels on your TV.
>>
>> Very different ergonomics. It gets gray, of course. "In-browser web
>> apps" for example. Or installing a shortcut to a URL on your home
>> screen, ala: iOS. But those are in-between edge cases. The two
>> categories above represent the paradigm mobile OS's have settled on.
>>
>> ... Not to say we couldn't innovate a bit, of course ;D

[Justin D'Arcangelo]

I thought that this was intended functionality. Aren't the Wikipedia
and Facebook apps presented like this?

-Justin

On Mar 14, 2012, at 8:21 PM, Josh Carpenter <jcarp...@mozilla.com> wrote:

> If we choose to provide this functionality in B2G (present bookmarks as apps), then I totally agree: iOS nailed it, and it's a good model to reference. This would probably be fairly low-priority, though. Chris, what do you think?
>
> --
> Josh Carpenter
> UX Designer
> Mozilla Corporation
>
>
>
> On Mar 14, 2012, at 5:07 PM, Justin D'Arcangelo wrote:
>
>> See, I also think there is definitely a distinction between a web app
>> and a web site that simply gets bookmarked to the home screen. A web
>> site wouldn't have an app manifest to indicate its icons, etc. On iOS,
>> a special META tag is needed to specify that a page is an app. An
>> interesting thing happens when you "bookmark" a site to the home
>> screen on iOS: if the "app" META tag exists, the app runs full-screen
>> (chromeless), however, if there is nothing to specify that a page is
>> an "app", it simply opens the site up in the browser with the chrome.
>> This is absolutely necessary to solve the navigation problem. iOS is
>> an interesting case because it *IS* a device with no hardware back
>> button. I think this is probably the very reason why they introduced
>> the META tag for differentiating between a site and an app because an
>> app would (should) already include all necessary navigation.
>>

>> -Justin
>>
>>
>> On Mar 14, 2012, at 7:22 PM, Josh Carpenter <jcarp...@mozilla.com> wrote:
>>
>>>> Justin, I think a "back-button exists" api is unnecessary. Apps should
>>>> always include navigation.
>>>

>>> Completely agree. Apps should handle their own nav and never assume
>>> device will provide. If device _does_ provide HW button, the worst
>>> that happens is you have duplicate HW and SW navigation. Again, see
>>> Ice Cream Sandwich. Same situation.
>>>

>>>> I also disagree that there needs to be a distinction between websites and
>>>> web apps.
>>>

>>> Disagree with this, though. They may share the same DNA, but they are
>>> very different breeds. Each with their own real-world pros and cons.
>>>
>>> - Apps have to define own navigation (no chrome = no buttons)
>>> - "In-browser web content" doesn't have to (browser chrome = back &
>>> refresh buttons)
>>>
>>> - Apps are commonly acquired through curated "stores" (ala: retail
>>> channels). They download, install, and live on your device. They are
>>> the DVD's on your shelf.
>>> - "In-browser web content" is accessed via browsers, and skimmed,
>>> usually in and out very quickly. There is no install necessary. They
>>> are the channels on your TV.
>>>
>>> Very different ergonomics. It gets gray, of course. "In-browser web
>>> apps" for example. Or installing a shortcut to a URL on your home
>>> screen, ala: iOS. But those are in-between edge cases. The two
>>> categories above represent the paradigm mobile OS's have settled on.
>>>
>>> ... Not to say we couldn't innovate a bit, of course ;D

[Josh Carpenter]

Sort of. I don't believe they appear with browser chrome. And we manually created manifests and icons for them. So if we wanted to do something like the iOS approach, there would still be work to do.

--
Josh Carpenter
UX Designer
Mozilla Corporation

On Mar 14, 2012, at 6:05 PM, Justin D'Arcangelo wrote:

> I thought that this was intended functionality. Aren't the Wikipedia
> and Facebook apps presented like this?
>

> -Justin
>

> On Mar 14, 2012, at 8:21 PM, Josh Carpenter <jcarp...@mozilla.com> wrote:
>
>> If we choose to provide this functionality in B2G (present bookmarks as apps), then I totally agree: iOS nailed it, and it's a good model to reference. This would probably be fairly low-priority, though. Chris, what do you think?
>>
>> --
>> Josh Carpenter
>> UX Designer
>> Mozilla Corporation
>>
>>
>>
>> On Mar 14, 2012, at 5:07 PM, Justin D'Arcangelo wrote:
>>
>>> See, I also think there is definitely a distinction between a web app
>>> and a web site that simply gets bookmarked to the home screen. A web
>>> site wouldn't have an app manifest to indicate its icons, etc. On iOS,
>>> a special META tag is needed to specify that a page is an app. An
>>> interesting thing happens when you "bookmark" a site to the home
>>> screen on iOS: if the "app" META tag exists, the app runs full-screen
>>> (chromeless), however, if there is nothing to specify that a page is
>>> an "app", it simply opens the site up in the browser with the chrome.
>>> This is absolutely necessary to solve the navigation problem. iOS is
>>> an interesting case because it *IS* a device with no hardware back
>>> button. I think this is probably the very reason why they introduced
>>> the META tag for differentiating between a site and an app because an
>>> app would (should) already include all necessary navigation.
>>>

>>> -Justin
>>>
>>>
>>> On Mar 14, 2012, at 7:22 PM, Josh Carpenter <jcarp...@mozilla.com> wrote:
>>>
>>>>> Justin, I think a "back-button exists" api is unnecessary. Apps should
>>>>> always include navigation.
>>>>

>>>> Completely agree. Apps should handle their own nav and never assume
>>>> device will provide. If device _does_ provide HW button, the worst
>>>> that happens is you have duplicate HW and SW navigation. Again, see
>>>> Ice Cream Sandwich. Same situation.
>>>>

>>>>> I also disagree that there needs to be a distinction between websites and
>>>>> web apps.
>>>>

>>>> Disagree with this, though. They may share the same DNA, but they are
>>>> very different breeds. Each with their own real-world pros and cons.
>>>>
>>>> - Apps have to define own navigation (no chrome = no buttons)
>>>> - "In-browser web content" doesn't have to (browser chrome = back &
>>>> refresh buttons)
>>>>
>>>> - Apps are commonly acquired through curated "stores" (ala: retail
>>>> channels). They download, install, and live on your device. They are
>>>> the DVD's on your shelf.
>>>> - "In-browser web content" is accessed via browsers, and skimmed,
>>>> usually in and out very quickly. There is no install necessary. They
>>>> are the channels on your TV.
>>>>
>>>> Very different ergonomics. It gets gray, of course. "In-browser web
>>>> apps" for example. Or installing a shortcut to a URL on your home
>>>> screen, ala: iOS. But those are in-between edge cases. The two
>>>> categories above represent the paradigm mobile OS's have settled on.
>>>>
>>>> ... Not to say we couldn't innovate a bit, of course ;D

[Chris Jones]

----- Original Message -----
> From: "Ben Francis" <b...@krellian.com>
> To: "Josh Carpenter" <jcarp...@mozilla.com>
> Cc: mozilla...@lists.mozilla.org
> Sent: Tuesday, March 13, 2012 4:00:26 AM
> Subject: Re: [b2g] Universal Navigation for Web Apps
>
> On Tue, Mar 13, 2012 at 6:10 AM, Josh Carpenter
> <jcarp...@mozilla.com>wrote:
>

> > On Mar 6, 3:48 am, Vivien <2...@vingtetun.org> wrote:
> > > In any case pressing the 'home' button bring you back to the
> > > homescreen
> > > and from here you can manage your applications.
> >
> > Egg-zactly. The clarity of a single button.
> >
>

> I actually really like the purity of a single hardware button and no
> chrome. I just want to be clear that we're not just designing the UX
> for
> B2G here, we're setting a precedent for how web apps might be used on
> other

> platforms too. Currently many web apps make the assumption that a
> chrome or

> hardware back button is present. We're saying that sometimes that
> won't be
> the case, which is not just something which effects Gaia apps on B2G,
> but
> all web apps on all platforms.
>

When legacy content makes assumptions that no longer hold, the market rewards players who implement fallbacks to degrade gracefully. The original MobileSafari kicked everyone's ass doing that.

The market also rewards players who lead the way on innovation and better UX. Unsuccessful ideas turn into dead ends, and successful ones become the next decade's legacy content that everyone has to support. We have to walk a fine line.

Agreed on making sure the line is clearly drawn between b2g and Gaia. b2g doesn't care what it's drawing, it's just an engine. Conversely, Gaia only cares what's being drawn, and doesn't care what engine is drawing it (could be webkit).

> I don't have a problem with having no persistent back button outside
> of app

> iframes in Gaia, as long as Gaia apps still behave as the user would

> expect
> on other platforms, like not breaking the back button on desktop
> Firefox

> for example. The downside of this is that on platforms that *do* have

> a
> chrome or hardware back or menu button, you're duplicating user
> interface
> elements. There's no API that I know of to find out whether the user
> agent
> has a back button or not... maybe this could be part of the device
> capabilities API?
>

The general process is, opt-in to new hotness, or fall back and degrade gracefully. My personal opinion is that contextual navigation >> fixed UI like a chrome/HW back button. If that's right, contextual navigation will win and UAs/devices that support that best will win in the market. That is, the better paradigm will kill HW/chrome back buttons. Duplicated UI will reflect badly on the *device/chrome*, not the app.

As an anecdote, there are several android applications on my gingerbread phone that have contextual nav, and I've learned to prefer it and look for it. I only press the HW back button as a last-ditch "get me out of here" mechanism, and I don't know where it will take me.

If contextual navigation wins, a capability check for HW/chrome back button doesn't seem like a useful API. Legacy content wouldn't know about it, and contextual-navigation-using apps would just ignore it.

We need to decide on the direction for Gaia. Sentiment seems to be in favor of contextual nav. If that's the direction, then the question is how to fall back. We have some options
- special gesture to bring up a compat context menu, like a long-tap. "Back" could be an option in the compat menu.
- allow pages to indicate semantically they're providing their own contextual navigation. Fall back for pages that don't. I lean towards this solution.
- show back control in standard location, make pages opt-in to not having controls. I don't really like this, but it's an option that might make sense given data.

We don't have enough information to make an informed decision yet, I don't think. We need to test these out with real pages.

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Josh Carpenter" <jcarp...@mozilla.com>
> To: mozilla...@lists.mozilla.org
> Sent: Wednesday, March 14, 2012 2:05:21 AM
> Subject: Re: [b2g] Universal Navigation for Web Apps
>

> > I don't have a problem with having no persistent back button

> > outside of app frames in Gaia, as long as Gaia apps still behave

> > as the user would expect on other platforms, like not breaking the
> > back button on desktop Firefox for example.
>

> Okay, so my gut reaction here: forget desktop, tablets, and fridges.
> All we care about is making Gaia apps insanely awesome on phones. If
> Edge Case Edward (amazing) wants to install the dialer on their
> dual-24" setup, they can. It'll work, it won't break back button,
> etc.
> But we're not going to expend one drop of energy actually designing,
> developing, and testing for that odd situation. We just don't have
> the
> bandwidth. Trying to create beautiful apps that effectively flex from
> 3.5—5.5" screen sizes and 160—340ppi is bad enough. God forbid we
> have
> to then design that same app for the fridge's 17" touch panel.
>

I agree with you somewhat, but not entirely. I think it's a decision per app, driven by economics. There's a separate issue that's the limited bandwidth of people hacking on Gaia, and prioritizing.

Web technologies like HTML and CSS make it relatively easier to write layouts that work on a variety of presentation contexts. That's what they were designed to do, and it's awesome. But the fundamental issue is, that doesn't come for free.

We should *prioritize* a first-class UX on phone screens above all else right now, definitely. I would never use the Gaia settings app in my desktop browsers. But I definitely would use a Gaia eReader app, say. (Amazon leading the way here.) I would even use a cool dialer, in the future, with a navigator.telephony backend that talked VoIP or something. But that's all about economics. People who read the tea leaves better than us will kick our ass. That's the way these things are supposed to work.

But in all cases we should strive to set an example for other developers.

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Josh Carpenter" <jcarp...@mozilla.com>
> To: mozilla...@lists.mozilla.org
> Sent: Wednesday, March 14, 2012 4:22:29 PM
> Subject: Re: [b2g] Universal Navigation for Web Apps
>

> > I also disagree that there needs to be a distinction between
> > websites and
> > web apps.
>
> Disagree with this, though. They may share the same DNA, but they are
> very different breeds. Each with their own real-world pros and cons.
>

I sort of agree with you, but for different reasons than you cited. The issue is more mundane, I think: "web browser", for better or worse, mostly means "document reader" today. That's the paradigm arbitrary web pages expect. In that paradigm, users click links to different domains, type in URLs to different sites, etc. Different documents show up in the same box. It's technically feasible for web documents to implement UI for navigating back to a previous page from another domain (sigh), but why would nytimes.com care about that, e.g.? A "back" button on the nytimes.com home page would be out of place.

The difference for "web apps", in the installed-app-inside-a-security-sandbox sense, is that they own their tab/iframe. Pages from other domains can't be loaded in there; the "app" owns the box. Different apps are in different boxes. This is the paradigm that's existing in every windowing system since the Xerox PARC GUI.

But pages and "apps" have the same needs. I might click an article link on nytimes.com, e.g., and want to navigate back to the home page. That need is the same whether it's a page or an "app". Web content is always free to make its own contextual UI, and indeed NYTimes does this. It also can take advantage of built-in UI to navigate, the chrome "back" button.

Cheers,
Chris

[Josh Carpenter]

> But pages and "apps" have the same needs. I might click an article link on nytimes.com, e.g., and want to navigate back to the home page. That need is the same whether it's a page or an "app".

Actually "Back" buttons—in the classic browser sense—aren't very relevant in Apps design. There are plenty of much more effective navigation design patterns, such as tabs, Windows Mobile's panorama, modal windows, etc. In the relatively rare instance within Apps where you burrow down a level into the hierarchy, and need to ascend back up, iOS and Android 4 solve the problem with labeled UI buttons in top-left.

Unlabeled "Back" buttons are a blunt force, unsophisticated tool. Blind jumps. Useful in fairly linear document-to-document navigtation where you probably remember where they're taking you, but breaking down fast in the dynamic world of the app.

> The general process is, opt-in to new hotness, or fall back and degrade gracefully. My personal opinion is that contextual navigation >> fixed UI like a chrome/HW back button. If that's right, contextual navigation will win and UAs/devices that support that best will win in the market. That is, the better paradigm will kill HW/chrome back buttons. Duplicated UI will reflect badly on the *device/chrome*, not the app.
>
> As an anecdote, there are several android applications on my gingerbread phone that have contextual nav, and I've learned to prefer it and look for it. I only press the HW back button as a last-ditch "get me out of here" mechanism, and I don't know where it will take me.
>
> If contextual navigation wins, a capability check for HW/chrome back button doesn't seem like a useful API. Legacy content wouldn't know about it, and contextual-navigation-using apps would just ignore it.
>
> We need to decide on the direction for Gaia. Sentiment seems to be in favor of contextual nav. If that's the direction, then the question is how to fall back. We have some options
> - special gesture to bring up a compat context menu, like a long-tap. "Back" could be an option in the compat menu.
> - allow pages to indicate semantically they're providing their own contextual navigation. Fall back for pages that don't. I lean towards this solution.
> - show back control in standard location, make pages opt-in to not having controls. I don't really like this, but it's an option that might make sense given data.
>
> We don't have enough information to make an informed decision yet, I don't think. We need to test these out with real pages.

I'm not clear on whether you're recommending the above solution for both "web content" and Apps. I'm assuming yes.

The issue here is that unlabeled back buttons are poor App usability, regardless of whether they're hardware, browser chrome, or tucked in a contextual menu. So I'd say:
For content designed to live in a browser ("document reader" content, as per your other email) we do provide Firefox, which does have chrome back button. We could also look at supplemental alternatives, from swipes to contextual menus.
For Apps, devs are responsible for their own nav, and will inevitably leverage the rich array of establish mobile design patterns out there. Our first party apps will continue to avoid blind back buttons.
FWIW, I can foresee using contextual menus ala: ICM, populating them with less-common functions. And maybe as backup nav. But for primary Apps nav, definitely not.

--
Josh Carpenter
UX Designer
Mozilla Corporation

On Mar 14, 2012, at 11:11 PM, Chris Jones wrote:

> ----- Original Message -----

>> From: "Ben Francis" <b...@krellian.com>
>> To: "Josh Carpenter" <jcarp...@mozilla.com>
>> Cc: mozilla...@lists.mozilla.org
>> Sent: Tuesday, March 13, 2012 4:00:26 AM

>> Subject: Re: [b2g] Universal Navigation for Web Apps
>>

>> On Tue, Mar 13, 2012 at 6:10 AM, Josh Carpenter
>> <jcarp...@mozilla.com>wrote:
>>
>>> On Mar 6, 3:48 am, Vivien <2...@vingtetun.org> wrote:
>>>> In any case pressing the 'home' button bring you back to the
>>>> homescreen
>>>> and from here you can manage your applications.
>>>
>>> Egg-zactly. The clarity of a single button.
>>>
>>
>> I actually really like the purity of a single hardware button and no
>> chrome. I just want to be clear that we're not just designing the UX
>> for
>> B2G here, we're setting a precedent for how web apps might be used on
>> other
>> platforms too. Currently many web apps make the assumption that a
>> chrome or
>> hardware back button is present. We're saying that sometimes that
>> won't be
>> the case, which is not just something which effects Gaia apps on B2G,
>> but
>> all web apps on all platforms.
>>
>
> When legacy content makes assumptions that no longer hold, the market rewards players who implement fallbacks to degrade gracefully. The original MobileSafari kicked everyone's ass doing that.
>
> The market also rewards players who lead the way on innovation and better UX. Unsuccessful ideas turn into dead ends, and successful ones become the next decade's legacy content that everyone has to support. We have to walk a fine line.
>
> Agreed on making sure the line is clearly drawn between b2g and Gaia. b2g doesn't care what it's drawing, it's just an engine. Conversely, Gaia only cares what's being drawn, and doesn't care what engine is drawing it (could be webkit).
>

>> I don't have a problem with having no persistent back button outside
>> of app

>> iframes in Gaia, as long as Gaia apps still behave as the user would

>> expect
>> on other platforms, like not breaking the back button on desktop
>> Firefox

[Panos Astithas]

On Thu, Mar 15, 2012 at 10:44 AM, Josh Carpenter <jcarp...@mozilla.com>wrote:

> The issue here is that unlabeled back buttons are poor App usability,
> regardless of whether they're hardware, browser chrome, or tucked in a
> contextual menu. So I'd say:
> For content designed to live in a browser ("document reader" content, as
> per your other email) we do provide Firefox, which does have chrome back
> button. We could also look at supplemental alternatives, from swipes to
> contextual menus.
>

So in that case, clicking on an external link in the NYTimes app (or
similar) should open it in Firefox, with it's own URL bar and back button,
right? This seems rather heavy, judging by past iOS & Android experience,
but it might be smooth in b2g (it's just another iframe, right?).

Panos

[Josh Carpenter]

> So in that case, clicking on an external link in the NYTimes app (or similar) should open it in Firefox, with it's own URL bar and back button, right? This seems rather heavy, judging by past iOS & Android experience, but it might be smooth in b2g (it's just another iframe, right?).

It depends. Some apps provide in-app browsing (Twitter clients, RSS readers, etc). Others throw links to an external browser (opening a link from within an email App, for example). It's a case by case thing, up to the app makers.

Stepping back, this thread has been awesome. I think we've got the constraints and possibilities thoroughly mapped out now, and Patryk and myself can step back and figure out the OS-level big picture of navigation.

--
Josh Carpenter
UX Designer
Mozilla Corporation

[Ben Francis]

On Thu, Mar 15, 2012 at 2:42 AM, Josh Carpenter <jcarp...@mozilla.com>wrote:

> Sort of. I don't believe they appear with browser chrome. And we manually
> created manifests and icons for them. So if we wanted to do something like
> the iOS approach, there would still be work to do.
>

We have a Gaia Wikipedia app and a Gaia NY Times app which are locally
hosted apps that contain iFrames which load the actual web site inside.
This is a hack and apps like this should never get into the Marketplace.

With the Facebook, GMail and Google Calendar apps we're still spoofing the
manifest (because these vendors don't host Open Web App manifests yet), but
they load the original sites/apps from the real origin without an
additional iFrame. This is also a temporary hack (spoofed manifests), which
we shouldn't be doing in the long term either.

If we want to add bookmarks to the homescreen we need to find another
method of doing this. The homescreen could just maintain a database of
bookmarks with titles, URLs and a cached favicon (we'd have to figure out
how to present this because web sites generally only have a tiny icon).

Note that the apps team is also discussing whether users should be able to
"install" arbitrary web sites as an app, even if they don't have a
manifest. This could be really helpful in the short term while few sites
host a manifest, but would kind of degrade the perceived user experience of
"apps".

[Ben Francis]

On Thu, Mar 15, 2012 at 6:11 AM, Chris Jones <cjo...@mozilla.com> wrote:

> We need to decide on the direction for Gaia. Sentiment seems to be in
> favor of contextual nav. If that's the direction, then the question is how
> to fall back. We have some options
> - special gesture to bring up a compat context menu, like a long-tap.
> "Back" could be an option in the compat menu.
>

That's an interesting idea. It might mean adding extra capabilities to
mozapp iframes though.

> - allow pages to indicate semantically they're providing their own
> contextual navigation. Fall back for pages that don't. I lean towards
> this solution.
>


> - show back control in standard location, make pages opt-in to not having
> controls. I don't really like this, but it's an option that might make
> sense given data.
>

They could specify this in the app manifest, though it seems like we'd
prefer all apps to choose the "no chrome" option. Alternatively we could
have no controls by default and make apps opt-in to legacy browser chrome
if they want standard controls.

In desktop Chrome the user can specify whether a particular app opens in a
standard tab, a pinned tab, a window or full screen (both standard tabs and
pinned tabs have standard navigation controls, a window is a window in the
desktop environment with no navigation controls, fullscreen has no
navigation controls but turns into a normal tab if you exit full screen
mode).

In Gaia we could allow the user to specify whether an app or bookmark opens
as a web site (with chrome) or as a web app (without chrome). This gives
the user more control, but asks them to make the decision rather than the
app developer.

> We don't have enough information to make an informed decision yet, I don't
> think. We need to test these out with real pages.
>

This could definitely do with some research.

[Josh Carpenter]

> I agree with you somewhat, but not entirely. I think it's a decision per app, driven by economics. There's a separate issue that's the limited bandwidth of people hacking on Gaia, and prioritizing.
>
> Web technologies like HTML and CSS make it relatively easier to write layouts that work on a variety of presentation contexts. That's what they were designed to do, and it's awesome. But the fundamental issue is, that doesn't come for free.
>
> We should *prioritize* a first-class UX on phone screens above all else right now, definitely. I would never use the Gaia settings app in my desktop browsers. But I definitely would use a Gaia eReader app, say. (Amazon leading the way here.) I would even use a cool dialer, in the future, with a navigator.telephony backend that talked VoIP or something. But that's all about economics. People who read the tea leaves better than us will kick our ass. That's the way these things are supposed to work.
>
> But in all cases we should strive to set an example for other developers.

Completely agree on all points. On a related tangent, I pinged Bryan Clark for his input on this today. His response.

> The technology makes it possible to run in any supported browser and people could actually run an app on any device if they wanted to however we are allowing developers to "restrict" usage in a "designed for X" context.
>
> . . . The Marketplace is working on a device compatibility system that allows developer to target Phones, Tablets, and Desktops with their applications because sometimes that's what people want to do. Phones tend to have a lot more device access than desktops will so it makes sense you might make a game that requires the tilt sensor that a desktop doesn't have.

That's exactly what I was hoping for. Attached is the Marketplace screenshot he shared.

--
Josh Carpenter
UX Designer
Mozilla Corporation

On Mar 14, 2012, at 11:20 PM, Chris Jones wrote:

> ----- Original Message -----

>> From: "Josh Carpenter" <jcarp...@mozilla.com>
>> To: mozilla...@lists.mozilla.org

>> Sent: Wednesday, March 14, 2012 2:05:21 AM
>> Subject: Re: [b2g] Universal Navigation for Web Apps
>>

>>> I don't have a problem with having no persistent back button

>>> outside of app frames in Gaia, as long as Gaia apps still behave

>>> as the user would expect on other platforms, like not breaking the
>>> back button on desktop Firefox for example.
>>

[Josh Carpenter]

In case that Marketplace screenshot was stripped out, here it is:

http://cl.ly/1E3o0r0W1C1h3M1Y2x0u

[SUN Haitao]

Maybe we can integrate the ability to make apps go back (and forward)
into the task manager.

For example, we can use a interface (inspired from David Regev's
'Ubiquitous Firefox' concept[1]) like this:

* The foreground app transforms into a thumbnail on the centre of
screen when the task manager is activated.
* Swiping up/down on this thumbnail make the the foreground app go
back/forward.
* Swiping left/right on this thumbnail switches the the foreground app.

[1]: https://wiki.mozilla.org/User:David_Regev/Ubiquitous_Firefox

[Robert Kaiser]

Chris Jones schrieb:

> My personal opinion is that contextual navigation>> fixed UI like a chrome/HW back button. If that's right, contextual navigation will win and UAs/devices that support that best will win in the market. That is, the better paradigm will kill HW/chrome back buttons.

I like your thinking there. I have a phone without any button at all
(except power and volume up/down at the side if the device), and it
works find, they solved all actions beautifully in on-screen UI (except
for some cases where it looks like they hastily put on a back button
without too much UX thinking and it "wastes" an entire toolbar). I hope
the future goes in that direction at some point.

Robert Kaiser