Quantcast

SIdebar Navigation

classic Classic list List threaded Threaded
13 messages Options
Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

SIdebar Navigation

Hello,

I do not like the home button in the top right of the LibreOffice mobile
app. I know that it is in the Android HIG to do it like this but I feel as
though it is not the most efficient way and think we
should consider another method. IMHO Facebook has figured out the best(or
at least a better way) of doing this. In the latest update for the Facebook
app the home button has been replaced with a side bar pop out navigation
button in which allows you to do more than just going to the home page. It
not only shows you the home, but it also can bring you to your profile,
messages, friends... and many other options.  This is much better then just
going straight to home.

So I purpose that we use this form of navigation. I have made my proposal
on my user page here [1].
cheers,
Andrew

[1]
https://wiki.documentfoundation.org/User:Android272#Navigation

--
Unsubscribe instructions: E-mail to [hidden email]
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

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

Hi Andrew,

2012/5/23 Andrew Pullins <[hidden email]>

> Hello,
>
> I do not like the home button in the top right of the LibreOffice mobile
> app. I know that it is in the Android HIG to do it like this but I feel as
> though it is not the most efficient way and think we
> should consider another method. IMHO Facebook has figured out the best(or
> at least a better way) of doing this. In the latest update for the Facebook
> app the home button has been replaced with a side bar pop out navigation
> button in which allows you to do more than just going to the home page. It
> not only shows you the home, but it also can bring you to your profile,
> messages, friends... and many other options.  This is much better then just
> going straight to home.
>
So I purpose that we use this form of navigation. I have made my proposal
> on my user page here [1].
> cheers,
> Andrew
>
> [1]
> https://wiki.documentfoundation.org/User:Android272#Navigation
>

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. You yourself linked to an article
criticizing Facebook's non-native form of navigation [1].
I also don't see what advantage this bar would hold for us. 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.
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.
"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. And here they would be accessed
with two taps as well.
"Options" belongs in the overflow menu as well -- two taps.
I don't think we need an "About" item (and if we did, it belongs in the
overflow as well), but we certainly don't want a "Close" item.

[1] http://alexanderblom.se/2012/04/23/android-navigation-and-spotify/

--
Unsubscribe instructions: E-mail to [hidden email]
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

Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

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).
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.


> 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 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.


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.

"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.

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.


> 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.

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.

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.

cheers,
Andrew

--
Unsubscribe instructions: E-mail to [hidden email]
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

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

2012/5/23 Andrew Pullins <[hidden email]>

> 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 [hidden email]
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

Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

Mirek,

> > 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.

It's not that much different, click home or click menu > home. Wow what a
pain that was I had to tap twice.

> 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.

First Window$ has that to. Second windows has had many many yeas to ingrain
things into users minds. These tablets have not even been out an entire
decade. Who knows google may even change the HIG to this new way of
navigating. Some apps have already adopted the Facebook menu and I think
many more will and soon that will not be so alien.

> 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.

Facebook once did have a home screen and it was horrible.

> Because of that, it's acceptable (though not ideal) that Facebook uses
this sidebar
> instead.

I think it was the best solution.

> However, LibreOffice does have a true homescreeen, a true overview -- the
> file manager. And that's the screen the Up button should go to.

Are you talking about the phones back arrow or the home button? Because the
up button sounds weird.

> 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.

Yah it shouldn't bit most likely ummm will... Even if you make it work the
way you say.

> 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.

Ok out of all my apps on my phone only tree of them had some kind of
overflow menu. One being gmail witch is one of nine google applications. So
I'm not sure how much users are used to looking in the overflow menu. Could
you tell me of some apps that you have that uses them.

> > 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.

I know how this would work and I still think an application like ours would
take longer to load then you think or users want. Especially when the users
have many files.

> > 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.

I think I may have been thinking Bout a different overflow menu, ether way
I don't think it make much since.

> > 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 know of many apps that use it so give me some examples.

> > 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.

Ok I was thinking the toolbar overflow and the application overflow was the
same overflow witch having it there would be too many options.

> > > 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.

On my phone Pandora, two irc clients, att navigator, car panel, dock mobile
has button , pocket band, and radiou has button, all have exit menus or
buttons.

> > 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.

have you seen how fast the side menu pops out. You make it seem like
creating a new document would be like
tap...............................tap, when it would be more like tap..tap
or tap tap it the get used to it.

> 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.

I don't think this menu is frustrating at all. If we can get some better
examples in it I think you would see the benefit. It would be more
beneficial when editing a document then in the manager or viewer. But since
we are one shipping these views right now that's all I did.

--
Unsubscribe instructions: E-mail to [hidden email]
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

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

2012/5/23 Andrew Pullins <[hidden email]>

> Mirek,
>
> > > 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.
>
> It's not that much different, click home or click menu > home. Wow what a
> pain that was I had to tap twice.
>

It is a bother, because you're not used to it. It's as if clicking the
"Maximize" button on a window in LibreOffice gave you a menu every time,
with one of the items in the menu being "Maximize". It's bothersome to have
to tap twice when in every other app you just tap once.

>
> > 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.
>
> First Window$ has that to. Second windows has had many many yeas to ingrain
> things into users minds. These tablets have not even been out an entire
> decade. Who knows google may even change the HIG to this new way of
> navigating. Some apps have already adopted the Facebook menu and I think
> many more will and soon that will not be so alien.
>

The HIG is there for a reason -- to maintain consistency across the
platform. Android's HIG has been released only recently and not all app
developers have had time to adjust their UIs to it. That doesn't mean we
should respect it.
If app developers choose not to respect it, Android will be a mess of
different UIs.

On the Mac, all apps have menubars at the top. On Windows, they have them
below the title bar. There are advantages to both. In order to maintain
consistency, LibreOffice has menubars below the title bar on Windows and at
the top of the screen on the Mac. Think how annoying it would be if
LibreOffice put your menus below the titlebar on the Mac when every other
app has them at the top of the screen.

>
> > 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.
>
> Facebook once did have a home screen and it was horrible.
>

Then they designed it badly. Frankly, the Facebook sidebar could be easily
turned into a separate screen -- it wouldn't be that different
The Google+ app has a homescreen. It's especially awesome on its new iOS
release (http://theflickcast.com/wp-content/uploads//google-plus-ios-new.jpgcoming
soon to Android as well).

>
> > Because of that, it's acceptable (though not ideal) that Facebook uses
> this sidebar
> > instead.
>
> I think it was the best solution.
>
> > However, LibreOffice does have a true homescreeen, a true overview -- the
> > file manager. And that's the screen the Up button should go to.
>
> Are you talking about the phones back arrow or the home button? Because the
> up button sounds weird.
>

http://developer.android.com/design/patterns/navigation.html

>
> > 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.
>
> Yah it shouldn't bit most likely ummm will... Even if you make it work the
> way you say.
>

It will take exactly the same time to load if the thumbnails aren't loaded
up front.

>
> > 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.
>
> Ok out of all my apps on my phone only tree of them had some kind of
> overflow menu. One being gmail witch is one of nine google applications. So
> I'm not sure how much users are used to looking in the overflow menu. Could
> you tell me of some apps that you have that uses them.
>

You probably have a phone with a hardware menu button. In that case, you
don't see the overflow menu. Or maybe you don't have Ice Cream Sandwich yet.
The overflow should be present in all 9 apps from Google.

>
> > > 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.
>
> I know how this would work and I still think an application like ours would
> take longer to load then you think or users want. Especially when the users
> have many files.
>

It doesn't matter how many files the user has. The file list will load
after the screen and action bars are loaded.

>
> > > 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.
>
> I think I may have been thinking Bout a different overflow menu, ether way
> I don't think it make much since.
>

Sorry, I don't understand this.

>
> > > 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 know of many apps that use it so give me some examples.
>

All of the default apps, Google+, Boid, Firefox, Chrome, Google Drive, etc.
Take a look at the website http://holoeverywhere.com/ where a lot of other
apps are listed.

>
> > > 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.
>
> Ok I was thinking the toolbar overflow and the application overflow was the
> same overflow witch having it there would be too many options.
>

How so?
Remember that contextual actions would be shown as a contextual action bar,
and therefore contextual actions (like text formatting) and non-contextual
actions (search, save, print) don't mix.

>
> > > > 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.
>
> On my phone Pandora, two irc clients, att navigator, car panel, dock mobile
> has button , pocket band, and radiou has button, all have exit menus or
> buttons.
>

These are old designs back from times when there was no easy way to quit
apps. It's a remain of the pre-Holo era, not something we want to follow.

>
> > > 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.
>
> have you seen how fast the side menu pops out. You make it seem like
> creating a new document would be like
> tap...............................tap, when it would be more like tap..tap
> or tap tap it the get used to it.
>

Again, opening the overview wouldn't be slower. The user would also be used
to the new buttons always being on the bottom of the screen, and therefore
could push them faster (whereas they're harder to target in the menu).

>
> > 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.
>
> I don't think this menu is frustrating at all. If we can get some better
> examples in it I think you would see the benefit. It would be more
> beneficial when editing a document then in the manager or viewer. But since
> we are one shipping these views right now that's all I did.


I don't understand the last sentence.

--
Unsubscribe instructions: E-mail to [hidden email]
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

Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

Mirek,

> It's not that much different, click home or click menu > home. Wow what a
> > pain that was I had to tap twice.
> >
>
> It is a bother, because you're not used to it. It's as if clicking the
> "Maximize" button on a window in LibreOffice gave you a menu every time,
> with one of the items in the menu being "Maximize". It's bothersome to have
> to tap twice when in every other app you just tap once.
>

its not not going to bother people


> > First Window$ has that to. Second windows has had many many yeas to
> ingrain
> > things into users minds. These tablets have not even been out an entire
> > decade. Who knows google may even change the HIG to this new way of
> > navigating. Some apps have already adopted the Facebook menu and I think
> > many more will and soon that will not be so alien.
> >
>
> The HIG is there for a reason -- to maintain consistency across the
> platform. Android's HIG has been released only recently and not all app
> developers have had time to adjust their UIs to it. That doesn't mean we
> should respect it. If app developers choose not to respect it, Android
> will be a mess of
> different UIs.
>
> On the Mac, all apps have menubars at the top. On Windows, they have them
> below the title bar. There are advantages to both. In order to maintain
> consistency, LibreOffice has menubars below the title bar on Windows and at
> the top of the screen on the Mac. Think how annoying it would be if
> LibreOffice put your menus below the titlebar on the Mac when every other
> app has them at the top of the screen.
>

this is still completely different, tablet and phone OS's have not been out
very long(this includes Android, iOS, blackberry, webOS all of them) there
is no best way to do things and things will change all the time till
everyone(not Google and apple but the app developers) decide how we are
going to do things.

the iOS just stole Androids notification menu, Android just stole the
webOS's multitasking menu. Im sure that every one is taking ideas form
everyone and things are going to change.



> > Facebook once did have a home screen and it was horrible.
>
> Then they designed it badly.


the side bar or the home screen?


> Frankly, the Facebook sidebar could be easily turned into a separate screen


thats what I said, everything in the home screen is now in the side bar and
much, much more.

http://www.google.com/imgres?um=1&hl=en&sa=N&rlz=1C1CHFX_enUS485&biw=1280&bih=643&tbm=isch&tbnid=QzV68I9CPGyL6M:&imgrefurl=http://www.askdavetaylor.com/access_facebook_fan_pages_on_apple_iphone.html&docid=9curbUzGAAQTZM&imgurl=http://www.askdavetaylor.com/4-blog-pics/facebook-iphone-home-screen.png&w=320&h=480&ei=QH29T73SCMiI6AHSv7w0&zoom=1&iact=rc&dur=157&sig=109770077488246810252&page=1&tbnh=128&tbnw=86&start=0&ndsp=18&ved=1t:429,r:0,s:0,i:78&tx=39&ty=78


> -- it wouldn't be that different The Google+ app has a homescreen. It's
> especially awesome on its new iOS release (
> http://theflickcast.com/wp-content/uploads//google-plus-ios-new.jpgcoming
> soon to Android as well).
>

this link shows nothing?

http://googleblog.blogspot.com/2012/05/google-mobile-app-with-sense-and-soul.html

does the "Home" button in this picture switch to the second screen?
http://theflickcast.com/wp-content/uploads//google-plus-ios-new.jpg

then they once again do not follow their own HIG.


> > Because of that, it's acceptable (though not ideal) that Facebook uses
> > this sidebar
> > > instead.
> >
> > I think it was the best solution.
> >
> > > However, LibreOffice does have a true homescreeen, a true overview --
> the
> > > file manager. And that's the screen the Up button should go to.
> >
> > Are you talking about the phones back arrow or the home button? Because
> the
> > up button sounds weird.
> >
>
> http://developer.android.com/design/patterns/navigation.html


yes Iv seen this many many times. you post it every time we talk anything
Android. its quite confusing as well, the "Home" or "UP" button does not
always go to the HOME page.

"You have the ability to make the Up behavior even smarter based on your
knowledge of detail view. Extending the Play Store example from above,
imagine the user has navigated from the last Book viewed to the details for
the Movie adaptation. In that case, Up can return to a container (Movies)
which the user hasn't previously navigated through."

that would confuse me only every time it happens. especially seance it
would not happen much.


> > > 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.
> >
> > Yah it shouldn't bit most likely ummm will... Even if you make it work
> the
> > way you say.
> >
>
> It will take exactly the same time to load if the thumbnails aren't loaded
> up front.
>

then why does it even matter.

> > 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.
> >
> > Ok out of all my apps on my phone only tree of them had some kind of
> > overflow menu. One being gmail witch is one of nine google applications.
> So
> > I'm not sure how much users are used to looking in the overflow menu.
> Could
> > you tell me of some apps that you have that uses them.
> >
>
> You probably have a phone with a hardware menu button. In that case, you
> don't see the overflow menu. Or maybe you don't have Ice Cream Sandwich
> yet.
> The overflow should be present in all 9 apps from Google.
>

I has Ice Cream Sadwich and a phone that has a hardware menu button.

> > > 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.
> >
> > I know how this would work and I still think an application like ours
> would
> > take longer to load then you think or users want. Especially when the
> users
> > have many files.
> >
>
> It doesn't matter how many files the user has. The file list will load
> after the screen and action bars are loaded.
>

ok what ever.

> > > 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.
> >
> > I think I may have been thinking Bout a different overflow menu, ether
> way
> > I don't think it make much since.
> >
>
> Sorry, I don't understand this.
>

our app has its own overflow menus in the tool bar and you say it will also
have one at the end for users that do not  have the hardware menu button.


> > > > 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 know of many apps that use it so give me some examples.
> >
>
> All of the default apps, Google+, Boid, Firefox, Chrome, Google Drive, etc.
> Take a look at the website http://holoeverywhere.com/ where a lot of other
> apps are listed.
>

ok, they say that this is how Facebook should have been.
http://fc05.deviantart.net/fs70/f/2012/095/2/9/295db2cf5d52eb63f78e7b1e0dbf1203-d4v44wc.jpg

so here you only have Events, Photos, Friends, and Groups. where as now the
have all those AND the ability to go to News Feeds, Messages, Nearby,
Notes, a specificity group or see all groups, Apps, pages, list such as
close friends then see all, account, and help center.

id much more prefer that then just then just the four.



> > > > 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.
> >
> > Ok I was thinking the toolbar overflow and the application overflow was
> the
> > same overflow witch having it there would be too many options.
> >
>
> How so?
> Remember that contextual actions would be shown as a contextual action bar,
> and therefore contextual actions (like text formatting) and non-contextual
> actions (search, save, print) don't mix.
>

I miss understood what overflow you were talking about.


> > > > > 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.
> >
> > On my phone Pandora, two irc clients, att navigator, car panel, dock
> mobile
> > has button , pocket band, and radiou has button, all have exit menus or
> > buttons.
> >
>
> These are old designs back from times when there was no easy way to quit
> apps. It's a remain of the pre-Holo era, not something we want to follow.
>



> > > > 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.
> >
> > have you seen how fast the side menu pops out. You make it seem like
> > creating a new document would be like
> > tap...............................tap, when it would be more like
> tap..tap
> > or tap tap it the get used to it.
> >
>
> Again, opening the overview wouldn't be slower. The user would also be used
> to the new buttons always being on the bottom of the screen, and therefore
> could push them faster (whereas they're harder to target in the menu).
>

how so?

> > 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.
> >
> > I don't think this menu is frustrating at all. If we can get some better
> > examples in it I think you would see the benefit. It would be more
> > beneficial when editing a document then in the manager or viewer. But
> since
> > we are one shipping these views right now that's all I did.
>
>
> I don't understand the last sentence.
>

we are not going to have the full blown writer just a document viewer for
now.

Andrew

--
Unsubscribe instructions: E-mail to [hidden email]
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

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

2012/5/24 Andrew Pullins <[hidden email]>

> Mirek,
>
> > It's not that much different, click home or click menu > home. Wow what a
> > > pain that was I had to tap twice.
> > >
> >
> > It is a bother, because you're not used to it. It's as if clicking the
> > "Maximize" button on a window in LibreOffice gave you a menu every time,
> > with one of the items in the menu being "Maximize". It's bothersome to
> have
> > to tap twice when in every other app you just tap once.
> >
>
> its not not going to bother people
>

Exactly (though I assume you didn't actually mean that double-negative).

>
>
> > > First Window$ has that to. Second windows has had many many yeas to
> > ingrain
> > > things into users minds. These tablets have not even been out an entire
> > > decade. Who knows google may even change the HIG to this new way of
> > > navigating. Some apps have already adopted the Facebook menu and I
> think
> > > many more will and soon that will not be so alien.
> > >
> >
> > The HIG is there for a reason -- to maintain consistency across the
> > platform. Android's HIG has been released only recently and not all app
> > developers have had time to adjust their UIs to it. That doesn't mean we
> > should respect it. If app developers choose not to respect it, Android
> > will be a mess of
> > different UIs.
> >
> > On the Mac, all apps have menubars at the top. On Windows, they have them
> > below the title bar. There are advantages to both. In order to maintain
> > consistency, LibreOffice has menubars below the title bar on Windows and
> at
> > the top of the screen on the Mac. Think how annoying it would be if
> > LibreOffice put your menus below the titlebar on the Mac when every other
> > app has them at the top of the screen.
> >
>
> this is still completely different, tablet and phone OS's have not been out
> very long(this includes Android, iOS, blackberry, webOS all of them) there
> is no best way to do things and things will change all the time till
> everyone(not Google and apple but the app developers) decide how we are
> going to do things.
>

No, the developers don't get to decide. They need to follow the HIG --
that's what it's for.
It doesn't matter if the platform is new.
Actually, if it is, then it's even more important to follow the HIG. if
developers don't, it's going to be one mess of a platform.

>
> the iOS just stole Androids notification menu, Android just stole the
> webOS's multitasking menu. Im sure that every one is taking ideas form
> everyone and things are going to change.


None of these change the GUI of an application.
It's very likely that there aren't going to be huge HIG changes for Android
coming. With Android 3 and 4, Google has invested a lot of time and effort
into Android design, and the HIG is the fruit of that.

>
> > > Facebook once did have a home screen and it was horrible.
> >
> > Then they designed it badly.
>
> the side bar or the home screen?
>

The home screen.

>
> > Frankly, the Facebook sidebar could be easily turned into a separate
> screen
>
> thats what I said, everything in the home screen is now in the side bar and
> much, much more.
>

I meant that if the Facebook app removed the sliver of content on the right
side of the screen, the sidebar would be a screen in its own worth.
http://alexanderblom.se/images/facebook-ios.jpeg

The "Stream" button uses a home icon and goes to the stream.
The "Up" button isn't meant to take you "Home", it's meant to take you
"Up", to the parent screen.
>From Google's own design guidelines:
"The Up button is used to navigate within an app based on the hierarchical
relationships between screens. For instance, if screen A displays a list of
items, and selecting an item leads to screen B (which presents that item in
more detail), then screen B should offer an Up button that returns to
screen A.

If a screen is the topmost one in an app (that is, the app's home), it
should not present an Up button."

>
> > > Because of that, it's acceptable (though not ideal) that Facebook uses
> > > this sidebar
> > > > instead.
> > >
> > > I think it was the best solution.
> > >
> > > > However, LibreOffice does have a true homescreeen, a true overview --
> > the
> > > > file manager. And that's the screen the Up button should go to.
> > >
> > > Are you talking about the phones back arrow or the home button? Because
> > the
> > > up button sounds weird.
> > >
> >
> > http://developer.android.com/design/patterns/navigation.html
>
>
> yes Iv seen this many many times. you post it every time we talk anything
> Android. its quite confusing as well, the "Home" or "UP" button does not
> always go to the HOME page.
>

Right. It's not the home button, it shouldn't go to the home page.
It's the Up button. It should go up in hierarchy, which it always does.

>
> "You have the ability to make the Up behavior even smarter based on your
> knowledge of detail view. Extending the Play Store example from above,
> imagine the user has navigated from the last Book viewed to the details for
> the Movie adaptation. In that case, Up can return to a container (Movies)
> which the user hasn't previously navigated through."
>
> that would confuse me only every time it happens. especially seance it
> would not happen much.


It's not confusing once you understand the button means "Up", not "Back" or
"Home".

>


> > > > 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.
> > >
> > > Yah it shouldn't bit most likely ummm will... Even if you make it work
> > the
> > > way you say.
> > >
> >
> > It will take exactly the same time to load if the thumbnails aren't
> loaded
> > up front.
> >
>
> then why does it even matter.
>

You say that the advantage of a sidebar would be that it would load much
faster than the file manager.
I'm saying that it wouldn't.

>
> > > 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.
> > >
> > > Ok out of all my apps on my phone only tree of them had some kind of
> > > overflow menu. One being gmail witch is one of nine google
> applications.
> > So
> > > I'm not sure how much users are used to looking in the overflow menu.
> > Could
> > > you tell me of some apps that you have that uses them.
> > >
> >
> > You probably have a phone with a hardware menu button. In that case, you
> > don't see the overflow menu. Or maybe you don't have Ice Cream Sandwich
> > yet.
> > The overflow should be present in all 9 apps from Google.
> >
>
> I has Ice Cream Sadwich and a phone that has a hardware menu button.
>

That explains it, then. You're not seeing the software action overflow
button because the hardware menu button launches the menu instead.

>
> > > > 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.
> > >
> > > I know how this would work and I still think an application like ours
> > would
> > > take longer to load then you think or users want. Especially when the
> > users
> > > have many files.
> > >
> >
> > It doesn't matter how many files the user has. The file list will load
> > after the screen and action bars are loaded.
> >
>
> ok what ever.
>
> > > > 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.
> > >
> > > I think I may have been thinking Bout a different overflow menu, ether
> > way
> > > I don't think it make much since.
> > >
> >
> > Sorry, I don't understand this.
> >
>
> our app has its own overflow menus in the tool bar and you say it will also
> have one at the end for users that do not  have the hardware menu button.


What?
Our action bar will have one action overflow.
Its contents will change based on the selection (i.e. when you select Text,
it will show text actions).

>
> > > > > 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 know of many apps that use it so give me some examples.
> > >
> >
> > All of the default apps, Google+, Boid, Firefox, Chrome, Google Drive,
> etc.
> > Take a look at the website http://holoeverywhere.com/ where a lot of
> other
> > apps are listed.
> >
>
> ok, they say that this is how Facebook should have been.
>
> http://fc05.deviantart.net/fs70/f/2012/095/2/9/295db2cf5d52eb63f78e7b1e0dbf1203-d4v44wc.jpg
>
> so here you only have Events, Photos, Friends, and Groups. where as now the
> have all those AND the ability to go to News Feeds, Messages, Nearby,
> Notes, a specificity group or see all groups, Apps, pages, list such as
> close friends then see all, account, and help center.
>
> id much more prefer that then just then just the four.


> > > > > 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.
> > >
> > > Ok I was thinking the toolbar overflow and the application overflow was
> > the
> > > same overflow witch having it there would be too many options.
> > >
> >
> > How so?
> > Remember that contextual actions would be shown as a contextual action
> bar,
> > and therefore contextual actions (like text formatting) and
> non-contextual
> > actions (search, save, print) don't mix.
> >
>
> I miss understood what overflow you were talking about.
>
> > > > > > 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.
> > >
> > > On my phone Pandora, two irc clients, att navigator, car panel, dock
> > mobile
> > > has button , pocket band, and radiou has button, all have exit menus or
> > > buttons.
> > >
> >
> > These are old designs back from times when there was no easy way to quit
> > apps. It's a remain of the pre-Holo era, not something we want to follow.
> >
>
>
>
> > > > > 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.
> > >
> > > have you seen how fast the side menu pops out. You make it seem like
> > > creating a new document would be like
> > > tap...............................tap, when it would be more like
> > tap..tap
> > > or tap tap it the get used to it.
> > >
> >
> > Again, opening the overview wouldn't be slower. The user would also be
> used
> > to the new buttons always being on the bottom of the screen, and
> therefore
> > could push them faster (whereas they're harder to target in the menu).
> >
>
> how so?
>

A user's muscle memory will adjust to "New" buttons being on the bottom
from the home screen. If the "Up" button shows a sidebar instead, the user
will have to adjust to an additional placement of "New" buttons, and it
will take him longer to target them.

>
> > > 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.
> > >
> > > I don't think this menu is frustrating at all. If we can get some
> better
> > > examples in it I think you would see the benefit. It would be more
> > > beneficial when editing a document then in the manager or viewer. But
> > since
> > > we are one shipping these views right now that's all I did.
> >
> >
> > I don't understand the last sentence.
> >
>
> we are not going to have the full blown writer just a document viewer for
> now.


Yes.

--
Unsubscribe instructions: E-mail to [hidden email]
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

Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

Mirek,

What I was trying to say through out the last email is that I got confused
about the overflow. Every time you talked about it you just said overflow
with out distinguishing what over flow, or maybe you did and I did not know
what the action bar was. Ether way I do not even give a fuck about this
subject any more, it's a stupid argument that I'm obviously not even going
to come close to winning so I'm just going to back down. I think the
Android HIG I very retarded, and that the Facebook navigation is not
confusing or hard to understand and the best way of doing this. But since
its so obviously going to confuse every one who uses our app........ Bla.

No cheers,
Andrew

--
Unsubscribe instructions: E-mail to [hidden email]
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

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

Sorry if my responses made you angry -- I really didn't mean it badly.
You might want to read through the Android design guidelines [1] -- it's
actually an incredibly well-done guide, perhaps the best, most readable HIG
I've ever seen. And I have to say that the "Up" button is genious as well
-- this sort of hierarchical navigation is sorely missing on desktop UIs,
where it's very hard to navigate to the source of a document.

[1] http://developer.android.com/design/index.html

--
Unsubscribe instructions: E-mail to [hidden email]
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

Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

Yes Mirek I am very pist off but there is nothing we can do about that now.
Besides I'm just being stupid. I'll look stuffs over and comeback later.
On May 24, 2012 5:48 PM, "Mirek M." <[hidden email]> wrote:

> Sorry if my responses made you angry -- I really didn't mean it badly.
> You might want to read through the Android design guidelines [1] -- it's
> actually an incredibly well-done guide, perhaps the best, most readable HIG
> I've ever seen. And I have to say that the "Up" button is genious as well
> -- this sort of hierarchical navigation is sorely missing on desktop UIs,
> where it's very hard to navigate to the source of a document.
>
> [1] http://developer.android.com/design/index.html
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> 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
>
>

--
Unsubscribe instructions: E-mail to [hidden email]
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

Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

In reply to this post by mirek2
May I officially say..... HA. Google+ just realised an update today for
there android app, and it features a Facebook navigation button with the
side bar that shows the sliver of the page that you are currently viewing.
What do you say to that. They must see some value in this menu.

This makes me very happy because one of the reasons I got mad is because I
am designing many apps all them using this side bar menu.

--
Unsubscribe instructions: E-mail to [hidden email]
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

mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: SIdebar Navigation

2012/5/25 Andrew Pullins <[hidden email]>

> May I officially say..... HA. Google+ just realised an update today for
> there android app, and it features a Facebook navigation button with the
> side bar that shows the sliver of the page that you are currently viewing.
> What do you say to that. They must see some value in this menu.
>

Google+ doesn't break the HIG, though. The "Up" button still goes "Up", as
it's meant to.
In your proposal, the menu replaces true "Up" functionality (because "Up"
would mean being taken to the file browser) and adds context-sensitive
actions (such as "Print" and "Share") that have nothing to do there.

--
Unsubscribe instructions: E-mail to [hidden email]
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

Loading...