Re: [libreoffice-design] 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 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