%% Not multiple edits on same template %%
I think the edit page sould be more smart. If a user open the same page two times, the second time sould be warned that the page is already opened. This may need some trans-window comunication, that is not something browser love to do, but I guest is possible with DOMStorage/Cookies or something else.
%% Autosave feature for edit %%
Again, in this day and age, losing data because a computer crash is a problem that sould never ocurr. The edit page sould save the latest version of the edited text to a local persistent area ( DOMStorage? ). That way, I can 'accidentally close' the edit page, and wen I reopen the edit, the page sould detect "He.. the page is on the same revision, this mean my edited version is interesting", and let the user continue editing. "You closed the edit page withouth saving. Do you want to continue with the old version?". Somewhat like the "drafts" feature on gmail, or the autosave feature of OpenOffice.
%% Edit in the browser any fileformat wen webeditors for such fileformats are available %%
Wen possible, documents sould be editable inside the browser. This mean as possible, add a SVG editor or a Math editor or a HTML editor or a DOC editor or a PNG editor. The PNG is wrong -> download -> edit -> upload is lame. The PNG is wrong -> edit -> save is cool.
The current edit page only supports wikicode :-(
%% Un-cruft mode %%
There seems to be a lot of "META" information on the wiki, all this metainformation like "stub", etc.. sould be optional. There must be a single checkbox option to disable it all. I don't want to read even 1 more "citation needed" or "this is a stub" bloat. Maybe default sould be to "show cruft".
%% Wikipedia Green, Blue and Orange %%
A way to fight Deletionism, could be to have something like "different levels" on the wikipedia (a wiki). Set a group of pages on "Book Blue", for pages with a maintainer, and pages approved by a superior committee of quality. Set a group of pages on "Green Book" for pages that serve the merits of notability. "Yellow Book" for pages that don't fulfill a notability criteria. Deletionism is binary, computers can work with more values than 1, 0. Hell.. you can make Green Book and Yellow Book invisible for the un-loged users, only available for loged users. For this thing to work, Templates sould use different colors for differents books. Colors will also account for quality. The german will be mostly blue, while others will have more green pages. There will be a wiki with 90.000 green and 10.000 blue. And other one with 10.000 green and 90.000 blue.
%% The Death of Wiki %%
Ultimatelly, al wikis lose the war against entropy and are abandoned. This will hit all wikipedia wikis, and all based on mediawiki. While you can't stop that, you can code something so the resulting dead body of wiki is not pure shit. A possible idea could be to "auto-protect" pages without edit in N years (4 years), and save id of the "last know good version", this can be done flagging the pages as "dirty" after a edit, and flag pages as "clean" wen a logged editor say so. Something like "Page Milestones". Maybe the "History" view of a page sould list first the last 10 milestones (newer first), then the "dump" of all edits. There are probably about more than 10 years to think about this issue.
On Wed, Jan 13, 2010 at 6:42 AM, Tei oscar.vives@gmail.com wrote:
%% Not multiple edits on same template %%
I think the edit page sould be more smart. If a user open the same page two times, the second time sould be warned that the page is already opened. This may need some trans-window comunication, that is not something browser love to do, but I guest is possible with DOMStorage/Cookies or something else.
I don't think there's a reliable way to do this. We can set some type of storage when the user opens an edit page, but we can't reliably unset it when they close the page or navigate away.
%% Autosave feature for edit %%
Again, in this day and age, losing data because a computer crash is a problem that sould never ocurr. The edit page sould save the latest version of the edited text to a local persistent area ( DOMStorage? ). That way, I can 'accidentally close' the edit page, and wen I reopen the edit, the page sould detect "He.. the page is on the same revision, this mean my edited version is interesting", and let the user continue editing. "You closed the edit page withouth saving. Do you want to continue with the old version?". Somewhat like the "drafts" feature on gmail, or the autosave feature of OpenOffice.
We have this in the Drafts extension, don't we? I don't know what its status is.
%% Edit in the browser any fileformat wen webeditors for such fileformats are available %%
Wen possible, documents sould be editable inside the browser. This mean as possible, add a SVG editor or a Math editor or a HTML editor or a DOC editor or a PNG editor. The PNG is wrong -> download -> edit -> upload is lame. The PNG is wrong -> edit -> save is cool.
The current edit page only supports wikicode :-(
This has been talked about before, and would be nice to have, but I don't think there are any polished solutions available right now.
%% Un-cruft mode %%
There seems to be a lot of "META" information on the wiki, all this metainformation like "stub", etc.. sould be optional. There must be a single checkbox option to disable it all. I don't want to read even 1 more "citation needed" or "this is a stub" bloat. Maybe default sould be to "show cruft".
You mean when viewing articles, or editing them? Cutting out cruft when editing is something the usability project is looking into, AFAIK. Cruft while viewing is up to the individual projects, not a technical issue -- tell enwiki to use fewer annoying boxes if you don't like them.
%% Wikipedia Green, Blue and Orange %%
A way to fight Deletionism, could be to have something like "different levels" on the wikipedia (a wiki). Set a group of pages on "Book Blue", for pages with a maintainer, and pages approved by a superior committee of quality. Set a group of pages on "Green Book" for pages that serve the merits of notability. "Yellow Book" for pages that don't fulfill a notability criteria. Deletionism is binary, computers can work with more values than 1, 0. Hell.. you can make Green Book and Yellow Book invisible for the un-loged users, only available for loged users. For this thing to work, Templates sould use different colors for differents books. Colors will also account for quality. The german will be mostly blue, while others will have more green pages. There will be a wiki with 90.000 green and 10.000 blue. And other one with 10.000 green and 90.000 blue.
This would need to be requested by a particular community. We can't force people to keep pages they want to delete.
%% The Death of Wiki %%
Ultimatelly, al wikis lose the war against entropy and are abandoned. This will hit all wikipedia wikis, and all based on mediawiki. While you can't stop that, you can code something so the resulting dead body of wiki is not pure shit. A possible idea could be to "auto-protect" pages without edit in N years (4 years), and save id of the "last know good version", this can be done flagging the pages as "dirty" after a edit, and flag pages as "clean" wen a logged editor say so. Something like "Page Milestones". Maybe the "History" view of a page sould list first the last 10 milestones (newer first), then the "dump" of all edits. There are probably about more than 10 years to think about this issue.
I don't share your pessimism on this issue. But in any event, it would be easy to do this after the fact, since we keep all history, so we don't need to worry about it until it's actually happened.
2010/1/13 Aryeh Gregor Simetrical+wikilist@gmail.com:
We have this in the Drafts extension, don't we? I don't know what its status is.
We at the usability initiative have the intention to integrate that at some point, but no concrete plans yet AFAICT.
%% Un-cruft mode %%
There seems to be a lot of "META" information on the wiki, all this metainformation like "stub", etc.. sould be optional. There must be a single checkbox option to disable it all. I don't want to read even 1 more "citation needed" or "this is a stub" bloat. Maybe default sould be to "show cruft".
You mean when viewing articles, or editing them? Cutting out cruft when editing is something the usability project is looking into, AFAIK.
We're working on that now, yes.
Roan Kattouw (Catrope)
On Wed, Jan 13, 2010 at 7:35 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Wed, Jan 13, 2010 at 6:42 AM, Tei oscar.vives@gmail.com wrote:
%% Not multiple edits on same template %%
I think the edit page sould be more smart. If a user open the same page two times, the second time sould be warned that the page is already opened. This may need some trans-window comunication, that is not something browser love to do, but I guest is possible with DOMStorage/Cookies or something else.
I don't think there's a reliable way to do this. We can set some type of storage when the user opens an edit page, but we can't reliably unset it when they close the page or navigate away.
If there is an autosave type of function, and it is enabled, then one could control for duplicate windows using that communication stream. I actually like the idea of an autosave, but I could see how it might not be a high priority (and could eventually be something of resource hog if people are allowed to leave a lot of uncommitted drafts lying around).
You mean when viewing articles, or editing them? Cutting out cruft when editing is something the usability project is looking into, AFAIK. Cruft while viewing is up to the individual projects, not a technical issue -- tell enwiki to use fewer annoying boxes if you don't like them.
On the viewing side it isn't be hard to banish the [citation needed] tags and message boxes using CSS. I've played around with code for wiki sites I manage to add that sort of functionality (and other related options) as a toggle buttons on the sidebar. I don't know if putting it in the sidebar for everyone would be okay for enwiki, etc., but I'm sure someone could write a gadget to give logged in users the ability to hide the meta-data.
-Robert Rohde
On Wed, Jan 13, 2010 at 4:44 PM, Robert Rohde rarohde@gmail.com wrote:
If there is an autosave type of function, and it is enabled, then one could control for duplicate windows using that communication stream.
I don't see how you could reliably detect whether the other window is still open at the time you raise the warning. It doesn't seem like it would be a very common problem, anyway -- most people don't edit so many pages at once that they wouldn't notice they're editing the same page twice. :)
I actually like the idea of an autosave, but I could see how it might not be a high priority (and could eventually be something of resource hog if people are allowed to leave a lot of uncommitted drafts lying around).
Resource hog in what sense, disk space? I don't think disk space is a big deal. You do know that we keep all the old revisions of articles, right? :P
On Wed, Jan 13, 2010 at 2:51 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
I actually like the idea of an autosave, but I could see how it might not be a high priority (and could eventually be something of resource hog if people are allowed to leave a lot of uncommitted drafts lying around).
Resource hog in what sense, disk space? I don't think disk space is a big deal. You do know that we keep all the old revisions of articles, right? :P
As I recall, someone did an analysis and reported that people click on "edit" more than twice as often as they actually save an edit. If half of all database text were abandoned drafts, that would be dumb. Would WMF come tumbling down if the database doubled in size? Probably not, but it would still be a dumb use of resources. Historically, there has also been opposition to anything that would allow people to store "private" content on Wikipedia. Of course both issues could be dealt with if we just said unsaved drafts expired after a month or something.
-Robert Rohde
On Wed, Jan 13, 2010 at 7:02 PM, Robert Rohde rarohde@gmail.com wrote:
As I recall, someone did an analysis and reported that people click on "edit" more than twice as often as they actually save an edit. If half of all database text were abandoned drafts, that would be dumb. Would WMF come tumbling down if the database doubled in size? Probably not, but it would still be a dumb use of resources.
Hmm, you might be right, if the drafts are saved too aggressively. Expiring them after a while would make sense. Also note, though, that we can save drafts locally in recent browsers (localStorage is even supported in IE8) and avoid pushing them to the server often -- I don't know if Drafts does this or not.
Aryeh Gregor wrote:
On Wed, Jan 13, 2010 at 7:02 PM, Robert Rohde rarohde@gmail.com wrote:
As I recall, someone did an analysis and reported that people click on "edit" more than twice as often as they actually save an edit. If half of all database text were abandoned drafts, that would be dumb. Would WMF come tumbling down if the database doubled in size? Probably not, but it would still be a dumb use of resources.
Hmm, you might be right, if the drafts are saved too aggressively. Expiring them after a while would make sense. Also note, though, that we can save drafts locally in recent browsers (localStorage is even supported in IE8) and avoid pushing them to the server often -- I don't know if Drafts does this or not.
Please note that you can be going to edit just to view/copy the source, not really trying to change it or save a draft.
It didn't use any DOMStorage. It's completely server side. It was cited that the user may want to get the draft from a different computer. Using localStorage was accepted as a nice thing for the wishlist that just hadn't been implemented.
Note that having a localStorage draft would be the only way to save the work if the server goes down or the database read-only (eg. so a slave can catch it).
Robert Rohde wrote:
As I recall, someone did an analysis and reported that people click on "edit" more than twice as often as they actually save an edit.
It might be useful to save every "preview" at the server as a "personal draft", a new version of the the page [[Special:Draft]], visible only to that user and that only remembers the 100 last versions of whatever that user previewed (or diffed) during edit.
The performance issue would be small, since the server already has to handle traffic in and out for each preview.
This would be a low-tech approach to auto-saving, one that involves the user more and doesn't use any magic background Javascript.
On 2010-01-13, Tei wrote:
%% The Death of Wiki %%
Ultimatelly, al wikis lose the war against entropy and are abandoned. This will hit all wikipedia wikis, and all based on mediawiki. While you can't stop that, you can code something so the resulting dead body of wiki is not pure shit. A possible idea could be to "auto-protect" pages without edit in N years (4 years), and save id of the "last know good version", this can be done flagging the pages as "dirty" after a edit, and flag pages as "clean" wen a logged editor say so. Something like "Page Milestones". Maybe the "History" view of a page sould list first the last 10 milestones (newer first), then the "dump" of all edits. There are probably about more than 10 years to think about this issue.
The AbsenteeLandlord extension may fulfil this to a certain extent. [1]
[1] http://www.mediawiki.org/wiki/Extension:AbsenteeLandlord
Robert
2010/1/13 Robert Leverington robert@rhl.me.uk:
On 2010-01-13, Tei wrote:
%% The Death of Wiki %%
...
you can't stop that, you can code something so the resulting dead body of wiki is not pure shit. A possible idea could be to "auto-protect" pages without edit in N years (4 years),
...
The AbsenteeLandlord extension may fulfil this to a certain extent. [1]
[1] http://www.mediawiki.org/wiki/Extension:AbsenteeLandlord
I am happy, I am not the first one to think about these issues.
wikitech-l@lists.wikimedia.org