­­­

­­­­­­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:

unselected_text.png

The markup for this snippet looks like this:

example1.png

Now, imagine that a user selects the second occurrence of the word “this” in the sentence as follows:

selected_text.png

And this is where the trouble starts. Depending on how the browser has chosen to ha­ndle 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:

example2.png

Alternatively, the range could include the tag:

example3.png

(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,

example4.png

Safari, however, produces the following markup:

example5.png

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.

 

­

  1. 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.
  2. 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.
  3. 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.

­

Filed January 12th, 2009 under wysiwyg, ui, xinha

We’ve been using Xinha at TOPP for a while, and with two of us now core developers, I thought it would be worthwhile to try to hash out what we’re hoping to get out of our investment in Xinha.  Here, as a first step, is a discussion of Xinha-related goals and strategies that Doug, Nick B-­S, Sonali, Ian and I all agree on.

 

Goals

This section will address the goals which inform and are served by our commitment to Xinha.

1. Promote a document model of the web for easy human-readability, machine-readability and interoperability in a broader network of applications and services.

2. Build best-of-breed tools which can be repurposed for a variety­ of uses and in a variety of contexts, and which are good enough to attract business and financing on their own, whether as standalone products or as candidates for integration into other products.

3. Develop real communities of users and developers to collectively steer and own the software that we are involved with, with TOPP’s role in each limited to that of an initial catalyst if necessary, and to that of one equal user, producer and beneficiary among many.

4. Provide a solid base of tools to enable more and richer creation, editing and remixing of documents on the web to enable a more free and active exchange of communications, ideas and culture.

5. Help as many people as possible through our work, whether their rel­ationship to that work is casual or committed, technical or non-technical.

 

Strategies

This section will address the strategic directions we have set for our involvement with Xinha to further our broad goals.

1. An essential c­omponent of the strategy is developing and promoting useful and easy tools for web document creation and editing.­

  • To promote wide adoption, we must provide end-user value up front and allow our own value to naturally emerge from the user’s intentional actions.  To that end, our tools must push HTML and CSS down to the level of implementation details for the casual end user, and the casual user’s preferred actions should epiphenominally contribute to a document-driven web.
  • To promote deep adoption, we must instruct interested end users in the philosophy and practice of the document model.  To that end, our tools must provide tiered layers of value which simultaneously steer end users toward a deeper understanding of the underlying technologies and reward curious end users for their hard-won knowledge with increased functionality or flexibility — but without sacrificing the immediate value of a casual user’s interactions with the tools: upfront investment not required, and learning curves remaining smooth.

 

2. A WYSIWYG text editor is a very promising candidate to add to our portfolios of tools and expertise; it has broad applicability and appeal.  Because of the nature of a WYSIWYG editor, it is not likely to be a direct source of funding or work; rather, its value will mainly come from reusing it as a component of increasingly many projects.  Its presence in our portfolio increases the value of our portfolio as a whole.

  • To ensure reusability for a variety of uses, the software must provide flexible functionality and user interface.  To that end, the software should provide a sensible (and, ideally, requiring no deep technical knowledge) configuration layer, enable plugin development and skinning capabiities, and should provide tools to minimize the effort and overhead of reconfiguration.
  • To ensure reusability in a variety of contexts, the software must be easy to install, decoupled from any particular broader environment, and integratable into any number of broader environments.  To that end, the software must rely upon and promote general standards and best practices for intercommunication and integration of application components.
  • To build a best-of-breed WYSIWYG editor, the software must implement powerful functionality solidly and must present an extremely appealing interface to users.  To that end, we need to identify that functionality and interface by iterative use and user feedback.

 

3. Xinha has a history of community activity and has a commitment to real collective code ownership; it is rightly billed as “the community-built open source online HTML editor.”

  • To ensure that Xinha remains owned by its community and not by TOPP or any other organization, we must be careful not to put anything into the core repository which narrowly serves TOPP’s needs or does not have the support of the community.
  • To encourage an active and dedicated community to steer the project, we should pursue initiatives to increase Xinha’s visibility and to build interest and enthusiasm, and we should be prepared to offer any necessary organizational resources toward infrastructure for an open source community.

 

5. In addition to building a great WYSIWYG editor, we should actively share the domain-specific knowledge we gain in the process of building it.

Filed October 11th, 2008 under xinha

I spent most of my second week doing some Xinha UI work with Doug. Our broad directive was to improve the Xinha user experience, so we started by talking with Sonali and Bryan about known interface bugs and quirks, and got a good idea of where some of the major usability shortcomings are. My general thoughts on WYSIWYG editors for HTML-based content are that they’re almost always mediocre and are hard to do well as full-fledged desktop applications, and are even tougher to do well as web-based apps. To date, I’ve never seen any browser-based WYSIWYG editor that didn’t require me to either fight its idiosyncricities or delve into the source to get it to do exactly what I wanted it to. Xinha has come a long way, but there’s definitely still a lot of work to be done.

We decided to start by concentrating on Xinha’s popup dialogs, which are used in plugins all over the place, e.g., for adding a link or inserting an image. Since many people find popups annoying, not to mention the fact that they interfere with people’s popup-blockers, we decided to look into converting the existing popups into lightboxes. Not wanting to reinvent the wheel, we looked at several different options for lightbox libraries. I hadn’t realized just how many lightbox libraries have (no pun intended) popped up over the past year or two. Unfortunately, many of them have significant downsides: some aren’t released under free licenses, and more than a few appear to no longer be under active development. We ultimately opted to give nyroModal a shot, since it has had more than one release, uses JQuery, is relatively full-featured, and is released under an MIT license.

Not long after we started using nyroModal, however, we came across a branch of Xinha called new-dialogs that was started a few months ago by one of the core Xinha developers. As its name suggests, the branch is a major update to Xinha’s dialog system and has had a significant amount of work put into it. Details of its development can be found in the change history for ticket #1176. In short, it does almost exactly what we were hoping to do, and overall, does it quite well.

Interestingly, new-dialogs does not use any of the aforementioned libraries for its lightboxes. Instead, it includes its own lightbox code written from scratch. Its dialogs are resizable, draggable, and even dockable, though I’m not sure how necessary (or even desirable) the first two are for a modal system.

Much of what’s left to do with new-dialogs is to transition all of the plugins that use the old popup dialogs over to the new system. Doug and I have started working on this process by updating the UnFormat plugin.  Doug has since done the BackgroundImage plugin and I’ve done the Abbreviation and FindReplace plugins. There are still quite a few plugins to go, but once the rest are updated there shouldn’t be much holding us back from making the jump to a popup-free Xinha.

Filed June 30th, 2008 under ui, xinha