Hi,
It appears now that after uploading on Commons, the user is taken to a page at Special:Upload:
"Successful upload" "Please follow the link [image name] to the description page now, to verify that it uploaded correctly.
If your changes are significant, you should mention how you have modified the old image.
Note In some cases, you might have to refresh the browser cache to see your newly uploaded image. Do this by pressing "refresh" in your browser. If you need help, ask at the Help desk.
Return to Main Page." (MediaWiki:fileuploaded - note that we modified the message to reflect the fact that it only came up where the user was overwriting a file)
Formerly, the user only got this page if they were overwriting an existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
Also, in my experience at least, the sidebar appears pushed most of the way down the page. (Firefox 2.0.0.3 on Fedora Core 6)
Is there a reason behind this change? If not, can it please be reverted to the former behaviour?
thanks Brianna user:pfctdayelise
Hi Brianna,
On 6/27/07, Brianna Laugher brianna.laugher@gmail.com wrote:
Hi,
It appears now that after uploading on Commons, the user is taken to a page at Special:Upload:
<snip>
Formerly, the user only got this page if they were overwriting an
existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
Indeed. Is this a problem, or what is your comment on this change?
Also, in my experience at least, the sidebar appears pushed most of
the way down the page. (Firefox 2.0.0.3 on Fedora Core 6)
Is there a reason behind this change? If not, can it please be reverted to the former behaviour?
I've not noticed this behavior, nor am I aware of any change that would have caused this. Possibly a customization on commons? In any case, it appears fine to me. Anyone else?
On 28/06/07, Daniel Cannon cannon.danielc@gmail.com wrote:
Formerly, the user only got this page if they were overwriting an
existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
Indeed. Is this a problem, or what is your comment on this change?
My comment on this change is unless it was introduced for a reason, please change it back. Why mess with the UI unless it's an improvement? The old behaviour was faster for uploaders and ensured that people looked at their image at least once. The new behaviour may mean that people don't even look at the image once.Problems such as failing thumbnail, wrong orientation, badly rendered SVG, etc are less likely to be noticed, as are warnings from license selector "traps" which are sometimes used (e.g. license selector says "I don't know where the image is from" -> warning template about no source).
See also http://commons.wikimedia.org/wiki/Commons:Village_pump#Change_to_Upload_beha...
cheers, Brianna
On 6/28/07, Brianna Laugher brianna.laugher@gmail.com wrote:
My comment on this change is unless it was introduced for a reason, please change it back. Why mess with the UI unless it's an improvement? The old behaviour was faster for uploaders and ensured
A lot about the image upload process could be improved. There's still no warning/suggestion, even when using the wizard, to add categories to your uploaded image. And there is still that lame warning (last I checked) about converting spaces into underscores, with an even lamer and misleading warning about not overwriting other people's images.
Ideally, I think the process would go something like this: 1. Specify a source file name and destination file name 2. Start uploading 3. Be taken to an intermediate screen which asks for licence, description, author, categories etc, all as individual fields. 4. Save changes, wait for the upload. 5. When the upload finishes, be taken to its normal page, showing the image and all the fields you filled in, for doublechecking.
Being able to edit these fields during the upload would be much more conducive to good field descriptions (you're less impatient, because the upload is already going), and uploading bigger files (because you have less dead time). I have a pretty crappy upstream connection (10kbps), and I find the whole upload process incredibly tedious. The inability to readily delete or rename files is also, in a word, shit. And I know that the bug report has been around a long time, and annoying users like me complaining about its non implementation doesn't help. Sorry.
Steve
Brianna Laugher wrote:
Also, in my experience at least, the sidebar appears pushed most of the way down the page. (Firefox 2.0.0.3 on Fedora Core 6)
These are produced by unclosed <div>s. Introduced by Fred J on http://commons.wikimedia.org/w/index.php?title=MediaWiki:Fileuploaded&di..., i have just fixed it.
Brianna Laugher wrote:
Hi,
It appears now that after uploading on Commons, the user is taken to a page at Special:Upload:
[...]
Is there a reason behind this change? If not, can it please be reverted to the former behaviour?
Probably accidentally introduced by me in r23023. I'll look into it.
-- Tim Starling
Tim Starling wrote:
Brianna Laugher wrote:
Hi,
It appears now that after uploading on Commons, the user is taken to a page at Special:Upload:
[...]
Is there a reason behind this change? If not, can it please be reverted to the former behaviour?
Probably accidentally introduced by me in r23023. I'll look into it.
In fact the behaviour was accidentally introduced in MediaWiki 1.4, an unintended side-effect of using Article::insertNewArticle() to create the description page instead of direct DB access. Article::insertNewArticle() is very poor as a backend function, having all sorts of UI consequences, which is why I eventually introduced Article::doEdit(). In r23023, I changed recordUpload() to use doEdit() instead, which meant that the accidental redirect was disabled.
Since you like it, I can write it back in. More proof that MediaWiki is as much designed by luck as by humans.
Another feature designed by luck was the fact that watchlists only display the current revisions of watched articles, not all changes during the specified period. This was a by-product of the cur/old split. While I was an editor I considered it an annoying bug, but when I actually "fixed" it, there was an outcry. So now it's hacked back in.
-- Tim Starling
On 28/06/07, Tim Starling tstarling@wikimedia.org wrote:
Another feature designed by luck was the fact that watchlists only display the current revisions of watched articles, not all changes during the specified period. This was a by-product of the cur/old split. While I was an editor I considered it an annoying bug, but when I actually "fixed" it, there was an outcry. So now it's hacked back in.
Indeed, this was in fact later "fixed" again by me, although I have to admit that that was an accident. There was, as I recall, another outcry, and you fixed it again, and then Wegge came along and made it into a preference to keep everybody happy.
Rob Church
On 28/06/07, Tim Starling tstarling@wikimedia.org wrote:
Since you like it, I can write it back in. More proof that MediaWiki is as much designed by luck as by humans.
Thanks, Tim. :)
There are a lot of ways the upload process could be improved, and if a developer initiates such a discussion with the intent to improving it, I'll take part, but until then I'll just keep mum.
This user's comment about the change made me laugh:
I'm uploading on commons since a while; since today after uploading I get a message about /Successful upload/ - thats really nice to get this message but I would see it as well in the "tradtional" way; and even better as I have seen the image an the description immediately. Is this text trying to tell me that there are to many Images on commons and so to avoid more images the procedure is getting more difficult to anoy the uploaders? (already /Commons:Upload/ does it make more laborious; but I understand that it is needed for new users) Maybe its a feature and I just did not get the benefit? <<
cheers Brianna
Brianna Laugher wrote:
Formerly, the user only got this page if they were overwriting an existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
I've changed it back to the previous behaviour now. But are we sure we don't just want it to redirect all the time? We don't display a success message on page edit, do we? Presumably the same applies here, the user can see in the file history that their file has been uploaded correctly.
-- Tim Starling
Tim Starling wrote:
Brianna Laugher wrote:
Formerly, the user only got this page if they were overwriting an existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
I've changed it back to the previous behaviour now. But are we sure we don't just want it to redirect all the time? We don't display a success message on page edit, do we? Presumably the same applies here, the user can see in the file history that their file has been uploaded correctly.
-- Tim Starling
I guess it didn't automatically redirect on the beginning because broswer cache could still show the old image on the image page, annoying the uploader. At least, that's the reason i though it had.
On 29/06/07, Tim Starling tstarling@wikimedia.org wrote:
Brianna Laugher wrote:
Formerly, the user only got this page if they were overwriting an existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
I've changed it back to the previous behaviour now. But are we sure we don't just want it to redirect all the time? We don't display a success message on page edit, do we? Presumably the same applies here, the user can see in the file history that their file has been uploaded correctly.
It seemed as if the success message only came up on image overwriting. Thus we used the message to confirm with the uploader that they intended to overwrite another file. If people use a common filename (apples.jpg) and click 'ignore all warnings' they wouldn't know they had overwritten another file. (Steve was right in pointing out that the 'spaces have been changed to underscores' warning is quite useless. I often check 'ignore all warnings' to avoid this. Perhaps other experienced users do too.)
It might also be useful to use the 'successful upload' message to convey the fact that overwriting-uploading only overwrites files, not image page descriptions.
So, in conclusion, I don't know. :) I can ask what people at Commons think about it, though.
cheers Brianna
On 29/06/07, Tim Starling tstarling@wikimedia.org wrote:
Brianna Laugher wrote:
Formerly, the user only got this page if they were overwriting an existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
I've changed it back to the previous behaviour now. But are we sure we don't just want it to redirect all the time? We don't display a success message on page edit, do we? Presumably the same applies here, the user can see in the file history that their file has been uploaded correctly.
I got a response from 4 users about this, who all said that the page could be done without. One suggested that for overwriting, just one line could appear at the top of the image page as notification.
Perhaps something similar to what seems to now be happening with adding/removing watchlist items could be used? (MediaWiki:addedwatchtext appears at the top of the page you added, instead of having the intermediate page which said something like "page has been added to your watchlist".)
cheers Brianna
On 7/1/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 29/06/07, Tim Starling tstarling@wikimedia.org wrote:
Brianna Laugher wrote:
Formerly, the user only got this page if they were overwriting an existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
I've changed it back to the previous behaviour now. But are we sure we don't just want it to redirect all the time? We don't display a success message on page edit, do we? Presumably the same applies here, the user can see in the file history that their file has been uploaded correctly.
I got a response from 4 users about this, who all said that the page could be done without. One suggested that for overwriting, just one line could appear at the top of the image page as notification.
I just checked in a javascript function that will show a warning on the upload page itself (that is, before you even click "upload file") if there is already a file with that filename. The message will be turned on and off when you edit the destination filename manually, as well.
Magnus
Magnus Manske wrote:
On 7/1/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 29/06/07, Tim Starling tstarling@wikimedia.org wrote:
Brianna Laugher wrote:
Formerly, the user only got this page if they were overwriting an existing file, and ordinarily they would be taken straight to the new image page. Now it comes up if the file is being uploaded for the first time.
I've changed it back to the previous behaviour now. But are we sure we don't just want it to redirect all the time? We don't display a success message on page edit, do we? Presumably the same applies here, the user can see in the file history that their file has been uploaded correctly.
I got a response from 4 users about this, who all said that the page could be done without. One suggested that for overwriting, just one line could appear at the top of the image page as notification.
I just checked in a javascript function that will show a warning on the upload page itself (that is, before you even click "upload file") if there is already a file with that filename. The message will be turned on and off when you edit the destination filename manually, as well.
Whipped this feature into shape in r23608. Also removed the success page on overwrite, it now redirects unconditionally. I guess we'll see this on Wikimedia some time soon, if Brion doesn't hate it.
-- Tim Starling
wikitech-l@lists.wikimedia.org