[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          
     

turnip at turnipspatch.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://openclipart.org/cgi-
                   |                            |bin/upload_svg.cgi




------- Additional Comments From turnip at turnipspatch.com  2005-08-19 12:35 -------
(In reply to comment #3)
> > 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.

I would say the benefit to many outweighs the inconvenience to some. However, I
may be swayed by statistics on the number of sucessful auto-detections.

Another thing, we can quite easily detect XML from the XML declaration. Then we
can go on to find out (pretty reliably) whether it's SVG or not. I dunno about
the rest... ?

> > 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.)

Sure thing. Well the list-filling-in-textbox thing we currently have wouldn't
work without JS anyway, so... I would say it'd be enough to provide a link to
the list of keywords currently in use. Beyond that, we could possibly have some
alternative content that is sent with the page, and then hidden with
JavaScript... therefore non-JS users would see it but everyone else wouldn't.

> Also bear in mind that I don't really know 
> Javascript, so I will need help with anything very complicated.

Well I do so let's join forces and conquer the world -- I don't know Perl, after
all :) I'm happy to do the JS side of things.

> > 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?

Hmmm, okay. You're right. I guess my problem at the moment is that it looks a
bit "messy" to my little eyes. I'd suggest we have two textboxes floated left
and right respectively on each line -- each occupying 50% of the space. I don't
think it's a good idea to make the form un-necessarily long, but then again,
it's nice to space things out a bit too.

> > "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.

We could do that too, but all I'm suggesting is assigning a cookie to hold what
they type in the "author" field. We don't need a login or session mechanism to
do that -- it's pretty simple (at least in PHP, ASP and Ruby on Rails -- I can't
imagine Perl is particularly different).

> > 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.

I'd say we should read the metadata, and *then* display a second page giving
them the opportunity to edit it. If the license is wrong, then we can force them
to change it at that point. I guess that would mean three pages if we can't
autodetect the MIME type -- but I don't *really* see that as too much of a
problem, to be honest. "Wizards" in software interfaces never try to cram
everything into one dialogue.          
     
     
--           
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.