Author mode: content completion menu

[ra0543]

Would it be possible to change the order of the options that appear in the content completion context menu invoked in Author mode when the [enter] key is pressed?

At present the top two entries are:

ENTER
Split xx

and only then do the available elements appear. [I know that the ENTER only appears in certain CSS-determined contexts.]

I wonder whether both of these could be put at the bottom of the menu list that is invoked rather than at the top. They would of course still be easy to access, since using the cursor up from the top of the list cycles the focused option down to the very bottom of the list, but at present it is frustrating always to have to use the cursor down twice to go down to the elements past these two options that we have no use for.

My suggestion would not make things significantly more difficult for those who do use those options regularly while clearing them out of the way for those who don't.

Alternatively, if that's a step too far, perhaps this could be controlled by an option setting?

[adrian]

Hello,

ENTER appears only for elements that have their text preserved.

Unfortunately we cannot put these two items at the bottom of the list by default. Most of our users actually want to either split or input an ENTER with a single keystroke(right now they need at least two, first to show the menu, second to perform the action).

The content completion menu has key search, if you type one or more characters it will apply a filter and only show the elements that start with those characters. This will always be the faster way of choosing an item from a large list instead of navigating it with the arrow keys.

We will investigate the usability of the content completion list and if we find it appropriate we will change the default behaviour or add an option.

We also plan to make the content completion list customizable through our API.

Regards,
Adrian

[ra0543]

OK - I see the point. In that case having an option would be better (for those of us who don't want to have to do any complicated customisation!).

Personally I'd rather in that case there was the option to remove both from the content completion menu altogether:

• The 'Split' option is already easily accessible via the right-click context menu (which can also be activated by keyboard shortcuts etc.), so that wouldn't be a problem.

• In principle it would be better for this content completion menu to offer only the same kind of thing, i.e. elements; ENTER here is a character. Since the menu is itself accessed by pressing [ENTER] obviously there is a potential problem, but I would suggest simply offering a different shortcut for entering an actual ENTER, such as [SHIFT]+[ENTER] or [CTRL]+[ENTER].

The content completion menu has key search, if you type one or more characters it will apply a filter and only show the elements that start with those characters. This will always be the faster way of choosing an item from a large list instead of navigating it with the arrow keys.

True. One unfortunate consequence of the way this is set up, though, is that ENTER is still accessible to that filter, and so if you enter E ENTER is picked out by the filter as if it were an element, even though it isn't. And similarly if you use the cursor down key, it fills in ENTER as five separate letters (that you can delete separately, even though they are not meaningful separately but represent a single character unit).

Anyway, thanks for offering to look at it. There are a few other possible usability improvements for these menus, including presenting the possible elements in any sequence defined in the document schema, and where appropriate determining context on the basis not just of what precedes but also what follows, so as not to offer a new <b> between then end of an <a> and the start of an existing <b> if the schema does not allow it.

[adrian]

I've added your comments to our issue tracking tool and they will be considered when the decision is made.

One unfortunate consequence of the way this is set up, though, is that ENTER is still accessible to that filter, and so if you enter E ENTER is picked out by the filter as if it were an element, even though it isn't. And similarly if you use the cursor down key, it fills in ENTER as five separate letters (that you can delete separately, even though they are not meaningful separately but represent a single character unit).

ENTER and Split shouldn't be picked up by the key search. That's a bug and we will certainly fix it.

There are a few other possible usability improvements for these menus, including presenting the possible elements in any sequence defined in the document schema, and where appropriate determining context on the basis not just of what precedes but also what follows, so as not to offer a new <b> between then end of an <a> and the start of an existing <b> if the schema does not allow it.

We already have these feature requests on our issue tracking tool. I'm adding your vote for them.

Regards,
Adrian

[Radu]

Hi,

Oxygen 12.1 which will be released in a couple of weeks will have support for adding your own custom Author actions to the Content Completion window, Elements view and Contextual Insert (Outline/Breadcrumb) menus.
You will also be able to remove specified elements from appearing in the places specified above.
This control will be able in the Oxygen Preferences->Document Type Association page when editing a document type:
In the Author tab there is a new Content Completion tab which controls the features mentioned above.

Regards,
Radu