Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


2012/5/23 Andrew Pullins <android2772@gmail.com>

Mirek,


I'd prefer to stick to the HIG in this case. Almost every other Android
app
uses the form of navigation described in the HIG, and if we don't adhere
to
it, we'll feel alien on the platform.


I knew that you would chime in saying that we should stick to the HIG.
Every other app uses that form of navigation because its in the HIG (that
Is Human Interface * Guidelines* not absolutely must be this way  rules).


The HIG is for keeping some consistency across the platform. No, they don't
have to be followed all the time, but if they aren't followed, then it
causes users some pain, as they're used to certain items being in certain
places, and they're muscle memory is adjusted to that.
For example, LibreOffice could choose to get rid of the "maximize" window
control on Windows because the users could just use Aero Snap to maximize,
but Windows users would be confused and frustrated, as they're used to
Windows applications featuring a maximize button.

LibreOffice will already be alien to the platform for there are no other
apps like it(other then the very very very crappy M$O knockoffs on the
platform). many apps are switching to this new navigation or already have
something similar(springpad, spotify the youversion bible app are two that
I can think of). not to mention that Google's Gmail, and Google maps kinda
use this, like the youversion bible app its not quite the same but its
still similar.


There's a bit of a difference between LibreOffice and the Facebook app here.
The Facebook application doesn't really have a home screen or an overview
screen, so the category picker serves as the overview instead. Because of
that, it's acceptable (though not ideal) that Facebook uses this sidebar
instead.
However, LibreOffice does have a true homescreeen, a true overview -- the
file manager. And that's the screen the Up button should go to.


You yourself linked to an article criticizing Facebook's non-native form
of navigation [1].


I did not actually read the artical I was using it to show what facebook
and spotify do and show what that the google apps do something similar.


I also don't see what advantage this bar would hold for us.


the main advantage is that you do not have to hit the home button then
click new document to create a new document, you could click menu new. that
may not seem like much of a difference but with the way it is now the home
page would have to load before you could click create new document
and seance the current home page is the file manager the user may have many
documents making the home page larger  making the load time longer. with
the Facebook side menu the menu would just pop out and be quite fast.


The file manager shouldn't take any longer to load. The buttons on it
should load immediately and the thumbnails of documents should load
afterwards.


The items in your mockup would be just as accessible elsewhere, in places
deemed
appropriate by the HIG, or wouldn't be necessary at all.

yes thats the point, I could click home load the page then go to (new doc,
templates, or select item print or share or rename). witch wouldn't be
necessary at all? I think you may be talking about rename, print, share,
close options, about? the best part about the side bar is that it could
also hold menu items that you would find in the desktops file menu or
other useful things. not only is it a navigation tool.


That's actually the worst part -- the user wouldn't know where to look for
his tools.
If we follow the HIG, then every button has its rightful place and the user
knows where to look for it.


Under your proposal, it takes two taps to get to each of the items in the
menu (one on the icon, second on the menu item).

When following the HIG: The "File browser" would be accessed using the
"Up"
button with a single
tap. The "New" buttons and "Templates" would be accessed in the file
browser
with two taps -- one tap to get to the browser, one tap on one of the
buttons.


yes to get to the file browser it would take one tap of ether the home
button or the back/up arrow and the app would still use that to navigate.
but it would still take two taps and load time to get to "new" and
"templates". thats more time then two taps.


As I said, the load time would be the same. Thumbnails would load after the
screen and its buttons.


"Rename", "Print", and "Share" are all items that belong in the document's
overflow menu, as they're all actions to be done on the document. The
user shouldn't have to look for them elsewhere.

you say that these should be in the overflow menu because thats where they
are on the desktop because thats where they have always been on the
desktop, but IMHO these options should not be there on the desktop.  on the
table and phone this is stupid to place them there. the split button would
also be a document menu like in your citrus UI, a place where people would
expect to find these items. when I think of tool bar I think it should hold
things like tools to work on a new document, not things I should be doing
to a finished document.


That's where they belong on Android, not on the desktop.
They're not in the toolbar, they're in the overflow menu, which is
appropriate for actions done to a finished document.
And these actions certainly don't fit in a navigation bar.


And here they would be accessed with two taps as well. "Options" belongs in
the overflow menu as well -- two taps.

again why should this be in the overflow menu, because its there on the
desktop, that is not a reason for it to be there.


Because it's there in every other Android app, and the user knows to look
for it there.


I don't think we need an "About" item (and if we did, it belongs in the
overflow as well).

why don't we need an about item. and again it should not be in the overflow
menu. by this time the overflow menu (while for OVERFOW) is way OVERFLOWING
and has too much in there.


That's why we don't need an about item -- it's an unnecessary dialog, and
we already have too many commands.


but we certainly don't want a "Close" item.

yes we most certainly do my good friend, just hitting the home menu on the
phone keys or back arrow a few time does not close the app, and its not a
good thing to keep apps open useing all our users resources. when I want to
close an app I want to do it in the app not some other app. also another
reason  this is in there is think about how you can close the desktop app.
you have clicking the "X,red circal" clicking file > Exit, and you have
ctrl+W or Q. there needs to be many ways to do some things. yes some of
these things could just be placed in the apps menu dialog when the user
hits the phones menu key, but some people do not know that you can do that
all the time, some apps you can not do that all the time.


On Android, you can hit the "multitask" button (it's the third system
button) to see all the running apps and swipe them away to close them.
That's the standard way of doing it on Android, and that's why no Android
application (except perhaps a few shotty ones) features a "Close" button.
Sure, some users may not know about it. Some users may not at all know how
to use the keyboard on the desktop, but that doesn't mean that we should
include a tutorial in LibreOffice on how to use the keyboard. If a person
is using a platform, then we should assume he knows how to work with that
platform.


the side bar is not only a navigation tool but like the file menu and much
more. I was not sure what to place in each screen but all I was trying to
show is that the menu is contextual depending on what screen you are in. we
would need to figure out what all belongs in there.


I feel like this sidebar would frustrate users more than if we follow the
HIG. I still don't see a single advantage of it -- as I demonstrated,
accessing its buttons would be just as slow if not slower as if we used the
UI elements in the HIG. Opening a different document would be much slower.
On the contrary -- this sidebar would be frustrating for users that are
used to the Android platform.

-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.