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.