Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

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

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

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
it. Otherwise, there is no difference between it and the toolbar -- it
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

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,
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
you work with most in these applications. Hue represents category
the object is mostly visual, audible, textual, numerical, or a
of these), darkness shows hierarchy ("Page" is superior to "Paragraph",
which is superior to "Text", so "Page" is darkest and "Text" lightest)
contrast shows relevance (a paragraph can not only contain text, but also
an image, although its primary purpose is still holding text, so its
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
Sure it takes a little while to get used to, but it really makes much
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.



Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be

Q: Why is this email five sentences or less?

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.