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