[Clipart] [Bug 4134] Clipart submission form improvement

Sat Aug 20 05:53:28 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.     

https://bugs.freedesktop.org/show_bug.cgi?id=4134          

------- Additional Comments From turnip at turnipspatch.com  2005-08-20 05:53 -------
(In reply to comment #5)
> First round of changes checked in.  More remains to be done.

You work fast ;)

> > I don't know Perl, after all :)  I'm happy to do the JS side of things.
> 
> Okay.  Getting whatever JS code you write included in the output of the
> Perl script is the easy part of all this.

Yeah -- I reckon I can manage that much, but I'll shout if I'm stuck ;)

> > I'd suggest we have two textboxes floated left and right respectively 
> > on each line -- each occupying 50% of the space.
> 
> 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 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.
> 
> Some whitespace is good.  I'm thinking maybe take n% of the containing block's
> width for whitespace at the left, then m% for a text input, another n% space,
> another m% text input, and a final n% space.  3n + 2m = 100, so if n is 6 (a
> number I just picked out of the air), m would be 41.

Jesus, you make it sounds so complicated! I had to read that about three times
to even comprehend what you were saying ;). 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.

> First, will it have good usability?

Define "good usability"? I know what you are saying, but really it's anyone's
guess. There is little doubt in my mind that currently the usability is
suboptimal, so let me change it to how I have proposed, and we can discuss it
further then.

> Second, can we actually make it
> happen with HTML and CSS that recent major browsers will support?

Yes.

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

> I *think* the answer to the third question will
> be reasonably satisfactory once we get rid of the right sidebar per bug 3974

I agree.

> > I'm suggesting is assigning a cookie to hold what they type in the 
> > "author" field.
> 
> Oh.  I see.  Hmmm.
> 
> Aesthetically, I tend to prefer just one cookie per site that only holds a
> unique identifier that functions as a key to data stored on the server side. I
> really *hate* when sites litter up the cookie box with umpteen cookies for no
> good reason; it makes quite a mess for managing things on the user's end,
> management that *ought* to be done server-side (in terms of deciding which data
> are still relevant and whatnot).  But, as I noted, we're probably waiting on the
> DMS to do it the right way, and a special-purpose cookie would serve as an
> interim solution.  Hmmm.  Perhaps.

Well, yes, perhaps that's a better solution. However, we don't have the system
in place to do it like that now, and I think the benefit outweighs the
disadvantage. Anyway, how many people regularly survey their cookies? I
certainly don't.

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

> > "Wizards" in software interfaces never try to cram everything into 
> > one dialogue.
> 
> "Wizards" are one of the worst usability nightmares ever to become commonplace.
>  Why on earth would I want to give myself RSI by clicking "Next" a dozen times
> every time I do anything?

Well, it depends on the scenario really. I guess in desktop software there's
less excuse because the data/input/whatever can be assessed immediately -- but
in web applications you generally have to submit forms for the data to be sent.
An exception to this is using XMLHttpRequest ("ajax") -- but that's not really
practical for this situation where it would require sending a large file to the
server to be assessed; they may well have finished filling out the form by then.

Few more issues:

 * Do we really need the ordered list? I think not
 * 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.
 * I think we should get rid of the "SVG::Metadata" link. Who is this useful to?
 * Do we need the "(Optional) Description" ? Is this not metadata? Is it not
then covered under "I still want to add more [metadata]" ?          

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