-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For a long time we've had to suffer with an image upload form which was pretty bare-bones, while attempting to shoehorn more smarts into it through templates and JavaScript hacks.
Well, I think it's about time we prioritize really doing this thing right. Commons, and MediaWiki generally, needs an upload form which:
a) Works sensibly
b) Looks good
c) Allows you to upload the file, extract metadata, compare duplicates, make sure it's sensibly named, and *then* commit it into the system.
d) Handles batch uploads with a minimum of fuss (or at least, as minimally fussy as one can get with HTML file upload forms :)
Note that this isn't going to be done by tacking JavaScript and templates onto the existing form; this is going to be a real effort to redesign it from scratch into something that handles today's actual needs.
I'd appreciate hearing from people interested in helping out in the following capacities:
* Designing user interface mockups * Helping code it up in MediaWiki * Testing the new form under development * Providing constructive criticism as we work
This effort will probably take from a few weeks to a few months to get to the point where it's really live; we may even try experiments like having the old and new forms available side-by-side on the live site so people really have a chance to bang at it in real usage without forcing an in-flux test system on everyone.
- -- brion vibber (brion @ wikimedia.org)
On Thu, May 29, 2008 at 9:48 PM, Brion Vibber brion@wikimedia.org wrote:
- Designing user interface mockups
- Helping code it up in MediaWiki
Here to help :) I am of course a programmer, so other people better do the interface design ;)
- Testing the new form under development
- Providing constructive criticism as we work
This effort will probably take from a few weeks to a few months to get to the point where it's really live; we may even try experiments like having the old and new forms available side-by-side on the live site so people really have a chance to bang at it in real usage without forcing an in-flux test system on everyone.
While we are at it, it might be nice to do some things that are currently not possible with the PHP/HTML/JS combination: * Upload many files at once * Show status indication * Do a client site duplication check via SHA1. We might want an optional java applet for that.
Also while we're at it, increasing the upload limit would be greatly appreciated.
Bryan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bryan Tong Minh wrote:
On Thu, May 29, 2008 at 9:48 PM, Brion Vibber brion@wikimedia.org wrote:
- Designing user interface mockups
- Helping code it up in MediaWiki
Here to help :) I am of course a programmer, so other people better do the interface design ;)
:D
While we are at it, it might be nice to do some things that are currently not possible with the PHP/HTML/JS combination:
- Upload many files at once
You can upload multiple files on one form by adding more upload controls, but you still have to select them one-by-one. It's a compromise...
See Flickr's "basic" upload form for an example: http://www.flickr.com/photos/upload/basic/
- Show status indication
Status indication in theory should be possible with PHP 5.2...
- Do a client site duplication check via SHA1.
We might want an optional java applet for that.
Java upload applets are a pain in the butt, IMHO; you have to click through a "signed applet" warning then wait for Java to load. Ick!
WordPress 2.5 uses an optional Flash widget for streamlining uploads, which seems cute, but that brings in the whole flash/gnash/whatever morass. :D
I also recommend looking at Flickr and Ebay's current upload systems, if just to get an idea what else is out there. Both I believe are using Flash for their enhanced stuff to allow multiple selection and in-line submission.
As for duplication checks; at a minimum we can do a server-side hash check after physical upload but before committing the file into the wiki; in page editing terms, while still "previewing" it before "saving" it.
Also while we're at it, increasing the upload limit would be greatly appreciated.
When disk space is expanded... machines are on their way... :)
- -- brion
On Thu, May 29, 2008 at 10:13 PM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bryan Tong Minh wrote:
On Thu, May 29, 2008 at 9:48 PM, Brion Vibber brion@wikimedia.org wrote:
- Designing user interface mockups
- Helping code it up in MediaWiki
Here to help :) I am of course a programmer, so other people better do the interface design ;)
:D
While we are at it, it might be nice to do some things that are currently not possible with the PHP/HTML/JS combination:
- Upload many files at once
You can upload multiple files on one form by adding more upload controls, but you still have to select them one-by-one. It's a compromise...
See Flickr's "basic" upload form for an example: http://www.flickr.com/photos/upload/basic/
- Show status indication
Status indication in theory should be possible with PHP 5.2...
- Do a client site duplication check via SHA1.
We might want an optional java applet for that.
Java upload applets are a pain in the butt, IMHO; you have to click through a "signed applet" warning then wait for Java to load. Ick!
WordPress 2.5 uses an optional Flash widget for streamlining uploads, which seems cute, but that brings in the whole flash/gnash/whatever morass. :D
Oh yeah I like those Flash system, but ZOMG unfree11!! stuff will popup.
I also recommend looking at Flickr and Ebay's current upload systems, if just to get an idea what else is out there. Both I believe are using Flash for their enhanced stuff to allow multiple selection and in-line submission.
As for duplication checks; at a minimum we can do a server-side hash check after physical upload but before committing the file into the wiki; in page editing terms, while still "previewing" it before "saving" it.
It kinda sucks to upload 5M and then getting a warning. I'd rather have it before. Also HTTP is not the most convenient upload protocol. FTP similarly to sf's old file release system could be handy
Also while we're at it, increasing the upload limit would be greatly appreciated.
When disk space is expanded... machines are on their way... :)
Yaay!
Bryan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bryan Tong Minh wrote:
On Thu, May 29, 2008 at 10:13 PM, Brion Vibber brion@wikimedia.org wrote:
As for duplication checks; at a minimum we can do a server-side hash check after physical upload but before committing the file into the wiki; in page editing terms, while still "previewing" it before "saving" it.
It kinda sucks to upload 5M and then getting a warning. I'd rather have it before.
Well, I'd rather have it *immediately* on upload than wait until some admin sees it, deletes it, cleans up my five uses of it, and scolds me for the duplicate upload. :)
Also HTTP is not the most convenient upload protocol. FTP similarly to sf's old file release system could be handy
We need to concentrate on what people can do in a regular web browser with no custom software available.
Power tools for power users can be neat too, but effort should be concentrated on what 99% of contributors are going to be using both their first time and most of the time afterwards.
- -- brion vibber (brion @ wikimedia.org)
Bryan Tong Minh wrote:
Java upload applets are a pain in the butt, IMHO; you have to click through a "signed applet" warning then wait for Java to load. Ick!
WordPress 2.5 uses an optional Flash widget for streamlining uploads, which seems cute, but that brings in the whole flash/gnash/whatever morass. :D
Oh yeah I like those Flash system, but ZOMG unfree11!! stuff will popup.
Today I was seeing how the upload form of http://www.virustotal.com/ was showing the percentage of file uploaded. Seems AJAX or similar Web 2.0. IMHO viewing a measure of how we're slowly still sending it would be appreciated. Big files means a lot of time with a blank page being loaded (sending the post data).
On Thu, May 29, 2008 at 9:48 PM, Brion Vibber brion@wikimedia.org wrote:
- Designing user interface mockups
I would definitely be willing to help with this, the Commons upload form has been something i have been looking at for a long time on how things could be improved, and was one of the main reasons for starting the Wikiportrait project (see http://meta.wikimedia.org/wiki/Wikiportrait and www.wikiportret.nl for a demo, only in Dutch right now).
In my opinion, the choice of a license would also be something that has to be a part of the improved upload form.
Currently i'm a little busy (i will be moving places next weekend), but after that i'm sure that i can find some time to make some Photoshop / HTML mockups.
-- Hay / [[User:Husky]]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Husky wrote:
On Thu, May 29, 2008 at 9:48 PM, Brion Vibber brion@wikimedia.org wrote:
- Designing user interface mockups
I would definitely be willing to help with this, the Commons upload form has been something i have been looking at for a long time on how things could be improved, and was one of the main reasons for starting the Wikiportrait project (see http://meta.wikimedia.org/wiki/Wikiportrait and www.wikiportret.nl for a demo, only in Dutch right now).
In my opinion, the choice of a license would also be something that has to be a part of the improved upload form.
Currently i'm a little busy (i will be moving places next weekend), but after that i'm sure that i can find some time to make some Photoshop / HTML mockups.
Awesome, welcome aboard. :D
- -- brion
On Thu, May 29, 2008 at 8:48 PM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For a long time we've had to suffer with an image upload form which was pretty bare-bones, while attempting to shoehorn more smarts into it through templates and JavaScript hacks.
Well, I think it's about time we prioritize really doing this thing right. Commons, and MediaWiki generally, needs an upload form which:
a) Works sensibly
b) Looks good
c) Allows you to upload the file, extract metadata, compare duplicates, make sure it's sensibly named, and *then* commit it into the system.
d) Handles batch uploads with a minimum of fuss (or at least, as minimally fussy as one can get with HTML file upload forms :)
There you go : http://toolserver.org/~magnus/upstart/
Just a quick mockup hack but basically a) and d) covered, and has obvious room for c) I'm not good with the b, though...
Magnus
On Thu, May 29, 2008 at 9:48 PM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For a long time we've had to suffer with an image upload form which was pretty bare-bones, while attempting to shoehorn more smarts into it through templates and JavaScript hacks.
Something to do is split the upload logic from UploadForm into a separate upload class. Furthermore we should be able to make multiple customizable upload forms without having to resolve to uselang= hacks.
I started writing stuff on http://www.mediawiki.org/wiki/Upload_form_changes; everybody feel free to ammend
Bryan
2008/5/30 Brion Vibber brion@wikimedia.org:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For a long time we've had to suffer with an image upload form which was pretty bare-bones, while attempting to shoehorn more smarts into it through templates and JavaScript hacks.
Hooray. This is well overdue.
I'd appreciate hearing from people interested in helping out in the following capacities:
- Designing user interface mockups
Well, you could argue the JavaScript hack-up at the moment is a pretty fair mock-up of what we can envisage.
This effort will probably take from a few weeks to a few months to get to the point where it's really live; we may even try experiments like having the old and new forms available side-by-side on the live site so people really have a chance to bang at it in real usage without forcing an in-flux test system on everyone.
I think that's a great idea. There's no reason we couldn't have Special:Bulkupload or Special:Powerupload (for "power users") permanently, is there?
As Bryan mentioned, we would definitely like the ability to create purpose-specific forms. Trying to cram all the relevant info on a single form results in something horribly cluttered, crowded and ultimately ignored by most users. (This gets a little bit messy when trying to figure out how fallback language codes should work, IIRC)
Via JavaScript we have now separate template fields into separate form elements. Ultimately, we'd like those fields to be stored separately so we can query over them (e.g. date, geotag, license). OK, we have the world's messiest data at the moment, but we did start from a single blob rather than separate fields.
There is also, as always, the "multilingual factor" (I am big fan of the JavaScript-enforced prompting for descriptions in specific languages). I don't know exactly what problems are in store there, I just feel certain that there are some. :)
cheers, Brianna
About purpose-specific forms. Two of our purpose-specific forms are actually for functions that probably shouldn't be directly through the upload form.
One is for images from Flickr. If ImportFreeImages was installed on Commons this could be done away with. https://bugzilla.wikimedia.org/show_bug.cgi?id=8854 (This request has been open for 16 months.)
Another, more important, is for transferring images from another Wikimedia project to Commons. https://bugzilla.wikimedia.org/show_bug.cgi?id=5283 (This is open over two years.) I don't dare to hope that SUL means this might be easier! But I'm not sure what makes it a hard problem now.
Brianna
On Mon, Jun 9, 2008 at 3:29 PM, Brianna Laugher brianna.laugher@gmail.com wrote:
About purpose-specific forms. Two of our purpose-specific forms are actually for functions that probably shouldn't be directly through the upload form.
One is for images from Flickr. If ImportFreeImages was installed on Commons this could be done away with. https://bugzilla.wikimedia.org/show_bug.cgi?id=8854 (This request has been open for 16 months.)
That looks nice. But if we're rewriting the upload function anyway, how well would this integrate? Or would it be easier/prettier/more useful to rewrite that functionality from scratch?
Another, more important, is for transferring images from another Wikimedia project to Commons. https://bugzilla.wikimedia.org/show_bug.cgi?id=5283 (This is open over two years.) I don't dare to hope that SUL means this might be easier! But I'm not sure what makes it a hard problem now.
As I can tell you from experience[1], correctly transfering the description does make it hard: * parsing {{Information}} templates in various languages * parsing "freestyle text" descriptions for keywords (e.g. "self"), again in various languages * for images with multiple versions by different uploaders, figure out who the original uploader of the current one is * converting license templates from (you guessed) various languages * some of these "local" templates have author names included where Commonjs does not, or vice versa * similar, various versions of {{self}}, {{self2}}, etc where multiple licenses have to be moved within the template, or separated * of course, templates can contain enclosed templates, which makes the entire parsing operation spin out of control...
In summary, it requires a whole lot of parsing and special cases, sometimes per-language, which is probably not the right approach for core code.
But hey, we can just copy over the original description (in a language spoken by 50 people world-wide) and wait for someone to fix it by hand ;-)
Cheers, Magnus
On Mon, Jun 9, 2008 at 5:23 PM, Magnus Manske magnusmanske@googlemail.com wrote:
On Mon, Jun 9, 2008 at 3:29 PM, Brianna Laugher brianna.laugher@gmail.com wrote:
About purpose-specific forms. Two of our purpose-specific forms are actually for functions that probably shouldn't be directly through the upload form.
One is for images from Flickr. If ImportFreeImages was installed on Commons this could be done away with. https://bugzilla.wikimedia.org/show_bug.cgi?id=8854 (This request has been open for 16 months.)
That looks nice. But if we're rewriting the upload function anyway, how well would this integrate? Or would it be easier/prettier/more useful to rewrite that functionality from scratch?
Probably. See my proposal on http://www.mediawiki.org/wiki/Upload_form_changes. I would like to separate the logics for 1) showing the upload form, 2) the read part and 3) the storage part. You may for example want to use the same logic for showing the upload form but want to replace 2) to upload from Flickr. Or you want to give users the opportunity to upload from different forms while keeping the backend the same.
I would like some comments of this, because I might make this my project for this summer :)
Bryan
Bryan Tong Minh wrote:
Probably. See my proposal on http://www.mediawiki.org/wiki/Upload_form_changes. I would like to separate the logics for 1) showing the upload form, 2) the read part and 3) the storage part. You may for example want to use the same logic for showing the upload form but want to replace 2) to upload from Flickr. Or you want to give users the opportunity to upload from different forms while keeping the backend the same.
Looks good.
I would like some comments of this, because I might make this my project for this summer :)
Even better :)
Magnus Manske magnusmanske@googlemail.com wrote on mon, 9 jun 2008 16:23:58 +0100
As I can tell you from experience[1], correctly transfering the description does make it hard:
[...]
- converting license templates from (you guessed) various languages
maybe http://toolserver.org/~luxo/litafi.php could be of some help there - although it only supports German at the moment ...
Best regards,
Flo