Petition against project Renaissance

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

Petition against project Renaissance

Andreas Bartel
Hi everyone,

unfortunately I would not be able to sleep well seeing this:

http://www.petitionspot.com/discussion/view/47163

Bernd already posted a pretty nice reply. However, what is going on  
there? Anyone, any idea? What do you think of that?

Best,
Andreas

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

Reply | Threaded
Open this post in threaded view
|

Re: Petition against project Renaissance

Martin Hanzel
It seems that even more people are against the Prototype UI.

This shouldn't affect us, for two reasons:
1. Openoffice is Free Software. The people who work on OOo like us are
volunteers who do it just for the hell of doing it. I don't see the
petitioners doing anything on a similar scale, short of complaining. It
disgusts me.

"The better alternative is to actually become part of that process and add
own value to it by providing own suggestions for new ideas or providing
comments to those ideas and suggestions of others in an attempt to influence
the direction into which this process is to be going. Similar just
complaining about the fact that software does have issues (and all software
does) does not help much."


Hear, hear. Great speaking, Bernd!

2. We have decided (sort of) that the Prototype UI is NOT the UI that will
be in the next major version of OOo. Actually, we have barely decided
anything, at the moment. The petitioners are ignorant. The prototype UI was
just an idea that someone had, and I give them credit because they took a
huge chunk out of their time and effort to show the world their opinion in a
little Java application. Likewise, others have their own opinions (I've made
two mockups so far), and I understand some people's natural hostility
towards these opinions. But to express that hostility in a way that implies
STOPPING the flow of great ideas (made even worse by the fact that these
ideas go towards Free Software) is insolence in every way. Petitioners, if
you don't like it, and have done nothing to fix it, you are free to migrate
to MS Office any day and rid us of your presence.

If anything, this petition has told us only that we should not lean towards
a Ribbon-esque UI, like the one in the current prototype, and perhaps
implement a sidebar. We should'nt discard the great ideas in the forums and
mailing lists, sidebar or other, because of a handful of people's opinions.
Don't lose sleep over it.

Sorry for the ramble,

.Martin


On Mon, Aug 24, 2009 at 7:03 PM, Andreas Bartel <[hidden email]>wrote:

> Hi everyone,
>
> unfortunately I would not be able to sleep well seeing this:
>
> http://www.petitionspot.com/discussion/view/47163
>
> Bernd already posted a pretty nice reply. However, what is going on there?
> Anyone, any idea? What do you think of that?
>
> Best,
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Petition against project Renaissance

Miroslav Mazel
Hi everyone,
I think the petitioners have a good reason to be mad -- not to say that I
don't like the movement. Up to now, OOo was kind of the software to go to
escape the ribbon. I guess I feel for them, because I've witnessed a similar
thing with one of my favorite vector editors (a long while ago),
CreatureHouse Expression, which Microsoft bought and heartlessly butchered.
In any case, I think the OOo branch of Sun should:
* Publicly announce that they'll end up with a flexible UI, and how flexible
it will be. (I've been very vocal about the fact that toolbars can be pretty
easily transformed into panels, and therefore a ribbon, just by resizing, so
everyone can customize a UI to his/her desires; and, if these customizations
were saveable, businesses, customers, etc. could easily apply the desired
interface, including the old one, which they would be able to download and
wouldn't have to craft themselves, on all their computers; plus, this would
probably satisfy legal complaints from MS if the ribbon is ever really
patented, because it is a natural extension of toolbars.)
* If this described customizability cannot be reached, work with both the
haters and the likers of the new UI to reach a compromise.
* Be crystal clear when it comes to the UI -- what is definitely going to
stay (menu bar?), what we're not sure about, what will definitely change,
and what has yet to come (more prominent styles?).
* Really look at the good alternatives to the ribbon (especially as there is
a pending patent on it).

2009/8/25 Martin Hanzel <[hidden email]>

> It seems that even more people are against the Prototype UI.
>
> This shouldn't affect us, for two reasons:
> 1. Openoffice is Free Software. The people who work on OOo like us are
> volunteers who do it just for the hell of doing it. I don't see the
> petitioners doing anything on a similar scale, short of complaining. It
> disgusts me.
>
> "The better alternative is to actually become part of that process and add
> own value to it by providing own suggestions for new ideas or providing
> comments to those ideas and suggestions of others in an attempt to
> influence
> the direction into which this process is to be going. Similar just
> complaining about the fact that software does have issues (and all software
> does) does not help much."
>
>
> Hear, hear. Great speaking, Bernd!
>
> 2. We have decided (sort of) that the Prototype UI is NOT the UI that will
> be in the next major version of OOo. Actually, we have barely decided
> anything, at the moment. The petitioners are ignorant. The prototype UI was
> just an idea that someone had, and I give them credit because they took a
> huge chunk out of their time and effort to show the world their opinion in
> a
> little Java application. Likewise, others have their own opinions (I've
> made
> two mockups so far), and I understand some people's natural hostility
> towards these opinions. But to express that hostility in a way that implies
> STOPPING the flow of great ideas (made even worse by the fact that these
> ideas go towards Free Software) is insolence in every way. Petitioners, if
> you don't like it, and have done nothing to fix it, you are free to migrate
> to MS Office any day and rid us of your presence.
>
> If anything, this petition has told us only that we should not lean towards
> a Ribbon-esque UI, like the one in the current prototype, and perhaps
> implement a sidebar. We should'nt discard the great ideas in the forums and
> mailing lists, sidebar or other, because of a handful of people's opinions.
> Don't lose sleep over it.
>
> Sorry for the ramble,
>
> .Martin
>
>
> On Mon, Aug 24, 2009 at 7:03 PM, Andreas Bartel <[hidden email]
> >wrote:
>
> > Hi everyone,
> >
> > unfortunately I would not be able to sleep well seeing this:
> >
> > http://www.petitionspot.com/discussion/view/47163
> >
> > Bernd already posted a pretty nice reply. However, what is going on
> there?
> > Anyone, any idea? What do you think of that?
> >
> > Best,
> > Andreas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
This is a site which donates money to a custom charity when you search
(Google or Yahoo!): http://www.neoaid.com/index.php?referer_id=882
Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] Petition against project Renaissance

Éric Savary
In reply to this post by Andreas Bartel
Hi Andreas!

I couldn't sleep either after reading that.
And gave Bernd my support.
My 2cts.

Sometimes I don't understand *some* of "you"...

Bye
Éric

Andreas Bartel wrote:

> Hi everyone,
>
> unfortunately I would not be able to sleep well seeing this:
>
> http://www.petitionspot.com/discussion/view/47163
>
> Bernd already posted a pretty nice reply. However, what is going on
> there? Anyone, any idea? What do you think of that?
>
> Best,
> Andreas
>
> ---------------------------------------------------------------------
> 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] Petition against project Renaissance

Cor Nouws
Hi guys,

Éric Savary wrote (25-8-2009 4:50)

> I couldn't sleep either after reading that.

Hmm, pls don't forget your sleep :-)

> And gave Bernd my support.
> My 2cts.
>
> Sometimes I don't understand *some* of "you"...

Since this all here is open, there are people with many different
backgrounds and ways of working that can be strange, sometimes
absolutely idiot *for me* , or maybe very inspiring ...
An action as this petition is a really and concrete danger for the
project. So whoever did this, is either mad or just bad.

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]

Reply | Threaded
Open this post in threaded view
|

Re: Petition against project Renaissance

Philip Ganchev
In reply to this post by Martin Hanzel
The petitioners want developers to know that they dislike whatever
they know about the Rennaisance project. Perhaps they have only read
something partial; perhaps they dislike some of the prototypes, or
anything that resembles a ribbon UI.

But *why* do they not like the ribbon or the prototypes? What do they
know about the project? We should ask them these and try to engage
them. This would be more productive for them and for us, because we
would learn something about a subset of our users.

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

Reply | Threaded
Open this post in threaded view
|

Re: Petition against project Renaissance

Christoph Noack-4
Hi Philip!

Am Dienstag, den 25.08.2009, 05:48 -0400 schrieb Philip Ganchev:
>
> But *why* do they not like the ribbon or the prototypes? What do they
> know about the project? We should ask them these and try to engage
> them. This would be more productive for them and for us, because we
> would learn something about a subset of our users.

Sometimes I would like to know, but currently I'm a bit tired... At
least it helps to find some sleep ;-)

If you like, it would be great if you can bring some of this information
to this list. I replied to some of the questions and comments in the
last few days, but I cannot provide any valuable insights.


Christoph


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

Reply | Threaded
Open this post in threaded view
|

Re: Petition against project Renaissance

Olivier R.
Hi everyone,

Christoph Noack a écrit :
> Am Dienstag, den 25.08.2009, 05:48 -0400 schrieb Philip Ganchev:
>> But *why* do they not like the ribbon or the prototypes? [...]
>
> Sometimes I would like to know, [...]
>
> If you like, it would be great if you can bring some of this information
> to this list. I replied to some of the questions and comments in the
> last few days, but I cannot provide any valuable insights.

 From what I read, a lot of people don’t like the ribbons for the
following reasons:

1. It takes too much space, especially for those who have netbooks, but
even people who have big screen usually think it would be smarter to
have a vertical ui, as screens are now very wide and not that much high.

About this point, I wonder why the idea of ribbons/tabs/sections have
not been offered vertically (like in the browser Opera). Something
between Symphony and Opera would look great.

2. It’s not customizable. The interface is graved in stone. It is not
possible to change it.

3. They (or their customers) don’t want to learn to work differently
than they do now. It’s not perfect, but it’s ok, so why take the risk to
change everything?

4. They believe you want to copy Microsoft.


The point 1 is the _main issue_ for a lot of people.

The point 2 is a power-user concern.

The point 4 seems to be the problem of those who teach to other users.
And there will always be people reluctant to change their habits,
whatever you do.

The point 4 is a “free software vs M$” war. Everything from M$ is evil.
Good or bad ideas, it doesn’t matter.


Best regards,
--
Olivier R.

** E-mail dedicated to mailing-lists.                             **
** Messages from anywhere else are _automatically_ erased.        **
== Adresse mail réservée aux listes de discussion.                ==
== Les messages venant d’ailleurs sont _automatiquement_ effacés. ==

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

Reply | Threaded
Open this post in threaded view
|

Sidepanes

Andreas Bartel
Hi folks,

in short, very short, I will finally try to present some problems that  
may arise using vertical tabs/side panes etc. I think it is necessary  
because I feel there is strong preference for that design pattern  
inside our community but lots of pitfalls using it seem to go  
unnoticed. These are pure UX engineering considerations, I am not  
speaking of my own preferences. To be honest, there are apps where I  
consider sidepanes useful for commands but there are also apps that  
cause more terror than benefit using sidepanes e.g. OmniGraggle. So  
overall, neither me nor anyone else from the UX team is opposing or  
promoting that particular design pattern. As the matter of fact, we  
are not religious about any UI design pattern.

First, we never attempted to remove sidepanes completely. Hence, in  
some contexts sidepanes might appear. However, our design strategy is  
to remain horizontal for the access of all commands.

So, here are two objections, your honor ;-)

1. In general, changing from horizontal to vertical tabs/toolbars  
whatsoever is a major modification that also breaks with a lot of  
habits computer users have been gaining in the last 30 years. That is  
a fact. Usually, everyone expects commands to be located at the top of  
the screen. That is similar to entering a room (in a building, on  
earth, in our century) and looking for a window. Where would you look  
or expect a window to be? Certainly the wall would be the first place  
a window might appear. Not the roof, although possible, and certainly  
not the floor.

2. So, since that change would induce as much confusion as any other  
change of such severity, it better should be really beneficial. If it  
does not significantly improve usability by a factor of X that is  
worse going through the pain of relearning, then IT MAKES NO SENSE to  
change that at all. And again, yes, that is the measure we apply for  
all possible solutions, including the prototypes presented so far. So  
let's check one argument that is PRO sidepanes and is often mentioned.

2.1 Better use of screen real estate

--> Is that a problem at all? Is the use of screen real estate a  
problem that makes OOo sometimes harder to use? Will the transition of  
horizontal toolbars to vertical ones help people complete their tasks,  
also tasks that are not done often? We don't see any evidence that a  
vertical UI would help us to solve our main problem more elegantly.  
Namely "How to enable users to find all the necessary commands they  
need to complete a task". If something is buried in a horizontal or in  
a vertical UI, is irrelevant. In addition, in a vertical UI you are  
forced to either use some sort of an "ACCORDION", "TABS or VERTICAL  
TABS" or a mixture of both. Using these controls means that you loose  
a lot of vertical space, depending on the font or icon size and the  
LANGUAGE (how about Finish), that is occupied by the labels of tabs or  
accordion elements. This space will not be available for commands  
anymore. Therefore we would need to use scrolling bars, especially on  
NETBOOKS where vertical space is precious. Try to squeeze 340 commands  
into a sidepane of e.g. 75 x 600 pixels size. Scrolling bars would  
again hide some commands, which brings us back to the current  
problems. Overall, there is a tradeoff between gaining and loosing  
screen real estate that cancels possible improvements. Therefore, no  
obvious significant step forward towards a solution.

I'd really like to present you a pictorial explanation but right now,  
I don't have one. Maybe tomorrow when I get my camera.

--> Most of us who think of a presentation applications, or slides and  
NETBOOKS in particular, also think of 16:9 or 16:10 screen formats.  
But most of us remain with the thought that the SLIDES are 4:3.  
Currently that might be true, which is also a pure ASSUMPTION, but  
that will certainly change rapidly since presenters start to support  
more the formats of laptop and netbook screen ratios. WHAT WILL HAPPEN  
THEN??? Slides that resemble the screen ration on a 16:9 or even 16:10  
screen use MORE screen real estate. That makes a vertical UI less  
efficient concerning screen real estate usage.

--> "Everyone works in full-screen mode". That is a possibility but a  
PURE ASSUMPTION. Having a big wide-screen does not necessarily mean  
that EVERYONE on the planet has the same usage patterns regarding that  
screen. On the contrary, it might often be the case that users work  
with several apps in parallel and reduce the windows of the apps. As  
long as we do not have any evidence, we should not develop for that  
use case SOLELY. Meaning, NO FOCUS on anything that works best in full-
screen only.

--> "Sidepanes work well in Writer" That might be true. However, it is  
not evident for Impress and certainly not for Calc where sheet content  
is the essence of the app. Steeling 3 columns might be a lot worse  
than steeling 3 rows. Again, no evidence here that a sidepane would  
improve usability by a sufficient amount.

In sum, it is very likely that you will not see a vertical toolbar for  
accessing all commands as the main location. However, you might see  
that design patterns for other purposes and in different contexts.  
That really depends on the app and on the task.

I hope this information helps you to understand how we actually make  
decisions and why certain design ideas, although tempting at the  
begging, end up in the bin. If you find such clarifications more  
helpful when posted to the mailings lists then we will be more active  
here than on the blog.

That's it for today. Best!
Andreas

---------------------------------------------------------------------
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] Petition against project Renaissance

Elizabeth Matthis
In reply to this post by Cor Nouws
Hi All,

On 08/25/09 09:03, Cor Nouws wrote:

> Hi guys,
>
> Éric Savary wrote (25-8-2009 4:50)
>
>> I couldn't sleep either after reading that.
>
> Hmm, pls don't forget your sleep :-)
>
>> And gave Bernd my support.
>> My 2cts.
>>
>> Sometimes I don't understand *some* of "you"...
>
> Since this all here is open, there are people with many different
> backgrounds and ways of working that can be strange, sometimes
> absolutely idiot *for me* , or maybe very inspiring ...
> An action as this petition is a really and concrete danger for the
> project. So whoever did this, is either mad or just bad.
>
The words that come to my mind are things like: Spreading "Fear,
Uncertainty and Doubt." Sabotage.
It might not be someone bad, but rather just someone who is insanely
scared or wants to make himself appear important. It *is* scary for some
people to think of change coming and not know what that change will
be.[1]  In this economy a lot of people are scared in general: of losing
their jobs, of losing their status, their homes, their investments, of
getting the swine influenza, of flying in an airplane, etc.

It is not possible in an open project like Renaissance for such people
to be "protected" from knowing about the project before it is concluded.
In other life situations  (in education, for example), anxious people
would be better  presented with a final solution and then accept it in
one sweep---realizing after a brief reorientation that it is okay (for
example: be with a new teacher or in a different classroom) without
spending months getting all nervous, sweating, having heart
palpitations, imagining the worst, etc.[2]

But hey, this is open source. So it's open. I'm sorry for the people who
are scared. But I'm *not* sorry for those of us who are taking part in
the birth of something new, something exciting, something better.
> Ciao - Cor
>
>
Kind regards (from my vacation in America ;-) ),
Liz

[1] I personally have had great experiences with change and even with
uncertain futures, like when I went to Australia as an exchange student
and had absolutely no idea as to what to expect: no knowledge of my host
family or the home I would live in, no knowledge of my future school or
friends, etc. It was the best year of my life!

[2] That is why nurses generally don't let you see the shot or IV
coming, they just suddenly do it and after a very quick "ouch", you feel
better all over and never had time to worry about it in the first place.



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

Reply | Threaded
Open this post in threaded view
|

Re: Sidepanes --- Why don't be honest about it? --- Some real arguments

Johannes Eva
In reply to this post by Andreas Bartel
Hi Andreas and everybody!

thanks Andreas for this answer, I have been waiting for arguments
against sidebars/sidepanes for a while now, to try to understand why the
possibility of a vertical UI is not taken seriously.

To say it immediately, I am not convinced by your arguments, and I will
try to explain why.


> 1. In general, changing from horizontal to vertical tabs/toolbars
> whatsoever is a major modification that also breaks with a lot of
> habits computer users have been gaining in the last 30 years. That is
> a fact. Usually, everyone expects commands to be located at the top
> of the screen. That is similar to entering a room (in a building, on
> earth, in our century) and looking for a window. Where would you look
> or expect a window to be? Certainly the wall would be the first place
> a window might appear. Not the roof, although possible, and certainly
> not the floor.
Remember Myth #9:
http://carsonified.com/blog/design/top-10-ux-myths/
(I don't remember who posted it, but thank you!)

I'll give you another example (excuse my English for this one, I don't
have the specific vocabulary I would need to be more clear).
Here is a picture of my oven, in the kitchen:
http://dl.getdropbox.com/u/173771/CIMG3324.JPG

As with all ovens and cooking plates I have had in my short life (that's
about   a dozen because I move a lot) I remember that I always had the
same "problem": the buttons to switch the cooking plates are not "on"
the working space beside the cooking plate, but under the hangover, on
the vertical side.

So when I have to switch a plate on, I have to bend down to find the
correct button for the correct plate I want to switch on.
If it would be on top, I would see the buttons better, and would not
need to bend down to use them.

To me it is clearly a design mistake, but the majority of ovens I have
seen in my life are like this.
So, two remarks about this:
1. the majority is not always the best design.
2. Do you think I would get used to the buttons place if they would be
"on" the table beside the cooking plates, instead under the hangover?
I think anyone would get used to it very fast.


To go back to the UI Myth #9. I think users can adapt, and that your
argument about "since 30 years" is wrong. For 30 years, we had 4:3
screens, now almost all new displays are 16:9. Things change, but UIs
shoudn't?.

Many people on the mailing list have already given a ton of examples of
UIs with vertical designs or vertical elements, definitely proving that
users are already used to vertical designs. iTunes, or even the standard
menu of gmail to cite only two. These applications don't seem to be a
problem to billions of users. I don't think that OOo users are dumber
than average.

Another argument: in the era of the web, users are used to browse on a
quantity of websites, all of them having different layouts: menu
layouts, organisation, etc. In many cases, the structure is vertical, or
vertical + horizontal. Nowadays, people are used to change, because
that's what they do everyday on the web. If the UI is good and well
tested, let it be horizontal or vertical, people will adapt, really.


One more argument: you insist that for 30 years the menus have been on
top of the screen, and it would be difficult to some users to adapt, and
find elements, for example, on a left vertical sidepane.
Pure supposition, and there is no vertical design planned. But see;
http://carsonified.com/blog/design/top-10-ux-myths/

I tried it. Yesterday night we had guests, so I asked 5 persons, all
musicians and not technically gifted at all, to point on the screen how
they would do following actions in the following mockup:
http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png
- save
- change font, and font size
- center paragraph
- copy and paste

ALL of them found it immediately. And they seemed to be very at ease
with the vertical sidepane. (two of them wondered about the styles at
the bottom, "so here you can change the font, too?")

I admit my testing is quite light, on the same type of basic users and
basic commands. But it is still better that pretending something without
even doing this most basic testing.

As a conclusion, I don't know how you can pretend that people would have
difficulties to adapt to a vertical design, without testing it. And also
continually ignore existing software with vertical UIs.


(By the way, if someone wants to test RedOffice beta 4: I can send the
archive of the beta, for Windows. I don't manage to get and install
newer versions.)


***

> 2. So, since that change would induce as much confusion as any other
> change of such severity, it better should be really beneficial. If it
>  does not significantly improve usability by a factor of X that is
> worse going through the pain of relearning, then IT MAKES NO SENSE to
> change that at all.
Well, I didn't see any publications of testings concerning the actual
prototypes. I really don't know if and how they would be really
beneficial, or more beneficial that a vertical design or some other
features, taking in account that it would probably take 3-5 years of
development.

The most beneficial thing, according to the users themselves, can be
found on slide 30 of this presentation:
http://wiki.services.openoffice.org/w/images/1/11/Renaissance-status-2009-01-30_wiki.odp
I often think, if we would think about the users, well, a lot of the
energy would have to go to a better MSO 07/03 compatibility.

And I don't see in 3.2 the ability to write OOXML, what a disappointment!

I'm sorry, I'm off topic. But I don't have seen any publication of tests
showing that some of the the prototypes would be better for the end
users than the current UI. (Neither that vertical UIs to better or
worse, of course.)
It is really so beneficial that it justifies concentrating that much
resources and energy on it? There are so many things that could be done
in OOo...


> 2.1 Better use of screen real estate
>
> In addition, in a
> vertical UI you are forced to either use some sort of an "ACCORDION",
> "TABS or VERTICAL TABS" or a mixture of both. Using these controls
> means that you loose a lot of vertical space, depending on the font
> or icon size and the LANGUAGE (how about Finish), that is occupied by
> the labels of tabs or accordion elements.
That's only true for some designs.
I'm sorry to use my proposal again as an illustration, but it is not
true in it. Neither it is in Office Mac 2008 or Apple pages. Again, how
can you write your argument ignoring these?

In this kind of design, the language and length of text is not very
important neither:
http://wiki.services.openoffice.org/w/images/5/5d/Mockup_fin22rev.png
(from the proposal by Constantin Bürgi)

And if you take a look at the last proposal by IBM (by the way, great
proposal, great ideas! Better to me than actual Symphony versions!), it
does not loose vertical space neither:
http://wiki.services.openoffice.org/wiki/Sidebar_Proposal_by_IBM

So how come you can affirm that a vertical design has to loose vertical
space in this way?
And again, many designd would work with any "length" of language.


> Therefore we would need to use
> scrolling bars, especially on NETBOOKS where vertical space is
> precious.
Need scrolling bars? Again, you are making curious affirmations, without
argumenting them very well.
The proposal by IBM, as well as mine, don't need vertical scrolling bars
in general. Neither does RedOffice.

With "in general", I mean that the sidepane does not need its own
scrolling bar. Indeed some elements would need one, like the "styles &
formatting" in this mockup:
http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png
(yeah, I know, I use this one a lot, sorry!)

And sorry to say this, but I fond scrolling bars in horizontal UI
elements much more ridiculous. See Office 2007.

 > Try to squeeze 340 commands into a sidepane of e.g. 75 x
> 600 pixels size. Scrolling bars would again hide some commands, which
> brings us back to the current problems. Overall, there is a tradeoff
> between gaining and loosing screen real estate that cancels possible
> improvements. Therefore, no obvious significant step forward towards
> a solution.
First, I am very disappointed, because your arguments show that you did
never really consider the option of a vertical UI. It seems that you are
bringing mostly personal arguments, without a "testing" base.
 > e.g. 75 x 600 pixels size
I know, "e.g."... but at least 200 pixels width are standard.
See:
http://wiki.services.openoffice.org/w/images/c/c3/Martinu_-_Sidebar_Width_in_different_Office_Suites_applications.png

Let's have numbers. In 800x600,
Prototype 0.16 :
800x125= 100000

This mockup:
http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png
207x488= 101016

I have to agree, 800x600 is not a smart choice, but as you can see, the
space for the UI is the same (it may very a little, depending how you
calculate it). And without scrolling bars, of course, why did you get
the idea that these would be needed?

***

Now, is there enough space for commands, even in 600 pixels height, with
a vertical design? Here is the answer:

I would like you to look again at this mockup I made, with a 800x600
pixels resolution. These are about 50 commands on one side pane, many
(22) of them with text+icon.
http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png

Now count how much commands there are on the "start" tab of the 0.16
prototype: about 25, half as much. 11 with text, also half as much.
The "format" tab has the most commands in the 0.16 prototype, and these
are only 27. Note that the text is smaller in the prototypes that in my
mockups.
(I know, it's only a prototype, ...)

One more thing. I have space for 9 "tabs" in my proposal. (with vertical
icon tabs as in the IBM design, there would be space for as many as one
would like.)
If we have the same amount of commands for each tab, about 50, there is
a possibility of 450 commands, many of them with full text.
With 600 pixels height.

I admit that it is the "most optimistic" method to calculate, but
still... you were speaking of 340, my result is that there would be
space for 450, with 600 pixels height.

Conclusion: in any case, even with a less optimistic calculation, there
is enough space in a well made vertical UI. And this, without "eating"
the vertical space of a netbook, as does a "ribbon" design.


To conclude this point, I was really disappointed to see that you insist
on saying that there would be not enough space in a vertical UI, without
really trying it.


> --> Most of us who think of a presentation applications, or slides
> and NETBOOKS in particular, also think of 16:9 or 16:10 screen
> formats. But most of us remain with the thought that the SLIDES are
> 4:3. Currently that might be true, which is also a pure ASSUMPTION,
> but that will certainly change rapidly since presenters start to
> support more the formats of laptop and netbook screen ratios. WHAT
> WILL HAPPEN THEN??? Slides that resemble the screen ration on a 16:9
> or even 16:10 screen use MORE screen real estate. That makes a
> vertical UI less efficient concerning screen real estate usage.
Once again, you are saying something very strongly, but didn't tried it
out...
I was almost about to say "I didn't think about this" and "you're
right", but then I tried it out. And here is a mockup:
http://dl.getdropbox.com/u/173771/Martinu%20-%20General%20Mockup%2011%20-%20Writer%20in%201366x768%20-%20NEW%20MOCKUP%20WITH%2016%209%20slides.png
(with a 16:9 slide on a 16:9 screen)

In fact, it works very well, even with 2 sidebars, as in the mockup!
(The other solution, with one sidebar only, and the slides overview on
the bottom, has even more space for 16:9 slides.)

Conclusion: the argument of the 16:9 slides invalidating the usefulness
of a vertical UI is not valid, sorry.


> --> "Everyone works in full-screen mode". That is a possibility but a
>  PURE ASSUMPTION. Having a big wide-screen does not necessarily mean
> that EVERYONE on the planet has the same usage patterns regarding
> that screen. On the contrary, it might often be the case that users
> work with several apps in parallel and reduce the windows of the
> apps. As long as we do not have any evidence, we should not develop
> for that use case SOLELY. Meaning, NO FOCUS on anything that works
> best in full-screen only.
It would also be pure assumption to imagine that people maximize the
windows vertically, thus making the waste of vertical space in a
"ribbon" UI even worse. This is not specially an argument against
vertical UIs.

As you could see in my mockups, but also in those of the IBM proposal, a
vertical UI really works well also in small resolutions.
And don't forget that most users use Word, with a "portrait" page.
(I don't say all do, but most of them.)


> --> "Sidepanes work well in Writer" That might be true. However, it
> is not evident for Impress and certainly not for Calc where sheet
> content is the essence of the app. Steeling 3 columns might be a lot
> worse than steeling 3 rows.
Well, I already posted my mockup of Impress with 2 sidepanes.
I already posted a message about the Calc argument.
So here it is again: your argument about rows being more important than
columns works well in 4:3 resolutions, but again, doesn't apply in 16:9.
Here is a screenshot of Calc in 1920x1080. I pasted a random sidebar to
have an idea of the relative width.
/media/Kakemphaton/Johannes/Dropbox/Dropbox/Public/OOo_calc_1920x1080.png

Do you REALLY think that the lost space due to the sidepane is still
relevant in 16:9 resolutions?

***


A last small thing: the marvelous thing about the ribbons in Office 2007
is how they scale to the size of the window. There are many dynamic
elements that adapt their size. I don't see this in the prototypes - yes
I know, these are only prototypes.

Once more, I find a vertical UI very suited for these kind of
auto-scaling elements. Take for example this mockup, which I'm really
sorry to link here for the 10000th time!
http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png

Well, the "styles and formatting" element at the bottom would scale to
all resolutions, displaying more or less lines.
I miss this in the prototypes, the "ribbon" style UI makes no sense
without this scalability.


Note that the current toolbars in 3.x could be made scalable also,
playing with the text labels, as described here:
http://wiki.services.openoffice.org/wiki/Proposal_by_Johannes_Eva#14.1_More_about_toolbars


***


> So overall, neither me nor
> anyone else from the UX team is opposing or promoting that particular
> design pattern. As the matter of fact, we are not religious about any UI
> design pattern.
>
> First, we never attempted to remove sidepanes completely. Hence, in some
> contexts sidepanes might appear. However, our design strategy is to
> remain horizontal for the access of all commands.

> In sum, it is very likely that you will not see a vertical toolbar for
> accessing all commands as the main location. However, you might see that
> design patterns for other purposes and in different contexts. That
> really depends on the app and on the task.

Honestly, I am just chocked by this overall hypocrisy. Really. First say
things like "we are not religious about any design pattern" or "the
prototypes are only prototypes", or "we don't need prototypes of
vertical UIs, we have Symphony", and pretending being open.

And then, it was the feeling I and some other people had, thank you for
saying it out loud, already having chosen that the design won't be vertical.

Without having tested it seriously.

Despite a lot of people, not only me, speaking in favor of vertical UIs.
I would say, despite of the modern monitor format speaking for vertical
UIs.

I mean, did you really read more than 10 comments from the last GullFOSS
blog posts, what they say? Not all are rude and dumb, many smart people
out there. A lot of them for vertical UIs.

And then, you post some unverified arguments and explanations telling
why you have already chosen that the UI would be not vertical.
Where are the real usability studies?

"Create a User Interface so that OpenOffice.org becomes *the users'
choice* not only out of need, but also out of desire."
I don't believe in it anymore. Saying "we are open", and then not be
really open, but stuck in old ideas and designs, despite of the public
opinion being that brutal against it: that's not being open.



***

I know my words are harsh, and I'm sorry about it. And I'm sorry
speaking only to you, Andreas, I don't know which other persons are
behind what is for me a "hypocrisy".

And I also know that you, the team behind OOo, don't have the resources
you would need and you deserve to do it as well as it should be done.
I'm sorry for it.

But this is a reason more for not putting OOo in danger, sucking a lot
of its resources in a project that should not be, at least to me, the
main priority, and that would last many many years, and that started so
baldy, at least in the public opinion.

Are you aware that if Renaissance fails, this could be the death of OOo
as a sucessful project? I take so much time to write about this, because
I am really worried about all this.

All the best, really, to you and OOo,
Johannes








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

Reply | Threaded
Open this post in threaded view
|

Re: Sidepanes --- Why don't be honest about it? --- Some real arguments

Andreas Bartel
Hi Johannes,

finally, someone! Thank you!

So, let's see what we have here. I will try to address all points today.

Johannes Eva schrieb:
> Hi Andreas and everybody!
>
> thanks Andreas for this answer, I have been waiting for arguments
> against sidebars/sidepanes for a while now, to try to understand why
> the possibility of a vertical UI is not taken seriously.
>
> To say it immediately, I am not convinced by your arguments, and I
> will try to explain why.
Thank god! Otherwise we would not be having this discussion ;-)

>
>
>
>> 1. In general, changing from horizontal to vertical tabs/toolbars
>> whatsoever is a major modification that also breaks with a lot of
>> habits computer users have been gaining in the last 30 years. That is
>> a fact. Usually, everyone expects commands to be located at the top
>> of the screen. That is similar to entering a room (in a building, on
>> earth, in our century) and looking for a window. Where would you look
>> or expect a window to be? Certainly the wall would be the first place
>> a window might appear. Not the roof, although possible, and certainly
>> not the floor.
> Remember Myth #9:
> http://carsonified.com/blog/design/top-10-ux-myths/
> (I don't remember who posted it, but thank you!)
>
> I'll give you another example (excuse my English for this one, I don't
> have the specific vocabulary I would need to be more clear).
> Here is a picture of my oven, in the kitchen:
> http://dl.getdropbox.com/u/173771/CIMG3324.JPG
>
> As with all ovens and cooking plates I have had in my short life
> (that's about   a dozen because I move a lot) I remember that I always
> had the same "problem": the buttons to switch the cooking plates are
> not "on" the working space beside the cooking plate, but under the
> hangover, on the vertical side.
>
> So when I have to switch a plate on, I have to bend down to find the
> correct button for the correct plate I want to switch on.
> If it would be on top, I would see the buttons better, and would not
> need to bend down to use them.
>
> To me it is clearly a design mistake, but the majority of ovens I have
> seen in my life are like this.
> So, two remarks about this:
> 1. the majority is not always the best design.
> 2. Do you think I would get used to the buttons place if they would be
> "on" the table beside the cooking plates, instead under the hangover?
> I think anyone would get used to it very fast.
>
>
> To go back to the UI Myth #9. I think users can adapt, and that your
> argument about "since 30 years" is wrong. For 30 years, we had 4:3
> screens, now almost all new displays are 16:9. Things change, but UIs
> shoudn't?.
Your way of understanding my argument and probably the way I stated it,
leads to disagreement where there is none! Where exactly did you read
that I have the oppinion that people don't change? Sorry for that but
you are certainly wrong here in your perception of my argument. If I
would not believe that user's are capable of change or are not capable
of learning and adapting to new information, I would certainly not be a
UX engineer. Or at least I should not be one ;-)

People change, users change etc. I could go on here to the level of
brain plasticity but that is not the point. The point is that if we
induce a major change in the UI by transforming something from
horizontal to vertical, hence by just moving something from A to B, IT
JUST HAS TO BE WORTH GOING THROUGH THE PAIN OF ADAPTATION. Overall, this
would require same learning processes to start working as in the changes
present in the current prototype or in the UI transition fron MSO 2003
to MSO 2007.

So, let's summarize insights:

1. Tranferring the location where users can access commands from
horizontal to vertical, hence from toolbars to a sidepane, is a major
change.
2. Users can adapt to that change.
3.1 Adaptation always involves some sort of individual change or "pain"
that is perceived in many ways by all kinds of users (see blog comments
;-) )
3.2 Some users like change and other clearly DON'T
4. The reward going through the pain of adaptation must be higher than
the threshold of not willing to adapt

Now back to you. I'd like you or anyone else to consider the following
questions:

1. What are the current problems of the overall UI in OOo with all it's
constituents?
1.1 Do these problems apply to all users?
1.2 Do these problems occur in all contexts?

2. Is the growing number of 16:9 or 16:10 screens a current issue for OOo?
2.1 Does the current UI lead to significant usability problems with
these types of screens?
2.2 Is a vertically aligned pane a solution?
2.3 If so, then to which particular problem is that the solution?
2.4 If so, does a vertical pane work equally well in all applications?
2.4 Is that the best solution we can think of?
2.5 What might become more hard to use as a side effect?

3. Are the users willing to accept the change?
3.1 What do we offer that is so valuable that users are willing to go
through the pain of adaptation?
3.2 Do all users adapt to the change equally well?

Suddenly, this matter becomes more complex, right? As all other UI
issues when considered more closely. However, these are just a few
"things to think with" when talking about changes. No negative feelings
attached. But currently, in our context, and to our project, what
probably matters most are these two questions: "WHAT MAJOR PROBLEMS
WOULD A VERTICAL PANE SOLVE NOW?" and "HOW WOULD THAT CHANGE AFFECT THE
MAJORITY OF OUR USERS?"
>
> Many people on the mailing list have already given a ton of examples
> of UIs with vertical designs or vertical elements, definitely proving
> that users are already used to vertical designs. iTunes, or even the
> standard menu of gmail to cite only two. These applications don't seem
> to be a problem to billions of users. I don't think that OOo users are
> dumber than average.
Come on, there is no need to exaggerate things. Noone has ever been
talking here about the intelligence level of our user. But you are
right, many have proposed immidiate solutions without describing well
which problem they actually address.

>
> Another argument: in the era of the web, users are used to browse on a
> quantity of websites, all of them having different layouts: menu
> layouts, organisation, etc. In many cases, the structure is vertical,
> or vertical + horizontal. Nowadays, people are used to change, because
> that's what they do everyday on the web. If the UI is good and well
> tested, let it be horizontal or vertical, people will adapt, really.
>
>
> One more argument: you insist that for 30 years the menus have been on
> top of the screen, and it would be difficult to some users to adapt,
> and find elements, for example, on a left vertical sidepane.
> Pure supposition, and there is no vertical design planned. But see;
> http://carsonified.com/blog/design/top-10-ux-myths/
I think that you underestimate the importance and the impact of CONTEXT.
Web is not desktop, office productivity is not prefessional graphics
tools etc. Each context activates behavior (usage) petterns that fit
that particular context. These patterns were shaped by a learning
process and are stored as prior knowledge which is istantly activated,
when certain perceptual cues appear, in order to trigger appropriate
behavior. Humans are pattern matchers, constantly trying to apply things
they've already learned in a given situation/context. Hence, a lot of
user/usage "behavior" that is appropriate for the web might not be
appropriate for the desktop (e.g. one click vs. double click on the
mouse as a pure example). Consequently, these issues are pretty hard to
assess. That is the reason why we always should keep in mind that
transferring things that work in one context to another one is a tricky
business. (NOT SAYING THAT IT IS NOT POSSIBLE AT ALL)

>
> I tried it. Yesterday night we had guests, so I asked 5 persons, all
> musicians and not technically gifted at all, to point on the screen
> how they would do following actions in the following mockup:
> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>
> - save
> - change font, and font size
> - center paragraph
> - copy and paste
>
> ALL of them found it immediately. And they seemed to be very at ease
> with the vertical sidepane. (two of them wondered about the styles at
> the bottom, "so here you can change the font, too?")
AGAIN, it's not about IF they can achieve the same things that they
already could before but it's about how much QUICKER, EASIER, ETC they
can do it.
>
> I admit my testing is quite light, on the same type of basic users and
> basic commands. But it is still better that pretending something
> without even doing this most basic testing.
>
> As a conclusion, I don't know how you can pretend that people would
> have difficulties to adapt to a vertical design, without testing it.
> And also continually ignore existing software with vertical UIs.
OK, given that you have a limited insight and understanding of how the
UX team works (maybe our fault), what skills are present and how we make
decisions, you might get the impression that we do not consider obvious
solutions cerefully enough. However, accusing us of "pretending and
ignorring" is certainly baseless.


As my conclusion, thanks for the feedback!

Best,
Andreas

>
>
> (By the way, if someone wants to test RedOffice beta 4: I can send the
> archive of the beta, for Windows. I don't manage to get and install
> newer versions.)
>
>
> ***
>
>> 2. So, since that change would induce as much confusion as any other
>> change of such severity, it better should be really beneficial. If it
>>  does not significantly improve usability by a factor of X that is
>> worse going through the pain of relearning, then IT MAKES NO SENSE to
>> change that at all.
> Well, I didn't see any publications of testings concerning the actual
> prototypes. I really don't know if and how they would be really
> beneficial, or more beneficial that a vertical design or some other
> features, taking in account that it would probably take 3-5 years of
> development.
>
> The most beneficial thing, according to the users themselves, can be
> found on slide 30 of this presentation:
> http://wiki.services.openoffice.org/w/images/1/11/Renaissance-status-2009-01-30_wiki.odp 
>
> I often think, if we would think about the users, well, a lot of the
> energy would have to go to a better MSO 07/03 compatibility.
>
> And I don't see in 3.2 the ability to write OOXML, what a disappointment!
>
> I'm sorry, I'm off topic. But I don't have seen any publication of
> tests showing that some of the the prototypes would be better for the
> end users than the current UI. (Neither that vertical UIs to better or
> worse, of course.)
> It is really so beneficial that it justifies concentrating that much
> resources and energy on it? There are so many things that could be
> done in OOo...
>
>
>> 2.1 Better use of screen real estate
>>
>> In addition, in a
>> vertical UI you are forced to either use some sort of an "ACCORDION",
>> "TABS or VERTICAL TABS" or a mixture of both. Using these controls
>> means that you loose a lot of vertical space, depending on the font
>> or icon size and the LANGUAGE (how about Finish), that is occupied by
>> the labels of tabs or accordion elements.
> That's only true for some designs.
> I'm sorry to use my proposal again as an illustration, but it is not
> true in it. Neither it is in Office Mac 2008 or Apple pages. Again,
> how can you write your argument ignoring these?
>
> In this kind of design, the language and length of text is not very
> important neither:
> http://wiki.services.openoffice.org/w/images/5/5d/Mockup_fin22rev.png
> (from the proposal by Constantin Bürgi)
>
> And if you take a look at the last proposal by IBM (by the way, great
> proposal, great ideas! Better to me than actual Symphony versions!),
> it does not loose vertical space neither:
> http://wiki.services.openoffice.org/wiki/Sidebar_Proposal_by_IBM
>
> So how come you can affirm that a vertical design has to loose
> vertical space in this way?
> And again, many designd would work with any "length" of language.
>
>
>> Therefore we would need to use
>> scrolling bars, especially on NETBOOKS where vertical space is
>> precious.
> Need scrolling bars? Again, you are making curious affirmations,
> without argumenting them very well.
> The proposal by IBM, as well as mine, don't need vertical scrolling
> bars in general. Neither does RedOffice.
>
> With "in general", I mean that the sidepane does not need its own
> scrolling bar. Indeed some elements would need one, like the "styles &
> formatting" in this mockup:
> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>
> (yeah, I know, I use this one a lot, sorry!)
>
> And sorry to say this, but I fond scrolling bars in horizontal UI
> elements much more ridiculous. See Office 2007.
>
> > Try to squeeze 340 commands into a sidepane of e.g. 75 x
>> 600 pixels size. Scrolling bars would again hide some commands, which
>> brings us back to the current problems. Overall, there is a tradeoff
>> between gaining and loosing screen real estate that cancels possible
>> improvements. Therefore, no obvious significant step forward towards
>> a solution.
> First, I am very disappointed, because your arguments show that you
> did never really consider the option of a vertical UI. It seems that
> you are bringing mostly personal arguments, without a "testing" base.
> > e.g. 75 x 600 pixels size
> I know, "e.g."... but at least 200 pixels width are standard.
> See:
> http://wiki.services.openoffice.org/w/images/c/c3/Martinu_-_Sidebar_Width_in_different_Office_Suites_applications.png 
>
>
> Let's have numbers. In 800x600,
> Prototype 0.16 :
> 800x125= 100000
>
> This mockup:
> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
>
> 207x488= 101016
>
> I have to agree, 800x600 is not a smart choice, but as you can see,
> the space for the UI is the same (it may very a little, depending how
> you calculate it). And without scrolling bars, of course, why did you
> get the idea that these would be needed?
>
> ***
>
> Now, is there enough space for commands, even in 600 pixels height,
> with a vertical design? Here is the answer:
>
> I would like you to look again at this mockup I made, with a 800x600
> pixels resolution. These are about 50 commands on one side pane, many
> (22) of them with text+icon.
> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
>
>
> Now count how much commands there are on the "start" tab of the 0.16
> prototype: about 25, half as much. 11 with text, also half as much.
> The "format" tab has the most commands in the 0.16 prototype, and
> these are only 27. Note that the text is smaller in the prototypes
> that in my mockups.
> (I know, it's only a prototype, ...)
>
> One more thing. I have space for 9 "tabs" in my proposal. (with
> vertical icon tabs as in the IBM design, there would be space for as
> many as one would like.)
> If we have the same amount of commands for each tab, about 50, there
> is a possibility of 450 commands, many of them with full text.
> With 600 pixels height.
>
> I admit that it is the "most optimistic" method to calculate, but
> still... you were speaking of 340, my result is that there would be
> space for 450, with 600 pixels height.
>
> Conclusion: in any case, even with a less optimistic calculation,
> there is enough space in a well made vertical UI. And this, without
> "eating" the vertical space of a netbook, as does a "ribbon" design.
>
>
> To conclude this point, I was really disappointed to see that you
> insist on saying that there would be not enough space in a vertical
> UI, without really trying it.
>
>
>> --> Most of us who think of a presentation applications, or slides
>> and NETBOOKS in particular, also think of 16:9 or 16:10 screen
>> formats. But most of us remain with the thought that the SLIDES are
>> 4:3. Currently that might be true, which is also a pure ASSUMPTION,
>> but that will certainly change rapidly since presenters start to
>> support more the formats of laptop and netbook screen ratios. WHAT
>> WILL HAPPEN THEN??? Slides that resemble the screen ration on a 16:9
>> or even 16:10 screen use MORE screen real estate. That makes a
>> vertical UI less efficient concerning screen real estate usage.
> Once again, you are saying something very strongly, but didn't tried
> it out...
> I was almost about to say "I didn't think about this" and "you're
> right", but then I tried it out. And here is a mockup:
> http://dl.getdropbox.com/u/173771/Martinu%20-%20General%20Mockup%2011%20-%20Writer%20in%201366x768%20-%20NEW%20MOCKUP%20WITH%2016%209%20slides.png 
>
> (with a 16:9 slide on a 16:9 screen)
>
> In fact, it works very well, even with 2 sidebars, as in the mockup!
> (The other solution, with one sidebar only, and the slides overview on
> the bottom, has even more space for 16:9 slides.)
>
> Conclusion: the argument of the 16:9 slides invalidating the
> usefulness of a vertical UI is not valid, sorry.
>
>
>> --> "Everyone works in full-screen mode". That is a possibility but a
>>  PURE ASSUMPTION. Having a big wide-screen does not necessarily mean
>> that EVERYONE on the planet has the same usage patterns regarding
>> that screen. On the contrary, it might often be the case that users
>> work with several apps in parallel and reduce the windows of the
>> apps. As long as we do not have any evidence, we should not develop
>> for that use case SOLELY. Meaning, NO FOCUS on anything that works
>> best in full-screen only.
> It would also be pure assumption to imagine that people maximize the
> windows vertically, thus making the waste of vertical space in a
> "ribbon" UI even worse. This is not specially an argument against
> vertical UIs.
>
> As you could see in my mockups, but also in those of the IBM proposal,
> a vertical UI really works well also in small resolutions.
> And don't forget that most users use Word, with a "portrait" page.
> (I don't say all do, but most of them.)
>
>
>> --> "Sidepanes work well in Writer" That might be true. However, it
>> is not evident for Impress and certainly not for Calc where sheet
>> content is the essence of the app. Steeling 3 columns might be a lot
>> worse than steeling 3 rows.
> Well, I already posted my mockup of Impress with 2 sidepanes.
> I already posted a message about the Calc argument.
> So here it is again: your argument about rows being more important
> than columns works well in 4:3 resolutions, but again, doesn't apply
> in 16:9.
> Here is a screenshot of Calc in 1920x1080. I pasted a random sidebar
> to have an idea of the relative width.
> /media/Kakemphaton/Johannes/Dropbox/Dropbox/Public/OOo_calc_1920x1080.png
>
> Do you REALLY think that the lost space due to the sidepane is still
> relevant in 16:9 resolutions?
>
> ***
>
>
> A last small thing: the marvelous thing about the ribbons in Office
> 2007 is how they scale to the size of the window. There are many
> dynamic elements that adapt their size. I don't see this in the
> prototypes - yes I know, these are only prototypes.
>
> Once more, I find a vertical UI very suited for these kind of
> auto-scaling elements. Take for example this mockup, which I'm really
> sorry to link here for the 10000th time!
> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>
>
> Well, the "styles and formatting" element at the bottom would scale to
> all resolutions, displaying more or less lines.
> I miss this in the prototypes, the "ribbon" style UI makes no sense
> without this scalability.
>
>
> Note that the current toolbars in 3.x could be made scalable also,
> playing with the text labels, as described here:
> http://wiki.services.openoffice.org/wiki/Proposal_by_Johannes_Eva#14.1_More_about_toolbars 
>
>
>
> ***
>
>
>> So overall, neither me nor anyone else from the UX team is opposing
>> or promoting that particular design pattern. As the matter of fact,
>> we are not religious about any UI design pattern.
>>
>> First, we never attempted to remove sidepanes completely. Hence, in
>> some contexts sidepanes might appear. However, our design strategy is
>> to remain horizontal for the access of all commands.
>
>> In sum, it is very likely that you will not see a vertical toolbar
>> for accessing all commands as the main location. However, you might
>> see that design patterns for other purposes and in different
>> contexts. That really depends on the app and on the task.
>
> Honestly, I am just chocked by this overall hypocrisy. Really. First
> say things like "we are not religious about any design pattern" or
> "the prototypes are only prototypes", or "we don't need prototypes of
> vertical UIs, we have Symphony", and pretending being open.
>
> And then, it was the feeling I and some other people had, thank you
> for saying it out loud, already having chosen that the design won't be
> vertical.
>
> Without having tested it seriously.
>
> Despite a lot of people, not only me, speaking in favor of vertical
> UIs. I would say, despite of the modern monitor format speaking for
> vertical UIs.
>
> I mean, did you really read more than 10 comments from the last
> GullFOSS blog posts, what they say? Not all are rude and dumb, many
> smart people out there. A lot of them for vertical UIs.
>
> And then, you post some unverified arguments and explanations telling
> why you have already chosen that the UI would be not vertical.
> Where are the real usability studies?
>
> "Create a User Interface so that OpenOffice.org becomes *the users'
> choice* not only out of need, but also out of desire."
> I don't believe in it anymore. Saying "we are open", and then not be
> really open, but stuck in old ideas and designs, despite of the public
> opinion being that brutal against it: that's not being open.
>
>
>
> ***
>
> I know my words are harsh, and I'm sorry about it. And I'm sorry
> speaking only to you, Andreas, I don't know which other persons are
> behind what is for me a "hypocrisy".
>
> And I also know that you, the team behind OOo, don't have the
> resources you would need and you deserve to do it as well as it should
> be done. I'm sorry for it.
>
> But this is a reason more for not putting OOo in danger, sucking a lot
> of its resources in a project that should not be, at least to me, the
> main priority, and that would last many many years, and that started
> so baldy, at least in the public opinion.
>
> Are you aware that if Renaissance fails, this could be the death of
> OOo as a sucessful project? I take so much time to write about this,
> because I am really worried about all this.
>
> All the best, really, to you and OOo,
> Johannes
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: [ux-discuss] Re: [ux-user interface] Sidepanes --- Why don't be honest about it? --- Some real arguments

Brian Fleeger
In reply to this post by Johannes Eva
Andreas Bartel wrote (in response to Johannes Eva):
<Hi Johannes,
<finally, someone! Thank you!
[snip...]
<People change, users change etc. I could go on here to the level of
<brain plasticity but that is not the point. The point is that if we
<induce a major change in the UI by transforming something from
<horizontal to vertical, hence by just moving something from A to B, IT
<JUST HAS TO BE WORTH GOING THROUGH THE PAIN OF ADAPTATION. Overall, this
<would require same learning processes to start working as in the changes
<present in the current prototype or in the UI transition fron MSO 2003
<to MSO 2007.
<So, let's summarize insights:
<1. Tranferring the location where users can access commands from
<horizontal to vertical, hence from toolbars to a sidepane, is a major
<change.
<2. Users can adapt to that change.
<3.1 Adaptation always involves some sort of individual change or "pain"
<that is perceived in many ways by all kinds of users (see blog comments
<;-) )
<3.2 Some users like change and other clearly DON'T

Really an excellent point about people hating change, especially in
reference to the suggested changes to OO.o itself.  However, I would
argue that the comments in retaliation against the Java mockups were not based on resistance to change per se.  Reading
the comments, even those critics who called for a halt to all UI work
did so mostly out of resentment of OO.o's imitation (real or perceived)
of Microsoft Office.  This means that this particular example is less
about resisting change and more about OO.o's market and brand
identity.

<4. The reward going through the pain of adaptation must be higher than
<the threshold of not willing to adapt
<Now back to you. I'd like you or anyone else to consider the following
<questions:
<1. What are the current problems of the overall UI in OOo with all it's
<constituents?

You mentioned OO.o's constituents, and therein lies some of the reason for the backlash -- who are OO.o's current constituents, and who does OO.o want to be its future constituents.  Its current constituents consist largely of technically savvy people who have chosen for either ideological or cost motivated reasons to use a free alternative to MS Office.  In the future, OO.o wants to expand its base, which by definition means that the ratio of ideologically motivated users will drop.  Therefore, OO.o needs to be pragmatic in how it caters to the next generation of users (this is my assessment of the reasoning anyway).

I feel that a number of current users held high hopes when Project Renaissance was first announced that it would come up with a truly novel and superior UI, leapfrogging the competition.  When they saw the mockups, it was a shock on an emotional level, and probably threatened a lot of people's identities (as OO.o users, who specifically chose NOT to use Microsoft office).  But, I do acknowledge that OO.o is seeking to expand to a new constituency with Project Renaissance, moving beyond its base.  

I can understand the desire of the UX team to conform to the norms and conventions of design as defined by the dominant market holder -- that is why most hollywood movies tend to look similar and have similar plots, and more and more coffee shops look like Starbucks.  But people also have to understand that by conforming too closely to established conventions (especially as defined by a highly controversial monopoly company), that is by-definition reducing diversity.  People can argue that OO.o has always been a copy of Office, but a lot of people actually dreamed it would evolve into something better.  So now, people are upset and angry for the same reason that there was rioting at the WTO conference in 1999, or that people sneer when they see a McDonalds in Beirut.  In some weird way, OO.o is engaged in a conflict not unlike the backlash against globalization.  Its current users (or at least a very vocal portion) just really don't want to see their
 desktop experience too homogenized.  

But to answer your question about constituents more directly, the problem with the UI currently is clearly the same problem that Microsoft had with Office2003 and prior editions, ie hard to find functions burried in menus, and unintuitive UI in general.  Further, the top-mounted horizontal mid-fidelity mockups do address many of these issues, just as Microsoft did with Office 2007.  But there are also unaddressed UI deficiencies in the current Office 2007 and 2010 layouts, and I don't think I need to repeat the arguments about saving space by using a vertical bar, or wasted space using horizontal on widescreens.  Again, I just want to reiterate, people are expecting more than imitation from OO.o.  Even though all cars have four wheels and an engine, I think there is more room for alternative UIs than what has been presented so far.  Really, its a compliment, because to a lot of people OO.o is like some kind of lofty dream of a post-monopolized world.

<1.1 Do these problems apply to all users?

Widescreens, yada yada... ;-)

<1.2 Do these problems occur in all contexts?
<2. Is the growing number of 16:9 or 16:10 screens a current issue for OOo?
<2.1 Does the current UI lead to significant usability problems with
<these types of screens?

Yup, sure do

<2.2 Is a vertically aligned pane a solution?

Yup

<2.3 If so, then to which particular problem is that the solution?
<2.4 If so, does a vertical pane work equally well in all applications?

This is a little bit of a trick question.  If the vertical plane is sub-optimal in some applications, cannot the same be said for the horizontal plane?  Anyway, in my view they are as follows:
Writer -- would very much benefit from a vertical plane.  Just look at Johannes's mockups to see how much more room there is.
Impress -- Neutral.  Even when using a 16:9 slide layout, the preview column can be flipped on its side and laid on the bottom, also as shown in Johannes' drawings.
Calc -- Depends on usage data to which I do not have, ie are people using columns or rows more in Calc.  Personally, I use more rows (long long lists) so a vertical layout would be idea.  Other times, like when I do cost benefit projects or other cost models, I might need more columns.  But in my personal usage, I tend to go straight down more than sideways.  

<2.4 Is that the best solution we can think of?
<2.5 What might become more hard to use as a side effect?

As above, Calc *may* suffer, but it depends on implementation.  For instance, in RedOffice 4, the side panel can be undocked and made into one big block of a floating panel, as well as redocked on either side.  A similar solution could mitigate these negative effects in a side panel for OO.o.

<3. Are the users willing to accept the change?

This question is impossible to answer if there is no mid-fidelity mockup for users to try and which could collect measurable usage data.  

<3.1 What do we offer that is so valuable that users are willing to go
<through the pain of adaptation?

Potentially, in that other than the advantages others have outlined regarding space, a side panel would also provide differentiation and greater brand identity.  But does OO.o want its own brand identity, or is OO.o itself just a trojan horse in the larger chess game of corporate developers to get people to reduce their dependency on the Windows ecosystem?  I can't resist a little conspiracy theory every now and then! (I kid!!  I am OS agnostic) ;-)

<3.2 Do all users adapt to the change equally well?

Trick question again.  All users do not adapt equally well, but the bigger question is to what *degree* different users adapt to change.  And without a prototype which could collect real, quantitative data, any answer to this question would be mere conjecture.

<But currently, in our context, and to our project, what
<probably matters most are these two questions: "WHAT MAJOR PROBLEMS
<WOULD A VERTICAL PANE SOLVE NOW?" and "HOW WOULD
<THAT CHANGE AFFECT THE MAJORITY OF OUR USERS?"
<[snip...] I think that you underestimate the importance and the impact of CONTEXT.
<Web is not desktop, office productivity is not prefessional graphics
<tools etc. Each context activates behavior (usage) petterns that fit
<that particular context. These patterns were shaped by a learning
<process and are stored as prior knowledge which is istantly activated,
<when certain perceptual cues appear, in order to trigger appropriate
<behavior. Humans are pattern matchers, constantly trying to apply things
<they've already learned in a given situation/context. Hence, a lot of
<user/usage "behavior" that is appropriate for the web might not be
<appropriate for the desktop (e.g. one click vs. double click on the
<mouse as a pure example). Consequently, these issues are pretty hard to
<assess. That is the reason why we always should keep in mind that
<transferring things that work in one context to another one is a tricky
<business. (NOT SAYING THAT IT IS NOT POSSIBLE AT ALL)

When you speak of contexts, and of the importance of conforming to current desktop usage patterns, you more or less preclud the possibility of EVER making any user interface which is different in any significant way  from Microsoft standards.  Not to offend, but that is the logical conclusion of your argument as I understand it.  As the monopoly holder, they will always define people's "desktop contexts."  But it is also important to remember that the desktop context that the current mockups are seeking to emulate is itself a relatively new cognitive mode.  That is, people's brains are still malleable having been forced to adapt from Office 2003 to Office 2007, so will likely be more likely to adapt more quickly to other new interface models -- should OO.o have the courage to present them and stand on its own two legs.

<[snip...] OK, given that you have a limited insight and understanding of how the
<UX team works (maybe our fault), what skills are present and how we make
<decisions, you might get the impression that we do not consider obvious
<solutions cerefully enough.

I am also not a UI professional, other UI professionals (namely, from IBM) have concluded that a vertical panel is highly desirable, and that by itself, apart from all the arguments presented here, makes it worthy of greater consideration.  

Anyway, great read and I like this thread!

Regards,
Brian

<As my conclusion, thanks for the feedback!
<Best,
<Andreas
>


>
> (By the way, if someone wants to test RedOffice beta 4: I can send the archive of the beta, for Windows. I don't manage to get and install newer versions.)
>
>
> ***
>
>> 2. So, since that change would induce as much confusion as any other change of such severity, it better should be really beneficial. If it
>>  does not significantly improve usability by a factor of X that is
>> worse going through the pain of relearning, then IT MAKES NO SENSE to
>> change that at all.
> Well, I didn't see any publications of testings concerning the actual prototypes. I really don't know if and how they would be really beneficial, or more beneficial that a vertical design or some other features, taking in account that it would probably take 3-5 years of development.
>
> The most beneficial thing, according to the users themselves, can be found on slide 30 of this presentation:
> http://wiki.services.openoffice.org/w/images/1/11/Renaissance-status-2009-01-30_wiki.odp 
> I often think, if we would think about the users, well, a lot of the energy would have to go to a better MSO 07/03 compatibility.
>
> And I don't see in 3.2 the ability to write OOXML, what a disappointment!
>
> I'm sorry, I'm off topic. But I don't have seen any publication of tests showing that some of the the prototypes would be better for the end users than the current UI. (Neither that vertical UIs to better or worse, of course.)
> It is really so beneficial that it justifies concentrating that much resources and energy on it? There are so many things that could be done in OOo...
>
>
>> 2.1 Better use of screen real estate
>>
>> In addition, in a
>> vertical UI you are forced to either use some sort of an "ACCORDION",
>> "TABS or VERTICAL TABS" or a mixture of both. Using these controls
>> means that you loose a lot of vertical space, depending on the font
>> or icon size and the LANGUAGE (how about Finish), that is occupied by
>> the labels of tabs or accordion elements.
> That's only true for some designs.
> I'm sorry to use my proposal again as an illustration, but it is not true in it. Neither it is in Office Mac 2008 or Apple pages. Again, how can you write your argument ignoring these?
>
> In this kind of design, the language and length of text is not very important neither:
> http://wiki.services.openoffice.org/w/images/5/5d/Mockup_fin22rev.png
> (from the proposal by Constantin Bürgi)
>
> And if you take a look at the last proposal by IBM (by the way, great proposal, great ideas! Better to me than actual Symphony versions!), it does not loose vertical space neither:
> http://wiki.services.openoffice.org/wiki/Sidebar_Proposal_by_IBM
>
> So how come you can affirm that a vertical design has to loose vertical space in this way?
> And again, many designd would work with any "length" of language.
>
>
>> Therefore we would need to use
>> scrolling bars, especially on NETBOOKS where vertical space is
>> precious.
> Need scrolling bars? Again, you are making curious affirmations, without argumenting them very well.
> The proposal by IBM, as well as mine, don't need vertical scrolling bars in general. Neither does RedOffice.
>
> With "in general", I mean that the sidepane does not need its own scrolling bar. Indeed some elements would need one, like the "styles & formatting" in this mockup:
> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
> (yeah, I know, I use this one a lot, sorry!)
>
> And sorry to say this, but I fond scrolling bars in horizontal UI elements much more ridiculous. See Office 2007.
>
> > Try to squeeze 340 commands into a sidepane of e.g. 75 x
>> 600 pixels size. Scrolling bars would again hide some commands, which
>> brings us back to the current problems. Overall, there is a tradeoff
>> between gaining and loosing screen real estate that cancels possible
>> improvements. Therefore, no obvious significant step forward towards
>> a solution.
> First, I am very disappointed, because your arguments show that you did never really consider the option of a vertical UI. It seems that you are bringing mostly personal arguments, without a "testing" base.
> > e.g. 75 x 600 pixels size
> I know, "e.g."... but at least 200 pixels width are standard.
> See:
> http://wiki.services.openoffice.org/w/images/c/c3/Martinu_-_Sidebar_Width_in_different_Office_Suites_applications.png 
>
> Let's have numbers. In 800x600,
> Prototype 0.16 :
> 800x125= 100000
>
> This mockup:
> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
> 207x488= 101016
>
> I have to agree, 800x600 is not a smart choice, but as you can see, the space for the UI is the same (it may very a little, depending how you calculate it). And without scrolling bars, of course, why did you get the idea that these would be needed?
>
> ***
>
> Now, is there enough space for commands, even in 600 pixels height, with a vertical design? Here is the answer:
>
> I would like you to look again at this mockup I made, with a 800x600 pixels resolution. These are about 50 commands on one side pane, many (22) of them with text+icon.
> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
>
> Now count how much commands there are on the "start" tab of the 0.16 prototype: about 25, half as much. 11 with text, also half as much.
> The "format" tab has the most commands in the 0.16 prototype, and these are only 27. Note that the text is smaller in the prototypes that in my mockups.
> (I know, it's only a prototype, ...)
>
> One more thing. I have space for 9 "tabs" in my proposal. (with vertical icon tabs as in the IBM design, there would be space for as many as one would like.)
> If we have the same amount of commands for each tab, about 50, there is a possibility of 450 commands, many of them with full text.
> With 600 pixels height.
>
> I admit that it is the "most optimistic" method to calculate, but still... you were speaking of 340, my result is that there would be space for 450, with 600 pixels height.
>
> Conclusion: in any case, even with a less optimistic calculation, there is enough space in a well made vertical UI. And this, without "eating" the vertical space of a netbook, as does a "ribbon" design.
>
>
> To conclude this point, I was really disappointed to see that you insist on saying that there would be not enough space in a vertical UI, without really trying it.
>
>
>> --> Most of us who think of a presentation applications, or slides
>> and NETBOOKS in particular, also think of 16:9 or 16:10 screen
>> formats. But most of us remain with the thought that the SLIDES are
>> 4:3. Currently that might be true, which is also a pure ASSUMPTION,
>> but that will certainly change rapidly since presenters start to
>> support more the formats of laptop and netbook screen ratios. WHAT
>> WILL HAPPEN THEN??? Slides that resemble the screen ration on a 16:9
>> or even 16:10 screen use MORE screen real estate. That makes a
>> vertical UI less efficient concerning screen real estate usage.
> Once again, you are saying something very strongly, but didn't tried it out...
> I was almost about to say "I didn't think about this" and "you're right", but then I tried it out. And here is a mockup:
> http://dl.getdropbox.com/u/173771/Martinu%20-%20General%20Mockup%2011%20-%20Writer%20in%201366x768%20-%20NEW%20MOCKUP%20WITH%2016%209%20slides.png 
> (with a 16:9 slide on a 16:9 screen)
>
> In fact, it works very well, even with 2 sidebars, as in the mockup!
> (The other solution, with one sidebar only, and the slides overview on the bottom, has even more space for 16:9 slides.)
>
> Conclusion: the argument of the 16:9 slides invalidating the usefulness of a vertical UI is not valid, sorry.
>
>
>> --> "Everyone works in full-screen mode". That is a possibility but a
>>  PURE ASSUMPTION. Having a big wide-screen does not necessarily mean
>> that EVERYONE on the planet has the same usage patterns regarding
>> that screen. On the contrary, it might often be the case that users
>> work with several apps in parallel and reduce the windows of the
>> apps. As long as we do not have any evidence, we should not develop
>> for that use case SOLELY. Meaning, NO FOCUS on anything that works
>> best in full-screen only.
> It would also be pure assumption to imagine that people maximize the windows vertically, thus making the waste of vertical space in a "ribbon" UI even worse. This is not specially an argument against vertical UIs.
>
> As you could see in my mockups, but also in those of the IBM proposal, a vertical UI really works well also in small resolutions.
> And don't forget that most users use Word, with a "portrait" page.
> (I don't say all do, but most of them.)
>
>
>> --> "Sidepanes work well in Writer" That might be true. However, it
>> is not evident for Impress and certainly not for Calc where sheet
>> content is the essence of the app. Steeling 3 columns might be a lot
>> worse than steeling 3 rows.
> Well, I already posted my mockup of Impress with 2 sidepanes.
> I already posted a message about the Calc argument.
> So here it is again: your argument about rows being more important than columns works well in 4:3 resolutions, but again, doesn't apply in 16:9.
> Here is a screenshot of Calc in 1920x1080. I pasted a random sidebar to have an idea of the relative width.
> /media/Kakemphaton/Johannes/Dropbox/Dropbox/Public/OOo_calc_1920x1080.png
>
> Do you REALLY think that the lost space due to the sidepane is still relevant in 16:9 resolutions?
>
> ***
>
>
> A last small thing: the marvelous thing about the ribbons in Office 2007 is how they scale to the size of the window. There are many dynamic elements that adapt their size. I don't see this in the prototypes - yes I know, these are only prototypes.
>
> Once more, I find a vertical UI very suited for these kind of auto-scaling elements. Take for example this mockup, which I'm really sorry to link here for the 10000th time!
> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>
> Well, the "styles and formatting" element at the bottom would scale to all resolutions, displaying more or less lines.
> I miss this in the prototypes, the "ribbon" style UI makes no sense without this scalability.
>
>
> Note that the current toolbars in 3.x could be made scalable also, playing with the text labels, as described here:
> http://wiki.services.openoffice.org/wiki/Proposal_by_Johannes_Eva#14.1_More_about_toolbars 
>
>
> ***
>
>
>> So overall, neither me nor anyone else from the UX team is opposing or promoting that particular design pattern. As the matter of fact, we are not religious about any UI design pattern.
>>
>> First, we never attempted to remove sidepanes completely. Hence, in some contexts sidepanes might appear. However, our design strategy is to remain horizontal for the access of all commands.
>
>> In sum, it is very likely that you will not see a vertical toolbar for accessing all commands as the main location. However, you might see that design patterns for other purposes and in different contexts. That really depends on the app and on the task.
>
> Honestly, I am just chocked by this overall hypocrisy. Really. First say things like "we are not religious about any design pattern" or "the prototypes are only prototypes", or "we don't need prototypes of vertical UIs, we have Symphony", and pretending being open.
>
> And then, it was the feeling I and some other people had, thank you for saying it out loud, already having chosen that the design won't be vertical.
>
> Without having tested it seriously.
>
> Despite a lot of people, not only me, speaking in favor of vertical UIs. I would say, despite of the modern monitor format speaking for vertical UIs.
>
> I mean, did you really read more than 10 comments from the last GullFOSS blog posts, what they say? Not all are rude and dumb, many smart people out there. A lot of them for vertical UIs.
>
> And then, you post some unverified arguments and explanations telling why you have already chosen that the UI would be not vertical.
> Where are the real usability studies?
>
> "Create a User Interface so that OpenOffice.org becomes *the users' choice* not only out of need, but also out of desire."
> I don't believe in it anymore. Saying "we are open", and then not be really open, but stuck in old ideas and designs, despite of the public opinion being that brutal against it: that's not being open.
>
>
>
> ***
>
> I know my words are harsh, and I'm sorry about it. And I'm sorry speaking only to you, Andreas, I don't know which other persons are behind what is for me a "hypocrisy".
>
> And I also know that you, the team behind OOo, don't have the resources you would need and you deserve to do it as well as it should be done. I'm sorry for it.
>
> But this is a reason more for not putting OOo in danger, sucking a lot of its resources in a project that should not be, at least to me, the main priority, and that would last many many years, and that started so baldy, at least in the public opinion.
>
> Are you aware that if Renaissance fails, this could be the death of OOo as a sucessful project? I take so much time to write about this, because I am really worried about all this.
>
> All the best, really, to you and OOo,
> Johannes
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: [ux-discuss] Re: [ux-user interface] Sidepanes --- Why don't be honest about it? --- Some real arguments

Andreas Bartel
Hi there,

OK, quick quick quick answers:

Brian Fleeger schrieb:

> Andreas Bartel wrote (in response to Johannes Eva):
> <Hi Johannes,
> <finally, someone! Thank you!
> [snip...]
> <People change, users change etc. I could go on here to the level of
> <brain plasticity but that is not the point. The point is that if we
> <induce a major change in the UI by transforming something from
> <horizontal to vertical, hence by just moving something from A to B, IT
> <JUST HAS TO BE WORTH GOING THROUGH THE PAIN OF ADAPTATION. Overall, this
> <would require same learning processes to start working as in the changes
> <present in the current prototype or in the UI transition fron MSO 2003
> <to MSO 2007.
> <So, let's summarize insights:
> <1. Tranferring the location where users can access commands from
> <horizontal to vertical, hence from toolbars to a sidepane, is a major
> <change.
> <2. Users can adapt to that change.
> <3.1 Adaptation always involves some sort of individual change or "pain"
> <that is perceived in many ways by all kinds of users (see blog comments
> <;-) )
> <3.2 Some users like change and other clearly DON'T
>
> Really an excellent point about people hating change, especially in
> reference to the suggested changes to OO.o itself.  However, I would
> argue that the comments in retaliation against the Java mockups were not based on resistance to change per se.  Reading
> the comments, even those critics who called for a halt to all UI work
> did so mostly out of resentment of OO.o's imitation (real or perceived)
> of Microsoft Office.  This means that this particular example is less
> about resisting change and more about OO.o's market and brand
> identity.
>
> <4. The reward going through the pain of adaptation must be higher than
> <the threshold of not willing to adapt
> <Now back to you. I'd like you or anyone else to consider the following
> <questions:
> <1. What are the current problems of the overall UI in OOo with all it's
> <constituents?
>
> You mentioned OO.o's constituents, and therein lies some of the reason for the backlash -- who are OO.o's current constituents, and who does OO.o want to be its future constituents.  Its current constituents consist largely of technically savvy people who have chosen for either ideological or cost motivated reasons to use a free alternative to MS Office.  In the future, OO.o wants to expand its base, which by definition means that the ratio of ideologically motivated users will drop.  Therefore, OO.o needs to be pragmatic in how it caters to the next generation of users (this is my assessment of the reasoning anyway).
>  
Sorry, by constituents I ment the parts of the UI of OOo and all
interactions.
> I feel that a number of current users held high hopes when Project Renaissance was first announced that it would come up with a truly novel and superior UI, leapfrogging the competition.  When they saw the mockups, it was a shock on an emotional level, and probably threatened a lot of people's identities (as OO.o users, who specifically chose NOT to use Microsoft office).  But, I do acknowledge that OO.o is seeking to expand to a new constituency with Project Renaissance, moving beyond its base.  
>
> I can understand the desire of the UX team to conform to the norms and conventions of design as defined by the dominant market holder -- that is why most hollywood movies tend to look similar and have similar plots, and
Sorry, not true! We are not seeking any conformation with competition
but INSTEAD looking at existing design patterns (tabs, side panes,
menus, toolbars etc.) that can help us to actually IMPROVE interactions
in OOo and solve real problems without too much change. Basically, it's
all about the right level of trade-offs. Hence, FINDING A BALANCE
BETWEEN NECESSARY CHANGE AND OFFERED VALUE is our goal. Nothing more or
less.

>  more and more coffee shops look like Starbucks.  But people also have to understand that by conforming too closely to established conventions (especially as defined by a highly controversial monopoly company), that is by-definition reducing diversity.  People can argue that OO.o has always been a copy of Office, but a lot of people actually dreamed it would evolve into something better.  So now, people are upset and angry for the same reason that there was rioting at the WTO conference in 1999, or that people sneer when they see a McDonalds in Beirut.  In some weird way, OO.o is engaged in a conflict not unlike the backlash against globalization.  Its current users (or at least a very vocal portion) just really don't want to see their
>  desktop experience too homogenized.  
>
> But to answer your question about constituents more directly, the problem with the UI currently is clearly the same problem that Microsoft had with Office2003 and prior editions, ie hard to find functions burried in menus, and unintuitive UI in general.  Further, the top-mounted horizontal mid-fidelity mockups do address many of these issues, just as Microsoft did with Office 2007.  But there are also unaddressed UI deficiencies in the current Office 2007 and 2010 layouts, and I don't think I need to repeat the arguments about saving space by using a vertical bar, or wasted space using horizontal on widescreens.  Again, I just want to reiterate, people are expecting more than imitation from OO.o.  Even though all cars have four wheels and an engine, I think there is more room for alternative UIs than what has been presented so far.  Really, its a compliment, because to a lot of people OO.o is like some kind of lofty dream of a post-monopolized world.
>
> <1.1 Do these problems apply to all users?
>
> Widescreens, yada yada... ;-)
>
> <1.2 Do these problems occur in all contexts?
> <2. Is the growing number of 16:9 or 16:10 screens a current issue for OOo?
> <2.1 Does the current UI lead to significant usability problems with
> <these types of screens?
>
> Yup, sure do
>  
Please be more specific, what are these problems you consider to be
really significant?
> <2.2 Is a vertically aligned pane a solution?
>
> Yup
>  
Again, please specify.
> <2.3 If so, then to which particular problem is that the solution?
> <2.4 If so, does a vertical pane work equally well in all applications?
>
> This is a little bit of a trick question.  If the vertical plane is sub-optimal in some applications, cannot the same be said for the horizontal plane?
Yes, but we don't have to change anything there, do we?

>   Anyway, in my view they are as follows:
> Writer -- would very much benefit from a vertical plane.  Just look at Johannes's mockups to see how much more room there is.
> Impress -- Neutral.  Even when using a 16:9 slide layout, the preview column can be flipped on its side and laid on the bottom, also as shown in Johannes' drawings.
> Calc -- Depends on usage data to which I do not have, ie are people using columns or rows more in Calc.  Personally, I use more rows (long long lists) so a vertical layout would be idea.  Other times, like when I do cost benefit projects or other cost models, I might need more columns.  But in my personal usage, I tend to go straight down more than sideways.  
>
> <2.4 Is that the best solution we can think of?
> <2.5 What might become more hard to use as a side effect?
>
> As above, Calc *may* suffer, but it depends on implementation.  For instance, in RedOffice 4, the side panel can be undocked and made into one big block of a floating panel, as well as redocked on either side.  A similar solution could mitigate these negative effects in a side panel for OO.o.
>
> <3. Are the users willing to accept the change?
>
> This question is impossible to answer if there is no mid-fidelity mockup for users to try and which could collect measurable usage data.  
>
> <3.1 What do we offer that is so valuable that users are willing to go
> <through the pain of adaptation?
>
> Potentially, in that other than the advantages others have outlined regarding space, a side panel would also provide differentiation and greater brand identity.  But does OO.o want its own brand identity, or is OO.o itself just a trojan horse in the larger chess game of corporate developers to get people to reduce their dependency on the Windows ecosystem?  I can't resist a little conspiracy theory every now and then! (I kid!!  I am OS agnostic) ;-)
>  
OK, you name space. I consider that a myth because there is plainly no
evidence that "space" is currently such a hurdle that makes OOo harder
to use. From a UX perspective there is no such thing as WASTE OF SPACE.
Every bit of information, hence every pixel ADDS TO NOISE, COMPLEXITY
and  NEEDS TO BE PROCESSED by the receiver (user). Therefore, on the
contrary plain space is goooood, it helps to keep the signal-to-noise
ration on a acceptable level.

By the way, you ask lots of hypothetical or philosophical questions :-)
that could lead to endless discussion with great fun but little
agreement.  Let's concentrate on the UX side of the concepts.

Going through the feedback of hundreds (Impress) and thousands  who
commented in our surveys, there no evidence that "space" or the location
of the toolbars, or any format of the screen is of particular
importance/problem to those who decided to give feedback in our surveys.
Hence, despite us here on the lists and others who join the discussion
elsewhere, there is actually very little validation that our users have
significant difficluties with horizontal toolbars in 16:9 or 16:10 screens.

> <3.2 Do all users adapt to the change equally well?
>
> Trick question again.  All users do not adapt equally well, but the bigger question is to what *degree* different users adapt to change.  And without a prototype which could collect real, quantitative data, any answer to this question would be mere conjecture.
>
> <But currently, in our context, and to our project, what
> <probably matters most are these two questions: "WHAT MAJOR PROBLEMS
> <WOULD A VERTICAL PANE SOLVE NOW?" and "HOW WOULD
> <THAT CHANGE AFFECT THE MAJORITY OF OUR USERS?"
> <[snip...] I think that you underestimate the importance and the impact of CONTEXT.
> <Web is not desktop, office productivity is not prefessional graphics
> <tools etc. Each context activates behavior (usage) petterns that fit
> <that particular context. These patterns were shaped by a learning
> <process and are stored as prior knowledge which is istantly activated,
> <when certain perceptual cues appear, in order to trigger appropriate
> <behavior. Humans are pattern matchers, constantly trying to apply things
> <they've already learned in a given situation/context. Hence, a lot of
> <user/usage "behavior" that is appropriate for the web might not be
> <appropriate for the desktop (e.g. one click vs. double click on the
> <mouse as a pure example). Consequently, these issues are pretty hard to
> <assess. That is the reason why we always should keep in mind that
> <transferring things that work in one context to another one is a tricky
> <business. (NOT SAYING THAT IT IS NOT POSSIBLE AT ALL)
>
> When you speak of contexts, and of the importance of conforming to current desktop usage patterns, you more or less preclud the possibility of EVER making any user interface which is different in any significant way  from
Again, you miss the point. I am really starting to wonder where you guys
get the impression from that we don't want change? If that was so, we
would not do the prototypes, would we?

However, our main directive was and still is that IF WE DECIDE TO CHANGE
ANYTHING it just has to be WORTH DOING IT. In plain English, we need to
offer a great portion of VALUE (to a great deal of users) behind ANY CHANGE!

That is as simple as that.

Once again, we are not talking about vertical panes as being totally
useless. But their benefit for the SOLE PURPOSE of offering the access
to all commands is certainly limited, there is no clear significant
advantage over a horizontal one. I agree that there are many other
purposes for vertical panes that are beneficial, and I assure you that
we will use this deisng pattern then.

> Microsoft standards.  Not to offend, but that is the logical conclusion of your argument as I understand it.  As the monopoly holder, they will always define people's "desktop contexts."  But it is also important to remember that the desktop context that the current mockups are seeking to emulate is itself a relatively new cognitive mode.  That is, people's brains are still malleable having been forced to adapt from Office 2003 to Office 2007, so will likely be more likely to adapt more quickly to other new interface models -- should OO.o have the courage to present them and stand on its own two legs.
>
> <[snip...] OK, given that you have a limited insight and understanding of how the
> <UX team works (maybe our fault), what skills are present and how we make
> <decisions, you might get the impression that we do not consider obvious
> <solutions cerefully enough.
>
> I am also not a UI professional, other UI professionals (namely, from IBM) have concluded that a vertical panel is highly desirable, and that by itself, apart from all the arguments presented here, makes it worthy of greater consideration.  
>
> Anyway, great read and I like this thread!
>
> Regards,
> Brian
>
>  
Thanks a lot, and "your turn" ;-)!

Best,
Andreas

> <As my conclusion, thanks for the feedback!
> <Best,
> <Andreas
>  
>
>
>  
>> (By the way, if someone wants to test RedOffice beta 4: I can send the archive of the beta, for Windows. I don't manage to get and install newer versions.)
>>
>>
>> ***
>>
>>    
>>> 2. So, since that change would induce as much confusion as any other change of such severity, it better should be really beneficial. If it
>>>  does not significantly improve usability by a factor of X that is
>>> worse going through the pain of relearning, then IT MAKES NO SENSE to
>>> change that at all.
>>>      
>> Well, I didn't see any publications of testings concerning the actual prototypes. I really don't know if and how they would be really beneficial, or more beneficial that a vertical design or some other features, taking in account that it would probably take 3-5 years of development.
>>
>> The most beneficial thing, according to the users themselves, can be found on slide 30 of this presentation:
>> http://wiki.services.openoffice.org/w/images/1/11/Renaissance-status-2009-01-30_wiki.odp 
>> I often think, if we would think about the users, well, a lot of the energy would have to go to a better MSO 07/03 compatibility.
>>
>> And I don't see in 3.2 the ability to write OOXML, what a disappointment!
>>
>> I'm sorry, I'm off topic. But I don't have seen any publication of tests showing that some of the the prototypes would be better for the end users than the current UI. (Neither that vertical UIs to better or worse, of course.)
>> It is really so beneficial that it justifies concentrating that much resources and energy on it? There are so many things that could be done in OOo...
>>
>>
>>    
>>> 2.1 Better use of screen real estate
>>>
>>> In addition, in a
>>> vertical UI you are forced to either use some sort of an "ACCORDION",
>>> "TABS or VERTICAL TABS" or a mixture of both. Using these controls
>>> means that you loose a lot of vertical space, depending on the font
>>> or icon size and the LANGUAGE (how about Finish), that is occupied by
>>> the labels of tabs or accordion elements.
>>>      
>> That's only true for some designs.
>> I'm sorry to use my proposal again as an illustration, but it is not true in it. Neither it is in Office Mac 2008 or Apple pages. Again, how can you write your argument ignoring these?
>>
>> In this kind of design, the language and length of text is not very important neither:
>> http://wiki.services.openoffice.org/w/images/5/5d/Mockup_fin22rev.png
>> (from the proposal by Constantin Bürgi)
>>
>> And if you take a look at the last proposal by IBM (by the way, great proposal, great ideas! Better to me than actual Symphony versions!), it does not loose vertical space neither:
>> http://wiki.services.openoffice.org/wiki/Sidebar_Proposal_by_IBM
>>
>> So how come you can affirm that a vertical design has to loose vertical space in this way?
>> And again, many designd would work with any "length" of language.
>>
>>
>>    
>>> Therefore we would need to use
>>> scrolling bars, especially on NETBOOKS where vertical space is
>>> precious.
>>>      
>> Need scrolling bars? Again, you are making curious affirmations, without argumenting them very well.
>> The proposal by IBM, as well as mine, don't need vertical scrolling bars in general. Neither does RedOffice.
>>
>> With "in general", I mean that the sidepane does not need its own scrolling bar. Indeed some elements would need one, like the "styles & formatting" in this mockup:
>> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>> (yeah, I know, I use this one a lot, sorry!)
>>
>> And sorry to say this, but I fond scrolling bars in horizontal UI elements much more ridiculous. See Office 2007.
>>
>>    
>>> Try to squeeze 340 commands into a sidepane of e.g. 75 x
>>> 600 pixels size. Scrolling bars would again hide some commands, which
>>> brings us back to the current problems. Overall, there is a tradeoff
>>> between gaining and loosing screen real estate that cancels possible
>>> improvements. Therefore, no obvious significant step forward towards
>>> a solution.
>>>      
>> First, I am very disappointed, because your arguments show that you did never really consider the option of a vertical UI. It seems that you are bringing mostly personal arguments, without a "testing" base.
>>    
>>> e.g. 75 x 600 pixels size
>>>      
>> I know, "e.g."... but at least 200 pixels width are standard.
>> See:
>> http://wiki.services.openoffice.org/w/images/c/c3/Martinu_-_Sidebar_Width_in_different_Office_Suites_applications.png 
>>
>> Let's have numbers. In 800x600,
>> Prototype 0.16 :
>> 800x125= 100000
>>
>> This mockup:
>> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
>> 207x488= 101016
>>
>> I have to agree, 800x600 is not a smart choice, but as you can see, the space for the UI is the same (it may very a little, depending how you calculate it). And without scrolling bars, of course, why did you get the idea that these would be needed?
>>
>> ***
>>
>> Now, is there enough space for commands, even in 600 pixels height, with a vertical design? Here is the answer:
>>
>> I would like you to look again at this mockup I made, with a 800x600 pixels resolution. These are about 50 commands on one side pane, many (22) of them with text+icon.
>> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
>>
>> Now count how much commands there are on the "start" tab of the 0.16 prototype: about 25, half as much. 11 with text, also half as much.
>> The "format" tab has the most commands in the 0.16 prototype, and these are only 27. Note that the text is smaller in the prototypes that in my mockups.
>> (I know, it's only a prototype, ...)
>>
>> One more thing. I have space for 9 "tabs" in my proposal. (with vertical icon tabs as in the IBM design, there would be space for as many as one would like.)
>> If we have the same amount of commands for each tab, about 50, there is a possibility of 450 commands, many of them with full text.
>> With 600 pixels height.
>>
>> I admit that it is the "most optimistic" method to calculate, but still... you were speaking of 340, my result is that there would be space for 450, with 600 pixels height.
>>
>> Conclusion: in any case, even with a less optimistic calculation, there is enough space in a well made vertical UI. And this, without "eating" the vertical space of a netbook, as does a "ribbon" design.
>>
>>
>> To conclude this point, I was really disappointed to see that you insist on saying that there would be not enough space in a vertical UI, without really trying it.
>>
>>
>>    
>>> --> Most of us who think of a presentation applications, or slides
>>> and NETBOOKS in particular, also think of 16:9 or 16:10 screen
>>> formats. But most of us remain with the thought that the SLIDES are
>>> 4:3. Currently that might be true, which is also a pure ASSUMPTION,
>>> but that will certainly change rapidly since presenters start to
>>> support more the formats of laptop and netbook screen ratios. WHAT
>>> WILL HAPPEN THEN??? Slides that resemble the screen ration on a 16:9
>>> or even 16:10 screen use MORE screen real estate. That makes a
>>> vertical UI less efficient concerning screen real estate usage.
>>>      
>> Once again, you are saying something very strongly, but didn't tried it out...
>> I was almost about to say "I didn't think about this" and "you're right", but then I tried it out. And here is a mockup:
>> http://dl.getdropbox.com/u/173771/Martinu%20-%20General%20Mockup%2011%20-%20Writer%20in%201366x768%20-%20NEW%20MOCKUP%20WITH%2016%209%20slides.png 
>> (with a 16:9 slide on a 16:9 screen)
>>
>> In fact, it works very well, even with 2 sidebars, as in the mockup!
>> (The other solution, with one sidebar only, and the slides overview on the bottom, has even more space for 16:9 slides.)
>>
>> Conclusion: the argument of the 16:9 slides invalidating the usefulness of a vertical UI is not valid, sorry.
>>
>>
>>    
>>> --> "Everyone works in full-screen mode". That is a possibility but a
>>>  PURE ASSUMPTION. Having a big wide-screen does not necessarily mean
>>> that EVERYONE on the planet has the same usage patterns regarding
>>> that screen. On the contrary, it might often be the case that users
>>> work with several apps in parallel and reduce the windows of the
>>> apps. As long as we do not have any evidence, we should not develop
>>> for that use case SOLELY. Meaning, NO FOCUS on anything that works
>>> best in full-screen only.
>>>      
>> It would also be pure assumption to imagine that people maximize the windows vertically, thus making the waste of vertical space in a "ribbon" UI even worse. This is not specially an argument against vertical UIs.
>>
>> As you could see in my mockups, but also in those of the IBM proposal, a vertical UI really works well also in small resolutions.
>> And don't forget that most users use Word, with a "portrait" page.
>> (I don't say all do, but most of them.)
>>
>>
>>    
>>> --> "Sidepanes work well in Writer" That might be true. However, it
>>> is not evident for Impress and certainly not for Calc where sheet
>>> content is the essence of the app. Steeling 3 columns might be a lot
>>> worse than steeling 3 rows.
>>>      
>> Well, I already posted my mockup of Impress with 2 sidepanes.
>> I already posted a message about the Calc argument.
>> So here it is again: your argument about rows being more important than columns works well in 4:3 resolutions, but again, doesn't apply in 16:9.
>> Here is a screenshot of Calc in 1920x1080. I pasted a random sidebar to have an idea of the relative width.
>> /media/Kakemphaton/Johannes/Dropbox/Dropbox/Public/OOo_calc_1920x1080.png
>>
>> Do you REALLY think that the lost space due to the sidepane is still relevant in 16:9 resolutions?
>>
>> ***
>>
>>
>> A last small thing: the marvelous thing about the ribbons in Office 2007 is how they scale to the size of the window. There are many dynamic elements that adapt their size. I don't see this in the prototypes - yes I know, these are only prototypes.
>>
>> Once more, I find a vertical UI very suited for these kind of auto-scaling elements. Take for example this mockup, which I'm really sorry to link here for the 10000th time!
>> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>>
>> Well, the "styles and formatting" element at the bottom would scale to all resolutions, displaying more or less lines.
>> I miss this in the prototypes, the "ribbon" style UI makes no sense without this scalability.
>>
>>
>> Note that the current toolbars in 3.x could be made scalable also, playing with the text labels, as described here:
>> http://wiki.services.openoffice.org/wiki/Proposal_by_Johannes_Eva#14.1_More_about_toolbars 
>>
>>
>> ***
>>
>>
>>    
>>> So overall, neither me nor anyone else from the UX team is opposing or promoting that particular design pattern. As the matter of fact, we are not religious about any UI design pattern.
>>>
>>> First, we never attempted to remove sidepanes completely. Hence, in some contexts sidepanes might appear. However, our design strategy is to remain horizontal for the access of all commands.
>>>      
>>> In sum, it is very likely that you will not see a vertical toolbar for accessing all commands as the main location. However, you might see that design patterns for other purposes and in different contexts. That really depends on the app and on the task.
>>>      
>> Honestly, I am just chocked by this overall hypocrisy. Really. First say things like "we are not religious about any design pattern" or "the prototypes are only prototypes", or "we don't need prototypes of vertical UIs, we have Symphony", and pretending being open.
>>
>> And then, it was the feeling I and some other people had, thank you for saying it out loud, already having chosen that the design won't be vertical.
>>
>> Without having tested it seriously.
>>
>> Despite a lot of people, not only me, speaking in favor of vertical UIs. I would say, despite of the modern monitor format speaking for vertical UIs.
>>
>> I mean, did you really read more than 10 comments from the last GullFOSS blog posts, what they say? Not all are rude and dumb, many smart people out there. A lot of them for vertical UIs.
>>
>> And then, you post some unverified arguments and explanations telling why you have already chosen that the UI would be not vertical.
>> Where are the real usability studies?
>>
>> "Create a User Interface so that OpenOffice.org becomes *the users' choice* not only out of need, but also out of desire."
>> I don't believe in it anymore. Saying "we are open", and then not be really open, but stuck in old ideas and designs, despite of the public opinion being that brutal against it: that's not being open.
>>
>>
>>
>> ***
>>
>> I know my words are harsh, and I'm sorry about it. And I'm sorry speaking only to you, Andreas, I don't know which other persons are behind what is for me a "hypocrisy".
>>
>> And I also know that you, the team behind OOo, don't have the resources you would need and you deserve to do it as well as it should be done. I'm sorry for it.
>>
>> But this is a reason more for not putting OOo in danger, sucking a lot of its resources in a project that should not be, at least to me, the main priority, and that would last many many years, and that started so baldy, at least in the public opinion.
>>
>> Are you aware that if Renaissance fails, this could be the death of OOo as a sucessful project? I take so much time to write about this, because I am really worried about all this.
>>
>> All the best, really, to you and OOo,
>> Johannes
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]
>
>
>      
>
>  


--
*********************************************************************

Sun Microsystems GmbH                Andreas Bartel
Nagelsweg 55                         User Experience Engineer
20097 Hamburg                        Phone: (+49 40)23646 672
Germany                              Fax:   (+49 40)23646 550
http://www.sun.com                   mailto:[hidden email]

*********************************************************************

Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring



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

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] Re: [ux-user interface] Sidepanes --- Why don't be honest about it? --- Some real arguments

Andreas Bartel
Hi again,

going through my own reply I recognized that my statements about screen
real estate might lead to misunderstandings. I guess we all AGREE that
in certain conditions the distribution of UI elements in the current
interface is "problematic" in a sence that it comsumes a lot of space
that otherwise would be available for the content of a document, be it
slides, pages or sheets.

Hence, one current usablity bug is certainly the condition that there is
often not enough room for the things the users actually focus on,
namely, the content they wish to create. However, there is little
evidence that this problem significanlty varies between different screen
formats (not size). It's more or less an omnipresent problem that needs
to be addressed.

Best,
Andreas

Andreas Bartel schrieb:

> Hi there,
>
> OK, quick quick quick answers:
>
> Brian Fleeger schrieb:
>> Andreas Bartel wrote (in response to Johannes Eva):
>> <Hi Johannes,
>> <finally, someone! Thank you!
>> [snip...]
>> <People change, users change etc. I could go on here to the level of
>> <brain plasticity but that is not the point. The point is that if we
>> <induce a major change in the UI by transforming something from
>> <horizontal to vertical, hence by just moving something from A to B, IT
>> <JUST HAS TO BE WORTH GOING THROUGH THE PAIN OF ADAPTATION. Overall,
>> this
>> <would require same learning processes to start working as in the
>> changes
>> <present in the current prototype or in the UI transition fron MSO 2003
>> <to MSO 2007.
>> <So, let's summarize insights:
>> <1. Tranferring the location where users can access commands from
>> <horizontal to vertical, hence from toolbars to a sidepane, is a major
>> <change.
>> <2. Users can adapt to that change.
>> <3.1 Adaptation always involves some sort of individual change or "pain"
>> <that is perceived in many ways by all kinds of users (see blog comments
>> <;-) )
>> <3.2 Some users like change and other clearly DON'T
>>
>> Really an excellent point about people hating change, especially in
>> reference to the suggested changes to OO.o itself.  However, I would
>> argue that the comments in retaliation against the Java mockups were
>> not based on resistance to change per se.  Reading
>> the comments, even those critics who called for a halt to all UI work
>> did so mostly out of resentment of OO.o's imitation (real or perceived)
>> of Microsoft Office.  This means that this particular example is less
>> about resisting change and more about OO.o's market and brand
>> identity.
>> <4. The reward going through the pain of adaptation must be higher than
>> <the threshold of not willing to adapt
>> <Now back to you. I'd like you or anyone else to consider the following
>> <questions:
>> <1. What are the current problems of the overall UI in OOo with all it's
>> <constituents?
>>
>> You mentioned OO.o's constituents, and therein lies some of the
>> reason for the backlash -- who are OO.o's current constituents, and
>> who does OO.o want to be its future constituents.  Its current
>> constituents consist largely of technically savvy people who have
>> chosen for either ideological or cost motivated reasons to use a free
>> alternative to MS Office.  In the future, OO.o wants to expand its
>> base, which by definition means that the ratio of ideologically
>> motivated users will drop.  Therefore, OO.o needs to be pragmatic in
>> how it caters to the next generation of users (this is my assessment
>> of the reasoning anyway).
>>  
> Sorry, by constituents I ment the parts of the UI of OOo and all
> interactions.
>> I feel that a number of current users held high hopes when Project
>> Renaissance was first announced that it would come up with a truly
>> novel and superior UI, leapfrogging the competition.  When they saw
>> the mockups, it was a shock on an emotional level, and probably
>> threatened a lot of people's identities (as OO.o users, who
>> specifically chose NOT to use Microsoft office).  But, I do
>> acknowledge that OO.o is seeking to expand to a new constituency with
>> Project Renaissance, moving beyond its base.
>> I can understand the desire of the UX team to conform to the norms
>> and conventions of design as defined by the dominant market holder --
>> that is why most hollywood movies tend to look similar and have
>> similar plots, and
> Sorry, not true! We are not seeking any conformation with competition
> but INSTEAD looking at existing design patterns (tabs, side panes,
> menus, toolbars etc.) that can help us to actually IMPROVE
> interactions in OOo and solve real problems without too much change.
> Basically, it's all about the right level of trade-offs. Hence,
> FINDING A BALANCE BETWEEN NECESSARY CHANGE AND OFFERED VALUE is our
> goal. Nothing more or less.
>>  more and more coffee shops look like Starbucks.  But people also
>> have to understand that by conforming too closely to established
>> conventions (especially as defined by a highly controversial monopoly
>> company), that is by-definition reducing diversity.  People can argue
>> that OO.o has always been a copy of Office, but a lot of people
>> actually dreamed it would evolve into something better.  So now,
>> people are upset and angry for the same reason that there was rioting
>> at the WTO conference in 1999, or that people sneer when they see a
>> McDonalds in Beirut.  In some weird way, OO.o is engaged in a
>> conflict not unlike the backlash against globalization.  Its current
>> users (or at least a very vocal portion) just really don't want to
>> see their
>>  desktop experience too homogenized.
>> But to answer your question about constituents more directly, the
>> problem with the UI currently is clearly the same problem that
>> Microsoft had with Office2003 and prior editions, ie hard to find
>> functions burried in menus, and unintuitive UI in general.  Further,
>> the top-mounted horizontal mid-fidelity mockups do address many of
>> these issues, just as Microsoft did with Office 2007.  But there are
>> also unaddressed UI deficiencies in the current Office 2007 and 2010
>> layouts, and I don't think I need to repeat the arguments about
>> saving space by using a vertical bar, or wasted space using
>> horizontal on widescreens.  Again, I just want to reiterate, people
>> are expecting more than imitation from OO.o.  Even though all cars
>> have four wheels and an engine, I think there is more room for
>> alternative UIs than what has been presented so far.  Really, its a
>> compliment, because to a lot of people OO.o is like some kind of
>> lofty dream of a post-monopolized world.
>>
>> <1.1 Do these problems apply to all users?
>>
>> Widescreens, yada yada... ;-)
>>
>> <1.2 Do these problems occur in all contexts?
>> <2. Is the growing number of 16:9 or 16:10 screens a current issue
>> for OOo?
>> <2.1 Does the current UI lead to significant usability problems with
>> <these types of screens?
>>
>> Yup, sure do
>>  
> Please be more specific, what are these problems you consider to be
> really significant?
>> <2.2 Is a vertically aligned pane a solution?
>>
>> Yup
>>  
> Again, please specify.
>> <2.3 If so, then to which particular problem is that the solution?
>> <2.4 If so, does a vertical pane work equally well in all applications?
>>
>> This is a little bit of a trick question.  If the vertical plane is
>> sub-optimal in some applications, cannot the same be said for the
>> horizontal plane?
> Yes, but we don't have to change anything there, do we?
>>   Anyway, in my view they are as follows:
>> Writer -- would very much benefit from a vertical plane.  Just look
>> at Johannes's mockups to see how much more room there is.
>> Impress -- Neutral.  Even when using a 16:9 slide layout, the preview
>> column can be flipped on its side and laid on the bottom, also as
>> shown in Johannes' drawings.
>> Calc -- Depends on usage data to which I do not have, ie are people
>> using columns or rows more in Calc.  Personally, I use more rows
>> (long long lists) so a vertical layout would be idea.  Other times,
>> like when I do cost benefit projects or other cost models, I might
>> need more columns.  But in my personal usage, I tend to go straight
>> down more than sideways.
>> <2.4 Is that the best solution we can think of?
>> <2.5 What might become more hard to use as a side effect?
>>
>> As above, Calc *may* suffer, but it depends on implementation.  For
>> instance, in RedOffice 4, the side panel can be undocked and made
>> into one big block of a floating panel, as well as redocked on either
>> side.  A similar solution could mitigate these negative effects in a
>> side panel for OO.o.
>>
>> <3. Are the users willing to accept the change?
>>
>> This question is impossible to answer if there is no mid-fidelity
>> mockup for users to try and which could collect measurable usage data.
>> <3.1 What do we offer that is so valuable that users are willing to go
>> <through the pain of adaptation?
>>
>> Potentially, in that other than the advantages others have outlined
>> regarding space, a side panel would also provide differentiation and
>> greater brand identity.  But does OO.o want its own brand identity,
>> or is OO.o itself just a trojan horse in the larger chess game of
>> corporate developers to get people to reduce their dependency on the
>> Windows ecosystem?  I can't resist a little conspiracy theory every
>> now and then! (I kid!!  I am OS agnostic) ;-)
>>  
> OK, you name space. I consider that a myth because there is plainly no
> evidence that "space" is currently such a hurdle that makes OOo harder
> to use. From a UX perspective there is no such thing as WASTE OF
> SPACE. Every bit of information, hence every pixel ADDS TO NOISE,
> COMPLEXITY and  NEEDS TO BE PROCESSED by the receiver (user).
> Therefore, on the contrary plain space is goooood, it helps to keep
> the signal-to-noise ration on a acceptable level.
>
> By the way, you ask lots of hypothetical or philosophical questions
> :-) that could lead to endless discussion with great fun but little
> agreement.  Let's concentrate on the UX side of the concepts.
>
> Going through the feedback of hundreds (Impress) and thousands  who
> commented in our surveys, there no evidence that "space" or the
> location of the toolbars, or any format of the screen is of particular
> importance/problem to those who decided to give feedback in our
> surveys. Hence, despite us here on the lists and others who join the
> discussion elsewhere, there is actually very little validation that
> our users have significant difficluties with horizontal toolbars in
> 16:9 or 16:10 screens.
>> <3.2 Do all users adapt to the change equally well?
>>
>> Trick question again.  All users do not adapt equally well, but the
>> bigger question is to what *degree* different users adapt to change.  
>> And without a prototype which could collect real, quantitative data,
>> any answer to this question would be mere conjecture.
>>
>> <But currently, in our context, and to our project, what
>> <probably matters most are these two questions: "WHAT MAJOR PROBLEMS
>> <WOULD A VERTICAL PANE SOLVE NOW?" and "HOW WOULD <THAT CHANGE AFFECT
>> THE MAJORITY OF OUR USERS?"
>> <[snip...] I think that you underestimate the importance and the
>> impact of CONTEXT.
>> <Web is not desktop, office productivity is not prefessional graphics
>> <tools etc. Each context activates behavior (usage) petterns that fit
>> <that particular context. These patterns were shaped by a learning
>> <process and are stored as prior knowledge which is istantly activated,
>> <when certain perceptual cues appear, in order to trigger appropriate
>> <behavior. Humans are pattern matchers, constantly trying to apply
>> things
>> <they've already learned in a given situation/context. Hence, a lot of
>> <user/usage "behavior" that is appropriate for the web might not be
>> <appropriate for the desktop (e.g. one click vs. double click on the
>> <mouse as a pure example). Consequently, these issues are pretty hard to
>> <assess. That is the reason why we always should keep in mind that
>> <transferring things that work in one context to another one is a tricky
>> <business. (NOT SAYING THAT IT IS NOT POSSIBLE AT ALL)
>>
>> When you speak of contexts, and of the importance of conforming to
>> current desktop usage patterns, you more or less preclud the
>> possibility of EVER making any user interface which is different in
>> any significant way  from
> Again, you miss the point. I am really starting to wonder where you
> guys get the impression from that we don't want change? If that was
> so, we would not do the prototypes, would we?
>
> However, our main directive was and still is that IF WE DECIDE TO
> CHANGE ANYTHING it just has to be WORTH DOING IT. In plain English, we
> need to offer a great portion of VALUE (to a great deal of users)
> behind ANY CHANGE!
>
> That is as simple as that.
>
> Once again, we are not talking about vertical panes as being totally
> useless. But their benefit for the SOLE PURPOSE of offering the access
> to all commands is certainly limited, there is no clear significant
> advantage over a horizontal one. I agree that there are many other
> purposes for vertical panes that are beneficial, and I assure you that
> we will use this deisng pattern then.
>> Microsoft standards.  Not to offend, but that is the logical
>> conclusion of your argument as I understand it.  As the monopoly
>> holder, they will always define people's "desktop contexts."  But it
>> is also important to remember that the desktop context that the
>> current mockups are seeking to emulate is itself a relatively new
>> cognitive mode.  That is, people's brains are still malleable having
>> been forced to adapt from Office 2003 to Office 2007, so will likely
>> be more likely to adapt more quickly to other new interface models --
>> should OO.o have the courage to present them and stand on its own two
>> legs.
>>
>> <[snip...] OK, given that you have a limited insight and
>> understanding of how the
>> <UX team works (maybe our fault), what skills are present and how we
>> make
>> <decisions, you might get the impression that we do not consider obvious
>> <solutions cerefully enough.
>> I am also not a UI professional, other UI professionals (namely, from
>> IBM) have concluded that a vertical panel is highly desirable, and
>> that by itself, apart from all the arguments presented here, makes it
>> worthy of greater consideration.
>> Anyway, great read and I like this thread!
>>
>> Regards,
>> Brian
>>
>>  
> Thanks a lot, and "your turn" ;-)!
>
> Best,
> Andreas
>> <As my conclusion, thanks for the feedback!
>> <Best,
>> <Andreas
>>  
>>
>>  
>>> (By the way, if someone wants to test RedOffice beta 4: I can send
>>> the archive of the beta, for Windows. I don't manage to get and
>>> install newer versions.)
>>>
>>>
>>> ***
>>>
>>>    
>>>> 2. So, since that change would induce as much confusion as any
>>>> other change of such severity, it better should be really
>>>> beneficial. If it
>>>>  does not significantly improve usability by a factor of X that is
>>>> worse going through the pain of relearning, then IT MAKES NO SENSE to
>>>> change that at all.      
>>> Well, I didn't see any publications of testings concerning the
>>> actual prototypes. I really don't know if and how they would be
>>> really beneficial, or more beneficial that a vertical design or some
>>> other features, taking in account that it would probably take 3-5
>>> years of development.
>>>
>>> The most beneficial thing, according to the users themselves, can be
>>> found on slide 30 of this presentation:
>>> http://wiki.services.openoffice.org/w/images/1/11/Renaissance-status-2009-01-30_wiki.odp 
>>> I often think, if we would think about the users, well, a lot of the
>>> energy would have to go to a better MSO 07/03 compatibility.
>>>
>>> And I don't see in 3.2 the ability to write OOXML, what a
>>> disappointment!
>>>
>>> I'm sorry, I'm off topic. But I don't have seen any publication of
>>> tests showing that some of the the prototypes would be better for
>>> the end users than the current UI. (Neither that vertical UIs to
>>> better or worse, of course.)
>>> It is really so beneficial that it justifies concentrating that much
>>> resources and energy on it? There are so many things that could be
>>> done in OOo...
>>>
>>>
>>>    
>>>> 2.1 Better use of screen real estate
>>>>
>>>> In addition, in a
>>>> vertical UI you are forced to either use some sort of an "ACCORDION",
>>>> "TABS or VERTICAL TABS" or a mixture of both. Using these controls
>>>> means that you loose a lot of vertical space, depending on the font
>>>> or icon size and the LANGUAGE (how about Finish), that is occupied by
>>>> the labels of tabs or accordion elements.      
>>> That's only true for some designs.
>>> I'm sorry to use my proposal again as an illustration, but it is not
>>> true in it. Neither it is in Office Mac 2008 or Apple pages. Again,
>>> how can you write your argument ignoring these?
>>>
>>> In this kind of design, the language and length of text is not very
>>> important neither:
>>> http://wiki.services.openoffice.org/w/images/5/5d/Mockup_fin22rev.png
>>> (from the proposal by Constantin Bürgi)
>>>
>>> And if you take a look at the last proposal by IBM (by the way,
>>> great proposal, great ideas! Better to me than actual Symphony
>>> versions!), it does not loose vertical space neither:
>>> http://wiki.services.openoffice.org/wiki/Sidebar_Proposal_by_IBM
>>>
>>> So how come you can affirm that a vertical design has to loose
>>> vertical space in this way?
>>> And again, many designd would work with any "length" of language.
>>>
>>>
>>>    
>>>> Therefore we would need to use
>>>> scrolling bars, especially on NETBOOKS where vertical space is
>>>> precious.      
>>> Need scrolling bars? Again, you are making curious affirmations,
>>> without argumenting them very well.
>>> The proposal by IBM, as well as mine, don't need vertical scrolling
>>> bars in general. Neither does RedOffice.
>>>
>>> With "in general", I mean that the sidepane does not need its own
>>> scrolling bar. Indeed some elements would need one, like the "styles
>>> & formatting" in this mockup:
>>> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>>> (yeah, I know, I use this one a lot, sorry!)
>>>
>>> And sorry to say this, but I fond scrolling bars in horizontal UI
>>> elements much more ridiculous. See Office 2007.
>>>
>>>    
>>>> Try to squeeze 340 commands into a sidepane of e.g. 75 x
>>>> 600 pixels size. Scrolling bars would again hide some commands, which
>>>> brings us back to the current problems. Overall, there is a tradeoff
>>>> between gaining and loosing screen real estate that cancels possible
>>>> improvements. Therefore, no obvious significant step forward towards
>>>> a solution.
>>>>      
>>> First, I am very disappointed, because your arguments show that you
>>> did never really consider the option of a vertical UI. It seems that
>>> you are bringing mostly personal arguments, without a "testing" base.
>>>    
>>>> e.g. 75 x 600 pixels size
>>>>      
>>> I know, "e.g."... but at least 200 pixels width are standard.
>>> See:
>>> http://wiki.services.openoffice.org/w/images/c/c3/Martinu_-_Sidebar_Width_in_different_Office_Suites_applications.png 
>>>
>>> Let's have numbers. In 800x600,
>>> Prototype 0.16 :
>>> 800x125= 100000
>>>
>>> This mockup:
>>> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
>>> 207x488= 101016
>>>
>>> I have to agree, 800x600 is not a smart choice, but as you can see,
>>> the space for the UI is the same (it may very a little, depending
>>> how you calculate it). And without scrolling bars, of course, why
>>> did you get the idea that these would be needed?
>>>
>>> ***
>>>
>>> Now, is there enough space for commands, even in 600 pixels height,
>>> with a vertical design? Here is the answer:
>>>
>>> I would like you to look again at this mockup I made, with a 800x600
>>> pixels resolution. These are about 50 commands on one side pane,
>>> many (22) of them with text+icon.
>>> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
>>>
>>> Now count how much commands there are on the "start" tab of the 0.16
>>> prototype: about 25, half as much. 11 with text, also half as much.
>>> The "format" tab has the most commands in the 0.16 prototype, and
>>> these are only 27. Note that the text is smaller in the prototypes
>>> that in my mockups.
>>> (I know, it's only a prototype, ...)
>>>
>>> One more thing. I have space for 9 "tabs" in my proposal. (with
>>> vertical icon tabs as in the IBM design, there would be space for as
>>> many as one would like.)
>>> If we have the same amount of commands for each tab, about 50, there
>>> is a possibility of 450 commands, many of them with full text.
>>> With 600 pixels height.
>>>
>>> I admit that it is the "most optimistic" method to calculate, but
>>> still... you were speaking of 340, my result is that there would be
>>> space for 450, with 600 pixels height.
>>>
>>> Conclusion: in any case, even with a less optimistic calculation,
>>> there is enough space in a well made vertical UI. And this, without
>>> "eating" the vertical space of a netbook, as does a "ribbon" design.
>>>
>>>
>>> To conclude this point, I was really disappointed to see that you
>>> insist on saying that there would be not enough space in a vertical
>>> UI, without really trying it.
>>>
>>>
>>>    
>>>> --> Most of us who think of a presentation applications, or slides
>>>> and NETBOOKS in particular, also think of 16:9 or 16:10 screen
>>>> formats. But most of us remain with the thought that the SLIDES are
>>>> 4:3. Currently that might be true, which is also a pure ASSUMPTION,
>>>> but that will certainly change rapidly since presenters start to
>>>> support more the formats of laptop and netbook screen ratios. WHAT
>>>> WILL HAPPEN THEN??? Slides that resemble the screen ration on a 16:9
>>>> or even 16:10 screen use MORE screen real estate. That makes a
>>>> vertical UI less efficient concerning screen real estate usage.
>>>>      
>>> Once again, you are saying something very strongly, but didn't tried
>>> it out...
>>> I was almost about to say "I didn't think about this" and "you're
>>> right", but then I tried it out. And here is a mockup:
>>> http://dl.getdropbox.com/u/173771/Martinu%20-%20General%20Mockup%2011%20-%20Writer%20in%201366x768%20-%20NEW%20MOCKUP%20WITH%2016%209%20slides.png 
>>> (with a 16:9 slide on a 16:9 screen)
>>>
>>> In fact, it works very well, even with 2 sidebars, as in the mockup!
>>> (The other solution, with one sidebar only, and the slides overview
>>> on the bottom, has even more space for 16:9 slides.)
>>>
>>> Conclusion: the argument of the 16:9 slides invalidating the
>>> usefulness of a vertical UI is not valid, sorry.
>>>
>>>
>>>    
>>>> --> "Everyone works in full-screen mode". That is a possibility but a
>>>>  PURE ASSUMPTION. Having a big wide-screen does not necessarily mean
>>>> that EVERYONE on the planet has the same usage patterns regarding
>>>> that screen. On the contrary, it might often be the case that users
>>>> work with several apps in parallel and reduce the windows of the
>>>> apps. As long as we do not have any evidence, we should not develop
>>>> for that use case SOLELY. Meaning, NO FOCUS on anything that works
>>>> best in full-screen only.
>>>>      
>>> It would also be pure assumption to imagine that people maximize the
>>> windows vertically, thus making the waste of vertical space in a
>>> "ribbon" UI even worse. This is not specially an argument against
>>> vertical UIs.
>>>
>>> As you could see in my mockups, but also in those of the IBM
>>> proposal, a vertical UI really works well also in small resolutions.
>>> And don't forget that most users use Word, with a "portrait" page.
>>> (I don't say all do, but most of them.)
>>>
>>>
>>>    
>>>> --> "Sidepanes work well in Writer" That might be true. However, it
>>>> is not evident for Impress and certainly not for Calc where sheet
>>>> content is the essence of the app. Steeling 3 columns might be a lot
>>>> worse than steeling 3 rows.      
>>> Well, I already posted my mockup of Impress with 2 sidepanes.
>>> I already posted a message about the Calc argument.
>>> So here it is again: your argument about rows being more important
>>> than columns works well in 4:3 resolutions, but again, doesn't apply
>>> in 16:9.
>>> Here is a screenshot of Calc in 1920x1080. I pasted a random sidebar
>>> to have an idea of the relative width.
>>> /media/Kakemphaton/Johannes/Dropbox/Dropbox/Public/OOo_calc_1920x1080.png
>>>
>>>
>>> Do you REALLY think that the lost space due to the sidepane is still
>>> relevant in 16:9 resolutions?
>>>
>>> ***
>>>
>>>
>>> A last small thing: the marvelous thing about the ribbons in Office
>>> 2007 is how they scale to the size of the window. There are many
>>> dynamic elements that adapt their size. I don't see this in the
>>> prototypes - yes I know, these are only prototypes.
>>>
>>> Once more, I find a vertical UI very suited for these kind of
>>> auto-scaling elements. Take for example this mockup, which I'm
>>> really sorry to link here for the 10000th time!
>>> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>>>
>>> Well, the "styles and formatting" element at the bottom would scale
>>> to all resolutions, displaying more or less lines.
>>> I miss this in the prototypes, the "ribbon" style UI makes no sense
>>> without this scalability.
>>>
>>>
>>> Note that the current toolbars in 3.x could be made scalable also,
>>> playing with the text labels, as described here:
>>> http://wiki.services.openoffice.org/wiki/Proposal_by_Johannes_Eva#14.1_More_about_toolbars 
>>>
>>>
>>> ***
>>>
>>>
>>>    
>>>> So overall, neither me nor anyone else from the UX team is opposing
>>>> or promoting that particular design pattern. As the matter of fact,
>>>> we are not religious about any UI design pattern.
>>>>
>>>> First, we never attempted to remove sidepanes completely. Hence, in
>>>> some contexts sidepanes might appear. However, our design strategy
>>>> is to remain horizontal for the access of all commands.
>>>>       In sum, it is very likely that you will not see a vertical
>>>> toolbar for accessing all commands as the main location. However,
>>>> you might see that design patterns for other purposes and in
>>>> different contexts. That really depends on the app and on the task.
>>>>      
>>> Honestly, I am just chocked by this overall hypocrisy. Really. First
>>> say things like "we are not religious about any design pattern" or
>>> "the prototypes are only prototypes", or "we don't need prototypes
>>> of vertical UIs, we have Symphony", and pretending being open.
>>>
>>> And then, it was the feeling I and some other people had, thank you
>>> for saying it out loud, already having chosen that the design won't
>>> be vertical.
>>>
>>> Without having tested it seriously.
>>>
>>> Despite a lot of people, not only me, speaking in favor of vertical
>>> UIs. I would say, despite of the modern monitor format speaking for
>>> vertical UIs.
>>>
>>> I mean, did you really read more than 10 comments from the last
>>> GullFOSS blog posts, what they say? Not all are rude and dumb, many
>>> smart people out there. A lot of them for vertical UIs.
>>>
>>> And then, you post some unverified arguments and explanations
>>> telling why you have already chosen that the UI would be not vertical.
>>> Where are the real usability studies?
>>>
>>> "Create a User Interface so that OpenOffice.org becomes *the users'
>>> choice* not only out of need, but also out of desire."
>>> I don't believe in it anymore. Saying "we are open", and then not be
>>> really open, but stuck in old ideas and designs, despite of the
>>> public opinion being that brutal against it: that's not being open.
>>>
>>>
>>>
>>> ***
>>>
>>> I know my words are harsh, and I'm sorry about it. And I'm sorry
>>> speaking only to you, Andreas, I don't know which other persons are
>>> behind what is for me a "hypocrisy".
>>>
>>> And I also know that you, the team behind OOo, don't have the
>>> resources you would need and you deserve to do it as well as it
>>> should be done. I'm sorry for it.
>>>
>>> But this is a reason more for not putting OOo in danger, sucking a
>>> lot of its resources in a project that should not be, at least to
>>> me, the main priority, and that would last many many years, and that
>>> started so baldy, at least in the public opinion.
>>>
>>> Are you aware that if Renaissance fails, this could be the death of
>>> OOo as a sucessful project? I take so much time to write about this,
>>> because I am really worried about all this.
>>>
>>> All the best, really, to you and OOo,
>>> Johannes
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>>
>>      
>>  
>
>


--
*********************************************************************

Sun Microsystems GmbH                Andreas Bartel
Nagelsweg 55                         User Experience Engineer
20097 Hamburg                        Phone: (+49 40)23646 672
Germany                              Fax:   (+49 40)23646 550
http://www.sun.com                   mailto:[hidden email]

*********************************************************************

Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring


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

Reply | Threaded
Open this post in threaded view
|

Re: [ux-discuss] Re: [ux-user interface] Sidepanes --- Why don't be honest about it? --- Some real arguments

Irné Barnard
In reply to this post by Andreas Bartel
Andreas Bartel wrote:

> OK, you name space. I consider that a myth because there is plainly no
> evidence that "space" is currently such a hurdle that makes OOo harder
> to use. From a UX perspective there is no such thing as WASTE OF
> SPACE. Every bit of information, hence every pixel ADDS TO NOISE,
> COMPLEXITY and  NEEDS TO BE PROCESSED by the receiver (user).
> Therefore, on the contrary plain space is goooood, it helps to keep
> the signal-to-noise ration on a acceptable level.
>
> By the way, you ask lots of hypothetical or philosophical questions
> :-) that could lead to endless discussion with great fun but little
> agreement.  Let's concentrate on the UX side of the concepts.
>
> Going through the feedback of hundreds (Impress) and thousands  who
> commented in our surveys, there no evidence that "space" or the
> location of the toolbars, or any format of the screen is of particular
> importance/problem to those who decided to give feedback in our
> surveys. Hence, despite us here on the lists and others who join the
> discussion elsewhere, there is actually very little validation that
> our users have significant difficluties with horizontal toolbars in
> 16:9 or 16:10 screens.
To show the so called "wasted space" the user needed to maximize the
window, since the window opens to a 4:3 ratio by default. That could be
why there's no comments about it. I know that if I use Impress I
maximize it always, for that matter all OOo programs are maximized by
default.

See a screen capture of the latest prototype on my 16:9 20" screen :

    * The opening variant:
      http://www.4shared.com/file/129872875/d16153fb/Variant1.html
    * The one loosing the least amount of space:
      http://www.4shared.com/file/129877405/a0e4cc6a/Variant3.html
    * The one I think works the best (of these variants) on my screen:
      http://www.4shared.com/file/129879409/498df772/ScrollVariant1.html

As you can see there's significant space not used at all either side of
the presentation page. But more importantly, see the blank space in the
top tabbed ribbon. The Scrolling version has less "wasted" space in the
tab panel itself, seeing as more than one tab is shown at once. This is
where I derived my suggestion of collapsible panels. While the scrolling
version makes full use of the area, it does so by simply placing
consecutive panels next to each other - irrespective of what action the
user is busy with. To figure out which panels need to open together is a
near impossible task, since the UX team would need to think of each and
every possible scenario in which a user may find himself. Therefore I'd
simply have the last opened panel visible next to the currently open
panel, to make it easier for the user to see which - it would even be an
idea to highlight the tabs of which the panels are visible.

There is absolutely no reason why the tabbed panels can't be placed as
sidebars either: Each tabbed panel has several sub-groups so these could
form the "lines" in the sidebar.

Regards Irné Barnard




---------------------------------------------------------------------
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] Re: [ux-user interface] Sidepanes --- Why don't be honest about it? --- Some real arguments

Cor Nouws
In reply to this post by Andreas Bartel
Hi Andreas, *,

Thanks to you and all others for the (detailed) q & a's (and round trips
;-) ).

But I get the impression that it is a bit too much black-white
discussion: OpenOffice.org does have an interface that is partly
vertical oriented. Stylist, Navigator, other panes in Draw and Impress,
Formula list in Calc ... The only point seems to be about possible
changes in the current tool bars.
OK, so look at that, with just facts about usability, and pls don't
disturb me any longer with v* versus h* ;-)

By the way: I like the concept from IBM with panes. Any change that it
can be (partially) combined in a next prototype?

Another still not answered question (will ask again if needed - do I
need to point to my earlier mails about this): what about promoting the
use of styles, making use of those easier, more visible. So enhancing an
already strong point of our product and benefiting from that. What ideas
do exist for that?

Thanks to all for the answers, ideas and gOOod work,
Cor



Andreas Bartel wrote (3-9-2009 17:21)
> going through my own reply I recognized that my statements about screen
> real estate might lead to misunderstandings. I guess we all AGREE that
> in certain conditions the distribution of UI elements in the current
> [...]


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

Reply | Threaded
Open this post in threaded view
|

Re: Re: [ux-discuss] Re: [ux-user interface] Sidepanes --- Why don't be honest about it? --- Some real arguments

Brian Fleeger
In reply to this post by Andreas Bartel
Hi Andreas,

Sorry for my confusion about constituents, I am a political science junky and automatically thought you were talking about users (like voters)!  Also, I did not go into too great a detail about what I foresaw as the benefits of "v" vs. "h" just because I think they have been outlined by others and I felt I would not contribute anything to the discussion by simply repeating.  I won't do it now either, since I think people are getting tired.  Both sides of this discussion think they have answered the questions of the other side, and believe the other side is being irrational.  

There is a lot of cross-talk going on, and emotions and egos of a lot of people have been hurt for no reason.  I know I would feel bad if I found out there was a petition telling me I should stop working and go home!   You guys are really doing great work.  This is the point in the conversation where, if we were all face to face, I
would hope everyone just shook hands and maybe we could have a drink
;-)  

My final conclusion is that I think the IBM proposal has a lot of
interesting potential, and I sincerely hope your two groups can have a
productive discussion and maybe integrate a side panel in some way.  That's just
my preference, and clearly the preferences of many others too.  But I also think you direct OO.o developers, and everyone else
participating in this long and tiring discussion, are worthy of a lot
of respect.  You have been very patient, and are not obligated to be as open as you have been in this process.

Best Regards,
Brian




________________________________
From: Andreas Bartel <[hidden email]>
To: [hidden email]
Cc: [hidden email]
Sent: Thursday, September 3, 2009 11:21:49 AM
Subject: [ux-user interface] Re: [ux-discuss] Re: [ux-user interface] Sidepanes --- Why don't be honest about it? --- Some real arguments

Hi again,

going through my own reply I recognized that my statements about screen real estate might lead to misunderstandings. I guess we all AGREE that in certain conditions the distribution of UI elements in the current interface is "problematic" in a sence that it comsumes a lot of space that otherwise would be available for the content of a document, be it slides, pages or sheets.

Hence, one current usablity bug is certainly the condition that there is often not enough room for the things the users actually focus on, namely, the content they wish to create. However, there is little evidence that this problem significanlty varies between different screen formats (not size). It's more or less an omnipresent problem that needs to be addressed.

Best,
Andreas

Andreas Bartel schrieb:

> Hi there,
>
> OK, quick quick quick answers:
>
> Brian Fleeger schrieb:
>> Andreas Bartel wrote (in response to Johannes Eva):
>> <Hi Johannes,
>> <finally, someone! Thank you!
>> [snip...]
>> <People change, users change etc. I could go on here to the level of
>> <brain plasticity but that is not the point. The point is that if we
>> <induce a major change in the UI by transforming something from
>> <horizontal to vertical, hence by just moving something from A to B, IT
>> <JUST HAS TO BE WORTH GOING THROUGH THE PAIN OF ADAPTATION. Overall, this
>> <would require same learning processes to start working as in the changes
>> <present in the current prototype or in the UI transition fron MSO 2003
>> <to MSO 2007.
>> <So, let's summarize insights:
>> <1. Tranferring the location where users can access commands from
>> <horizontal to vertical, hence from toolbars to a sidepane, is a major
>> <change.
>> <2. Users can adapt to that change.
>> <3.1 Adaptation always involves some sort of individual change or "pain"
>> <that is perceived in many ways by all kinds of users (see blog comments
>> <;-) )
>> <3.2 Some users like change and other clearly DON'T
>>
>> Really an excellent point about people hating change, especially in
>> reference to the suggested changes to OO.o itself.  However, I would
>> argue that the comments in retaliation against the Java mockups were not based on resistance to change per se.  Reading
>> the comments, even those critics who called for a halt to all UI work
>> did so mostly out of resentment of OO.o's imitation (real or perceived)
>> of Microsoft Office.  This means that this particular example is less
>> about resisting change and more about OO.o's market and brand
>> identity.
>> <4. The reward going through the pain of adaptation must be higher than
>> <the threshold of not willing to adapt
>> <Now back to you. I'd like you or anyone else to consider the following
>> <questions:
>> <1. What are the current problems of the overall UI in OOo with all it's
>> <constituents?
>>
>> You mentioned OO.o's constituents, and therein lies some of the reason for the backlash -- who are OO.o's current constituents, and who does OO.o want to be its future constituents.  Its current constituents consist largely of technically savvy people who have chosen for either ideological or cost motivated reasons to use a free alternative to MS Office.  In the future, OO.o wants to expand its base, which by definition means that the ratio of ideologically motivated users will drop.  Therefore, OO.o needs to be pragmatic in how it caters to the next generation of users (this is my assessment of the reasoning anyway).
>>  
> Sorry, by constituents I ment the parts of the UI of OOo and all interactions.
>> I feel that a number of current users held high hopes when Project Renaissance was first announced that it would come up with a truly novel and superior UI, leapfrogging the competition.  When they saw the mockups, it was a shock on an emotional level, and probably threatened a lot of people's identities (as OO.o users, who specifically chose NOT to use Microsoft office).  But, I do acknowledge that OO.o is seeking to expand to a new constituency with Project Renaissance, moving beyond its base. I can understand the desire of the UX team to conform to the norms and conventions of design as defined by the dominant market holder -- that is why most hollywood movies tend to look similar and have similar plots, and
> Sorry, not true! We are not seeking any conformation with competition but INSTEAD looking at existing design patterns (tabs, side panes, menus, toolbars etc.) that can help us to actually IMPROVE interactions in OOo and solve real problems without too much change. Basically, it's all about the right level of trade-offs. Hence, FINDING A BALANCE BETWEEN NECESSARY CHANGE AND OFFERED VALUE is our goal. Nothing more or less.
>>  more and more coffee shops look like Starbucks.  But people also have to understand that by conforming too closely to established conventions (especially as defined by a highly controversial monopoly company), that is by-definition reducing diversity.  People can argue that OO.o has always been a copy of Office, but a lot of people actually dreamed it would evolve into something better.  So now, people are upset and angry for the same reason that there was rioting at the WTO conference in 1999, or that people sneer when they see a McDonalds in Beirut.  In some weird way, OO.o is engaged in a conflict not unlike the backlash against globalization.  Its current users (or at least a very vocal portion) just really don't want to see their
>>  desktop experience too homogenized. But to answer your question about constituents more directly, the problem with the UI currently is clearly the same problem that Microsoft had with Office2003 and prior editions, ie hard to find functions burried in menus, and unintuitive UI in general.  Further, the top-mounted horizontal mid-fidelity mockups do address many of these issues, just as Microsoft did with Office 2007.  But there are also unaddressed UI deficiencies in the current Office 2007 and 2010 layouts, and I don't think I need to repeat the arguments about saving space by using a vertical bar, or wasted space using horizontal on widescreens.  Again, I just want to reiterate, people are expecting more than imitation from OO.o.  Even though all cars have four wheels and an engine, I think there is more room for alternative UIs than what has been presented so far.  Really, its a compliment, because to a lot of people OO.o is like some kind of
 lofty dream of a post-monopolized world.

>>
>> <1.1 Do these problems apply to all users?
>>
>> Widescreens, yada yada... ;-)
>>
>> <1.2 Do these problems occur in all contexts?
>> <2. Is the growing number of 16:9 or 16:10 screens a current issue for OOo?
>> <2.1 Does the current UI lead to significant usability problems with
>> <these types of screens?
>>
>> Yup, sure do
>>  
> Please be more specific, what are these problems you consider to be really significant?
>> <2.2 Is a vertically aligned pane a solution?
>>
>> Yup
>>  
> Again, please specify.
>> <2.3 If so, then to which particular problem is that the solution?
>> <2.4 If so, does a vertical pane work equally well in all applications?
>>
>> This is a little bit of a trick question.  If the vertical plane is sub-optimal in some applications, cannot the same be said for the horizontal plane?
> Yes, but we don't have to change anything there, do we?
>>   Anyway, in my view they are as follows:
>> Writer -- would very much benefit from a vertical plane.  Just look at Johannes's mockups to see how much more room there is.
>> Impress -- Neutral.  Even when using a 16:9 slide layout, the preview column can be flipped on its side and laid on the bottom, also as shown in Johannes' drawings.
>> Calc -- Depends on usage data to which I do not have, ie are people using columns or rows more in Calc.  Personally, I use more rows (long long lists) so a vertical layout would be idea.  Other times, like when I do cost benefit projects or other cost models, I might need more columns.  But in my personal usage, I tend to go straight down more than sideways. <2.4 Is that the best solution we can think of?
>> <2.5 What might become more hard to use as a side effect?
>>
>> As above, Calc *may* suffer, but it depends on implementation.  For instance, in RedOffice 4, the side panel can be undocked and made into one big block of a floating panel, as well as redocked on either side.  A similar solution could mitigate these negative effects in a side panel for OO.o.
>>
>> <3. Are the users willing to accept the change?
>>
>> This question is impossible to answer if there is no mid-fidelity mockup for users to try and which could collect measurable usage data. <3.1 What do we offer that is so valuable that users are willing to go
>> <through the pain of adaptation?
>>
>> Potentially, in that other than the advantages others have outlined regarding space, a side panel would also provide differentiation and greater brand identity.  But does OO.o want its own brand identity, or is OO.o itself just a trojan horse in the larger chess game of corporate developers to get people to reduce their dependency on the Windows ecosystem?  I can't resist a little conspiracy theory every now and then! (I kid!!  I am OS agnostic) ;-)
>>  
> OK, you name space. I consider that a myth because there is plainly no evidence that "space" is currently such a hurdle that makes OOo harder to use. From a UX perspective there is no such thing as WASTE OF SPACE. Every bit of information, hence every pixel ADDS TO NOISE, COMPLEXITY and  NEEDS TO BE PROCESSED by the receiver (user). Therefore, on the contrary plain space is goooood, it helps to keep the signal-to-noise ration on a acceptable level.
>
> By the way, you ask lots of hypothetical or philosophical questions :-) that could lead to endless discussion with great fun but little agreement.  Let's concentrate on the UX side of the concepts.
>
> Going through the feedback of hundreds (Impress) and thousands  who commented in our surveys, there no evidence that "space" or the location of the toolbars, or any format of the screen is of particular importance/problem to those who decided to give feedback in our surveys. Hence, despite us here on the lists and others who join the discussion elsewhere, there is actually very little validation that our users have significant difficluties with horizontal toolbars in 16:9 or 16:10 screens.
>> <3.2 Do all users adapt to the change equally well?
>>
>> Trick question again.  All users do not adapt equally well, but the bigger question is to what *degree* different users adapt to change.  And without a prototype which could collect real, quantitative data, any answer to this question would be mere conjecture.
>>
>> <But currently, in our context, and to our project, what
>> <probably matters most are these two questions: "WHAT MAJOR PROBLEMS
>> <WOULD A VERTICAL PANE SOLVE NOW?" and "HOW WOULD <THAT CHANGE AFFECT THE MAJORITY OF OUR USERS?"
>> <[snip...] I think that you underestimate the importance and the impact of CONTEXT.
>> <Web is not desktop, office productivity is not prefessional graphics
>> <tools etc. Each context activates behavior (usage) petterns that fit
>> <that particular context. These patterns were shaped by a learning
>> <process and are stored as prior knowledge which is istantly activated,
>> <when certain perceptual cues appear, in order to trigger appropriate
>> <behavior. Humans are pattern matchers, constantly trying to apply things
>> <they've already learned in a given situation/context. Hence, a lot of
>> <user/usage "behavior" that is appropriate for the web might not be
>> <appropriate for the desktop (e.g. one click vs. double click on the
>> <mouse as a pure example). Consequently, these issues are pretty hard to
>> <assess. That is the reason why we always should keep in mind that
>> <transferring things that work in one context to another one is a tricky
>> <business. (NOT SAYING THAT IT IS NOT POSSIBLE AT ALL)
>>
>> When you speak of contexts, and of the importance of conforming to current desktop usage patterns, you more or less preclud the possibility of EVER making any user interface which is different in any significant way  from
> Again, you miss the point. I am really starting to wonder where you guys get the impression from that we don't want change? If that was so, we would not do the prototypes, would we?
>
> However, our main directive was and still is that IF WE DECIDE TO CHANGE ANYTHING it just has to be WORTH DOING IT. In plain English, we need to offer a great portion of VALUE (to a great deal of users) behind ANY CHANGE!
>
> That is as simple as that.
>
> Once again, we are not talking about vertical panes as being totally useless. But their benefit for the SOLE PURPOSE of offering the access to all commands is certainly limited, there is no clear significant advantage over a horizontal one. I agree that there are many other purposes for vertical panes that are beneficial, and I assure you that we will use this deisng pattern then.
>> Microsoft standards.  Not to offend, but that is the logical conclusion of your argument as I understand it.  As the monopoly holder, they will always define people's "desktop contexts."  But it is also important to remember that the desktop context that the current mockups are seeking to emulate is itself a relatively new cognitive mode.  That is, people's brains are still malleable having been forced to adapt from Office 2003 to Office 2007, so will likely be more likely to adapt more quickly to other new interface models -- should OO.o have the courage to present them and stand on its own two legs.
>>
>> <[snip...] OK, given that you have a limited insight and understanding of how the
>> <UX team works (maybe our fault), what skills are present and how we make
>> <decisions, you might get the impression that we do not consider obvious
>> <solutions cerefully enough.
>> I am also not a UI professional, other UI professionals (namely, from IBM) have concluded that a vertical panel is highly desirable, and that by itself, apart from all the arguments presented here, makes it worthy of greater consideration. Anyway, great read and I like this thread!
>>
>> Regards,
>> Brian
>>
>>  
> Thanks a lot, and "your turn" ;-)!
>
> Best,
> Andreas
>> <As my conclusion, thanks for the feedback!
>> <Best,
>> <Andreas
>>  
>>  
>>> (By the way, if someone wants to test RedOffice beta 4: I can send the archive of the beta, for Windows. I don't manage to get and install newer versions.)
>>>
>>>
>>> ***
>>>
>>>    
>>>> 2. So, since that change would induce as much confusion as any other change of such severity, it better should be really beneficial. If it
>>>>  does not significantly improve usability by a factor of X that is
>>>> worse going through the pain of relearning, then IT MAKES NO SENSE to
>>>> change that at all.      
>>> Well, I didn't see any publications of testings concerning the actual prototypes. I really don't know if and how they would be really beneficial, or more beneficial that a vertical design or some other features, taking in account that it would probably take 3-5 years of development.
>>>
>>> The most beneficial thing, according to the users themselves, can be found on slide 30 of this presentation:
>>> http://wiki.services.openoffice.org/w/images/1/11/Renaissance-status-2009-01-30_wiki.odp I often think, if we would think about the users, well, a lot of the energy would have to go to a better MSO 07/03 compatibility.
>>>
>>> And I don't see in 3.2 the ability to write OOXML, what a disappointment!
>>>
>>> I'm sorry, I'm off topic. But I don't have seen any publication of tests showing that some of the the prototypes would be better for the end users than the current UI. (Neither that vertical UIs to better or worse, of course.)
>>> It is really so beneficial that it justifies concentrating that much resources and energy on it? There are so many things that could be done in OOo...
>>>
>>>
>>>    
>>>> 2.1 Better use of screen real estate
>>>>
>>>> In addition, in a
>>>> vertical UI you are forced to either use some sort of an "ACCORDION",
>>>> "TABS or VERTICAL TABS" or a mixture of both. Using these controls
>>>> means that you loose a lot of vertical space, depending on the font
>>>> or icon size and the LANGUAGE (how about Finish), that is occupied by
>>>> the labels of tabs or accordion elements.      
>>> That's only true for some designs.
>>> I'm sorry to use my proposal again as an illustration, but it is not true in it. Neither it is in Office Mac 2008 or Apple pages. Again, how can you write your argument ignoring these?
>>>
>>> In this kind of design, the language and length of text is not very important neither:
>>> http://wiki.services.openoffice.org/w/images/5/5d/Mockup_fin22rev.png
>>> (from the proposal by Constantin Bürgi)
>>>
>>> And if you take a look at the last proposal by IBM (by the way, great proposal, great ideas! Better to me than actual Symphony versions!), it does not loose vertical space neither:
>>> http://wiki.services.openoffice.org/wiki/Sidebar_Proposal_by_IBM
>>>
>>> So how come you can affirm that a vertical design has to loose vertical space in this way?
>>> And again, many designd would work with any "length" of language.
>>>
>>>
>>>    
>>>> Therefore we would need to use
>>>> scrolling bars, especially on NETBOOKS where vertical space is
>>>> precious.      
>>> Need scrolling bars? Again, you are making curious affirmations, without argumenting them very well.
>>> The proposal by IBM, as well as mine, don't need vertical scrolling bars in general. Neither does RedOffice.
>>>
>>> With "in general", I mean that the sidepane does not need its own scrolling bar. Indeed some elements would need one, like the "styles & formatting" in this mockup:
>>> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png (yeah, I know, I use this one a lot, sorry!)
>>>
>>> And sorry to say this, but I fond scrolling bars in horizontal UI elements much more ridiculous. See Office 2007.
>>>
>>>    
>>>> Try to squeeze 340 commands into a sidepane of e.g. 75 x
>>>> 600 pixels size. Scrolling bars would again hide some commands, which
>>>> brings us back to the current problems. Overall, there is a tradeoff
>>>> between gaining and loosing screen real estate that cancels possible
>>>> improvements. Therefore, no obvious significant step forward towards
>>>> a solution.
>>>>      
>>> First, I am very disappointed, because your arguments show that you did never really consider the option of a vertical UI. It seems that you are bringing mostly personal arguments, without a "testing" base.
>>>    
>>>> e.g. 75 x 600 pixels size
>>>>      
>>> I know, "e.g."... but at least 200 pixels width are standard.
>>> See:
>>> http://wiki.services.openoffice.org/w/images/c/c3/Martinu_-_Sidebar_Width_in_different_Office_Suites_applications.png 
>>> Let's have numbers. In 800x600,
>>> Prototype 0.16 :
>>> 800x125= 100000
>>>
>>> This mockup:
>>> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 207x488= 101016
>>>
>>> I have to agree, 800x600 is not a smart choice, but as you can see, the space for the UI is the same (it may very a little, depending how you calculate it). And without scrolling bars, of course, why did you get the idea that these would be needed?
>>>
>>> ***
>>>
>>> Now, is there enough space for commands, even in 600 pixels height, with a vertical design? Here is the answer:
>>>
>>> I would like you to look again at this mockup I made, with a 800x600 pixels resolution. These are about 50 commands on one side pane, many (22) of them with text+icon.
>>> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png 
>>> Now count how much commands there are on the "start" tab of the 0.16 prototype: about 25, half as much. 11 with text, also half as much.
>>> The "format" tab has the most commands in the 0.16 prototype, and these are only 27. Note that the text is smaller in the prototypes that in my mockups.
>>> (I know, it's only a prototype, ...)
>>>
>>> One more thing. I have space for 9 "tabs" in my proposal. (with vertical icon tabs as in the IBM design, there would be space for as many as one would like.)
>>> If we have the same amount of commands for each tab, about 50, there is a possibility of 450 commands, many of them with full text.
>>> With 600 pixels height.
>>>
>>> I admit that it is the "most optimistic" method to calculate, but still... you were speaking of 340, my result is that there would be space for 450, with 600 pixels height.
>>>
>>> Conclusion: in any case, even with a less optimistic calculation, there is enough space in a well made vertical UI. And this, without "eating" the vertical space of a netbook, as does a "ribbon" design.
>>>
>>>
>>> To conclude this point, I was really disappointed to see that you insist on saying that there would be not enough space in a vertical UI, without really trying it.
>>>
>>>
>>>    
>>>> --> Most of us who think of a presentation applications, or slides
>>>> and NETBOOKS in particular, also think of 16:9 or 16:10 screen
>>>> formats. But most of us remain with the thought that the SLIDES are
>>>> 4:3. Currently that might be true, which is also a pure ASSUMPTION,
>>>> but that will certainly change rapidly since presenters start to
>>>> support more the formats of laptop and netbook screen ratios. WHAT
>>>> WILL HAPPEN THEN??? Slides that resemble the screen ration on a 16:9
>>>> or even 16:10 screen use MORE screen real estate. That makes a
>>>> vertical UI less efficient concerning screen real estate usage.
>>>>      
>>> Once again, you are saying something very strongly, but didn't tried it out...
>>> I was almost about to say "I didn't think about this" and "you're right", but then I tried it out. And here is a mockup:
>>> http://dl.getdropbox.com/u/173771/Martinu%20-%20General%20Mockup%2011%20-%20Writer%20in%201366x768%20-%20NEW%20MOCKUP%20WITH%2016%209%20slides.png (with a 16:9 slide on a 16:9 screen)
>>>
>>> In fact, it works very well, even with 2 sidebars, as in the mockup!
>>> (The other solution, with one sidebar only, and the slides overview on the bottom, has even more space for 16:9 slides.)
>>>
>>> Conclusion: the argument of the 16:9 slides invalidating the usefulness of a vertical UI is not valid, sorry.
>>>
>>>
>>>    
>>>> --> "Everyone works in full-screen mode". That is a possibility but a
>>>>  PURE ASSUMPTION. Having a big wide-screen does not necessarily mean
>>>> that EVERYONE on the planet has the same usage patterns regarding
>>>> that screen. On the contrary, it might often be the case that users
>>>> work with several apps in parallel and reduce the windows of the
>>>> apps. As long as we do not have any evidence, we should not develop
>>>> for that use case SOLELY. Meaning, NO FOCUS on anything that works
>>>> best in full-screen only.
>>>>      
>>> It would also be pure assumption to imagine that people maximize the windows vertically, thus making the waste of vertical space in a "ribbon" UI even worse. This is not specially an argument against vertical UIs.
>>>
>>> As you could see in my mockups, but also in those of the IBM proposal, a vertical UI really works well also in small resolutions.
>>> And don't forget that most users use Word, with a "portrait" page.
>>> (I don't say all do, but most of them.)
>>>
>>>
>>>    
>>>> --> "Sidepanes work well in Writer" That might be true. However, it
>>>> is not evident for Impress and certainly not for Calc where sheet
>>>> content is the essence of the app. Steeling 3 columns might be a lot
>>>> worse than steeling 3 rows.      
>>> Well, I already posted my mockup of Impress with 2 sidepanes.
>>> I already posted a message about the Calc argument.
>>> So here it is again: your argument about rows being more important than columns works well in 4:3 resolutions, but again, doesn't apply in 16:9.
>>> Here is a screenshot of Calc in 1920x1080. I pasted a random sidebar to have an idea of the relative width.
>>> /media/Kakemphaton/Johannes/Dropbox/Dropbox/Public/OOo_calc_1920x1080.png
>>>
>>> Do you REALLY think that the lost space due to the sidepane is still relevant in 16:9 resolutions?
>>>
>>> ***
>>>
>>>
>>> A last small thing: the marvelous thing about the ribbons in Office 2007 is how they scale to the size of the window. There are many dynamic elements that adapt their size. I don't see this in the prototypes - yes I know, these are only prototypes.
>>>
>>> Once more, I find a vertical UI very suited for these kind of auto-scaling elements. Take for example this mockup, which I'm really sorry to link here for the 10000th time!
>>> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png 
>>> Well, the "styles and formatting" element at the bottom would scale to all resolutions, displaying more or less lines.
>>> I miss this in the prototypes, the "ribbon" style UI makes no sense without this scalability.
>>>
>>>
>>> Note that the current toolbars in 3.x could be made scalable also, playing with the text labels, as described here:
>>> http://wiki.services.openoffice.org/wiki/Proposal_by_Johannes_Eva#14.1_More_about_toolbars 
>>>
>>> ***
>>>
>>>
>>>    
>>>> So overall, neither me nor anyone else from the UX team is opposing or promoting that particular design pattern. As the matter of fact, we are not religious about any UI design pattern.
>>>>
>>>> First, we never attempted to remove sidepanes completely. Hence, in some contexts sidepanes might appear. However, our design strategy is to remain horizontal for the access of all commands.
>>>>       In sum, it is very likely that you will not see a vertical toolbar for accessing all commands as the main location. However, you might see that design patterns for other purposes and in different contexts. That really depends on the app and on the task.
>>>>      
>>> Honestly, I am just chocked by this overall hypocrisy. Really. First say things like "we are not religious about any design pattern" or "the prototypes are only prototypes", or "we don't need prototypes of vertical UIs, we have Symphony", and pretending being open.
>>>
>>> And then, it was the feeling I and some other people had, thank you for saying it out loud, already having chosen that the design won't be vertical.
>>>
>>> Without having tested it seriously.
>>>
>>> Despite a lot of people, not only me, speaking in favor of vertical UIs. I would say, despite of the modern monitor format speaking for vertical UIs.
>>>
>>> I mean, did you really read more than 10 comments from the last GullFOSS blog posts, what they say? Not all are rude and dumb, many smart people out there. A lot of them for vertical UIs.
>>>
>>> And then, you post some unverified arguments and explanations telling why you have already chosen that the UI would be not vertical.
>>> Where are the real usability studies?
>>>
>>> "Create a User Interface so that OpenOffice.org becomes *the users' choice* not only out of need, but also out of desire."
>>> I don't believe in it anymore. Saying "we are open", and then not be really open, but stuck in old ideas and designs, despite of the public opinion being that brutal against it: that's not being open.
>>>
>>>
>>>
>>> ***
>>>
>>> I know my words are harsh, and I'm sorry about it. And I'm sorry speaking only to you, Andreas, I don't know which other persons are behind what is for me a "hypocrisy".
>>>
>>> And I also know that you, the team behind OOo, don't have the resources you would need and you deserve to do it as well as it should be done. I'm sorry for it.
>>>
>>> But this is a reason more for not putting OOo in danger, sucking a lot of its resources in a project that should not be, at least to me, the main priority, and that would last many many years, and that started so baldy, at least in the public opinion.
>>>
>>> Are you aware that if Renaissance fails, this could be the death of OOo as a sucessful project? I take so much time to write about this, because I am really worried about all this.
>>>
>>> All the best, really, to you and OOo,
>>> Johannes
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>>
>>        
>
>


-- *********************************************************************

Sun Microsystems GmbH                Andreas Bartel
Nagelsweg 55                         User Experience Engineer
20097 Hamburg                        Phone: (+49 40)23646 672
Germany                              Fax:   (+49 40)23646 550
http://www.sun.com                   mailto:[hidden email]

*********************************************************************

Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring


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


Reply | Threaded
Open this post in threaded view
|

Re: Sidepanes --- Why don't be honest about it? --- Some real arguments

Andreas Schuderer
In reply to this post by Johannes Eva
Hi Johannes,

I fully agree with the points you've made.

I think that, before challenging YOU to do it, Andreas Bartel should  
answer his own questions himself first:

> 1. What are the current problems of the overall UI in OOo with all  
> it's constituents?
> 1.1 Do these problems apply to all users?
> 1.2 Do these problems occur in all contexts?
>
> 2. Is the growing number of 16:9 or 16:10 screens a current issue  
> for OOo?
> 2.1 Does the current UI lead to significant usability problems with  
> these types of screens?
> 2.2 Is a vertically aligned pane a solution?
> 2.3 If so, then to which particular problem is that the solution?
> 2.4 If so, does a vertical pane work equally well in all applications?
> 2.4 Is that the best solution we can think of?
> 2.5 What might become more hard to use as a side effect?
>
> 3. Are the users willing to accept the change?
> 3.1 What do we offer that is so valuable that users are willing to  
> go through the pain of adaptation?
> 3.2 Do all users adapt to the change equally well?


(In his answer, replacing "vertical" with "horizontal tabbed toolbar".)

This would at least give /a little/ insight into SUN's motivation of  
following their apparently favoured approach. Right now, it's a black  
box which is being ratonalized re-using the same old weak arguments  
that have already been demolished again* and again. But this doesn't  
seem to keep anyone from repeating them (let alone - gasp! - deal with  
them on content level).

*) e.g. in my reaction to a posting by Frank Loehmann:
http://ux.openoffice.org/servlets/ReadMsg?list=ui&msgNo=823

Andreas

Am 2. Sep 2009 um 23:14 schrieb Johannes Eva:

> Hi Andreas and everybody!
>
> thanks Andreas for this answer, I have been waiting for arguments  
> against sidebars/sidepanes for a while now, to try to understand why  
> the possibility of a vertical UI is not taken seriously.
>
> To say it immediately, I am not convinced by your arguments, and I  
> will try to explain why.
>
>
>> 1. In general, changing from horizontal to vertical tabs/toolbars  
>> whatsoever is a major modification that also breaks with a lot of
>> habits computer users have been gaining in the last 30 years. That is
>> a fact. Usually, everyone expects commands to be located at the top
>> of the screen. That is similar to entering a room (in a building, on
>> earth, in our century) and looking for a window. Where would you look
>> or expect a window to be? Certainly the wall would be the first place
>> a window might appear. Not the roof, although possible, and certainly
>> not the floor.
> Remember Myth #9:
> http://carsonified.com/blog/design/top-10-ux-myths/
> (I don't remember who posted it, but thank you!)
>
> I'll give you another example (excuse my English for this one, I  
> don't have the specific vocabulary I would need to be more clear).
> Here is a picture of my oven, in the kitchen:
> http://dl.getdropbox.com/u/173771/CIMG3324.JPG
>
> As with all ovens and cooking plates I have had in my short life  
> (that's about   a dozen because I move a lot) I remember that I  
> always had the same "problem": the buttons to switch the cooking  
> plates are not "on" the working space beside the cooking plate, but  
> under the hangover, on the vertical side.
>
> So when I have to switch a plate on, I have to bend down to find the  
> correct button for the correct plate I want to switch on.
> If it would be on top, I would see the buttons better, and would not  
> need to bend down to use them.
>
> To me it is clearly a design mistake, but the majority of ovens I  
> have seen in my life are like this.
> So, two remarks about this:
> 1. the majority is not always the best design.
> 2. Do you think I would get used to the buttons place if they would  
> be "on" the table beside the cooking plates, instead under the  
> hangover?
> I think anyone would get used to it very fast.
>
>
> To go back to the UI Myth #9. I think users can adapt, and that your  
> argument about "since 30 years" is wrong. For 30 years, we had 4:3  
> screens, now almost all new displays are 16:9. Things change, but  
> UIs shoudn't?.
>
> Many people on the mailing list have already given a ton of examples  
> of UIs with vertical designs or vertical elements, definitely  
> proving that users are already used to vertical designs. iTunes, or  
> even the standard menu of gmail to cite only two. These applications  
> don't seem to be a problem to billions of users. I don't think that  
> OOo users are dumber than average.
>
> Another argument: in the era of the web, users are used to browse on  
> a quantity of websites, all of them having different layouts: menu  
> layouts, organisation, etc. In many cases, the structure is  
> vertical, or vertical + horizontal. Nowadays, people are used to  
> change, because that's what they do everyday on the web. If the UI  
> is good and well tested, let it be horizontal or vertical, people  
> will adapt, really.
>
>
> One more argument: you insist that for 30 years the menus have been  
> on top of the screen, and it would be difficult to some users to  
> adapt, and find elements, for example, on a left vertical sidepane.
> Pure supposition, and there is no vertical design planned. But see;
> http://carsonified.com/blog/design/top-10-ux-myths/
>
> I tried it. Yesterday night we had guests, so I asked 5 persons, all  
> musicians and not technically gifted at all, to point on the screen  
> how they would do following actions in the following mockup:
> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png
> - save
> - change font, and font size
> - center paragraph
> - copy and paste
>
> ALL of them found it immediately. And they seemed to be very at ease  
> with the vertical sidepane. (two of them wondered about the styles  
> at the bottom, "so here you can change the font, too?")
>
> I admit my testing is quite light, on the same type of basic users  
> and basic commands. But it is still better that pretending something  
> without even doing this most basic testing.
>
> As a conclusion, I don't know how you can pretend that people would  
> have difficulties to adapt to a vertical design, without testing it.  
> And also continually ignore existing software with vertical UIs.
>
>
> (By the way, if someone wants to test RedOffice beta 4: I can send  
> the archive of the beta, for Windows. I don't manage to get and  
> install newer versions.)
>
>
> ***
>
>> 2. So, since that change would induce as much confusion as any  
>> other change of such severity, it better should be really  
>> beneficial. If it
>> does not significantly improve usability by a factor of X that is
>> worse going through the pain of relearning, then IT MAKES NO SENSE to
>> change that at all.
> Well, I didn't see any publications of testings concerning the  
> actual prototypes. I really don't know if and how they would be  
> really beneficial, or more beneficial that a vertical design or some  
> other features, taking in account that it would probably take 3-5  
> years of development.
>
> The most beneficial thing, according to the users themselves, can be  
> found on slide 30 of this presentation:
> http://wiki.services.openoffice.org/w/images/1/11/Renaissance-status-2009-01-30_wiki.odp
> I often think, if we would think about the users, well, a lot of the  
> energy would have to go to a better MSO 07/03 compatibility.
>
> And I don't see in 3.2 the ability to write OOXML, what a  
> disappointment!
>
> I'm sorry, I'm off topic. But I don't have seen any publication of  
> tests showing that some of the the prototypes would be better for  
> the end users than the current UI. (Neither that vertical UIs to  
> better or worse, of course.)
> It is really so beneficial that it justifies concentrating that much  
> resources and energy on it? There are so many things that could be  
> done in OOo...
>
>
>> 2.1 Better use of screen real estate
>> In addition, in a
>> vertical UI you are forced to either use some sort of an "ACCORDION",
>> "TABS or VERTICAL TABS" or a mixture of both. Using these controls
>> means that you loose a lot of vertical space, depending on the font
>> or icon size and the LANGUAGE (how about Finish), that is occupied by
>> the labels of tabs or accordion elements.
> That's only true for some designs.
> I'm sorry to use my proposal again as an illustration, but it is not  
> true in it. Neither it is in Office Mac 2008 or Apple pages. Again,  
> how can you write your argument ignoring these?
>
> In this kind of design, the language and length of text is not very  
> important neither:
> http://wiki.services.openoffice.org/w/images/5/5d/Mockup_fin22rev.png
> (from the proposal by Constantin Bürgi)
>
> And if you take a look at the last proposal by IBM (by the way,  
> great proposal, great ideas! Better to me than actual Symphony  
> versions!), it does not loose vertical space neither:
> http://wiki.services.openoffice.org/wiki/Sidebar_Proposal_by_IBM
>
> So how come you can affirm that a vertical design has to loose  
> vertical space in this way?
> And again, many designd would work with any "length" of language.
>
>
>> Therefore we would need to use
>> scrolling bars, especially on NETBOOKS where vertical space is
>> precious.
> Need scrolling bars? Again, you are making curious affirmations,  
> without argumenting them very well.
> The proposal by IBM, as well as mine, don't need vertical scrolling  
> bars in general. Neither does RedOffice.
>
> With "in general", I mean that the sidepane does not need its own  
> scrolling bar. Indeed some elements would need one, like the "styles  
> & formatting" in this mockup:
> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png
> (yeah, I know, I use this one a lot, sorry!)
>
> And sorry to say this, but I fond scrolling bars in horizontal UI  
> elements much more ridiculous. See Office 2007.
>
> > Try to squeeze 340 commands into a sidepane of e.g. 75 x
>> 600 pixels size. Scrolling bars would again hide some commands, which
>> brings us back to the current problems. Overall, there is a tradeoff
>> between gaining and loosing screen real estate that cancels possible
>> improvements. Therefore, no obvious significant step forward towards
>> a solution.
> First, I am very disappointed, because your arguments show that you  
> did never really consider the option of a vertical UI. It seems that  
> you are bringing mostly personal arguments, without a "testing" base.
> > e.g. 75 x 600 pixels size
> I know, "e.g."... but at least 200 pixels width are standard.
> See:
> http://wiki.services.openoffice.org/w/images/c/c3/Martinu_-_Sidebar_Width_in_different_Office_Suites_applications.png
>
> Let's have numbers. In 800x600,
> Prototype 0.16 :
> 800x125= 100000
>
> This mockup:
> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png
> 207x488= 101016
>
> I have to agree, 800x600 is not a smart choice, but as you can see,  
> the space for the UI is the same (it may very a little, depending  
> how you calculate it). And without scrolling bars, of course, why  
> did you get the idea that these would be needed?
>
> ***
>
> Now, is there enough space for commands, even in 600 pixels height,  
> with a vertical design? Here is the answer:
>
> I would like you to look again at this mockup I made, with a 800x600  
> pixels resolution. These are about 50 commands on one side pane,  
> many (22) of them with text+icon.
> http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3_-_800x600_Full_home_sidebar.png
>
> Now count how much commands there are on the "start" tab of the 0.16  
> prototype: about 25, half as much. 11 with text, also half as much.
> The "format" tab has the most commands in the 0.16 prototype, and  
> these are only 27. Note that the text is smaller in the prototypes  
> that in my mockups.
> (I know, it's only a prototype, ...)
>
> One more thing. I have space for 9 "tabs" in my proposal. (with  
> vertical icon tabs as in the IBM design, there would be space for as  
> many as one would like.)
> If we have the same amount of commands for each tab, about 50, there  
> is a possibility of 450 commands, many of them with full text.
> With 600 pixels height.
>
> I admit that it is the "most optimistic" method to calculate, but  
> still... you were speaking of 340, my result is that there would be  
> space for 450, with 600 pixels height.
>
> Conclusion: in any case, even with a less optimistic calculation,  
> there is enough space in a well made vertical UI. And this, without  
> "eating" the vertical space of a netbook, as does a "ribbon" design.
>
>
> To conclude this point, I was really disappointed to see that you  
> insist on saying that there would be not enough space in a vertical  
> UI, without really trying it.
>
>
>> --> Most of us who think of a presentation applications, or slides
>> and NETBOOKS in particular, also think of 16:9 or 16:10 screen
>> formats. But most of us remain with the thought that the SLIDES are
>> 4:3. Currently that might be true, which is also a pure ASSUMPTION,
>> but that will certainly change rapidly since presenters start to
>> support more the formats of laptop and netbook screen ratios. WHAT
>> WILL HAPPEN THEN??? Slides that resemble the screen ration on a 16:9
>> or even 16:10 screen use MORE screen real estate. That makes a
>> vertical UI less efficient concerning screen real estate usage.
> Once again, you are saying something very strongly, but didn't tried  
> it out...
> I was almost about to say "I didn't think about this" and "you're  
> right", but then I tried it out. And here is a mockup:
> http://dl.getdropbox.com/u/173771/Martinu%20-%20General%20Mockup%2011%20-%20Writer%20in%201366x768%20-%20NEW%20MOCKUP%20WITH%2016%209%20slides.png
> (with a 16:9 slide on a 16:9 screen)
>
> In fact, it works very well, even with 2 sidebars, as in the mockup!
> (The other solution, with one sidebar only, and the slides overview  
> on the bottom, has even more space for 16:9 slides.)
>
> Conclusion: the argument of the 16:9 slides invalidating the  
> usefulness of a vertical UI is not valid, sorry.
>
>
>> --> "Everyone works in full-screen mode". That is a possibility but a
>> PURE ASSUMPTION. Having a big wide-screen does not necessarily mean
>> that EVERYONE on the planet has the same usage patterns regarding
>> that screen. On the contrary, it might often be the case that users
>> work with several apps in parallel and reduce the windows of the
>> apps. As long as we do not have any evidence, we should not develop
>> for that use case SOLELY. Meaning, NO FOCUS on anything that works
>> best in full-screen only.
> It would also be pure assumption to imagine that people maximize the  
> windows vertically, thus making the waste of vertical space in a  
> "ribbon" UI even worse. This is not specially an argument against  
> vertical UIs.
>
> As you could see in my mockups, but also in those of the IBM  
> proposal, a vertical UI really works well also in small resolutions.
> And don't forget that most users use Word, with a "portrait" page.
> (I don't say all do, but most of them.)
>
>
>> --> "Sidepanes work well in Writer" That might be true. However, it
>> is not evident for Impress and certainly not for Calc where sheet
>> content is the essence of the app. Steeling 3 columns might be a lot
>> worse than steeling 3 rows.
> Well, I already posted my mockup of Impress with 2 sidepanes.
> I already posted a message about the Calc argument.
> So here it is again: your argument about rows being more important  
> than columns works well in 4:3 resolutions, but again, doesn't apply  
> in 16:9.
> Here is a screenshot of Calc in 1920x1080. I pasted a random sidebar  
> to have an idea of the relative width.
> /media/Kakemphaton/Johannes/Dropbox/Dropbox/Public/
> OOo_calc_1920x1080.png
>
> Do you REALLY think that the lost space due to the sidepane is still  
> relevant in 16:9 resolutions?
>
> ***
>
>
> A last small thing: the marvelous thing about the ribbons in Office  
> 2007 is how they scale to the size of the window. There are many  
> dynamic elements that adapt their size. I don't see this in the  
> prototypes - yes I know, these are only prototypes.
>
> Once more, I find a vertical UI very suited for these kind of auto-
> scaling elements. Take for example this mockup, which I'm really  
> sorry to link here for the 10000th time!
> http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_10_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png
>
> Well, the "styles and formatting" element at the bottom would scale  
> to all resolutions, displaying more or less lines.
> I miss this in the prototypes, the "ribbon" style UI makes no sense  
> without this scalability.
>
>
> Note that the current toolbars in 3.x could be made scalable also,  
> playing with the text labels, as described here:
> http://wiki.services.openoffice.org/wiki/Proposal_by_Johannes_Eva#14.1_More_about_toolbars
>
>
> ***
>
>
>> So overall, neither me nor anyone else from the UX team is opposing  
>> or promoting that particular design pattern. As the matter of fact,  
>> we are not religious about any UI design pattern.
>> First, we never attempted to remove sidepanes completely. Hence, in  
>> some contexts sidepanes might appear. However, our design strategy  
>> is to remain horizontal for the access of all commands.
>
>> In sum, it is very likely that you will not see a vertical toolbar  
>> for accessing all commands as the main location. However, you might  
>> see that design patterns for other purposes and in different  
>> contexts. That really depends on the app and on the task.
>
> Honestly, I am just chocked by this overall hypocrisy. Really. First  
> say things like "we are not religious about any design pattern" or  
> "the prototypes are only prototypes", or "we don't need prototypes  
> of vertical UIs, we have Symphony", and pretending being open.
>
> And then, it was the feeling I and some other people had, thank you  
> for saying it out loud, already having chosen that the design won't  
> be vertical.
>
> Without having tested it seriously.
>
> Despite a lot of people, not only me, speaking in favor of vertical  
> UIs. I would say, despite of the modern monitor format speaking for  
> vertical UIs.
>
> I mean, did you really read more than 10 comments from the last  
> GullFOSS blog posts, what they say? Not all are rude and dumb, many  
> smart people out there. A lot of them for vertical UIs.
>
> And then, you post some unverified arguments and explanations  
> telling why you have already chosen that the UI would be not vertical.
> Where are the real usability studies?
>
> "Create a User Interface so that OpenOffice.org becomes *the users'  
> choice* not only out of need, but also out of desire."
> I don't believe in it anymore. Saying "we are open", and then not be  
> really open, but stuck in old ideas and designs, despite of the  
> public opinion being that brutal against it: that's not being open.
>
>
>
> ***
>
> I know my words are harsh, and I'm sorry about it. And I'm sorry  
> speaking only to you, Andreas, I don't know which other persons are  
> behind what is for me a "hypocrisy".
>
> And I also know that you, the team behind OOo, don't have the  
> resources you would need and you deserve to do it as well as it  
> should be done. I'm sorry for it.
>
> But this is a reason more for not putting OOo in danger, sucking a  
> lot of its resources in a project that should not be, at least to  
> me, the main priority, and that would last many many years, and that  
> started so baldy, at least in the public opinion.
>
> Are you aware that if Renaissance fails, this could be the death of  
> OOo as a sucessful project? I take so much time to write about this,  
> because I am really worried about all this.
>
> All the best, really, to you and OOo,
> Johannes
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: Sidepanes --- Why don't be honest about it? --- Some real arguments

Benoit Lamarche-2
To echo Andreas comments, I find the design presented here:

http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_1
0_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png

one of the most elegant I've ever seen. And it seems functional to boot.
Mozilla, Red Flag Office and even Symphony have interesting GUI elements
that could leveraged from a concept standpoint.

-----Original Message-----
From: Andreas Schuderer [mailto:[hidden email]]
Sent: Tuesday, October 13, 2009 10:31 AM
To: [hidden email]
Subject: Re: [ux-user interface] Sidepanes --- Why don't be honest about it?
--- Some real arguments

Hi Johannes,

I fully agree with the points you've made.

I think that, before challenging YOU to do it, Andreas Bartel should  
answer his own questions himself first:

> 1. What are the current problems of the overall UI in OOo with all  
> it's constituents?
> 1.1 Do these problems apply to all users?
> 1.2 Do these problems occur in all contexts?
>
> 2. Is the growing number of 16:9 or 16:10 screens a current issue  
> for OOo?
> 2.1 Does the current UI lead to significant usability problems with  
> these types of screens?
> 2.2 Is a vertically aligned pane a solution?
> 2.3 If so, then to which particular problem is that the solution?
> 2.4 If so, does a vertical pane work equally well in all applications?
> 2.4 Is that the best solution we can think of?
> 2.5 What might become more hard to use as a side effect?
>
> 3. Are the users willing to accept the change?
> 3.1 What do we offer that is so valuable that users are willing to  
> go through the pain of adaptation?
> 3.2 Do all users adapt to the change equally well?


(In his answer, replacing "vertical" with "horizontal tabbed toolbar".)

This would at least give /a little/ insight into SUN's motivation of  
following their apparently favoured approach. Right now, it's a black  
box which is being ratonalized re-using the same old weak arguments  
that have already been demolished again* and again. But this doesn't  
seem to keep anyone from repeating them (let alone - gasp! - deal with  
them on content level).

*) e.g. in my reaction to a posting by Frank Loehmann:
http://ux.openoffice.org/servlets/ReadMsg?list=ui&msgNo=823

Andreas

Am 2. Sep 2009 um 23:14 schrieb Johannes Eva:

> Hi Andreas and everybody!
>
> thanks Andreas for this answer, I have been waiting for arguments  
> against sidebars/sidepanes for a while now, to try to understand why  
> the possibility of a vertical UI is not taken seriously.
>
> To say it immediately, I am not convinced by your arguments, and I  
> will try to explain why.
>
>
>> 1. In general, changing from horizontal to vertical tabs/toolbars  
>> whatsoever is a major modification that also breaks with a lot of
>> habits computer users have been gaining in the last 30 years. That is
>> a fact. Usually, everyone expects commands to be located at the top
>> of the screen. That is similar to entering a room (in a building, on
>> earth, in our century) and looking for a window. Where would you look
>> or expect a window to be? Certainly the wall would be the first place
>> a window might appear. Not the roof, although possible, and certainly
>> not the floor.
> Remember Myth #9:
> http://carsonified.com/blog/design/top-10-ux-myths/
> (I don't remember who posted it, but thank you!)
>
> I'll give you another example (excuse my English for this one, I  
> don't have the specific vocabulary I would need to be more clear).
> Here is a picture of my oven, in the kitchen:
> http://dl.getdropbox.com/u/173771/CIMG3324.JPG
>
> As with all ovens and cooking plates I have had in my short life  
> (that's about   a dozen because I move a lot) I remember that I  
> always had the same "problem": the buttons to switch the cooking  
> plates are not "on" the working space beside the cooking plate, but  
> under the hangover, on the vertical side.
>
> So when I have to switch a plate on, I have to bend down to find the  
> correct button for the correct plate I want to switch on.
> If it would be on top, I would see the buttons better, and would not  
> need to bend down to use them.
>
> To me it is clearly a design mistake, but the majority of ovens I  
> have seen in my life are like this.
> So, two remarks about this:
> 1. the majority is not always the best design.
> 2. Do you think I would get used to the buttons place if they would  
> be "on" the table beside the cooking plates, instead under the  
> hangover?
> I think anyone would get used to it very fast.
>
>
> To go back to the UI Myth #9. I think users can adapt, and that your  
> argument about "since 30 years" is wrong. For 30 years, we had 4:3  
> screens, now almost all new displays are 16:9. Things change, but  
> UIs shoudn't?.
>
> Many people on the mailing list have already given a ton of examples  
> of UIs with vertical designs or vertical elements, definitely  
> proving that users are already used to vertical designs. iTunes, or  
> even the standard menu of gmail to cite only two. These applications  
> don't seem to be a problem to billions of users. I don't think that  
> OOo users are dumber than average.
>
> Another argument: in the era of the web, users are used to browse on  
> a quantity of websites, all of them having different layouts: menu  
> layouts, organisation, etc. In many cases, the structure is  
> vertical, or vertical + horizontal. Nowadays, people are used to  
> change, because that's what they do everyday on the web. If the UI  
> is good and well tested, let it be horizontal or vertical, people  
> will adapt, really.
>
>
> One more argument: you insist that for 30 years the menus have been  
> on top of the screen, and it would be difficult to some users to  
> adapt, and find elements, for example, on a left vertical sidepane.
> Pure supposition, and there is no vertical design planned. But see;
> http://carsonified.com/blog/design/top-10-ux-myths/
>
> I tried it. Yesterday night we had guests, so I asked 5 persons, all  
> musicians and not technically gifted at all, to point on the screen  
> how they would do following actions in the following mockup:
>
http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_1
0_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png

> - save
> - change font, and font size
> - center paragraph
> - copy and paste
>
> ALL of them found it immediately. And they seemed to be very at ease  
> with the vertical sidepane. (two of them wondered about the styles  
> at the bottom, "so here you can change the font, too?")
>
> I admit my testing is quite light, on the same type of basic users  
> and basic commands. But it is still better that pretending something  
> without even doing this most basic testing.
>
> As a conclusion, I don't know how you can pretend that people would  
> have difficulties to adapt to a vertical design, without testing it.  
> And also continually ignore existing software with vertical UIs.
>
>
> (By the way, if someone wants to test RedOffice beta 4: I can send  
> the archive of the beta, for Windows. I don't manage to get and  
> install newer versions.)
>
>
> ***
>
>> 2. So, since that change would induce as much confusion as any  
>> other change of such severity, it better should be really  
>> beneficial. If it
>> does not significantly improve usability by a factor of X that is
>> worse going through the pain of relearning, then IT MAKES NO SENSE to
>> change that at all.
> Well, I didn't see any publications of testings concerning the  
> actual prototypes. I really don't know if and how they would be  
> really beneficial, or more beneficial that a vertical design or some  
> other features, taking in account that it would probably take 3-5  
> years of development.
>
> The most beneficial thing, according to the users themselves, can be  
> found on slide 30 of this presentation:
>
http://wiki.services.openoffice.org/w/images/1/11/Renaissance-status-2009-01
-30_wiki.odp

> I often think, if we would think about the users, well, a lot of the  
> energy would have to go to a better MSO 07/03 compatibility.
>
> And I don't see in 3.2 the ability to write OOXML, what a  
> disappointment!
>
> I'm sorry, I'm off topic. But I don't have seen any publication of  
> tests showing that some of the the prototypes would be better for  
> the end users than the current UI. (Neither that vertical UIs to  
> better or worse, of course.)
> It is really so beneficial that it justifies concentrating that much  
> resources and energy on it? There are so many things that could be  
> done in OOo...
>
>
>> 2.1 Better use of screen real estate
>> In addition, in a
>> vertical UI you are forced to either use some sort of an "ACCORDION",
>> "TABS or VERTICAL TABS" or a mixture of both. Using these controls
>> means that you loose a lot of vertical space, depending on the font
>> or icon size and the LANGUAGE (how about Finish), that is occupied by
>> the labels of tabs or accordion elements.
> That's only true for some designs.
> I'm sorry to use my proposal again as an illustration, but it is not  
> true in it. Neither it is in Office Mac 2008 or Apple pages. Again,  
> how can you write your argument ignoring these?
>
> In this kind of design, the language and length of text is not very  
> important neither:
> http://wiki.services.openoffice.org/w/images/5/5d/Mockup_fin22rev.png
> (from the proposal by Constantin Bürgi)
>
> And if you take a look at the last proposal by IBM (by the way,  
> great proposal, great ideas! Better to me than actual Symphony  
> versions!), it does not loose vertical space neither:
> http://wiki.services.openoffice.org/wiki/Sidebar_Proposal_by_IBM
>
> So how come you can affirm that a vertical design has to loose  
> vertical space in this way?
> And again, many designd would work with any "length" of language.
>
>
>> Therefore we would need to use
>> scrolling bars, especially on NETBOOKS where vertical space is
>> precious.
> Need scrolling bars? Again, you are making curious affirmations,  
> without argumenting them very well.
> The proposal by IBM, as well as mine, don't need vertical scrolling  
> bars in general. Neither does RedOffice.
>
> With "in general", I mean that the sidepane does not need its own  
> scrolling bar. Indeed some elements would need one, like the "styles  
> & formatting" in this mockup:
>
http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_1
0_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png

> (yeah, I know, I use this one a lot, sorry!)
>
> And sorry to say this, but I fond scrolling bars in horizontal UI  
> elements much more ridiculous. See Office 2007.
>
> > Try to squeeze 340 commands into a sidepane of e.g. 75 x
>> 600 pixels size. Scrolling bars would again hide some commands, which
>> brings us back to the current problems. Overall, there is a tradeoff
>> between gaining and loosing screen real estate that cancels possible
>> improvements. Therefore, no obvious significant step forward towards
>> a solution.
> First, I am very disappointed, because your arguments show that you  
> did never really consider the option of a vertical UI. It seems that  
> you are bringing mostly personal arguments, without a "testing" base.
> > e.g. 75 x 600 pixels size
> I know, "e.g."... but at least 200 pixels width are standard.
> See:
>
http://wiki.services.openoffice.org/w/images/c/c3/Martinu_-_Sidebar_Width_in
_different_Office_Suites_applications.png
>
> Let's have numbers. In 800x600,
> Prototype 0.16 :
> 800x125= 100000
>
> This mockup:
>
http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3
_-_800x600_Full_home_sidebar.png

> 207x488= 101016
>
> I have to agree, 800x600 is not a smart choice, but as you can see,  
> the space for the UI is the same (it may very a little, depending  
> how you calculate it). And without scrolling bars, of course, why  
> did you get the idea that these would be needed?
>
> ***
>
> Now, is there enough space for commands, even in 600 pixels height,  
> with a vertical design? Here is the answer:
>
> I would like you to look again at this mockup I made, with a 800x600  
> pixels resolution. These are about 50 commands on one side pane,  
> many (22) of them with text+icon.
>
http://wiki.services.openoffice.org/w/images/c/c5/Martinu_-_General_Mockup_3
_-_800x600_Full_home_sidebar.png

>
> Now count how much commands there are on the "start" tab of the 0.16  
> prototype: about 25, half as much. 11 with text, also half as much.
> The "format" tab has the most commands in the 0.16 prototype, and  
> these are only 27. Note that the text is smaller in the prototypes  
> that in my mockups.
> (I know, it's only a prototype, ...)
>
> One more thing. I have space for 9 "tabs" in my proposal. (with  
> vertical icon tabs as in the IBM design, there would be space for as  
> many as one would like.)
> If we have the same amount of commands for each tab, about 50, there  
> is a possibility of 450 commands, many of them with full text.
> With 600 pixels height.
>
> I admit that it is the "most optimistic" method to calculate, but  
> still... you were speaking of 340, my result is that there would be  
> space for 450, with 600 pixels height.
>
> Conclusion: in any case, even with a less optimistic calculation,  
> there is enough space in a well made vertical UI. And this, without  
> "eating" the vertical space of a netbook, as does a "ribbon" design.
>
>
> To conclude this point, I was really disappointed to see that you  
> insist on saying that there would be not enough space in a vertical  
> UI, without really trying it.
>
>
>> --> Most of us who think of a presentation applications, or slides
>> and NETBOOKS in particular, also think of 16:9 or 16:10 screen
>> formats. But most of us remain with the thought that the SLIDES are
>> 4:3. Currently that might be true, which is also a pure ASSUMPTION,
>> but that will certainly change rapidly since presenters start to
>> support more the formats of laptop and netbook screen ratios. WHAT
>> WILL HAPPEN THEN??? Slides that resemble the screen ration on a 16:9
>> or even 16:10 screen use MORE screen real estate. That makes a
>> vertical UI less efficient concerning screen real estate usage.
> Once again, you are saying something very strongly, but didn't tried  
> it out...
> I was almost about to say "I didn't think about this" and "you're  
> right", but then I tried it out. And here is a mockup:
>
http://dl.getdropbox.com/u/173771/Martinu%20-%20General%20Mockup%2011%20-%20
Writer%20in%201366x768%20-%20NEW%20MOCKUP%20WITH%2016%209%20slides.png

> (with a 16:9 slide on a 16:9 screen)
>
> In fact, it works very well, even with 2 sidebars, as in the mockup!
> (The other solution, with one sidebar only, and the slides overview  
> on the bottom, has even more space for 16:9 slides.)
>
> Conclusion: the argument of the 16:9 slides invalidating the  
> usefulness of a vertical UI is not valid, sorry.
>
>
>> --> "Everyone works in full-screen mode". That is a possibility but a
>> PURE ASSUMPTION. Having a big wide-screen does not necessarily mean
>> that EVERYONE on the planet has the same usage patterns regarding
>> that screen. On the contrary, it might often be the case that users
>> work with several apps in parallel and reduce the windows of the
>> apps. As long as we do not have any evidence, we should not develop
>> for that use case SOLELY. Meaning, NO FOCUS on anything that works
>> best in full-screen only.
> It would also be pure assumption to imagine that people maximize the  
> windows vertically, thus making the waste of vertical space in a  
> "ribbon" UI even worse. This is not specially an argument against  
> vertical UIs.
>
> As you could see in my mockups, but also in those of the IBM  
> proposal, a vertical UI really works well also in small resolutions.
> And don't forget that most users use Word, with a "portrait" page.
> (I don't say all do, but most of them.)
>
>
>> --> "Sidepanes work well in Writer" That might be true. However, it
>> is not evident for Impress and certainly not for Calc where sheet
>> content is the essence of the app. Steeling 3 columns might be a lot
>> worse than steeling 3 rows.
> Well, I already posted my mockup of Impress with 2 sidepanes.
> I already posted a message about the Calc argument.
> So here it is again: your argument about rows being more important  
> than columns works well in 4:3 resolutions, but again, doesn't apply  
> in 16:9.
> Here is a screenshot of Calc in 1920x1080. I pasted a random sidebar  
> to have an idea of the relative width.
> /media/Kakemphaton/Johannes/Dropbox/Dropbox/Public/
> OOo_calc_1920x1080.png
>
> Do you REALLY think that the lost space due to the sidepane is still  
> relevant in 16:9 resolutions?
>
> ***
>
>
> A last small thing: the marvelous thing about the ribbons in Office  
> 2007 is how they scale to the size of the window. There are many  
> dynamic elements that adapt their size. I don't see this in the  
> prototypes - yes I know, these are only prototypes.
>
> Once more, I find a vertical UI very suited for these kind of auto-
> scaling elements. Take for example this mockup, which I'm really  
> sorry to link here for the 10000th time!
>
http://wiki.services.openoffice.org/w/images/2/24/Martinu_-_General_Mockup_1
0_-_Writer_in_1366x768_-_With_Styles%2C_ruler_button%2C_zoom.png

>
> Well, the "styles and formatting" element at the bottom would scale  
> to all resolutions, displaying more or less lines.
> I miss this in the prototypes, the "ribbon" style UI makes no sense  
> without this scalability.
>
>
> Note that the current toolbars in 3.x could be made scalable also,  
> playing with the text labels, as described here:
>
http://wiki.services.openoffice.org/wiki/Proposal_by_Johannes_Eva#14.1_More_
about_toolbars

>
>
> ***
>
>
>> So overall, neither me nor anyone else from the UX team is opposing  
>> or promoting that particular design pattern. As the matter of fact,  
>> we are not religious about any UI design pattern.
>> First, we never attempted to remove sidepanes completely. Hence, in  
>> some contexts sidepanes might appear. However, our design strategy  
>> is to remain horizontal for the access of all commands.
>
>> In sum, it is very likely that you will not see a vertical toolbar  
>> for accessing all commands as the main location. However, you might  
>> see that design patterns for other purposes and in different  
>> contexts. That really depends on the app and on the task.
>
> Honestly, I am just chocked by this overall hypocrisy. Really. First  
> say things like "we are not religious about any design pattern" or  
> "the prototypes are only prototypes", or "we don't need prototypes  
> of vertical UIs, we have Symphony", and pretending being open.
>
> And then, it was the feeling I and some other people had, thank you  
> for saying it out loud, already having chosen that the design won't  
> be vertical.
>
> Without having tested it seriously.
>
> Despite a lot of people, not only me, speaking in favor of vertical  
> UIs. I would say, despite of the modern monitor format speaking for  
> vertical UIs.
>
> I mean, did you really read more than 10 comments from the last  
> GullFOSS blog posts, what they say? Not all are rude and dumb, many  
> smart people out there. A lot of them for vertical UIs.
>
> And then, you post some unverified arguments and explanations  
> telling why you have already chosen that the UI would be not vertical.
> Where are the real usability studies?
>
> "Create a User Interface so that OpenOffice.org becomes *the users'  
> choice* not only out of need, but also out of desire."
> I don't believe in it anymore. Saying "we are open", and then not be  
> really open, but stuck in old ideas and designs, despite of the  
> public opinion being that brutal against it: that's not being open.
>
>
>
> ***
>
> I know my words are harsh, and I'm sorry about it. And I'm sorry  
> speaking only to you, Andreas, I don't know which other persons are  
> behind what is for me a "hypocrisy".
>
> And I also know that you, the team behind OOo, don't have the  
> resources you would need and you deserve to do it as well as it  
> should be done. I'm sorry for it.
>
> But this is a reason more for not putting OOo in danger, sucking a  
> lot of its resources in a project that should not be, at least to  
> me, the main priority, and that would last many many years, and that  
> started so baldy, at least in the public opinion.
>
> Are you aware that if Renaissance fails, this could be the death of  
> OOo as a sucessful project? I take so much time to write about this,  
> because I am really worried about all this.
>
> All the best, really, to you and OOo,
> Johannes
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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]