WYSYIWYG Editors, The Back Button and a Monkey
The back button has been a great challenge for a lot of modern web applications and WYSIWYG editors are certainly no exception. Way back before I can remember, someone had the fantastic idea of preserving content entered into text fields and restoring it if the user hit the back button to return to the page. Unfortunately, with the advent of WYSIWYG editors, this was generally lost because the browser reruns the JavaScript in the page again, providing no indication that the user was returning to the page. I could be wrong, and I'd love to hear of other examples, but I don't believe there is a WYSIWYG editors available today that preserves content when the user hits the back button. I find it somewhat interesting that despite the huge amount of user angst this causes1, there doesn't seem to be a lot of interest in solving the problem.
Similarly interesting is the Ephox engineering team's fascination with monkeys.
One night I must have been pondering this2 before falling asleep because in the middle of the night I awoke with a solution for this perplexing back button issue racing through my mind. An hour or so working on a proof of concept and it was clear that it really could work. Andy came along and worked out all the details3, refining the raw concepts in some pretty neat ways and generally weaving the code magic that he does and now EditLive! is the first4 WYSIWYG editor that works correctly with the back button5. You can check it on in the EditLive! 6.0 beta.
While track changes gets all the fanfare, this has to be my favorite feature that we've ever added to EditLive! I know longer live in fear of accidentally clicking a link or hitting backspace when the editor doesn't have focus6.
You may be wondering what this has to do with monkeys. It turns out that while I was explaining this great idea to Brett, I started by mentioning that I was dreaming. Brett didn't care about what the idea was, he just wanted to know if there was a monkey in the dream. Naturally I said there was and from then on the monkey got all the credit for coming up with the back button solution and any other great idea the engineering team has had. Stupid monkey…
In the end, I think what I really like about this feature is that users will never notice it – it will save them from experiencing major data loss countless times and they won't even know. It will just work the way they expect it to. Could there be a better user interface for a feature?
1 – not least of all to me considering how much time I spend using WYSIWYG editors in a browser↩
2 – the back button problem, not the fascination with monkeys↩
3 – like how to make it work in practice on 4 different OS's, and who knows how many browsers↩
4 – at least that we know of, let me know if you know of another one↩
5 – it also works with the forward button incidentally.↩
6 – who decided backspace should be a shortcut for back in browsers anyway??↩
October 25th, 2006 at 9:30 am
Hi! No I wasn’t wondering “why monkey”, I was wondering “how you’ve done it?”
If you think this appropriate and it’s not deeply connected with EditLive
internals (which I don’t know) a couple words outlining the main monkey idea would have been nice!
cheers
October 25th, 2006 at 10:47 am
It is fairly EditLive! specific, it’s also a pretty compelling advantage we currently have over our competitors. No doubt they’ll copy the technique but for now it’s probably wisest for me to keep quiet on how it works. If our solution for browser< ->applet communication is anything to go by, the competition should decompile our code and copy it in a year or two. Once that happens I’ll see if I can get approval to write about the technical details.
Also, just for the record, our blogging policy is pretty open, but it does suggest that you don’t give away information that would give our competitors a free ride. This seems like one of the few bits of information that is worth keeping to ourselves under that policy. Sorry. :)
October 25th, 2006 at 12:03 pm
Completely untested: couldn’t you simply persist the data (via ajax, or into a cookie, or something) onUnload ?
October 25th, 2006 at 12:26 pm
Dave,
Go and test it and you’ll find what the hard part is. :)
October 25th, 2006 at 12:38 pm
onBeforeUnload then (still untested). E.g. http://www.4guysfromrolla.com/demos/OnBeforeUnloadDemo3.htm
October 25th, 2006 at 12:41 pm
Colder…. :)
October 25th, 2006 at 8:28 pm
HTTP Put. Amaya. AOLPress. sigh. AJAX, an endless machine to reinvent the wheel.
October 25th, 2006 at 8:55 pm
karl,
What are you talking about? EditLive! is not AJAX and there are distinct benefits to having an in-browser editor instead of an external program such as when you happen to be editing content that’s stored in a CMS etc.
October 26th, 2006 at 12:06 am
What I mean is that… In-browser editors yes. It is the Web as it has been defined. The first browser WWW (re-baptized Nexus) was an editor and a browser. Every editing application should work in the Web (HTTP) metaphor.
What I find silly is people designing javascript toolbars inside browsers to enhance forms. When a Web page can be modified directly with an HTTP PUT and edited in place.
October 26th, 2006 at 6:49 am
There’s a major difference between using a user-agent to edit the page you’re currently viewing and uploading it wholesale with a HTTP PUT than using an in-browser editor to edit a snippet of HTML from anywhere and submitting it back to a database. Now I know that HTTP PUT could use a database storage but it is fundamentally flawed in terms of editing experience. It has to edit the entire page, not just the content that’s unique to the page and ignore any common navigation structure. It doesn’t have a locking mechanism, change control, meta data etc. It’s nice that the original web was planned to be editable, but it didn’t happen and since then better techniques and technologies have been developed to edit web content.
If you’ve worked with modern CMSs you’ll see that they provide far more than was ever envisioned in the original concept of the editable web.
October 27th, 2006 at 4:19 am
Adrian,
This is a very important feature which I totally agree will avoid numerous user problems with a WYSIWYG editor. This is one of the most obvious times when a user sends an angry email to support, because they’ve lost maybe half an hours work.
And its present in some of the more prominent web applications around, including the blogging platform, Typepad.
Nice work! ;)
Richard
November 16th, 2006 at 2:10 pm
[...] The best feature is content preservation. Apparently great minds really do think alike because AJ posted the same thing about three weeks ago. I found it funny that people in his comments tried to work out how we’ve done it, I wonder how many of those were actually developers on competing products. As much as I’d love to show off and point out the technical genius that was involved, we need to get paid somehow and this is a huge competitive advantage (even if it’s not a very marketable one) [...]
January 18th, 2007 at 5:54 am
EditLive! 6.0 – creating web content just got easier…
We are pleased to announce that EditLive! 6.0 is complete and can now be downloaded from our web site. This major release provides significant new upgrades: EditLive! Productivity Pack support Track Changes Thesaurus Equation Editor Content preservatio…