Based on an IRC conversation I submit the following.
It would be great if Clipart Contributers had even more requests to work from.
Fulfilling requests would make the collection larger, and possible more
relevant to a wider base of Clip Art users.
With this in mind, I feel that the simplest way for the average clipart user
to make a request would be a simple web form. Below is a possible sample to be
used as jump off point.
Possible form for submission of Clip Art Requests.
Email ____________ (Optional - is e-mail required to submit a request ?)
Description of Request ____________ (Please describe what you'd like drawn)
 3-D Effect
 Other ____________
 Black and White
 Limited Colours
 Many colours are OK
 Other ____________
I am attaching (or linking) a...
 Hand drawn image scanned
 Photo of item for illustration
Clip Art Artist should...
 Make the clipart as close to my file as possible.
 Make the Clipart based on my file in the style I listed above.
 Has full artistic license.
 Requestor agrees that any clipart based on uploaded file is to be placed
and used in the public domain etc, and that uploaded file is not subject to
copywrite that would make the request a violation.
Requestor found OpenClipArt site by...
 web search
Requestor intends to use Clip Art for...
 Online graphics
 Printed output
 other options as desired here...
Other possible information could be gathered here.
Created attachment 2921 [details] [review]
Was learning about forms this evening, so I used this as an example to work on.
Hopefully this helps even a little.
Very cool man! We have to figure out how to attach this to the site and then
track clipart. I wonder if making this as an interface to bugzilla wouldn't be
such a bad idea? We need to figure out how to do user management, so I wonder if
tieing into Bugzilla's db wouldn't be such a bad idea.
So if we went this route, then clipart requests would be filed as bugs into this
bugtracker. I could setup another product for clipart requests.
Maybe though this needs to be more integrated with the website.
Thoughts on this?
I think that integration on the site is probably better.
Anyhow, the form looks great.
Yes I think integration to the web site is way batter.
Most clipart users are not going to be willing to create a bugzilla account and
jump through hoops to make a request.
It needs to be as simple to use as possible.
However I read in someones e-mail that it would be good to be able track if
someone is working on a request, and if it is complete or what. This would be
good as a bug, but I still think it would be too complicated for general
Also of note I just remembered somone suggesting the requestor be able to place
a "need by" date into the request. So should be added to the form if this
becomes a go.
Cool, you should have a go at adding it to the website to a test page. Then, we
can work together on implementing this functionality. I need to spearhead the
user management system.
Just to give a few pointers:
1) The usability of the form could be *greatly* improved if the label element
was used. Two good links:
You can also wrap a label around an element and thus don't need to use the for
attribute. Like so:
<label>Your name: <input type="text [...] ></label>
This is especially important on radio buttons and check boxes as they are very
very small and hard to click otherwise.
2) You could also use legends and fieldsets -- see the above links.
3) Please convert it to XHTML -- we should use the same DOCTYPE throughout the
site otherwise things would just get silly.
As much as I like Bugzilla, I agree that we probably don't want to require end
users to create a bugzilla account in order to submit clipart requests.
> Also of note I just remembered somone suggesting the requestor be able
> to place a "need by" date into the request.
I would worry that a "need by" date, labelled that way, could create an
expectation that the request would (or should, or needs to) be filled by that
date, which is an expectation we probably don't want to create. Perhaps it
should be labelled "Request expires" (or something along those lines) instead,
to convey the subtly-different idea that the requester only wants the item if it
can be done by that date. I realise that I'm picking semantic nits here, but I
think the difference in expectations could potentially be significant.
Created attachment 3071 [details]
Example difference image
Made some revisions to the form as suggested.
I see that this is already addressed somewhat in the layout of the form but I
think the description part should have a little text about how a request is more
likly to be filled if it is very descriptive and not something like "church
clipart" That is too broad a catagory for most artists to tackle. The more files
requested in a single submition, the less likly to be filled. From filling
requests and watching requests be filled, the ones that are usually done are the
ones that are simple requests or are very detailed in what they are looking for.
Sorry, I ramble....
(In reply to comment #2)
I think using Bugzilla is a good idea, we just need to create a front end on the
openclipart site that allows for easy submission and review of the request.
As far as needing bugzilla accounts, we could have a generic "clipartrequest"
bugzilla user. When a new submission occurs, to keep track of the requestors
name and email you could have the description start with something like:
RequestedBy : <Name>
RequestedByEmail: <E-mail Address>
comments from the submission form
A similar account could be used for the clip artist responding to the request.
A quick perusal of the bugzilla docs, shows that the response to your bugzilla
query can come back in different formats, html, rdf, etc. So hopefully
something like the rdf format would be relatively easy to parse and then display
in a preferred format on the openclipart site.
This approach may be as complicated, or even more so, than just coming up with
our own from scatch, but I think it is worth exploring.
This is easy to do now, but we have changed the way we do things. This is out of date :)
on Oct 25, 2016 at 04:54:31.
(provided by the Example extension).