[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-21 20:10 -------
> > I thought text inputs were sized as a given number of characters.
> > Can you get them to take up a certain percentage of the containing
> > block's width?  With CSS, maybe?  I hadn't thought about this
> > possibility...
> 
> Yeah, you can. Specifying the width by characters is a pretty bad
> idea, really.

I specify the width of most things as percentages (if I specify it at
all), but I just didn't realize this was possible for input elements.

> I had to read that about three times to even comprehend what you
> were saying ;). 

Sorry.  I do tend to squeeze in a few too many clauses per sentence,
sometimes.

> We would enclose the input boxes each in a div element. The divs
> would be floated left or right and assigned a width of 50%. Then we
> would apply a margin to the inputs of however much we want. I think
> that should work. Ideally we wouldn't have to have a div, but
> without it the floated layout would break.

Oh...  Do float: left and float: right actually work in the browsers
people use these days?  The last time I checked, Gecko was the only
major browser that had implemented them properly.  Granted, that was
a while back, and I'm not entirely certain I had IE6 ...

> > And third, how's it going to work out when the user's browser
> > window is an atypical size or has an atypical font override?
> 
> Well currently there are three boxes running horizontally, which is
> worse.  Again, this is a "fix and discuss" issue really.

You have made the cardinal mistake of assuming everyone is using the
same setup you are using.  Currently, the number of keyword inputs on
each line entirely depends on the user's window size, font size, and
other factors.  They use whatever space there is and then wrap around.

This is even more apparent if you add some keywords so that there are
more than three.  If your window is big enough for seven keywords on a
line, seven will go on one line; if it's only big enough for two per
line, then there are two per line.  The next ones go down to the next
line.

Currently the selection box with the list of keywords also wraps up
onto the same line with them if there's room, but it could be put in a
separate div easily enough if that is desired.

> Anyway, how many people regularly survey their cookies? 

Only a few look at them regularly, but almost everyone at some point
ends up trying to look through them, for one reason or another ("Our
site isn't working correctly?  It *couldn't* be a design problem on
our end!  Check your cookies!" is a standard answer you will get from
approximately a third of the large corporate sites and more like three
quarters of all government sites...)
  
> > > I'd say we should read the metadata, and *then* display a second
> > > page giving them the opportunity to edit it.
> > 
> > So they have to fill out an extra form no matter what?  I think
> > some of the people submitting a large number of images might not
> > care for that.
> 
> Okay, you're right. I assume your "I still want to add more
> keywords" checkbox is meant to give this option? In which case,
> should it not say "I still want to add more metadata"? But yeah, I
> think that's an adaquate solution.

That checkbox used to also enable adding more optional fields in step
4, but we've recently discarded step 4 and the optional fields.  So
now it just allows adding more cookies, if the insert-keyword stuff
fails for some reason (e.g., you don't have scripts turned on).  What
it does is, it causes an additional round trip to the form, with a
larger number of blanks that you can fill in.  If the insert-keyword
client-side script works for you, you don't need it.  (Perhaps we
should have a script hide that checkbox, then, so it doesn't
needlessly confuse people who don't need it?)

>  * Do we really need the ordered list? I think not

No, we have the ordered list because (get ready) we've always had it
that way.  In particular, the old PHP-based non-metadata-aware upload
facility had an ordered list, and I just copied it and modified it as
necessary.  This is not a good reason to keep the ordered list.  We
could turn each li element into a div element and throw out the ol
wrapper, or whatever makes the most sense.

>  * If we're linking to the "File and Style Guidelines", which
> explain the copyright issues, can we cut down on the text by the
> license checkbox? I think "Yes, I am the copyright holder of this
> work and agree to release my clipart to the Public Domain and assert
> that it is not legally encumbered by trademarks or reserved rights."
> is enough.

Perhaps.

>  * I think we should get rid of the "SVG::Metadata" link. Who is this useful to?

You're probably right on that one.

>  * Do we need the "(Optional) Description" ? Is this not metadata?
> Is it not then covered under "I still want to add more [metadata]" ?

Currently it is not.          
     
     
--           
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.