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:
> 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.
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=statusUpda…
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.
