Want to collaborate on writing a feature?

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Want to collaborate on writing a feature?

Platonides
>> 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.
>
> 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 mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Want to collaborate on writing a feature?

Nick Jenkins
In reply to this post by Simetrical
> On 8/26/06, Ligulem <[hidden email]> 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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Want to collaborate on writing a feature?

Nick Jenkins
In reply to this post by 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=72279462

> > 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=statusUpdate&section=SectionName&lastChange=34&charsChanged=235&editSum
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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Want to collaborate on writing a feature?

Arne 'Timwi' Heizmann
In reply to this post by Nick Jenkins
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Want to collaborate on writing a feature?

Rob Church
On 28/08/06, Timwi <[hidden email]> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Want to collaborate on writing a feature?

Felipe Sanches
After all these 42 messages, is there anybody working on this feature at all?

juca
_______________________________________________
Wikitech-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
123