Hey everyone,
Last week I've done some usability testing with my InlineEditor extension, to see whether or not it's a good idea at all. I've still got to do formal analysis, but that'll take a while, so for now I'll only share with you the most important things I noticed while doing the tests.
First, a few remarks. The test group was heavily biased towards students of Information Sciences, so towards above average intelligence and familiarity with codes and programming. There were 3 test groups, testing both versions of the editor (one where you can select an edit mode like "Sentences", "References", "Media", etc., and one where you can select "Sentences", "Paragraphs", "Sections") and a control group.
1. The editing of sentences was great the new way. Users were much more comfortable seeing the article and being able to directly manipulate it. 2. Users did not really notice the other editing options. This is a huge problem, as the whole idea of this editor is to show the user an increasing amount of wikitext complexity. When users did notice it...: a. In the case of the functional edit options ("References", "Media", etc.), users used this more as a help center and then proceeded to the full (original) editor. b. In the case of the block edit options ("Paragraphs", "Sections"), users used it correctly and found it helpful. This might indicate that this is the right way to go (which was my hypothesis), but it still has to be approached differently. 3. Users did actually like the idea of the interface, whether or not they could accomplish their tasks. Users noticed the edit summary field earlier and used it more often (although the test groups were too small to draw a formal conclusion from this).
In conclusion: users really liked the direct manipulation, but did not get the different edit modes. So, back to the drawing board! ;)
Full interview videos will be available on Wikimedia Commons somewhere next month. They are in Dutch, though.
You can try the editor with block edit options at http://janpaulposma.nl/sle/wiki. It's still work in progress: do expect to run into bugs that I did not find worthy to fix yet. :)
Best regards, Jan Paul Posma
2010/11/29 Jan Paul Posma jp.posma@gmail.com:
Full interview videos will be available on Wikimedia Commons somewhere next month. They are in Dutch, though.
Michael, can we subtitle those with mwEmbed magic?
Roan Kattouw (Catrope)
On 11/29/2010 07:56 AM, Roan Kattouw wrote:
2010/11/29 Jan Paul Posma jp.posma@gmail.com:
Full interview videos will be available on Wikimedia Commons somewhere next month. They are in Dutch, though.
Michael, can we subtitle those with mwEmbed magic?
Roan Kattouw (Catrope)
We can. We can even subtitle them with the slick universal subtitles interface ;) http://techblog.wikimedia.org/2010/10/video-labs-universal-subtitles-on-comm...
Hopefully by then I will have time to add a little language selection dialog at start-up, for now you would have to move the "English" subtitle into the do "Dutch" subtitle name after you complete your transcription.
--michael
Op 29 nov 2010, om 13:11 heeft Jan Paul Posma het volgende geschreven:
You can try the editor with block edit options at http://janpaulposma.nl/sle/wiki . It's still work in progress: do expect to run into bugs that I did not find worthy to fix yet. :)
Best regards, Jan Paul Posma
Looks nice.
A few points which may or may not have been raised before: * I think editing inline like this eliminates or lessens the need for a WYSIWYG editor because it already is very direct. * Serverside parsing with AJAX, good choise. No half-parser serverside, this way advanced users are ensured they can use all the syntax they know which would work in the full editor. * Currently the editmodes are indicated like tabs, which wrap around an instructional paragraph. I would recommand making the tabs indicate/wrap around the entire article below (just like Page, Discussion, View, Edit are tabs for the entire page, "Sentences, "Paragraphs" etc. would be tabs for the article part (Ie. full width, and perhaps a suddle border connecting the tabs with the article) * List items could be / expected to be editable sentences * Feature suggestions: An [edit] link at each section in sentences and paragraphs edit mode which, when clicked, switches to Section edit mode + edits that section * Bug: When adding (wether or not by accident) an interwiki link or category link inside a sentence and the sentence didn't contain anything else, it dissapears. Some kind of padded border box should atleast be left behind in order to edit it again * Bug: When adding ..... inside a sentence, clicking preview results in the sentence being split into two seperate sentences at the point where the category link was insterted. At this point neither editable sentence contains the category link. I would expect the categorylink to be, albeit invisible, not a sentence-breakpoint, just an invisible thing as part of the sentence.
Errors: Pressing enter in the edit summary input field caused a fatal error (verified several times): ( ! ) Fatal error: Call to undefined method stdClass::getWikiOriginal() in /home/janpaul/domains/janpaulposma.nl/ public_html/sle/wiki/extensions/InlineEditor/InlineEditor.class.php on line 208 Call Stack # Time Memory Function Location 1 0.0005 131192 {main}( ) ../index.php:0 2 0.0686 10124312 MediaWiki->performRequestForTitle( ) ../index.php:115 3 0.0786 12044680 MediaWiki->performAction( ) ../Wiki.php:69 4 0.0786 12046272 wfRunHooks( ) ../Wiki.php:474 5 0.0798 12229488 call_user_func_array ( ) ../Hooks.php:158 6 0.0798 12230512 InlineEditor::mediaWikiPerformAction( ) ../Hooks.php:0 7 0.0799 12233416 InlineEditor->render( ) ../InlineEditor.class.php:68 Pressing Back in the browser and trying to save again by pressing the Publish button again went without a problem though.
I must say I reallylike the general flow of the thing!
-- Krinkle
Thanks for the replies!
There's a few hours of video material, so that might be a bit too much to subtitle. Perhaps I'll find the time to make a compilation of the highlights, though.
A few points which may or may not have been raised before:
- I think editing inline like this eliminates or lessens the need for
a WYSIWYG editor because it already is very direct.
- Serverside parsing with AJAX, good choise. No half-parser
serverside, this way advanced users are ensured they can use all the syntax they know which would work in the full editor.
Yeah, still displaying wikitext and being able to use all wikitext codes is one of the important design decisions. One of the goals of this interface is not to replace the current editor, but to make it easier to do simple edits. Also, it should encourage people to edit more often ("Increase participation", Wikimedia strategy) and perhaps become regular editors one day, who would more often use the current / full interface.
- Currently the editmodes are indicated like tabs, which wrap around
an instructional paragraph. I would recommand making the tabs indicate/wrap around the entire article below (just like Page, Discussion, View, Edit are tabs for the entire page, "Sentences, "Paragraphs" etc. would be tabs for the article part (Ie. full width, and perhaps a suddle border connecting the tabs with the article)
This is indeed something that could perhaps solve the problem of the users not understanding these edit modes. I've got a few other ideas which I'll consider. Some of them will make it into prototypes next year. If you've got an idea how to present this in a better way, please respond!
[snip; lots of bugs]
Those are known bugs which I intentionally did not fix. Once the interface and user experience become more stable we can focus on making the code more stable! Two users actually encountered another bug during the usability research, when trying to add references. :)
I must say I reallylike the general flow of the thing!
Thanks!
Best regards, Jan Paul
wikitech-l@lists.wikimedia.org