Ok, things are finally starting to normalize as far as getting away from fundraiser craziness, preparing regular releases, and generally getting on with making things better for users!
I've enabled the Drafts extension for testing on http://test.wikipedia.org -- this little cutie was new staff dev Trevor Parscal's first assignment here, but deployment got pushed back when we went full-steam on fundraiser banner stuff.
I've written up a quickie blog post with some purty screen shots:
http://leuksman.com/log/2009/01/16/drafts-extension-enabled-on-test-wikipedi...
Suggestions for improvements to the UI and workflow are always welcome!
-- brion
Great! Share a Wikipedia account with friends/conspirators/fellow terrorists, and leave them secret messages on Wikipedia that only they can read. And it will self-destruct after a month! I can see Jack Bauer coming through the door in 3, 2, 1... ;-)
Magnus
On Sat, Jan 17, 2009 at 12:38 AM, Brion Vibber brion@wikimedia.org wrote:
Ok, things are finally starting to normalize as far as getting away from fundraiser craziness, preparing regular releases, and generally getting on with making things better for users!
I've enabled the Drafts extension for testing on http://test.wikipedia.org -- this little cutie was new staff dev Trevor Parscal's first assignment here, but deployment got pushed back when we went full-steam on fundraiser banner stuff.
I've written up a quickie blog post with some purty screen shots:
http://leuksman.com/log/2009/01/16/drafts-extension-enabled-on-test-wikipedi...
Suggestions for improvements to the UI and workflow are always welcome!
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
can't save summary?
2009/1/18 Magnus Manske magnusmanske@googlemail.com
Great! Share a Wikipedia account with friends/conspirators/fellow terrorists, and leave them secret messages on Wikipedia that only they can read. And it will self-destruct after a month! I can see Jack Bauer coming through the door in 3, 2, 1... ;-)
Magnus
On Sat, Jan 17, 2009 at 12:38 AM, Brion Vibber brion@wikimedia.org wrote:
Ok, things are finally starting to normalize as far as getting away from fundraiser craziness, preparing regular releases, and generally getting on with making things better for users!
I've enabled the Drafts extension for testing on http://test.wikipedia.org -- this little cutie was new staff dev Trevor Parscal's first assignment here, but deployment got pushed back when we went full-steam on fundraiser banner stuff.
I've written up a quickie blog post with some purty screen shots:
http://leuksman.com/log/2009/01/16/drafts-extension-enabled-on-test-wikipedi...
Suggestions for improvements to the UI and workflow are always welcome!
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Jan 17, 2009 at 11:00 AM, Magnus Manske magnusmanske@googlemail.com wrote:
Great! Share a Wikipedia account with friends/conspirators/fellow terrorists, and leave them secret messages on Wikipedia that only they can read. And it will self-destruct after a month! I can see Jack Bauer coming through the door in 3, 2, 1... ;-)
Meh. People have already smuggled content in commons uploads unnoticed for enormous spans of time... this seems less harmful (and given the size limits, less useful)
Although the problem could be avoided for drafts by using browser local storage for the data, or requiring some cookie as a key.
On Sat, Jan 17, 2009 at 9:50 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
Although the problem could be avoided for drafts by using browser local storage for the data, or requiring some cookie as a key.
Which kind of kills the "save progress at home and continue at work" use-case, for no very good reason. I don't think we care if people use Wikipedia as a private datastore. If they really felt like it, they could dump stuff somewhere in their preferences, their signature or something (do we actually validate that 255-char limit on the server side?). When people make a WikipediaDraftFS, then we can start to take action.
On Sun, Jan 18, 2009 at 4:03 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
do we actually validate that 255-char limit on the server side?
Yes, at least MySQL forces us to AFAIR. Anyway, you can bypass it by creating e.g. User:XY/sig.js and then put {{subst:User:XY/sig.js}} in your signature field.
Marco
On Sun, Jan 18, 2009 at 5:56 AM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
Yes, at least MySQL forces us to AFAIR.
No, the sig is just part of user_options, which is a BLOB. However, we do validate the length in SpecialPreferences.php.
Anyway, you can bypass it by creating e.g. User:XY/sig.js and then put {{subst:User:XY/sig.js}} in your signature field.
My point was that you could store information *privately* already. But it really doesn't matter, since we have no reason to care if a few people use drafts to save private info.
After trying it out on testwikipedia, I am very impressed. This is a feature I have long been waiting for, and it's finally a reality. :) Is there an estimate as to when this may go live on WMF servers?
Soxred93/X!
On Jan 16, 2009, at 7:38 PM [Jan 16, 2009 ], Brion Vibber wrote:
Ok, things are finally starting to normalize as far as getting away from fundraiser craziness, preparing regular releases, and generally getting on with making things better for users!
I've enabled the Drafts extension for testing on http://test.wikipedia.org -- this little cutie was new staff dev Trevor Parscal's first assignment here, but deployment got pushed back when we went full-steam on fundraiser banner stuff.
I've written up a quickie blog post with some purty screen shots:
http://leuksman.com/log/2009/01/16/drafts-extension-enabled-on-test- wikipedia/
Suggestions for improvements to the UI and workflow are always welcome!
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Jan 17, 2009 at 10:16 PM, Soxred93 soxred93@gmail.com wrote:
After trying it out on testwikipedia, I am very impressed. This is a feature I have long been waiting for, and it's finally a reality. :) Is there an estimate as to when this may go live on WMF servers?
per brion in previous issues: "when it's ready"? :-)
wikitech-l-bounces@lists.wikimedia.org wrote on 17/01/2009 00:38:38:
Ok, things are finally starting to normalize as far as getting away from
fundraiser craziness, preparing regular releases, and generally getting on with making things better for users!
I've enabled the Drafts extension for testing on http://test.wikipedia.org -- this little cutie was new staff dev Trevor Parscal's first assignment here, but deployment got pushed back when we went full-steam on fundraiser banner stuff.
I've written up a quickie blog post with some purty screen shots:
http://leuksman.com/log/2009/01/16/drafts-extension-enabled-on-test-wikipedi...
Suggestions for improvements to the UI and workflow are always welcome!
Is there an API for getting/saving the draft edits?
On Jan 20, 2009, at 2:15, Jim Higson Jim.Higson@admin.ox.ac.uk wrote:
wikitech-l-bounces@lists.wikimedia.org wrote on 17/01/2009 00:38:38:
Suggestions for improvements to the UI and workflow are always welcome!
Is there an API for getting/saving the draft edits?
Not currently, but that'd be a great thing to have for third-party editing tools.
-- Brion
-- Jim Higson Web CMS Developer BSP, University of Oxford tel: 01865 2 80691
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Brion Vibber schreef:
On Jan 20, 2009, at 2:15, Jim Higson Jim.Higson@admin.ox.ac.uk wrote:
wikitech-l-bounces@lists.wikimedia.org wrote on 17/01/2009 00:38:38:
Suggestions for improvements to the UI and workflow are always welcome!
Is there an API for getting/saving the draft edits?
Not currently, but that'd be a great thing to have for third-party editing tools.
I'll put it on my TODO list, which means I hope to finish it this month (my TODO list has grown considerably lately).
Roan Kattouw (Catrope)
wikitech-l-bounces@lists.wikimedia.org wrote on 20/01/2009 18:10:47:
Brion Vibber schreef:
Suggestions for improvements to the UI and workflow are always welcome!
Is there an API for getting/saving the draft edits?
Not currently, but that'd be a great thing to have for third-party editing tools.
That's what I was thinking (since I'm working on such a tool, I tend to ask myself with every new feature "how could I work this in?")
For example, I might start a large edit from a browser at work, decide I need to look some things up first, go home and fire up an external editor. It'd be neat if my drafts were automatically loaded for me.
I'll put it on my TODO list, which means I hope to finish it this month (my TODO list has grown considerably lately).
Excellent. Thank you :-)
It seems to me that the Drafts extension provides a neat feature with the potential to save data from being lost by accident in many cases. It also seems like adding a per-user setting to enable/disable it would be trivial and also useful for the few (or perhaps many) users who may find it worth disabling. Additionally the addition of a disable / enable setting would not detract from the features or fuxtionality of the extension. Finally it may be less offensive, especially to our avid contributors, to add a new optional feature rather than a mandatory one.
Since the features of the extension are disabled for unregistered users already, adding such a setting would truly be a matter of adding a few more lines of code in a few very obvious places.
Additionally it may be useful (or at least interesting) to be able to study the statistics of how many / what kind of editors really do disable the extension - as it may be a fair metric on how likely different kinds of users are to accept (or reject) modifications to the editing process. These studies may help to make future feature enhancements more successful and less alienating.
Does anyone actually object to the addition of a disable drafts feature?
- Trevor
On Tue, Jan 20, 2009 at 1:49 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Since the features of the extension are disabled for unregistered users already
Is this a design decision, or just to simplify implementation? You could use a cookie or something, but if you did that you'd have to make sure Squid doesn't serve pages differently because of it.
Does anyone actually object to the addition of a disable drafts feature?
Yes. For virtually any feature imaginable, there will be some minority of users who don't like it. That does not imply that we should add a user preference to disable every single feature we add. Every extra user preference clutters up the user preferences screen, making it harder to use; and adds more code paths, making bugs harder to track down.
In this case, as far as I can tell, the only thing disabling the feature for a given user would do is hide one button from the UI. We already have a mechanism by which users can do things like that if they really care: they can use a CSS rule in their user stylesheet. Or, they could just ignore the button, which doesn't seem like an excessive hardship. If the extension is adding lots of annoying interface elements when the user actually has no drafts saved, that's possibly a problem that should be fixed for all users of the extension.
Aryeh Gregor wrote:
On Tue, Jan 20, 2009 at 1:49 PM, Trevor Parscal tparscal@wikimedia.org wrote:
Since the features of the extension are disabled for unregistered users already
Is this a design decision, or just to simplify implementation? You could use a cookie or something, but if you did that you'd have to make sure Squid doesn't serve pages differently because of it.
I don't think it would be wise to add that for anonymous users. People could be seeing drafts from other people and we would be unable to assist or even verify reports of things that people see that their coworkers are writing.
They could benefit from drafts, but in that case better to do it on the browser itself. IMHO we still need some kind of saving into firefox storage, for cases like a read-only db. Instead of 'You can't save, the site is read-only'->'Save-draft'->'No, you can't, the db is read-only', 'You can't save, the site is read-only'->'Save-draft'->'The site is read-only, the draft has been saved into your browser'.
A completely different approach could be to allow anyone to view other's drafts. As a new feature, it could be accepted as it is, without treating it as a completely privacy section. Normal wikipedians won't mind of people seeing the article as they're writing in. However, the auto-save-draft may conflict with it.
BTW, the discard link should go via $wgScriptPath not $wgArticlePath Doing this could lead to eg. search ngines following those links (although not likely to cause problems for *this* extension)
On Tue, Jan 20, 2009 at 4:40 PM, Platonides Platonides@gmail.com wrote:
I don't think it would be wise to add that for anonymous users. People could be seeing drafts from other people and we would be unable to assist or even verify reports of things that people see that their coworkers are writing.
So?
They could benefit from drafts, but in that case better to do it on the browser itself.
I don't see a practical difference between that and using cookies here (except, e.g., DB read-only).
IMHO we still need some kind of saving into firefox storage, for cases like a read-only db. Instead of 'You can't save, the site is read-only'->'Save-draft'->'No, you can't, the db is read-only', 'You can't save, the site is read-only'->'Save-draft'->'The site is read-only, the draft has been saved into your browser'.
This can be done in cutting-edge browsers using HTML5's localStorage and sessionStorage.
A completely different approach could be to allow anyone to view other's drafts. As a new feature, it could be accepted as it is, without treating it as a completely privacy section. Normal wikipedians won't mind of people seeing the article as they're writing in. However, the auto-save-draft may conflict with it.
I'd be completely behind this, now that you mention it. It's like how we don't allow private discussions between users (except by e-mail, okay). We should be encouraging transparency at every step of using the software.
On Tue, Jan 20, 2009 at 11:35 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Tue, Jan 20, 2009 at 4:40 PM, Platonides Platonides@gmail.com wrote:
IMHO we still need some kind of saving into firefox storage, for cases like a read-only db. Instead of 'You can't save, the site is read-only'->'Save-draft'->'No, you can't, the db is read-only', 'You can't save, the site is read-only'->'Save-draft'->'The site is read-only, the draft has been saved into your browser'.
This can be done in cutting-edge browsers using HTML5's localStorage and sessionStorage.
What about Google Gears? Yeah, it's Google, but GG supports a variety of browsers and we wouldn't have to wait for M$ to support it properly in IE 20.
Marco
On Wed, Jan 21, 2009 at 8:34 AM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
What about Google Gears? Yeah, it's Google, but GG supports a variety of browsers and we wouldn't have to wait for M$ to support it properly in IE 20.
IE8b2 already supports localStorage, from what I've heard, more or less according to spec. The problem is legacy browsers. These will have to be handled somehow regardless of whether people install Gears, since we can't expect many people to install Gears. The extra effort to implement three different ways of doing things (localStorage + Gears + legacy fallback) isn't worth it: the number of people with Gears but not localStorage is probably very small.
Since Gears is open-source, there should be no principled problem with using it. (I'm not sure why you think anyone would object on the basis that Google makes it -- would you expect objections to use of MySQL or Java because Sun makes those, or YUI because Yahoo! makes it?) But pragmatically, I doubt it has enough market adoption to be worth supporting.
On 1/20/09 1:40 PM, Platonides wrote:
They could benefit from drafts, but in that case better to do it on the browser itself. IMHO we still need some kind of saving into firefox storage, for cases like a read-only db. Instead of 'You can't save, the site is read-only'->'Save-draft'->'No, you can't, the db is read-only', 'You can't save, the site is read-only'->'Save-draft'->'The site is read-only, the draft has been saved into your browser'.
Client-side storage would be fantastic (and avoid unnecessary server round-trips). We discussed this in original planning but didn't get round to implementing it yet.
A completely different approach could be to allow anyone to view other's drafts. As a new feature, it could be accepted as it is, without treating it as a completely privacy section. Normal wikipedians won't mind of people seeing the article as they're writing in. However, the auto-save-draft may conflict with it.
I wouldn't be comfortable with that, especially for discussion pages. I also wouldn't be comfortable with my e-mail client showing everybody my drafts of my e-mails...
I'm sure I'm not the only one who sometimes writes things they delete for a very good reason before pushing save. ;)
-- brion
Brion Vibber wrote:
Client-side storage would be fantastic (and avoid unnecessary server round-trips). We discussed this in original planning but didn't get round to implementing it yet.
I thought the rationale was to allow people to migrate browsers. Still, choosing the kind of draft-saving from several storages seems a better preference as just 'do you want drafts', if finally gets to the preference system.
A completely different approach could be to allow anyone to view other's drafts. As a new feature, it could be accepted as it is, without treating it as a completely privacy section. Normal wikipedians won't mind of people seeing the article as they're writing in. However, the auto-save-draft may conflict with it.
I wouldn't be comfortable with that, especially for discussion pages. I also wouldn't be comfortable with my e-mail client showing everybody my drafts of my e-mails...
I'm sure I'm not the only one who sometimes writes things they delete for a very good reason before pushing save. ;)
-- brion
Hehehe, that's why I predicted problems with auto-saving. Pressing Save draft, you may well understand that others may see it. If it was saved when previewing or by auto-save, not so much.
I only thought about articles, but you're right you may want to draft an angry response to a discussion. And having the other participants sniffing on your arguments is not a good idea.
On 1/20/09 3:14 PM, Platonides wrote:
Brion Vibber wrote:
Client-side storage would be fantastic (and avoid unnecessary server round-trips). We discussed this in original planning but didn't get round to implementing it yet.
I thought the rationale was to allow people to migrate browsers.
Not specifically, though that can be a useful aspect of server-side draft storage.
-- brion
On Tue, Jan 20, 2009 at 2:49 PM, Brion Vibber brion@wikimedia.org wrote:
On 1/20/09 1:40 PM, Platonides wrote:
They could benefit from drafts, but in that case better to do it on the browser itself. IMHO we still need some kind of saving into firefox storage, for cases like a read-only db. Instead of 'You can't save, the site is read-only'->'Save-draft'->'No, you can't, the db is read-only', 'You can't save, the site is read-only'->'Save-draft'->'The site is read-only, the draft has been saved into your browser'.
Client-side storage would be fantastic (and avoid unnecessary server round-trips). We discussed this in original planning but didn't get round to implementing it yet.
Surely plenty of people want to work on drafts from home at work?
Of course, we shouldn't be editing Wikipedia at work, should we? ;-)
On Tue, Jan 20, 2009 at 6:21 PM, Andrew Garrett andrew@epstone.net wrote:
Of course, we shouldn't be editing Wikipedia at work, should we? ;-)
Hey, could be during lunch break. Not our business. ;)
Brion Vibber wrote:
On 1/20/09 1:40 PM, Platonides wrote:
They could benefit from drafts, but in that case better to do it on the browser itself. IMHO we still need some kind of saving into firefox storage, for cases like a read-only db. Instead of 'You can't save, the site is read-only'->'Save-draft'->'No, you can't, the db is read-only', 'You can't save, the site is read-only'->'Save-draft'->'The site is read-only, the draft has been saved into your browser'.
Client-side storage would be fantastic (and avoid unnecessary server round-trips). We discussed this in original planning but didn't get round to implementing it yet.
A completely different approach could be to allow anyone to view other's drafts. As a new feature, it could be accepted as it is, without treating it as a completely privacy section. Normal wikipedians won't mind of people seeing the article as they're writing in. However, the auto-save-draft may conflict with it.
I wouldn't be comfortable with that, especially for discussion pages. I also wouldn't be comfortable with my e-mail client showing everybody my drafts of my e-mails...
I'm sure I'm not the only one who sometimes writes things they delete for a very good reason before pushing save. ;)
This is also open as https://bugzilla.wikimedia.org/show_bug.cgi?id=17087
A possible option would be to have a checkbox (probably on Special:Drafts itself, to avoid cluttering the edit page and to avoid accidental clicks) to mark drafts as public. This would be especially useful when combined with bug 17067, the ability to create drafts of protected pages, a user could make a draft, mark it as public, then link to it for an admin to add to the page.
Alex wrote:
A possible option would be to have a checkbox (probably on Special:Drafts itself, to avoid cluttering the edit page and to avoid accidental clicks) to mark drafts as public. This would be especially useful when combined with bug 17067, the ability to create drafts of protected pages, a user could make a draft, mark it as public, then link to it for an admin to add to the page.
I worry it goes beyond what Drafts attempted to do. So now you start having queues of Drafts, someone seeing the public draft shouldn't delete others drafts when saving, but perhaps the original draft should be marked as 'Foo did an edit from this'. Should the history mark the draft author somewhere?
Welcome to the Wikimedia developer life, Trevor.
:)
Hi,There seems to be an issue with the extension: It seems when I saved a draft after editing a section, the draft was considered a draft of the corresponding section number (it was mentioned as "Article#Section name" in the list of drafts). If the given section was removed, clicking on this saved draft I received the error that "section number 6 doesn't exist", and thus it could not restore the draft. Changing the page, to again contain at least 6 sections, restoring the draft was possible, at the cost of removing the new section that has replaced it.
I believe that this is not really user friendly, even if this is intended behaviour. (You click on a named section and receive a raw number (of the section) in the error message; without any help message or the possibility to restore the text of your draft is someone changes the page in the mean time in an unexpected way).
Best regards, Bence Damokos
On Wed, Jan 21, 2009 at 7:26 PM, Platonides Platonides@gmail.com wrote:
Alex wrote:
A possible option would be to have a checkbox (probably on Special:Drafts itself, to avoid cluttering the edit page and to avoid accidental clicks) to mark drafts as public. This would be especially useful when combined with bug 17067, the ability to create drafts of protected pages, a user could make a draft, mark it as public, then link to it for an admin to add to the page.
I worry it goes beyond what Drafts attempted to do. So now you start having queues of Drafts, someone seeing the public draft shouldn't delete others drafts when saving, but perhaps the original draft should be marked as 'Foo did an edit from this'. Should the history mark the draft author somewhere?
Welcome to the Wikimedia developer life, Trevor.
:)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org