Most developers have specialisations -- some of us hate UI design and love DB performance optimisation, others don't know any PHP but can speak HTML/CSS like a second language. This is a problem for writing features for an open source web app -- the nature of the work is cross-disciplinary, but the culture encourages individual effort. The result of this is that developers are placed under pressure to learn a huge skill set, and that can be a disincentive to participation.
I have an idea for a feature, and I was wondering if anyone might want to collaborate on it. The idea is to display, in a box in the edit window, information about who else has the same edit window open. For example, it could display each username, along with the amount of time they have been idle and the edit summary they have typed if any. The box will periodically refresh itself, say once every 10 seconds. At the same time as fetching updated data, the client sends back information about how long the user has been idle and so on.
An optional subfeature would be allow the user to remove themselves from the box voluntarily, e.g. to signal that they have no interest in actually saving the article and that they are just looking at the source.
There are three different skill sets which are required to make this feature:
Person 1: User interface design Person 2: Client-side programming Person 3: Server-side programming
The tasks can be roughly divided as follows:
Person 1: Make a mockup of the user interface by taking the HTML of an edit page from MediaWiki and adding a box with the required information. Edit the HTML and the CSS. PHP or JavaScript knowledge is not required, although some JS knowledge may be desirable to allow them to demonstrate any necessary show/hide buttons and popups.
Person 2: Write the JavaScript. Monitor the edit window and send the information I have described to the server. To update the info box, write a model server response with a text editor, save it as a static file. Have the JS load the model response and update the box in response. Deliver a request/response format specification.
Person 3: Write the PHP. Implement the AJAX handler using the specification from Person 2. Implement an internationalised user interface based on the mockup delivered by Person 1.
I can probably be Person 3, but I don't think I can handle the other two tasks as well. Any volunteers? Anyone know anyone who might be interested?
-- Tim Starling
On 8/25/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Most developers have specialisations -- some of us hate UI design and love DB performance optimisation, others don't know any PHP but can speak HTML/CSS like a second language. This is a problem for writing features for an open source web app -- the nature of the work is cross-disciplinary, but the culture encourages individual effort. The result of this is that developers are placed under pressure to learn a huge skill set, and that can be a disincentive to participation.
I really like this idea. I'd like to help develop MediaWiki, but since I don't know PHP MySQL it's going to be a learning curve before I really get started. However, I have a strong interest in user interface design and would love to colaborate. (Unfortunately, probably not for this project as I'm about to hit the road for 7 weeks of continuous travelling - lucky me).
I have an idea for a feature, and I was wondering if anyone might want to collaborate on it. The idea is to display, in a box in the edit window, information about who else has the same edit window open. For example, it could display each username, along with the amount of time they have been idle and the edit summary they have typed if any. The box will periodically refresh itself, say once every 10 seconds. At the same time as fetching updated data, the client sends back information about how long the user has been idle and so on.
Certainly an interesting idea. I have a mild concern about the use of this feature on users' talk pages (I've already had instances of two users accusing each other of monitoring my talk page for badmouthing from the other!!), but it'd be especially nice for other talk pages which get updated frequently.
If you wanted to take it even further, make it possibly to automatically resync with the server if someone else saves the page. It shouldn't be too hard to use a really granular diffing algorithm to add or remove whole paragraphs, and to just say "no, too hard" if there are any overlaps in the changes.
An optional subfeature would be allow the user to remove themselves from the box voluntarily, e.g. to signal that they have no interest in actually saving the article and that they are just looking at the source.
If you're doing all this in javascript, could you not attempt to treat them as being in "view source" mode until they actually modify the source?
I can probably be Person 3, but I don't think I can handle the other two tasks as well. Any volunteers? Anyone know anyone who might be interested?
If you don't find anyone before late October, feel free to give me a yell ;)
Steve
Tim Starling wrote:
The idea is to display, in a box in the edit window, information about who else has the same edit window open. For example, it could display each username, along with the amount of time they have been idle and the edit summary they have typed if any.
While technically a nice idea, I'm a bit concerned about privacy.
I for myself do expect that I can edit a page and type anything into the edit window without anyone else knowing. Not even knowing that I have this page open. I don't want to publish any info *until* I hit save.
I have several times canceled a talk page post already written into the edit window (censoring myself). And sometimes I was really glad having canceled ;)
--Ligulem
On 8/25/06, Ligulem ligulem@pobox.com wrote:
I for myself do expect that I can edit a page and type anything into the edit window without anyone else knowing. Not even knowing that I have this page open. I don't want to publish any info *until* I hit save.
I have several times canceled a talk page post already written into the edit window (censoring myself). And sometimes I was really glad having canceled ;)
Come to think of it, is there any need to display the username? Or at least, make username-displaying an optional, opt-in feature?
It's certainly happened to me to consider editing articles which, at save time, I reconsidered and decided I didn't want to be a permanent part of my editing record. Call me a wuss, sure :)
Steve
Steve Bennett wrote:
Come to think of it, is there any need to display the username? Or at least, make username-displaying an optional, opt-in feature?
The whole feature should be opt-in.
We have the {{inuse}} on en, which can be deliberately set or not. Problem is, people forget to remove it.
And what about anons? Would we see the IP of someone that hit on edit? We could then block that IP even before the user saves ;)
Steve Bennett wrote:
On 8/25/06, Ligulem ligulem@pobox.com wrote:
I for myself do expect that I can edit a page and type anything into the edit window without anyone else knowing. Not even knowing that I have this page open. I don't want to publish any info *until* I hit save.
I have several times canceled a talk page post already written into the edit window (censoring myself). And sometimes I was really glad having canceled ;)
Come to think of it, is there any need to display the username? Or at least, make username-displaying an optional, opt-in feature?
It's certainly happened to me to consider editing articles which, at save time, I reconsidered and decided I didn't want to be a permanent part of my editing record. Call me a wuss, sure :)
Username yes, IP address for anons no. RC patrol can be a lonely task, I want to make it a little bit more human. Displaying usernames encourages a sense of community. But like I said in my original post, an opt-out feature would be nice.
-- Tim Starling
On 8/25/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Username yes, IP address for anons no. RC patrol can be a lonely task, I want to make it a little bit more human. Displaying usernames encourages a sense of community. But like I said in my original post, an opt-out feature would be nice.
Ah yeah, ok. The difficulty is how to make that opt-out work nicely, without the user having to "quickly" hit some button if he doesn't want others to know he's viewing the source or whatever. Hence your request for a GUI designer ;)
More collaborative editing tools in general might be nice. We see so much discussion on this list about the few really controversial articles that get dozens of edits a day that we forget that the vast majority of Wikipedia is a very quiet place where you rarely bump into anyone at all.
Steve
On Fri, Aug 25, 2006 at 02:45:18PM +0200, Steve Bennett wrote:
More collaborative editing tools in general might be nice. We see so much discussion on this list about the few really controversial articles that get dozens of edits a day that we forget that the vast majority of Wikipedia is a very quiet place where you rarely bump into anyone at all.
And while we're tangentially on the topic of my favorite hobby horse:
Are we *ever* going to get a way to edit ledes without having to lock the whole page?
(Tim: could your thing show which section they're editing, too?)
Cheers, -- jra
As someone who always sets "invisible mode" off on forums, I can say it can be slightly creepy to have someone say "Oh, you're sending a private message, I wonder who it's to?" or "I wondered when you'd get around to reading that thread" on IRC or wherever. Given the number of privacy-lovers you get in the open-source community, I suspect you'll see fairly strong backlash if you make it opt-out rather than opt-in, and don't at least make a checkbox or something to set the preference right from the edit window.
Personally, I would put more stress on the message box and less on the names. Make the name-showing opt-in, not opt-out (with those who fail to opt in being billed as "invisible users" or something); messages should be sendable even without logging in or showing your name.
On 8/25/06, Jay R. Ashworth jra@baylink.com wrote:
Are we *ever* going to get a way to edit ledes without having to lock the whole page?
The edit-conflict resolver doesn't care whether you're editing the page or a section. If the two edits are to different lines, they're merged; if they're to the same line, they conflict. (There may be some more details that I don't know of, but that's the gist of it.) Edit conflicts occur most frequently on busy RFAs or talk pages because everyone's editing the same line, namely the one below where the last guy left his comment.
On Fri, Aug 25, 2006 at 01:47:16PM -0400, Simetrical wrote:
On 8/25/06, Jay R. Ashworth jra@baylink.com wrote:
Are we *ever* going to get a way to edit ledes without having to lock the whole page?
The edit-conflict resolver doesn't care whether you're editing the page or a section. If the two edits are to different lines, they're merged; if they're to the same line, they conflict. (There may be some more details that I don't know of, but that's the gist of it.)
Let me be the first to say that, psychologically, it doesn't feel that way at *all*. And based on other people's comments, I'm not the only one who doesn't get that.
Edit conflicts occur most frequently on busy RFAs or talk pages because everyone's editing the same line, namely the one below where the last guy left his comment.
Sure; but that wasn't the situation I was trying to fix.
Cheers, -- jra
Simetrical wrote:
The edit-conflict resolver doesn't care whether you're editing the page or a section. If the two edits are to different lines, they're merged; if they're to the same line, they conflict. (There may be some more details that I don't know of, but that's the gist of it.) Edit conflicts occur most frequently on busy RFAs or talk pages because everyone's editing the same line, namely the one below where the last guy left his comment.
I would probably mumble something about my long-ago proposal to do away with the "Edit Conflict" screen altogether, if only it hadn't been criticised and flamed so much at the time....
On 25/08/06, Timwi timwi@gmx.net wrote:
I would probably mumble something about my long-ago proposal to do away with the "Edit Conflict" screen altogether, if only it hadn't been criticised and flamed so much at the time....
I'd like to see it removed in more cases; more intelligent handling of merges. And in the cases where it does come up, as mentioned above, I'd like to see people presented with a fancier interface (where possible), to make it all easier.
I'd suspect an edit conflict is up there with other horrendous quirks when putting newbies off participating in discussions.
Rob Church
On 8/26/06, Rob Church robchur@gmail.com wrote:
I'd like to see it removed in more cases; more intelligent handling of merges. And in the cases where it does come up, as mentioned above, I'd like to see people presented with a fancier interface (where possible), to make it all easier.
I'd suspect an edit conflict is up there with other horrendous quirks when putting newbies off participating in discussions.
It's obviously annoying enough that people frequently mention it in their actual posts ("argh! 2 edit conflicts!") Hardly ever happens to me. I must type too quickly :)
Steve
On Fri, Aug 25, 2006 at 08:06:17PM +0100, Timwi wrote:
Jay R. Ashworth wrote:
Are we *ever* going to get a way to edit ledes without having to lock the whole page?
Edit any section, then change 'section=n' in the URL to 'section=0'.
Which means the machinery is in place, just not the UI. Thanks for pointing that out, Timwi.
Cheers, -- jra
On 27/08/06, Jay R. Ashworth jra@baylink.com wrote:
Which means the machinery is in place, just not the UI. Thanks for pointing that out, Timwi.
See also http://bugzilla.wikimedia.org/show_bug.cgi?id=156.
Rob Church
On Sun, Aug 27, 2006 at 03:41:57AM +0100, Rob Church wrote:
On 27/08/06, Jay R. Ashworth jra@baylink.com wrote:
Which means the machinery is in place, just not the UI. Thanks for pointing that out, Timwi.
Noted, Rob. Thanks.
Cheers, -- jra
Ligulem wrote:
Tim Starling wrote:
The idea is to display, in a box in the edit window, information about who else has the same edit window open. For example, it could display each username, along with the amount of time they have been idle and the edit summary they have typed if any.
While technically a nice idea, I'm a bit concerned about privacy.
I for myself do expect that I can edit a page and type anything into the edit window without anyone else knowing. Not even knowing that I have this page open. I don't want to publish any info *until* I hit save.
I have several times canceled a talk page post already written into the edit window (censoring myself). And sometimes I was really glad having canceled ;)
I feel the same way, which is why I'm not suggesting that we send the actual text typed into the edit box to the server. Just some meta-information such as number of characters typed, or an explicitly public summary. Perhaps we could have a separate textbox where the user can type a message to send to other people viewing the edit page. Imagine if you could type "I'm busy rewriting this rubbish stub, don't bother fixing the spelling". Then anyone else who opened the article from new pages patrol would know to stay away. It would save a lot of edit conflicts.
-- Tim Starling
On 8/25/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
It would save a lot of edit conflicts.
If this is the goal, why not consider allowing true section editing where editing section A doesn't conflict with an edit to section B? Could be more work though :)
How do you feel about not showing the user's name? Perhaps if they want to show it, they can type ~~~~ somewhere in the "meta-edit box"?
Also, are you proposing this feature being standard for all editors? On Wikipedia?
Steve
On Fri, Aug 25, 2006 at 02:36:09PM +0200, Steve Bennett wrote:
On 8/25/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
It would save a lot of edit conflicts.
If this is the goal, why not consider allowing true section editing where editing section A doesn't conflict with an edit to section B? Could be more work though :)
Color me confused: I thought we'd had *this* for *years*...
Cheers, -- jra
On 25/08/06, Jay R. Ashworth jra@baylink.com wrote:
On Fri, Aug 25, 2006 at 02:36:09PM +0200, Steve Bennett wrote:
On 8/25/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
It would save a lot of edit conflicts.
If this is the goal, why not consider allowing true section editing where editing section A doesn't conflict with an edit to section B? Could be more work though :)
Color me confused: I thought we'd had *this* for *years*...
We do, sufficient enough. MediaWiki will attempt to merge edits (simple merging, we're not talking gratuitous hyper-intelligent stuff) if it can; I would wager that a lot of edit conflicts are avoided in this step alone. Of course, if it can't, it throws a conflict. And I expect sometimes something upsets it, and it throws a conflict for the sheer hell of it. :)
There's quite a bit that could be done in the edit conflict arena, though. Three-way merging of edits, anyone? A friendlier conflict UI would be a damn good start, although I have to admit I'm not sure what I'd call a "friendlier conflict UI"...I'd have to think on it.
One immediate improvement that someone could make is to have MediaWiki handle in-section conflicts without "breaking out" and showing both copies of the full text. Current behaviour means that, e.g. two editors adding comments in a section on a discussion page who cause an edit conflict will have to battle with the full text of the page...which, as we all know, can be quite a considerable whack.
Rob Church
On Fri, Aug 25, 2006 at 02:14:03PM +0100, Rob Church wrote:
Color me confused: I thought we'd had *this* for *years*...
We do, sufficient enough. MediaWiki will attempt to merge edits (simple merging, we're not talking gratuitous hyper-intelligent stuff) if it can; I would wager that a lot of edit conflicts are avoided in this step alone. Of course, if it can't, it throws a conflict. And I expect sometimes something upsets it, and it throws a conflict for the sheer hell of it. :)
There's quite a bit that could be done in the edit conflict arena, though. Three-way merging of edits, anyone? A friendlier conflict UI would be a damn good start, although I have to admit I'm not sure what I'd call a "friendlier conflict UI"...I'd have to think on it.
One immediate improvement that someone could make is to have MediaWiki handle in-section conflicts without "breaking out" and showing both copies of the full text. Current behaviour means that, e.g. two editors adding comments in a section on a discussion page who cause an edit conflict will have to battle with the full text of the page...which, as we all know, can be quite a considerable whack.
Come to think of it, yeah, I guess the Edit Conflict page *does* show the whole page, doesn't it. I don't fight that battle too often.
Cheers, -- jra
Tim Starling wrote:
I feel the same way, which is why I'm not suggesting that we send the actual text typed into the edit box to the server. Just some meta-information such as number of characters typed, or an explicitly public summary. Perhaps we could have a separate textbox where the user can type a message to send to other people viewing the edit page. Imagine if you could type "I'm busy rewriting this rubbish stub, don't bother fixing the spelling". Then anyone else who opened the article from new pages patrol would know to stay away. It would save a lot of edit conflicts.
Ok. But you wrote: ... "and the edit summary they have typed if any"
So others could see the edit summary? (Shudder ;)
Maybe an optional message box would be helpful (editable). The message while editing might not be the same as the edit summary.
Chatting with each other while editing? Like an IRC channel with the title of the page?
On 8/25/06, Ligulem ligulem@pobox.com wrote:
Ok. But you wrote: ... "and the edit summary they have typed if any"
So others could see the edit summary? (Shudder ;)
Maybe an optional message box would be helpful (editable). The message while editing might not be the same as the edit summary.
Two separate messages for one short edit might be a bit overkill. Dunno about everyone else, but my usual editing sequence goes something like this:
1. Make a change 2. Type an edit summary and set the watch/minor checkboxes 3. Preview 4. Save or go back to 1.
Chatting with each other while editing? Like an IRC channel with the title of the page?
Some kind of chat features would be kind of cool (but a totally separate project), bearing in mind that: - discussing anything "serious" by chat is bad for talk pages as it's not recorded - IRC already exists :)
However, it would certainly be useful as not everyone has access to an IRC client, and it would be more centralised if built into the main interface.
Steve
Steve Bennett wrote:
On 8/25/06, Ligulem ligulem@pobox.com wrote:
Ok. But you wrote: ... "and the edit summary they have typed if any"
So others could see the edit summary? (Shudder ;)
Maybe an optional message box would be helpful (editable). The message while editing might not be the same as the edit summary.
Two separate messages for one short edit might be a bit overkill.
If it's too much then don't type it. If you think the feature won't be used at all, then I think you have another thing coming.
Dunno about everyone else, but my usual editing sequence goes something like this:
- Make a change
- Type an edit summary and set the watch/minor checkboxes
- Preview
- Save or go back to 1.
Yes, so does everyone's, that's because we don't have an interactive message box to type into. Behaviour will change according to features.
Let me also say this: if your typical editing behaviour is to open the edit box, change some little thing, and save it immediately, then you're one of the culprits of the edit conflict problem. You're the kind of user that the "please don't edit this" message is aimed at. Some users want to spend longer editing and reviewing a change, and they shouldn't be penalised for their extra dedication to correctness.
Chatting with each other while editing? Like an IRC channel with the title of the page?
Some kind of chat features would be kind of cool (but a totally separate project), bearing in mind that:
- discussing anything "serious" by chat is bad for talk pages as it's
not recorded
- IRC already exists :)
However, it would certainly be useful as not everyone has access to an IRC client, and it would be more centralised if built into the main interface.
Enough chit chat, where's my Person 1? I want concrete features and I want them now. The feature is a simple one, if we can assemble the right skills, just a few hours' work each. But to get us started, someone needs to make that UI mockup.
-- Tim Starling
On 25/08/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Enough chit chat, where's my Person 1? I want concrete features and I want them now. The feature is a simple one, if we can assemble the right skills, just a few hours' work each. But to get us started, someone needs to make that UI mockup.
Tim wants his person one and he wants him/her now! But he's failed to factor in the importance of promising cookies and fame. Oh, and the fact that being brisk and abrupt and snappish to a bunch of volunteers is a bad idea...
You know what "want" did, don't you?
Any road, snotty sarcasm over; I can see this feature enjoying use by a wide variety of users; there's those who make long cleanup edits to a page (and you don't really want to duplicate cleanup effort), recent changes patrol, etc. Unfortunately, my UI skills are still pretty crap; anything decent I've output is sheer chaos, luck and swearing at Dreamweaver. One idea, though, might be to shove it all in a nice box parallel to the top of the edit form; using a not-too-ridiculous font size (the default, or a few points shaved off it, should do), and positioning it in a sensible location (it'll be seen there, before the text is, and will be in the user's view for the first few seconds of editing, at least) will, hopefully, cause it to be considered useful, not intrusive.
Is it worth making this a (default on) preference? I can think of cases or wikis where I wouldn't want to use it, and being able to switch it off for a few edits would be useful. Should we also, perhaps, indicate whether the user in question is adding a section (discussion pages, etc.)?
Rob Church
On Fri, Aug 25, 2006 at 02:25:01PM +0100, Rob Church wrote:
On 25/08/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Enough chit chat, where's my Person 1? I want concrete features and I want them now. The feature is a simple one, if we can assemble the right skills, just a few hours' work each. But to get us started, someone needs to make that UI mockup.
Tim wants his person one and he wants him/her now! But he's failed to factor in the importance of promising cookies and fame. Oh, and the fact that being brisk and abrupt and snappish to a bunch of volunteers is a bad idea...
You know what "want" did, don't you?
Turn Robchurch's sense of humor off, temporarily? :-)
Any road, snotty sarcasm over; I can see this feature enjoying use by a wide variety of users; there's those who make long cleanup edits to a page (and you don't really want to duplicate cleanup effort), recent changes patrol, etc. Unfortunately, my UI skills are still pretty crap; anything decent I've output is sheer chaos, luck and swearing at Dreamweaver. One idea, though, might be to shove it all in a nice box parallel to the top of the edit form; using a not-too-ridiculous font size (the default, or a few points shaved off it, should do), and positioning it in a sensible location (it'll be seen there, before the text is, and will be in the user's view for the first few seconds of editing, at least) will, hopefully, cause it to be considered useful, not intrusive.
Pony: while we're working on the edit form, could we please at least consider putting a LiveJournal inspired "log me in with this edit" box?
Is it worth making this a (default on) preference? I can think of cases or wikis where I wouldn't want to use it, and being able to switch it off for a few edits would be useful. Should we also, perhaps, indicate whether the user in question is adding a section (discussion pages, etc.)?
I suspect that which *way* it defaults should be an installation time/ configuration file option.
Cheers, -- jra
On 8/25/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Two separate messages for one short edit might be a bit overkill.
If it's too much then don't type it. If you think the feature won't be used at all, then I think you have another thing coming.
??? where did that come from???
Steve
Steve Bennett wrote:
On 8/25/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Two separate messages for one short edit might be a bit overkill.
If it's too much then don't type it. If you think the feature won't be used at all, then I think you have another thing coming.
??? where did that come from???
I didn't mean to sound rude. Just a figure of speech.
-- Tim Starling
On Fri, Aug 25, 2006 at 11:16:44PM +1000, Tim Starling wrote:
If it's too much then don't type it. If you think the feature won't be used at all, then I think you have another thing coming.
Ken Jennings says that's "another think coming". :-)
Dunno about everyone else, but my usual editing sequence goes something like this:
- Make a change
- Type an edit summary and set the watch/minor checkboxes
- Preview
- Save or go back to 1.
Yes, so does everyone's, that's because we don't have an interactive message box to type into. Behaviour will change according to features.
Sometimes. You hope. :-)
Let me also say this: if your typical editing behaviour is to open the edit box, change some little thing, and save it immediately, then you're one of the culprits of the edit conflict problem. You're the kind of user that the "please don't edit this" message is aimed at. Some users want to spend longer editing and reviewing a change, and they shouldn't be penalised for their extra dedication to correctness.
No, but they person fixing one thing shouldn't be penalized, neither, should they? Making them *both* happy was, I thought, your target here.
Enough chit chat, where's my Person 1? I want concrete features and I want them now. The feature is a simple one, if we can assemble the right skills, just a few hours' work each. But to get us started, someone needs to make that UI mockup.
Alas, it's not me. I'll shut up now.
Cheers, -- jra
Tim Starling wrote:
Enough chit chat, where's my Person 1? I want concrete features and I want them now. The feature is a simple one, if we can assemble the right skills, just a few hours' work each. But to get us started, someone needs to make that UI mockup.
Most edit conflicts happen on "discussion" (voting) pages. Stuff like RfA's. This feature won't change that situation.
I can't think of any edit conflict in main space of my edits. Not even among my thousands of AWB/MWB edits. But I'm not a featured article artist (template wonk might fit better).
Major overhauls of articles are either done by a single chef de cuisine or they are discussed before.
But I'll shut up now ;) (I'm not person 1)
On Fri, Aug 25, 2006 at 06:17:48PM +0200, Ligulem wrote:
Most edit conflicts happen on "discussion" (voting) pages. Stuff like RfA's. This feature won't change that situation.
You didn't spend much time on "2004 US Presidential Election", did you?
Cheers, -- jra
On 8/25/06, Jay R. Ashworth jra@baylink.com wrote:
On Fri, Aug 25, 2006 at 06:17:48PM +0200, Ligulem wrote:
Most edit conflicts happen on "discussion" (voting) pages. Stuff like RfA's. This feature won't change that situation.
You didn't spend much time on "2004 US Presidential Election", did you?
What's the scenario that happens with a page like that that could be resolved if you could see who was working on which section? I hardly ever work on "busy" pages, myself.
Steve
On Fri, Aug 25, 2006 at 06:47:52PM +0200, Steve Bennett wrote:
On 8/25/06, Jay R. Ashworth jra@baylink.com wrote:
On Fri, Aug 25, 2006 at 06:17:48PM +0200, Ligulem wrote:
Most edit conflicts happen on "discussion" (voting) pages. Stuff like RfA's. This feature won't change that situation.
You didn't spend much time on "2004 US Presidential Election", did you?
What's the scenario that happens with a page like that that could be resolved if you could see who was working on which section? I hardly ever work on "busy" pages, myself.
I wasn't suggesting that Tim's proposed feech would solve the [[Bushdot syndrome]], merely clarifying for Ligulem that I disagreed with his characterization.
Cheers, -- jra
But to get us started, someone needs to make that UI mockup.
Very draft mock-up of a possible UI, from what I think you're describing: http://files.nickj.org/MediaWiki/ui-draft-mockup.png In the picture, the "Notify others of my edit" box should be ticked (since it is shown in the list). Maybe "Notify others of my edit" should labelled "Notify others of my progress"? Maybe the number of characters changed should be shown, maybe it shouldn't. Maybe the name of the other user should be shown, and maybe it shouldn't. Maybe the user's own changes should be shown in the list, maybe they shouldn't.
For the messages between client JavaScript and the PHP on the server, sounds like maybe there are 3 types of messages: 1) A status update when someone starts editing something, or a periodic update as they make changes. 2) A method for querying what the current status is of ongoing edits it. 3) A response from the server as to what the status of current edits is.
Format 1 probably needs the summary, section, revision, time since the user last changed anything in the textbox, and possibly the number of characters changed. The server presumably already knows the username from the cookie. E.g.: (Section, chars modified, revision, seconds since last change, edit summary): ["Background",235,20060823110052,34,"Typo fixes"]
Format 2: Can just be a get request, using the exact same URL format as per index.php : e.g. GET http://en.wikipedia.org/wiki/edit-status.php?title=User:Nickj/Sandbox
Possible response format from PHP on server for number 3 (in response to GET request #2) is:
# No conflicts: []
# Only one conflict. Fields are: Username, section name, changed characters, timestamp of version editing, seconds since last change, edit summary: [["User:Nickj","Background",235,20060823110052,34,"Typo fixes"]]
# Two conflicts (sorted by seconds since last change?) : [["User:Nickj","Background",235,20060823110052,34,"Typo fixes"],["User:203.15.35.81","",1000,20041112231221,100,"I am a Vandal!"]]
You probably also need a timeout mechanism (e.g. if haven't received a status report from a client in 5 mins, then drop the user from the list), and maybe also a message to inform the server if the user aborts the edit (although they can just click the "back" button, rather than clicking "cancel", in which case you probably won't get the message).
All the best, Nick.
Nick Jenkins wrote:
Very draft mock-up of a possible UI, from what I think you're describing: http://files.nickj.org/MediaWiki/ui-draft-mockup.png
Looks nice. Many thanks for doing the mockup.
While you guys are at it: could you make the edit summary field larger? I mean extending it to right edge of the window. I always do have a strong key hole viewing feeling when looking at this edit page.
Also could you please add a preview for the edit summary (when I hit preview I want a preview for the page text *and* the edit summary as it will appear in the history). Reason: I'm prone to typos but I see them better when I can look at the text in original font and with links parsed.
And how bad would it be being able to edit my own edit summary *after* save? Maybe with a time limit (after 6 hours or whatever time limit the edit summary is fixed forever). We sometimes put some stuff in edit summaries we regret later (example: Wikipedians have been opposed on RfA's for edit summaries alone). Nobody is perfect ;-) Of course, this feature would be limited to logged in users.
--Ligulem
On 8/26/06, Ligulem ligulem@pobox.com wrote:
While you guys are at it: could you make the edit summary field larger? I mean extending it to right edge of the window. I always do have a strong key hole viewing feeling when looking at this edit page.
One-line stylesheet change: input#wpSummary { width: 80%; }. I've had it in my personal CSS for a while now, and it's much better.
Simetrical wrote:
On 8/26/06, Ligulem ligulem@pobox.com wrote:
While you guys are at it: could you make the edit summary field larger? I mean extending it to right edge of the window. I always do have a strong key hole viewing feeling when looking at this edit page.
One-line stylesheet change: input#wpSummary { width: 80%; }. I've had it in my personal CSS for a while now, and it's much better.
Cool. Exactly what I needed. Thanks a lot!
On 8/26/06, Ligulem ligulem@pobox.com wrote:
While you guys are at it: could you make the edit summary field larger? I mean extending it to right edge of the window. I always do have a strong key hole viewing feeling when looking at this edit page.
One-line stylesheet change: input#wpSummary { width: 80%; }. I've had it in my personal CSS for a while now, and it's much better.
That is so much better. Wouldn't it be nicer to make this the default?
I've filed a lowest-priority enhancement bug at http://bugzilla.wikimedia.org/show_bug.cgi?id=7139 requesting this.
All the best, Nick.
Nick Jenkins wrote:
But to get us started, someone needs to make that UI mockup.
Very draft mock-up of a possible UI, from what I think you're describing: http://files.nickj.org/MediaWiki/ui-draft-mockup.png In the picture, the "Notify others of my edit" box should be ticked (since it is shown in the list). Maybe "Notify others of my edit" should labelled "Notify others of my progress"? Maybe the number of characters changed should be shown, maybe it shouldn't. Maybe the name of the other user should be shown, and maybe it shouldn't. Maybe the user's own changes should be shown in the list, maybe they shouldn't.
Thanks for that. Can we have the HTML source for it?
For the messages between client JavaScript and the PHP on the server, sounds like maybe there are 3 types of messages:
- A status update when someone starts editing something, or a periodic update as they make changes.
- A method for querying what the current status is of ongoing edits it.
- A response from the server as to what the status of current edits is.
Format 1 probably needs the summary, section, revision, time since the user last changed anything in the textbox, and possibly the number of characters changed. The server presumably already knows the username from the cookie. E.g.: (Section, chars modified, revision, seconds since last change, edit summary): ["Background",235,20060823110052,34,"Typo fixes"]
Format 2: Can just be a get request, using the exact same URL format as per index.php : e.g. GET http://en.wikipedia.org/wiki/edit-status.php?title=User:Nickj/Sandbox
Possible response format from PHP on server for number 3 (in response to GET request #2) is:
# No conflicts: []
# Only one conflict. Fields are: Username, section name, changed characters, timestamp of version editing, seconds since last change, edit summary: [["User:Nickj","Background",235,20060823110052,34,"Typo fixes"]]
# Two conflicts (sorted by seconds since last change?) : [["User:Nickj","Background",235,20060823110052,34,"Typo fixes"],["User:203.15.35.81","",1000,20041112231221,100,"I am a Vandal!"]]
You probably also need a timeout mechanism (e.g. if haven't received a status report from a client in 5 mins, then drop the user from the list), and maybe also a message to inform the server if the user aborts the edit (although they can just click the "back" button, rather than clicking "cancel", in which case you probably won't get the message).
I imagine we would have both a client-side timeout and a server-side timeout. The client-side timeout would be a maximum idle period, it would turn off the periodic updates to prevent excessive resource usage when the user leaves the computer with an edit window open. The server-side timeout would cancel the editing status when the client stops sending messages for whatever reason. The server could also redundantly enforce the maximum idle time. As for cancel buttons: is it possible to send a cancel message asynchronously, without blocking the client from leaving the page?
-- Tim Starling
Tim Starling wrote:
Thanks for that. Can we have the HTML source for it?
The image was based on image-editing a modified screenshot, but the green status table that was added is just a wiki table, which can be got from here: http://en.wikipedia.org/w/index.php?title=User_talk:Nickj/sandbox&oldid=...
For the messages between client JavaScript and the PHP on the server, sounds like maybe there are 3 types of messages:
- A status update when someone starts editing something, or a periodic update as they make changes.
- A method for querying what the current status is of ongoing edits it.
- A response from the server as to what the status of current edits is.
Self-correction: messages 1) and 2) can probably be combined (send your status + request global status) into one get request, for example something like:
GET http://en.wikipedia.org/wiki/index.php?title=PageName&action=statusUpdat... mary=Typo+fixes&revision=20060823110052
The client-side timeout would be a maximum idle period, it would turn off the periodic updates to prevent excessive resource usage when the user leaves the computer with an edit window open. The server-side timeout would cancel the editing status when the client stops sending messages for whatever reason.
Ok, but suppose a user opens an edit window, makes some changes, then the work day ends, then go home but they leave their computer on overnight, and then the following morning (18 hours later) when things get quiet they finish their changes, and hit save. Isn't that qualitatively different from someone who clicks edit, then immediately changes their mind and hits the back button? Shouldn't the 18-hour edit still appear in the status window? Should there perhaps be some kind of back-off mechanism, whereby a status update is sent more regularly at first, and then progressively slower (until a maximum of once per hour is reached, say, at which point there would still be hourly status updates sent to the server). That way you still get updates, but they're not excessive.
Also, the status message could include an indicator of how long the client expects it to be until the next status message (e.g. 5 minutes), assuming the user doesn't type anything (i.e. this figure would be a maximum). That way, the server would not have to work this out [it could just take: min(1 hour, client's figure) + 5 minutes ... the 5 minutes is to allow a bit of leeway ], and store this as a date value in a timeout field, and that way it could have a small timeout for someone that has just started editing a page, and 1 hour 5 minutes timeout for someone who has the window open overnight (i.e. variable timeout windows, instead of a fixed window size).
And here's a different scenario/question: Suppose user-A clicks edit, and makes no changes. Then user-B clicks edit on the same article, makes their changes, and clicks save. Should user-A's edit window reload with the updated wiki source (provided they really have made no changes)? This could be achieved by sending the current revision timestamp with the status messages, and reloading the source if we used to have the latest version (and now don't), and haven't modified the text in the textarea.
And for amusement, if we start sending the current revision timestamp, then there is the potential to create some "interesting" user-interfaces. Suppose you're editing something, and then someone else starts to edit: it could play a sound (like the "uh-oh" sound from ICQ, followed by David Bowie's "Under Pressure") to warn you of an impending potential edit conflict ... and then if they save first, it could play a sound like when Pac-Man gets eaten ("Wah-wah-waa") and display a message in red in the status area like: "You snooze, you lose! Remember: Save first, ask questions later." ... I am joking about this paragraph, of course ;-)
Jay R. Ashworth wrote:
Given the functionality extension of the edit summary, I think perhaps the entire box should be moved up above the textedit window...
Well the downside of putting it above the text area is that as other people start or stop editing the page, the number of rows in the status table will increase or decrease. Now, if the table is above the textarea, this will have the effect of making the whole textarea box jump up or down the page in a potentially quite annoying way :-)
"Hide that I'm editing", and default it to off. The negative connotation will change the default amongst people who don't care in a fashion that will make the feature more useful, while not keeping people who care from switching it.
That's good psychology, I like it.
It should also be possible to set a default in the User Preferences though I think, as per the two other boxes, for which you can currently set a default preference.
Maybe the name of the other user should be shown, and maybe it shouldn't.
I like the summary the way you have it.
Yeah, it just feels more personal & community-orientated to have a name, rather than "some other unidentifiable person is doing something".
Maybe the user's own changes should be shown in the list, maybe they shouldn't.
Perhaps they should; to reinforce to people whether they're visible or not...
Good point.
You probably also need a timeout mechanism (e.g. if haven't received a status report from a client in 5 mins, then drop the user from the list), and maybe also a message to inform the server if the user aborts the edit (although they can just click the "back" button, rather than clicking "cancel", in which case you probably won't get the message).
I think you can trap pageexit, though I'm not positive.
I'm not sure either, although this page http://www.4guysfromrolla.com/demos/OnBeforeUnloadDemo3.htm seems to be able to trap the events that indicate navigating away from the page (could also be useful to Rob Church's for his draft-saving possibility), using window.onbeforeunload (works for me in IE and Firefox), so perhaps we can use that?
All the best, Nick.
On Sat, Aug 26, 2006 at 02:38:57PM +1000, Nick Jenkins wrote:
But to get us started, someone needs to make that UI mockup.
Very draft mock-up of a possible UI, from what I think you're describing: http://files.nickj.org/MediaWiki/ui-draft-mockup.png
Not bad.
Given the functionality extension of the edit summary, I think perhaps the entire box should be moved up above the textedit window... (Specifically, the fact that what you put in the summary will now be visible before you click any buttons (onblur?))
In the picture, the "Notify others of my edit" box should be ticked (since it is shown in the list). Maybe "Notify others of my edit" should labelled "Notify others of my progress"?
"Hide that I'm editing", and default it to off. The negative connotation will change the default amongst people who don't care in a fashion that will make the feature more useful, while not keeping people who care from switching it.
Maybe the name of the other user should be shown, and maybe it shouldn't.
I like the summary the way you have it.
Maybe the user's own changes should be shown in the list, maybe they shouldn't.
Perhaps they should; to reinforce to people whether they're visible or not...
You probably also need a timeout mechanism (e.g. if haven't received a status report from a client in 5 mins, then drop the user from the list), and maybe also a message to inform the server if the user aborts the edit (although they can just click the "back" button, rather than clicking "cancel", in which case you probably won't get the message).
I think you can trap pageexit, though I'm not positive.
Cheers, -- jra
Nick Jenkins wrote:
But to get us started, someone needs to make that UI mockup.
Very draft mock-up of a possible UI, from what I think you're describing: http://files.nickj.org/MediaWiki/ui-draft-mockup.png
If you're going to display the summary line, don't you think it is obviously going to be used by some people to deliberately put inflammatory/aggressive/offensive/provocative text in there, just to annoy other editors?
Timwi
On 28/08/06, Timwi timwi@gmx.net wrote:
If you're going to display the summary line, don't you think it is obviously going to be used by some people to deliberately put inflammatory/aggressive/offensive/provocative text in there, just to annoy other editors?
That happens with existing edit summaries and even entire pages now. No reason to suppress useful functionality just because the Internet is full of dickheads.
Rob Church
After all these 42 messages, is there anybody working on this feature at all?
juca
Dunno about everyone else, but my usual editing sequence goes something like this:
- Make a change
- Type an edit summary and set the watch/minor checkboxes
- Preview
- Save or go back to 1.
Yes, so does everyone's, that's because we don't have an interactive message box to type into. Behaviour will change according to features.
Let me also say this: if your typical editing behaviour is to open the edit box, change some little thing, and save it immediately, then you're one of the culprits of the edit conflict problem. You're the kind of user that the "please don't edit this" message is aimed at. Some users want to spend longer editing and reviewing a change, and they shouldn't be penalised for their extra dedication to correctness.
I'd like the edit conflict to 'rise' on step 3 (preview), sometimes it's not worth even finishing the edit, as someone else has done. What is frustating is writing a some paragraphs (with their previews) only to find an edit conflict with 3 people that ended quite ago. It doesn't need to be anything complex. A line near "This is a preview" saying "This page has been edited" would be enough. It could be expanded to say it was [[User:Foo]], a diff... But the base is being informed that someone already changed it.
wikitech-l@lists.wikimedia.org