Nothing forces us to put the back button in the top-left corner of the
screen. The mockups I've seen put it in the bottom left, which should be
closer to your fingers.
And overall I'm not sure what users are expecting. I'm not sure they
care about the tabbed web model so much (tabs scale poorly). But they
need a way to efficiently access new content and to get back to things
they have opened, recently or not so recently.
Fabrice
On 10/21/2015 08:34 AM, eyome wrote:
> I would completely agree with you for a desktop app, but on smartphone,
> it's not the same thing: with a Nexus 5-like, I need to change the
> position of my phone in my hand to reach the top corner left on my phone
> (I am a right hand user).
>
> User story: In the public transport like the bus, I need to take with
> these changes of positions to not drop down my phone (my fear...)->
> sorry for the story...
>
> For a right end user, use a top corner left is logical, yes, but not
> comfortable.
>
> SailfishOS (Jolla) has good idea for these issues, please, you should
> try it.
>
> Tim Guan-tin Chien a écrit :
>> I am for anything that is closer to the Web experience as we know it.
>> I have been saying that since the beginning of the project -- "market
>> expectations" and other reasons unknown to me force us to mock an app
>> experience instead.
>>
>> For the past 10+ years the Web experiences means the following:
>>
>> 0. URLs
>> 1. Linear history navigable with chrome
>> 2. Tabs, and easily switching between tabs
>>
>> To this day I don't really understand why we are not built on this
>> reliable and familiar origin.
>>
>> On 2010. Mozilla Labs published a heat map showed 95% of the Firefox
>> users clicks the Back button [a]. 95% means it ranks all the way at
>> the top.
>>
>> [a] https://heatmap.mozillalabs.com/
>>
>> So yeah, if there is a place for back button we should definitely put
>> one for the purpose of (1) above.
>>
>> By focus on the 3 points mentioned, and do it right, we can proudly
>> say whatever Web App works well on the Web will work well on Firefox
>> OS. That's what user expects on a browser, *regardless of* and UI the
>> sites offers.
>>
>> On a technical note, and as a user, I don't really care how app are
>> engineered as long as it works with that back button. Single page web
>> app with hashes works with it. URL writes with history API could do
>> the magic too. It's better to have pre-rendering and other magical
>> stuff claimed by NGA but it will fit into the same navigation model
>> anyway.
>>
>> Obviously screen estate is valuable -- I have faith in our UX team to
>> get it right. However I personally thinks (2) is equally important as
>> well so I won't re-map edge swipe back to history navigation, as
>> Przemak suggests, and keep it as gestures to continue to switching
>> between "Tabs" (AppWindow in Gaia System).
>>
>> User interface is a conversation between the machine and the user,
>> let's start with some familiar warm welcome and build on top of that.
>>
>>
>> Tim
>>
>>
>> On Wed, Oct 21, 2015 at 10:01 PM, Przemek Abratowski
>> <[email protected]> wrote:
>>
>> As Wilson mentioned currently in Alopex we're trying out a back
>> button in the soft home key area that we're using as the bottom
>> bar of the browser chrome. The back button would be used to
>> navigate history, and fade away when the user is at the start of
>> his browsing history. Also we can use swiping left and right from
>> the screens edge to navigate between history.
>>
>> We're also looking at solution for full page games or web apps.
>> We're trying to make the experience feel like the user is always
>> in a browser as much as possible so easy access to the chrome from
>> anywhere is something we're focusing on, and at the same time
>> we're not trying to take up unnecessary permanent screen space.
>>
>> I'll attach some very early mock ups of the browser chrome. Please
>> note that the top URL bar would hide on scroll or sometimes right
>> after loading a web app, and that the bottom bar is the soft home
>> key area.
>>
>> This solution is currently focused at devices with a soft home
>> key, for devices with a physical home button we'd remove the home
>> button from the bottom bar and let that chrome also hide when needed.
>>
>>
>> Don't be alarmed at the dark browser chrome in this pic, we're
>> still iterating on both dark and white versions.
>>
>> Przemek
>>
>>
>>
>>
>> On Wed, Oct 21, 2015 at 9:24 AM, Mihai Barbat <[email protected]>
>> wrote:
>>
>> Hi all,
>>
>> The problem with swipe from the middle is that it's not a
>> back! Right now it switches to another running application.
>> Ah, and it's also slow, at least on my Flame.
>>
>> On Wed, Oct 21, 2015 at 3:17 PM, eyome <[email protected]>
>> wrote:
>>
>> Hi all,
>>
>> to honest, I am against to add a back button to the home
>> bar: I would prefer a swippe from the middle to the right
>> of the screen.
>>
>> I feel this elegant and really comfortable, please,
>> considere it. It avoids to add another button on the home
>> bar (and I could still using "home bar plus" add-on and
>> his "kill app" button...).
>>
>>
>> Sam Giles a écrit :
>>> +1
>>>
>>> It seems wrong to have to build navigation into web apps
>>> when the platform has more than adequate support for it.
>>> As an app developer I dislike the idea of having to
>>> provide my own mechanism to 'go back' to the previous
>>> view. As a user it can be frustrating, each app
>>> implementing navigation in a subtly different way.
>>>
>>> These ideas would definitely be good to try out in Alopex.
>>>
>>> Sam
>>>
>>> On Wed, Oct 21, 2015 at 1:51 PM, Wilson Page
>>> <[email protected]> wrote:
>>>
>>> I'm in favour of this model so long as it doesn't
>>> intrude on app developer real-estate with extra
>>> chrome. From the early visuals we've seen from Alopex
>>> it appeared that the back button would live in the
>>> footer bar with the home button, which seems like a
>>> good solution :)
>>>
>>> It might be nice to have this button appear only when
>>> there is history state to navigate back to. Or
>>> perhaps when there is no history the button does
>>> something else, like closing the app/tab?
>>>
>>> *W I L S O N P A G E*
>>>
>>> Front-end Developer
>>> Firefox OS (Gaia)
>>> London Office
>>>
>>> Twitter: @wilsonpage
>>> IRC: wilsonpage
>>>
>>> On Wed, Oct 21, 2015 at 1:30 PM, Michael Henretty
>>> <[email protected]> wrote:
>>>
>>> Hi Gaia folk,
>>>
>>> In the early days of Firefox OS, we built all of
>>> Gaia as single-page apps. I wasn't around then
>>> but I imagine we did this for a number of
>>> reasons, with performance and responsiveness at
>>> the top of the list. As part of this, we
>>> encouraged app developers to implement navigation
>>> controls in their own apps and not rely on
>>> browser chrome functionality like "back" and
>>> "refresh". This totally made sense in the context
>>> of a single-page app, especially when you take
>>> into account that native apps on iOS and Android
>>> (albeit to a lesser extent) have to implement
>>> their own navigation as well.
>>>
>>> But with more recent technologies like Service
>>> Workers, better caching APIs, pre-rendering, etc.
>>> (basically all the stuff that NGA takes advantage
>>> of), I think the web is shifting away from
>>> single-page apps as a performance workaround. And
>>> let's not forget that single-page apps often
>>> negate one of the webs biggest strengths: deep
>>> linking.
>>>
>>> So I write this email today as sort of an opinion
>>> poll. Personally, I think it's time we bring back
>>> the browser chrome into Firefox OS apps. I think
>>> we should encourage developers to write URL-based
>>> apps, to not be afraid of browser chrome
>>> navigation, and therefore to build their Firefox
>>> OS app as a standard website + some experimental
>>> (or proprietary :/) APIs.
>>>
>>> There has been some discussion around this with
>>> the work we are doing on Pinning the Web and
>>> Alopex. But I want to hear from the greater FxOS
>>> community too, especially those with app
>>> development experience. What do you think, should
>>> we bring the "back" button back?
>>>
>>> -Michael
>>>
>>> _______________________________________________
>>> dev-fxos mailing list
>>> [email protected]
>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>
>>>
>>>
>>> _______________________________________________
>>> dev-fxos mailing list
>>> [email protected]
>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>
>>>
>> Envoyé depuis Firefox OS
>>
>>
>> _______________________________________________
>> dev-fxos mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-fxos
>>
>>
>>
>> _______________________________________________
>> dev-fxos mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-fxos
>>
>>
>>
>> _______________________________________________
>> dev-fxos mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-fxos
>>
>>
> Sent Using Firefox OS
>
>
>
> _______________________________________________
> dev-fxos mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-fxos
>
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
