MediaWiki Developer Meet-Up 2009/Notes/WYSIWYG
< MediaWiki Developer Meet-Up 2009 | Notes(Redirected from Project:Developer meet-up 2009/Notes/WYSIWYG)Jump to navigation Jump to search
Wikia's Rich Text Editor
- Work on Wikia's rich text editor began more than a year ago using Socialtext's open source "Wikiwyg" as a starting point.
- Wikia's plug in includes a reverse parser plus work on the parser, linker, and other parts. It is used with FCKeditor but could also be used with other editors such as TinyMCE.
- It is currently in use on 100s of wikis and will be rolled out to all Wikia's sites in the near future.
- Templates are shown as placeholders so it is not full WYSIWYG. When clicking on a template placeholder, you see a preview of the template and have the option of editing the templates parameters. Reference tags and signatures are also shown as placeholders.
- One aim was to stick to normally-used wiki layouts and not to encourage crazy formatting of colored text in random locations.
- Users can easily switch between rich text and wikitext (source) format whilst editing. HTML comments are not currently supported. Rich text mode can be switched off on a per-page basis using a magic word.
- Planning to gather more data on when and why people switch to wikitext source view.
- TinyMCE is not as maintained as FCK. FCK is large in filesize but can be compressed.
- WYWIWYM (what you see is what you mean) has a regex mini-parser with some common functions such as bold, italic, headers, links only.
- WMU are more likely to use fold-away templates and help improvements rather than using a WYWIWYG editor or anything that causes a major change to the current editing method. One reason is that people need to learn the wikitext features to become power editors.
- However, they may find those through templates without needing everyone to see the wikitext in throughout article.
- More work is needed on visual editing tools. For example, displaying museum articles on a map so you can easily see which museum is missing an article. One example of this sort of tool is the Wikimedia Atlas.
- Another visual tool idea is to show the sections of an article so people better understand how to add a section rather than adding a whole new page. Semantic MediaWiki forms might help with this as a form can be used to create an article. One potential disadvantage would be people viewing form-filling as boring or work-like.
- Visual tools could also be used to add co-ordinates to articles.
- Michael Dale is working on uploads, primarily video.
- A new grant-supported project will also work on this, both on the upload process and the licensing choice process.
- An upload wizard may be developed. Currently on commons there is a form of wizard but the interface changes to toolserver in some parts of the process.
- The form needs to be less restrictive. For example, 'source' does not always make sense if uploading a photo of an engraving of a painting whereas that could be explained more easily in a text field.
- The process needs to be streamlined.
- The result needs to be more what the user is expecting.
- The result needs to be editable afterwards. Currently, you can edit it, but only as plain text - you can't get back to the wizard after uploading.
- The current interface may be too focused on self-taken photos and not on other forms of upload. Multiple uploads are unnecessarily difficult.
- If you click 'help' when uploading on commons, you are presented with a 47-section article!
- Wikia has experimented with 'edit tips' which show the most commonly used wiki syntax in the sidebar whilst editing. People need short help at the right time, not a 400-page book!
- WMU found that people get lost in help and rarely find what they need.
- References are hard to add and are used differently by different people.
- Exercises were developed for the Wikipedia Academy in Sweden and translations are available on Meta. The exercises used by the WMU studies will be available in future on the usability wiki.