[libreoffice-design] 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 design+help@global.libreoffice.org
> 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 design+help@global.libreoffice.org
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