TinyMCE

Current status

As of August 12, 2010, a basic plugin using the TinyMCE rich edit control is available in 0.9.x and 1.0.x development branches. It sorta works, but isn't yet suitable for general usage.

This has been brought up to date and patched up from the earlier versions Evan experimented with; there are very slight changes to core to add a few event hooks which the plugin uses to format input and to take over some bits on-screen.

IE has not been tested with the current code, but it's known to work on current betas of Firefox and Chrome. :D

What's it for?

Why do we need a wysiwyg rich text editor for our microblogging? Isn't simple text enough?

The most important thing we need isn't actually the eye candy like bold/italics or image embedding, but making hidden behavior visible. Today, parsing and validation of @-replies, #-tags, !-groups, and URL links is all done after you, the user have submitted the notice to the system for publishing.

Made a mistake? Too late! You can delete the message and send another, but it's already gone out to your friends and the general public, been reposted to other services, and notifications emailed to possibly hundreds of recipients.

Using a rich editor will allow us to do the parsing while you type, so all your links and tags and mentions are already known and clear before you hit "send".

Screenshots

The basic input looks fairly standard; a couple formatting controls are thrown in, and URLs can be linked both automatically and explicitly:

We also detect when you've added an attachment, and stick an image placeholder into the notice. See how the text area has increased in size automatically to make room for the added content!

You can move and resize the placeholder in the usual way you'd expect; cut-n-paste and click-and-drag. Resize handles appear when the image is selected. (This magic is all provided by TinyMCE already! You can also add a remote image reference which will actually display inline during editing, though that might not still be allowed at the end.)

When you send your message, the actual image will be inserted in place of the placeholder (scaled down to fit if necessary):

Issues

These need to get migrated into the issue tracker and linked.

•   Currently, there's no handling for #hashes, @mentions, or !groups. That's kind of a problem!
  • This is absolutely required before pushing things to the wild; at least linking on submit and preferably linking during typing.
    • I'd go so far as to say that magic linking that happens *after* submission would be really bad here. Link it live for best user experience!
  • Typeahead suggestions would be very useful, including disambig of conflicting names.
•  Auto URL linking behavior doesn't quite match internal behavior
•   Attachment behavior doesn't match what we do from the plaintext edit
  • Should we do a similar image attachment for things that were typed? Or should we do the inline display in a different way?
•   Untested with direct messages; should apply the same for both.
•   Currently we've got bad handling of paragraphs; single-para messages should perhaps be reduced? Or we should fix our output so we're not trying to shove paras into a wrapping para
•  We should perhaps be stricter, and clearer, about what HTML is supported
  • there's a pretty wide net cast on the htmlawed validation on input...
  • ...but we only enable a few things in the toolbar.
•  Live character counter doesn't always match what we get on submission
  • I think whitespace is the main difference, and this could also vary between browsers.
•   Cropping of long messages is not handled well.
  • The cropping is kinda funky to begin with, and should probably be handled better (and more generally; similar concerns apply to OStatus foreign site input, where we do explicit ellipsis generation which is pretty nasty.)

UX

•   Initializing the editor is relatively slow, and currently happens on every page view. Eww!
  • If we delayed editor setup until you focus into the textarea, it might be a little nicer.
    • The initialization could also be partly hidden by animating the textarea bumping into a larger size, or something.
    • This might be good in combination with a redesign of the input form; if the actual controls fold out only when you use them, we can also provide more space to type, and take up more on-screen space for things like the positional controls.
    • That would also let us delay location lookup until it's needed.
•   Link and image dialogs don't fit with the rest of the site style
  • The skin/theme can be customized to match better...
•   The attachment workflow doesn't let you preview the actual image's size or contents (since it's not uploaded yet while we're editing)
  • A mini-dialog that uploads first, then attaches, might be a more natural look.
    • Consider needs to garbage-collect files that are uploaded, then not used.
•   The image-edit button also lets you insert a new image with an explicit URL reference. This dialog sucks, is confusing in that it semi-duplicates the attach button, and doesn't give a chance to upload.
  • A 'browse' button next to the URL input can be added and hooked, but I'd prefer to replace the whole dialog as it's kinda nasty.
•   Fullscreen mode from the editor kinda sucks. Possibly drop it, especially if we're already going for a bigger thing.
•   If you manually type something like 'slashdot.org' into the linking dialog, you end up with a relative link.
  • Particularly annoying since typing 'slashdot.org' in body text DOES work, and even auto-links as you type.
  • Need to tweak it so it takes them as HTTP hosts rather than relative pathnames
•   No clear way to clean up text if it's formatted weirdly when you paste it in.