Inspired by Doug, and the fact that I’ve promised myself that I’d blog more this year, here’s my much-delayed return to blogging.
I’ve been thinking a lot about the importance of consistency and predictability in terms of software usability, specifically with respect to Xinha. Web-based WYSIWYG editors face particularly tough challenges when it comes to consistency, since they must deal with a slew of cross-browser (and cross-browser version) incompatibilities, quirks, bugs, or whatever else you what to call all of the little and not-so-little issues that arise when trying to write modern web applications.
If cross-browser inconsistencies are bad, intra-browser inconsistencies — that is, user-facing inconsistent behavior in the same version of the same browser — are really bad. To make things concrete, here’s an example of what I’m talking about: bolding text. This is an exceedingly basic task that any rich text editor is going to need to be able to handle. Yet as far as I know there is not yet a single online WYSIWYG editor that handles bolding both consistently and properly.1
This issue stems from the fact that visual text selections do not have a one-to-one mapping to ranges in the DOM. For example, consider the following text as rendered in a browser:
The markup for this snippet looks like this:
Now, imagine that a user selects the second occurrence of the word “this” in the sentence as follows:
And this is where the trouble starts. Depending on how the browser has chosen to handle selections, this selection could actually correspond to either of two different ranges in the DOM. The core question is whether or not the selection includes the opening STRONG tag. If it does include the tag, the selection looks like this:
Alternatively, the range could include the tag:
(If the selection extended to the end of the sentence, the situation would be even worse, since the range could include or not include the closing tag. In this case the visible selection could map to up to four distinct ranges.)
Now, for many cases minor discrepancies like these do not matter. However, there are several where these differences greatly affect how the application actually works.
For instance, if the user proceeds to type a word to replace the selection, the outcome will be different depending on the boundaries of the range.2 For example, in Xinha, TinyMCE, and Google Docs under Firefox 3 and IE 7, the behavior is “correct” in that it does what I think most users would expect: The resulting word is still bold. That is, if the user types “THIS” the resulting markup is,
Safari, however, produces the following markup:
Another place where this issue crops up is cursor placement. Continuing with our example above, if a user puts the cursor at the beginning of the bolds section (i.e., just before the first bolded letter), the expected behavior is to not bold whatever the user types next. If on the other hand he places the cursor after the final bolded letter, the expected behavior is that the text typed at that point is bolded. Unfortunately, the behavior is inconsistent and sometimes unexpected. For example, Firefox shows consistent behavior, however, it is anything but obvious to novice users or those unfamiliar with HTML markup. Firefox determines whether the cursor is inside or outside of the tag depending on how the cursor got there. Approach an opening tag from the left (e.g., by using the arrow keys), and it will be outside of the tag; approach the opening tag from the right, and the cursor will be inside the tag. This means it’s possible to press the left arrow key and then the right arrow key and end up in the same visible location but in a different point in the DOM.3
The issue here is that in order to know what will happen when you start typing, you have to know something about the past — you have to know how the cursor got to be where it currently is. There is no way to know whether your text will be bold simply by looking at the current state of the editor.
None of these issues are deal-breakers; there are ways around all of them, and users tend to discover such workarounds over time. My concern is that the cumulative effect of all of these little annoyances is significant: It puts an undue burden on the user (to remember if/when the editing behavior differs from the rest of her computing experience, and to know how it differs between browsers if she switches or uses a friend’s computer), and it subtly teaches people to distrust the software. As I’m primarily interested in writing software that people will love — and I would argue that it’s nearly impossible to love a program you can’t trust — I think these “minor” issues are actually real barriers. As such, I’m hoping that after getting the upcoming release of Xinha out the door, I will be able to spend a real amount of time ironing out these inconsistencies. The result will I hope not just better software, but more enjoyable software.
- Note that by “properly” I mean “how the vast majority of users expect things to work.” Realistically, this means — for better or worse — working the way that Microsoft Word works and most other word processors work.
- Unless, of course, the editor’s developers have made a special effort to take these distinct cases into account and alter the browser’s default behavior if it differs from what they want it to be.
- Note that this behavior is not a “bug” in Firefox, since it is sometimes helpful to be able get in/out of a tag. However, that does not mean that this isn’t very confusing to users, and inconsistent with most of their experience using other types of rich-text editors.