Hey all,
I've been working on the InlineEditor extension again, primarily working on a new interface that doesn't use the different edit modes anymore, as the usability testing showed that this was not the right approach. Luckily, without a change in the underlying algorithms, it was doable to combine all the edit modes into one interface. This also resulted in the deletion of tens of files plus hundreds of lines of code [1], which usually is a good thing, because it shows it's a simpler and more natural approach. If you're interested in testing this on your own wiki or looking at the code, grab your copy from SVN. [2]
If you're interested in testing this, a wiki has been set up here: http://janpaulposma.nl/sle/wiki As you might know, some more usability testing will be done soon by GRNET [3], so we can see if this interface works better or not. Feel free to ask questions and throw in suggestions, etc.
Best regards, Jan Paul
[1] http://www.mediawiki.org/w/index.php?path=%2Ftrunk%2Fextensions%2FInlineEdit... [2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/InlineEditor/ [3] https://code.grnet.gr/projects/wikipedia-wysiwyg/wiki
Jan Paul Posma <jp.posma <at> gmail.com> writes:
Hey all,
I've been working on the InlineEditor extension again, primarily working on a
new interface that doesn't
use the different edit modes anymore, as the usability testing showed that
this was not the right
approach. Luckily, without a change in the underlying algorithms, it was
doable to combine all the edit
modes into one interface. This also resulted in the deletion of tens of files
plus hundreds of lines of code
[1], which usually is a good thing, because it shows it's a simpler and more
natural approach. If you're
interested in testing this on your own wiki or looking at the code, grab your
copy from SVN. [2]
If you're interested in testing this, a wiki has been set up here:
http://janpaulposma.nl/sle/wiki As you
might know, some more usability testing will be done soon by GRNET [3], so we
can see if this interface works
better or not. Feel free to ask questions and throw in suggestions, etc.
Best regards, Jan Paul
path=%2Ftrunk%2Fextensions%2FInlineEditor&title=Special%3ACode%2FMediaWiki%2Fpat h
[2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/InlineEditor/ [3] https://code.grnet.gr/projects/wikipedia-wysiwyg/wiki
Hi Jan I will start testing with http://janpaulposma.nl/sle/wiki
Following will be covered in initial test run. 1) Sentence-level editing 2) Browser compatibility
Thanks Janesh Kodikara
Jan Paul Posma wrote:
Hey all,
I've been working on the InlineEditor extension again, primarily working on a new interface that doesn't use the different edit modes anymore, as the usability testing showed that this was not the right approach. Luckily, without a change in the underlying algorithms, it was doable to combine all the edit modes into one interface. This also resulted in the deletion of tens of files plus hundreds of lines of code [1], which usually is a good thing, because it shows it's a simpler and more natural approach. If you're interested in testing this on your own wiki or looking at the code, grab your copy from SVN. [2]
If you're interested in testing this, a wiki has been set up here: http://janpaulposma.nl/sle/wiki As you might know, some more usability testing will be done soon by GRNET [3], so we can see if this interface works better or not. Feel free to ask questions and throw in suggestions, etc.
Best regards, Jan Paul
[1] http://www.mediawiki.org/w/index.php?path=%2Ftrunk%2Fextensions%2FInlineEdit... [2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/InlineEditor/ [3] https://code.grnet.gr/projects/wikipedia-wysiwyg/wiki
I completely missed the "You can edit the article below, by clicking on blue elements in the page." line. Only found after thinking "this needs some kind of notice on how to edit, since it's not clear what to do to change the page...".
Jan,
Very cool. Took me a minute to figure out how to use it, but once I did I really liked it. I think the user should have some way to correct any incorrectly parsed sentences though. Doing this would help develop a better sentence boundary parser in the long run too.
Nice work.
---- Original Message ----- From: "Jan Paul Posma" jp.posma@gmail.com Newsgroups: gmane.science.linguistics.wikipedia.technical To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Sent: Sunday, January 23, 2011 5:07 PM Subject: Sentence-level editing / InlineEditor extension update
Feel free to ask questions and throw in suggestions, etc.
Best regards, Jan Paul
Hi Jan, We have found few bugs and enhancements to be reported. What is the appropriate component for this project. https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions I cannot locate InlineEditor. Inline scripts if the correct component?
Best Regards Janesh Kodikara
2011/1/26 Janesh Kodikara janesh@calcey.com:
We have found few bugs and enhancements to be reported. What is the appropriate component for this project. https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions I cannot locate InlineEditor. Inline scripts if the correct component?
There is an InlineEditor component now. I don't know who created it; I tried to create it just now, but to my surprise it already existed.
Roan Kattouw (Catrope)
On Wed, Jan 26, 2011 at 12:36 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
There is an InlineEditor component now. I don't know who created it; I tried to create it just now, but to my surprise it already existed.
That would be Sam.
-Chad
We have found few bugs and enhancements to be reported. What is the appropriate component for this project. https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions I cannot locate InlineEditor. Inline scripts if the correct component?
Ah, looking forward to see what you've come up with! Like Roan and Chad said, the InlineEditor component is now in the list, so you can add bugs there.
Very cool. Took me a minute to figure out how to use it, but once I did I really liked it. I think the user should have some way to correct any incorrectly parsed sentences though. Doing this would help develop a better sentence boundary parser in the long run too.
Yeah, thought about that, but I think that anything not related to actually editing the wikitext might be distracting and confusing, so I would recommend not do do this.
I completely missed the "You can edit the article below, by clicking on blue elements in the page." line. Only found after thinking "this needs some kind of notice on how to edit, since it's not clear what to do to change the page...".
in usability testing I also found that people don't read texts like that at all. That's one of the reasons I removed the different edit modes. It was also clear, however, that just by moving the mouse over the screen and seeing text being highlighted, there wasn't any need to read that kind of notices, as all users understood the concept very quickly. After that they would search for a save button, and would find the publish button after looking around for a bit.
If you have suggestions how to make it more clear how this works it would be appreciated, but there already is a minimum of text and notices on the screen right now.
Jan Paul
Jan Paul Posma wrote:
I completely missed the "You can edit the article below, by clicking on blue elements in the page." line. Only found after thinking "this needs some kind of notice on how to edit, since it's not clear what to do to change the page...".
in usability testing I also found that people don't read texts like that at all. That's one of the reasons I removed the different edit modes. It was
also clear,
however, that just by moving the mouse over the screen and seeing text being highlighted, there wasn't any need to read that kind of notices, as all users understood the concept very quickly. After that they would search for a save button, and would find the publish button after looking around for a bit.
That's precisely the kind of things you want to find out from a usability study. That's why I reported it, not only to show the world how dumb I am :) My eyes moved from "Awesome, you are editing Wikipedia!" to "Can you briefly describe the changes you're making?" completely missing it on the first scan. Worse, I also wondered for a few seconds where was the edit box. You need to move the mouse and click to really be sure you're doing it the right way. Having the text about blue elements on a (lighter) blue box may not be a good idea.
A few other improvements: When you open the "line editor" you get the options 'Preview' and 'Cancel'. It's a bit puzzling not having a button to Save, so I would rename the first one to "Change", and maybe delay showing the Publish button until you have done one Change. That needs testing with longer articles, though. Although that would also allow us to reuse the upper space for both telling them to click lines, and -after they discover it- showing the "Remember to press Publish".
On 27-Jan-2011, at 0:04, Platonides wrote:
Jan Paul Posma wrote:
I completely missed the "You can edit the article below, by clicking on blue elements in the page." line. Only found after thinking "this needs some kind of notice on how to edit, since it's not clear what to do to change the page...".
in usability testing I also found that people don't read texts like that at all. That's one of the reasons I removed the different edit modes. It was
also clear,
however, that just by moving the mouse over the screen and seeing text being highlighted, there wasn't any need to read that kind of notices, as all users understood the concept very quickly. After that they would search for a save button, and would find the publish button after looking around for a bit.
That's precisely the kind of things you want to find out from a usability study. That's why I reported it, not only to show the world how dumb I am :) My eyes moved from "Awesome, you are editing Wikipedia!" to "Can you briefly describe the changes you're making?" completely missing it on the first scan. Worse, I also wondered for a few seconds where was the edit box.
Haha, yep, that's obviously what's going to happen to current editors with any new interface as radical as this ;)
You need to move the mouse and click to really be sure you're doing it the right way. Having the text about blue elements on a (lighter) blue box may not be a good idea.
Good point! Perhaps a grey or white box with blue outline also fits better in the current Vector design.
A few other improvements: When you open the "line editor" you get the options 'Preview' and 'Cancel'. It's a bit puzzling not having a button to Save, so I would rename the first one to "Change", and maybe delay showing the Publish button until you have done one Change. That needs testing with longer articles, though. Although that would also allow us to reuse the upper space for both telling them to click lines, and -after they discover it- showing the "Remember to press Publish".
The text "Preview" was chosen very specifically to indicate that it will not be saved/published right away, as you might think with "Change". This might prohibit new users from starting to experiment as they fear the changes will instantly be visible. On the other hand, I've had many comments on the "Preview" text from the participants of the usability tests. So in the end I'd rather have a label that is a bit weirder at first, but conveys the message of how the interface works better.
Your suggestion of showing a remember text later is one I've also thought about. However, it doesn't take away the fear of editing at first. Another way to signal to users that their first changes aren't published, is the text When you're done, don't forget to publish the page!", which also indicates that nothing happens before hitting the publish button.
Anyway, I'm not a professional copywriter ;) so yeah, I've heard some good suggestions out there. If you're interested in this kind of "micro" interface design, check out the rationale for the current texts: http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing/Prototy... I'm not quite sure if this is something to really think about now or in a later stage of the design (it's still possible that things will change a lot), but it's an interesting discussion nevertheless :)
Jan Paul
On Wed, Jan 26, 2011 at 3:56 PM, Jan Paul Posma jp.posma@gmail.com wrote:
The text "Preview" was chosen very specifically to indicate that it will not be saved/published right away, as you might think with "Change". This might prohibit new users from starting to experiment as they fear the changes will instantly be visible. On the other hand, I've had many comments on the "Preview" text from the participants of the usability tests. So in the end I'd rather have a label that is a bit weirder at first, but conveys the message of how the interface works better.
How about "Continue" and "Undo" in place of "Preview" and "Cancel"?
Neither suggests an immediate end to the entire editing session, but both make some sort of sense within a wider scope of making several changes to a document.
-- brion
On Thu, Jan 27, 2011 at 12:56 AM, Jan Paul Posma jp.posma@gmail.com wrote:
That's precisely the kind of things you want to find out from a usability study. That's why I reported it, not only to show the world how dumb I am :) My eyes moved from "Awesome, you are editing Wikipedia!" to "Can you briefly describe the changes you're making?" completely missing it on the first scan. Worse, I also wondered for a few seconds where was the edit box.
Haha, yep, that's obviously what's going to happen to current editors with any new interface as radical as this ;)
Perhaps an image at the top, showing a sentence with a mouse cursor hovering above it, accompanied with "click on a sentence to edit it" would help?
Bryan
"Jan Paul Posma" jp.posma@gmail.com wrote in message news:C9B32333-E8B7-4CC5-9B54-EA012F90B0E2@gmail.com...
We have found few bugs and enhancements to be reported. What is the appropriate component for this project. https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions I cannot locate InlineEditor. Inline scripts if the correct component?
Ah, looking forward to see what you've come up with! Like Roan and Chad said, the InlineEditor component is now in the list, so you can add bugs there.
Hi Jan Few bugs and a enchantement are reported. We will continue with bit of boundary testing.
Is it a good idea to keep a track of enhancements/bugsposted by others? I mean recording them in Bugzilla
Thanks Janesh
Few bugs and a enchantement are reported. We will continue with bit of boundary testing.
Thanks! :)
Is it a good idea to keep a track of enhancements/bugsposted by others? I mean recording them in Bugzilla
I'll add the suggestions of the mailinglist to bugzilla somewhere next week.
Jan Paul
----- Original Message ----- From: "Jan Paul Posma" jp.posma@gmail.com Newsgroups: gmane.science.linguistics.wikipedia.technical To: "Janesh Kodikara" janesh@calcey.com; "Wikimedia developers" wikitech-l@lists.wikimedia.org Sent: Friday, January 28, 2011 3:00 AM Subject: Re: Sentence-level editing / InlineEditorextensionupdate
Few bugs and a enchantement are reported. We will continue with bit of boundary testing.
Thanks! :)
Is it a good idea to keep a track of enhancements/bugsposted by others? I mean recording them in Bugzilla
I'll add the suggestions of the mailinglist to bugzilla somewhere next week.
Jan Paul
Hi Jan We tested inline edior installation too. http://www.pragmatictestlabs.com/pragmaticwiki/
Thanks Janesh
Hey Janesh,
We tested inline edior installation too. http://www.pragmatictestlabs.com/pragmaticwiki/
Great! The bugs you filed in Bugzilla will be looked at by GRNET developers soon. :) I'll also add some suggestions and bugs from the mailinglist to Bugzilla this weekend. Thanks again for the testing!
Cheers, Jan Paul
wikitech-l@lists.wikimedia.org