Re: [libreoffice-design] 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 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