Bug 38194 - Style indicator in document margin
Summary: Style indicator in document margin
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 50516 133258 (view as bug list)
Depends on:
Blocks: Sidebar Writer-Styles Writer-Enhancements
  Show dependency treegraph
 
Reported: 2011-06-11 15:43 UTC by fenglich
Modified: 2022-11-04 09:43 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Mockup (252.75 KB, image/png)
2019-08-27 09:19 UTC, Heiko Tietze
Details
Revised mockup (493.83 KB, image/png)
2019-09-03 08:25 UTC, Heiko Tietze
Details
Alternative mockup (246.63 KB, image/png)
2019-10-02 08:30 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fenglich 2011-06-11 15:43:03 UTC
When editing documents and wanting to have a strong control over formatting, I've found Microsoft Word's style guides feature highly useful.

Here's a screen shot of the feature in use, found with Google Images:

http://common3.ziffdavisinternet.com/util_get_image/23/0,1425,i=235534&sz=1,00.jpg

Implementing it could 1) Provide useful functionality 2) Make it easier for Microsoft Word users to adopt LibreOffice.
Comment 1 Björn Michaelsen 2011-12-23 12:26:08 UTC Comment hidden (obsolete)
Comment 2 Florian Reisinger 2012-08-14 14:01:35 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:02:39 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:07:14 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:09:20 UTC Comment hidden (obsolete)
Comment 6 fenglich 2012-08-16 02:20:04 UTC Comment hidden (off-topic)
Comment 7 Florian Reisinger 2012-08-16 07:26:28 UTC Comment hidden (off-topic)
Comment 8 fenglich 2012-08-29 12:59:33 UTC
*** Bug 50516 has been marked as a duplicate of this bug. ***
Comment 9 Brian Westlake 2013-07-11 04:30:41 UTC
Hello LibreOffice Developers,

This functionality/feature enhancement request, if implemented, would significantly contribute to the migration of users from Microsoft Office to LibreOffice.

The synchronised Style pane is one of the most useful features of Microsoft Word, and is extremely handy for debugging the meta-structure of word documents - a 'logical structure debugger', if you will.

Please refer to the equivalent feature enhancement request for OpenOffice, and the commentary therein:

https://issues.apache.org/ooo/show_bug.cgi?id=76667

This is what the synchonised style pane looks like in Microsoft Word:

http://www.bettersolutions.com/word/WXX433/LR910331212.htm

One could also envisage a page element panel as well, displaying page, section, header and footer characteristics, synchronously.

Part of a fully general, *synchronous*, dockable, multi-pane 'logical structure debugger'.

It would be the cat's miaow, the ant's pants, the bee's knees and the banana's pyjamas, in no fixed order. :-)

Thank you for your attention.

Yours faithfully,

Brian Westlake.
Comment 10 Florian Reisinger 2013-07-11 05:45:39 UTC
Changed some bits...
Comment 11 Brian Westlake 2013-07-11 07:22:58 UTC
Thank you very much Florian.

It will be removing a major disincentive to migrate from MS Office.
Comment 12 Brian Westlake 2013-09-14 00:37:58 UTC
With the implementation of experimental Sidebars functionality, in LibreOffice 4.1.0, from the IBM Lotus Symphony Office codebase, it might have become easier to implement this feature.

The sidebar does have a style panel, however it is not the functionality provided by the microsoft style area as previously described.

Given that the Sidebars work in single page view, would there not be the possiblity of having both left and right sidebars (either none, XOR, or both)?

If so, could not the microsoft functionality be implemented in a right sidebar?

On the road to a fully optioned logical (meta-)structure debugger. :-)

Thank you for your attention, LibreOffice developers.
Comment 13 Brian Westlake 2014-11-06 05:57:29 UTC
Dear Libreoffice Developers,

Admittedly a "bump".

However this link provides a neat summation of the "Reveal Code" functionalities of Microsoft Word (and WordPerfect), including the "Style Area", which is the specific functionality of this feature request:

http://wordfaqs.mvps.org/revealcodes.htm

A fully fledged "Logical Structure Debugger" integrating the best from Word and WordPerfect, and eclipsing both, for Writer would contribute strongly to the uptake of Writer from Word users, in particular.

Thank you for you attentions.

Best regards,

Brian Westlake.
Comment 14 Heiko Tietze 2019-04-30 13:10:26 UTC
I like the idea of having a visual indicator in the document margin to give a visual feedback of the applied style. Makes it easier to format the document. However, it's not necessary to copy Microsoft, so I changed the summary a bit.
Comment 15 Heiko Tietze 2019-08-27 09:19:31 UTC
Created attachment 153684 [details]
Mockup

Here is a (first) mockup. It adds the request of nested styles (bug 115311 c5) that makes a combination of paragraph and character styles necessary and the styles inspector from bug 112852, see also bug 90646). And takes also bug 94427 into account (see comment at the styles inspector).

The actual requirements for all those tickets are:
* Eve wants to use paragraph and character styles to properly format the document.
* Eve wants to get insights to applied styles to format the document consistently.
* Eve wants to apply styles easily meaning to organize, sort, and filter the lists.
* Eve wants to see what properties a style has to make sure the applied variant is correct.

While the mockup in bug 115311 shows more or less all properties, I went here with the difference to the parent style to cover with the limited space. That means Default would always have no information in the style indicator. Drawback is that some special children of Text Body, for example, with just have one different property list only this particular value.

For the document, it's a bit confusing to highlight character styles, eg. "Slowly" has a background color (direct formatting here, shown as gray overlay), which would spoil the yellow indicator. The only ultimate solution is to also have character styles at the left "indicator line", toggled with paragraph information. I don't think that's a good solution, however.
Comment 16 Thomas Lendo 2019-08-28 00:28:05 UTC
Very nice, thanks for the mock-up, Heiko.

I've two general concerns.
First, character styles are indicated within the text, paragraph styles in the margin. I'd prefer to show both in the margin, maybe character styles only as a line with the third of the width of paragraph indicator? (The whole paragraph style indicator is e.g. red and there is a character style in one line for which a yellow indication is visible in the margin that is as high as the line and has a third of the width so that in this line the indicator is red in two-thirds and yellow in one-third. If there is a second character style in the same line, the character indicators takes two-thirds of the space. Paragraph + 1. character + 2. character style. If there are more character styles in the same line, they share at maximum the two-thirds of the space. I doubt there will be so much character styles in a line that this results in indicators with hairbreadth. ;) )

Second, paragraph indicators should have strong colors and character styles should have pastel colors. But are there enough colors to show all possibilities in a document? We've soooo much pre-defined styles ...
Comment 17 Cor Nouws 2019-08-28 18:12:40 UTC
Well, as long as users can turn it off.
For most use cases it is a bit overkill - IMHO :)
Comment 18 andreas_k 2019-08-28 18:57:21 UTC
(In reply to Cor Nouws from comment #17)
> For most use cases it is a bit overkill - IMHO :)

that will be true. In addition if you have this colorfull layout what do you do with it? is it to review style usage. Most users don't care about styles.

Would it be more helpful to use an mockup language layout. for example you have something like 

<h1>First chapter</h1>

<p>He heard quit steps behind him. .... <i>particular moment</i>, just after he pulled off the <b>big time</b> and was making off ...

or any other mockup language like markdown or latex. with syntax highlighting it gave an good overview and you can change stuff like in an text editor.
Comment 19 Tomaz Vajngerl 2019-08-29 23:34:25 UTC
andreas_k - you just reinvented "reveal codes" from Wordperfect :)
Comment 20 Thomas Lendo 2019-08-30 00:17:22 UTC
(In reply to Tomaz Vajngerl from comment #19)
> andreas_k - you just reinvented "reveal codes" from Wordperfect :)
See bug 34002 ;)
Comment 21 Heiko Tietze 2019-08-30 05:36:24 UTC
(In reply to Thomas Lendo from comment #16)
> I'd prefer to show both in the margin, maybe character styles
> only as a line with the third of the width of paragraph indicator?

There could be more than one character style in one line. So it would be many lines next to each other. The mixing approach, 1/3, 2/3 etc., sounds a bit complex to me.

> Second, paragraph indicators should have strong colors and character styles
> should have pastel colors. But are there enough colors to show all
> possibilities in a document? We've soooo much pre-defined styles ...

Guess we have to randomize the colors. And what's missing in the indicator bars is a number to not only rely on the color. Doesn't work with my way to highlight character styles.

(In reply to andreas_k from comment #18)
> Would it be more helpful to use an mockup language layout. 

Isn't the markdown/reveal code approach the opposite of feedback to the WYSIWYG document? I mean you enter (a few) styles to the document - and we have formatted it. Point here is to get an overview and understanding of what is applied and how styles are defined.
Comment 22 andreas_k 2019-08-30 07:42:58 UTC
> (In reply to andreas_k from comment #18)
> > Would it be more helpful to use an mockup language layout. 
> 
> Isn't the markdown/reveal code approach the opposite of feedback to the
> WYSIWYG document? I mean you enter (a few) styles to the document - and we
> have formatted it. Point here is to get an overview and understanding of
> what is applied and how styles are defined.

Maybe its the other way around, but this is a complete new ui scenario and mockup languages + highlighting is an well known approach from coding, html editting, ... for me mockup language support is the link between latex users, coders and an office suite.

I am thinking more like webinspector tools from firefox and chrome. Split the content into text and styles into an separate view.
Comment 23 Heiko Tietze 2019-09-03 08:25:28 UTC
Created attachment 153832 [details]
Revised mockup

Here is the revised version. Colored variant has now also numbers to not only rely on colors. And I added a B/W version according Andreas' comment.


Pure mark-up means to read the raw document that contains this information. For example, just a little bit stripped for only style information:

   <style-name="Heading_20_1">First chapter</text:h>
   <text:style-name="Text_20_body">He heard quiet steps behind him. That didn&apos;t bode well. Who could be following him this late at night and in this deadbeat part of town? And at this <text:style-name="T4">Emphasis</text:span></text:p>, just after he pulled off the <text:style-name="T4">big time</text:span> and was making off with the greenbacks. Was there another crook who&apos;d had the same idea, and was now watching him and waiting for a chance to grab the fruit of his labor?</text:p>
   <text:style-name="Caption">Or did the steps behind him mean that one of many law officers in town was on to him and just waiting to pounce and snap those cuffs on his wrists?...

Mark-up is not for humans ;-). At least not when it goes beyond <b>/<i>.
Comment 24 Regina Henschel 2019-09-04 10:16:39 UTC
Putting such information into the comment margin will conflict with ordinary comments. This area is too small anyway. I see also problems with adding rectangles to the page margins. You would need to touch a lot of code, to distinct them from other graphic content. So I do not like that idea at all.

But I support Andreas' idea of a separate inspector window similar to those known from DOM inspectors. It has the advantage, that it needs no code integration, but can be provided purely as extension. Such window would allow a more detailed view on the inheritance of properties. For example, a portion of text can have a direct format "yellow", a character style with "italic", which is derived from a character style with language set to "German", and uses the font height of the paragraph style, which inherits the font itself from the default style. And such window can be freely positioned and sized.
Comment 25 Heiko Tietze 2019-09-04 12:40:30 UTC
(In reply to Regina Henschel from comment #24)
> Putting such information into the comment margin will conflict...

Comments go to the right document margin, the indicators are at left (at least for LTR). Where exactly do you see the issue?
Comment 26 Regina Henschel 2019-09-04 13:41:35 UTC
Then I do not understand your mockup. I thought the blue parts show the character formatting of the marked text part.
Comment 27 Heiko Tietze 2019-09-04 14:23:13 UTC
(In reply to Regina Henschel from comment #26)
> Then I do not understand your mockup. I thought the blue parts show the
> character formatting of the marked text part.

I took the formatted dummy text example as available in this extensions [1] as prototype. This dummy text has comments for testing purpose. Changes are only made to the left margin and the content. Didn't I write some text?
Comment 28 Heiko Tietze 2019-09-04 14:24:03 UTC Comment hidden (off-topic)
Comment 29 Heiko Tietze 2019-09-25 08:32:23 UTC
*** Bug 127708 has been marked as a duplicate of this bug. ***
Comment 30 Eyal Rozenberg 2019-09-25 09:10:14 UTC
(In reply to Heiko Tietze from comment #15)
> t's a bit confusing to highlight character styles, eg.
> "Slowly" has a background color (direct formatting here, shown as gray
> overlay), which would spoil the yellow indicator. 

Maybe consider the possibility of suppressing text-highlighting when enabling style indicators?
Comment 31 Heiko Tietze 2019-10-02 08:30:29 UTC
Created attachment 154693 [details]
Alternative mockup

MikeK suggested to separate the two workflows. The highlighting is supposed for cleaning up while the inspector shows the reason of the actual layout.

I recommended in bug 127708 to have the ability to remove single properties from a style in this inspector but changed my mind. Better we provide an interaction to go to the paragraph or character style dialog and have some means there than overloading this widget. So right click (or some tiny button on top as well) opens the respective dialog.
Comment 32 Thomas Lendo QA 2019-10-02 21:01:55 UTC
(In reply to Heiko Tietze from comment #31)
> I recommended in bug 127708 to have the ability to remove single properties
> from a style in this inspector but changed my mind. Better we provide an
> interaction to go to the paragraph or character style dialog and have some
> means there than overloading this widget. So right click (or some tiny
> button on top as well) opens the respective dialog.
I support this with a button to open the corresponding style dialog tab.
Comment 33 Xisco Faulí 2019-11-29 13:27:19 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 34 Heiko Tietze 2020-05-22 12:49:57 UTC
*** Bug 133258 has been marked as a duplicate of this bug. ***
Comment 35 Luke Kendall 2020-05-22 13:14:25 UTC Comment hidden (off-topic)
Comment 36 Luke Kendall 2020-05-22 14:10:33 UTC
Please ignore my last comment: I thought I was applying it to bug 133258.

I will note in passing though that often when I view the HTML produced from Writer (or if I delve into the XML), I find long sequences of various kinds of text styles that are all the same, sometimes in sequences, sometimes nested.
The style changes have no perceptible effect (they're just "no-ops") and merely complicate the structure. So if that structure was revealed by some kind of "show codes", it would reveal the "under the rug" complexity.

My feeling is that much of the complex structure seems to be caused merely by editing the text - as if runs of text are broken to allow new text to be inserted (or deleted), even though there is no change in style.  But that's just my intuition, based on knowing I haven't applied direct formatting, simply changed my mind about phrasing, or adding or removing information.
Comment 37 Commit Notification 2021-07-30 10:15:10 UTC
Anshu committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/172f589471edcac9a4974132a3145b721942879a

tdf#38194 related: introduce StylesList control

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 38 Eyal Rozenberg 2021-07-30 11:15:31 UTC
Two issues:

1. What turns this color-coding on?

2. What about people with different kinds of color blindness? Patricularly Green-Red? Is it possible to control the palettes somehow?
Comment 39 Heiko Tietze 2021-08-09 09:26:12 UTC
(In reply to Eyal Rozenberg from comment #38)
> 1. What turns this color-coding on?

The patch is just a minor step ahead. It separates the internal logic from the visualization. The color coding comes later.
Comment 40 Eyal Rozenberg 2021-08-09 10:16:23 UTC
(In reply to Heiko Tietze from comment #39)

I wasn't asking about the patch, but in general. What _should_ turn the color-coding on? ... looking at the mockups again - is it supposed to be the "highlight styles" checkbox?
Comment 41 Heiko Tietze 2021-08-09 10:24:44 UTC
(In reply to Eyal Rozenberg from comment #40)
> (In reply to Heiko Tietze from comment #39)
> 
> I wasn't asking about the patch, but in general. What _should_ turn the
> color-coding on? ... looking at the mockups again - is it supposed to be the
> "highlight styles" checkbox?

Yes, this checkbox is supposed to turn on the color coded bars in the document margin.
Comment 42 Eyal Rozenberg 2021-08-09 10:47:37 UTC
(In reply to Heiko Tietze from comment #41)
> Yes, this checkbox is supposed to turn on the color coded bars in the
> document margin.

Well, in that case, there needs to be some bike-shedding about its text, because it's a bit confusing. It could mean "styles for highlights".

Also it takes up vertical real-estate, which may be in short supply if the styles bar gets split in two. But I'm just pointing this out as something to consider later on.
Comment 43 Heiko Tietze 2022-02-01 09:38:27 UTC Comment hidden (noise)
Comment 44 Eyal Rozenberg 2022-03-07 14:21:01 UTC
A question about the second mockup: Are the comments with the style names supposed to be part of this feature? i.e. will the style indicator add comments with style names? Otherwise, they're a bit confusing.
Comment 45 Heiko Tietze 2022-03-07 15:12:01 UTC Comment hidden (obsolete)
Comment 46 Eyal Rozenberg 2022-05-24 21:10:52 UTC
This is just for Writer, right?
Comment 47 Brian Westlake 2022-09-12 04:56:35 UTC
Hello,

I am early, non-technical, commentator, from the early years (2013, 2014) of this feature request.

I was wondering if the feature was anywhere near being fully implemented in a public release?

Thank you.
Comment 48 Heiko Tietze 2022-11-04 09:43:58 UTC
*** Bug 151707 has been marked as a duplicate of this bug. ***