Deployment of Babaco Enhancements
The Usability Team is preparing a supplemental release which will bring more stability and functionality to the features of their Babaco release, which has been available to logged in users of Wikimedia sites since October 2009. Among the changes which have been made are many improvements in interactivity and aesthetics, but the most critical change is using an HTML iframe element together with a special design mode that modern browsers support, in favor of the previous HTML textarea. This paves the way for developing a rich editing experience with collapsible templates and syntax highlighting, as well as provides a foundation on which a WYSIWYG editor may eventually be built upon.
The table of contents, which now features controls for expanding, collapsing and resizing, is also much more accurate than before. The link dialog which once had a tabbed interface for making internal or external links now intelligently detects the type of link you are making, an improvement we designed and prototyped while literally watching users struggle with the software during usability testing. Finally, there is now support for language specific icons in the toolbar, with a several languages ready to go such as German, French, Spanish, Dutch, Portuguese, and Polish. This feature allows us to provide a more native experience by using language specific mnemonics. So far we’ve applied this feature to the bold and italic buttons, which are now B and I for English, F and K for German and G and C for Spanish. Languages without customized icons will continue using A and A.
The team will be deploying these upgrades in the coming days. To learn more about the Wikipedia Usability Initiative, check out their website at http://usability.wikimedia.org.
Woo! I love it when you guys announce stuff. Most announcements in the wiki-verse mean things get bigger/better but also more complicated/difficult. Your announcements mean things are getting bigger/better but also *simpler/eaiser*!
“[…] using an HTML iframe element together with a special design mode that modern browsers support […]”
Just a reminder, but could you please make sure that this fails semi-gracefully on platforms that don’t support it? In particular, I sometimes edit on my iPod touch. Babaco has worked excellently so far on it, and I’d be disappointed if that was suddenly broken.
I particularly love the search/replace feature, which makes edits like this one possible: http://en.wikipedia.org/w/index.php?title=Caesium&diff=340539935&oldid=340489681 . A minor edit, but otherwise extremely tedious on an iPod.
I’m looking forward to hearing more updates from the Usability team! In particular, I’m looking forward to getting to define template forms: http://usability.wikimedia.org/wiki/Template_forms . I get the impression that this will be a feature in the Citron release?
The rich text thing has screwed up editing on wikipedia. Read http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Edit_box_.26_monospace_style_changes .
Please revert changes ASAP! Or make an option to disable RichText box. And next time – test on test wiki :-/.
I agree, the rich text is highly annoying and troublesome, especially due to hidden characters that screw up spacing. Anyway, the feature can ultimately be a good thing, but at the very least, PLEASE offer an easy-to-use “Paste Special” option where we can drop text in without all the formatting.
I’ve been happily using Beta on Chrome. Except for editing: where the Edit Summary didn’t render right, leading to an aborted edit and crash. I’ve noticed this has been fixed in the past few days, so thank you.
I fully agree to Nux. When the project with the goal to improve usability releases a beta, which is prominently advertised on virtually every page in the wikiverse but that actually worsens the usability (RichText Editor without any functionality but annoying formattings on insert, side effects on other skins etc.) you are loosing reputation and beta testers. The user ‘out there’ is testing Beta, sees those annoying things and will probably never ever re-use the Beta again.
So the Rich Text Editor is a “…foundation on which a WYSIWYG editor may eventually be built upon..”. I appreciate your effort in that Editor, but could you not simply keep it in your revision control system until there is really a use case for that feature? That way your work won’t get lost and neither the reputation.
How do I disable the Rich Text Editor and all of its associated problems? Or do I need to leave the Beta to disable it?
We did test it, we just didn’t happen to try the use cases that triggered the bugs.
We’re working on fixing these pasting bugs.
There’s features in the current release that already benefit from the rich text editor (the accuracy of the navigable TOC has been improved by a lot), and we’re planning to deploy another feature built on this editor (template collapsing) in a few weeks. If we had held off on deploying this editor before all those features built on it were ready. we’d be deploying like 6 months of code at once and that’s kinda scary.
Yes, you have to leave beta to disable it. We’re fixing the bugs full-time though: some fixes have already gone out and there’s more in the pipeline.