On 27/11/2015 09:57, Adam Farden wrote:
(sorry Enrico for the double mail, I forgot to reply to all)
> I think an OS should provide all of this functions when needed, in a
structured and consistent way.
The fallacy here is that you're trying to force these different types
of action into separate functions, making some of it optional, then
depending on Apps to provide the rest of that fundamental navigation
instead of the OS providing it. The OS should provide all of these
functions /at all times/, not just 'when needed'. The OS is clearly
not smart enough to get the 'when needed' part correct, and relying on
Apps to fill in the holes of OS navigation makes a poor OS.
You have a point, but trying to merge these functions at all cost brings
his own set of problem.
Idea: a back button that performs a default back depending on the
context, like on Android, but when long-pressed, will let the user
choose which "back action" he wants (ctrl+z, back one page, back one app
etc...). Would that cover your need while avoiding weird behaviour?
Btw, this is not incompatible with edge gestures to switch app. We could
have both (I'd miss edge gestures for sure, I really love them, even
with the problems you guys described).
That would also have the advantage of moving away the back button from
the headers of applications, ie having the back button nearer the thumb.
Augustin Trancart
Phoxygen
> Secondly, the [return to app] functionality in FxOS is provided by
the App Manager and the edge-swipe gesture.
The fallacy here is that the edge-swipe gesture is not always
available to the user. It is by definition always hidden from the user
who has to be taught this action, it can be completely disabled in
Settings, and hardware accessories or even the hardware itself can
make using edge gestures impossible.
The global back button is always visible, is always in one location,
and always performs the same action: 'go back one step'. The 'go back
one step' action is all that is required for the vast majority of Apps
and use cases.
Browsers are probably the only exception to this as they should
probably provide back and forward navigation, which is what we
generally expect from browsers. This is why Chrome on Android provides
an additional, optional back button next to the forward button, to
keep similar navigation UI close together. As far as I can tell,
Internet Explorer on Windows Mobile goes one step further and relies
solely on the global back button.
And BTW it's not just Android that has the global back button, it's
also Windows Mobile, Symbian, and pretty much every single feature
phone ever built. iOS is the exception to the rule, meaning FxOS has
an alien, broken navigation system to anyone who comes to FxOS from
anything that isn't iOS.
> Long story short, I think that FxOS already implements most forms of "back/undo" in a
structured way, provided that the back button inside apps is used
consistently with the browser's "back in history" button. This
function could be assigned to an Android-style homebar back button,
but I see no particular benefit in that.
Yes, FxOS does implement some forms of a back button. However it does
not do it well. It does not implement all of them. It does not do it
in a way that meets a new user's expectations. It does not do it in a
way that is always obvious and always available.
The overall point here isn't that it may or may not make technical
sense for our particular OS. It is all about meeting user expectation.
If you do not see the value in providing functionality that 90% of new
users will expect then there is something very very wrong. Are we
trying to build something amazing for the world to use or just
something special for our little group?
Think of the real world we live in. In fact I can give a real example.
In the country where I live, 90% of smartphones do not run iOS. in
fact only 45% of cell phones are even considered smartphones. This
means 95.5% of all people who use any kind of cell phone expect there
to be a back button. 95.5% of people in my country will likely reject
FxOS because of what they perceive as a lack of fundamental navigation.
http://www.ceeitandtelecom.com/news/247701/o2-czech-republic-75-of-smartphones-with-android
Just look at Microsoft. Windows 8 on the desktop was considered a
failure, simply because of it's unusual ,different, and unexpected
navigation. However Microsoft listened for Windows 10, changed
everything back to user expectations and is considered a comeback success.
In fact this is the exact analogy for our system right now. Our
methods of navigation do not meet the majority expectation. We should
change to meet that majority expectation, regardless of how we feel
about it technically.
On Fri, Nov 27, 2015 at 12:24 AM, Enrico Ghiorzi
<[email protected] <mailto:[email protected]>> wrote:
Il giorno giovedì 26 novembre 2015 15:11:02 UTC+1, Enrico Ghiorzi
ha scritto:
> I also have something it's puzzling me, but I can't manage to
put my finger on it. Much has been said about an Android-style
back button: there's even even an add-on to add that to the
homebar. Let's call this a 'navigation' back button, as it brings
you to the structurally-previous view inside an app. Then there is
the 'history' back button implemented in the browser. At last,
there is the 'Ctrl-z-style' back button, as described in
https://www.fastcodesign.com/3053406/how-apple-is-giving-design-a-bad-name
as a great feature Apple dismissed. Each OS has to implement (or
dismiss) these three kinds of back functions, which are somewhat
similar but still different. Is there a sensible way to implement
this all in a structural way? How this plays with FxOS and its
agenda? I have no answer here, but maybe some of you have.
After some thought I may have wrapped my head around this, so I'll
try to articulate. Please bear with me if I say stupid/obvious things!
I can think of four different kinds of "back/undo" action:
a) Navigation back button, which brings you to the structurally
precedent view inside an app.
a') History back button, as it works in browsers.
b) Return to the app you were using before the current one; or, in
a browser, return to the previous tab.
c) Undo last action, like "Ctrl-z" does on desktop.
I think an OS should provide all of this functions when needed, in
a structured and consistent way.
First of all, observe that (a) and (a') coincide when the history
back button is the only way to navigate backwards inside an app.
This is already mostly done in FxOS: most apps use a back button
on the left of the header which looks exactly like browser's back
button. The single apps are responsible for using this back button
consistently (and at present they mostly do that, I think).
Secondly, the (b) functionality in FxOS is provided by the App
Manager and the edge-swipe gesture (which, as others here noticed,
has issues on its own which should be addressed).
We are left then with the (c) functionality, which seems to be
completely absent in FxOS. These are the use-cases I can think of:
- Restoring deleted objects (such as messages, e-mails, contacts,
pictures, videos, audio files, and apps)
- Restoring default settings
- Restoring deleted text
I think most, if not all, of these scenarios could be subject to
an ad-hoc solution managed by the involved app: whenever you
delete a picture, there you have a "restore picture" button where
the picture was before, and analogously with messages, e-mails,
contacts, videos, audio files, and apps. Alternatively, a "trash
bin" app could be implemented, storing deleted objects and letting
the user restore them. The Settings app could have "Restore
default settings" buttons where most needed, and so each app in
its own settings menu. Finally, a "Ctrl-z" key could be added to
the keyboard to restore deleted text.
Long story short, I think that FxOS already implements most forms
of "back/undo" in a structured way, provided that the back button
inside apps is used consistently with the browser's "back in
history" button. This function could be assigned to an
Android-style homebar back button, but I see no particular benefit
in that.
App switching is an important form of navigation which should be
improved even further, solving the issues that have been reported.
What is still missing is an error recovery, "Ctrl-z" style back
button. This can be done in different but equivalently useful
ways. A beneficial effect of that, other than indulgently letting
the user recover from mistakes, would be that "Are you sure you
want to delete this" confirmation screens would no longer be
necessary, making interaction faster.
_______________________________________________
dev-fxos mailing list
[email protected] <mailto:[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
