Another proposal and mock-up

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

Another proposal and mock-up

Miroslav Mazel
Hello everyone,
Since we already have the first solid, full proposal with a mockup, the FLUX
UI, I'm going to throw my hat into the ring and introduce another proposal:
http://3.bp.blogspot.com/_NMbQ5YXn8Gw/SVafz4H3JXI/AAAAAAAAAG4/HzBh2IM3R1I/s1600-h/ui+proposal.png.
The biggest suggested change here is a cloud-based version of OOo, which
would be the base for the future versions of OOo. I'm not sure how much work
it would take to move OOo from an application to a web site (I don't know
much about programming), and perhaps it would be more trouble than it's
worth, but here's my reasoning behind moving to the cloud:
 - OOo would be platform independent.
 - OOo could now edit/view online documents. (I'm not expecting OOo to
provide online document storage, but rather integration with services like
Google Docs.)
 - OOo would become even more portable.
 - As a cloud application, OOo should be streamlined (loading times should
be quick, especially with the offline version).
 - Cloud-based apps, it seems, will be the future of all applications.
I still expect there to be offline, installable versions of OOo, probably
based on things like Mozilla Prism or Google Gears, with higher OS
integration, extensions and perhaps some other advantages.
Moving on, another proposed change is a left sidebar -- the "i" icon stands
for the Maccish "Inspector" (it's basically a "Properties" sidebar, much
like that in Symphony). The "stack" icon next to the "Navigator" icon is a
feature idea (I'm calling it "Stockpile"), suggested a while back by someone
on the UX mailing list (I'm thinking Leonard Mada, but I could be wrong). It
is basically a place for temporarily setting aside stuff (text, images,
videos, etc.) one might like to use in the document. I also tried to
integrate some other past suggestions -- there's the recent scrollbar
suggestion, page numbering groups, a menu item search (under "Search," the
only menu item on the right; this search would search menus as well as the
document's text, or the text of all open documents, depending on the user's
choice), and also a start page (not in the mock-up; a user would get this
page with "Option/Ctrl+N", by clicking on the "New Tab" icon, or through
"File>New Window/Tab"; it would offer links for creating new documents,
opening new documents and recent files, and for templates and wizards). I
also tried to reorder the menus (now the menus are categorized and there are
contextual menus, like "Text," "Frame," "Image," "Shape," and "Table") --
here's what I have so far, if you'd like to see it:
http://ititlehere.blogspot.com/2008/12/ui-suggestion.html. The toolbars
(ignore the small height -- that's a mistake, not a suggestion) are now also
categorized and more flexible. They are color-coded, the user can choose the
icon size of individual toolbars, and there's a new contextual toolbar
(similarly to Symphony and iWork). Toolbars and their sections would now be
positioned by dragging the bottom "title" bars (clicking once would select a
section, twice would select the toolbar), and if the window were to be
resized, icons would be hidden by usage, and ultimately turned into pop-up
menus by sections. Also, if too many tabs were open or the window was too
small (if meaningful parts of the title could no longer fit), the tabs would
disappear and a tab browsing button would be shown instead (functioning much
like that in Symphony or Quick Tabs in Internet Explorer).
A few other things:

   - There should be an extension (desktop version only) for the features
   that we remove/hide in streamlining OOo.
   - The new OOo should use pockets (contextual snippets) and, for things
   like Paste (Special) and password-protected documents, browser-like
   toolbars.
   - Pockets could optionally provide access to contextual menus
   - Equations should act like the main text, not like frames
   - Help should be completely redone. It should be more visually appealing,
   include walk-throughs (do the tasks for the user, showing every step),
   pictures (when there can't be walk-throughs, e.g. used with defining a
   pocket), and tutorials, use less formal language to be more understandable,
   define terms like "toolbar," and feature a simple home screen with links
   to: "New Stuff" (what was added in the new version; includes menu search,
   pockets, sidebar, page numbering groups, tabs, etc.), "(Re)Moved Stuff"
   (where some previous features have gone), "Useful Stuff" (Useful features
   that aren't too apparent; could include things like tab stops),
   and "Tutorials and Walk-throughs."
Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Joshua Martin
I remain attentive to my own proposal, FLUX UI, because I think it allows
the software to present the document in a more intuitive and simple way.

However, I see several things in your design that I'd like to integrate into
FLUX (with your help). In particular, I like the way you integrated document
tabs into the design just above the actual
document/spreadsheet/presentation's window - given the popularity seen on
this list for document tabbing, it would be a good idea to integrate such a
feature in the way you've done.

Secondly, I like the "Stockpile" feature you've integrated - this would be a
useful feature for my own use and I'm sure would also be for others.

Thirdly, I have taken notice to a few other features you've very subtly
integrated that are more than appropriate for a design like FLUX; these
features include the settings icon, the search button (I'm guessing to
search commands and help), and some of the elements in the status bar.

As we've discussed already on this list many times over, the menus remain a
controversial issue. I have remained very open minded about the issue
without an abnormal amount of bias for either way, but I really do think
that the days of "menu based feature organization" in a application are
nearing an end. As the capabilities of software applications like OOo
increase, our users become smarter - and they expect their software to be
smarter as well. I think we need to increase the user friendliness of OOo,
and I believe the removal of menu based organization is a necessary
prerequisite... Not just to do something different that the other
applications haven't done - but to truly produce an innovative user
experience that allows our users to engage the software in a very productive
and unique way. Any way, just my humble opinion...

--
_________________________________

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

Re: Another proposal and mock-up

Clément Pillias
In reply to this post by Miroslav Mazel
Hello Miroslav (or Mazel?),

Le 27 déc. 08 à 23:28, Miroslav Mazel a écrit :

> The biggest suggested change here is a cloud-based version of OOo,  
> [...]

I won't comment this suggestion since it seems that it goes far from  
the scope of the Renaissance Project. Moreover, I don't believe in  
your assumption that “Cloud-based apps will be the future of all  
applications.„ But this is out of topic.

> Moving on, another proposed change is a left sidebar -- the "i"  
> icon stands for the Maccish "Inspector" (it's basically a  
> "Properties" sidebar, much like that in Symphony).

You should make it clear that these icons act as tabs, relatively to  
the area right above. They rather looks like somme icons that open  
some dialog, like the "?" in the top right corner (by the way, what  
is the gear icon on its left?).

> I also tried to integrate some other past suggestions [...]

I don't know if these suggestions are purely "interface" or if they  
involve "new features", so I don't know if it is in the scope of the  
Renaissance Project.

But I'm satisfied to see that all these ideas, put together, have the  
potential to create a whole new experience.

> I also tried to reorder the menus (now the menus are categorized  
> and there are contextual menus, like "Text," "Frame," "Image,"  
> "Shape," and "Table") -- here's what I have so far, if you'd like  
> to see it:
> http://ititlehere.blogspot.com/2008/12/ui-suggestion.html.

I am not sure if it is better than the actual menu: you seem to  
prefer an organization of menus according to the type of object  
involved in the command (page, image, text, Tab…), while the actual  
menu is organized according to the task the user is trying to achieve  
(insert, format, edit…). I believe the user is more familiar with the  
second kind, and that it is more efficient, but this is arguable and  
testable ;)

> The toolbars (ignore the small height -- that's a mistake, not a  
> suggestion) are now also categorized and more flexible. They are  
> color-coded, the user can choose the icon size of individual  
> toolbars, and there's a new contextual toolbar (similarly to  
> Symphony and iWork).

I am not sure if it is a good idea to allow the user to customize the  
icons size for each toolbar, because it breaks the uniformity of the  
toolbars area and eventual horizontal and vertical alignments (which  
are underused in the actual toolbars).

It is a good idea to help the user distinguish the different  
toolbars, although color-coding has a lot of issues (no meaning  
associated to color, color-blindness, etc…). Moreover, the position  
may be sufficient, if the limits of the toolbars are easily perceivable.

I put a big +1 for the categorization of toolbars. I think that we  
should even make the categories more distinct. One of the things that  
I have customized in the toolbars is the position of icons in the  
"format" toolbar, such that all items acting on paragraphs  
(alignment, list type, indent and background color) are separated  
from the items acting on characters (font, bold/italic/underlined,  
color and highlighting). I think it is easier to access stuff this way.

> Toolbars and their sections would now be positioned by dragging the  
> bottom "title" bars (clicking once would select a section, twice  
> would select the toolbar), and if the window were to be
> resized, icons would be hidden by usage, and ultimately turned into  
> pop-up menus by sections.

+1

> Also, if too many tabs were open or the window was too
> small (if meaningful parts of the title could no longer fit), the  
> tabs would disappear and a tab browsing button would be shown  
> instead (functioning much like that in Symphony or Quick Tabs in  
> Internet Explorer).

Or as in Firefox?

> A few other things: [...]

Once again, the status of all this is unclear: feature or interface?  
I think that we need clarification (Frank, Christoph?). And while  
we're here, I would like to ask how the UI project is involved in the  
Renaissance Project? And the Art project?

Finally, some remarks on your mockup:
* The choice of colors could match the Windows style, but it is  
horrible on a mac :(
* If find it strange to have the menu below the tabs. And once again,  
it won't work on mac os.
* In your toolbars, there is not enough "affordance": icons for bold,  
italic and underline have the same look than the save icons, while  
they are boolean toggles. Your font drop-menu also looks like a text  
field, although it does not allow any text to be entered, etc.

Regards,

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

Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Clément Pillias
In reply to this post by Joshua Martin

Le 28 déc. 08 à 01:24, Joshua Martin a écrit :

> However, I see several things in your design that I'd like to  
> integrate into FLUX (with your help). In particular, I like the way  
> you integrated document tabs into the design just above the actual  
> document/spreadsheet/presentation's window - given the popularity  
> seen on this list for document tabbing, it would be a good idea to  
> integrate such a feature in the way you've done.

And the advantage is that tabbing features are totally separated from  
the rest of the interface, so, technically, it reduces the  
interdependence of features :)

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

Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Miroslav Mazel
In reply to this post by Joshua Martin
Hi Joshua and others,

2008/12/27 Joshua Martin <[hidden email]>

> I remain attentive to my own proposal, FLUX UI, because I think it allows
> the software to present the document in a more intuitive and simple way.


Don't get me wrong, I also like the FLUX UI. However, I'm still unsure about
a few things about it:
 - How would it work with a much smaller window, or a closely zoomed-in
document? Where would the "sidebars" go?
 - Do features have to be removed in order to reach this kind of simplicity
and, if so, which ones?
I tried to make my proposal as flexible as possible, and, hypothetically,
something close to FLUX UI could be reached with it (I might work on a
mockup for that) -- the sidebar can be moved to the right, the "General"
sidebar can use bigger icons and be moved above the contextual sidebar, and
the menu bar and status bar could be hidden (either through "Options" or
through "View" in the menu; the menu would still be toggled by Alt under
Linux and Windows). The only differences would be in the use of the
document's margins and in the use of accordions/tabs for the "General"
toolbar. I also support the idea of no pop-up windows (Help and Options are
supposed to be tabs also in my mockup, although that's not at all apparent;
mousing over "Page ___" in the status bar would show "Word count" in a
bubble), and I definitely support your idea of using pull down menus.

>
>
> However, I see several things in your design that I'd like to integrate
> into
> FLUX (with your help).

Sure. I'm not sure if you'll need my help, though.

> In particular, I like the way you integrated document
> tabs into the design just above the actual
> document/spreadsheet/presentation's window - given the popularity seen on
> this list for document tabbing, it would be a good idea to integrate such a
> feature in the way you've done.

Thanks.

>
>
> Secondly, I like the "Stockpile" feature you've integrated - this would be
> a
> useful feature for my own use and I'm sure would also be for others.
>
> Thirdly, I have taken notice to a few other features you've very subtly
> integrated that are more than appropriate for a design like FLUX; these
> features include the settings icon, the search button (I'm guessing to
> search commands and help), and some of the elements in the status bar.
>
> As we've discussed already on this list many times over, the menus remain a
> controversial issue. I have remained very open minded about the issue
> without an abnormal amount of bias for either way, but I really do think
> that the days of "menu based feature organization" in a application are
> nearing an end. As the capabilities of software applications like OOo

increase, our users become smarter - and they expect their software to be
> smarter as well. I think we need to increase the user friendliness of OOo,
> and I believe the removal of menu based organization is a necessary
> prerequisite... Not just to do something different that the other
> applications haven't done - but to truly produce an innovative user
> experience that allows our users to engage the software in a very
> productive
> and unique way. Any way, just my humble opinion...

I actually think menus help applications, or at least feature-packed
applications like OOo, be more user friendly, since they provide a single
place, a feature map of sorts, to browse/search through in determining the
application's capabilities. As always, I like the way Mac OS X does it - it
nicely puts away the toolbar at the top of the window, so that it doesn't
get in the way, but it's always there in case the user needs it. In any
case, I would rather we hide the menu by default (like Microsoft has done
with IE) than remove it and keep the ALT shortcuts.

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

Re: Another proposal and mock-up

Joshua Martin
In appeal to your last post...

No, features do not have to be sacrificed for FLUX UI. The basic design
principles for FLUX allow the features of OOo to be integrated in a
nonobtrusive way that allows the user to focus more on his/her document.

I imagine we could handle smaller screens just like the current OOo and
other office productivity suites. For instance, in OOo resizing the window
to an abnormally small size simply disallows the user to see everything he
would normally see. Just like other office suites, the UI will scale to
various resolutions - screen size differences really aren't an issue as far
as I can see because I keep these situations in mind.

And of course, just like any other office suite, the user will be able to
rearrange the "toolbars" any way he pleases. The left sidebar that holds
static options could be moved to the top (just below the tabs) or the right
or bottom. That top horizontal tabs toolbar could be moved to the bottom or
even the two right or left sides. Again, this really isn't even an issue...

Lastly, I won't continue to bash the menus, but I will say that my overall
ambition for this design is to eliminate a menu based UI.

--
_________________________________

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

Re: Another proposal and mock-up

Miroslav Mazel
In reply to this post by Miroslav Mazel
Hello everyone,

2008/12/28 Miroslav Mazel <[hidden email]>

> Hi Joshua and others,
>
> 2008/12/27 Joshua Martin <[hidden email]>
>
>> I remain attentive to my own proposal, FLUX UI, because I think it allows
>> the software to present the document in a more intuitive and simple way.
>
>
> Don't get me wrong, I also like the FLUX UI. However, I'm still unsure
> about a few things about it:
>  - How would it work with a much smaller window, or a closely zoomed-in
> document? Where would the "sidebars" go?
>  - Do features have to be removed in order to reach this kind of simplicity
> and, if so, which ones?
>
Thanks for the answers.

> I tried to make my proposal as flexible as possible, and, hypothetically,
> something close to FLUX UI could be reached with it (I might work on a
> mockup for that)
>
And I did, but it sort of turned into an additional update:
http://2.bp.blogspot.com/_NMbQ5YXn8Gw/SV-k7xtp-rI/AAAAAAAAAHA/fZKpAtDBgWo/s1600-h/ui+proposal+3.png.The
toolbars now have title bars at the top, which, when clicked reveal the
complete range of commands under that toolbar (unless the window size is too
small to hold them all, in which case it expands as much as possible,
leaving room for three expand arrows of the other toolbars and itself; when
the tab is clicked again, the toolbar would collapse back to the default
width). Also, the toolbars are now broadly categorized and contain
subcategories. When the user mouses over a command, the toolbar's title bar
shows the subcategory's name instead of the category's name.
http://4.bp.blogspot.com/_NMbQ5YXn8Gw/SV-lX8S_a4I/AAAAAAAAAHI/IYBdTXOs6FU/s1600-h/ui+proposal+3+full+tab.png
In streamlining, I removed data sources, line break, media player, and
gallery, although those could be easily added back. I renamed "Page break"
to "New page" (similar to "Insert Slide" in Impress; I tried to avoid using
the word insert, since the category "Insert" is pretty full, and the command
really should belong under "Pages"), "Sections" to "Rows," and "Fields" to
"Segment" (that's still a horrible name, I know. We should work to find a
suitable name, since neither "Fields" nor "Segments" accurately
characterizes the feature they stand for). Comments on changes are now
notes, only with "accept" and "reject" icons. They are, like notes, viewed
contextually in the sidebar. Lastly, the zoom slider on the left (only when
the status bar is hidden) is moved into a drop-down menu when the "Zoom"
button under "Document" is clicked (hidden in the mock-up), and language
tools are shown in the contextual text menu.

> -- the sidebar can be moved to the right, the "General" sidebar can use
> bigger icons and be moved above the contextual sidebar, and the menu bar and
> status bar could be hidden (either through "Options" or through "View" in
> the menu; the menu would still be toggled by Alt under Linux and Windows).
> The only differences would be in the use of the document's margins and in
> the use of accordions/tabs for the "General" toolbar. I also support the
> idea of no pop-up windows (Help and Options are supposed to be tabs also in
> my mockup, although that's not at all apparent; mousing over "Page ___" in
> the status bar would show "Word count" in a bubble), and I definitely
> support your idea of using pull down menus.
>
>>
>>
>> However, I see several things in your design that I'd like to integrate
>> into
>> FLUX (with your help).
>
> Sure. I'm not sure if you'll need my help, though.
>
>> In particular, I like the way you integrated document
>> tabs into the design just above the actual
>> document/spreadsheet/presentation's window - given the popularity seen on
>> this list for document tabbing, it would be a good idea to integrate such
>> a
>> feature in the way you've done.
>
> Thanks.
>
>>
>>
>> Secondly, I like the "Stockpile" feature you've integrated - this would be
>> a
>> useful feature for my own use and I'm sure would also be for others.
>>
>> Thirdly, I have taken notice to a few other features you've very subtly
>> integrated that are more than appropriate for a design like FLUX; these
>> features include the settings icon, the search button (I'm guessing to
>> search commands and help), and some of the elements in the status bar.
>>
>> As we've discussed already on this list many times over, the menus remain
>> a
>> controversial issue. I have remained very open minded about the issue
>> without an abnormal amount of bias for either way, but I really do think
>> that the days of "menu based feature organization" in a application are
>> nearing an end. As the capabilities of software applications like OOo
>
> increase, our users become smarter - and they expect their software to be
>> smarter as well. I think we need to increase the user friendliness of OOo,
>> and I believe the removal of menu based organization is a necessary
>> prerequisite... Not just to do something different that the other
>> applications haven't done - but to truly produce an innovative user
>> experience that allows our users to engage the software in a very
>> productive
>> and unique way. Any way, just my humble opinion...
>
> I actually think menus help applications, or at least feature-packed
> applications like OOo, be more user friendly, since they provide a single
> place, a feature map of sorts, to browse/search through in determining the
> application's capabilities. As always, I like the way Mac OS X does it - it
> nicely puts away the toolbar at the top of the window, so that it doesn't
> get in the way, but it's always there in case the user needs it. In any
> case, I would rather we hide the menu by default (like Microsoft has done
> with IE) than remove it and keep the ALT shortcuts.
>
>>
>>
>> --
>> _________________________________
>>
>> Joshua S. Martin
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Joshua Martin
What happens when a user clicks on a table or an image? Popups or the
floating toolbars?

--
_________________________________

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

Re: Another proposal and mock-up

Clément Pillias
In reply to this post by Miroslav Mazel
Hi,

Le 3 janv. 09 à 19:16, Miroslav Mazel a écrit :

> http://2.bp.blogspot.com/_NMbQ5YXn8Gw/SV-k7xtp-rI/AAAAAAAAAHA/ 
> fZKpAtDBgWo/s1600-h/ui+proposal+3.png.
>
> The toolbars now have title bars at the top, which, when clicked  
> reveal the complete range of commands under that toolbar (unless  
> the window size is too small to hold them all, in which case it  
> expands as much as possible, leaving room for three expand arrows  
> of the other toolbars and itself; when the tab is clicked again,  
> the toolbar would collapse back to the default width).

I'm not sure about that feature. In my opinion, elements in toolbars  
should not change place during normal interaction (ie, not  
customization). I am sure that we can find scenarii were the user  
will have to switch between toolbars most of the time. And if we  
accept that behavior, the conceptual model of the accordion seems  
simpler to me.

> Also, the toolbars are now broadly categorized and contain  
> subcategories. When the user mouses over a command, the toolbar's  
> title bar shows the subcategory's name instead of the category's name.

This sounds strange too. Maybe you should simply add the subcategory  
name after the category name.

Three additional remarks:
* I think that the title bars of the toolbars take a lot of vertical  
space, and it also forces the user in using a two-level strategy:  
first find the right toolbar (horizontal search), then go down to  
locate the buttons, and then search the button in the toolbar  
horizontally. Have you considered putting titles on the left of the  
toolbars?
* The triangles should be labeled "More…" (actually, the triangles  
could be replaced by that label.) And don't forget the "…" at the end  
of labels when the button opens a dialog, as for "Save as…".
* The last comment does not only concern your mockups, but I feel  
that we should separate ideas about the interface and proposals for  
"look and feel." The value of your proposal would be IMO more visible  
if the "look and feel" used was the same as the current  
implementation, or the same as usual on a given OS. The risk  
otherwise is to focus on "those horrible colors" or whatever is  
unusual in the look and feel.

Regards,

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

Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Miroslav Mazel
Hi Clément,
2009/1/3 Clément Pillias <[hidden email]>

> Hi,
>
> Le 3 janv. 09 à 19:16, Miroslav Mazel a écrit :
>
>  http://2.bp.blogspot.com/_NMbQ5YXn8Gw/SV-k7xtp-rI/AAAAAAAAAHA/
>> fZKpAtDBgWo/s1600-h/ui+proposal+3.png.
>>
>> The toolbars now have title bars at the top, which, when clicked reveal
>> the complete range of commands under that toolbar (unless the window size is
>> too small to hold them all, in which case it expands as much as possible,
>> leaving room for three expand arrows of the other toolbars and itself; when
>> the tab is clicked again, the toolbar would collapse back to the default
>> width).
>>
>
> I'm not sure about that feature. In my opinion, elements in toolbars should
> not change place during normal interaction (ie, not customization). I am
> sure that we can find scenarii were the user will have to switch between
> toolbars most of the time. And if we accept that behavior, the conceptual
> model of the accordion seems simpler to me.


I don't know. I'm trying to find a middle ground between tabs and no tabs,
so that as many buttons are shown as possible with any window size, but also
so that the user can easily and quickly reveal all the commands under a
single group by clicking a tab -- that's why I don't use an accordion;
because I want the title bars separate from the buttons and therefore have
more clickable real estate.
But I guess the behavior I'm proposing is a bit too wierd for a new user,
and would probably confuse or discourage him.

>
>
>  Also, the toolbars are now broadly categorized and contain subcategories.
>> When the user mouses over a command, the toolbar's title bar shows the
>> subcategory's name instead of the category's name.
>>
>
> This sounds strange too. Maybe you should simply add the subcategory name
> after the category name.


That would make more sense, I guess.

>
>
> Three additional remarks:
> * I think that the title bars of the toolbars take a lot of vertical space,
> and it also forces the user in using a two-level strategy: first find the
> right toolbar (horizontal search), then go down to locate the buttons, and
> then search the button in the toolbar horizontally. Have you considered
> putting titles on the left of the toolbars?
> * The triangles should be labeled "More…" (actually, the triangles could be
> replaced by that label.) And don't forget the "…" at the end of labels when
> the button opens a dialog, as for "Save as…".

I'm still debating that. After all, the current OOo toolbars don't have a
"More..." label, and users cope just fine. The problem with "More..." is
that it sometimes implies a link to website, and that scares the user
away...
As for the ellipsis, I'm thinking we could replace all the dialogs with
drop-down menus (drop-down menus are indicated, in my proposal, on
mouse-over only by a down arrow); if we want to move away from dialogs, why
not go the whole nine yards?

>


> * The last comment does not only concern your mockups, but I feel that we
> should separate ideas about the interface and proposals for "look and feel."
> The value of your proposal would be IMO more visible if the "look and feel"
> used was the same as the current implementation, or the same as usual on a
> given OS. The risk otherwise is to focus on "those horrible colors" or
> whatever is unusual in the look and feel.


Sorry, I'll keep that in mind for my next proposal version (if there is
one).

>
>
> Regards,
>
>
> Clément.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Miroslav Mazel
In reply to this post by Joshua Martin
Hi Joshua,

2009/1/3 Joshua Martin <[hidden email]>

> What happens when a user clicks on a table or an image? Popups or the
> floating toolbars?
>

Those toolbars are actually supposed to be locked (or whatever the opposite
of floating is), but I should have made a clearer distinction between the
toolbar and the document workspace.
If a user clicks on a table or an image, the contextual (the one with the
small icons) toolbar changes accordingly to offer the appropriate buttons.

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

Reversal of aspect ratio of display [was: Another proposal and mock-up]

Graham Perrin
Administrator
In reply to this post by Joshua Martin
Joshua Martin wrote
I imagine we could handle smaller screens just like the current OOo and other office productivity suites. For instance, in OOo resizing the window to an abnormally small size simply disallows the user to see everything he would normally see. Just like other office suites, the UI will scale to various resolutions - screen size differences really aren't an issue as far as I can see because I keep these situations in mind.

And of course, just like any other office suite, the user will be able to rearrange the "toolbars" any way he pleases. … this really isn't even an issue …
Without considering *how* things might rearrange automatically (probably out of scope of Renaissance), it should be good to consider *where* things might land, if arranged automatically.

Example: tablet PC or similar, reversing its aspect ratio (automatically, or on demand) whenever it is rotated 90°.

(My older MacBook Pro lacks the display software preference to rotate 90° so I can't tell how OOo 3.0 behaves at the moment.)

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

Re: Another proposal and mock-up

Clément Pillias
In reply to this post by Miroslav Mazel

Le 4 janv. 09 à 02:15, Miroslav Mazel a écrit :

> 2009/1/3 Clément Pillias <[hidden email]>
>
>> * The triangles should be labeled "More…" (actually, the triangles  
>> could be replaced by that label.) And don't forget the "…" at the  
>> end of labels when the button opens a dialog, as for "Save as…".
>
> I'm still debating that. After all, the current OOo toolbars don't  
> have a "More..." label, and users cope just fine.

I'm not sure that the users "cope just fine" with the current toolbars…

> The problem with "More..." is that it sometimes implies a link to  
> website, and that scares the user away...

I don't know. Maybe.

> As for the ellipsis, I'm thinking we could replace all the dialogs  
> with drop-down menus (drop-down menus are indicated, in my  
> proposal, on mouse-over only by a down arrow); if we want to move  
> away from dialogs, why not go the whole nine yards?

Well, I don't think that the ellipsis are here to signal that the  
button opens a dialog, specifically. In my mind, the ellipsis signal  
that there will be more steps to accomplish the action than the sole  
click on the button. So, dialog or drop-down menu make no difference  
in this case. But it is true that for the special case of drop-down  
menu, we have a better alternative than the ellipsis: the small down  
arrow.

The question is then: should we display the down arrow permanently or  
a mouse-over is sufficient? I can see the benefit of the mouse-over  
in term of simplification of the interface by removing stuff of small  
importance. But notice that the down-arrow should be shown when the  
button has the focus, not only when the focus is given by pointing  
with the mouse. But it may make no difference, because I don't know  
if your toolbars are accessible via the keyboard :)

On the other hand, one benefit of permanent display of the down arrow  
is that it becomes a part of the icon and can help to distinguish  
otherwise similar icons, such as "Save" and "Save as…".

Regards,

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

Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Christoph Noack-2
In reply to this post by Clément Pillias
Hi Clément, and all the others!

Am Sonntag, den 28.12.2008, 01:31 +0100 schrieb Clément Pillias:
[...]
> > A few other things: [...]
>
> Once again, the status of all this is unclear: feature or interface?  
> I think that we need clarification (Frank, Christoph?). And while  
> we're here, I would like to ask how the UI project is involved in the  
> Renaissance Project? And the Art project?

First, thank you all for providing new ideas and discussing potential
improvements to OpenOffice.org. I'm looking forward how these
interaction proposals will relate to the data which has been collected
from different sources (e.g. the surveys).

Concerning your question of "feature or interface" - I'm glad that you
put a question mark after my name, because I'm not too deep involved in
the Renaissance development (at the moment). And so my answer is only
based on some talks with Sun UX Team members...

Inside Sun the team tried to focus the development on user interface and
user interaction changes. And - I think - they had to prove internally
that the effort for such a project is somehow calculable and manageable.
(Sun is a company...)

My personal opinion is, that during the time Renaissance is developed,
it is hardly possible to stop capability improvements (here I try to
avoid the term "features"). And if we have good ideas how to solve
problems, then it we should consider that for the design decisions and
e.g. implement those features later. And a little bit off-topic: I'm
glad how the "presenting and rating ideas" thread went on ... I will try
to comment it as soon as possible.

Back to your questions: I have no special information about the UI
project and the Visual Design activities within the UI project. What I
know is, that the preparation of Renaissance at Sun involved nearly
every aspect of software development because of the required resources
(and the UI technology should be really part of the game *g*). Why do
you ask? Is there anything of particular interest?

Bye,
Christoph


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

Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Clément Pillias
Hi Christoph!

Le 5 janv. 09 à 09:55, Christoph Noack a écrit :

> Back to your questions: I have no special information about the UI
> project and the Visual Design activities within the UI project.  
> What I know is, that the preparation of Renaissance at Sun involved  
> nearly every aspect of software development because of the required  
> resources (and the UI technology should be really part of the game  
> *g*). Why do you ask? Is there anything of particular interest?

I was just wondering how the ideas of the UX team would be  
transformed in an actual product :) I also wanted to evaluate the  
resources available (directly related to the size of the changes that  
we can make). And finally I was wondering what would happen if we  
decided to implement some new interaction technic needing to rewrite  
a large part of the UI or of the GUI toolkit. E.g., I have not  
forgotten that the tooltips formating is limited. You know that we  
are easily dreaming, here, so my question was "what is the limit?"

Cheers

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

Reply | Threaded
Open this post in threaded view
|

Re: Another proposal and mock-up

Elizabeth Matthis
Hi Clément
Thanks so much for your great involvement in the UX discussion. I am on
the OOo/SO UX team at Sun so I hope I can help with a couple of your
questions below.
On 01/05/09 10:20, Clément Pillias wrote:
[...]
> I was just wondering how the ideas of the UX team would be transformed
> in an actual product :) I also wanted to
This is a long term project, so useful ideas will be carefully
"transformed" into concepts, specified and tested and re-specified and
implemented, etc. (By testing I mean usability testing)  Or did you
think we would just collect them and then make paper airplanes out of
them? ;-) ha ha No, seriously, the ideas being shared here will
hopefully later help in developing the solutions to usability problems,
and therefore increase the usability of the product and make everyone
want to cuddle our sexy OOo!
> evaluate the resources available (directly related to the size of the
> changes that we can make). And finally I was
How much are you willing to be one of the "resources"? ;-) There are
lots of people here on the list who are capable and willing, I hope. In
which capacity, we can only later determine as the Renaissance project
progresses. There are always many ways the community can be active, even
if only on mailing lists or by getting everyone you know to fill out
surveys, test concepts, etc.
Right now, we are only in the research phase
http://wiki.services.openoffice.org/wiki/Renaissance:Phase_1.
We are not actually in the ideas collecting phase because we first want
to collect the data on who the users are and what they do with OOo.
Then, after we have personas, etc, we need ideas to address the problems
we have decided to focus on. Most of the ideas posted on this list have
usability issues at their root, so getting to those roots and deciding
on the best course of action to achieve solutions is the aim.
> wondering what would happen if we decided to implement some new
> interaction technic needing to rewrite a large part of the UI or of
> the GUI toolkit. E.g., I have not forgotten that the tooltips
> formating is limited. You know that we are easily dreaming, here, so
> my question was "what is the limit?"
>
The sky! After the research phase, we have to develop solutions (that
would be when we need ideas for solutions) and evaluate the usability
priorities to determine implementation plans. But right now, nobody
should worry that it will be too much to implement. We want to *really
really* improve OOo in a big way.
> Cheers
>
> Clément.
Even if the Sun UX people don't write comments and responses to all the
posts, the posts are still being read and appreciated! There are only 4
1/2 of us for OOo, so that is why the other UX people in the community
are very important. There are so many juicy brain cells exchanging
impluses on this list. It's great! Thank you soooooo much everyone, for
your energy and enthusiasm. Keep it up!

Best regards,
Liz

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