[Libreoffice-ux-advise] GSOC work on Special Character dialog

[V Stuart Foote]

Heiko,  *

Sorry if I missed the boat during discussions for dropping an edit buffer for input but it is the correct workflow for composing and entering strings.  Unfortunately the impact of replacing it with single character pick/place is a major loss of function that was not discussed or reviewed. it is not about the number of key strokes needed to place a character to canvas, rather it is about the ability to work with multiple fonts and the language scripts they support.

Discussion and work in tdf#34882 [1] was for adding search, a favorites/recently used glyph list, and even OCR search. It did  not include removing the "Characters" edit bar/edit buffer and the whole work flow it supported. That somehow came out of the design session [2] placing emphasis on shifting UI to only a recently used pick list. It frankly removes one of the most useful features of LibreOffice for working with multiple scripts. 

For comparison of what is being lost, please have a look at the Windows utility BabelMap [3], or the BablePad text editor that incorporates it.  The multi-line "edit buffer" there allows assembling Strings of glyphs, even as sentences, from multiple fonts.  We should be implementing more features supporting that Unicode based workflow, not removing them.

For LibreOffice the dialog benefits from the addition of recently used glyphs, as for tdf#34882, but removing the "Characters" edit bar deletes useful interface for no reason.  Before this gets too far, please restore the "Characters" edit bar as a buffer for composing strings as removing it was ill-considered.  Providing just a pick/place to canvas UI is wrong.

Stuart

=-ref-=
[1] https://bugs.documentfoundation.org/show_bug.cgi?id=34882
[2] https://docs.google.com/document/d/1PxkIpkzgWF1cX9oQmBhjiTBhUXvUEqbz06Bn4hzbF54/edit
[3] http://www.babelstone.co.uk/Software/BabelMap.html
________________________________________
From: Heiko Tietze <tietze.heiko at googlemail.com>
Sent: Monday, July 10, 2017 6:25 AM
To: V Stuart Foote
Cc: libreoffice-ux-advise at lists.freedesktop.org
Subject: Re: [Libreoffice-ux-advise] GSOC work on Special Character dialog

Hi Stuart,

this modification is being done intentionally. I don't see the benefit
from clicking <FOO> (into the edit bar) plus Insert (to actually
insert the string) compared to double-click <F><O><O> which inserts
the chars into the document and adds them to the list of recently
used. One click less (okay, two more if you count double-click twice).
But more important, we focus on the actual workflow. I doubt the
usefulness of compiling a string from the special chars, and at least
90% users will use only a few special chars but never make a special
string.
The workflow/design was introduced in 2015 at
https://user-prompt.com/de/libreoffice-design-session-special-character/
without concerns about lost functionality.

Cheers,
Heiko

2017-07-08 21:13 GMT+02:00 V Stuart Foote <VStuart.Foote at utsa.edu>:
> @Samuel, Heiko, Akshay, *
>
> Looks like Akshay is making progress on his GSOC special character dialog
> work. But I am concerned that the "Characters" edit bar of the dialog has
> been dropped from the UI. And  now only have the new "Recent Characters"
> glyph boxes available.
>
> Functionally the Characters/edit bar allows one to assemble a string for
> insertion into a document by picking multiple glyphs from the selected
> active font with a shaped/rendered preview, and then to insert the entire
> string to document canvas. This is VERY necessary for efficient input of
> content from different language/scripts than current text body where the
> "preview" of the Characters/edit bar lets one review the string prior to
> insertion.
>
> The double-click Pick/Place behavior as we seem to be shifting to is simply
> not as efficient and actually slows down string input making it a single
> character at a time process.   Not clear there is a valid justification for
> dropping the "Characters"  edit bar, please have another look and add back
> that function.
>
> Stuart