Project Renaissance: Feedback on Feedback

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

Project Renaissance: Feedback on Feedback

Frank Loehmann
Hi,

Please find some answers to recent comments in our new 'Feedback on
Feedback' post on GullFOSS:

http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface

Best regards,

The Renaissance Team

--
Sun Microsystems GmbH                Frank Loehmann
Nagelsweg 55                         User Experience StarOffice
20097 Hamburg                        Phone: (+49 40)23646 882
Germany                              Fax:   (+49 40)23646 550
http://www.sun.de                    mailto:[hidden email]

OpenOffice.org User Experience Team
http://ux.openoffice.org

Sitz der Gesellschaft:
Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering


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

Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Andreas Schuderer
Dear Frank,

I'm afraid that I still haven't heard a single valid argument in favor  
of sticking to the horizontal toolbar placement. You've listed a few  
arguments, but all of them can be easily refuted, or they are just  
plainly irrelevant to the vertical-vs-horizontal question:

On July 20, you posted to the [ux-user interface] list:
> We decided to centralized the UI on top and put only the view things  
> into the status bar. On top because it is more natural to search for  
> elements there than on the side or bottom.


In your recent blog post, you clarified what you meant by "natural":
> The reading direction in western countries is from top left to  
> bottom right and users are used to finding the interface on top of  
> the document area.

This is, at it's very best, a very weak initial bias. And culture-
dependent, too! Do you earnestly hold the opinion that users will need  
to "search" for the toolbar if it's not located at the top but, say,  
at the left side? How much time do you think they'll have to invest in  
total to adapt to the new toolbar position? Something like 2 seconds  
or more like 3? I bet that, after 5 minutes of using the interface,  
there will be no users left who haven't adapted to the new location of  
this very frequently-used UI-element (and, yes: this includes the  
gaussian "long tail").

> Furthermore the height available for a bar on, e.g. the left side,  
> is too low for the amount of functions, especially on small displays  
> like netbooks.

I don't see how this is an argument against vertical bars. With a  
horizontal bar, you'll have to solve exactly the same problem anyway  
(situations where there's not enough x-space to accommodate the  
complete toolbar). Just use the same approach for the vertical bar as  
you would for the horizontal bar, anyway!

On the contrary, I see rather strong advantages of a vertical  
arrangement: It's much easier to arrange items neat and clear in a  
column than in a row, especially when it will contain horizontal text  
and sliders. And, concerning the above-mentioned space problem, there  
are already established and proven solutions for this problem in  
vertical arrangements, but not so for horizontal arrangements (think  
"scroll wheel").

> Also we did not want to spread the functionality all around the  
> application.

This argument doesn't apply to the question of placing the toolbar at  
the left or right side. Having a vertical toolbar doesn't mean  
splitting it up into different parts.

> So the team decided to go with a horizontal on top even if monitors  
> are getting wider (b) these days.

Um, and why?

I'm not joining the bashing. I still think that the Renaissance  
project, although it has its weaknesses, is heading in the right  
direction. But those arguments make the impression that you're  
rationalizing a decision after it's been made, instead of giving the  
real reasons for why the decision has been made. If the decision has  
been made without thinking or because "we wanted it so", and it can't  
be changed now for whatever reason, just be straightforward and say so.

Best regards,
Andreas

P.S.: After re-reading my post, I noticed something funny and sad  
about Frank's second argument:
> Furthermore the height available for a bar on, e.g. the left side,  
> is too low for the amount of functions, especially on small displays  
> like netbooks.
Do you notice something? Yes -- it means "chrome deserves more space  
than content!"


Am 14. Aug 2009 um 16:17 schrieb Frank Loehmann:

> Hi,
>
> Please find some answers to recent comments in our new 'Feedback on  
> Feedback' post on GullFOSS:
>
> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface
>
> Best regards,
>
> The Renaissance Team
>
> --
> Sun Microsystems GmbH                Frank Loehmann
> Nagelsweg 55                         User Experience StarOffice
> 20097 Hamburg                        Phone: (+49 40)23646 882
> Germany                              Fax:   (+49 40)23646 550
> http://www.sun.de                    mailto:[hidden email]
>
> OpenOffice.org User Experience Team
> http://ux.openoffice.org
>
> Sitz der Gesellschaft:
> Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
> Vorsitzender des Aufsichtsrates: Martin Haering
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Martin Hanzel
And what about 16:9 screen ratios?
With screens getting wider, the user will have to move  a longer distance to
the side in order to reach to sidebar.

-Martin


On Sat, Aug 15, 2009 at 9:03 AM, Andreas Schuderer
<[hidden email]>wrote:

> Dear Frank,
>
> I'm afraid that I still haven't heard a single valid argument in favor of
> sticking to the horizontal toolbar placement. You've listed a few arguments,
> but all of them can be easily refuted, or they are just plainly irrelevant
> to the vertical-vs-horizontal question:
>
> On July 20, you posted to the [ux-user interface] list:
>
>> We decided to centralized the UI on top and put only the view things into
>> the status bar. On top because it is more natural to search for elements
>> there than on the side or bottom.
>>
>
>
> In your recent blog post, you clarified what you meant by "natural":
>
>> The reading direction in western countries is from top left to bottom
>> right and users are used to finding the interface on top of the document
>> area.
>>
>
> This is, at it's very best, a very weak initial bias. And
> culture-dependent, too! Do you earnestly hold the opinion that users will
> need to "search" for the toolbar if it's not located at the top but, say, at
> the left side? How much time do you think they'll have to invest in total to
> adapt to the new toolbar position? Something like 2 seconds or more like 3?
> I bet that, after 5 minutes of using the interface, there will be no users
> left who haven't adapted to the new location of this very frequently-used
> UI-element (and, yes: this includes the gaussian "long tail").
>
>  Furthermore the height available for a bar on, e.g. the left side, is too
>> low for the amount of functions, especially on small displays like netbooks.
>>
>
> I don't see how this is an argument against vertical bars. With a
> horizontal bar, you'll have to solve exactly the same problem anyway
> (situations where there's not enough x-space to accommodate the complete
> toolbar). Just use the same approach for the vertical bar as you would for
> the horizontal bar, anyway!
>
> On the contrary, I see rather strong advantages of a vertical arrangement:
> It's much easier to arrange items neat and clear in a column than in a row,
> especially when it will contain horizontal text and sliders. And, concerning
> the above-mentioned space problem, there are already established and proven
> solutions for this problem in vertical arrangements, but not so for
> horizontal arrangements (think "scroll wheel").
>
>  Also we did not want to spread the functionality all around the
>> application.
>>
>
> This argument doesn't apply to the question of placing the toolbar at the
> left or right side. Having a vertical toolbar doesn't mean splitting it up
> into different parts.
>
>  So the team decided to go with a horizontal on top even if monitors are
>> getting wider (b) these days.
>>
>
> Um, and why?
>
> I'm not joining the bashing. I still think that the Renaissance project,
> although it has its weaknesses, is heading in the right direction. But those
> arguments make the impression that you're rationalizing a decision after
> it's been made, instead of giving the real reasons for why the decision has
> been made. If the decision has been made without thinking or because "we
> wanted it so", and it can't be changed now for whatever reason, just be
> straightforward and say so.
>
> Best regards,
> Andreas
>
> P.S.: After re-reading my post, I noticed something funny and sad about
> Frank's second argument:
>
>> Furthermore the height available for a bar on, e.g. the left side, is too
>> low for the amount of functions, especially on small displays like netbooks.
>>
> Do you notice something? Yes -- it means "chrome deserves more space than
> content!"
>
>
> Am 14. Aug 2009 um 16:17 schrieb Frank Loehmann:
>
>  Hi,
>>
>> Please find some answers to recent comments in our new 'Feedback on
>> Feedback' post on GullFOSS:
>>
>> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface
>>
>> Best regards,
>>
>> The Renaissance Team
>>
>> --
>> Sun Microsystems GmbH                Frank Loehmann
>> Nagelsweg 55                         User Experience StarOffice
>> 20097 Hamburg                        Phone: (+49 40)23646 882
>> Germany                              Fax:   (+49 40)23646 550
>> http://www.sun.de                    mailto:[hidden email]
>>
>> OpenOffice.org User Experience Team
>> http://ux.openoffice.org
>>
>> Sitz der Gesellschaft:
>> Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
>> Amtsgericht Muenchen: HRB 161028
>> Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
>> Vorsitzender des Aufsichtsrates: Martin Haering
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Andreas Schuderer
Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
> And what about 16:9 screen ratios?
> With screens getting wider, the user will have to move  a longer  
> distance to
> the side in order to reach to sidebar.

This is not an argument against the sidebar, but against a faulty  
implementation of window maximization.

See:
http://schuderer.net/pub/smart-dumb-and-grosslystupid-maximization.png

If the window is maximized correctly (topmost image), it increases the  
width just far enough to fit the contents (this is the case in most  
Mac OS X applications). The sidebar is still perfectly convenient to  
use.

If the window is maximized in a dumb way (middle image), it increases  
the width to fit the whole, mind-boggingly vast horizontal space of a  
widescreen monitor, and stretches (zooms) the content accordingly.  
This does in fact increase mouse travel for a significant portion of  
the content.

If the window is maximized in a grossly stupid way (last image), it  
stretches the window over the whole screen width, but does not zoom in  
on the content. It presents it's white, soft underbelly (gray "nothing  
to see here" area) to the user.

So, again, this argument hasn't got anything to do with the sidebar.

Cheers,
Andreas




Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:

> And what about 16:9 screen ratios?
> With screens getting wider, the user will have to move  a longer  
> distance to
> the side in order to reach to sidebar.
>
> -Martin
>
>
> On Sat, Aug 15, 2009 at 9:03 AM, Andreas Schuderer
> <[hidden email]>wrote:
>
>> Dear Frank,
>>
>> I'm afraid that I still haven't heard a single valid argument in  
>> favor of
>> sticking to the horizontal toolbar placement. You've listed a few  
>> arguments,
>> but all of them can be easily refuted, or they are just plainly  
>> irrelevant
>> to the vertical-vs-horizontal question:
>>
>> On July 20, you posted to the [ux-user interface] list:
>>
>>> We decided to centralized the UI on top and put only the view  
>>> things into
>>> the status bar. On top because it is more natural to search for  
>>> elements
>>> there than on the side or bottom.
>>>
>>
>>
>> In your recent blog post, you clarified what you meant by "natural":
>>
>>> The reading direction in western countries is from top left to  
>>> bottom
>>> right and users are used to finding the interface on top of the  
>>> document
>>> area.
>>>
>>
>> This is, at it's very best, a very weak initial bias. And
>> culture-dependent, too! Do you earnestly hold the opinion that  
>> users will
>> need to "search" for the toolbar if it's not located at the top  
>> but, say, at
>> the left side? How much time do you think they'll have to invest in  
>> total to
>> adapt to the new toolbar position? Something like 2 seconds or more  
>> like 3?
>> I bet that, after 5 minutes of using the interface, there will be  
>> no users
>> left who haven't adapted to the new location of this very  
>> frequently-used
>> UI-element (and, yes: this includes the gaussian "long tail").
>>
>> Furthermore the height available for a bar on, e.g. the left side,  
>> is too
>>> low for the amount of functions, especially on small displays like  
>>> netbooks.
>>>
>>
>> I don't see how this is an argument against vertical bars. With a
>> horizontal bar, you'll have to solve exactly the same problem anyway
>> (situations where there's not enough x-space to accommodate the  
>> complete
>> toolbar). Just use the same approach for the vertical bar as you  
>> would for
>> the horizontal bar, anyway!
>>
>> On the contrary, I see rather strong advantages of a vertical  
>> arrangement:
>> It's much easier to arrange items neat and clear in a column than  
>> in a row,
>> especially when it will contain horizontal text and sliders. And,  
>> concerning
>> the above-mentioned space problem, there are already established  
>> and proven
>> solutions for this problem in vertical arrangements, but not so for
>> horizontal arrangements (think "scroll wheel").
>>
>> Also we did not want to spread the functionality all around the
>>> application.
>>>
>>
>> This argument doesn't apply to the question of placing the toolbar  
>> at the
>> left or right side. Having a vertical toolbar doesn't mean  
>> splitting it up
>> into different parts.
>>
>> So the team decided to go with a horizontal on top even if monitors  
>> are
>>> getting wider (b) these days.
>>>
>>
>> Um, and why?
>>
>> I'm not joining the bashing. I still think that the Renaissance  
>> project,
>> although it has its weaknesses, is heading in the right direction.  
>> But those
>> arguments make the impression that you're rationalizing a decision  
>> after
>> it's been made, instead of giving the real reasons for why the  
>> decision has
>> been made. If the decision has been made without thinking or  
>> because "we
>> wanted it so", and it can't be changed now for whatever reason,  
>> just be
>> straightforward and say so.
>>
>> Best regards,
>> Andreas
>>
>> P.S.: After re-reading my post, I noticed something funny and sad  
>> about
>> Frank's second argument:
>>
>>> Furthermore the height available for a bar on, e.g. the left side,  
>>> is too
>>> low for the amount of functions, especially on small displays like  
>>> netbooks.
>>>
>> Do you notice something? Yes -- it means "chrome deserves more  
>> space than
>> content!"
>>
>>
>> Am 14. Aug 2009 um 16:17 schrieb Frank Loehmann:
>>
>> Hi,
>>>
>>> Please find some answers to recent comments in our new 'Feedback on
>>> Feedback' post on GullFOSS:
>>>
>>> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface
>>>
>>> Best regards,
>>>
>>> The Renaissance Team
>>>
>>> --
>>> Sun Microsystems GmbH                Frank Loehmann
>>> Nagelsweg 55                         User Experience StarOffice
>>> 20097 Hamburg                        Phone: (+49 40)23646 882
>>> Germany                              Fax:   (+49 40)23646 550
>>> http://www.sun.de                    mailto:[hidden email]
>>>
>>> OpenOffice.org User Experience Team
>>> http://ux.openoffice.org
>>>
>>> Sitz der Gesellschaft:
>>> Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
>>> Amtsgericht Muenchen: HRB 161028
>>> Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
>>> Vorsitzender des Aufsichtsrates: Martin Haering
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Alexandro Colorado
On Sat, Aug 15, 2009 at 9:16 AM, Andreas
Schuderer<[hidden email]> wrote:

> Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
>>
>> And what about 16:9 screen ratios?
>> With screens getting wider, the user will have to move  a longer distance
>> to
>> the side in order to reach to sidebar.
>
> This is not an argument against the sidebar, but against a faulty
> implementation of window maximization.
>
> See:
> http://schuderer.net/pub/smart-dumb-and-grosslystupid-maximization.png
>
> If the window is maximized correctly (topmost image), it increases the width
> just far enough to fit the contents (this is the case in most Mac OS X
> applications). The sidebar is still perfectly convenient to use.
>
> If the window is maximized in a dumb way (middle image), it increases the
> width to fit the whole, mind-boggingly vast horizontal space of a widescreen
> monitor, and stretches (zooms) the content accordingly. This does in fact
> increase mouse travel for a significant portion of the content.
>
> If the window is maximized in a grossly stupid way (last image), it
> stretches the window over the whole screen width, but does not zoom in on
> the content. It presents it's white, soft underbelly (gray "nothing to see
> here" area) to the user.
>
> So, again, this argument hasn't got anything to do with the sidebar.
>
> Cheers,
> Andreas
>
>
>
>
> Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
>
>> And what about 16:9 screen ratios?
>> With screens getting wider, the user will have to move  a longer distance
>> to
>> the side in order to reach to sidebar.
>>
>> -Martin
>>
>>
>> On Sat, Aug 15, 2009 at 9:03 AM, Andreas Schuderer
>> <[hidden email]>wrote:
>>
>>> Dear Frank,
>>>
>>> I'm afraid that I still haven't heard a single valid argument in favor of
>>> sticking to the horizontal toolbar placement. You've listed a few
>>> arguments,
>>> but all of them can be easily refuted, or they are just plainly
>>> irrelevant
>>> to the vertical-vs-horizontal question:
>>>
>>> On July 20, you posted to the [ux-user interface] list:
>>>
>>>> We decided to centralized the UI on top and put only the view things
>>>> into
>>>> the status bar. On top because it is more natural to search for elements
>>>> there than on the side or bottom.
>>>>
>>>
>>>
>>> In your recent blog post, you clarified what you meant by "natural":
>>>
>>>> The reading direction in western countries is from top left to bottom
>>>> right and users are used to finding the interface on top of the document
>>>> area.
>>>>
>>>
>>> This is, at it's very best, a very weak initial bias. And
>>> culture-dependent, too! Do you earnestly hold the opinion that users will
>>> need to "search" for the toolbar if it's not located at the top but, say,
>>> at
>>> the left side? How much time do you think they'll have to invest in total
>>> to
>>> adapt to the new toolbar position? Something like 2 seconds or more like
>>> 3?
>>> I bet that, after 5 minutes of using the interface, there will be no
>>> users
>>> left who haven't adapted to the new location of this very frequently-used
>>> UI-element (and, yes: this includes the gaussian "long tail").
>>>
>>> Furthermore the height available for a bar on, e.g. the left side, is too
>>>>
>>>> low for the amount of functions, especially on small displays like
>>>> netbooks.
>>>>
>>>
>>> I don't see how this is an argument against vertical bars. With a
>>> horizontal bar, you'll have to solve exactly the same problem anyway
>>> (situations where there's not enough x-space to accommodate the complete
>>> toolbar). Just use the same approach for the vertical bar as you would
>>> for
>>> the horizontal bar, anyway!
>>>
>>> On the contrary, I see rather strong advantages of a vertical
>>> arrangement:
>>> It's much easier to arrange items neat and clear in a column than in a
>>> row,
>>> especially when it will contain horizontal text and sliders. And,
>>> concerning
>>> the above-mentioned space problem, there are already established and
>>> proven
>>> solutions for this problem in vertical arrangements, but not so for
>>> horizontal arrangements (think "scroll wheel").
>>>
>>> Also we did not want to spread the functionality all around the
>>>>
>>>> application.
>>>>
>>>
>>> This argument doesn't apply to the question of placing the toolbar at the
>>> left or right side. Having a vertical toolbar doesn't mean splitting it
>>> up
>>> into different parts.
>>>
>>> So the team decided to go with a horizontal on top even if monitors are
>>>>
>>>> getting wider (b) these days.
>>>>
>>>
>>> Um, and why?
>>>
>>> I'm not joining the bashing. I still think that the Renaissance project,
>>> although it has its weaknesses, is heading in the right direction. But
>>> those
>>> arguments make the impression that you're rationalizing a decision after
>>> it's been made, instead of giving the real reasons for why the decision
>>> has
>>> been made. If the decision has been made without thinking or because "we
>>> wanted it so", and it can't be changed now for whatever reason, just be
>>> straightforward and say so.
>>>
>>> Best regards,
>>> Andreas
>>>
>>> P.S.: After re-reading my post, I noticed something funny and sad about
>>> Frank's second argument:
>>>
>>>> Furthermore the height available for a bar on, e.g. the left side, is
>>>> too
>>>> low for the amount of functions, especially on small displays like
>>>> netbooks.
>>>>
>>> Do you notice something? Yes -- it means "chrome deserves more space than
>>> content!"
>>>
>>>
>>> Am 14. Aug 2009 um 16:17 schrieb Frank Loehmann:
>>>
>>> Hi,
>>>>
>>>> Please find some answers to recent comments in our new 'Feedback on
>>>> Feedback' post on GullFOSS:
>>>>
>>>> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface
>>>>
>>>> Best regards,
>>>>
>>>> The Renaissance Team
>>>>
>>>> --
>>>> Sun Microsystems GmbH                Frank Loehmann
>>>> Nagelsweg 55                         User Experience StarOffice
>>>> 20097 Hamburg                        Phone: (+49 40)23646 882
>>>> Germany                              Fax:   (+49 40)23646 550
>>>> http://www.sun.de                    mailto:[hidden email]
>>>>
>>>> OpenOffice.org User Experience Team
>>>> http://ux.openoffice.org
>>>>
>>>> Sitz der Gesellschaft:
>>>> Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
>>>> Amtsgericht Muenchen: HRB 161028
>>>> Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
>>>> Vorsitzender des Aufsichtsrates: Martin Haering
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

+1 for vertical toolbars



--
Alexandro Colorado
OpenOffice.org Espa&ntilde;ol
IM: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Martin Hanzel
In reply to this post by Andreas Schuderer
Most operating systems maximize windows stupid-style (Windows). This would
require an override of maximizing behavior.

-Martin


On Sat, Aug 15, 2009 at 10:16 AM, Andreas Schuderer
<[hidden email]>wrote:

> Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
>
>> And what about 16:9 screen ratios?
>> With screens getting wider, the user will have to move  a longer distance
>> to
>> the side in order to reach to sidebar.
>>
>
> This is not an argument against the sidebar, but against a faulty
> implementation of window maximization.
>
> See:
> http://schuderer.net/pub/smart-dumb-and-grosslystupid-maximization.png
>
> If the window is maximized correctly (topmost image), it increases the
> width just far enough to fit the contents (this is the case in most Mac OS X
> applications). The sidebar is still perfectly convenient to use.
>
> If the window is maximized in a dumb way (middle image), it increases the
> width to fit the whole, mind-boggingly vast horizontal space of a widescreen
> monitor, and stretches (zooms) the content accordingly. This does in fact
> increase mouse travel for a significant portion of the content.
>
> If the window is maximized in a grossly stupid way (last image), it
> stretches the window over the whole screen width, but does not zoom in on
> the content. It presents it's white, soft underbelly (gray "nothing to see
> here" area) to the user.
>
> So, again, this argument hasn't got anything to do with the sidebar.
>
> Cheers,
> Andreas
>
>
>
>
> Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
>
>
>  And what about 16:9 screen ratios?
>> With screens getting wider, the user will have to move  a longer distance
>> to
>> the side in order to reach to sidebar.
>>
>> -Martin
>>
>>
>> On Sat, Aug 15, 2009 at 9:03 AM, Andreas Schuderer
>> <[hidden email]>wrote:
>>
>>  Dear Frank,
>>>
>>> I'm afraid that I still haven't heard a single valid argument in favor of
>>> sticking to the horizontal toolbar placement. You've listed a few
>>> arguments,
>>> but all of them can be easily refuted, or they are just plainly
>>> irrelevant
>>> to the vertical-vs-horizontal question:
>>>
>>> On July 20, you posted to the [ux-user interface] list:
>>>
>>>  We decided to centralized the UI on top and put only the view things
>>>> into
>>>> the status bar. On top because it is more natural to search for elements
>>>> there than on the side or bottom.
>>>>
>>>>
>>>
>>> In your recent blog post, you clarified what you meant by "natural":
>>>
>>>  The reading direction in western countries is from top left to bottom
>>>> right and users are used to finding the interface on top of the document
>>>> area.
>>>>
>>>>
>>> This is, at it's very best, a very weak initial bias. And
>>> culture-dependent, too! Do you earnestly hold the opinion that users will
>>> need to "search" for the toolbar if it's not located at the top but, say,
>>> at
>>> the left side? How much time do you think they'll have to invest in total
>>> to
>>> adapt to the new toolbar position? Something like 2 seconds or more like
>>> 3?
>>> I bet that, after 5 minutes of using the interface, there will be no
>>> users
>>> left who haven't adapted to the new location of this very frequently-used
>>> UI-element (and, yes: this includes the gaussian "long tail").
>>>
>>> Furthermore the height available for a bar on, e.g. the left side, is too
>>>
>>>> low for the amount of functions, especially on small displays like
>>>> netbooks.
>>>>
>>>>
>>> I don't see how this is an argument against vertical bars. With a
>>> horizontal bar, you'll have to solve exactly the same problem anyway
>>> (situations where there's not enough x-space to accommodate the complete
>>> toolbar). Just use the same approach for the vertical bar as you would
>>> for
>>> the horizontal bar, anyway!
>>>
>>> On the contrary, I see rather strong advantages of a vertical
>>> arrangement:
>>> It's much easier to arrange items neat and clear in a column than in a
>>> row,
>>> especially when it will contain horizontal text and sliders. And,
>>> concerning
>>> the above-mentioned space problem, there are already established and
>>> proven
>>> solutions for this problem in vertical arrangements, but not so for
>>> horizontal arrangements (think "scroll wheel").
>>>
>>> Also we did not want to spread the functionality all around the
>>>
>>>> application.
>>>>
>>>>
>>> This argument doesn't apply to the question of placing the toolbar at the
>>> left or right side. Having a vertical toolbar doesn't mean splitting it
>>> up
>>> into different parts.
>>>
>>> So the team decided to go with a horizontal on top even if monitors are
>>>
>>>> getting wider (b) these days.
>>>>
>>>>
>>> Um, and why?
>>>
>>> I'm not joining the bashing. I still think that the Renaissance project,
>>> although it has its weaknesses, is heading in the right direction. But
>>> those
>>> arguments make the impression that you're rationalizing a decision after
>>> it's been made, instead of giving the real reasons for why the decision
>>> has
>>> been made. If the decision has been made without thinking or because "we
>>> wanted it so", and it can't be changed now for whatever reason, just be
>>> straightforward and say so.
>>>
>>> Best regards,
>>> Andreas
>>>
>>> P.S.: After re-reading my post, I noticed something funny and sad about
>>> Frank's second argument:
>>>
>>>  Furthermore the height available for a bar on, e.g. the left side, is
>>>> too
>>>> low for the amount of functions, especially on small displays like
>>>> netbooks.
>>>>
>>>>  Do you notice something? Yes -- it means "chrome deserves more space
>>> than
>>> content!"
>>>
>>>
>>> Am 14. Aug 2009 um 16:17 schrieb Frank Loehmann:
>>>
>>> Hi,
>>>
>>>>
>>>> Please find some answers to recent comments in our new 'Feedback on
>>>> Feedback' post on GullFOSS:
>>>>
>>>> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface
>>>>
>>>> Best regards,
>>>>
>>>> The Renaissance Team
>>>>
>>>> --
>>>> Sun Microsystems GmbH                Frank Loehmann
>>>> Nagelsweg 55                         User Experience StarOffice
>>>> 20097 Hamburg                        Phone: (+49 40)23646 882
>>>> Germany                              Fax:   (+49 40)23646 550
>>>> http://www.sun.de                    mailto:[hidden email]
>>>>
>>>> OpenOffice.org User Experience Team
>>>> http://ux.openoffice.org
>>>>
>>>> Sitz der Gesellschaft:
>>>> Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
>>>> Amtsgericht Muenchen: HRB 161028
>>>> Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
>>>> Vorsitzender des Aufsichtsrates: Martin Haering
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Andreas Schuderer
Good to hear you agree.

Am 15. Aug 2009 um 19:53 schrieb Martin Hanzel:

> Most operating systems maximize windows stupid-style (Windows). This  
> would
> require an override of maximizing behavior.
>
> -Martin
>
>
> On Sat, Aug 15, 2009 at 10:16 AM, Andreas Schuderer
> <[hidden email]>wrote:
>
>> Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
>>
>>> And what about 16:9 screen ratios?
>>> With screens getting wider, the user will have to move  a longer  
>>> distance
>>> to
>>> the side in order to reach to sidebar.
>>>
>>
>> This is not an argument against the sidebar, but against a faulty
>> implementation of window maximization.
>>
>> See:
>> http://schuderer.net/pub/smart-dumb-and-grosslystupid- 
>> maximization.png
>>
>> If the window is maximized correctly (topmost image), it increases  
>> the
>> width just far enough to fit the contents (this is the case in most  
>> Mac OS X
>> applications). The sidebar is still perfectly convenient to use.
>>
>> If the window is maximized in a dumb way (middle image), it  
>> increases the
>> width to fit the whole, mind-boggingly vast horizontal space of a  
>> widescreen
>> monitor, and stretches (zooms) the content accordingly. This does  
>> in fact
>> increase mouse travel for a significant portion of the content.
>>
>> If the window is maximized in a grossly stupid way (last image), it
>> stretches the window over the whole screen width, but does not zoom  
>> in on
>> the content. It presents it's white, soft underbelly (gray "nothing  
>> to see
>> here" area) to the user.
>>
>> So, again, this argument hasn't got anything to do with the sidebar.
>>
>> Cheers,
>> Andreas
>>
>>
>>
>>
>> Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
>>
>>
>> And what about 16:9 screen ratios?
>>> With screens getting wider, the user will have to move  a longer  
>>> distance
>>> to
>>> the side in order to reach to sidebar.
>>>
>>> -Martin
>>>
>>>
>>> On Sat, Aug 15, 2009 at 9:03 AM, Andreas Schuderer
>>> <[hidden email]>wrote:
>>>
>>> Dear Frank,
>>>>
>>>> I'm afraid that I still haven't heard a single valid argument in  
>>>> favor of
>>>> sticking to the horizontal toolbar placement. You've listed a few
>>>> arguments,
>>>> but all of them can be easily refuted, or they are just plainly
>>>> irrelevant
>>>> to the vertical-vs-horizontal question:
>>>>
>>>> On July 20, you posted to the [ux-user interface] list:
>>>>
>>>> We decided to centralized the UI on top and put only the view  
>>>> things
>>>>> into
>>>>> the status bar. On top because it is more natural to search for  
>>>>> elements
>>>>> there than on the side or bottom.
>>>>>
>>>>>
>>>>
>>>> In your recent blog post, you clarified what you meant by  
>>>> "natural":
>>>>
>>>> The reading direction in western countries is from top left to  
>>>> bottom
>>>>> right and users are used to finding the interface on top of the  
>>>>> document
>>>>> area.
>>>>>
>>>>>
>>>> This is, at it's very best, a very weak initial bias. And
>>>> culture-dependent, too! Do you earnestly hold the opinion that  
>>>> users will
>>>> need to "search" for the toolbar if it's not located at the top  
>>>> but, say,
>>>> at
>>>> the left side? How much time do you think they'll have to invest  
>>>> in total
>>>> to
>>>> adapt to the new toolbar position? Something like 2 seconds or  
>>>> more like
>>>> 3?
>>>> I bet that, after 5 minutes of using the interface, there will be  
>>>> no
>>>> users
>>>> left who haven't adapted to the new location of this very  
>>>> frequently-used
>>>> UI-element (and, yes: this includes the gaussian "long tail").
>>>>
>>>> Furthermore the height available for a bar on, e.g. the left  
>>>> side, is too
>>>>
>>>>> low for the amount of functions, especially on small displays like
>>>>> netbooks.
>>>>>
>>>>>
>>>> I don't see how this is an argument against vertical bars. With a
>>>> horizontal bar, you'll have to solve exactly the same problem  
>>>> anyway
>>>> (situations where there's not enough x-space to accommodate the  
>>>> complete
>>>> toolbar). Just use the same approach for the vertical bar as you  
>>>> would
>>>> for
>>>> the horizontal bar, anyway!
>>>>
>>>> On the contrary, I see rather strong advantages of a vertical
>>>> arrangement:
>>>> It's much easier to arrange items neat and clear in a column than  
>>>> in a
>>>> row,
>>>> especially when it will contain horizontal text and sliders. And,
>>>> concerning
>>>> the above-mentioned space problem, there are already established  
>>>> and
>>>> proven
>>>> solutions for this problem in vertical arrangements, but not so for
>>>> horizontal arrangements (think "scroll wheel").
>>>>
>>>> Also we did not want to spread the functionality all around the
>>>>
>>>>> application.
>>>>>
>>>>>
>>>> This argument doesn't apply to the question of placing the  
>>>> toolbar at the
>>>> left or right side. Having a vertical toolbar doesn't mean  
>>>> splitting it
>>>> up
>>>> into different parts.
>>>>
>>>> So the team decided to go with a horizontal on top even if  
>>>> monitors are
>>>>
>>>>> getting wider (b) these days.
>>>>>
>>>>>
>>>> Um, and why?
>>>>
>>>> I'm not joining the bashing. I still think that the Renaissance  
>>>> project,
>>>> although it has its weaknesses, is heading in the right  
>>>> direction. But
>>>> those
>>>> arguments make the impression that you're rationalizing a  
>>>> decision after
>>>> it's been made, instead of giving the real reasons for why the  
>>>> decision
>>>> has
>>>> been made. If the decision has been made without thinking or  
>>>> because "we
>>>> wanted it so", and it can't be changed now for whatever reason,  
>>>> just be
>>>> straightforward and say so.
>>>>
>>>> Best regards,
>>>> Andreas
>>>>
>>>> P.S.: After re-reading my post, I noticed something funny and sad  
>>>> about
>>>> Frank's second argument:
>>>>
>>>> Furthermore the height available for a bar on, e.g. the left  
>>>> side, is
>>>>> too
>>>>> low for the amount of functions, especially on small displays like
>>>>> netbooks.
>>>>>
>>>>> Do you notice something? Yes -- it means "chrome deserves more  
>>>>> space
>>>> than
>>>> content!"
>>>>
>>>>
>>>> Am 14. Aug 2009 um 16:17 schrieb Frank Loehmann:
>>>>
>>>> Hi,
>>>>
>>>>>
>>>>> Please find some answers to recent comments in our new 'Feedback  
>>>>> on
>>>>> Feedback' post on GullFOSS:
>>>>>
>>>>> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface
>>>>>
>>>>> Best regards,
>>>>>
>>>>> The Renaissance Team
>>>>>
>>>>> --
>>>>> Sun Microsystems GmbH                Frank Loehmann
>>>>> Nagelsweg 55                         User Experience StarOffice
>>>>> 20097 Hamburg                        Phone: (+49 40)23646 882
>>>>> Germany                              Fax:   (+49 40)23646 550
>>>>> http://www.sun.de                    mailto:[hidden email]
>>>>>
>>>>> OpenOffice.org User Experience Team
>>>>> http://ux.openoffice.org
>>>>>
>>>>> Sitz der Gesellschaft:
>>>>> Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
>>>>> Amtsgericht Muenchen: HRB 161028
>>>>> Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
>>>>> Vorsitzender des Aufsichtsrates: Martin Haering
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Martin Hanzel
>
> Good to hear you agree.


I agreed a long time ago. I think sidebars are a great idea........ just not
tested enough in the real world.

Speaking of which, I think that implementing a sidebar-type interface in OOo
will also inspire other applications to do the same.

Though I also can't express enough how many more people we will satisfy with
a customizable plugin-type interface.

-Martin


On Sat, Aug 15, 2009 at 2:15 PM, Andreas Schuderer
<[hidden email]>wrote:

> Good to hear you agree.
>
> Am 15. Aug 2009 um 19:53 schrieb Martin Hanzel:
>
>
>  Most operating systems maximize windows stupid-style (Windows). This would
>> require an override of maximizing behavior.
>>
>> -Martin
>>
>>
>> On Sat, Aug 15, 2009 at 10:16 AM, Andreas Schuderer
>> <[hidden email]>wrote:
>>
>>  Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
>>>
>>>  And what about 16:9 screen ratios?
>>>> With screens getting wider, the user will have to move  a longer
>>>> distance
>>>> to
>>>> the side in order to reach to sidebar.
>>>>
>>>>
>>> This is not an argument against the sidebar, but against a faulty
>>> implementation of window maximization.
>>>
>>> See:
>>> http://schuderer.net/pub/smart-dumb-and-grosslystupid-maximization.png
>>>
>>> If the window is maximized correctly (topmost image), it increases the
>>> width just far enough to fit the contents (this is the case in most Mac
>>> OS X
>>> applications). The sidebar is still perfectly convenient to use.
>>>
>>> If the window is maximized in a dumb way (middle image), it increases the
>>> width to fit the whole, mind-boggingly vast horizontal space of a
>>> widescreen
>>> monitor, and stretches (zooms) the content accordingly. This does in fact
>>> increase mouse travel for a significant portion of the content.
>>>
>>> If the window is maximized in a grossly stupid way (last image), it
>>> stretches the window over the whole screen width, but does not zoom in on
>>> the content. It presents it's white, soft underbelly (gray "nothing to
>>> see
>>> here" area) to the user.
>>>
>>> So, again, this argument hasn't got anything to do with the sidebar.
>>>
>>> Cheers,
>>> Andreas
>>>
>>>
>>>
>>>
>>> Am 15. Aug 2009 um 15:12 schrieb Martin Hanzel:
>>>
>>>
>>> And what about 16:9 screen ratios?
>>>
>>>> With screens getting wider, the user will have to move  a longer
>>>> distance
>>>> to
>>>> the side in order to reach to sidebar.
>>>>
>>>> -Martin
>>>>
>>>>
>>>> On Sat, Aug 15, 2009 at 9:03 AM, Andreas Schuderer
>>>> <[hidden email]>wrote:
>>>>
>>>> Dear Frank,
>>>>
>>>>>
>>>>> I'm afraid that I still haven't heard a single valid argument in favor
>>>>> of
>>>>> sticking to the horizontal toolbar placement. You've listed a few
>>>>> arguments,
>>>>> but all of them can be easily refuted, or they are just plainly
>>>>> irrelevant
>>>>> to the vertical-vs-horizontal question:
>>>>>
>>>>> On July 20, you posted to the [ux-user interface] list:
>>>>>
>>>>> We decided to centralized the UI on top and put only the view things
>>>>>
>>>>>> into
>>>>>> the status bar. On top because it is more natural to search for
>>>>>> elements
>>>>>> there than on the side or bottom.
>>>>>>
>>>>>>
>>>>>>
>>>>> In your recent blog post, you clarified what you meant by "natural":
>>>>>
>>>>> The reading direction in western countries is from top left to bottom
>>>>>
>>>>>> right and users are used to finding the interface on top of the
>>>>>> document
>>>>>> area.
>>>>>>
>>>>>>
>>>>>>  This is, at it's very best, a very weak initial bias. And
>>>>> culture-dependent, too! Do you earnestly hold the opinion that users
>>>>> will
>>>>> need to "search" for the toolbar if it's not located at the top but,
>>>>> say,
>>>>> at
>>>>> the left side? How much time do you think they'll have to invest in
>>>>> total
>>>>> to
>>>>> adapt to the new toolbar position? Something like 2 seconds or more
>>>>> like
>>>>> 3?
>>>>> I bet that, after 5 minutes of using the interface, there will be no
>>>>> users
>>>>> left who haven't adapted to the new location of this very
>>>>> frequently-used
>>>>> UI-element (and, yes: this includes the gaussian "long tail").
>>>>>
>>>>> Furthermore the height available for a bar on, e.g. the left side, is
>>>>> too
>>>>>
>>>>>  low for the amount of functions, especially on small displays like
>>>>>> netbooks.
>>>>>>
>>>>>>
>>>>>>  I don't see how this is an argument against vertical bars. With a
>>>>> horizontal bar, you'll have to solve exactly the same problem anyway
>>>>> (situations where there's not enough x-space to accommodate the
>>>>> complete
>>>>> toolbar). Just use the same approach for the vertical bar as you would
>>>>> for
>>>>> the horizontal bar, anyway!
>>>>>
>>>>> On the contrary, I see rather strong advantages of a vertical
>>>>> arrangement:
>>>>> It's much easier to arrange items neat and clear in a column than in a
>>>>> row,
>>>>> especially when it will contain horizontal text and sliders. And,
>>>>> concerning
>>>>> the above-mentioned space problem, there are already established and
>>>>> proven
>>>>> solutions for this problem in vertical arrangements, but not so for
>>>>> horizontal arrangements (think "scroll wheel").
>>>>>
>>>>> Also we did not want to spread the functionality all around the
>>>>>
>>>>>  application.
>>>>>>
>>>>>>
>>>>>>  This argument doesn't apply to the question of placing the toolbar at
>>>>> the
>>>>> left or right side. Having a vertical toolbar doesn't mean splitting it
>>>>> up
>>>>> into different parts.
>>>>>
>>>>> So the team decided to go with a horizontal on top even if monitors are
>>>>>
>>>>>  getting wider (b) these days.
>>>>>>
>>>>>>
>>>>>>  Um, and why?
>>>>>
>>>>> I'm not joining the bashing. I still think that the Renaissance
>>>>> project,
>>>>> although it has its weaknesses, is heading in the right direction. But
>>>>> those
>>>>> arguments make the impression that you're rationalizing a decision
>>>>> after
>>>>> it's been made, instead of giving the real reasons for why the decision
>>>>> has
>>>>> been made. If the decision has been made without thinking or because
>>>>> "we
>>>>> wanted it so", and it can't be changed now for whatever reason, just be
>>>>> straightforward and say so.
>>>>>
>>>>> Best regards,
>>>>> Andreas
>>>>>
>>>>> P.S.: After re-reading my post, I noticed something funny and sad about
>>>>> Frank's second argument:
>>>>>
>>>>> Furthermore the height available for a bar on, e.g. the left side, is
>>>>>
>>>>>> too
>>>>>> low for the amount of functions, especially on small displays like
>>>>>> netbooks.
>>>>>>
>>>>>> Do you notice something? Yes -- it means "chrome deserves more space
>>>>>>
>>>>> than
>>>>> content!"
>>>>>
>>>>>
>>>>> Am 14. Aug 2009 um 16:17 schrieb Frank Loehmann:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>> Please find some answers to recent comments in our new 'Feedback on
>>>>>> Feedback' post on GullFOSS:
>>>>>>
>>>>>> http://blogs.sun.com/GullFOSS/entry/prototyping_a_new_user_interface
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> The Renaissance Team
>>>>>>
>>>>>> --
>>>>>> Sun Microsystems GmbH                Frank Loehmann
>>>>>> Nagelsweg 55                         User Experience StarOffice
>>>>>> 20097 Hamburg                        Phone: (+49 40)23646 882
>>>>>> Germany                              Fax:   (+49 40)23646 550
>>>>>> http://www.sun.de                    mailto:[hidden email]
>>>>>>
>>>>>> OpenOffice.org User Experience Team
>>>>>> http://ux.openoffice.org
>>>>>>
>>>>>> Sitz der Gesellschaft:
>>>>>> Sun Microsystems GmbH,Sonnenallee 1, D-85551 Kirchheim-Heimstetten
>>>>>> Amtsgericht Muenchen: HRB 161028
>>>>>> Geschaeftsfuehrer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
>>>>>> Vorsitzender des Aufsichtsrates: Martin Haering
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>>  ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Cor Nouws
In reply to this post by Andreas Schuderer
Hi all,

Since I find the discussion interesting - no preference yet from my side
- I post some additional remarks. Trying to avoid right/wrong statements ...

Andreas Schuderer wrote (15-8-2009 15:03)

> On July 20, you posted to the [ux-user interface] list:
>> We decided to centralized the UI on top and put only the view things
>> into the status bar. On top because it is more natural to search for
>> elements there than on the side or bottom.
>
> In your recent blog post, you clarified what you meant by "natural":
>> The reading direction in western countries is from top left to bottom
>> right and users are used to finding the interface on top of the
>> document area.
>
> This is, at it's very best, a very weak initial bias. And
> culture-dependent, too! Do you earnestly hold the opinion that users
> will need to "search" for the toolbar if it's not located at the top
> but, say, at the left side? How much time do you think they'll have to
> invest in total to adapt to the new toolbar position? Something like 2
> seconds or more like 3? I bet that, after 5 minutes of using the
> interface, there will be no users left who haven't adapted to the new
> location of this very frequently-used UI-element (and, yes: this
> includes the gaussian "long tail").

I also expect that users would learn it very fast. But have no proof of
example for that.

>> Furthermore the height available for a bar on, e.g. the left side, is
>> too low for the amount of functions, especially on small displays like
>> netbooks.
>
> I don't see how this is an argument against vertical bars. With a
> horizontal bar, you'll have to solve exactly the same problem anyway
> (situations where there's not enough x-space to accommodate the complete
> toolbar). Just use the same approach for the vertical bar as you would
> for the horizontal bar, anyway!

Only thing is that on a vertical bar, it would be needed to make it
wider to find enough room. Might make it more difficult?

(I once have read that implementing the Red-Flag version (vertical pane
on the right) would be difficult. But I forgot the reason.)


And what about this interface:

   =======================================OOo==
   =  menu                                    =
   =  'toolbars'                              =
   = ---------------------------------------- =
   =       -                         -        =
   = navi  -                         - stylist=
   = gator -                         -        =
   =       -                         -        =
   =       -                         -        =
   =       -                         -        =
   =       -                         -        =
   =       -                         -        =
   ============================================

   is this horizontal or vertical ??

> On the contrary, I see rather strong advantages of a vertical
> arrangement: It's much easier to arrange items neat and clear in a
> column than in a row, especially when it will contain horizontal text
> and sliders. And, concerning the above-mentioned space problem, there
> are already established and proven solutions for this problem in
> vertical arrangements, but not so for horizontal arrangements (think
> "scroll wheel").

Shift-scroll ;-)

>> Also we did not want to spread the functionality all around the
>> application.
>
> This argument doesn't apply to the question of placing the toolbar at
> the left or right side. Having a vertical toolbar doesn't mean splitting
> it up into different parts.

Apart from that: when working in Impress, with lots of functions and
settings, is it a drawback, if all is divided in two/three groups on the
screen?

Looking forward to ideas :-)
Cor

--
Cor Nouws - nl.OpenOffice.org marketing contact
Ontwikkelaar? Join! http://council.openoffice.org/developers.html
Gevoel niet vrij te zijn? Zie www.nieuwsteversie.nl

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

Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Christoph Noack-4
In reply to this post by Andreas Schuderer
Hi Andreas!

I think you raised very good points - some of them can be explained
easily, for some others we will require help by the other Renaissance
team members. Whenever one of them will become available again :-)

If I get your message right, it is about the rationale concerning some
design decisions. Let's go...

Am Samstag, den 15.08.2009, 15:03 +0200 schrieb Andreas Schuderer:
> Dear Frank,
>
> I'm afraid that I still haven't heard a single valid argument in favor  
> of sticking to the horizontal toolbar placement. You've listed a few  
> arguments, but all of them can be easily refuted, or they are just  
> plainly irrelevant to the vertical-vs-horizontal question:

On a broader view, I currently know how difficult it is to provide
answers with a sufficient level of detail, which serves everybody well.
As I know from experience, some of the decisions are the "best
compromise" are really hard to communicate.

Concerning the decision horizontal vs. vertical use of space, I remember
that Frank said (currently I lack a link to the blog post or mail), that
those things will get prototyped first, that are unavailable in products
which can easily used for testing (e.g. RedOffice):
http://www.redoffice.com/

When we look back, the first ideas which have been realized (scrolling
toolbar) are very different to the current result. So I think the
decision to go for different UI might still be open, if it can be proven
that its superior.

Another thing I remember when looking back to the preparation of the
"Design Proposal Collection" in Hamburg was, that OOo should somehow
preserve a "familiar" look. Later, we omitted this "requirement" to not
(additionally) hinder the creativity of the proposal authors - maybe
this was still the reason to start with something which re-uses the
current toolbar screen area.

> On July 20, you posted to the [ux-user interface] list:
> > We decided to centralized the UI on top and put only the view things  
> > into the status bar. On top because it is more natural to search for  
> > elements there than on the side or bottom.
>
> In your recent blog post, you clarified what you meant by "natural":
> > The reading direction in western countries is from top left to  
> > bottom right and users are used to finding the interface on top of  
> > the document area.
>
> This is, at it's very best, a very weak initial bias. And culture-
> dependent, too! Do you earnestly hold the opinion that users will need  
> to "search" for the toolbar if it's not located at the top but, say,  
> at the left side? How much time do you think they'll have to invest in  
> total to adapt to the new toolbar position? Something like 2 seconds  
> or more like 3? I bet that, after 5 minutes of using the interface,  
> there will be no users left who haven't adapted to the new location of  
> this very frequently-used UI-element (and, yes: this includes the  
> gaussian "long tail").

Mmh, I would say that Frank intended to say that a wide bar might be
better than a tall one - which might (!) reduce scanning time. The
problem is, that this has to be tested or looked up in scientific
papers.

> > Furthermore the height available for a bar on, e.g. the left side,  
> > is too low for the amount of functions, especially on small displays  
> > like netbooks.
>
> I don't see how this is an argument against vertical bars. With a  
> horizontal bar, you'll have to solve exactly the same problem anyway  
> (situations where there's not enough x-space to accommodate the  
> complete toolbar). Just use the same approach for the vertical bar as  
> you would for the horizontal bar, anyway!

That's correct

> On the contrary, I see rather strong advantages of a vertical  
> arrangement: It's much easier to arrange items neat and clear in a  
> column than in a row, especially when it will contain horizontal text  
> and sliders. And, concerning the above-mentioned space problem, there  
> are already established and proven solutions for this problem in  
> vertical arrangements, but not so for horizontal arrangements (think  
> "scroll wheel").

My initial thought is, that scrolling moves items which might be bad for
the habituation of the users. But this is an initial thought - maybe the
others can better comment on that.

> > Also we did not want to spread the functionality all around the  
> > application.
>
> This argument doesn't apply to the question of placing the toolbar at  
> the left or right side. Having a vertical toolbar doesn't mean  
> splitting it up into different parts.

At least if we consider the decision (how final it may be, I don't know)
that we will still provide a conventional application menu, the elements
are "splitted" visually.

> > So the team decided to go with a horizontal on top even if monitors  
> > are getting wider (b) these days.
>
> Um, and why?
>
> I'm not joining the bashing. I still think that the Renaissance  
> project, although it has its weaknesses, is heading in the right  
> direction. But those arguments make the impression that you're  
> rationalizing a decision after it's been made, instead of giving the  
> real reasons for why the decision has been made. If the decision has  
> been made without thinking or because "we wanted it so", and it can't  
> be changed now for whatever reason, just be straightforward and say so.

I strongly support the last sentence, although I'm sure that there are
real reasons to go for this or that (I decided to support the team by
doing other stuff related to more current versions of OOo, so they can
better concentrate on Renaissance - the result is that my knowledge
concerning the decisions is limited). We can only ask for more
information "just in time" - which hopefully will relax later
discussions.

> Best regards,
> Andreas
>
> P.S.: After re-reading my post, I noticed something funny and sad  
> about Frank's second argument:
> > Furthermore the height available for a bar on, e.g. the left side,  
> > is too low for the amount of functions, especially on small displays  
> > like netbooks.
> Do you notice something? Yes -- it means "chrome deserves more space  
> than content!"

There is also something which made me sad in the last few days - but
this is not targeted at you, Andreas. Especially at the moment, time and
money is very valuable for Sun. Each discussion/comment/blog which is
driven by "opinions" instead of arguments might result in distrust by
those who approve the budget for the UX teams and other participants.
Until now, there is no final feedback by real end-customers, so these
people may rely on what they hear in the net or read in the press.

Okay, after reading my comments again I know that I didn't provide any
substantial input except having a look at the first results and further
"bothering" the team in providing information what they currently do
instead of explaining design decisions afterwards.

By the way, I also started to better explain things like that. A short
overview why we headed towards a certain design in Printerpullpages is
here - maybe this might serve as an example:
http://wiki.services.openoffice.org/wiki/Printerpullpages#Application_Independent_Design_Decisions

Have a nice evening,
Christoph

[...]


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

Reply | Threaded
Open this post in threaded view
|

Re: Project Renaissance: Feedback on Feedback

Sophie-2-2
In reply to this post by Cor Nouws
Hi all,
Cor Nouws wrote:

> Hi all,
>
> Since I find the discussion interesting - no preference yet from my side
> - I post some additional remarks. Trying to avoid right/wrong statements
> ...
>
> Andreas Schuderer wrote (15-8-2009 15:03)
>
>> On July 20, you posted to the [ux-user interface] list:
>>> We decided to centralized the UI on top and put only the view things
>>> into the status bar. On top because it is more natural to search for
>>> elements there than on the side or bottom.
>>
>> In your recent blog post, you clarified what you meant by "natural":
>>> The reading direction in western countries is from top left to bottom
>>> right and users are used to finding the interface on top of the
>>> document area.
>>
>> This is, at it's very best, a very weak initial bias. And
>> culture-dependent, too! Do you earnestly hold the opinion that users
>> will need to "search" for the toolbar if it's not located at the top
>> but, say, at the left side? How much time do you think they'll have to
>> invest in total to adapt to the new toolbar position? Something like 2
>> seconds or more like 3? I bet that, after 5 minutes of using the
>> interface, there will be no users left who haven't adapted to the new
>> location of this very frequently-used UI-element (and, yes: this
>> includes the gaussian "long tail").
>
> I also expect that users would learn it very fast. But have no proof of
> example for that.
>
>>> Furthermore the height available for a bar on, e.g. the left side, is
>>> too low for the amount of functions, especially on small displays
>>> like netbooks.
>>
>> I don't see how this is an argument against vertical bars. With a
>> horizontal bar, you'll have to solve exactly the same problem anyway
>> (situations where there's not enough x-space to accommodate the
>> complete toolbar). Just use the same approach for the vertical bar as
>> you would for the horizontal bar, anyway!
>
> Only thing is that on a vertical bar, it would be needed to make it
> wider to find enough room. Might make it more difficult?
>
> (I once have read that implementing the Red-Flag version (vertical pane
> on the right) would be difficult. But I forgot the reason.)

 From what I remember, it was because of the string space needed for
some locales. Look at the space used under each icon, it's very short.

Kind regards
Sophie

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

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] Project Renaissance: Feedback on Feedback

Andreas Bartel
In reply to this post by Frank Loehmann
Hi everyone,

yes André, I would agree that a lot of misconceptions inside and  
specifically outside our community lead to effects/thoughts/worries  
that might actually be not that imminent. Some reasons are certainly  
some sort of missing information, lack of understanding of UX  
engineering/product design or pure lack of interest to dig deeper and  
give it thought. That are just my personal concerns/explanations based  
on the comments I read so far all over the net.

When I am finished with going through appr. 800 mails, I will try to  
address your concerns and those of many others by blogging on  
GullFoss. However, I am also curious, without any judgement, why so  
little attention was directed towards e.g. my blog weeks ago (http://blogs.sun.com/GullFOSS/entry/what_s_on_vogue_in 
), where I tried to explain what we were up to (that post was really  
short, I can't talk as long as Christoph N. ;-)). And I am, as an UX  
advocate, very much interested why so many active community members  
are that frightened by the change that may be ahead of us regarding  
the new UI, however it might turn out to be. Again, no offense or any  
judgement, I really enjoy the comments so far, even the trolls ;-)  
That is what prototyping is for! I am just really curious about the  
overall change resistance and how community members perceive that  
attitude.

In sum, I would like to remind everyone what is currently/actually/
really going on. This is the first time OpenOffice.org is being  
developed in the open to a degree that virtually everyone can be a  
part of, give comments and see what happens instantly. And I stress  
"TO A DEGREE" specifically because we have chosen a very structured  
approach to ensure a professional and manageable UX work with very,  
very, VEEEEERY limited resources WHILE being as transparent as the  
circumstances allow us to be. We really appreciate all of your  
feedback but you need to have (reminds me of a song ;-)) a little  
faith in our abilities to make something out of that feedback. Be a  
bit more open, more curious and remain confident that we will actually  
make progress and improve OpenOffice.org, even if it SEEMS to happen  
in slow-motion and on the contrary to you personal attitude/opinion/
preference. If you think of all the new stuff we have done and  
achieved over the last 10 month, come-on, look at all the attention we  
suddenly get just by putting up a mid-fi prototype to the web, and how  
much insights and knowledge we've gained up to now.

However, last but not least, I want to shortly state what was the main  
goal of the prototypes you have seen so far. Actually, it's pretty  
simple. What would be the best UI for a peace of software, in general?  
Well, that would certainly be one that offers instant access to all of  
its features with no hurdles. Well, in Impress that would be a UI with  
over 300 buttons in one toolbar. But that would make finding the  
single one you need at certain point in time very hard. To solve that  
problem, we would need to give the features some structure, like in  
the library. We could label and sort them in alphabetic order or we  
could arrange them in meaningful groups. But not too many groups since  
searching for a particularly command/feature among many groups (or  
toolbars) would also be too complex. But then again, how do we create  
groups and how do we label them? One possibility would be to create  
groups that match the tasks or better subtasks/subgoals a user is able  
to accomplish/achieve with Impress. OK, we tried exactly that. But the  
first hurdle we had to overcome was to arrange many groups on a 2D  
surface. So we required a mechanism to switch among groups. Tabs  
seemed very handy to solve that issue. Still, we had to squeeze over  
300 features into the groups. We thought about the purpose of the  
menus when they were invented and came up with the idea to keep them,  
at least to some degree. That would save us from squeezing each and  
every function into the tabs and provide existing users with some sort  
of familiarity. The strategy was to move all important features into  
the tabs and keeps the rest in the menus. That would make important  
feature prominent and the rest discoverable through menus. Of course  
we thought of increasing context-sensitivity as much as possible but  
that was never finalized in the prototype. Hence, the main goal of the  
prototypes was to check how visually to arrange groups in a  
comprehendible and efficient way while keeping the menu alive.  
Consequently, we did not spend a lot of efforts to think about group  
labels, toolbar/tab height or button size. All the fun stuff actually  
emerged in between e.g. 3D view, master pages view, editing in slide  
sorter view etc.

So, that's enough for today. I am loosing focus :-). Hope that this  
helps you a bit to get a more clear picture of what has and will  
happen in the Renaissance Project.

Best,
Andreas

Am 24.08.2009 um 19:31 schrieb André Schnabel:

> Hi,
>
> late and yet another feedback to the feedback :)
>
> We had some discussion at [hidden email] about the  
> prototype, project renaissance, the feedback and so on.
>
> First I like to thanks Christian Lippka for his patience and great  
> information on the list - and also to Christoph Noack, who stepped  
> in very late ( 12:21 am local time) to the discussion, but also  
> providing very valuable feedback.
>
> The discussion brought not much new feedback on the prototypes  
> (there is enough feedback around). But as "intrested users" could  
> now discuss in their native language, it became obvious, that  
> important informations are missing or just not visible outside the  
> renaissance project, even if you are reading the blogs and status  
> presentations. So I'd guess, much of the very bad feedback (mainly  
> the rants) are because of this missing information.
>
> For instance, Christian stated very early in the discussion, that  
> all core team members agreed to stay with the menus - and that also  
> contxt menues will be kept (but likely to be reworked). Before this  
> statement many (including me) feared, that menues and context menues  
> might go away and the new toolbars will be the "one and only  
> interface". You might call this silly fears - but we just did not  
> know better.
>
>
> So I'd like to ask the renaissance team to provide better  
> information, about what is actually already desided (or at least  
> what is extremely likely to be in the upcoming interface). It is  
> also important to clearly say, what is a current prototype about -  
> and what not. (E.g. it was unclear if the last prototype had no  
> context menues because we are going to remove them or beause this  
> was not the focus of the prototype).
>
> I think, it was also helpfull to provide this information in some  
> kind of "management summary".  Although many community members are  
> interested in renaissance, it is hard to read full text of all the  
> blogs. As ummary would help to identify the "interesting part" of a  
> blog and read the details if necessary.
> This might also help  the community to better react on bad press  
> coverage. The community can quite easily join online discussions and  
> give it direction - if we have the information available.
>
>
>
> Thanks for the work on UX and Renaissance.
>
> André
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
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] Project Renaissance: Feedback on Feedback

Cor Nouws
Hi Andreas,

Andreas Bartel wrote (25-8-2009 0:22)

> [...]
> So, that's enough for today. I am loosing focus :-). Hope that this
> helps you a bit to get a more clear picture of what has and will happen
> in the Renaissance Project.

Thanks for explaining and it was good to see the new prototype 0.16
(happened to start when I use the link on the wiki :-) ) with a great
step in the direction of the balance you wrote about.

For future trying, it might be less confusing if only two most recent
versions are provided (for the great mass). Might help preventing wrong
impressions of what we are heading for ;-)

I have some questions left, in some mails, but just wait a little more
for answers to appear.

Ciao - Cor


--
Cor Nouws
   - nl.OpenOffice.org marketing contact
   - Community Contributor Representative in the Community Council
Gevoel niet vrij te zijn? Zie www.nieuwsteversie.nl

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