FLUX - Horizontal Menu

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

FLUX - Horizontal Menu

Joshua Martin
Well, it needs some work... But this is the start of what could be a
horizontal accordion...

http://2044447852705379421-a-1802744773732722657-s-sites.googlegroups.com/site/fluxuserinterface/Home/writer_horizontal_menu.png?attredirects=0&auth=ANoY7cprelWRiIEjoxJiLGK3wRN2J62-L2og3YBEHJ2mgzM79MvbPL-PtbMhhqRVdHneBHBtgBHjmA0ItXE3JJJwsUKwojb2CVi_vdcafvgH7P6sBhZgRF1G-7fYi1kFWQgUMu1Dxu0-rhtEUz9SSiV0ihnK08cUZJ3ZctGJSqTUQfn6EIAGkXbOl06T8-NCyOoBhyL17_SGbFqAy6kmrPuB7GBPwh9zaTNOva1tK7hwyApadWPgBy8%3D

--
_________________________________

Joshua S. Martin


CONFIDENTIALITY NOTE: This e-mail message, including any attachment(s),
contains information that may be confidential, protected by the attorney
client or other legal privileges, and or proprietary non public information.
If you are not an intended recipient of this message or an authorized
assistant to an intended recipient, please notify the sender by replying to
this message and then delete it from your system. Use, dissemination,
distribution, or reproduction of this message and or any of its attachments
(if any) by unintended recipients is not authorized and may be unlawful.
Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Joshua Martin
Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Graham Perrin
Administrator
Joshua Martin wrote
Here is a much better representation of a horizontal accordion and tabbed documents -
Hacked, not tidily:


Tabs for documents: ranged left (not right).

Tab for foreground document: highlighted (not low-lighted) to reduce the risk of the user associating a dark tab with a matching dark area of the toolbar beneath.

Formatting toolbar: to the left (not centred) so that no matter how wide the window, the user can aim their clicks in a highly predictable position.

Text within UI should, please, never be rotated.

For no particular reason I have increased from four, to six, the number of buttons. Labelled radio buttons, if you like. One of the six is active (highlighted, though you may prefer to low-light).

The set of icons within the darkened area changes, according to the chosen button. (Is that the gist?)

In the dimension between the foreground toolbar and the background of the window, the text tips for the icons. One text, or all texts, might increase in contrast/clarity when the user moves the cursor in/around the icons area, only after the user has paused for a (?) fraction of a second.

At this point, a critical eye may wince at the asymmetry: the light grey space in the right of the toolbar, the dark grey space to the right of the six radio buttons. Consider:

* a user's wish (occasionally, a user's *requirement) to reduce the width of a window

* maybe (who knows?) a developer's wish to extend OOo:

— within the bounds of the window

— respectably, without changing the ratios that might become associated with a UI.

My limited hacking didn't allow me to preserve an accordion. I do like accordion effect, so if it can be done (without rotating text) I should welcome it.
Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Joshua Martin
Reply | Threaded
Open this post in threaded view
|

preferring traditional radio buttons to an accordion in this area of FLUX UI

Graham Perrin
Administrator
Returning briefly to an earlier <http://sites.google.com/site/fluxuserinterface/Home/writer_horizontal_accordion2.png>,

Joshua Martin wrote
Here are some of the changes you mentioned (with the accordion in place).
I'm not convinced that an accordion adds value in this particular situation.

Focusing only on the radio buttons (not the icons, shading etc.), compare these two:





In the first: I can tip-toe from one to another, left to right and back, across all six radio buttons.

In the second: despite the fewer buttons, greater leaps are required, and the distance to leap may be unpredictable — depending on the arrangement of icons and separators within each fold of the bellows — depending also on whether the user has customised any fold.

Another comparator, an accordion in an entirely different situation:

<http://www.apple.com/downloads/> |
[ All Apple Downloads ~ Top Apple Downloads ~ Top Downloads ]

I *think* I like it when bellows reveal/close their folds *without* click input.

I do not like the impatient auto-play of that particular Apple accordion. There should be a respectable delay before the bellows move.
Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Joshua Martin
I see what you're saying... about the "flip back and forth"

Now that I think about it, it might be better understood for new users if
there were buttons across the top like in your drawing that highlight as
they're selected...

I'll try to add that to the drawings...

--
_________________________________

Joshua S. Martin
Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Clément Pillias

Le 28 déc. 08 à 15:27, Joshua Martin a écrit :

> I see what you're saying... about the "flip back and forth"
>
> Now that I think about it, it might be better understood for new  
> users if there were buttons across the top like in your drawing  
> that highlight as they're selected...

Don't use (radio) buttons to change the content displayed! There is  
no hint with this kinds of buttons that tells the user that it will  
change the content of some area.

Tabs are used for that purpose, because there is a closure relation  
that link the content that will be changed with the interactor  
changing responsible for its change.

Although Graham comments are valid, I am not sure that tabs are  
better than an accordion because :

* Tabs needs a two dimensional interpretation of the area: first  
horizontally for the tabs, then vertically to pass from the tabs to  
the icons, and then horizontally again for the icons. The interaction  
may be harder with accordion but the interpretation is simpler and  
thus, it reduce the cognitive burden by offering a less complex  
structure an a clear scan path.

* I am not sure that the search pattern consisting in looking in  
each  fold will happen frequently, considering the labeling of those  
folds.

Cheers,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Joshua Martin
So you think the accordion is a better fit for this application, rather than
the tabs?

As seen in this image?

http://sites.google.com/site/fluxuserinterface/Home/writer_document_tabs_white.png

--
_________________________________

Joshua S. Martin
Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Clément Pillias

Le 28 déc. 08 à 19:12, Joshua Martin a écrit :

> So you think the accordion is a better fit for this application,  
> rather than the tabs?
>
> As seen in this image?
>
> http://sites.google.com/site/fluxuserinterface/Home/ 
> writer_document_tabs_white.png

I don't know what is best, only a rigorous test campaign can tell us  
what is effectively the best. But I think that the accordion is a  
valuable idea, and I have a preference for it.

Cheers,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Joshua Martin
I'm willing to hear any and all opinions on the matter - and will take
suggestions seriously.

I agree that the horizontal accordion looks better, but after hearing
comments from Graham... I do have concern that it might not scale well over
smaller screens OR if extension developers want to add a tab to the
accordion for their extensions.

Regardless of the fact, any suggestions on how to make it look better (more
like an accordion)?



--
_________________________________

Joshua S. Martin
Reply | Threaded
Open this post in threaded view
|

Re: FLUX - Horizontal Menu

Joshua Martin
Here's a possible solution for the horizontal accordion...

http://sites.google.com/site/fluxuserinterface/Home/writer_horizontal_accordion4.png

--
_________________________________

Joshua S. Martin
Reply | Threaded
Open this post in threaded view
|

toolbar field 'Search Commands'

Graham Perrin
Administrator
The presence of 'Search Commands' in the toolbar reminds me that on Mac OS X:

* 'Search Commands' field should not present in the toolbar

* commands in a UI such as FLUX should remain compatible with 'Spotlight for Help' (highlighted at <http://www.diigo.com/annotated/ade05da6fadd607ddfbd30df8d2d76ae>); screen shot at <http://homepage.mac.com/madfax7/.Pictures/HelpMenuSearch.jpg> (referred from Miroslav Mazel's <http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=1770>) demonstrates the effect.
Reply | Threaded
Open this post in threaded view
|

Re: OS-specific features: extensions, I guess

Ivan M
On Wed, Dec 31, 2008 at 3:45 PM, Graham Perrin <[hidden email]> wrote:
> Vincent - D. Ertner wrote:
>> How would the […] work on OSes which don't have a system wide […]
>> facility?
>
> I guess, as OS-specific extensions to OOo.

A strong -1 ... at least for major features such as the command search
function.

Command search would be a major new piece of functionality for OOo
with huge benefits for users. Having it as an extension would mean
many users missing out on it simply because they might not know much
about extensions, or they might not be able to install them for
technical reasons (software hosted on a single drive with read-only
access), etc.

On Thu, Jan 1, 2009 at 3:32 AM, Drew Jensen <[hidden email]> wrote:
> Well, it sounds turned around backwards to me.
>
> The OS with the special service would merit the extension.

+1. Why should regular users be inconvenienced just because MacOS does
things differently (better, you might argue, but the functionality of
the command search will likely top the functionality offered natively
by MacOS)

- Ivan.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OS-specific features: extensions, I guess

Clément Pillias

Hi everybody,

I really don't understand all these discussions around OS-specific  
features available as extensions.

Either it is a native feature, and it is not provided as an  
extension, either it is an extension, and then it can or has to be OS-
specific. The choice between native feature or extension should not  
be done according to the OS-specificity of the feature, but according  
to the properties of extensions.

It seems that the real question is: how much liberty do we have to  
create OS-specific interface elements? I believe that one of the  
goals of Renaissance should be to make OOo integrate well/better with  
the OS guidelines and features. Firefox 3 has done a great job to  
achieve a part of this goal, concerning visual integration:

The announcement and explanation:
http://blog.mozilla.com/faaborg/2007/10/10/the-firefox-3-visual- 
refresh-system-integration/

The strategy:
http://blog.mozilla.com/faaborg/2007/11/15/the-shape-of-things-to-come/

The result:
http://blog.mozilla.com/faaborg/2008/05/14/firefox-3-themes/

(Note: these pages contains a lot of useful references if we choose  
to follow that path.)

What do you think about that?

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

FLUX - Horizontal Menu - tabs in lieu of radio buttons (agreed)

Graham Perrin
Administrator
In reply to this post by Clément Pillias
Clément Pillias wrote
Don't use (radio) buttons to change the content displayed! There is no hint with this kinds of buttons that tells the user that it will change the content of some area.

Tabs are used for that purpose…
+1 and thanks to Clément for the alert.

Both my graphic (re-using elements from someone else's mock-up) and my choice of words were careless. I did mean tabs, but I used the wrong expression.

The 'button' was intended to mean that only one could be pressed at a time. I visualised 'rectangular radio buttons' with words on them (not within them) ... which, to most people, means 'tab' ;)

(OT: now, I realise in most mock-ups, the non-rectangular tabs are (to me) non-native. Unconsciously, that was probably the reason for me not choosing the word 'tab'.)

Regards
Graham
Reply | Threaded
Open this post in threaded view
|

not confusing Renaissance with the presence of features that are out-of-scope

Graham Perrin
Administrator
In reply to this post by Clément Pillias
With apologies for cross-posting

On 31st December, I moved the relevant thread to [hidden email]
  but (at this time) I can not offer an openoffice.org reference; we  
have some problems with the list archive (messages posted after 29th  
December seem to be missing).

@ [hidden email]

<http://wiki.services.openoffice.org/wiki/Renaissance:The_Scope>  
reminds us of the one and only thing that is _out of scope_:

>> Anything that users can currently not accomplish with OpenOffice.org

-- and so (please) within the Renaissance mock-ups, features that are  
not implemented feature (such as, 'Search Commands') should not appear.

----

On 1 Jan 2009, at 22:46, Clément Pillias wrote:

> I believe that one of the goals of Renaissance should be to make OOo  
> integrate well/better with the OS guidelines and features.

+1

but <http://wiki.services.openoffice.org/wiki/Renaissance:The_Goal>  
does not express this. If a member of Renaissance team could review  
and update, it will be much appreciated. If it *is* amongst the goals,  
please make the statement at the wiki. If it is *not* amongst the  
goals, or if it is in any way out of scope, again please update the  
wiki.

Thanks and regards
Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

OS guidelines and features, a Firefox example, and OOo

Graham Perrin
Administrator
In reply to this post by Clément Pillias
Clément Pillias wrote
I believe that one of the goals of Renaissance should be to make OOo integrate well/better with the OS guidelines and features. Firefox 3 has done a great job to achieve a part of this goal, concerning visual integration:

The announcement and explanation:
http://blog.mozilla.com/faaborg/2007/10/10/the-firefox-3-visual-refresh-system-integration/

The strategy:
http://blog.mozilla.com/faaborg/2007/11/15/the-shape-of-things-to-come/

The result:
http://blog.mozilla.com/faaborg/2008/05/14/firefox-3-themes/

… What do you think about that?
Extracted from one of the images within those URLs:


— Firefox for Mac OS X window to Firefox Library is good.

Comparing Firefox for Mac OS X menus and browser window (foreground)
(ignore the Diigo menu) with a Safari window (background):
 

— Firefox is not as clean as it should be, some horizontal and vertical space is wasted, the controls are of mixed sizes, where one shade of grey should suffice they have maybe three, most close boxes are misplaced (on the wrong side).
 
However: it's true that Firefox 3 *looks* better than Firefox 2.
Reply | Threaded
Open this post in threaded view
|

Re: OS guidelines and features, a Firefox example, and OOo

Graham Perrin
Administrator
This post was updated on .
I shan't quote from the three URLs offered by Clément but the readers' comments, some of which are heated, *do* make very interesting reading.

Graham Perrin wrote
Firefox is not as clean as it should be, some horizontal and vertical space is wasted, the controls are of mixed sizes, where one shade of grey should suffice they have maybe three, most close boxes are misplaced (on the wrong side).
 
However: it's true that Firefox 3 *looks* better than Firefox 2.
A September 2007 vision  
 
offered by Stephen Horlander at <https://bugzilla.mozilla.org/show_bug.cgi?id=303110#c31> appears better than the June 2008 final product.

Also, Firefox icon for security (on which Firefox prides itself) can be lost, various extensions present controls in the status bar (a poor situation for controls; IMO symptomatic of too much being squeezed into the UI), preferences for Firefox themes are missing from the Preferences dialogue, and when I do find the default Firelight theme

I see two themes within one theme but no hint of how to achieve the one that I prefer, et cetera.

From a graceful (September 2007) vision, to a final product (June 2008): how did such pollution occur?

Expanding upon some earlier thoughts I guess that there was, in part, an unspoken realisation that:

* some _extensions_ to Firefox can diminish features that are _integral_ to Firefox

and in this battle of the visuals, Mozilla thought it necessary to:

* stray from guidelines.

Relevance to OOo?

* where guidelines are clear, follow them;

* consider how some extensions to OOo might, in subtle ways, pollute visions of a Renaissance UI; plan the UI carefully to accommodate extensibility with grace;

* consider how some extensions to OOo might, in subtle ways, pollute an otherwise fine combination of OOo + operating system

— et cetera, I'm conscious of noise and some of this is a little repetitive (sorry!).

Regards
Graham
Reply | Threaded
Open this post in threaded view
|

Some confusion and misinterpretation

Graham Perrin
Administrator
In reply to this post by Ivan M
On January 1st,
Ivan M wrote
Why should regular users be inconvenienced just because MacOS does things differently
With respect:

* I _never_ suggested that anyone should be inconvenienced

* we should _never_ suggest that any user group is superior or irregular, it has the potential to alienate.

The previous day, <http://markmail.org/message/fu6ngd2gp5uey4ws>:

* I did emphasise my _main concern_ that OOo load and response times should be good/improved

-- echoing another writer's concern that
   "OOo should be streamlined (loading times should be quick …)"

* I did make very clear my respect for users of other OSes.

Also, there has been discussion (ultimately beyond the scope of Renaissance) of how best to achieve such things.

Let's keep this polite, thanks all!

(One of the list archives is missing all posts since 29th December, I guess that it's easy to lack the fullest picture.)

Kind regards
Graham
Reply | Threaded
Open this post in threaded view
|

Re: Some confusion and misinterpretation

Ivan M
Hi Graham, all,

My comments were only intended with regard to major
[proposed/hypothetical] features that already may have a native
implementation in one single OS, such as the command search, which,
given the discussions at [1], may not end up being just a command
search - there may be additional functionality such as the execution
of commands themselves.

[1] http://ux.openoffice.org/servlets/BrowseList?list=discuss&by=thread&from=2124105

On Sat, Jan 3, 2009 at 7:28 AM, Graham Perrin <[hidden email]> wrote:

>
> On January 1st,
> Ivan M wrote:
>>
>> Why should regular users be inconvenienced just because MacOS does things
>> differently
>>
> With respect:
>
> * I _never_ suggested that anyone should be inconvenienced
>
> * we should _never_ suggest that any user group is superior or irregular, it
> has the potential to alienate.

You're absolutely right - I should have been more careful with my
wording so I'll clarify on the intended meaning. In the context of the
thread you're quoting, regular users would be ordinary users from all
OS'es; the users of Windows, Linux, and any other non-MacOS operating
system would miss out on important functionality by default, as it
would only be available as an extension. MacOS users would have
command search thanks to the native implementation, but they would
miss out on any extra functionality offered by the OOo implementation.

In this [hypothetical] situation, all users would miss out by default
if decisions to exclude features in the core OOo application are based
on what a single OS does/requires/recommends.

Given the thread from which this topic stemmed, it wasn't clear to me
if the thread titled "OS-specific features: extensions, I guess" was
intended to refer to command search as a specific feature with regard
to MacOS, or whether it was referring to command search as a specific
feature for all OSes other than MacOS. So that's probably some
confusion on my part. However, in the case of this email, it would
have been easier if you had replied to the original thread from which
you quoted me instead of starting a new thread altogether - it makes
it hard to keep track of discussions that are related and it's easy to
lose context.

> The previous day, <http://markmail.org/message/fu6ngd2gp5uey4ws>:
>
> * I did emphasise my _main concern_ that OOo load and response times should
> be good/improved
>
> -- echoing another writer's concern that
>   "OOo should be streamlined (loading times should be quick …)"
>
> * I did make very clear my respect for users of other OSes.
>
> Also, there has been discussion (ultimately beyond the scope of Renaissance)
> of how best to achieve such things.
>
> Let's keep this polite, thanks all!

I apologize if I've offended anyone - that is never my intention.

Regards,
Ivan.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12