When an author changes the appearance of a page, those changes should be represented in the underlying structure of the page. This post looks at what the interface should be.
With a WYSIWYG interface, there has to be an area that appears as it will when published, which means to change bits within it, you need one or more toolbars. This is an exploration of what those toolbars should do.
You could argue that the author doesn’t need to know anything about block or inline elements, they should simply apply a heading (block) or bold (inline). I would agree, but these elements behave quite differently when published, so on balance, I would rather make that explicit in the interface, and mark the behaviour as different.
The default installations of the editors don’t tend to separate block and inline elements, this is a screen shot from X-Standard lite:
The issues I’ve seen with this are that there is a gap between what the user thinks will happen, and what does. I’d like separate mechanisms for applying block and inline elements, and buttons for elements that require a more wizard like approach (e.g. tables and images).
Essentially, when applying a block element (heading, paragraph etc.) it shouldn’t matter whether some text is selected or not, the change would apply to the block element around the cursor.
There are quite a few block elements (headings etc.), so a drop-down widget seems like a good choice:
That drop-down would default to paragraph, and include:
- Main heading
- Quote (block)
There are several other block elements that are not in that list because people are either used to them being separate (lists, horizontal rule) or because they require more information (tables). These need their own buttons:
Applying inline elements generally requires the user to select a certain amount of text and then select a button which then wraps the text in the appropriate tag (see below). Some editors allow the user to switch-on bold (for example), write, and then switch it off, and carry on writing. ‘m in two minds about that, it means that buttons to not act consistently, but it is a learned behaviour from other editors. So long as it replicates other editors and doesn’t disrupt the markup, it should be ok.
There are a few others that you could include:
ins, or others from the allowed HTML list, but these are the ones I’ve found are most commonly used.
The exceptions are images, links and acronyms; which require more information, however they are still inline items, and follow the same type of rules.
That leaves a useful set of elements to work with, and a means of applying style variations:
(NB: This example was created with TinyMCE, which is missing
acronym and doesn’t necessarily produce the correct markup for each item.)
Interface variations for elements
There are certain behaviours that you would want an editor to show that vary by the element being used.
Paragraphs, line breaks and spaces
By default, an editor should make a new paragraph when the user presses return. A line break can be added with shift-return. This applies to headings as well, so that upon return a new paragraph is added below with focus. If the cursor is not at the end of the element, it would split the current element into two.
An editor should not insert non-breaking spaces (
) if the user presses space more than once, it should ignore the attempt.
Blockquote & Quote
One of the primary interface problems with blockquotes is that they are often referred to as indentation – a very clear problem when trying to get non-technical people to use them correctly! Blockquotes are also tricky because it allows other block elements within it, usually paragraphs. I would suggest that:
- Blockquote must be referred to as “quote”, “block quote” or similar, not indent.
- When a paragraph is made into a blockquote, there is automatically a paragraph inside and below the blockquote, with the focus remaining in the blockquote. This would enable the user to add paragraphs or other elements within the quote and press down to leave the quote.
- There must be a mechanism to add the
citeattribute (a URL). This could be:
- a ‘properties’ command (button or context menu).
- A wizard approach where a box pops-up with URL and text fields.
- Something is added to the interface that the user can select, for example:
The quote (
q) element is an inline version, so cannot contain block elements but should allow the addition of the cite URL.
There are two primary behaviours needed for lists:
- Pressing tab within a list creates a correctly nested list.
- When the cursor is within the last item and it is blank, pressing return will remove the item and start a paragraph below the list.
Very few editors do nested lists properly, to many times they will incorrectly do this:
<ul> <li>Item one</li> <ul> <li>sub-item one</li> </ul> </ul>
However, a nested list should be within a list item.
Links, acronyms & images
Images will be covered in greater detail later, but all these elements require more information than simply applying a style. An image requires an image location and alternative text, links require a URL, an acronym should have a title. Selecting the button should open up a dialogue to take the appropriate information.
A context menu (often right-click in windows, or control-click in OSX) can be a very useful short-cut to changing the selected item. These menus should be dynamic (i.e. change depending on the context), and given browser controls I am surprised that editors don’t usually provide a button for this type of function, as right-clicking can be over-ridden by the browser.
In the same way that the style drop-downs should be dynamic, the context menu would provide access to the additional attributes of the element in question, but only those defined in the allowed HTML.
A context menu would be a useful addition that allows quick access to attributes of each element, as well as the usual cut and paste.
How the editors do
Previously I have been through each editor at this stage, however, it’s a slow process trying the different configurations for each. Instead, I’m going to leave that to the end, and instead build up a check list of all the points covered in each of these WYSIWYG posts. Then I can test each editor from start to finish, not only establishing the best and worst points of each, but finding the best configurations for each.
Coming soon, how editors should let you add alternative text to images and manage images.
11 contributions to “WYSIWYG editors spec – adding structural code”
Just in case you are worried nobody reads these, I’ve been following them with a lot of interest. A well written and nicely thought out analysis of the problems and solutions of authoring HTML.
(Btw, how about applying the input font styling to this textbox as well?)
Thanks Ben, good to know! I was hoping people might post any critisisms or ommisions that I could work back into them, but I guess no news is good news in this case.
The interesting ones for me will be keyboard (and screen reader) accessibility, and applying custom style templates (columns etc.), which I’ve got some ideas for that I haven’t seen implmented anywhere yet.
Oh, and you are right about the comments, I haven’t really changed them from the default install, they are next on the list of things to change. (I’ve also found the ‘subscribe to comments’ pluggin that Bruce Lawson uses, which I like.)
XStandard Pro gives you freedom to customise that menu via the styles.xml file. It supports grouped items, but not nested groups in my experience. That aside it provides good scope to present a list of elements in a way that suits you and your users.
Hi Dan, you can make that customisation in Xstandard lite as well.
I’m only testing the free version to start with, at the end I’ll try the full one to.
It is a weak-to-moderate usability issue if they aren’t separated, but I’ll try customising each as best I can (within what the documentation specifies).
I’ve also been following this series with interest. I think a big problem with WYSIWYG editors is the separation of control from within the text. To me, actioning meaning/styling through buttons seems fairly impractical for AT users. It would probably entails jumping back and forth from buttons to textarea.
I can see that a screen reader user’s preference may be for meaning/styling to be applied while typing. Hence, you are left with some form of markup – HTML, Textile, Markdown, etc.
This is why I like live previews. The preview doesn’t really get in the way for screen reader users. As and when AT can pick up on DOM updates, they may provide a useful read-through preview, but you can do that in part by reading through the text in the textarea.
Dotjay said: “actioning meaning/styling through buttons seems fairly impractical for AT users.”
It is to an extent, it is something we’ve been through. If you think about the other applications people regularly use (e.g. word/textpad), it isn’t a new problem, just a different context.
There are three real solutions in a WYSIWYG context, two of which I consider better than any of the wiki or textile interfaces:
1. Using access keys or tabindex to make going from the text to the controls easier (not ideal, but a legitimate use of access keys).
2. Using a pop-up window of the controls, so it’s easy to alt-tab between the content and the controls.
3. Using a context menu (like right-click in word).
These are not mutually exclusive options either, you can use any or all and include user preferences as well.
I’ll cover this more in the keyboard accessibility post coming up later.
AlastairC: “I’ll cover this more in the keyboard accessibility post coming up later.”
Cool, thanks Alastair.
The TAB and SHIFT+TAB should be used for moving focus to other controls on the form. In XStandard, sublists are created via context menu.
To bring up a context menu in XStandard for OS X, it’s CONTROL+mouse click or CONTROL+SPACE.
Alastair, I never figured out why some editors give the author the option to create a paragraph from a menu. The paragraph is the default construct in WYSIWYG editors which is created by pressing ENTER.
Also, editors should be able to hide the ability to create high level headers like h1 because these are created by the page template. For example, in XStandard, most developers remove h1 from styles.xml and label h2 as Heading and h3 as Sub-heading.
That’s the heading behaviour described above, I guess that also having the option in the drop-down allows the user to turn a heading into a paragraph (for example).
With regards to heading 1s, totally agreed, you’ll see that in the image example above, and in the later article on preventing problems.
By form controls I mean the contols on the Web page not in the editor. The editor itself is a form control.
Say you have a Web page with a textfield, WYSIWYG editor and a submit button. An author using a keyboard, will navigate into the textarea using the TAB key. Then they will use the TAB key to navigate into the WYSIWYG editor. Then they should be able to use the TAB key to navigate to the submit button. But if the WYSIWYG editor is using the TAB key for creating sublists or internal navigation, then the user will not be able to get to the submit button or another form control.
Some editors use the TAB key for internal navigation such as moving from cell to cell in a table. I’ve some cases where an author tabs into the editor and the focus is first set to the toolbar. So the author has to tab through all the buttons before they get into the content area.
The TAB key should only be used to move between form controls.
IE has the best support for keyboard navigation. Mozilla is currently developing a specification for supporting keyboard navigation for plug-ins. This API will then be adopted by Safari and Opera.
Comments are closed.