[Clipart] [Bug 4134] Clipart submission form improvement
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Aug 19 12:35:38 PDT 2005
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.
turnip at turnipspatch.com changed:
What |Removed |Added
------- 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
> disabled. (It doesn't have to be slick or featureful if the user has
> 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
> Also bear in mind that I don't really know
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.
More information about the clipart