Re: [ux-discuss] FLUX UI

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

Re: [ux-discuss] FLUX UI

Clément Pillias
Hi Joshua,

This discussion should rather take place on the renaissance list,  
(so, please reply there.)

Le 25 déc. 08 à 01:51, Joshua Martin a écrit :

> I will soon have designs depicting what I will discuss here...
>
> First of all, I see the screen as divided into different sections -  
> each of a different purpose. At the center of the screen will  
> always be the document or work; the left side of the screen will  
> always be devoted to other static elements like undo/redo, zoom,  
> help, and other necessary options that should always be available.

First of all, I want to say that it is a good idea to discuss *design  
principles* first, for the Renaissance project. Maybe we could have a  
wiki page Renaissance/Design_Principles or something similar, to  
discuss design principles.

So, here, you propose a design principle that I will call "Divide the  
screen into sections of different purpose". I think its a good idea,  
but we should add precisions about what are the "purposes."

It seems that your classification of purposes rely on "static vs.  
dynamic" interactors:

> The tabbed bar at the top of the screen will be static; various  
> options will be displayed here such as those that might be present  
> on the insert or format > page menus.
>
> The right sidebar is almost completely dynamic; as objects are  
> selected, so are the properties displayed here.
>
> The top bar just above the object is semi-static and semi-dynamic  
> (I honestly haven't made a decision yet). It is very useful to have  
> this bar present for Writer where one would need font options  
> available and would be useful in Calc where one would need formula  
> options available - but again, this is somewhat a "dynamic need"  
> because one doesn't need font tools when you're working with an image.

We could add some dimensions to the classification: somme commands  
are general, application, window, tab, document, selection or object -
related. Some commands are edition-related while others are  
navigation-related, file-related, etc.

But these dimensions are artificial. From my own experience, I  
believe that, when this kind of classification is used, users are not  
conscious of it unless explicitly told. So, I believe that commands  
should be grouped according to taskonomies [1], and not according to  
traditional taxonomies. So this is my first critic to your FLUX  
interface.

[1] http://jnd.org/dn.mss/logic_versus_usage_the_case_for_activity- 
centered_design.html

The second critic is rather a warning and a call to enhancement. I  
just want you to notice that the more distinctive visual zones you  
use to group commands, the more you risk to confuse the users, and  
particularly the newbies. Each time you are looking for a command,  
you have to look in more possible places, and each place has its own  
organization, so you have to use many search strategies, and it makes  
the cognitive burden higher. And it takes more time, especially if  
you've got tabs or dialogs to open...

(in your mockups, I count seven zones: the icons on blue background  
at the top, the icons on black background at the top, the black tabs  
below, the blue tabs on the right (documents), the formating commands  
on gray background at the top, commands on the left, and commands on  
the right. And there may still be window decorations.)

Toolbars may be ugly, but in the default configuration (below the  
menu), all toolbars altogether forms a visually uniform area that can  
be quickly browsed. The user may move some toolbars on the sides or  
below the page, but since it is a conscious action and explicit  
choice, this don't add confusion.

But this does not necessarily imply that we should reduce the number  
of distinctive visual areas. It just mean that we have to take care of:
* make clear how the area relates to the commands it contains and to  
the tasks they are related to.
* make the different areas easy to distinguish and recognize.

Alex Faaborg from the Mozilla User Experience Team has recently  
posted an interesting article on his blog about all this:

http://blog.mozilla.com/faaborg/2008/10/24/firefox-themes-the- 
contention-between-visual-hierarchy-and-toolbar-customization/

My third and last critic concerns the "engraved in stone" aspect of  
your design: static commands are on the left, dynamic ones on the  
right. What about user customization? What about adaptation to non-
standard platforms such as mobile phones or computers with small  
screens?

Finally, my feeling with FLUX UI and other similar investigations, is  
that we should not try to build something new from scratch on the  
basis of "new principle designs." I believe that we should rather  
start from the actual interface and enhance it.

Look what Firefox has done between version 2 and 3. The "awesome  
bar", the "keyhole-shaped back/forth button", bookmarks management  
and security information integrated in the address bar... All that  
stuff is carefully-tuned enhancement of things that already existed  
and were already efficient, and only use well-known principle of  
design and tools such as the Fitt Law.

Regards,

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: [ux-discuss] FLUX UI

Joshua Martin
I see no Renaissance mailing list...

http://wiki.services.openoffice.org/wiki/Renaissance



On Fri, Dec 26, 2008 at 12:10 PM, Clément Pillias
<[hidden email]>wrote:

> Hi Joshua,
>
> This discussion should rather take place on the renaissance list, (so,
> please reply there.)
>
> Le 25 déc. 08 à 01:51, Joshua Martin a écrit :
>
>  I will soon have designs depicting what I will discuss here...
>>
>> First of all, I see the screen as divided into different sections - each
>> of a different purpose. At the center of the screen will always be the
>> document or work; the left side of the screen will always be devoted to
>> other static elements like undo/redo, zoom, help, and other necessary
>> options that should always be available.
>>
>
> First of all, I want to say that it is a good idea to discuss *design
> principles* first, for the Renaissance project. Maybe we could have a wiki
> page Renaissance/Design_Principles or something similar, to discuss design
> principles.
>
> So, here, you propose a design principle that I will call "Divide the
> screen into sections of different purpose". I think its a good idea, but we
> should add precisions about what are the "purposes."
>
> It seems that your classification of purposes rely on "static vs. dynamic"
> interactors:
>
>  The tabbed bar at the top of the screen will be static; various options
>> will be displayed here such as those that might be present on the insert or
>> format > page menus.
>>
>> The right sidebar is almost completely dynamic; as objects are selected,
>> so are the properties displayed here.
>>
>> The top bar just above the object is semi-static and semi-dynamic (I
>> honestly haven't made a decision yet). It is very useful to have this bar
>> present for Writer where one would need font options available and would be
>> useful in Calc where one would need formula options available - but again,
>> this is somewhat a "dynamic need" because one doesn't need font tools when
>> you're working with an image.
>>
>
> We could add some dimensions to the classification: somme commands are
> general, application, window, tab, document, selection or object -related.
> Some commands are edition-related while others are navigation-related,
> file-related, etc.
>
> But these dimensions are artificial. From my own experience, I believe
> that, when this kind of classification is used, users are not conscious of
> it unless explicitly told. So, I believe that commands should be grouped
> according to taskonomies [1], and not according to traditional taxonomies.
> So this is my first critic to your FLUX interface.
>
> [1] http://jnd.org/dn.mss/logic_versus_usage_the_case_for_activity-
> centered_design.html
>
> The second critic is rather a warning and a call to enhancement. I just
> want you to notice that the more distinctive visual zones you use to group
> commands, the more you risk to confuse the users, and particularly the
> newbies. Each time you are looking for a command, you have to look in more
> possible places, and each place has its own organization, so you have to use
> many search strategies, and it makes the cognitive burden higher. And it
> takes more time, especially if you've got tabs or dialogs to open...
>
> (in your mockups, I count seven zones: the icons on blue background at the
> top, the icons on black background at the top, the black tabs below, the
> blue tabs on the right (documents), the formating commands on gray
> background at the top, commands on the left, and commands on the right. And
> there may still be window decorations.)
>
> Toolbars may be ugly, but in the default configuration (below the menu),
> all toolbars altogether forms a visually uniform area that can be quickly
> browsed. The user may move some toolbars on the sides or below the page, but
> since it is a conscious action and explicit choice, this don't add
> confusion.
>
> But this does not necessarily imply that we should reduce the number of
> distinctive visual areas. It just mean that we have to take care of:
> * make clear how the area relates to the commands it contains and to the
> tasks they are related to.
> * make the different areas easy to distinguish and recognize.
>
> Alex Faaborg from the Mozilla User Experience Team has recently posted an
> interesting article on his blog about all this:
>
> http://blog.mozilla.com/faaborg/2008/10/24/firefox-themes-the-
> contention-between-visual-hierarchy-and-toolbar-customization/
>
> My third and last critic concerns the "engraved in stone" aspect of your
> design: static commands are on the left, dynamic ones on the right. What
> about user customization? What about adaptation to non-standard platforms
> such as mobile phones or computers with small screens?
>
> Finally, my feeling with FLUX UI and other similar investigations, is that
> we should not try to build something new from scratch on the basis of "new
> principle designs." I believe that we should rather start from the actual
> interface and enhance it.
>
> Look what Firefox has done between version 2 and 3. The "awesome bar", the
> "keyhole-shaped back/forth button", bookmarks management and security
> information integrated in the address bar... All that stuff is
> carefully-tuned enhancement of things that already existed  and were already
> efficient, and only use well-known principle of design and tools such as the
> Fitt Law.
>
> Regards,
>
> Clément.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
_________________________________

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: Re: [ux-discuss] FLUX UI

Clément Pillias

Le 26 déc. 08 à 18:19, Joshua Martin a écrit :

> I see no Renaissance mailing list...
>
> http://wiki.services.openoffice.org/wiki/Renaissance

You are actually reading 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: Re: [ux-discuss] FLUX UI

Stefan Weigel
In reply to this post by Joshua Martin
Hi Joshua,

(Please do not quote whole messages.)

Joshua Martin schrieb:
> I see no Renaissance mailing list...
>
> http://wiki.services.openoffice.org/wiki/Renaissance

Look: http://ux.openoffice.org/servlets/ProjectMailingListList

Stefan


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

Reply | Threaded
Open this post in threaded view
|

Re: Re: [ux-discuss] FLUX UI

Joshua Martin
My apologies... Yes, all of my other discussions have been taking place on
the Renaissance list since December 24/25.

As for your critique - it is good. I appreciate your insight into some
points I didn't think about.

With your insight into the amount of "visual areas" I have in FLUX and
whether or not they're options are static or dynamic, I have made a few
changes to suit these needs. I have considered eliminating the right-hand
sidebar that would've been dynamic and combined those options into the top
bar (also context sensitive).

The changes can be seen here
http://2044447852705379421-a-1802744773732722657-s-sites.googlegroups.com/site/fluxuserinterface/Home/writer_new.png?attredirects=0&auth=ANoY7cqRbZwULAUUrQa0eWxDOXcWZQ0ISGX_wj_wfEccI1MzHyDoNa_T0TbFS4fq_Lq5RFvQE8NGrQNwRxevWz_fnYmPQm9A30LyVKLVN3ZCNEALXgHB17_UFnSvHR8ulGj57zslU6kLrMzn_spUjJYh_eWmDloBSLcQHXlK87uSqvqv36sOcALSovDKRhGEwhOXGt1WSOKwe_j4x_B0EWLu1XLKYGH8qA%3D%3D

I think these changes would allow for more flexibility and a little less
confusion on the user's part. Note that these toolbars would be "floatable"
and dockable just like those that already exist in OOo.

--
_________________________________

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

Posting without subscription, and domain/Project confusion for newcomers

Graham Perrin
Administrator
In reply to this post by Stefan Weigel
On 26 Dec 2008, at 17:34, Stefan Weigel wrote:

>> I see no Renaissance mailing list...
>> http://wiki.services.openoffice.org/wiki/Renaissance
>
> Look: http://ux.openoffice.org/servlets/ProjectMailingListList

<http://wiki.services.openoffice.org/wiki/Renaissance> offers the  
mailto: address, encouraging posts without subscription.

Is the list configured to allow posts from non-subscribers?

There is also (as previously mentioned) the issue that the
user interface domain <http://ui.openoffice.org/> does not include
user interface Renainssance.

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

Reply | Threaded
Open this post in threaded view
|

Renaissance: free thinking, with reality in parallel

Graham Perrin
Administrator
In reply to this post by Clément Pillias
Clément Pillias wrote
… my feeling with FLUX UI and other similar investigations, is that we should not try to build something new from scratch on the basis of "new principle designs." I believe that we should rather start from the actual interface and enhance it.
Earlier posts from me may have given an impression that I'm hung up on guidelines.

For the purposes of Renaissance, I _will_ go through phases of:

* periodically tearing (without breaking) OOo and OOo behaviours into scraps of paper, throwing them to a light wind, watching how they land -- with or without placement from interested individuals

-- and (bite me!) I encourage others to go through such phases, without apology, without regard for the current guidelines for a Renaissance group.

I might _never_ assume that operating system rules and guidelines can bend to suit the creative thoughts of Renaissance people. If I offer reminders from time to time, don't take it the wrong way ;)

Look what Firefox has done… 
Also, look at what Firefox has _NOT_ done whilst enjoying the sunshine on Mozilla island! It is, for example, over seven years since the interapplication communication (System Services) issue was bugged and in such ways, to a significant group of users, Firefox is in the cold.

Back to OOo:

I believe that we should rather start from the actual interface
I half-share that belief, I also believe that we can:

* allow our early thoughts to race way beyond the bounds of the actual interface

whilst

* being prepared for disappiontment, if what later coalesces is considered technically impossible in relation to any milestone.

(My gut feeling: the greatest disappointments will come when there is a UI that is almost universally acceptable, but that can not be implemented within the near future.)

----

Early thoughts of dashboard didn't suit me (personally) but they are thought-provoking in a nice way and when I find enough free time, I'll return to those thoughts.

An early impression of FLUX didn't suit me (personally) but I do see FLUX re-shaping in response to feedback from the list. Now, it's closer to something that might suit me. Maybe when FLUX or whatever has settled to a form that is widely agreeable, it will be less scary to developers on some other side of the fence.
Reply | Threaded
Open this post in threaded view
|

FLUX UI, menus from buttons, harmony with zoomed-out views

Graham Perrin
Administrator
In reply to this post by Joshua Martin
Joshua Martin wrote
I have considered eliminating the right-hand sidebar that would've been dynamic and combined those options into the top bar (also context sensitive).

… I think these changes would allow for more flexibility and a little less confusion on the user's part. Note that these toolbars would be "floatable" and dockable just like those that already exist in OOo.
<http://sites.google.com/site/fluxuserinterface/>, <http://sites.google.com/site/fluxuserinterface/features-replaced-with-flux> etc. clearly more refined, thanks to Joshua and the list.

<http://sites.google.com/site/fluxuserinterface/features-replaced-with-flux/feature_zoom_new.png> sparks some thoughts:

1. I tend to zoom in and out *very* frequently, I like the OOo 3 allowance to do so with a single click.

2. De-focusing from the zoom example: the appearance of a menu, extending from a button, is appealing.

3. Re-focusing on the zoom example: terminology. Would we call the thing that extends to the right of the button:

* the zoom menu
* the zoom sub-menu
* the zoom button menu
* or something else?

4. Mashing <http://sites.google.com/site/fluxuserinterface/Home/writer_new.png> and <http://sites.google.com/site/fluxuserinterface/features-replaced-with-flux/feature_zoom_new.png> with points (1) and (2) above:

* for myself, I most often work with (Word) zoomed to show two full pages of A4 alongside each other

* for others (when I am called to provide support at someone else's desk), I usually begin by zooming to 25% or less so that I can gain a broad overview of how a long document feels, in its entirety

* for myself and for others, I routinely work at 50% or less when applying styles to a series of paragraphs (such as a bibliography) that extends across multiple pages.

Suggestions
===========

i) Think about how UI elements, with or without menus extending to their right, might fit, least intrusively, with the words that are being processed

-- for example: might a menu, extending to the right of the properties button, unexpectedly obscure the characters to which the properties apply?

ii) ... and I forgot what the second point was, it can wait!

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

Re: [ux-discuss] FLUX UI

Graham Perrin
Administrator
My previous message messed up through careless typing and Baileys-
fuelled dyslexia. sorry!

<http://n2.nabble.com/Re%3A--ux-discuss--FLUX-UI- 
tt1916614.html#a2016374> for the tidy version. With Joshua's name  
spelt correctly.

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

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] FLUX UI

Joshua Martin
I also zoom *very* frequently and have considered what you said about
covering up what you might need to see while zooming.

Though, I think that this menu does allow more visibility (especially in the
cases where one would zoom from a pop up menu), there are some things we can
improve upon to allow more visibility. Perhaps the menu could be a bit
smaller...

These "pull out" menus (which are a somewhat good name), can be used for a
variety of the sidebar options. Rather than being presented with a full pop
up window for adjusting the document's properties, a pull out menu can be
drawn out to present all of those options. Note that the size of the pull
out window can be adjusted to whatever the contents may be and the uses
needed.

I think that last screenshot I gave showing the new type of tabs and the
subtracted tabbed document feature is the one to start working from, as it
is a more appropriate migration from the current OOo UI. It is more subtle,
but also more cooperative to the user's needs.

The left sidebar remains to be for static options that should always be at
the user's figertips, while the bar above the document should be for
dynamic, context sensitive options (we'll work more on that later).


--
_________________________________

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

The benefits of cleanliness, simplicity, and a grey or minimalist palette; making the most of operating systems

Graham Perrin
Administrator
In reply to this post by Clément Pillias
Clément Pillias wrote
… we have to take care of:
* make clear how the area relates to the commands it contains and to the tasks they are related to.
* make the different areas easy to distinguish and recognize.

Alex Faaborg from the Mozilla User Experience Team has recently posted an interesting article on his blog about all this:

<http://blog.mozilla.com/faaborg/2008/10/24/firefox-themes-the-contention-between-visual-hierarchy-and-toolbar-customization/>
Mozilla aside: a few years ago we had pinstripes.
Then, other novelties.
Then, five-star UNO <http://osx.iusethis.com/app/uno> <http://www.macupdate.com/info.php/id/19384>,

>>> aimed to those who want a clean and un-osbstructive interface

Since October 2007, Mac OS X essentially follows a UNO tradition: clean and un-obstructive.

Snippets from the Mozilla blog:

>> Give Dominant Controls More Weight

>> One way to tell how visually dominant a control is, is to blur
>> the design (or close one eye and squint) in order to roughly
>> approximate early visual processing. If a control passes this
>> test the user should be able to visually target it at a very
>> quick glance.

A snippet from outdated <http://www.mozilla-europe.org/en/firefox/#feature-vsie>:

>> Thousands of ways to personalize

With thousands of ways to personalise, and extensions encroaching at top, left and bottom of a window, is it any wonder that developers eventually find it desirable/necessary to make some things within this mix _heavy_?

>> Give Dominant Controls More Weight

Another way of helping the user to visually target a button:

* do not blur its situation, do not surround the button with scores of multi-coloured controls and thousands of ways of personalise ;)

A comparison:



With far few *fewer controls*, I have far *greater control* over my browser content. What makes possible this paradox?

Safari is the better citizen, the one that plays nicely with the operating system and with other applications.

In Mac OS X, such applications often appear

1. clean
2. simple
3. with a grey or minimalist palette

-- and if the user chooses to use the application in ways that are complex or powerful, its design allows those uses without spoiling the appearance.

(That is, the impression I have gained, with zero reference to Apple guidelines. Some time, I should check the guidelines to see if the intention was along those lines.)

----

In Vista and in future versions of Windows, and in other OSes that are supported by OpenOffice.org, the three points may be different:

1.
2.
3.

-- I do _not_ expect anyone to add (to this thread) the three (or more or less) points that they perceive in relation to the other OSes

-- I _do hope_ that the products of Renaissance will be applications that make best use of what's provided by the OS, and this _may_ mean a UI that is minimalist.

What I currently see at <http://sites.google.com/site/fluxuserinterface/> does at first glance appear to fit the 'minimalist' bill.

A glance at Pages, my requirement for which is extremely rare, shows:

* the gamut of colour in only one place (the icon for 'Colors')

* groups of things distinguished by grey space, grey spacers (never by background colour)

* a blue highlight applied to active radio buttons (even when in System Preferences I prefer graphite to blue)




(and in my years of using Mac OS X, I have never wished to stray from the OS default blue).

I might encourage developers of the UIs to consider methods of distinction that:

* do succeed with space and/or shades of grey alone
* do not necessitate multi-coloured tabs
* do not necessitate multi-coloured toolbars, etc..

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

Re: The benefits of cleanliness, simplicity, and a grey or minimalist palette; making the most of operating systems

Clément Pillias

Le 28 déc. 08 à 14:08, Graham Perrin a écrit :

> -- I _do hope_ that the products of Renaissance will be  
> applications that make best use of what's provided by the OS, and  
> this _may_ mean a UI that is minimalist.

+1

> I might encourage developers of the UIs to consider methods of  
> distinction that:
>
> * do succeed with space and/or shades of grey alone
> * do not necessitate multi-coloured tabs
> * do not necessitate multi-coloured toolbars, etc..

+1

Graham, you've won two more points ;)

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

Reply | Threaded
Open this post in threaded view
|

Re: The benefits of cleanliness, simplicity, and a grey or minimalist palette; making the most of operating systems

Graham Perrin
Administrator
This post was updated on .
In reply to this post by Graham Perrin
Graham Perrin wrote
A glance at Pages, my requirement for which is extremely rare, shows …

… a blue highlight applied to active radio buttons…
Correcting my earlier language: the screen shot of Apple Pages shows a highlight applied to a rectangular tab (not to a radio button).

Postscript (but not correcting myself on-list yet again ;) — the screen shot shows a rectangular tab _selected_ (not highlighted).

Reply | Threaded
Open this post in threaded view
|

Re: Posting without subscription, and domain/Project confusion for newcomers

Christoph Noack-2
In reply to this post by Graham Perrin
Hi Graham!

Am Samstag, den 27.12.2008, 15:15 +0000 schrieb Graham Perrin:

> On 26 Dec 2008, at 17:34, Stefan Weigel wrote:
>
> >> I see no Renaissance mailing list...
> >> http://wiki.services.openoffice.org/wiki/Renaissance
> >
> > Look: http://ux.openoffice.org/servlets/ProjectMailingListList
>
> <http://wiki.services.openoffice.org/wiki/Renaissance> offers the  
> mailto: address, encouraging posts without subscription.
>
> Is the list configured to allow posts from non-subscribers?

No and yes. Non-subscriber postings are sent to the moderators of the
mailing lists. Currently Frank Loehmann and me do the "manual spam
filtering". If the messages are UX related, there we agree to the
posting and the CollabNet system handles them like usual. If people do
repeatedly send messages without being subscribed, then we inform them
how to join (but this is very seldom).

> There is also (as previously mentioned) the issue that the
> user interface domain <http://ui.openoffice.org/> does not include
> user interface Renainssance.

Good (and sad) point. Currently UI is more or less technical related and
(from *my* point of view) relatively quiet. So I don't see a real
benefit in adding Renaissance there ... maybe Frank has a different
opinion on that. But (a little bit off-topic), sometimes I think
Stella's work is more and more related to UX.

Did that answer the questions?

Bye,
Christoph


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