Some Feedback on Citrus.

classic Classic list List threaded Threaded
30 messages Options
Next » 12
Stefan Knorr (Astron) Stefan Knorr (Astron)
Reply | Threaded
Open this post in threaded view
|

Some Feedback on Citrus.

Hi everyone,

a few days ago, Andrew asked for feedback on Mirek's Citrus proposal.
So, here, I want to start a thread on what I/we like and what I/we
don't like (about the desktop/laptop proposal), in the hope that it
helps Mirek to refine his proposal. Please note, I am not a regular
reader of Mirek's blog and my assumptions are based on the short
descriptions from the wiki, so if anything on this list seems wrong to
you, feel free to correct me.
Here we go, structure is as on Mirek2's wiki page:

* Ellipsis menu:
I like the idea and it looks much better (cleaner) than it does
currently; for executing commands it is also more functional.
Here's what I don't like: that you can customise your toolbar via
drag-and-drop is not made visible at all; for users of accessibility
solutions there seems to be no way to add or remove something.

* Page/slide handles:
I like the idea (so much I opened a bug about it – fdo#38597). There's
a lot to discuss, though, before this can be implemented (how it
zooms, how it acts, etc.). Also, the proposal doesn't work at all for
Calc (which Mirek explained, he uses so seldomly that he didn't
include it in his proposals).

* Continuously scrollable slides:
Not a bad idea for the read-only mode. When editing a document,
however, there will sometimes be the case that an image or other
element would overlap into the next slide. What should LibO do then?
Push the slide further below? Cut the element off in between the two
slides? I'm sceptical.

* Add page/slide:
I can see this being very useful in Impress and Draw, but in those
programs, I would probably put this button into the sidebar.
For Writer, it would be similarly useful, but we'd also need more
complexity: it'd need at least a "Add page" and an "Add Section"
button (unless there is any way in which we can make those two
commands the same).

*Float bar:
I'm not sure that I heavily subscribe to this – there is a similar bar
in the Pencil extension for Firefox that I use for mock-ups that pops
up when one edits certain text fields.
I think the most important aspect for the float bar is that it keeps a
large enough distance from the element, so it doesn't annoy the user
or gets in the way; and still is not positioned so far from the
element that the user thinks it doesn't belong o the element any more.
There are a few other positioning questions that need to be solved: if
the element covers the entire screen, where would the float bar be
least in the way (it can either cover the element itself or cover the
docked toolbars or maybe could be positioned vertically) ... what's
the best option?

* Insert bar:
This is an idea from Ooo 1.0, I think. I'd love to know why it was
abandoned, then, because it probably is a good idea..?

* Live preview:
An MSO idea. I am unsure how much I like it, but I am pretty sure that
developers will protest at its resource usage. The idea is also not
very detailed.

* Color-coded icons:
This is a really good idea. But, I think, the codification is wrong.
Currently there are too many shades that are so close to each other
that no user will associate them with their underlying functional
aspect. Similar shades would appear clustered in certain application
(textual shades → Writer). Two ideas:
→ reduce the shades to only a few (~5)
→ maybe use menu titles as the basis for which command should have an
icon of which shade (one for file actions, one for editing, viewing,
formatting...)
I'd love to see if such a colour coding system is viable. I'd also
love to know if it is problematic for colour-blind or otherwise
visually impaired users.
By the way, building such an icon set is something the design team can
do on its own (all you need is a zipping tool, graphics software, a
file manager and lots of time) – so it could be the first part of
Citrus that would actually be implemented.

* Reduced standard toolbar:
I agree, mostly. I think Print is essential though. I always hide
Email (because I am a bit of a Ctrl frk and always open documents
again before sending, then drag/drop them from the file manager into
the mail application), but I think many people would see Email as
equally essential.
Finally, there is a command that I often use, but that doesn't fit the
standard toolbar even today: Non-printing Characters. Where could it
go or do we not need it in the toolbar? (I am assuming the Gallery
would become part of the Insert toolbar – is that correct?)

* Drop-down buttons:
Creates a lot of functional inconsistency, I don't think users would
like it. But we can agree on the direction of the arrows.



* Sorting out commands:
Good principles, basically, but probably too rough to be usable in
their current form. Point two (no greyed-out buttons) is contradictory
to the reasoning found under Reduced standard toolbar (clickable
buttons as indicators).
Also, this is part of the proposal is throwing (useful) conventions
out of the window: should we really move Cut, Copy and Paste into
completely different menus?

* Getting rid of formatting dialogs:
Granted, I am biased here [1], but I don't like interacting with menus
in this way at all, even though that's something Microsoft Office
makes heavy use of.
It is also a huge, huge, huge amount of work for an unclear (to me)
benefit. Two disadvantages of relying so much on rich menus:
→ opening menus to change anything all the time should be pretty annoying
→ customising styles is made very hard (we should want people to use
styles, so they can create more coherent looking documents more
easily!)

* Combining navigator and side pane.
I never actually use the Navigator, but I think that's an idea (a very
rough one, though) worth investigating.

* Simplified Options:
I am pseudo-actively working on a proposal here [2], so yes, absolutely.

* Rich menus:
In principle, yes, but I wouldn't base the whole UI on them (rf.
Getting rid of formatting dialogs).

Overall, this proposal is quite coherent (and radical and creative)
and that's all good, but there are still too many loose ends hanging
around.
Blip.
Astron.


[1] http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout
[2] http://wiki.documentfoundation.org/Design/Whiteboards/OptionsRework

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

Hi Astron, everyone,

2011/10/30 Astron <[hidden email]>

> Hi everyone,
>
> a few days ago, Andrew asked for feedback on Mirek's Citrus proposal.
> So, here, I want to start a thread on what I/we like and what I/we
> don't like (about the desktop/laptop proposal), in the hope that it
> helps Mirek to refine his proposal. Please note, I am not a regular
> reader of Mirek's blog and my assumptions are based on the short
> descriptions from the wiki, so if anything on this list seems wrong to
> you, feel free to correct me.
> Here we go, structure is as on Mirek2's wiki page:
>
> * Ellipsis menu:
> I like the idea and it looks much better (cleaner) than it does
> currently; for executing commands it is also more functional.
> Here's what I don't like: that you can customise your toolbar via
> drag-and-drop is not made visible at all; for users of accessibility
> solutions there seems to be no way to add or remove something.


The ellipsis menu wouldn't be the only way a toolbar could be customized.
If the ellipsis menu was implemented in today's LibreOffice, there would
still be a link to the Customize dialog in the menubar and the toolbar's
right-click menu.


> * Page/slide handles:
> I like the idea (so much I opened a bug about it – fdo#38597). There's
> a lot to discuss, though, before this can be implemented (how it
> zooms, how it acts, etc.). Also, the proposal doesn't work at all for
> Calc (which Mirek explained, he uses so seldomly that he didn't
> include it in his proposals).
>

It shouldn't be in Calc, at least not with how Calc works now.
I don't think Calc lets you change page formatting for each page
separately, so being able to select separate pages would be of no use. (You
can select the whole table with the blank top-left corner cell, though.)
And Calc already has a way of showing page number under Page view,
different from how all the other LibO apps show page number.

>
> * Continuously scrollable slides:
> Not a bad idea for the read-only mode. When editing a document,
> however, there will sometimes be the case that an image or other
> element would overlap into the next slide. What should LibO do then?
> Push the slide further below? Cut the element off in between the two
> slides? I'm sceptical.
>
There are two ways it could go:
- Keep it shown on both slides, and leave cropping to the user.
- Keep the element shown on one slide only. If the user wanted to have it
on both slides, he would simply duplicate it.
I think the latter would be the ideal way of going about it, as it would
keep the functionality the same and therefore there would be no
compatibility probems between LibO versions.
The object would show up only on one slide, that slide being the one it was
created in (if it was a shape, this would be the slide in which the cursor
was placed initially) or dragged to (that is, on the slide where the cursor
stopped).

>
> * Add page/slide:
> I can see this being very useful in Impress and Draw, but in those
> programs, I would probably put this button into the sidebar.
>
There is no sidebar for Impress/Draw in Citrus (unless you mean the
Navigator). The point of this button is to have a button inline, so that a
user didn't have to have a sidebar open to get this core functionality.
That's especially useful when working on a small screen and/or with two
windows side-by-side (which I have quite often).

> For Writer, it would be similarly useful, but we'd also need more
> complexity: it'd need at least a "Add page" and an "Add Section"
> button (unless there is any way in which we can make those two
> commands the same).
>
It's in the more recent proposal (add page is centered on the left half,
add section on the right half). :)

>
> *Float bar:
> I'm not sure that I heavily subscribe to this – there is a similar bar
> in the Pencil extension for Firefox that I use for mock-ups that pops
> up when one edits certain text fields.
> I think the most important aspect for the float bar is that it keeps a
> large enough distance from the element, so it doesn't annoy the user
> or gets in the way; and still is not positioned so far from the
> element that the user thinks it doesn't belong o the element any more.
> There are a few other positioning questions that need to be solved: if
> the element covers the entire screen, where would the float bar be
> least in the way (it can either cover the element itself or cover the
> docked toolbars or maybe could be positioned vertically) ... what's
> the best option?
>
The whole point of the float bar is to be as close to the selection without
covering it, so as to minimize mouse distance. That's the reason for having
it. Otherwise, there is no difference between it and the toolbar -- it can
only contain the same commands as the toolbar. And just like the toolbar,
it could be hidden/shown in the "View" menu.
(It would show up on any selection, it wouldn't discriminate.)

>
> * Insert bar:
> This is an idea from Ooo 1.0, I think. I'd love to know why it was
> abandoned, then, because it probably is a good idea..?
>
> * Live preview:
> An MSO idea. I am unsure how much I like it, but I am pretty sure that
> developers will protest at its resource usage. The idea is also not
> very detailed.
>
That was an older idea that really isn't that necessary. I'm all for saving
resources.

>
> * Color-coded icons:
> This is a really good idea. But, I think, the codification is wrong.
> Currently there are too many shades that are so close to each other
> that no user will associate them with their underlying functional
> aspect. Similar shades would appear clustered in certain application
> (textual shades → Writer).

That was kind of a point: that way, Writer would have an associated blue
color, Calc a green color (green for tables), Impress an orange color
(images), and Draw a yellow color (shapes), just based on the kind of items
you work with most in these applications. Hue represents category (whether
the object is mostly visual, audible, textual, numerical, or a combination
of these), darkness shows hierarchy ("Page" is superior to "Paragraph",
which is superior to "Text", so "Page" is darkest and "Text" lightest) and
contrast shows relevance (a paragraph can not only contain text, but also
an image, although its primary purpose is still holding text, so its color
has less contrast than that of a text box, which can contain only text).

> Two ideas:
> → reduce the shades to only a few (~5)
> → maybe use menu titles as the basis for which command should have an
> icon of which shade (one for file actions, one for editing, viewing,
> formatting...)
>
It does use menu titles as the basis, only the titles of the menus proposed
for citrus. If it used the current menu titles, most toolbar icons would
end up based on a single color, no matter what the toolbar would pertain
to, as the toolbar holds mostly formatting commands.

> I'd love to see if such a colour coding system is viable. I'd also
> love to know if it is problematic for colour-blind or otherwise
> visually impaired users.
>
As problematic as the current scheme, if not less.
This icon theme would have a lot of black-on-white (or white-on-black,
depending on the user's theme) icons, which have high contrast and are
great for visually impaired users.
Restricting a single icon's color scheme to only three shades allows for
better automatization: making a variant for dark themes could be as simple
as making a script to turn all the black shapes into white shapes (and
maybe to brighten up the object's color too), shading could be automated
also. Making a high-contrast theme would also be easy: just turn the
object's color into black (or white with an inverted HC theme) and lose the
shading.
Much simpler than with multi-colored icons.

> By the way, building such an icon set is something the design team can
> do on its own (all you need is a zipping tool, graphics software, a
> file manager and lots of time) – so it could be the first part of
> Citrus that would actually be implemented.
>
On the other hand, it would be a lot of work. A lot more, I think, than
implementing the "Add page/slide" button...
Not only that, we'd also need to make sure that the designers can make
similar enough icons, so that there's no obvious difference between one
designer's work and another's.

>
> * Reduced standard toolbar:
> I agree, mostly. I think Print is essential though. I always hide
> Email (because I am a bit of a Ctrl frk and always open documents
> again before sending, then drag/drop them from the file manager into
> the mail application), but I think many people would see Email as
> equally essential.
> Finally, there is a command that I often use, but that doesn't fit the
> standard toolbar even today: Non-printing Characters. Where could it
> go or do we not need it in the toolbar? (I am assuming the Gallery
> would become part of the Insert toolbar – is that correct?)
>
There are a lot of commands that could go in here. I recently found myself
using "Export to PDF" in Draw, as I needed to add a signature to about 25
PDF's and there was no keyboard shortcut for this command.
Before we reduce the standard toolbar, I recommend adding in more
shortcuts, so ALL commands are equally accessible by keyboard.
(Surprisingly, even google Docs seems to outperform LibO in this respect,
offering shortcuts for styles, for superscripts/subscripts, and making
Ctrl-Shift-Z as well as Ctrl-Y redo; I use these a ton.)

>
> * Drop-down buttons:
> Creates a lot of functional inconsistency, I don't think users would
> like it. But we can agree on the direction of the arrows.


I know it creates a bit of inconsistency between vertical and horizontal
toolbars, but at least it makes vertical toolbars usable. Honestly, a
vertical Drawing toolbar is pretty unusable right now.

>
>
> * Sorting out commands:
> Good principles, basically, but probably too rough to be usable in
> their current form. Point two (no greyed-out buttons) is contradictory
> to the reasoning found under Reduced standard toolbar (clickable
> buttons as indicators).
> Also, this is part of the proposal is throwing (useful) conventions
> out of the window: should we really move Cut, Copy and Paste into
> completely different menus?
>

Why not? They're used in different situations. You can only use "Copy" and
"Cut" when you have something selected. And you can only use "Paste" when
you're in an editable field. "Paste" therefore fits perfectly under
"Insert", while "Cut" and "Copy" fit well under a contextual menu/toolbar.
Sure it takes a little while to get used to, but it really makes much more
sense than a generic "Edit" menu.

>
> * Getting rid of formatting dialogs:
> Granted, I am biased here [1], but I don't like interacting with menus
> in this way at all, even though that's something Microsoft Office
> makes heavy use of.
> It is also a huge, huge, huge amount of work for an unclear (to me)
> benefit. Two disadvantages of relying so much on rich menus:
> → opening menus to change anything all the time should be pretty annoying
>
that's why toolbars contain the same commands as menus: so that you could
do everything quickly, right in the toolbar

> → customising styles is made very hard (we should want people to use
> styles, so they can create more coherent looking documents more
> easily!)
>
how so? You simply push "Edit" and edit the formatting options.

>
> * Combining navigator and side pane.
> I never actually use the Navigator, but I think that's an idea (a very
> rough one, though) worth investigating.


I've only used it in Writer, and it always seemed so much more complex than
it had to be. I wouldn't call myself a pro user, though.

> * Simplified Options:
> I am pseudo-actively working on a proposal here [2], so yes, absolutely.




> * Rich menus:
> In principle, yes, but I wouldn't base the whole UI on them (rf.
> Getting rid of formatting dialogs).
>
Me neither. I'm actually backing away from rich menus right now, as they
break most operating system's UI guidelines and they probably wouldn't be
very cross-platform. (I don't think Mac OS X or Ubuntu Unity's menu bar
would allow these rich menus.)
On the other hand, they would be pretty useful if they were implemented on
at least some platforms...

>
> Overall, this proposal is quite coherent (and radical and creative)
> and that's all good, but there are still too many loose ends hanging
> around.
> Blip.
> Astron.
>

P. S.  -- , so I probably won't read or answer other mails on the mailing
list today (there are quite a few unread mails), as I just came back from a
permaculture seminar and now I have some work to do and then a lot of sleep.
This one e-mail just got my attention. :)

>
>
> [1]
> http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout
> [2] http://wiki.documentfoundation.org/Design/Whiteboards/OptionsRework


>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

>
> Astron, team


 a few days ago, Andrew asked for feedback on Mirek's Citrus proposal.
> So, here, I want to start a thread on what I/we like and what I/we
> don't like (about the desktop/laptop proposal), in the hope that it
> helps Mirek to refine his proposal. Please note, I am not a regular
> reader of Mirek's blog and my assumptions are based on the short
> descriptions from the wiki, so if anything on this list seems wrong to
> you, feel free to correct me.

Here we go, structure is as on Mirek2's wiki page:


thank you so much Astron for taking the time and starting this. I
was begging to think that no one would help with this. some people have
said that they have problems with it but have not said what. so thank you.
I would read his blog, he goes into so much more detail. plus you get the
evolution of it and ideas that he thought of but has scraped but may still
be useful.


> * Ellipsis menu:
> I like the idea and it looks much better (cleaner) than it does
> currently; for executing commands it is also more functional.
> Here's what I don't like: that you can customise your toolbar via
> drag-and-drop is not made visible at all; for users of accessibility
> solutions there seems to be no way to add or remove something.


Mirek this is what I was trying to say about the Ellipsis menu. I as well I
like it but it is not immediately/at all apparent that you can drag and
drop the menu items. I do not know how we can fix this.

The ellipsis menu wouldn't be the only way a toolbar could be customized.
> If the ellipsis menu was implemented in today's LibreOffice, there would
> still be a link to the Customize dialog in the menubar and the toolbar's
> right-click menu.


ok but what do you think about putting a customize or like the
current viable buttons.

* Page/slide handles:
> I like the idea (so much I opened a bug about it – fdo#38597). There's
> a lot to discuss, though, before this can be implemented (how it
> zooms, how it acts, etc.). Also, the proposal doesn't work at all for
> Calc (which Mirek explained, he uses so seldomly that he didn't
> include it in his proposals).


for the zooming I have mocked that it would just get pushed to the side.
after a serten zoom level it could go above the page but that mite be
weird. as for not working for calc are you refering to not being able to
select a print page?  if not and you are talking about selecting all the
cells you can do this now, just double click on the top right corner where
"1" and "A" meat. if you are refereing to the page numbers, there are going
to be tabs still at the bottom like it is now. and as for Mirek not using
it so much that where I have stepped in and im sure the rest of the team
will help. the hard part is figuring out how the menus and tool bars will
work, he has made some grate mock ups for writer and impress but its hard
traslating the current menus into his menus.


> It shouldn't be in Calc, at least not with how Calc works now.
> I don't think Calc lets you change page formatting for each page
> separately, so being able to select separate pages would be of no use. (You
> can select the whole table with the blank top-left corner cell, though.)
> And Calc already has a way of showing page number under Page view,
> different from how all the other LibO apps show page number.


like I said you can select all the cells at once, but yes you would not
want to format this way. well you could do every other row/column a
different color formatting, but this is the only thing you would want to
format the entire sheet for.

* Continuously scrollable slides:
> Not a bad idea for the read-only mode. When editing a document,
> however, there will sometimes be the case that an image or other
> element would overlap into the next slide. What should LibO do then?
> Push the slide further below? Cut the element off in between the two
> slides? I'm sceptical.


I was thinking of this my self and have come up with some things that mite
be a good option.

proposal
so your on slide one, slide two would be graid out to indicate that you are
only editing slide one. all things off to the side of slide one will not
effect slide 2. once you scroll down and the majority of the screen is off
slide 1 and on slide 2, all slide 1 things out side the slide will
disappear, slide 1 will fade to gray and slide 2 will unfade. what do you
think about this?


> * Add page/slide:

I can see this being very useful in Impress and Draw, but in those
> programs, I would probably put this button into the sidebar.
> For Writer, it would be similarly useful, but we'd also need more
> complexity: it'd need at least a "Add page" and an "Add Section"
> button (unless there is any way in which we can make those two
> commands the same).


HAAA Mirek I told you, lol. this has changed some... well a lot. if you
look at my newest mock up edit, I have changed this for writer[1].
he needs to work on the wiki to show these updaits... sorry for puting
stuff on you Mirek, I could do some of it if you do not have the time to
work on all of this. sucks it needs updated in like three or four places

There is no sidebar for Impress/Draw in Citrus (unless you mean the
> Navigator). The point of this button is to have a button inline, so that a
> user didn't have to have a sidebar open to get this core functionality.
> That's especially useful when working on a small screen and/or with two
> windows side-by-side (which I have quite often).


Mirek what does inline to you mean, because it means in the text lines to
me. what are you talking about when you say that.

Mirek are you saying that there is no insertion bar on the side for
impress/draw. if so why, if not what bar are you talking about.

It's in the more recent proposal (add page is centered on the left half,
> add section on the right half). :)


ok so you like what I did in my latest mock up. could you reply to my email
thread about the changes in the mock up i made. I know that you do not have
a lot of time on your hands. lets keep this one for complaints and that one
about the mockups.

*Float bar:

> I'm not sure that I heavily subscribe to this – there is a similar bar
> in the Pencil extension for Firefox that I use for mock-ups that pops
> up when one edits certain text fields.
> I think the most important aspect for the float bar is that it keeps a
> large enough distance from the element, so it doesn't annoy the user
> or gets in the way; and still is not positioned so far from the
> element that the user thinks it doesn't belong o the element any more.
> There are a few other positioning questions that need to be solved: if
> the element covers the entire screen, where would the float bar be
> least in the way (it can either cover the element itself or cover the
> docked toolbars or maybe could be positioned vertically) ... what's
> the best option?


wow I did not think of some of those. I totally agree with you, the float
bar needs to stay out of the way of the object you are editing. this is a
big problem with the current float bar.

The whole point of the float bar is to be as close to the selection without
> covering it, so as to minimize mouse distance. That's the reason for having
> it. Otherwise, there is no difference between it and the toolbar -- it can
> only contain the same commands as the toolbar. And just like the toolbar,
> it could be hidden/shown in the "View" menu.
> (It would show up on any selection, it wouldn't discriminate.)


good my brother has a problem with the current floatbar, he says that if it
is not covering the selection then it will be better, and that he will try
it. but he wanted a way to hide it, I said that there would be a way but
was not sure how. I like this float bar much better then our current one.

* Color-coded icons:

> This is a really good idea. But, I think, the codification is wrong.
> Currently there are too many shades that are so close to each other
> that no user will associate them with their underlying functional
> aspect. Similar shades would appear clustered in certain application
> (textual shades → Writer). Two ideas:
> → reduce the shades to only a few (~5)
> → maybe use menu titles as the basis for which command should have an
> icon of which shade (one for file actions, one for editing, viewing,
> formatting...)
> I'd love to see if such a colour coding system is viable. I'd also
> love to know if it is problematic for colour-blind or otherwise
> visually impaired users.
> By the way, building such an icon set is something the design team can
> do on its own (all you need is a zipping tool, graphics software, a
> file manager and lots of time) – so it could be the first part of
> Citrus that would actually be implemented.


I have not looked at this section in a long time. when I see this color
coding I think that the intire program should have the same color. EX
writer, should have all blue UI elements, calc should have all green UI
elements. I think that it would just look cool if all the icons went with
the program you are in. this would mean for example that in writer when
selecting text the selection would be blue, where as in calc selecting text
the selection would be green. EX2 the b's above and below the A's in the
super and sub scrips icons, in writer they would be blue, but in calc they
would be green.  I am designing my own program, and all of the UI elements
are teal, it just looks cool for every thing to have the same color. I do
not know why I feel this way, it just looks cool. just an idea.

That was kind of a point: that way, Writer would have an associated blue
> color, Calc a green color (green for tables), Impress an orange color
> (images), and Draw a yellow color (shapes), just based on the kind of items
> you work with most in these applications. Hue represents category (whether
> the object is mostly visual, audible, textual, numerical, or a combination
> of these), darkness shows hierarchy ("Page" is superior to "Paragraph",
> which is superior to "Text", so "Page" is darkest and "Text" lightest) and
> contrast shows relevance (a paragraph can not only contain text, but also
> an image, although its primary purpose is still holding text, so its color
> has less contrast than that of a text box, which can contain only text).


... so was I right with what I said. or do you have tables being green in
writer as well.


* Drop-down buttons:
> Creates a lot of functional inconsistency, I don't think users would
> like it. But we can agree on the direction of the arrows.


what wont users like, that the drop-down buttons come out the side of the
button instead of down.

 * Sorting out commands:
> Good principles, basically, but probably too rough to be usable in
> their current form. Point two (no greyed-out buttons) is contradictory
> to the reasoning found under Reduced standard toolbar (clickable
> buttons as indicators).
> Also, this is part of the proposal is throwing (useful) conventions
> out of the window: should we really move Cut, Copy and Paste into
> completely different menus?


the hole thing about Citrus is that is is contextual, and the past is a
insert function so it should go into the insert menu, cut and copy are not
insertion method and do not belong there. not many people use the menu bar
to cut, copy, and past any way.

Why not? They're used in different situations. You can only use "Copy" and
> "Cut" when you have something selected. And you can only use "Paste" when
> you're in an editable field. "Paste" therefore fits perfectly under
> "Insert", while "Cut" and "Copy" fit well under a contextual menu/toolbar.
> Sure it takes a little while to get used to, but it really makes much more
> sense than a generic "Edit" menu.


I have to agree with Mirek. this makes a lot of sense once you get used to
it. why do you need a cut or copy if nothing is selected.


> * Simplified Options:
> I am pseudo-actively working on a proposal here [2], so yes, absolutely.


ooooo, shiny. I like how you have separated the general options and then
made each programs options available in all programs I assume.  I will like
this because I like to look through and change my options when I first
start a new program and the ability to change all the options in one
sitting and not have to open all of them would be nice. you have made a
grate mock up. I have had a problem with our options seance the first time
I opened them.


again thank you for starting this thread. I hope that others will join and
follow what you have done. from here read some of his blog and look at our
mock ups. again my mock up is [1] and he has not made an update to what I
have done yet so just wait till he emails the update.

cheers,
Andrew

[1]
https://docs.google.com/open?id=0B7y5FMHPsyaNNGJkZDY0ZDItOGNhNi00MzMzLThlNTUtZWU2ZmIyMmYyZmJi

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Some Feedback on Citrus.

Hi Andrew, everyone,

Am Dienstag, 1. November 2011 schrieb Andrew Pullins :

> >
> > Astron, team
>
>
>  a few days ago, Andrew asked for feedback on Mirek's Citrus proposal.
> > So, here, I want to start a thread on what I/we like and what I/we
> > don't like (about the desktop/laptop proposal), in the hope that it
> > helps Mirek to refine his proposal. Please note, I am not a regular
> > reader of Mirek's blog and my assumptions are based on the short
> > descriptions from the wiki, so if anything on this list seems wrong to
> > you, feel free to correct me.
>
> Here we go, structure is as on Mirek2's wiki page:
>
>
> thank you so much Astron for taking the time and starting this. I
> was begging to think that no one would help with this. some people have
> said that they have problems with it but have not said what. so thank you.
> I would read his blog, he goes into so much more detail. plus you get the
> evolution of it and ideas that he thought of but has scraped but may still
> be useful.
>
>
> > * Ellipsis menu:
> > I like the idea and it looks much better (cleaner) than it does
> > currently; for executing commands it is also more functional.
> > Here's what I don't like: that you can customise your toolbar via
> > drag-and-drop is not made visible at all; for users of accessibility
> > solutions there seems to be no way to add or remove something.
>
>
> Mirek this is what I was trying to say about the Ellipsis menu. I as well I
> like it but it is not immediately/at all apparent that you can drag and
> drop the menu items. I do not know how we can fix this.
>

I guess there could be a Customize button at the bottom of the Ellipsis
menu then. :)

>
> The ellipsis menu wouldn't be the only way a toolbar could be customized.
> > If the ellipsis menu was implemented in today's LibreOffice, there would
> > still be a link to the Customize dialog in the menubar and the toolbar's
> > right-click menu.
>
>
> ok but what do you think about putting a customize or like the
> current viable buttons.
>
> * Page/slide handles:
> > I like the idea (so much I opened a bug about it – fdo#38597). There's
> > a lot to discuss, though, before this can be implemented (how it
> > zooms, how it acts, etc.). Also, the proposal doesn't work at all for
> > Calc (which Mirek explained, he uses so seldomly that he didn't
> > include it in his proposals).
>
>
> for the zooming I have mocked that it would just get pushed to the side.
> after a serten zoom level it could go above the page but that mite be
> weird. as for not working for calc are you refering to not being able to
> select a print page?  if not and you are talking about selecting all the
> cells you can do this now, just double click on the top right corner where
> "1" and "A" meat. if you are refereing to the page numbers, there are going
> to be tabs still at the bottom like it is now. and as for Mirek not using
> it so much that where I have stepped in and im sure the rest of the team
> will help. the hard part is figuring out how the menus and tool bars will
> work, he has made some grate mock ups for writer and impress but its hard
> traslating the current menus into his menus.
>
>
> > It shouldn't be in Calc, at least not with how Calc works now.
> > I don't think Calc lets you change page formatting for each page
> > separately, so being able to select separate pages would be of no use.
> (You
> > can select the whole table with the blank top-left corner cell, though.)
> > And Calc already has a way of showing page number under Page view,
> > different from how all the other LibO apps show page number.
>
>
> like I said you can select all the cells at once, but yes you would not
> want to format this way. well you could do every other row/column a
> different color formatting, but this is the only thing you would want to
> format the entire sheet for.
>
> * Continuously scrollable slides:
> > Not a bad idea for the read-only mode. When editing a document,
> > however, there will sometimes be the case that an image or other
> > element would overlap into the next slide. What should LibO do then?
> > Push the slide further below? Cut the element off in between the two
> > slides? I'm sceptical.
>
>
> I was thinking of this my self and have come up with some things that mite
> be a good option.
>
> proposal
> so your on slide one, slide two would be graid out to indicate that you are
> only editing slide one. all things off to the side of slide one will not
> effect slide 2. once you scroll down and the majority of the screen is off
> slide 1 and on slide 2, all slide 1 things out side the slide will
> disappear, slide 1 will fade to gray and slide 2 will unfade. what do you
> think about this?
>
> I like it, but I wouldn't fade it to gray entirely, I'd just make it more
transparent/have less contrast, so that you could still see two slides at
once, but you could immediately tell which one was active.

>
> > * Add page/slide:
>
> I can see this being very useful in Impress and Draw, but in those
> > programs, I would probably put this button into the sidebar.
> > For Writer, it would be similarly useful, but we'd also need more
> > complexity: it'd need at least a "Add page" and an "Add Section"
> > button (unless there is any way in which we can make those two
> > commands the same).
>
>
> HAAA Mirek I told you, lol. this has changed some... well a lot. if you
> look at my newest mock up edit, I have changed this for writer[1].
> he needs to work on the wiki to show these updaits... sorry for puting
> stuff on you Mirek, I could do some of it if you do not have the time to
> work on all of this. sucks it needs updated in like three or four places
>
If you could write down the places that need updating, that'd be great. I
have so much stuff to add and don't really know where to begin.

>
> There is no sidebar for Impress/Draw in Citrus (unless you mean the
> > Navigator). The point of this button is to have a button inline, so that
> a
> > user didn't have to have a sidebar open to get this core functionality.
> > That's especially useful when working on a small screen and/or with two
> > windows side-by-side (which I have quite often).
>
>
> Mirek what does inline to you mean, because it means in the text lines to
> me. what are you talking about when you say that.
>
Here I mean right within the main application frame/section, where the
focus is, where the author is working. I may be using the word wrong,
though.

>
> Mirek are you saying that there is no insertion bar on the side for
> impress/draw. if so why, if not what bar are you talking about.
>
There is an insertion bar on the side for Impress/Draw (it's more important
there than in Writer, IMHO).
I don't think I understand the question...

>
> It's in the more recent proposal (add page is centered on the left half,
> > add section on the right half). :)
>
>
> ok so you like what I did in my latest mock up. could you reply to my email
> thread about the changes in the mock up i made. I know that you do not have
> a lot of time on your hands. lets keep this one for complaints and that one
> about the mockups.
>
OK, definitely.
Have to find it first, though.

>
> *Float bar:
> > I'm not sure that I heavily subscribe to this – there is a similar bar
> > in the Pencil extension for Firefox that I use for mock-ups that pops
> > up when one edits certain text fields.
> > I think the most important aspect for the float bar is that it keeps a
> > large enough distance from the element, so it doesn't annoy the user
> > or gets in the way; and still is not positioned so far from the
> > element that the user thinks it doesn't belong o the element any more.
> > There are a few other positioning questions that need to be solved: if
> > the element covers the entire screen, where would the float bar be
> > least in the way (it can either cover the element itself or cover the
> > docked toolbars or maybe could be positioned vertically) ... what's
> > the best option?
>
>
> wow I did not think of some of those. I totally agree with you, the float
> bar needs to stay out of the way of the object you are editing. this is a
> big problem with the current float bar.
>
> The whole point of the float bar is to be as close to the selection without
> > covering it, so as to minimize mouse distance. That's the reason for
> having
> > it. Otherwise, there is no difference between it and the toolbar -- it
> can
> > only contain the same commands as the toolbar. And just like the toolbar,
> > it could be hidden/shown in the "View" menu.
> > (It would show up on any selection, it wouldn't discriminate.)
>
>
> good my brother has a problem with the current floatbar, he says that if it
> is not covering the selection then it will be better, and that he will try
> it. but he wanted a way to hide it, I said that there would be a way but
> was not sure how.

Through the View menu, if it ever becomes reality. I've had the same
problem.

> I like this float bar much better then our current one.
>
> * Color-coded icons:
> > This is a really good idea. But, I think, the codification is wrong.
> > Currently there are too many shades that are so close to each other
> > that no user will associate them with their underlying functional
> > aspect. Similar shades would appear clustered in certain application
> > (textual shades → Writer). Two ideas:
> > → reduce the shades to only a few (~5)
> > → maybe use menu titles as the basis for which command should have an
> > icon of which shade (one for file actions, one for editing, viewing,
> > formatting...)
> > I'd love to see if such a colour coding system is viable. I'd also
> > love to know if it is problematic for colour-blind or otherwise
> > visually impaired users.
> > By the way, building such an icon set is something the design team can
> > do on its own (all you need is a zipping tool, graphics software, a
> > file manager and lots of time) – so it could be the first part of
> > Citrus that would actually be implemented.
>
>
> I have not looked at this section in a long time. when I see this color
> coding I think that the intire program should have the same color. EX
> writer, should have all blue UI elements, calc should have all green UI
> elements. I think that it would just look cool if all the icons went with
> the program you are in. this would mean for example that in writer when
> selecting text the selection would be blue, where as in calc selecting text
> the selection would be green. EX2 the b's above and below the A's in the
> super and sub scrips icons, in writer they would be blue, but in calc they
> would be green.  I am designing my own program, and all of the UI elements
> are teal, it just looks cool for every thing to have the same color. I do
> not know why I feel this way, it just looks cool. just an idea.




> That was kind of a point: that way, Writer would have an associated blue
> > color, Calc a green color (green for tables), Impress an orange color
> > (images), and Draw a yellow color (shapes), just based on the kind of
> items
> > you work with most in these applications. Hue represents category
> (whether
> > the object is mostly visual, audible, textual, numerical, or a
> combination
> > of these), darkness shows hierarchy ("Page" is superior to "Paragraph",
> > which is superior to "Text", so "Page" is darkest and "Text" lightest)
> and
> > contrast shows relevance (a paragraph can not only contain text, but also
> > an image, although its primary purpose is still holding text, so its
> color
> > has less contrast than that of a text box, which can contain only text).
>
>
> ... so was I right with what I said. or do you have tables being green in
> writer as well.
>

Tables are green in Writer as well, yes. And images orange. That way, you
always know what you have selected, what you're working with, and you start
associating green with tables and orange with images and yellow with
shapes. And that way, you'll remember that Calc (green) is the table
program, Draw (yellow) the shape program, etc.

I personally don't want to have a different color scheme for the different
LibO modules, I want them to feel like parts of a whole, with just
different "papers". I would also like to conform to the system theme as
much as possible (very important on Linux).

>
>
> * Drop-down buttons:
> > Creates a lot of functional inconsistency, I don't think users would
> > like it. But we can agree on the direction of the arrows.
>
>
> what wont users like, that the drop-down buttons come out the side of the
> button instead of down.
>
>  * Sorting out commands:
> > Good principles, basically, but probably too rough to be usable in
> > their current form. Point two (no greyed-out buttons) is contradictory
> > to the reasoning found under Reduced standard toolbar (clickable
> > buttons as indicators).
> > Also, this is part of the proposal is throwing (useful) conventions
> > out of the window: should we really move Cut, Copy and Paste into
> > completely different menus?
>
>
> the hole thing about Citrus is that is is contextual, and the past is a
> insert function so it should go into the insert menu, cut and copy are not
> insertion method and do not belong there. not many people use the menu bar
> to cut, copy, and past any way.
>
> Why not? They're used in different situations. You can only use "Copy" and
> > "Cut" when you have something selected. And you can only use "Paste" when
> > you're in an editable field. "Paste" therefore fits perfectly under
> > "Insert", while "Cut" and "Copy" fit well under a contextual
> menu/toolbar.
> > Sure it takes a little while to get used to, but it really makes much
> more
> > sense than a generic "Edit" menu.
>
>
> I have to agree with Mirek. this makes a lot of sense once you get used to
> it. why do you need a cut or copy if nothing is selected.
>
>
> > * Simplified Options:
> > I am pseudo-actively working on a proposal here [2], so yes, absolutely.
>
>
> ooooo, shiny. I like how you have separated the general options and then
> made each programs options available in all programs I assume.  I will like
> this because I like to look through and change my options when I first
> start a new program and the ability to change all the options in one
> sitting and not have to open all of them would be nice. you have made a
> grate mock up. I have had a problem with our options seance the first time
> I opened them.
>
>
> again thank you for starting this thread. I hope that others will join and
> follow what you have done. from here read some of his blog and look at our
> mock ups. again my mock up is [1] and he has not made an update to what I
> have done yet so just wait till he emails the update.
>
> cheers,
> Andrew
>
> [1]
>
> https://docs.google.com/open?id=0B7y5FMHPsyaNNGJkZDY0ZDItOGNhNi00MzMzLThlNTUtZWU2ZmIyMmYyZmJi
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>


--
Q: Why is this email five sentences or less?
A: http://five.sentenc.es

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

HI,

If you could write down the places that need updating, that'd be great. I
> have so much stuff to add and don't really know where to begin.


well some of the things on your LibreWiki page has gone with out an update
for a while. things have changed so much since you last changed it. as for
what can change the "Add page/slide" button and Live preview sections are
things that immediately jump out as needs to be changed.

Here I mean right within the main application frame/section, where the
> focus is, where the author is working. I may be using the word wrong,
> though.


thanks for clearing that up. I figured that was what you mean but was not
sure.

There is an insertion bar on the side for Impress/Draw (it's more important
> there than in Writer, IMHO).
> I don't think I understand the question...


in your reponse to Astron who said

* Add page/slide:
> I can see this being very useful in Impress and Draw, but in those
> programs, I would probably put this button into the sidebar.


you replied

 There is no sidebar for Impress/Draw in Citrus (unless you mean the
> Navigator). The point of this button is to have a button inline, so that a
> user didn't have to have a sidebar open to get this core functionality.
> That's especially useful when working on a small screen and/or with two
> windows side-by-side (which I have quite often).


I wanted to know if you were referring to the insertion bar. I thought that
the insertions bar was made for all the programs.

> ok so you like what I did in my latest mock up. could you reply to my
email
> thread about the changes in the mock up i made. I know that you do not
have
> a lot of time on your hands. lets keep this one for complaints and that
one
> about the mockups.

 OK, definitely.
> Have to find it first, though.


if you need my addition here it is [1]

Tables are green in Writer as well, yes. And images orange. That way, you
> always know what you have selected, what you're working with, and you start
> associating green with tables and orange with images and yellow with
> shapes. And that way, you'll remember that Calc (green) is the table
> program, Draw (yellow) the shape program, etc.


> I personally don't want to have a different color scheme for the different
> LibO modules, I want them to feel like parts of a whole, with just
> different "papers". I would also like to conform to the system theme as
> much as possible (very important on Linux).


I just thought that it would look cool. but I see what you are trying to
achieve with the color schemes.



[1]
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7y5FMHPsyaNN2RiNzU1MTItZTAyNy00NmZlLTk1MGQtY2VlZmQ1OTYyOTM3&hl=en_US

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Kévin PEIGNOT-3 Kévin PEIGNOT-3
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

In reply to this post by Stefan Knorr (Astron)
2011/10/30 Astron <[hidden email]>

> Hi everyone,
>
> a few days ago, Andrew asked for feedback on Mirek's Citrus proposal.
> So, here, I want to start a thread on what I/we like and what I/we
> don't like (about the desktop/laptop proposal), in the hope that it
> helps Mirek to refine his proposal. Please note, I am not a regular
> reader of Mirek's blog and my assumptions are based on the short
> descriptions from the wiki, so if anything on this list seems wrong to
> you, feel free to correct me.
> Here we go, structure is as on Mirek2's wiki page:
>
To gain time, I choosed to use the same structure.

>
> * Ellipsis menu:
> I like the idea and it looks much better (cleaner) than it does
> currently; for executing commands it is also more functional.
> Here's what I don't like: that you can customise your toolbar via
> drag-and-drop is not made visible at all; for users of accessibility
> solutions there seems to be no way to add or remove something.
>
I must say I agree with this. It's a great idea. Here a proposal of
solution : At the end of the toolbar, after the menu button, menu,
integrate an ellement with a "?" button. When a user click on it, a pop-up
appear with the tip, saying that drag'n-dropping is the way to proceed

* Page/slide handles:
> I like the idea (so much I opened a bug about it – fdo#38597). There's
> a lot to discuss, though, before this can be implemented (how it
> zooms, how it acts, etc.). Also, the proposal doesn't work at all for
> Calc (which Mirek explained, he uses so seldomly that he didn't
> include it in his proposals).
>
 Honestly I don't really see what is the point there. Do you have a
detailled article/page somewhere, I didn't find (I suppose I didn't
searched in the right place)


>
> * Continuously scrollable slides:
> Not a bad idea for the read-only mode. When editing a document,
> however, there will sometimes be the case that an image or other
> element would overlap into the next slide. What should LibO do then?
> Push the slide further below? Cut the element off in between the two
> slides? I'm sceptical.
>
I agree, I usually have some parts of my slides that are "out of the
slide", sometimes below, because it can be a movable picture that come half
from the bottom .... SO personally, I think it's a bad idea.



> * Add page/slide:
> I can see this being very useful in Impress and Draw, but in those
> programs, I would probably put this button into the sidebar.
> For Writer, it would be similarly useful, but we'd also need more
> complexity: it'd need at least a "Add page" and an "Add Section"
> button (unless there is any way in which we can make those two
> commands the same).
>
> It's just great as it is in the mock-up. It's simple, and exactly were you
need it. But I think that even if this is a great point, It should stay in
the left insert toolbar too. (some people will search it there I think)


*Float bar:
>
I'm absolutely in ! Then in the case the element you select take all the
screen, maybe putting the  in the top of the element : On the right by
default, with a button that switch it to the left if you want it there (or
maybe by "drag and dropping" the float bar from right to left ?). I don't
have time to make a mockup, but if you want one just ask I will try during
the week-end



> * Insert bar:
> This is an idea from Ooo 1.0, I think. I'd love to know why it was
> abandoned, then, because it probably is a good idea..?
>
Personally I always use it, and in the left of the screen, just as in your
proposal. Too useful ! So I don't see why it has been abandonnated. Maybe
it wasn't used enough according the "clic-map".



> * Live preview:
>
If it means updating the whole document I think it's a bad idea (I suppose
it would need too much resource). But if it's in a "preview box", then, I'm
in. One think that I don't like today is that in the format toolbar, the
fonts are described by there name, no preview. This is the little start of
a "live preview".



> * Color-coded icons:
>
Good idea, I think your color scheme proposal is great. Then, I think we
should brainstorm about it : for me, Red means *"Hy, I need attention" *,
so maybe this color shouldn't be used ?

More of that, I'm not sure that this is so useful : The icons concerning
text shoud appear only when text is selected, same with images, videos...
what do you think ?

PS : Re thinking the thing : I was wrong : you can select zones with both
pictures and audio



> * Reduced standard toolbar:
>
I almost agree, except that I don't understand where you would put
print/export in this case ? I personnaly use these two options every time
(I export to PDF every 30 minutes because of problems I had with odt files
in the past)



> * Drop-down buttons:
>
No special thought. To be honest I don't know if it's a good or bad idea.



> * Sorting out commands:
> Good principles, basically, but probably too rough to be usable in
> their current form. Point two (no greyed-out buttons) is contradictory
> to the reasoning found under Reduced standard toolbar (click-able
> buttons as indicators).
> Also, this is part of the proposal is throwing (useful) conventions
> out of the window: should we really move Cut, Copy and Paste into
> completely different menus?
>
I think the current menus, even if not perfect are great. The Edit menu is
especially useful I think. Then, if everything in this menu can be found in
the floatbar or other places (like text menu when text is selected for
copy/cut or insert menu to paste), then, perfect !


* Getting rid of formatting dialogs :
>
Granted, I am biased here [1], but I don't like interacting with menus
> in this way at all, even though that's something Microsoft Office
> makes heavy use of.
> It is also a huge, huge, huge amount of work for an unclear (to me)
> benefit. Two disadvantages of relying so much on rich menus:
> → opening menus to change anything all the time should be pretty annoying
> → customising styles is made very hard (we should want people to use
> styles, so they can create more coherent looking documents more
> easily!)
>
Personally, just for me, I think it could be a great idea, because
formatting dialogues would still be available to edit a style. Then, a lot
of people don't use styles AT ALL, and they act directly on the text. To do
this, a formatting dialogue seems me easier : you have everything in the
same window, else you must go to the menu for every change (BOLD, Italic,
color, underline....). Except if the major parts (underline, font/color,
bold, italic....) are in the floatbar or elsewhere easily click-able



> * Combining navigator and side pane.
> I never actually use the Navigator, (I'm probably wrong, I will try to
> force me to use it to see.
>



> * Simplified Options:
>
I would say yes, only if the advanced pane is still available : Look at
Ubuntu  Unity or Gnome Shell (or the whole Gnome 3) : A lot of complaints
is from people who miss options. So don't say we do the simple options
dialogue then the advanced one. I think it's better making the simplest
one, then once finished redesigning (or not) the advanced one which could
stay the actual one.



> * Rich menus:
>
I'm totally in. Then, about Ubuntu (I don't know for Mac OSX), look at the
sound menu : it's an indicator, but it's a menu too and it contains non
traditional menus items. So it must be possible to include them in the
global menu. I'm sure (really sure) that if we can explain Canonical the
Why and the How (maybe based on a survey), they will help us integrate this
(I'm not sure, but it seems me there is a Canonical employee who is
"dedicated" to LibreOffice integration. More of that, going to an UDS to
discuss it would help a lot.


Conclusion :

I really really really Love your proposal, it's the exact direction I would
like to see LibO go : A cleanest UI, using less vertical spacing (just for
this point I hate the Office ribbons (they look just ridiculous on a
netbook or other little screen), with just what we need the most under our
eyes, every thing else in menus, the whole thing being easily configurable
(drag and drop, advanced option dialog) to adapt to every one needs, but
with good defaults. Just what I was thinking !

I'm sorry to be so late to answer, and not to take the time to study better
your proposal (believe me, I would love to have this time), so maybe I
mis-understood some parts. DOn't hesitate to say it to me. I will do my
best to answer any other questions you could have (it should take less time
than 5 weeks, I promise :D ). I'm also sorry for my English which is, I
know, not really perfect (yet ?), I'm working on this. If you don't
understand what I say, just ask, I will try to explain my idea (maybe I
just mis-understood your proposal too, so my answer would be stupid and out
of place, I hope this won't happen too much).

Anyway, Thank you Mirek for this great proposal, which is a really great
start point. I hope we will be able to take it far !

Kévin

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Alexander Wilms Alexander Wilms
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

Hi,

since I just received Kévins mail, I now took the time to browse Mireks proposals more deeply and I have to agree, that's just what I'd like to see :).

There are many great things in those drafts, but I especially like are the color codes and the command reorganization. In addition to the new handling of headers this would make LOs UI much more comfortable to use.

Another aspect I'd like to see integrated are those style groups, but in my opinion a little previw like in Word would be nice, maybe as a popout or that the styles get applied when hovering over each of them. In my opinion, there should be two selections though, one for the group style used (e.g. "My favorite selfmade style") and one for the formatting that gets applied (e.g. Heading 1, Table etc.). I'm not sure but maybe you've already adresses this aspect.

I generally like the idea of focusing on actual writing and letting the formatting be automated or taken care of, thats why I like the ability to export them and the new template manager, which could maybe even being integrated with the online repository, just like the fonts.

Still, there are some issues like flickering icons when hovering over them or flshing black background colors when editing a text in Impress. Those aren't immediately related to this proposal, but I hope this could be eliminated, too. Or have these issues already been adressed in the current development branch?

I am personally looking forward to the command reorg, hopefully we can start working this out very soon :)
Cheers

Alex

---- On Mon, 21 Nov 2011 20:07:06 +0100 Kévin PEIGNOT &lt;[hidden email]&gt; wrote ----


2011/10/30 Astron &lt;[hidden email]&gt;

&gt; Hi everyone,
&gt;
&gt; a few days ago, Andrew asked for feedback on Mirek's Citrus proposal.
&gt; So, here, I want to start a thread on what I/we like and what I/we
&gt; don't like (about the desktop/laptop proposal), in the hope that it
&gt; helps Mirek to refine his proposal. Please note, I am not a regular
&gt; reader of Mirek's blog and my assumptions are based on the short
&gt; descriptions from the wiki, so if anything on this list seems wrong to
&gt; you, feel free to correct me.
&gt; Here we go, structure is as on Mirek2's wiki page:
&gt;
To gain time, I choosed to use the same structure.

&gt;
&gt; * Ellipsis menu:
&gt; I like the idea and it looks much better (cleaner) than it does
&gt; currently; for executing commands it is also more functional.
&gt; Here's what I don't like: that you can customise your toolbar via
&gt; drag-and-drop is not made visible at all; for users of accessibility
&gt; solutions there seems to be no way to add or remove something.
&gt;
I must say I agree with this. It's a great idea. Here a proposal of
solution : At the end of the toolbar, after the menu button, menu,
integrate an ellement with a "?" button. When a user click on it, a pop-up
appear with the tip, saying that drag'n-dropping is the way to proceed

* Page/slide handles:
&gt; I like the idea (so much I opened a bug about it – fdo#38597). There's
&gt; a lot to discuss, though, before this can be implemented (how it
&gt; zooms, how it acts, etc.). Also, the proposal doesn't work at all for
&gt; Calc (which Mirek explained, he uses so seldomly that he didn't
&gt; include it in his proposals).
&gt;
 Honestly I don't really see what is the point there. Do you have a
detailled article/page somewhere, I didn't find (I suppose I didn't
searched in the right place)


&gt;
&gt; * Continuously scrollable slides:
&gt; Not a bad idea for the read-only mode. When editing a document,
&gt; however, there will sometimes be the case that an image or other
&gt; element would overlap into the next slide. What should LibO do then?
&gt; Push the slide further below? Cut the element off in between the two
&gt; slides? I'm sceptical.
&gt;
I agree, I usually have some parts of my slides that are "out of the
slide", sometimes below, because it can be a movable picture that come half
from the bottom .... SO personally, I think it's a bad idea.



&gt; * Add page/slide:
&gt; I can see this being very useful in Impress and Draw, but in those
&gt; programs, I would probably put this button into the sidebar.
&gt; For Writer, it would be similarly useful, but we'd also need more
&gt; complexity: it'd need at least a "Add page" and an "Add Section"
&gt; button (unless there is any way in which we can make those two
&gt; commands the same).
&gt;
&gt; It's just great as it is in the mock-up. It's simple, and exactly were you
need it. But I think that even if this is a great point, It should stay in
the left insert toolbar too. (some people will search it there I think)


*Float bar:
&gt;
I'm absolutely in ! Then in the case the element you select take all the
screen, maybe putting the in the top of the element : On the right by
default, with a button that switch it to the left if you want it there (or
maybe by "drag and dropping" the float bar from right to left ?). I don't
have time to make a mockup, but if you want one just ask I will try during
the week-end



&gt; * Insert bar:
&gt; This is an idea from Ooo 1.0, I think. I'd love to know why it was
&gt; abandoned, then, because it probably is a good idea..?
&gt;
Personally I always use it, and in the left of the screen, just as in your
proposal. Too useful ! So I don't see why it has been abandonnated. Maybe
it wasn't used enough according the "clic-map".



&gt; * Live preview:
&gt;
If it means updating the whole document I think it's a bad idea (I suppose
it would need too much resource). But if it's in a "preview box", then, I'm
in. One think that I don't like today is that in the format toolbar, the
fonts are described by there name, no preview. This is the little start of
a "live preview".



&gt; * Color-coded icons:
&gt;
Good idea, I think your color scheme proposal is great. Then, I think we
should brainstorm about it : for me, Red means *"Hy, I need attention" *,
so maybe this color shouldn't be used ?

More of that, I'm not sure that this is so useful : The icons concerning
text shoud appear only when text is selected, same with images, videos...
what do you think ?

PS : Re thinking the thing : I was wrong : you can select zones with both
pictures and audio



&gt; * Reduced standard toolbar:
&gt;
I almost agree, except that I don't understand where you would put
print/export in this case ? I personnaly use these two options every time
(I export to PDF every 30 minutes because of problems I had with odt files
in the past)



&gt; * Drop-down buttons:
&gt;
No special thought. To be honest I don't know if it's a good or bad idea.



&gt; * Sorting out commands:
&gt; Good principles, basically, but probably too rough to be usable in
&gt; their current form. Point two (no greyed-out buttons) is contradictory
&gt; to the reasoning found under Reduced standard toolbar (click-able
&gt; buttons as indicators).
&gt; Also, this is part of the proposal is throwing (useful) conventions
&gt; out of the window: should we really move Cut, Copy and Paste into
&gt; completely different menus?
&gt;
I think the current menus, even if not perfect are great. The Edit menu is
especially useful I think. Then, if everything in this menu can be found in
the floatbar or other places (like text menu when text is selected for
copy/cut or insert menu to paste), then, perfect !


* Getting rid of formatting dialogs :
&gt;
Granted, I am biased here [1], but I don't like interacting with menus
&gt; in this way at all, even though that's something Microsoft Office
&gt; makes heavy use of.
&gt; It is also a huge, huge, huge amount of work for an unclear (to me)
&gt; benefit. Two disadvantages of relying so much on rich menus:
&gt; → opening menus to change anything all the time should be pretty annoying
&gt; → customising styles is made very hard (we should want people to use
&gt; styles, so they can create more coherent looking documents more
&gt; easily!)
&gt;
Personally, just for me, I think it could be a great idea, because
formatting dialogues would still be available to edit a style. Then, a lot
of people don't use styles AT ALL, and they act directly on the text. To do
this, a formatting dialogue seems me easier : you have everything in the
same window, else you must go to the menu for every change (BOLD, Italic,
color, underline....). Except if the major parts (underline, font/color,
bold, italic....) are in the floatbar or elsewhere easily click-able



&gt; * Combining navigator and side pane.
&gt; I never actually use the Navigator, (I'm probably wrong, I will try to
&gt; force me to use it to see.
&gt;



&gt; * Simplified Options:
&gt;
I would say yes, only if the advanced pane is still available : Look at
Ubuntu Unity or Gnome Shell (or the whole Gnome 3) : A lot of complaints
is from people who miss options. So don't say we do the simple options
dialogue then the advanced one. I think it's better making the simplest
one, then once finished redesigning (or not) the advanced one which could
stay the actual one.



&gt; * Rich menus:
&gt;
I'm totally in. Then, about Ubuntu (I don't know for Mac OSX), look at the
sound menu : it's an indicator, but it's a menu too and it contains non
traditional menus items. So it must be possible to include them in the
global menu. I'm sure (really sure) that if we can explain Canonical the
Why and the How (maybe based on a survey), they will help us integrate this
(I'm not sure, but it seems me there is a Canonical employee who is
"dedicated" to LibreOffice integration. More of that, going to an UDS to
discuss it would help a lot.


Conclusion :

I really really really Love your proposal, it's the exact direction I would
like to see LibO go : A cleanest UI, using less vertical spacing (just for
this point I hate the Office ribbons (they look just ridiculous on a
netbook or other little screen), with just what we need the most under our
eyes, every thing else in menus, the whole thing being easily configurable
(drag and drop, advanced option dialog) to adapt to every one needs, but
with good defaults. Just what I was thinking !

I'm sorry to be so late to answer, and not to take the time to study better
your proposal (believe me, I would love to have this time), so maybe I
mis-understood some parts. DOn't hesitate to say it to me. I will do my
best to answer any other questions you could have (it should take less time
than 5 weeks, I promise :D ). I'm also sorry for my English which is, I
know, not really perfect (yet ?), I'm working on this. If you don't
understand what I say, just ask, I will try to explain my idea (maybe I
just mis-understood your proposal too, so my answer would be stupid and out
of place, I hope this won't happen too much).

Anyway, Thank you Mirek for this great proposal, which is a really great
start point. I hope we will be able to take it far !

Kévin

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted


--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Xi Embalsado Xi Embalsado
Reply | Threaded
Open this post in threaded view
|

LibreOffice Icons

In reply to this post by Kévin PEIGNOT-3

>Please include the new 256 pixel Icons. LibreOffice will look ugly on a the Large Icons >view in Windows.>> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be deleted
     
--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Kévin PEIGNOT-3 Kévin PEIGNOT-3
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

In reply to this post by Alexander Wilms
Hy  you wan't feedback on Citrus :

http://www.omgubuntu.co.uk/2011/11/citrus-a-libreoffice-interface-for-today/

This is a good start guys ;)

Kévin

2011/11/21 alexander.wilms <[hidden email]>

> Hi,
>
> since I just received Kévins mail, I now took the time to browse Mireks
> proposals more deeply and I have to agree, that's just what I'd like to see
> :).
>
> There are many great things in those drafts, but I especially like are the
> color codes and the command reorganization. In addition to the new handling
> of headers this would make LOs UI much more comfortable to use.
>
> Another aspect I'd like to see integrated are those style groups, but in
> my opinion a little previw like in Word would be nice, maybe as a popout or
> that the styles get applied when hovering over each of them. In my opinion,
> there should be two selections though, one for the group style used (e.g.
> "My favorite selfmade style") and one for the formatting that gets applied
> (e.g. Heading 1, Table etc.). I'm not sure but maybe you've already
> adresses this aspect.
>
> I generally like the idea of focusing on actual writing and letting the
> formatting be automated or taken care of, thats why I like the ability to
> export them and the new template manager, which could maybe even being
> integrated with the online repository, just like the fonts.
>
> Still, there are some issues like flickering icons when hovering over them
> or flshing black background colors when editing a text in Impress. Those
> aren't immediately related to this proposal, but I hope this could be
> eliminated, too. Or have these issues already been adressed in the current
> development branch?
>
> I am personally looking forward to the command reorg, hopefully we can
> start working this out very soon :)
> Cheers
>
> Alex
>
> ---- On Mon, 21 Nov 2011 20:07:06 +0100 Kévin PEIGNOT &
> lt;[hidden email]&gt; wrote ----
>
>
> 2011/10/30 Astron &lt;[hidden email]&gt;
>
> &gt; Hi everyone,
> &gt;
> &gt; a few days ago, Andrew asked for feedback on Mirek's Citrus proposal.
> &gt; So, here, I want to start a thread on what I/we like and what I/we
> &gt; don't like (about the desktop/laptop proposal), in the hope that it
> &gt; helps Mirek to refine his proposal. Please note, I am not a regular
> &gt; reader of Mirek's blog and my assumptions are based on the short
> &gt; descriptions from the wiki, so if anything on this list seems wrong to
> &gt; you, feel free to correct me.
> &gt; Here we go, structure is as on Mirek2's wiki page:
> &gt;
> To gain time, I choosed to use the same structure.
>
> &gt;
> &gt; * Ellipsis menu:
> &gt; I like the idea and it looks much better (cleaner) than it does
> &gt; currently; for executing commands it is also more functional.
> &gt; Here's what I don't like: that you can customise your toolbar via
> &gt; drag-and-drop is not made visible at all; for users of accessibility
> &gt; solutions there seems to be no way to add or remove something.
> &gt;
> I must say I agree with this. It's a great idea. Here a proposal of
> solution : At the end of the toolbar, after the menu button, menu,
> integrate an ellement with a "?" button. When a user click on it, a pop-up
> appear with the tip, saying that drag'n-dropping is the way to proceed
>
> * Page/slide handles:
> &gt; I like the idea (so much I opened a bug about it – fdo#38597). There's
> &gt; a lot to discuss, though, before this can be implemented (how it
> &gt; zooms, how it acts, etc.). Also, the proposal doesn't work at all for
> &gt; Calc (which Mirek explained, he uses so seldomly that he didn't
> &gt; include it in his proposals).
> &gt;
>  Honestly I don't really see what is the point there. Do you have a
> detailled article/page somewhere, I didn't find (I suppose I didn't
> searched in the right place)
>
>
> &gt;
> &gt; * Continuously scrollable slides:
> &gt; Not a bad idea for the read-only mode. When editing a document,
> &gt; however, there will sometimes be the case that an image or other
> &gt; element would overlap into the next slide. What should LibO do then?
> &gt; Push the slide further below? Cut the element off in between the two
> &gt; slides? I'm sceptical.
> &gt;
> I agree, I usually have some parts of my slides that are "out of the
> slide", sometimes below, because it can be a movable picture that come half
> from the bottom .... SO personally, I think it's a bad idea.
>
>
>
> &gt; * Add page/slide:
> &gt; I can see this being very useful in Impress and Draw, but in those
> &gt; programs, I would probably put this button into the sidebar.
> &gt; For Writer, it would be similarly useful, but we'd also need more
> &gt; complexity: it'd need at least a "Add page" and an "Add Section"
> &gt; button (unless there is any way in which we can make those two
> &gt; commands the same).
> &gt;
> &gt; It's just great as it is in the mock-up. It's simple, and exactly
> were you
> need it. But I think that even if this is a great point, It should stay in
> the left insert toolbar too. (some people will search it there I think)
>
>
> *Float bar:
> &gt;
> I'm absolutely in ! Then in the case the element you select take all the
> screen, maybe putting the in the top of the element : On the right by
> default, with a button that switch it to the left if you want it there (or
> maybe by "drag and dropping" the float bar from right to left ?). I don't
> have time to make a mockup, but if you want one just ask I will try during
> the week-end
>
>
>
> &gt; * Insert bar:
> &gt; This is an idea from Ooo 1.0, I think. I'd love to know why it was
> &gt; abandoned, then, because it probably is a good idea..?
> &gt;
> Personally I always use it, and in the left of the screen, just as in your
> proposal. Too useful ! So I don't see why it has been abandonnated. Maybe
> it wasn't used enough according the "clic-map".
>
>
>
> &gt; * Live preview:
> &gt;
> If it means updating the whole document I think it's a bad idea (I suppose
> it would need too much resource). But if it's in a "preview box", then, I'm
> in. One think that I don't like today is that in the format toolbar, the
> fonts are described by there name, no preview. This is the little start of
> a "live preview".
>
>
>
> &gt; * Color-coded icons:
> &gt;
> Good idea, I think your color scheme proposal is great. Then, I think we
> should brainstorm about it : for me, Red means *"Hy, I need attention" *,
> so maybe this color shouldn't be used ?
>
> More of that, I'm not sure that this is so useful : The icons concerning
> text shoud appear only when text is selected, same with images, videos...
> what do you think ?
>
> PS : Re thinking the thing : I was wrong : you can select zones with both
> pictures and audio
>
>
>
> &gt; * Reduced standard toolbar:
> &gt;
> I almost agree, except that I don't understand where you would put
> print/export in this case ? I personnaly use these two options every time
> (I export to PDF every 30 minutes because of problems I had with odt files
> in the past)
>
>
>
> &gt; * Drop-down buttons:
> &gt;
> No special thought. To be honest I don't know if it's a good or bad idea.
>
>
>
> &gt; * Sorting out commands:
> &gt; Good principles, basically, but probably too rough to be usable in
> &gt; their current form. Point two (no greyed-out buttons) is contradictory
> &gt; to the reasoning found under Reduced standard toolbar (click-able
> &gt; buttons as indicators).
> &gt; Also, this is part of the proposal is throwing (useful) conventions
> &gt; out of the window: should we really move Cut, Copy and Paste into
> &gt; completely different menus?
> &gt;
> I think the current menus, even if not perfect are great. The Edit menu is
> especially useful I think. Then, if everything in this menu can be found in
> the floatbar or other places (like text menu when text is selected for
> copy/cut or insert menu to paste), then, perfect !
>
>
> * Getting rid of formatting dialogs :
> &gt;
> Granted, I am biased here [1], but I don't like interacting with menus
> &gt; in this way at all, even though that's something Microsoft Office
> &gt; makes heavy use of.
> &gt; It is also a huge, huge, huge amount of work for an unclear (to me)
> &gt; benefit. Two disadvantages of relying so much on rich menus:
> &gt; → opening menus to change anything all the time should be pretty
> annoying
> &gt; → customising styles is made very hard (we should want people to use
> &gt; styles, so they can create more coherent looking documents more
> &gt; easily!)
> &gt;
> Personally, just for me, I think it could be a great idea, because
> formatting dialogues would still be available to edit a style. Then, a lot
> of people don't use styles AT ALL, and they act directly on the text. To do
> this, a formatting dialogue seems me easier : you have everything in the
> same window, else you must go to the menu for every change (BOLD, Italic,
> color, underline....). Except if the major parts (underline, font/color,
> bold, italic....) are in the floatbar or elsewhere easily click-able
>
>
>
> &gt; * Combining navigator and side pane.
> &gt; I never actually use the Navigator, (I'm probably wrong, I will try to
> &gt; force me to use it to see.
> &gt;
>
>
>
> &gt; * Simplified Options:
> &gt;
> I would say yes, only if the advanced pane is still available : Look at
> Ubuntu Unity or Gnome Shell (or the whole Gnome 3) : A lot of complaints
> is from people who miss options. So don't say we do the simple options
> dialogue then the advanced one. I think it's better making the simplest
> one, then once finished redesigning (or not) the advanced one which could
> stay the actual one.
>
>
>
> &gt; * Rich menus:
> &gt;
> I'm totally in. Then, about Ubuntu (I don't know for Mac OSX), look at the
> sound menu : it's an indicator, but it's a menu too and it contains non
> traditional menus items. So it must be possible to include them in the
> global menu. I'm sure (really sure) that if we can explain Canonical the
> Why and the How (maybe based on a survey), they will help us integrate this
> (I'm not sure, but it seems me there is a Canonical employee who is
> "dedicated" to LibreOffice integration. More of that, going to an UDS to
> discuss it would help a lot.
>
>
> Conclusion :
>
> I really really really Love your proposal, it's the exact direction I would
> like to see LibO go : A cleanest UI, using less vertical spacing (just for
> this point I hate the Office ribbons (they look just ridiculous on a
> netbook or other little screen), with just what we need the most under our
> eyes, every thing else in menus, the whole thing being easily configurable
> (drag and drop, advanced option dialog) to adapt to every one needs, but
> with good defaults. Just what I was thinking !
>
> I'm sorry to be so late to answer, and not to take the time to study better
> your proposal (believe me, I would love to have this time), so maybe I
> mis-understood some parts. DOn't hesitate to say it to me. I will do my
> best to answer any other questions you could have (it should take less time
> than 5 weeks, I promise :D ). I'm also sorry for my English which is, I
> know, not really perfect (yet ?), I'm working on this. If you don't
> understand what I say, just ask, I will try to explain my idea (maybe I
> just mis-understood your proposal too, so my answer would be stupid and out
> of place, I hope this won't happen too much).
>
> Anyway, Thank you Mirek for this great proposal, which is a really great
> start point. I hope we will be able to take it far !
>
> Kévin
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Charles-H. Schulz Charles-H. Schulz
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

Oh boy. How many times did we explain we cannot change the interface in one
shot?

Citrus looks good. But as we explained, if there's no one wrting
specicications for eaxh part of citrus nothing will get done.

It looks like we need to blog so that people don't get their hopes up. :-/

Best,
Charles.
Le 24 nov. 2011 21:44, "Kévin PEIGNOT" <[hidden email]> a écrit :

> Hy  you wan't feedback on Citrus :
>
>
> http://www.omgubuntu.co.uk/2011/11/citrus-a-libreoffice-interface-for-today/
>
> This is a good start guys ;)
>
> Kévin
>
> 2011/11/21 alexander.wilms <[hidden email]>
>
> > Hi,
> >
> > since I just received Kévins mail, I now took the time to browse Mireks
> > proposals more deeply and I have to agree, that's just what I'd like to
> see
> > :).
> >
> > There are many great things in those drafts, but I especially like are
> the
> > color codes and the command reorganization. In addition to the new
> handling
> > of headers this would make LOs UI much more comfortable to use.
> >
> > Another aspect I'd like to see integrated are those style groups, but in
> > my opinion a little previw like in Word would be nice, maybe as a popout
> or
> > that the styles get applied when hovering over each of them. In my
> opinion,
> > there should be two selections though, one for the group style used (e.g.
> > "My favorite selfmade style") and one for the formatting that gets
> applied
> > (e.g. Heading 1, Table etc.). I'm not sure but maybe you've already
> > adresses this aspect.
> >
> > I generally like the idea of focusing on actual writing and letting the
> > formatting be automated or taken care of, thats why I like the ability to
> > export them and the new template manager, which could maybe even being
> > integrated with the online repository, just like the fonts.
> >
> > Still, there are some issues like flickering icons when hovering over
> them
> > or flshing black background colors when editing a text in Impress. Those
> > aren't immediately related to this proposal, but I hope this could be
> > eliminated, too. Or have these issues already been adressed in the
> current
> > development branch?
> >
> > I am personally looking forward to the command reorg, hopefully we can
> > start working this out very soon :)
> > Cheers
> >
> > Alex
> >
> > ---- On Mon, 21 Nov 2011 20:07:06 +0100 Kévin PEIGNOT &
> > lt;[hidden email]&gt; wrote ----
> >
> >
> > 2011/10/30 Astron &lt;[hidden email]&gt;
> >
> > &gt; Hi everyone,
> > &gt;
> > &gt; a few days ago, Andrew asked for feedback on Mirek's Citrus
> proposal.
> > &gt; So, here, I want to start a thread on what I/we like and what I/we
> > &gt; don't like (about the desktop/laptop proposal), in the hope that it
> > &gt; helps Mirek to refine his proposal. Please note, I am not a regular
> > &gt; reader of Mirek's blog and my assumptions are based on the short
> > &gt; descriptions from the wiki, so if anything on this list seems wrong
> to
> > &gt; you, feel free to correct me.
> > &gt; Here we go, structure is as on Mirek2's wiki page:
> > &gt;
> > To gain time, I choosed to use the same structure.
> >
> > &gt;
> > &gt; * Ellipsis menu:
> > &gt; I like the idea and it looks much better (cleaner) than it does
> > &gt; currently; for executing commands it is also more functional.
> > &gt; Here's what I don't like: that you can customise your toolbar via
> > &gt; drag-and-drop is not made visible at all; for users of accessibility
> > &gt; solutions there seems to be no way to add or remove something.
> > &gt;
> > I must say I agree with this. It's a great idea. Here a proposal of
> > solution : At the end of the toolbar, after the menu button, menu,
> > integrate an ellement with a "?" button. When a user click on it, a
> pop-up
> > appear with the tip, saying that drag'n-dropping is the way to proceed
> >
> > * Page/slide handles:
> > &gt; I like the idea (so much I opened a bug about it – fdo#38597).
> There's
> > &gt; a lot to discuss, though, before this can be implemented (how it
> > &gt; zooms, how it acts, etc.). Also, the proposal doesn't work at all
> for
> > &gt; Calc (which Mirek explained, he uses so seldomly that he didn't
> > &gt; include it in his proposals).
> > &gt;
> >  Honestly I don't really see what is the point there. Do you have a
> > detailled article/page somewhere, I didn't find (I suppose I didn't
> > searched in the right place)
> >
> >
> > &gt;
> > &gt; * Continuously scrollable slides:
> > &gt; Not a bad idea for the read-only mode. When editing a document,
> > &gt; however, there will sometimes be the case that an image or other
> > &gt; element would overlap into the next slide. What should LibO do then?
> > &gt; Push the slide further below? Cut the element off in between the two
> > &gt; slides? I'm sceptical.
> > &gt;
> > I agree, I usually have some parts of my slides that are "out of the
> > slide", sometimes below, because it can be a movable picture that come
> half
> > from the bottom .... SO personally, I think it's a bad idea.
> >
> >
> >
> > &gt; * Add page/slide:
> > &gt; I can see this being very useful in Impress and Draw, but in those
> > &gt; programs, I would probably put this button into the sidebar.
> > &gt; For Writer, it would be similarly useful, but we'd also need more
> > &gt; complexity: it'd need at least a "Add page" and an "Add Section"
> > &gt; button (unless there is any way in which we can make those two
> > &gt; commands the same).
> > &gt;
> > &gt; It's just great as it is in the mock-up. It's simple, and exactly
> > were you
> > need it. But I think that even if this is a great point, It should stay
> in
> > the left insert toolbar too. (some people will search it there I think)
> >
> >
> > *Float bar:
> > &gt;
> > I'm absolutely in ! Then in the case the element you select take all the
> > screen, maybe putting the in the top of the element : On the right by
> > default, with a button that switch it to the left if you want it there
> (or
> > maybe by "drag and dropping" the float bar from right to left ?). I don't
> > have time to make a mockup, but if you want one just ask I will try
> during
> > the week-end
> >
> >
> >
> > &gt; * Insert bar:
> > &gt; This is an idea from Ooo 1.0, I think. I'd love to know why it was
> > &gt; abandoned, then, because it probably is a good idea..?
> > &gt;
> > Personally I always use it, and in the left of the screen, just as in
> your
> > proposal. Too useful ! So I don't see why it has been abandonnated. Maybe
> > it wasn't used enough according the "clic-map".
> >
> >
> >
> > &gt; * Live preview:
> > &gt;
> > If it means updating the whole document I think it's a bad idea (I
> suppose
> > it would need too much resource). But if it's in a "preview box", then,
> I'm
> > in. One think that I don't like today is that in the format toolbar, the
> > fonts are described by there name, no preview. This is the little start
> of
> > a "live preview".
> >
> >
> >
> > &gt; * Color-coded icons:
> > &gt;
> > Good idea, I think your color scheme proposal is great. Then, I think we
> > should brainstorm about it : for me, Red means *"Hy, I need attention" *,
> > so maybe this color shouldn't be used ?
> >
> > More of that, I'm not sure that this is so useful : The icons concerning
> > text shoud appear only when text is selected, same with images, videos...
> > what do you think ?
> >
> > PS : Re thinking the thing : I was wrong : you can select zones with both
> > pictures and audio
> >
> >
> >
> > &gt; * Reduced standard toolbar:
> > &gt;
> > I almost agree, except that I don't understand where you would put
> > print/export in this case ? I personnaly use these two options every time
> > (I export to PDF every 30 minutes because of problems I had with odt
> files
> > in the past)
> >
> >
> >
> > &gt; * Drop-down buttons:
> > &gt;
> > No special thought. To be honest I don't know if it's a good or bad idea.
> >
> >
> >
> > &gt; * Sorting out commands:
> > &gt; Good principles, basically, but probably too rough to be usable in
> > &gt; their current form. Point two (no greyed-out buttons) is
> contradictory
> > &gt; to the reasoning found under Reduced standard toolbar (click-able
> > &gt; buttons as indicators).
> > &gt; Also, this is part of the proposal is throwing (useful) conventions
> > &gt; out of the window: should we really move Cut, Copy and Paste into
> > &gt; completely different menus?
> > &gt;
> > I think the current menus, even if not perfect are great. The Edit menu
> is
> > especially useful I think. Then, if everything in this menu can be found
> in
> > the floatbar or other places (like text menu when text is selected for
> > copy/cut or insert menu to paste), then, perfect !
> >
> >
> > * Getting rid of formatting dialogs :
> > &gt;
> > Granted, I am biased here [1], but I don't like interacting with menus
> > &gt; in this way at all, even though that's something Microsoft Office
> > &gt; makes heavy use of.
> > &gt; It is also a huge, huge, huge amount of work for an unclear (to me)
> > &gt; benefit. Two disadvantages of relying so much on rich menus:
> > &gt; → opening menus to change anything all the time should be pretty
> > annoying
> > &gt; → customising styles is made very hard (we should want people to use
> > &gt; styles, so they can create more coherent looking documents more
> > &gt; easily!)
> > &gt;
> > Personally, just for me, I think it could be a great idea, because
> > formatting dialogues would still be available to edit a style. Then, a
> lot
> > of people don't use styles AT ALL, and they act directly on the text. To
> do
> > this, a formatting dialogue seems me easier : you have everything in the
> > same window, else you must go to the menu for every change (BOLD, Italic,
> > color, underline....). Except if the major parts (underline, font/color,
> > bold, italic....) are in the floatbar or elsewhere easily click-able
> >
> >
> >
> > &gt; * Combining navigator and side pane.
> > &gt; I never actually use the Navigator, (I'm probably wrong, I will try
> to
> > &gt; force me to use it to see.
> > &gt;
> >
> >
> >
> > &gt; * Simplified Options:
> > &gt;
> > I would say yes, only if the advanced pane is still available : Look at
> > Ubuntu Unity or Gnome Shell (or the whole Gnome 3) : A lot of complaints
> > is from people who miss options. So don't say we do the simple options
> > dialogue then the advanced one. I think it's better making the simplest
> > one, then once finished redesigning (or not) the advanced one which could
> > stay the actual one.
> >
> >
> >
> > &gt; * Rich menus:
> > &gt;
> > I'm totally in. Then, about Ubuntu (I don't know for Mac OSX), look at
> the
> > sound menu : it's an indicator, but it's a menu too and it contains non
> > traditional menus items. So it must be possible to include them in the
> > global menu. I'm sure (really sure) that if we can explain Canonical the
> > Why and the How (maybe based on a survey), they will help us integrate
> this
> > (I'm not sure, but it seems me there is a Canonical employee who is
> > "dedicated" to LibreOffice integration. More of that, going to an UDS to
> > discuss it would help a lot.
> >
> >
> > Conclusion :
> >
> > I really really really Love your proposal, it's the exact direction I
> would
> > like to see LibO go : A cleanest UI, using less vertical spacing (just
> for
> > this point I hate the Office ribbons (they look just ridiculous on a
> > netbook or other little screen), with just what we need the most under
> our
> > eyes, every thing else in menus, the whole thing being easily
> configurable
> > (drag and drop, advanced option dialog) to adapt to every one needs, but
> > with good defaults. Just what I was thinking !
> >
> > I'm sorry to be so late to answer, and not to take the time to study
> better
> > your proposal (believe me, I would love to have this time), so maybe I
> > mis-understood some parts. DOn't hesitate to say it to me. I will do my
> > best to answer any other questions you could have (it should take less
> time
> > than 5 weeks, I promise :D ). I'm also sorry for my English which is, I
> > know, not really perfect (yet ?), I'm working on this. If you don't
> > understand what I say, just ask, I will try to explain my idea (maybe I
> > just mis-understood your proposal too, so my answer would be stupid and
> out
> > of place, I hope this won't happen too much).
> >
> > Anyway, Thank you Mirek for this great proposal, which is a really great
> > start point. I hope we will be able to take it far !
> >
> > Kévin
> >
> > --
> > Unsubscribe instructions: E-mail to [hidden email]
> > Problems?
> > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> > List archive: http://listarchives.libreoffice.org/global/design/
> > All messages sent to this list will be publicly archived and cannot be
> > deleted
> >
> >
> > --
> > Unsubscribe instructions: E-mail to [hidden email]
> > Problems?
> > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> > List archive: http://listarchives.libreoffice.org/global/design/
> > All messages sent to this list will be publicly archived and cannot be
> > deleted
> >
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Kévin PEIGNOT-3 Kévin PEIGNOT-3
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

I just agree it can't be done in one time, it doesn't, but it's a good way
to have feedback anyway ;)

2011/11/24 Charles-H. Schulz <[hidden email]>

> Oh boy. How many times did we explain we cannot change the interface in one
> shot?
>
> Citrus looks good. But as we explained, if there's no one wrting
> specicications for eaxh part of citrus nothing will get done.
>
> It looks like we need to blog so that people don't get their hopes up. :-/
>
> Best,
> Charles.
> Le 24 nov. 2011 21:44, "Kévin PEIGNOT" <[hidden email]> a
> écrit :
>
> > Hy  you wan't feedback on Citrus :
> >
> >
> >
> http://www.omgubuntu.co.uk/2011/11/citrus-a-libreoffice-interface-for-today/
> >
> > This is a good start guys ;)
> >
> > Kévin
> >
> > 2011/11/21 alexander.wilms <[hidden email]>
> >
> > > Hi,
> > >
> > > since I just received Kévins mail, I now took the time to browse Mireks
> > > proposals more deeply and I have to agree, that's just what I'd like to
> > see
> > > :).
> > >
> > > There are many great things in those drafts, but I especially like are
> > the
> > > color codes and the command reorganization. In addition to the new
> > handling
> > > of headers this would make LOs UI much more comfortable to use.
> > >
> > > Another aspect I'd like to see integrated are those style groups, but
> in
> > > my opinion a little previw like in Word would be nice, maybe as a
> popout
> > or
> > > that the styles get applied when hovering over each of them. In my
> > opinion,
> > > there should be two selections though, one for the group style used
> (e.g.
> > > "My favorite selfmade style") and one for the formatting that gets
> > applied
> > > (e.g. Heading 1, Table etc.). I'm not sure but maybe you've already
> > > adresses this aspect.
> > >
> > > I generally like the idea of focusing on actual writing and letting the
> > > formatting be automated or taken care of, thats why I like the ability
> to
> > > export them and the new template manager, which could maybe even being
> > > integrated with the online repository, just like the fonts.
> > >
> > > Still, there are some issues like flickering icons when hovering over
> > them
> > > or flshing black background colors when editing a text in Impress.
> Those
> > > aren't immediately related to this proposal, but I hope this could be
> > > eliminated, too. Or have these issues already been adressed in the
> > current
> > > development branch?
> > >
> > > I am personally looking forward to the command reorg, hopefully we can
> > > start working this out very soon :)
> > > Cheers
> > >
> > > Alex
> > >
> > > ---- On Mon, 21 Nov 2011 20:07:06 +0100 Kévin PEIGNOT &
> > > lt;[hidden email]&gt; wrote ----
> > >
> > >
> > > 2011/10/30 Astron &lt;[hidden email]&gt;
> > >
> > > &gt; Hi everyone,
> > > &gt;
> > > &gt; a few days ago, Andrew asked for feedback on Mirek's Citrus
> > proposal.
> > > &gt; So, here, I want to start a thread on what I/we like and what I/we
> > > &gt; don't like (about the desktop/laptop proposal), in the hope that
> it
> > > &gt; helps Mirek to refine his proposal. Please note, I am not a
> regular
> > > &gt; reader of Mirek's blog and my assumptions are based on the short
> > > &gt; descriptions from the wiki, so if anything on this list seems
> wrong
> > to
> > > &gt; you, feel free to correct me.
> > > &gt; Here we go, structure is as on Mirek2's wiki page:
> > > &gt;
> > > To gain time, I choosed to use the same structure.
> > >
> > > &gt;
> > > &gt; * Ellipsis menu:
> > > &gt; I like the idea and it looks much better (cleaner) than it does
> > > &gt; currently; for executing commands it is also more functional.
> > > &gt; Here's what I don't like: that you can customise your toolbar via
> > > &gt; drag-and-drop is not made visible at all; for users of
> accessibility
> > > &gt; solutions there seems to be no way to add or remove something.
> > > &gt;
> > > I must say I agree with this. It's a great idea. Here a proposal of
> > > solution : At the end of the toolbar, after the menu button, menu,
> > > integrate an ellement with a "?" button. When a user click on it, a
> > pop-up
> > > appear with the tip, saying that drag'n-dropping is the way to proceed
> > >
> > > * Page/slide handles:
> > > &gt; I like the idea (so much I opened a bug about it – fdo#38597).
> > There's
> > > &gt; a lot to discuss, though, before this can be implemented (how it
> > > &gt; zooms, how it acts, etc.). Also, the proposal doesn't work at all
> > for
> > > &gt; Calc (which Mirek explained, he uses so seldomly that he didn't
> > > &gt; include it in his proposals).
> > > &gt;
> > >  Honestly I don't really see what is the point there. Do you have a
> > > detailled article/page somewhere, I didn't find (I suppose I didn't
> > > searched in the right place)
> > >
> > >
> > > &gt;
> > > &gt; * Continuously scrollable slides:
> > > &gt; Not a bad idea for the read-only mode. When editing a document,
> > > &gt; however, there will sometimes be the case that an image or other
> > > &gt; element would overlap into the next slide. What should LibO do
> then?
> > > &gt; Push the slide further below? Cut the element off in between the
> two
> > > &gt; slides? I'm sceptical.
> > > &gt;
> > > I agree, I usually have some parts of my slides that are "out of the
> > > slide", sometimes below, because it can be a movable picture that come
> > half
> > > from the bottom .... SO personally, I think it's a bad idea.
> > >
> > >
> > >
> > > &gt; * Add page/slide:
> > > &gt; I can see this being very useful in Impress and Draw, but in those
> > > &gt; programs, I would probably put this button into the sidebar.
> > > &gt; For Writer, it would be similarly useful, but we'd also need more
> > > &gt; complexity: it'd need at least a "Add page" and an "Add Section"
> > > &gt; button (unless there is any way in which we can make those two
> > > &gt; commands the same).
> > > &gt;
> > > &gt; It's just great as it is in the mock-up. It's simple, and exactly
> > > were you
> > > need it. But I think that even if this is a great point, It should stay
> > in
> > > the left insert toolbar too. (some people will search it there I think)
> > >
> > >
> > > *Float bar:
> > > &gt;
> > > I'm absolutely in ! Then in the case the element you select take all
> the
> > > screen, maybe putting the in the top of the element : On the right by
> > > default, with a button that switch it to the left if you want it there
> > (or
> > > maybe by "drag and dropping" the float bar from right to left ?). I
> don't
> > > have time to make a mockup, but if you want one just ask I will try
> > during
> > > the week-end
> > >
> > >
> > >
> > > &gt; * Insert bar:
> > > &gt; This is an idea from Ooo 1.0, I think. I'd love to know why it was
> > > &gt; abandoned, then, because it probably is a good idea..?
> > > &gt;
> > > Personally I always use it, and in the left of the screen, just as in
> > your
> > > proposal. Too useful ! So I don't see why it has been abandonnated.
> Maybe
> > > it wasn't used enough according the "clic-map".
> > >
> > >
> > >
> > > &gt; * Live preview:
> > > &gt;
> > > If it means updating the whole document I think it's a bad idea (I
> > suppose
> > > it would need too much resource). But if it's in a "preview box", then,
> > I'm
> > > in. One think that I don't like today is that in the format toolbar,
> the
> > > fonts are described by there name, no preview. This is the little start
> > of
> > > a "live preview".
> > >
> > >
> > >
> > > &gt; * Color-coded icons:
> > > &gt;
> > > Good idea, I think your color scheme proposal is great. Then, I think
> we
> > > should brainstorm about it : for me, Red means *"Hy, I need attention"
> *,
> > > so maybe this color shouldn't be used ?
> > >
> > > More of that, I'm not sure that this is so useful : The icons
> concerning
> > > text shoud appear only when text is selected, same with images,
> videos...
> > > what do you think ?
> > >
> > > PS : Re thinking the thing : I was wrong : you can select zones with
> both
> > > pictures and audio
> > >
> > >
> > >
> > > &gt; * Reduced standard toolbar:
> > > &gt;
> > > I almost agree, except that I don't understand where you would put
> > > print/export in this case ? I personnaly use these two options every
> time
> > > (I export to PDF every 30 minutes because of problems I had with odt
> > files
> > > in the past)
> > >
> > >
> > >
> > > &gt; * Drop-down buttons:
> > > &gt;
> > > No special thought. To be honest I don't know if it's a good or bad
> idea.
> > >
> > >
> > >
> > > &gt; * Sorting out commands:
> > > &gt; Good principles, basically, but probably too rough to be usable in
> > > &gt; their current form. Point two (no greyed-out buttons) is
> > contradictory
> > > &gt; to the reasoning found under Reduced standard toolbar (click-able
> > > &gt; buttons as indicators).
> > > &gt; Also, this is part of the proposal is throwing (useful)
> conventions
> > > &gt; out of the window: should we really move Cut, Copy and Paste into
> > > &gt; completely different menus?
> > > &gt;
> > > I think the current menus, even if not perfect are great. The Edit menu
> > is
> > > especially useful I think. Then, if everything in this menu can be
> found
> > in
> > > the floatbar or other places (like text menu when text is selected for
> > > copy/cut or insert menu to paste), then, perfect !
> > >
> > >
> > > * Getting rid of formatting dialogs :
> > > &gt;
> > > Granted, I am biased here [1], but I don't like interacting with menus
> > > &gt; in this way at all, even though that's something Microsoft Office
> > > &gt; makes heavy use of.
> > > &gt; It is also a huge, huge, huge amount of work for an unclear (to
> me)
> > > &gt; benefit. Two disadvantages of relying so much on rich menus:
> > > &gt; → opening menus to change anything all the time should be pretty
> > > annoying
> > > &gt; → customising styles is made very hard (we should want people to
> use
> > > &gt; styles, so they can create more coherent looking documents more
> > > &gt; easily!)
> > > &gt;
> > > Personally, just for me, I think it could be a great idea, because
> > > formatting dialogues would still be available to edit a style. Then, a
> > lot
> > > of people don't use styles AT ALL, and they act directly on the text.
> To
> > do
> > > this, a formatting dialogue seems me easier : you have everything in
> the
> > > same window, else you must go to the menu for every change (BOLD,
> Italic,
> > > color, underline....). Except if the major parts (underline,
> font/color,
> > > bold, italic....) are in the floatbar or elsewhere easily click-able
> > >
> > >
> > >
> > > &gt; * Combining navigator and side pane.
> > > &gt; I never actually use the Navigator, (I'm probably wrong, I will
> try
> > to
> > > &gt; force me to use it to see.
> > > &gt;
> > >
> > >
> > >
> > > &gt; * Simplified Options:
> > > &gt;
> > > I would say yes, only if the advanced pane is still available : Look at
> > > Ubuntu Unity or Gnome Shell (or the whole Gnome 3) : A lot of
> complaints
> > > is from people who miss options. So don't say we do the simple options
> > > dialogue then the advanced one. I think it's better making the simplest
> > > one, then once finished redesigning (or not) the advanced one which
> could
> > > stay the actual one.
> > >
> > >
> > >
> > > &gt; * Rich menus:
> > > &gt;
> > > I'm totally in. Then, about Ubuntu (I don't know for Mac OSX), look at
> > the
> > > sound menu : it's an indicator, but it's a menu too and it contains non
> > > traditional menus items. So it must be possible to include them in the
> > > global menu. I'm sure (really sure) that if we can explain Canonical
> the
> > > Why and the How (maybe based on a survey), they will help us integrate
> > this
> > > (I'm not sure, but it seems me there is a Canonical employee who is
> > > "dedicated" to LibreOffice integration. More of that, going to an UDS
> to
> > > discuss it would help a lot.
> > >
> > >
> > > Conclusion :
> > >
> > > I really really really Love your proposal, it's the exact direction I
> > would
> > > like to see LibO go : A cleanest UI, using less vertical spacing (just
> > for
> > > this point I hate the Office ribbons (they look just ridiculous on a
> > > netbook or other little screen), with just what we need the most under
> > our
> > > eyes, every thing else in menus, the whole thing being easily
> > configurable
> > > (drag and drop, advanced option dialog) to adapt to every one needs,
> but
> > > with good defaults. Just what I was thinking !
> > >
> > > I'm sorry to be so late to answer, and not to take the time to study
> > better
> > > your proposal (believe me, I would love to have this time), so maybe I
> > > mis-understood some parts. DOn't hesitate to say it to me. I will do my
> > > best to answer any other questions you could have (it should take less
> > time
> > > than 5 weeks, I promise :D ). I'm also sorry for my English which is, I
> > > know, not really perfect (yet ?), I'm working on this. If you don't
> > > understand what I say, just ask, I will try to explain my idea (maybe I
> > > just mis-understood your proposal too, so my answer would be stupid and
> > out
> > > of place, I hope this won't happen too much).
> > >
> > > Anyway, Thank you Mirek for this great proposal, which is a really
> great
> > > start point. I hope we will be able to take it far !
> > >
> > > Kévin
> > >
> > > --
> > > Unsubscribe instructions: E-mail to [hidden email]
> > > Problems?
> > > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > > Posting guidelines + more:
> http://wiki.documentfoundation.org/Netiquette
> > > List archive: http://listarchives.libreoffice.org/global/design/
> > > All messages sent to this list will be publicly archived and cannot be
> > > deleted
> > >
> > >
> > > --
> > > Unsubscribe instructions: E-mail to [hidden email]
> > > Problems?
> > > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > > Posting guidelines + more:
> http://wiki.documentfoundation.org/Netiquette
> > > List archive: http://listarchives.libreoffice.org/global/design/
> > > All messages sent to this list will be publicly archived and cannot be
> > > deleted
> > >
> >
> > --
> > Unsubscribe instructions: E-mail to [hidden email]
> > Problems?
> > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> > List archive: http://listarchives.libreoffice.org/global/design/
> > All messages sent to this list will be publicly archived and cannot be
> > deleted
> >
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

Charles, Kevin, every one,


> Citrus looks good. But as we explained, if there's no one wrting
> specicications for eaxh part of citrus nothing will get done.
>

ok yes we do need to start on some specifications so that we can get
started, but we have not talked about it all that much. first we need
to decide on what we all agree on and change what we do not. if we get more
people to agree with some things I would start some specifications, but I
still don't know exactly what is needed to write one. could someone write a
templet on what needs to be written. that would really help. till then
there are still some people that have not said what they do not like about
Citrus. if you wait any longer we'er going to have to just go with Citrus.

It looks like we need to blog so that people don't get their hopes up. :-/


all the more reason to get this started NOW. and before you guys say it ONE
MORE TIME. I know that we can not get this done in one shot, and that we
need to do this ONE STEP AT A TIME. but now that we have some press on this
and people know that we are working on this we NEED to get things rolling.

Andrew

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Kévin PEIGNOT-3 Kévin PEIGNOT-3
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

Maybe we could publish a survey asking, for each part of Citrus UI
(explained in a few word) what people think about it ? As we did with our
first survey ?

On each page a part of the survey, with a brief summary and if possible a
mockup. And why not at the end asking a "global impression" note. It's not
spec, but it permit to know what people think of the globals ideas ?

Kévin

2011/11/24 Andrew Pullins <[hidden email]>

> Charles, Kevin, every one,
>
>
> > Citrus looks good. But as we explained, if there's no one wrting
> > specicications for eaxh part of citrus nothing will get done.
> >
>
> ok yes we do need to start on some specifications so that we can get
> started, but we have not talked about it all that much. first we need
> to decide on what we all agree on and change what we do not. if we get more
> people to agree with some things I would start some specifications, but I
> still don't know exactly what is needed to write one. could someone write a
> templet on what needs to be written. that would really help. till then
> there are still some people that have not said what they do not like about
> Citrus. if you wait any longer we'er going to have to just go with Citrus.
>
> It looks like we need to blog so that people don't get their hopes up. :-/
>
>
> all the more reason to get this started NOW. and before you guys say it ONE
> MORE TIME. I know that we can not get this done in one shot, and that we
> need to do this ONE STEP AT A TIME. but now that we have some press on this
> and people know that we are working on this we NEED to get things rolling.
>
> Andrew
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Andrew Pullins Andrew Pullins
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

That is a grate idea, this way we can one easily get all(most) of the
people working on LibreOffice in on this(I have not even asked other
teams.) and two we could get the opinions of our users.

though I fear that the awesomeness of Citrus' contextuality will be lost to
those who read the survey. too fully grasp the what Citrus does you may
need play with it or read all of what Mirek has written on his blog. we
would need to stress this.

so how can we get this started.

Andrew

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Charles-H. Schulz Charles-H. Schulz
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

In reply to this post by Kévin PEIGNOT-3
A survey would be a great idea; in fact, it would help with asking
ourselves the right question for the spec; in short, it would be a real
work of User Experience.

Even better news: I think Christoph Noack and Bjoern Balazs know just
how to set up such a survey, but I might be perhaps too optimistic :-)

Best,

Charles.


On 25/11/2011 00:00, Kévin PEIGNOT wrote:

> Maybe we could publish a survey asking, for each part of Citrus UI
> (explained in a few word) what people think about it ? As we did with our
> first survey ?
>
> On each page a part of the survey, with a brief summary and if possible a
> mockup. And why not at the end asking a "global impression" note. It's not
> spec, but it permit to know what people think of the globals ideas ?
>
> Kévin
>
> 2011/11/24 Andrew Pullins <[hidden email]>
>
>> Charles, Kevin, every one,
>>
>>
>>> Citrus looks good. But as we explained, if there's no one wrting
>>> specicications for eaxh part of citrus nothing will get done.
>>>
>>
>> ok yes we do need to start on some specifications so that we can get
>> started, but we have not talked about it all that much. first we need
>> to decide on what we all agree on and change what we do not. if we get more
>> people to agree with some things I would start some specifications, but I
>> still don't know exactly what is needed to write one. could someone write a
>> templet on what needs to be written. that would really help. till then
>> there are still some people that have not said what they do not like about
>> Citrus. if you wait any longer we'er going to have to just go with Citrus.
>>
>> It looks like we need to blog so that people don't get their hopes up. :-/
>>
>>
>> all the more reason to get this started NOW. and before you guys say it ONE
>> MORE TIME. I know that we can not get this done in one shot, and that we
>> need to do this ONE STEP AT A TIME. but now that we have some press on this
>> and people know that we are working on this we NEED to get things rolling.
>>
>> Andrew
>>
>> --
>> Unsubscribe instructions: E-mail to [hidden email]
>> Problems?
>> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
>> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
>> List archive: http://listarchives.libreoffice.org/global/design/
>> All messages sent to this list will be publicly archived and cannot be
>> deleted
>>
>>
>


--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Alexander Wilms Alexander Wilms
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

Completely agree :)

Alex

---- On Fri, 25 Nov 2011 09:38:22 +0100 Charles-H. Schulz &lt;[hidden email]&gt; wrote ----


A survey would be a great idea; in fact, it would help with asking
ourselves the right question for the spec; in short, it would be a real
work of User Experience.
 
Even better news: I think Christoph Noack and Bjoern Balazs know just
how to set up such a survey, but I might be perhaps too optimistic :-)
 
Best,
 
Charles.
 
 
On 25/11/2011 00:00, Kévin PEIGNOT wrote:
&gt; Maybe we could publish a survey asking, for each part of Citrus UI
&gt; (explained in a few word) what people think about it ? As we did with our
&gt; first survey ?
&gt;
&gt; On each page a part of the survey, with a brief summary and if possible a
&gt; mockup. And why not at the end asking a "global impression" note. It's not
&gt; spec, but it permit to know what people think of the globals ideas ?
&gt;
&gt; Kévin
&gt;
&gt; 2011/11/24 Andrew Pullins &lt;[hidden email]&gt;
&gt;
&gt;&gt; Charles, Kevin, every one,
&gt;&gt;
&gt;&gt;
&gt;&gt;&gt; Citrus looks good. But as we explained, if there's no one wrting
&gt;&gt;&gt; specicications for eaxh part of citrus nothing will get done.
&gt;&gt;&gt;
&gt;&gt;
&gt;&gt; ok yes we do need to start on some specifications so that we can get
&gt;&gt; started, but we have not talked about it all that much. first we need
&gt;&gt; to decide on what we all agree on and change what we do not. if we get more
&gt;&gt; people to agree with some things I would start some specifications, but I
&gt;&gt; still don't know exactly what is needed to write one. could someone write a
&gt;&gt; templet on what needs to be written. that would really help. till then
&gt;&gt; there are still some people that have not said what they do not like about
&gt;&gt; Citrus. if you wait any longer we'er going to have to just go with Citrus.
&gt;&gt;
&gt;&gt; It looks like we need to blog so that people don't get their hopes up. :-/
&gt;&gt;
&gt;&gt;
&gt;&gt; all the more reason to get this started NOW. and before you guys say it ONE
&gt;&gt; MORE TIME. I know that we can not get this done in one shot, and that we
&gt;&gt; need to do this ONE STEP AT A TIME. but now that we have some press on this
&gt;&gt; and people know that we are working on this we NEED to get things rolling.
&gt;&gt;
&gt;&gt; Andrew
&gt;&gt;
&gt;&gt; --
&gt;&gt; Unsubscribe instructions: E-mail to [hidden email]
&gt;&gt; Problems?
&gt;&gt; http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ 
&gt;&gt; Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette 
&gt;&gt; List archive: http://listarchives.libreoffice.org/global/design/ 
&gt;&gt; All messages sent to this list will be publicly archived and cannot be
&gt;&gt; deleted
&gt;&gt;
&gt;&gt;
&gt;
 
 
--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ 
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette 
List archive: http://listarchives.libreoffice.org/global/design/ 
All messages sent to this list will be publicly archived and cannot be deleted
 


--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Greg-2 Greg-2
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

I don't want to rain on your parade but (as a UX practitioner of 20 yrs),
surveys are almost the least effective means to validate a UI design,
especially if UI behaviour is included in the investigation. A dozen face to
face interviews supported by static or even active prototypes, conducted with
a variety of users would yield much more useful and reliable results.

If you want to pat yourself on the back and tell everyone that 9 out of 10
users prefer the new LibreButtonOMatic, then a survey will give you that but
whether 9 out of 10 users actually do will be unrelated to that statistic.

Surely the UXers in the team know people who use these type of products (in
fact a sprinkling of users of competitive products would add value). I'd be
happy to work with other UXers to plan the investigation  and conduct a couple
of structured interviews.

Regards,

Noh

> Completely agree :)
>
> Alex
>
> ---- On Fri, 25 Nov 2011 09:38:22 +0100 Charles-H. Schulz
> &lt;[hidden email]&gt; wrote ----
>
>
> A survey would be a great idea; in fact, it would help with asking
> ourselves the right question for the spec; in short, it would be a real
> work of User Experience.
>
> Even better news: I think Christoph Noack and Bjoern Balazs know just
> how to set up such a survey, but I might be perhaps too optimistic :-)
>
> Best,
>
> Charles.
>
>
> On 25/11/2011 00:00, Kévin PEIGNOT wrote:
> &gt; Maybe we could publish a survey asking, for each part of Citrus UI
> &gt; (explained in a few word) what people think about it ? As we did with
> our &gt; first survey ?
> &gt;
> &gt; On each page a part of the survey, with a brief summary and if
> possible a &gt; mockup. And why not at the end asking a "global
> impression" note. It's not &gt; spec, but it permit to know what people
> think of the globals ideas ? &gt;
> &gt; Kévin
> &gt;
> &gt; 2011/11/24 Andrew Pullins &lt;[hidden email]&gt;
> &gt;
> &gt;&gt; Charles, Kevin, every one,
> &gt;&gt;
> &gt;&gt;
> &gt;&gt;&gt; Citrus looks good. But as we explained, if there's no one
> wrting &gt;&gt;&gt; specicications for eaxh part of citrus nothing will
> get done. &gt;&gt;&gt;
> &gt;&gt;
> &gt;&gt; ok yes we do need to start on some specifications so that we can
> get &gt;&gt; started, but we have not talked about it all that much. first
> we need &gt;&gt; to decide on what we all agree on and change what we do
> not. if we get more &gt;&gt; people to agree with some things I would
> start some specifications, but I &gt;&gt; still don't know exactly what is
> needed to write one. could someone write a &gt;&gt; templet on what needs
> to be written. that would really help. till then &gt;&gt; there are still
> some people that have not said what they do not like about &gt;&gt;
> Citrus. if you wait any longer we'er going to have to just go with Citrus.
> &gt;&gt;
> &gt;&gt; It looks like we need to blog so that people don't get their hopes
> up. :-/ &gt;&gt;
> &gt;&gt;
> &gt;&gt; all the more reason to get this started NOW. and before you guys
> say it ONE &gt;&gt; MORE TIME. I know that we can not get this done in one
> shot, and that we &gt;&gt; need to do this ONE STEP AT A TIME. but now
> that we have some press on this &gt;&gt; and people know that we are
> working on this we NEED to get things rolling. &gt;&gt;
> &gt;&gt; Andrew
> &gt;&gt;
> &gt;&gt; --
> &gt;&gt; Unsubscribe instructions: E-mail to
> [hidden email] &gt;&gt; Problems?
> &gt;&gt;
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> &gt;&gt; Posting guidelines + more:
> http://wiki.documentfoundation.org/Netiquette &gt;&gt; List archive:
> http://listarchives.libreoffice.org/global/design/ &gt;&gt; All messages
> sent to this list will be publicly archived and cannot be &gt;&gt; deleted
> &gt;&gt;
> &gt;&gt;
> &gt;

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Kévin PEIGNOT-3 Kévin PEIGNOT-3
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

I agree, but One think is sure : We must try to do an ergonomic AND sexy
interface. And a survey could help us find what people like.

Kévin

2011/11/25 Greg <[hidden email]>

> I don't want to rain on your parade but (as a UX practitioner of 20 yrs),
> surveys are almost the least effective means to validate a UI design,
> especially if UI behaviour is included in the investigation. A dozen face
> to
> face interviews supported by static or even active prototypes, conducted
> with
> a variety of users would yield much more useful and reliable results.
>
> If you want to pat yourself on the back and tell everyone that 9 out of 10
> users prefer the new LibreButtonOMatic, then a survey will give you that
> but
> whether 9 out of 10 users actually do will be unrelated to that statistic.
>
> Surely the UXers in the team know people who use these type of products (in
> fact a sprinkling of users of competitive products would add value). I'd be
> happy to work with other UXers to plan the investigation  and conduct a
> couple
> of structured interviews.
>
> Regards,
>
> Noh
>
> > Completely agree :)
> >
> > Alex
> >
> > ---- On Fri, 25 Nov 2011 09:38:22 +0100 Charles-H. Schulz
> > &lt;[hidden email]&gt; wrote ----
> >
> >
> > A survey would be a great idea; in fact, it would help with asking
> > ourselves the right question for the spec; in short, it would be a real
> > work of User Experience.
> >
> > Even better news: I think Christoph Noack and Bjoern Balazs know just
> > how to set up such a survey, but I might be perhaps too optimistic :-)
> >
> > Best,
> >
> > Charles.
> >
> >
> > On 25/11/2011 00:00, Kévin PEIGNOT wrote:
> > &gt; Maybe we could publish a survey asking, for each part of Citrus UI
> > &gt; (explained in a few word) what people think about it ? As we did
> with
> > our &gt; first survey ?
> > &gt;
> > &gt; On each page a part of the survey, with a brief summary and if
> > possible a &gt; mockup. And why not at the end asking a "global
> > impression" note. It's not &gt; spec, but it permit to know what people
> > think of the globals ideas ? &gt;
> > &gt; Kévin
> > &gt;
> > &gt; 2011/11/24 Andrew Pullins &lt;[hidden email]&gt;
> > &gt;
> > &gt;&gt; Charles, Kevin, every one,
> > &gt;&gt;
> > &gt;&gt;
> > &gt;&gt;&gt; Citrus looks good. But as we explained, if there's no one
> > wrting &gt;&gt;&gt; specicications for eaxh part of citrus nothing will
> > get done. &gt;&gt;&gt;
> > &gt;&gt;
> > &gt;&gt; ok yes we do need to start on some specifications so that we can
> > get &gt;&gt; started, but we have not talked about it all that much.
> first
> > we need &gt;&gt; to decide on what we all agree on and change what we do
> > not. if we get more &gt;&gt; people to agree with some things I would
> > start some specifications, but I &gt;&gt; still don't know exactly what
> is
> > needed to write one. could someone write a &gt;&gt; templet on what needs
> > to be written. that would really help. till then &gt;&gt; there are still
> > some people that have not said what they do not like about &gt;&gt;
> > Citrus. if you wait any longer we'er going to have to just go with
> Citrus.
> > &gt;&gt;
> > &gt;&gt; It looks like we need to blog so that people don't get their
> hopes
> > up. :-/ &gt;&gt;
> > &gt;&gt;
> > &gt;&gt; all the more reason to get this started NOW. and before you guys
> > say it ONE &gt;&gt; MORE TIME. I know that we can not get this done in
> one
> > shot, and that we &gt;&gt; need to do this ONE STEP AT A TIME. but now
> > that we have some press on this &gt;&gt; and people know that we are
> > working on this we NEED to get things rolling. &gt;&gt;
> > &gt;&gt; Andrew
> > &gt;&gt;
> > &gt;&gt; --
> > &gt;&gt; Unsubscribe instructions: E-mail to
> > [hidden email] &gt;&gt; Problems?
> > &gt;&gt;
> > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > &gt;&gt; Posting guidelines + more:
> > http://wiki.documentfoundation.org/Netiquette &gt;&gt; List archive:
> > http://listarchives.libreoffice.org/global/design/ &gt;&gt; All messages
> > sent to this list will be publicly archived and cannot be &gt;&gt;
> deleted
> > &gt;&gt;
> > &gt;&gt;
> > &gt;
>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>

--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Jay Lozier Jay Lozier
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

In reply to this post by Greg-2
On 11/25/2011 01:19 PM, Greg wrote:

> I don't want to rain on your parade but (as a UX practitioner of 20 yrs),
> surveys are almost the least effective means to validate a UI design,
> especially if UI behaviour is included in the investigation. A dozen face to
> face interviews supported by static or even active prototypes, conducted with
> a variety of users would yield much more useful and reliable results.
>
> If you want to pat yourself on the back and tell everyone that 9 out of 10
> users prefer the new LibreButtonOMatic, then a survey will give you that but
> whether 9 out of 10 users actually do will be unrelated to that statistic.
>
> Surely the UXers in the team know people who use these type of products (in
> fact a sprinkling of users of competitive products would add value). I'd be
> happy to work with other UXers to plan the investigation  and conduct a couple
> of structured interviews.
>
> Regards,
>
> Noh
The problem for us is how to get any user input. The problem we have is
logistical, how are the interviews conducted.

>> Completely agree :)
>>
>> Alex
>>
>> ---- On Fri, 25 Nov 2011 09:38:22 +0100 Charles-H. Schulz
>> &lt;[hidden email]&gt; wrote ----
>>
>>
>> A survey would be a great idea; in fact, it would help with asking
>> ourselves the right question for the spec; in short, it would be a real
>> work of User Experience.
>>
>> Even better news: I think Christoph Noack and Bjoern Balazs know just
>> how to set up such a survey, but I might be perhaps too optimistic :-)
>>
>> Best,
>>
>> Charles.
>>
>>
>> On 25/11/2011 00:00, Kévin PEIGNOT wrote:
>> &gt; Maybe we could publish a survey asking, for each part of Citrus UI
>> &gt; (explained in a few word) what people think about it ? As we did with
>> our&gt; first survey ?
>> &gt;
>> &gt; On each page a part of the survey, with a brief summary and if
>> possible a&gt; mockup. And why not at the end asking a "global
>> impression" note. It's not&gt; spec, but it permit to know what people
>> think of the globals ideas ?&gt;
>> &gt; Kévin
>> &gt;
>> &gt; 2011/11/24 Andrew Pullins&lt;[hidden email]&gt;
>> &gt;
>> &gt;&gt; Charles, Kevin, every one,
>> &gt;&gt;
>> &gt;&gt;
>> &gt;&gt;&gt; Citrus looks good. But as we explained, if there's no one
>> wrting&gt;&gt;&gt; specicications for eaxh part of citrus nothing will
>> get done.&gt;&gt;&gt;
>> &gt;&gt;
>> &gt;&gt; ok yes we do need to start on some specifications so that we can
>> get&gt;&gt; started, but we have not talked about it all that much. first
>> we need&gt;&gt; to decide on what we all agree on and change what we do
>> not. if we get more&gt;&gt; people to agree with some things I would
>> start some specifications, but I&gt;&gt; still don't know exactly what is
>> needed to write one. could someone write a&gt;&gt; templet on what needs
>> to be written. that would really help. till then&gt;&gt; there are still
>> some people that have not said what they do not like about&gt;&gt;
>> Citrus. if you wait any longer we'er going to have to just go with Citrus.
>> &gt;&gt;
>> &gt;&gt; It looks like we need to blog so that people don't get their hopes
>> up. :-/&gt;&gt;
>> &gt;&gt;
>> &gt;&gt; all the more reason to get this started NOW. and before you guys
>> say it ONE&gt;&gt; MORE TIME. I know that we can not get this done in one
>> shot, and that we&gt;&gt; need to do this ONE STEP AT A TIME. but now
>> that we have some press on this&gt;&gt; and people know that we are
>> working on this we NEED to get things rolling.&gt;&gt;
>> &gt;&gt; Andrew
>> &gt;&gt;
>> &gt;&gt; --
>> &gt;&gt; Unsubscribe instructions: E-mail to
>> [hidden email]&gt;&gt; Problems?
>> &gt;&gt;
>> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
>> &gt;&gt; Posting guidelines + more:
>> http://wiki.documentfoundation.org/Netiquette&gt;&gt; List archive:
>> http://listarchives.libreoffice.org/global/design/&gt;&gt; All messages
>> sent to this list will be publicly archived and cannot be&gt;&gt; deleted
>> &gt;&gt;
>> &gt;&gt;
>> &gt;


--
Jay Lozier
[hidden email]


--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Christoph Noack Christoph Noack
Reply | Threaded
Open this post in threaded view
|

Re: Some Feedback on Citrus.

In reply to this post by Kévin PEIGNOT-3
Hi Kevin, Grek, hi all!

I've planned to stay away from the computer today, but I think that
thread is reason enough to answer nevertheless ;-)


Am Freitag, den 25.11.2011, 19:29 +0100 schrieb Kévin PEIGNOT:
> I agree, but One think is sure : We must try to do an ergonomic AND sexy
> interface. And a survey could help us find what people like.

Yes, a simple mockup survey does tell us what people might like
(theoretically), but it doesn't tell us whether a complex design is
ergonomic, usable, or does fit to user's real needs ... I assume that's
what Greg wanted to say.

By the way, thanks Greg for your kind offer ... it would be great to
hear what you think how we could (pre-)validate Citrus (or any other
proposal).

>From my point-of-view - with regard to Citrus and surveys:
      * Either you are an experienced interviewer (listening to what
        people usually not say), or ...
      * We use a survey to get a very general indication whether it
        makes sense to continue working on Citrus (that would help a
        bit, but since most people don't like the current UI we don't
        need to ask that *g*), or ...
      * We focus on carefully selected areas of Citrus. In such cases,
        one could e.g. describe show pictures and describe workflows
        people need to rate. Then you get feedback on "design
        decisions" (not: visual design).

There are lots of examples where surveys asked for product feedback
(with a good intention), whilst making the updated product worse.
Whether it is a special magazine (the publisher asked what topics are
missing, people added lots of ideas, it became a "general purpose"
magazine without focus and much less user interest) or cars (the
manufacturer asked what configuration options users wanted to have,
people wanted all kinds of stuff, and disliked the product finally
because it was hard to use).

One last thing: If you ask people, then you have to make sure that you
use the right ones. Otherwise you get feedback that seems to be valid,
but is not, unfortunately.

So back to the initial question - do we need a user survey (now), or
should we continue whether we (as the Design Team) think that its
valuable.

If the latter, then I think it would be helpful to have all contributors
speak up (and provide a yes/no with some explanation).


Cheers,
Christoph


> Kévin
>
> 2011/11/25 Greg <[hidden email]>
>
> > I don't want to rain on your parade but (as a UX practitioner of 20 yrs),
> > surveys are almost the least effective means to validate a UI design,
> > especially if UI behaviour is included in the investigation. A dozen face
> > to
> > face interviews supported by static or even active prototypes, conducted
> > with
> > a variety of users would yield much more useful and reliable results.
> >
> > If you want to pat yourself on the back and tell everyone that 9 out of 10
> > users prefer the new LibreButtonOMatic, then a survey will give you that
> > but
> > whether 9 out of 10 users actually do will be unrelated to that statistic.
> >
> > Surely the UXers in the team know people who use these type of products (in
> > fact a sprinkling of users of competitive products would add value). I'd be
> > happy to work with other UXers to plan the investigation  and conduct a
> > couple
> > of structured interviews.
> >
> > Regards,
> >
> > Noh
> >
> > > Completely agree :)
> > >
> > > Alex
> > >
> > > ---- On Fri, 25 Nov 2011 09:38:22 +0100 Charles-H. Schulz
> > > &lt;[hidden email]&gt; wrote ----
> > >
> > >
> > > A survey would be a great idea; in fact, it would help with asking
> > > ourselves the right question for the spec; in short, it would be a real
> > > work of User Experience.
> > >
> > > Even better news: I think Christoph Noack and Bjoern Balazs know just
> > > how to set up such a survey, but I might be perhaps too optimistic :-)
> > >
> > > Best,
> > >
> > > Charles.
> > >
> > >
> > > On 25/11/2011 00:00, Kévin PEIGNOT wrote:
> > > &gt; Maybe we could publish a survey asking, for each part of Citrus UI
> > > &gt; (explained in a few word) what people think about it ? As we did
> > with
> > > our &gt; first survey ?
> > > &gt;
> > > &gt; On each page a part of the survey, with a brief summary and if
> > > possible a &gt; mockup. And why not at the end asking a "global
> > > impression" note. It's not &gt; spec, but it permit to know what people
> > > think of the globals ideas ? &gt;
> > > &gt; Kévin
> > > &gt;
> > > &gt; 2011/11/24 Andrew Pullins &lt;[hidden email]&gt;
> > > &gt;
> > > &gt;&gt; Charles, Kevin, every one,
> > > &gt;&gt;
> > > &gt;&gt;
> > > &gt;&gt;&gt; Citrus looks good. But as we explained, if there's no one
> > > wrting &gt;&gt;&gt; specicications for eaxh part of citrus nothing will
> > > get done. &gt;&gt;&gt;
> > > &gt;&gt;
> > > &gt;&gt; ok yes we do need to start on some specifications so that we can
> > > get &gt;&gt; started, but we have not talked about it all that much.
> > first
> > > we need &gt;&gt; to decide on what we all agree on and change what we do
> > > not. if we get more &gt;&gt; people to agree with some things I would
> > > start some specifications, but I &gt;&gt; still don't know exactly what
> > is
> > > needed to write one. could someone write a &gt;&gt; templet on what needs
> > > to be written. that would really help. till then &gt;&gt; there are still
> > > some people that have not said what they do not like about &gt;&gt;
> > > Citrus. if you wait any longer we'er going to have to just go with
> > Citrus.
> > > &gt;&gt;
> > > &gt;&gt; It looks like we need to blog so that people don't get their
> > hopes
> > > up. :-/ &gt;&gt;
> > > &gt;&gt;
> > > &gt;&gt; all the more reason to get this started NOW. and before you guys
> > > say it ONE &gt;&gt; MORE TIME. I know that we can not get this done in
> > one
> > > shot, and that we &gt;&gt; need to do this ONE STEP AT A TIME. but now
> > > that we have some press on this &gt;&gt; and people know that we are
> > > working on this we NEED to get things rolling. &gt;&gt;
> > > &gt;&gt; Andrew
> > > &gt;&gt;
> > > &gt;&gt; --
> > > &gt;&gt; Unsubscribe instructions: E-mail to
> > > [hidden email] &gt;&gt; Problems?
> > > &gt;&gt;
> > > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > > &gt;&gt; Posting guidelines + more:
> > > http://wiki.documentfoundation.org/Netiquette &gt;&gt; List archive:
> > > http://listarchives.libreoffice.org/global/design/ &gt;&gt; All messages
> > > sent to this list will be publicly archived and cannot be &gt;&gt;
> > deleted
> > > &gt;&gt;
> > > &gt;&gt;
> > > &gt;
> >
> > --
> > Unsubscribe instructions: E-mail to [hidden email]
> > Problems?
> > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> > List archive: http://listarchives.libreoffice.org/global/design/
> > All messages sent to this list will be publicly archived and cannot be
> > deleted
> >
> >
>



--
Unsubscribe instructions: E-mail to [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Next » 12