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