Family Historian User Group

ColeValleyGirl wrote: ↑

14 Dec 2022 14:33

Using exclusively plain text gives certainty about what will be exported/displayed, and using the plain text editor to manipulate plain text eliminates the risk of introducing inadvertent formatting (via user error or otherwise).

(my colouring/emphasis)

Knowing we have plain text can be useful, but I see having two editors as just "wrong" liable to give rise to all sorts of confusion. Are there other ways to "eliminate the risk of introducing inadvertent formatting", but have just a single editor (without funny key strokes to get at an alternative editor) with possibly a "Close as Rich Text" and a "Close as Plain Text" option? (Assuming that the editor code interface is available to CP for such modification!)

(Although I might argue that if you can get "paste unformatted" to behave acceptably - none of this matters, all Long Notes can be saved as Rich Text even if they only hold plain text)

With some subtle but significant differences, Mike.

Your proposal talked about a Preferred Formatting and made some (slight) modifications to the behaviour of the two editors (plus the new shortcut for pasting unformatted text).

Mine talks about having a Preferred Editor and makes no changes to the behaviour of either editor (other than the shortcut, and the need to support AutoText for the Plain Text Editor). It does propose improved ease of access to the Plain Text Editor (personally, I'd look to see icons for opening both/either of them, not just a double-click, or Ctrl-Alt-... mechanism but that's an implementation detail best left to CP to make consistent with their whole UI.)

I've also proposed a subtly different bulk conversion option, that allows for conversion of selected rich text Notes, not just all rich text or a single rich text note.

I will add to my proposal that when converting rich text to plain text, the results should be the same as when exporting a Gedcom using the FH Facility and asking for rich text to be converted to plain text.

davidf wrote: ↑

14 Dec 2022 15:18

I see having two editors as just "wrong" liable to give rise to all sorts of confusion.

Like having two ways to construct a source?

Are there other ways to "eliminate the risk of introducing inadvertent formatting", but have just a single editor (without funny key strokes to get at an alternative editor) with possibly a "Close as Rich Text" and a "Close as Plain Text" option? (Assuming that the editor code interface is available to CP for such modification!)

I do agree about the funny key strokes, hence asking for an easier way of accessing the plain text editor on demand. (I'd like to see an easier way for the rich text editor as well, but nobody else has asked for that).

A Close as Rich Text/Close as Plain Text option runs the risk of somebody saving a rich text note as plain text and not realising they've lost formatting and possibly even content. IMO it'd be even more confusing than two editors.

I might argue that if you can get "paste unformatted" to behave acceptably - none of this matters, all Long Notes can be saved as Rich Text even if they only hold plain text)

As I implied before, the storage format is a red herring; it's the UI behaviour we should be focussed on.

The 'snag' is that some users want Ctrl+V to perform an unformatted paste (as it does in the FH V6 plain text editor box).
That can only rationally be achieved by having a plain text default mode and plain text edit box in which Ctrl+V and Ctrl+Shft+V both paste unformatted text.
If I understand correctly, that is effectively how it works in AS by having a plain text editor separate from a rich text editor.

An associated wish is that short-text fields like the Citation Where Within and Facts tab Sentence box need a plain text editor.
See Wish List Ref 545 Edit window for short Text fields.
That would make such a plain text editor box a comfortable option for long-text fields.

tatewise wrote: ↑

14 Dec 2022 15:54

The 'snag' is that some users want Ctrl+V to perform an unformatted paste (as it does in the FH V6 plain text editor box).

It already does this in the Plain text editor box in V7, so no snag.

I've just checked and the 'Plain text editor' doesn't have spell-checking... Could be a problem?

Does a "V6 editor" without the V7 bells and whistles meet the needs of a Plain Text Only setting?

Or is the requirement for all the bells and whistles except formatting controls?

For clarity, I think this only affects the specification of requirements. It would be up to CP how they implemented it -- enhancing the existing Plain text editor, or removing functionality from the rich text editor, as long as both types of editing were available at all timers to everyone.

ColeValleyGirl wrote: ↑

14 Dec 2022 15:57

tatewise wrote: ↑

14 Dec 2022 15:54

The 'snag' is that some users want Ctrl+V to perform an unformatted paste (as it does in the FH V6 plain text editor box).

It already does this in the Plain text editor box in V7, so no snag.

But not in the Note box prior to opening the editor, so snag.

But if the Preferred editor setting made that box a plain text editor box if the preferred editor was plain text? i.e. didn't change the behaviour of either editor, but made that box to be the preferred option (and double clicking on it opens the same editor in a bigger window).

But the preferred editor setting doe not make a Note box a plain text editor if it already contains formatted rich text.
I believe we have already agreed that mixed mode working still allows both plain text and rich text notes.
When the Note box is opened via its [...] button the appropriate editor opens.
But before the Note box is opened what should Ctrl+V do?
Should it behave according to the preferred editor setting or according to the existing content of the Note?

The tricky cases are:

1. preferred editor setting is plain text but the Note already holds rich text.
   Should Ctrl+V perform an unformatted paste? i.e. paste plain text into a rich text Note.
2. preferred editor setting is rich text but the Note only holds plain text.
   Should Ctrl+V perform a formatted paste? i.e. change the Note into rich text.

Are we writing a coding spec, or a user requirement, Mike?

A coding spec would address the details you mention.

A user requirement would say:

• It should be possible to either:
  • mix plain and formatted text (both elements optional) within a Note, Autotext or other potentially formatted text field (as now) -- referred to here as 'Formatted Editing'
  • or, enforce plain text content within a Note etc. -- referred to here as 'Plain Editing'
• There should be no other differences between the two modes of working. (Catchall to ensure that the functionality available in the V7 editor is all still available in Plain Editing mode, without having to specify it all).
• Mouse and keyboard shortcuts for Paste Formatted text and Paste Unformatted text should be provided. Where formatted text is not allowed, the Paste Formatted text shortcuts will have the same result as the Paste Unformatted text shortcuts.
• User should be able to easily access either mode of working on demand (for accessibility reasons, this should include both mouse and keyboard shortcuts and preferably menu items or icons.)
• The mode of working should be obvious at all times that an editor is open.
• User should be able to switch from one mode of working to the other while an editor is open. If switching from Formatted Editing to Plain Editing, they should be warned this may result in content corruption (e.g. characters not being available in the default font) and asked to confirm they wish to proceed. Ctl+Z (Undo) should undo the conversion just as it undoes other operations.
• A facility should be available to be available to remove formatting from one, many or all instances of formatted text, with a warning that this may result in content corruption (as above). (Question: is it reasonable to expect Ctrl-Z to handle undoing multiple conversions, or does it sit in the same territory as File Merge, which can't be undone.).
• User should be able to set a preference to enforce Plain Text editing (default: Off), which will determine which editing mode is operational by default. If Plain Text editing is set to On and Formatted Text is then opened in the default Plain Text mode, the user should be warned that the content will be converted with the usual content corruption risk. The user can elect to continue in Plain Editing mode or switch to Formatted Editing mode on this occasion.

And even some of that is teaching grandad to suck eggs.

Suggested tweaks?

ColeValleyGirl wrote: ↑

14 Dec 2022 17:16

• ...
• A facility should be available to be available to remove formatting from one, many or all instances of formatted text (i.e. complete field contents), with a warning that this may result in content corruption (as above). (Question: is it reasonable to expect Ctrl-Z to handle undoing multiple conversions, or does it sit in the same territory as File Merge, which also can't be undone.).
  
• A facility should be available to remove formatting from part of an "instance of formatted text" [where part of the text has become a mess and the user wants to revert to plain text and 'try again']
  ...

This post has gotten very long winded and I've tried to keep up to some degree, but I've probably missed something.

I sometimes use rich text (census grids and individual links in my case) and the rest of the time use plain text. It seems like a setting to always use plain text wouldn't work. It seems like a solution might be to easily allow the opening of either a rich text editor or a plain text editor. I know about ctrl-alt-doubleclick, but that is a bit arcane and I don't think many folks know about it. I was happy with the plain text editor in v6 and earlier so don't need a spell checker.

I don't see how ctrl-shift-v is going to really help if it just invokes paste unformatted text which isn't giving truly unformatted text in some cases.

Bill

davidf wrote: ↑

14 Dec 2022 17:34

Suggested tweaks?

ColeValleyGirl wrote: ↑

14 Dec 2022 17:16

• ...
  
• A facility should be available to remove formatting from part of an "instance of formatted text" [where part of the text has become a mess and the user wants to revert to plain text and 'try again']
  ...

Isn't Ctrl+C Ctrl+X Ctrl+Sht+V adequate for that? Especially if documented.

BillH wrote: ↑

14 Dec 2022 17:40

I sometimes use rich text (census grids and individual links in my case) and the rest of the time use plain text. It seems like a setting to always use plain text wouldn't work. It seems like a solution might be to easily allow the opening of either a rich text editor or a plain text editor.

In my proposed Wish List entry posted on Mon 12th Dec 2022 22:40 in viewtopic.php?f=43&t=21280&start=50#p131602 it caters for mixed plain and rich text working. The preference only really applies to creating new notes.
Existing plain or rich text notes open in the appropriate editor.
In both editors, there needs to be an option to change to the other mode, so a plain text note can become rich, and a rich text note can become plain. I think Helen's latest proposals overlook that requirement.

tatewise wrote: ↑

14 Dec 2022 17:56

In my proposed Wish List entry posted on Mon 12th Dec 2022 22:40 in viewtopic.php?f=43&t=21280&start=50#p131602 it caters for mixed plain and rich text working.
Existing plain or rich text notes open in the appropriate editor.
In both editors, there needs to be an option to change to the other mode, so a plain text note can become rich, and a rich text note can become plain. I think Helen's latest proposals overlook that requirement.

Thanks Mike. That sounds like it would work. With all the discussion going back and forth it is easy to get lost and miss or forget things.

Bill

ColeValleyGirl wrote: ↑

14 Dec 2022 17:41

davidf wrote: ↑

14 Dec 2022 17:34

Suggested tweaks?

ColeValleyGirl wrote: ↑

14 Dec 2022 17:16

• ...
  
• A facility should be available to remove formatting from part of an "instance of formatted text" [where part of the text has become a mess and the user wants to revert to plain text and 'try again']
  ...

Isn't Ctrl+C Ctrl+X Ctrl+Sht+V adequate for that? Especially if documented.

That is OK for me, I was just trying to anticipate what might be required. Arguably the same key strokes could hand a "single instance" as well.

Sorry folks, this thread is getting very tedious. We’re defining what we want as users, not redesigning FH or second guessing how to implement it. Can we come up with something succinct and at least credible for CP to evaluate by the end of today please?

BillH wrote: ↑

14 Dec 2022 17:40

I sometimes use rich text (census grids and individual links in my case) and the rest of the time use plain text. It seems like a setting to always use plain text wouldn't work. It seems like a solution might be to easily allow the opening of either a rich text editor or a plain text editor. I know about ctrl-alt-doubleclick, but that is a bit arcane and I don't think many folks know about it. I was happy with the plain text editor in v6 and earlier so don't need a spell checker.

I work the same way, Bill, and am not proposing making it impossible

ColeValleyGirl wrote: ↑

14 Dec 2022 17:16

• User should be able to easily access either mode of working on demand (for accessibility reasons, this should include both mouse and keyboard shortcuts and preferably menu items or icons.)
• User should be able to set a preference to enforce Plain Text editing (default: Off), which will determine which editing mode is operational by default. If Plain Text editing is set to On and Formatted Text is then opened in the default Plain Text mode, the user should be warned that the content will be converted with the usual content corruption risk. The user can elect to continue in Plain Editing mode or switch to Formatted Editing mode on this occasion.

I don't see how ctrl-shift-v is going to really help if it just invokes paste unformatted text which isn't giving truly unformatted text in some cases.

Bill

We have to assume that eventually CP will find a way around the introduction of unexpected formatted text... Paste unformatted does work in the Plain Text editor (Ctl+Alt+... button) but that doesn't help if you need both rich and pain text in the same note.

Mark1834 wrote: ↑

14 Dec 2022 18:10

Sorry folks, this thread is getting very tedious. We’re defining what we want as users, not redesigning FH or second guessing how to implement it. Can we come up with something succinct and at least credible for CP to evaluate by the end of today please?

A bit like https://fhug.org.uk/forum/posting.php?m ... 1#pr131808? which I don't think Mike has read in detail.

tatewise wrote: ↑

14 Dec 2022 17:56

In my proposed Wish List entry posted on Mon 12th Dec 2022 22:40 in viewtopic.php?f=43&t=21280&start=50#p131602 it caters for mixed plain and rich text working. The preference only really applies to creating new notes.
Existing plain or rich text notes open in the appropriate editor.
In both editors, there needs to be an option to change to the other mode, so a plain text note can become rich, and a rich text note can become plain. I think Helen's latest proposals overlook that requirement.

Please go back and reread https://fhug.org.uk/forum/posting.php?m ... 1#pr131808.

It caters for mixed plain and rich text working, opening a rich text note in plain editing mode, and the option to change to the other mode to handle a conversion.

davidf wrote: ↑

14 Dec 2022 18:06

Arguably the same key strokes could hand a "single instance" as well.

Agreed. There's be three ways of handling a single instance: the select-cut=paste route, the 'switch editing mode route' and the bulk conversion but with only a single item selected.

See updates in bold.

Any other user requirements that are missing? My aim is to get this onto the Wish List tomorrow.

ColeValleyGirl wrote: ↑

14 Dec 2022 17:16

• It should be possible to either:
  • mix plain and formatted text (both elements optional) within a Note, Autotext or other potentially formatted text field (as now) -- referred to here as 'Formatted Editing'
  • or, enforce plain text content within a Note etc. -- referred to here as 'Plain Editing'
• There should be no other functional differences between the two modes of working, including for example spell checking and the ability to create and use Autotext . (Catchall to ensure that the functionality available in the V7 editor is all still available in Plain Editing mode, without having to specify it all).
• Mouse and keyboard shortcuts for Paste Formatted text and Paste Unformatted text should be provided. Where formatted text is not allowed, the Paste Formatted text shortcuts will have the same result as the Paste Unformatted text shortcuts.
• User should be able to easily access either mode of working on demand (for accessibility reasons, this should include both mouse and keyboard shortcuts and preferably menu items or icons.)
• The mode of working should be obvious at all times that an editor is open.
• User should be able to switch from one mode of working to the other while an editor is open. If switching from Formatted Editing to Plain Editing, they should be warned this may result in content corruption (e.g. characters not being available in the default font) and asked to confirm they wish to proceed. Ctl+Z (Undo) should undo the conversion just as it undoes other operations.
• A facility should be available to remove formatting from one, many or all instances of formatted text, with a warning that this may result in content corruption (as above). The ability to undo bulk conversions via Ctl-Z/Undo would be nice to have.
• A simple method should be available to remove formatting from part of an instance of formatted text.
• User should be able to set a preference to enforce Plain Text editing (default: Off), which will determine which editing mode is operational by default.
• If Plain Text editing is set to On and Formatted Text is then opened in the default Plain Text mode, the user should be warned that the content will be converted with the usual content corruption risk. The user can elect to continue in Plain Editing mode or switch to Formatted Editing mode on this occasion.
• Opening plain text in Formatting Editing mode need not result in a warning, as it's a valid operation. As long as the preferred editing mode is easy to access (as the default mode), users who wish to enforce Plain Text are unlikely to do this. If they do, it will be obvious which editing mode they are in, and they can immediately switch to Plain text mode without the content being affected.

Helen,

This looks good to me.

Thanks,
Bill

ColeValleyGirl wrote: ↑

14 Dec 2022 19:48

• User should be able to set a preference to enforce Plain Text editing (default: Off), which will determine which editing mode is operational by default.
• If Plain Text editing is set to On and Formatted Text is then opened in the default Plain Text mode, the user should be warned that the content will be converted with the usual content corruption risk. The user can elect to continue in Plain Editing mode or switch to Formatted Editing mode on this occasion.
• Opening plain text in Formatting Editing mode need not result in a warning, as it's a valid operation. As long as the preferred editing mode is easy to access (as the default mode), users who wish to enforce Plain Text are unlikely to do this. If they do, it will be obvious which editing mode they are in, and they can immediately switch to Plain text mode without the content being affected.

Particularly in mixed mode, when there are many notes on both plain text and rich text, I'm not happy with some of that.
What is wrong with always opening existing plain text in the plain text editor and existing rich text in the rich text editor?
When opening rich text while plain text is the default, I would find it annoying to keep confirming that I want the rich text editor and running the risk that an inadvertent click on the wrong option removes the formatting.
There are ways of removing formatting in bulk, etc. So any remaining rich text is likely to need to stay as rich text.
Likewise, opening plain text while rich text is the default should open the plain text editor to avoid inadvertently adding formatting.

There is already the requirement that "User should be able to switch from one mode of working to the other while an editor is open." So that always allows the mode to be changed.

Looks good, Helen. It’s a clear and consistent description of requirements that covers all reasonable use scenarios. I’d support going with that exactly as drafted.