[Clipart] [Bug 4134] Clipart submission form improvement

Fri Aug 19 19:05:07 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 jonadab at bright.net  2005-08-19 19:05 -------
First round of changes checked in.  More remains to be done.

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

What are we going to do tomorrow night, Brain?

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

> Hmmm, okay. You're right. I guess my problem at the moment is that it 
> looks a bit "messy" to my little eyes. 

Perhaps it does, a bit.

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

> 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.  About this three questions
I have.  First, will it have good usability?  Second, can we actually make it
happen with HTML and CSS that recent major browsers will support?  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?  I *think* the answer to the third question will
be reasonably satisfactory once we get rid of the right sidebar per bug 3974,
though we should check.  But the first two questions need answering first.

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

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

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

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