Ok, you know what I'm talking about: "You have new messages (last change)."
My question/proposal is this: how difficult would it be, from a technical POV, to change "(last change)" to "(previous change)". In other words, I'm proposing this change:
CURRENT: (1) the software knows when a user has last visited their own talk page (conventional name: DATE:LASTVISIT) (2) the software knows when a user's own talk page has been modified last (conventional name: DATE:LASTCHANGE) (3) on each page access, the software compares DATE:LASTVISIT with DATE:LASTCHANGE, and if the last change is more recent than the last visit, it offers two links: one straight to the user's talk page, and the second to a diff between the current and the previous version of the user's talk page
PROPOSAL: (1) no change (2) no change (3) no change, except the second link would be pointing to a diff between the current version and the version just before DATE:LASTVISIT, whenever that might be.
The pragmatic advantage to this change would be that people could actually notice ALL changes in their talk pages between their previous and the current visit (as opposed to the current implementation, which only shows the last change, which is a pretty arbitrary metric). And technically I can't see any cost (except for the cost associated with the actual changes in the code, of course) -- but I might be wrong.
What do you think?
Gutza
There is something like this in one of the popup scripts on the English Wikipeda; it may be Lupin's - I'm not sure - which shows "all changes since your last edit". Perhaps this could be adapted or implemented as you suggest.
On 20/01/2008, Gutza gutza@moongate.ro wrote:
Ok, you know what I'm talking about: "You have new messages (last change)."
My question/proposal is this: how difficult would it be, from a technical POV, to change "(last change)" to "(previous change)". In other words, I'm proposing this change:
CURRENT: (1) the software knows when a user has last visited their own talk page (conventional name: DATE:LASTVISIT) (2) the software knows when a user's own talk page has been modified last (conventional name: DATE:LASTCHANGE) (3) on each page access, the software compares DATE:LASTVISIT with DATE:LASTCHANGE, and if the last change is more recent than the last visit, it offers two links: one straight to the user's talk page, and the second to a diff between the current and the previous version of the user's talk page
PROPOSAL: (1) no change (2) no change (3) no change, except the second link would be pointing to a diff between the current version and the version just before DATE:LASTVISIT, whenever that might be.
The pragmatic advantage to this change would be that people could actually notice ALL changes in their talk pages between their previous and the current visit (as opposed to the current implementation, which only shows the last change, which is a pretty arbitrary metric). And technically I can't see any cost (except for the cost associated with the actual changes in the code, of course) -- but I might be wrong.
What do you think?
Gutza
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Gary,
On a superficial analysis (which is all I can do, since I don't know which specific tool you're talking about) I estimate that a JavaScript solution would be much more costly (i.e. much more demanding on the servers) than a native solution. As far as I can (theoretically) tell, a JS solution would involve a juicy piece of AJAX -- as such, it would have to make entirely new, unjustified requests toward the server in order to find the previous edit on the user's talk page. Had this been implemented natively, the whole of that request could be replaced by a single SQL query. But then again, this is only an outsider's assessment, maybe things are more/less complicated than I'm estimating.
Cheers, Gutza
Gary Kirk wrote:
There is something like this in one of the popup scripts on the English Wikipeda; it may be Lupin's - I'm not sure - which shows "all changes since your last edit". Perhaps this could be adapted or implemented as you suggest.
Hello,
JavaScript could update cookies when a user view his own talk page, so this functionality could be done with no requests to the server.
On Jan 20, 2008 12:16 AM, Jesse Martin (Pathoschild) pathoschild@gmail.com wrote:
JavaScript could update cookies when a user view his own talk page, so this functionality could be done with no requests to the server.
This is an excellent example of what JavaScript should *not* be used to do, if at all possible.
Roan Kattouw schreef:
That can be done in core, I'll try to implement it today.
I looked more closely, and it turns out it'll require a schema change. Requested feature at bug 12701 [1], please direct further discussion there.
Roan Kattouw (Catrope)
On Jan 19, 2008 8:48 PM, Gutza gutza@moongate.ro wrote:
PROPOSAL: (1) no change (2) no change (3) no change, except the second link would be pointing to a diff between the current version and the version just before DATE:LASTVISIT, whenever that might be.
I like this idea a lot, especially if the software is already storing the last viewed revision somewhere. File a bug report for it.
--Andrew Whitworth
Andrew Whitworth schreef:
I like this idea a lot, especially if the software is already storing the last viewed revision somewhere. File a bug report for it.
Filed yesterdag, bug 12701. The last viewed revision is *not* stored anywhere (yet), however.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org