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


Hello Christoph,

----- Mail original -----
De: "Christoph Noack" <christoph@dogmatux.com>
unbelievable ... at least for me: after several weeks I've finally
managed to have a running libo-daily :-) So let's get back to work
and
have a look on your fine changes.

Cool!

Am Donnerstag, den 18.08.2011, 14:42 +0200 schrieb Cedric Bosdonnat:
On Wed, 2011-07-06 at 09:52 +0200, Cedric Bosdonnat wrote:
I just moved the color definition to the options in the master
branch:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=d40dce0f0f00b88dd645a0f334e3d7b2d6af6515

I also changed the way the colors are defined: you define the main
color
(the one of the line) and the background color is that color with
the
luminance multiplied by 2.5. I tested with several colors and it
looks
quite nice in those cases too.

I hope this helps to make it a nice feature,

Thanks! At the moment, I'm thinking about how to make use of that -
we
have several hard-coded elements that would benefit if we could share
those color(s).

What are you thinking about? Those colors are already shared in the options... or there is 
something I don't understand

So, what was the real intention of the feature - please bear with me
if
I didn't get it so far. Here some proposals to choose from (or to add
one):
     1. It should be avoided that people accidentally enter the
        header/footer and "destroy" the given content / formatting
        (on
        several pages at once).
     2. It should be avoided that people are distracted from headers
     /
        footers when writing on the document content. Thus, the
        remaining elements get grayed out when not working on them.
     3. It should be avoided that people don't know what kind of
        header/footer they are editing.
     4. 1 ... 3 at once

First it was #1, but then the user/customer requested the separator thing... so I guess they were 
way too used to that thing. I wasn't really found of that UI thing... but you know how customers 
are ;)

The original problem was that we had tons of .DOC documents with an enormous picture anchored as 
background in the header to live with. In a lot of cases, clicking in the document body picked the 
picture instead of picking some paragraphs... that's why I needed to avoid the user to mistakenly 
click on the picture from the header / footer.

So, given all the alternatives, the current implementation misses
some
bits and pieces. From my POV, #1 could be solved differently, #2
de-WYSIWYGs Writer, #3 could be solved differently. Personally, I
really
need to know what was the original requirement ...

I agree with the de-WYSIWYG-ation of Writer, do you have an idea to show that more clearly? I have 
to admit that I had to hack the painting quite intensively to get it working in almost all cases... 
and I'm not too proud how some bits in that area.

I'm ready to make it better, though I spent quite a lot of time and energy to make it working 
almost nicely and would be quite disappointed if I had to throw it all away. 

Some of the things I've noticed:
      * Enter: It is hard to identify how to enter the header /
      footer -
        the given visualization (borders) highlight active text areas
        that can be entered via one click. But these areas are
        inactive ... unless the user double-clicks (which is not
        visualized to the user).

Is there anything we could do to make it easier to identify?

      * Abort: It is hard to identify how / and cumbersome to go back
      to
        the document content. In contrast to MSO, there is no
        visualization / hint how to do that. Examples:
              * Double-click is unusual (in LibO) and there is no
              visual
                clue

What kind of clue / mechanism would be more natural to users then?

              * Although single-click doesn't work to go back to the
                document content, right-clicking once works - why?

Doh! that's a bug / something I missed in the implementation.

              * ESC in header/footer goes back to the last position
              in
                the document, but: if the user moved to another page
                in
                the meantime, it jumps to the old location

Where should it go to in those cases? Should it be moved to the beginning of the current page in 
all cases?

      * Usability issues:
              * I've noticed (as Cor pointed out) some issues, e.g.
              it
                doesn't work well with Notes. For example:
                      * Edit the header content
                      * You can change into an existing note with
                      single
                        click (is that different to the document
                        content?)
                      * For exit, press ESC - the cursor is moved
                      back
                        to the document, but the content is shown
                        inactive (although I can edit it) --> users
                        get
                        lost
              * It also doesn't work well if headers/footers are
              removed
                when editing them ... all the highlighting stays (the
                banner and the grayed out document). --> users get
                lost

Ok, those are clearly bugs and I need to fix them.

              * I think the "Edit - Headers&Footers" behavior is a
              bit
                strange. Its deactivated, if there is no
                header/footer
                on the page. But, its activated if either header or
                footer is there. Then, the missing item gets
                highlighted
                anyway ... without providing a clue how to really add
                this missing element. --> could be more supporting

An option here is to enable that menu item in all cases. If triggered when there is no 
header/footer in the document, then it would add them to the current page style. How does it sound?

      * Technical issues: In my test environment (Fedora 15,
        VirtualBox), I regularly have ghost cursors showing up - if
        you
        change the mode when the blinking cursor is shown, it doesn't
        get removed (e.g. entering the header from the document, the
        document keeps a non-blinking cursor).

Could it come from the fact it's in a virtual machine? I had that fixed a while ago... but I may 
have missed something.

      * I'm still thinking how it should work in "facing pages" mode
      ...
        --> the common elements are usually mirrored in such
        situations

Ouch... I haven't though about that case! There may be some tricky cases there.

      * The feature could (as already pointed out) be more helpful if
      we
        actively show options like "exit, add header/footer, remove
        header/footer", ...

Sure! Where would they be best to be placed? In some menu, a toolbar or somewhere else?

Argh, just to mention that, beginning on Thursday, we'll have our
family
vacation until the Hackfest ... and there won't be any Internet
connection, as far as I know.

Hackfest will be a good time to brainstorm lively on that :D

--
Cedric

Context


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.