Bug 4134

2. the upload form detect the file type, but only after the "send file" button
is pressed (this is needed to process the metadata according with the type -
write inside the svg, create an additional metadata.rdf, put the metadata file
inside archive)

3. we really need step 4? it only add to the visual bloat and don't think anyone
used it so far

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.

> Number 1: Move the file selector box to the top.

Okay, I can see that, especially with Inkscape having adequate support now
for adding the metadata at composition time.

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

> 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.)  Also bear in mind that I don't really know 
Javascript, so I will need help with anything very complicated.

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

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

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

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

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?

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

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

Fwiw, DMS won't include web login management, so you'll want to work out a
suitable approach.  The plan is for DMS to simply be able to "hook in" to some
other login management system; it would keep track of the User ID's (UIDs) for
submitters, commenters, administrators, etc. but would not actually handle any
of the login, account management, etc. etc.  Fortunately, there is a lot of
existing code out there to do this.

It's been my experience that login and account management can be kept isolated
from the main service/application without much trouble, so I tend to prefer
application designs that keep it abstract enough that (in theory) the
administrator could replace it with a different system if they desired.

Kees did a review of existing PHP login management systems a couple months back,
and didn't like what he saw so ended up writing his own - you might drop him an
email (kees at outflux dot net) to inquire about it.  I suspect it may need some
additional work to polish up the HTML, etc. but the underlying security
mechanisms are probably squared away pretty well.

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

(In reply to comment #8)
> > 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 ...

It's not a case of implementing it properly, it's a case of getting the desired
result. IE's float model is totally ****ed up, granted, but it can be worked
with. But I'm perfectly happy to deal with this side of things.

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

Well, yeah. I am aware it is resolution/screen size -dependent, but I was
meaning *generally*. I resized my window, and -- in general -- I experienced
three boxes going across. However, if more were added, I'd probably experience
more. Anyway, we're getting sidetracked into discussing how many boxes there are
across, which is not really the point!

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

We could do that, but I think it'd be better to get the adding of extra boxes to
happen server side instead of client side, if scripting is turned off (through
the same link/button). Let's look at this bit again once that part of the form
has been reworked though; it will be easier to see the most unobtrusive solution.

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

Anybody else have an opinion on this?

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

Can/Should this be changed?

> You work fast ;)

I triage well.  The first round consisted entirely of easy changes.

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

That would work too, but what I meant was that if you post the client-side
scripts into this bug, I can easily roll them in with the other changes.

[a dedicated "author name" cookie]
> However, we don't have the system in place to do it [the ideal way]
> now, and I think the benefit outweighs the disadvantage. 

Having thought about this some more, I think I agree, provided it's a 
temporary stand-in measure and that we eventually want to move to using 
a single session or login cookie.

> Currently, the number of keyword inputs on each line entirely depends 
> on the user's window size, font size, and other factors.  

Then again, I guess what you're proposing makes the length of an input
field, in characters, depend on those things.  Which is probably okay.
We'll want to test with various setups, but I guess it should work out.

> However, if more were added, I'd probably experience more. 
> Anyway, we're getting sidetracked into discussing how many boxes 
> there are across, which is not really the point!

Agreed.

> > >  * 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.
> 
> Can/Should this be changed?

It can be.  Should still needs to be discussed.

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

But Bryce says...
> Fwiw, DMS won't include web login management, so you'll want to 
> work out a suitable approach.

So the upshot of this is that a login or session cookie mechanism is not
waiting on DMS; it's just waiting to be implemented.  I will file a new
bug for that, but IMO we don't have to hold this one back waiting for it.

Second round of changes checked in.  More remains to be done.  Among other
things, getting rid of the ordered list leaves things rather a mess; I don't
think we should go back to the way it was, but the way it is now isn't very good
either.  Among other things, perhaps the css should tell div.uploadstep to space
itself out a bit more vertically.  What do you think, Nicu?

How about invisible table borders?

> How about invisible table borders?

That would be a CSS change.  As it stands now, it would be a site-wide change,
although we could give this table a class attribute and style it that way.
Come to think of it, while I'm at it:  the tables in the upload form will
now have class="uploadstep".  (The divs already have this.)  So in the CSS
we can now style table.uploadstep in whatever fashion is desired, as well
as div.uploadstep.  (The tables are contained within the divs.  Each 
div.uploadstep corresponds to a step, i.e., formerly an li in the ol.)

Tables are for tabular data -- not structural presentation. This is not tablular
data. So we shouldn't really have any tables.

Third round of changes checked in...

> > > >  * 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.
> > 
> > Can/Should this be changed?
> 
> It can be.  Should still needs to be discussed.

Nothing fuels discussion like making undiscussed changes, so, erhm,
have a look at how this is handled now.

> Tables are for tabular data

In theory, I agree with that.  What do you propose?

(In reply to comment #16)
> Third round of changes checked in...
> 
> > > > >  * 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.
> > > 
> > > Can/Should this be changed?
> > 
> > It can be.  Should still needs to be discussed.
> 
> Nothing fuels discussion like making undiscussed changes, so, erhm,
> have a look at how this is handled now.

Cool. This is fine with me.

> > Tables are for tabular data
> 
> In theory, I agree with that.  What do you propose?

I propose waiting a little bit until I have time to take a crack at the
markup/style myself ; ). Then I'll do the scripting. I'm out tonight but I hope
to have the time tomorrow night. For the markup and style that is.

Okay, I've committed some stuff (hopefully I didn't break anything!). It's not
really much -- I cleaned up the markup a bit, added in labels, changed some of
the copy to make it more friendly, etc.

Still to do:
 * I'd like to try the float left/right thing on "Author" and "Title"
 * The ajaxified keyword inputs

I might get a chance to look at that tomorrow.

Have a few comments:
 * What is the use of "Send File Now"?
 * And what's the use of this: <input name="add_keywords_here" type="hidden" /> ???

Few more changes made -- nicu, what do you think of this?

I've realised the answer to my second question above. However, I have another:
if all the keyword input boxes are named "keyword", how does it all get sent as
POST data? I guess it must be possible otherwise it wouldn't be there, but I
thought "keyword[]" was the way to do it...

Jonathan Leighton wrote:
>Few more changes made -- nicu, what do you think of this?

Can we have the form a little more compact? For example on my 1152x864 display
it fit on one screen only if the browser window is maximized.

> What is the use of "Send File Now"?

If the metadata have already been added (e.g., in Inkscape), the user may not
need to use the rest of the form, and may not want to scroll down.  This is also
the whole point of moving the file upload element to the top of the form,
instead of its previous location at the bottom.

> And what's the use of this: <input name="add_keywords_here" type="hidden" />

The script uses it to find where to insert things.

> if all the keyword input boxes are named "keyword", how does it all get
> sent as POST data

In the usual way.  They all get sent.  The form-input parsing routine is
responsible for deciding how to handle this.  In the case of upload_svg.cgi,
$input{keyword} is a reference to an anonymous array.

The sidebar, incidentally, is in includes/sidebar_unified.php

(In reply to comment #20)
> Jonathan Leighton wrote:
> >Few more changes made -- nicu, what do you think of this?
> 
> Can we have the form a little more compact? For example on my 1152x864 display
> it fit on one screen only if the browser window is maximized.

How about now? Contrary to what I've previously said, I think floating the
keyword boxes left/right would make it more confusing, so I haven't done that.
I've brought them closer together though. I also changed some of the text around
a little.

I still intend to do the ajaxed keywords thing, but it might be quite a while
before I get round to it (I intend to launch the site redesign I did on my own
site months ago first). I think the form has been improved a lot and this bug
can probably be closed now.

obsolete due to the introduction of cchost