[Clipart] [Bug 4134] Clipart submission form improvement

[bugzilla-daemon at freedesktop.org]

Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=4134          
     




------- Additional Comments From jonadab at bright.net  2005-08-19 07:00 -------
> Number 1: Move the file selector box to the top.

Okay, I can see that, especially with Inkscape having adequate support now
for adding the metadata at composition time.

> 2: Do we need the user to specify the file type? Can this not be 
> detected automatically? (Bugzilla does it)

If the user does not specify the filetype, we attempt to detect it 
automatically (since we moved away from CGI::Lite we have had this 
feature), but  this is not 100%; it can fail to detect a filetype at 
all, or, less likely, it could get the type wrong.  As far as Bugzilla, 
I have had to type in image/svg+xml every time I have attached a mockup 
to this bug.  What we *could* do is, only ask for the filetype if we 
can't detect it.  However, that has the disadvantage of adding a step 
if the user knows the filetype will not be detectable.  OTOH, that's 
probably an edge case, so an extra step might be okay.  I'm not 100% 
certain what I think on this one.

> Could step 4 in the form be possibly replaced with an explanation 
> that this can be done through the image editor?

I'm thinking at this point that we can probably do away with step 4.

> The keywords bit could be more slick

Yes, but remember that it needs to be usable if the user has Javascript
disabled.  (It doesn't have to be slick or featureful if the user has 
Javascript disabled, but it needs to degrade reasonably, i.e., they still
need to be able to see the list somehow and type in some keywords, as a 
fallback mechanism.)  Also bear in mind that I don't really know 
Javascript, so I will need help with anything very complicated.

> At the very least I think the textboxes should each occupy a separate
> line to make it simpler to look at!

That would be easy to do, but wouldn't it make the form longer, needlessly?

> "Author" field -- is this stored in cookie data? If not, it could easily
> be. It's the little things...

Currently, we don't have any kind of login or session mechanism.  I 
think that's probably waiting on the DMS for the time being.  However,
this (all of this) only needs to be specified at upload time if it's
not already embedded in the metadata.  Perhaps the form could make it
more clear that those fields only need to be filled out if the image
doesn't already contain them embedded.

> Another thing I find confusing about the form: supposing the file has
> already metadata in it (say added with Inkscape), after browsing for 
> the file the author is still asked for new metadata, he does not know 
> which metadata will be used, the one already existing inside the file 
> or the new one introduced in the web form.  After submit, he will learn 
> the old metadata inside the file was used, but then is to late for that 
> info to be useful.

Hmm...  actually, it's even more complicated than that.  Some fields,
most notably the author, are not changed if present, but other fields
currently *are* updated with the upload-time data, if it is specified,
and keywords are merged in (i.e., both the original and upload-time
ones are retained).  This was an attempt to mostly DWIM yet also DTRT,
but perhaps we need to simplify/standardise/specify this merging process.          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.