[Libreoffice-ux-advise] Hiding/Showing the page breaks in writer

Christoph Noack christoph at dogmatux.com
Tue Sep 27 14:37:22 PDT 2011

Hi Cedric, all!

Am Dienstag, den 27.09.2011, 09:40 +0200 schrieb Cedric Bosdonnat:
> Hi Christoph,
> I'm having a fun hackweek here at SUSE working on a CMIS integration for
> LibreOffice (that is to help having it connected with Alfresco,
> SharePoint and friends). Thus there won't be any progress on the writer
> feature this week.

Well, there is progress with the other stuff you've mentioned ... and it
helps me to take care of other features as well ;-)

> On Sat, 2011-09-24 at 13:09 +0200, Christoph Noack wrote:
> > > I like the color red, but in this case, I still find it to different 
> > > compared to the rest of the 'color scheme' (Options > Appearance > Text 
> > > Document).
> > > I would vote for the 'Manual page break blue' from Calc.
> > 
> > Consistency is important, yes. Wasn't the color "red" introduced,
> > because the dark blue was hardly visible when using the old document
> > borders? Now, the blue color would work well again - so indeed it makes
> > sense to go back (another reason: red is considered to be a color for
> > warnings, blue for information).
> Let's go for the blue again...


> > Another small refinement - I think the current button interferes a bit
> > (only a bit) with the shadow. From my point-of-view, could you move it a
> > few pixels to the left?
> Well, it'll always interfere with something there... I even plan to make
> the button move with the page view to make sure we can always see it.

In this case, I'd say we should keep its position constant - otherwise
zooming/scrolling will make the page behave in a way that doesn't feel
"natural". To me, the header/footer was an exception, since you
initially stated that people should be always be aware when editing
headers/footers. But for the page break indicator, we have that nice
line that's always visible ... people just need to "follow" that.

> > Nevertheless, the current "button" might be something people don't want
> > to see all the time ... if you remember my proposal [1] of having "fade
> > in / out" functionality for the headers/footers, this can solve a bunch
> > of problems here, too. For example, for column breaks the button may
> > also just appear if the user hovers the red line (e.g. if not knowing
> > what this is about). Same for the "side by side" view mode.
> The fade in/out thing makes probably more sense here than on the
> header/footers thing as the page break indicator is always visible
> otherwise.

Fine for the page break, but some small refinement what I had in mind
concerning header/footer:
      * full fade in / out avoids being "suprised" when the markup
      * intermediate fade in helps us to show the feature earlier,
        without bothering the user

> > The "book mode" has also been addressed in this thread; I propose to
> > only draw the line above the page that gets "page breaked", so something
> > like that (page break on left page, affects next page):
> > 
> >         
> >         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br
> >         +-----------------------------+-------------------------------+
> >         |                             |                               |
> >         |                             |                               |
> >         |                             |                               |
> > 
> I think we are on the same ideas here.


> > One additional thing I'd like to know - Cedric, if we are sure that the
> > basic stuff is finished, could we ping / involve the documentation team,
> > so that the help texts are adapted accordingly? Just ping me if you
> > think its done, then I have a (UX) look at it again, and then we can
> > forward the discussion to the doc team - agreed?
> I'm not sure this is the final behavior... but we are approaching it.
> For example the Fade in/out things may need to be documented... and they
> aren't implemented yet.

Mmh, I think we (in terms of development) need the documentation of the
fade in/out behavior ... but I think the basic functionality for the
user should (soon) be fine. Please, all, if we think we're somehow
finished ... then please remember to ping the other teams to make sure
it will be a great LibO release :-)

> > Cedric, thanks a lot for making Writer a "cool thing" ;-)

Same again :-)


More information about the Libreoffice-ux-advise mailing list