Highlight feature uses underline icon

[dotancohen]

Zim does not have an underline feature, but rather a highlight feature. However, the highlight feature is represented by an underline button on the toolbar. This shoul be changed to a different icon.

[Jaap Karssenberg (jaap.karssenberg)]

Due to styles design. I tried to separate meaning and look of the formatting styles. However having buttons for "strong", "emphasis" and "highlight" scared away people used to "bold", "italic" and "underline" icons.

I agree it needs improvement, but will wait until styles are fixes properly.

[dotancohen (dotancohen)]

Note that in the Format menu, the Highlight feature is called Underline. This is even worse than just using the icon!

[dotancohen (dotancohen)]

> Due to styles design. I tried to separate meaning and look of the
> formatting styles. However having buttons for "strong", "emphasis"
> and "highlight" scared away people used to "bold", "italic" and "underline" icons.

In that case, use the "bold" and "italic" icons, but your own "highlight" icon. Substituting the "underline" icon is a usability issue.

[Jaap Karssenberg (jaap.karssenberg)]

Will change names to "emphasis", "strong" and "mark" while keeping the icons for italic, bold and underline respectively. This should make it clear that zim treats these styles different from tools that do visual layout.

[dotancohen (dotancohen)]

As per comment #4 on bug #271918:
https://bugs.launchpad.net/zim/+bug/271918/comments/4

I am attaching a mockup of a styles configuration dialog for "Strong", "Emphasis", and "Mark" that I think would satisfy all the current styles issues.

[Jaap Karssenberg (jaap.karssenberg)]

See also bug #230160, which is the explicit request for such a dialog.

[dotancohen (dotancohen)]

Thanks, I posted the dialog there.

I suggest that "Strong", "Emphasis", and "Mark" not use the Bold, Italic, and Underline buttons as those formating options are not hard coded to them. I suggest one of the following:
1) A dynamic button that changed based on the configuration. The icon could be regenerated each time the style configuration changes.
2) Descriptive pictograms that are not formating related. Strong could be, for instance, a muscular arm icon. Emphasis could be an exclamation point icon, and Mark could be a thick pen icon.

[Jaap Karssenberg (jaap.karssenberg)]

I disagree. I think an icon of a bold letter is much clearer than the icon of an arm. I agree that this may not be perfect rendering of what the icon does exactly, but the tooltip, menu text etc. are there to counter that. Changing icons automatically is even worse because it will confuse users and undermines a consistent look.

[dotancohen (dotancohen)]

> I disagree. I think an icon of a bold letter is much clearer
> than the icon of an arm.

Not if that is not what the icon does.

> I agree that this may not be perfect rendering of what the icon
> does exactly, but the tooltip, menu text etc. are there to counter that.

That is not the purpose of the tooltip, to clarify the _wrong_icon_. Maybe the icon of an arm is not a good solution, but neither is the bold icon. What else can be used as an icon, to represent the idea of strong?

Naturally, the issue does not affect the menu text.

> Changing icons automatically is even worse because it will confuse users and undermines a consistent look.

I agree with this statement.

[dotancohen (dotancohen)]

> What else can be used as an icon, to represent the
> idea of strong?

Maybe a dumbbell? A Viking helmet? A sword?

[Jaap Karssenberg (jaap.karssenberg)]

Closing this bug because I do not plan to change icons for now. When specif alternative images are available, a new bug can be opened.

[manny (estelar57)]

i just noticed that cherrytree uses the same icons (probably gpl?), but in a more intuitive way, i see no problem with borrowing 1 or 2 :)

[Ari (ari-reads)]

Just migrated from tomboy to zim with a massive number of notes (after 10 years of using it). I was about to open a feature request for a missing highlight feature!

I have to agree with most of the comments, IMHO this is indeed a usability issue. Sad to see it was marked as won't fix. I understand it may not be a priority but still an issue - common sense.