[Clipart] new site design in progress

[Jonadab the Unsightly One]

Bryce Harrington <bryce at bryceharrington.com> writes:

[The quick-upload form]
> Actually, I'd favor keeping it.  I do understand the point of it not
> being useful to a segment of the potential users, however I
> definitely do not think it should be hidden.

Well, I did say that the link to the main upload form should
definitely always be easy to find...

> From a project perspective, it's important to consider who the
> 'customers' are.  In a traditional proprietary product-oriented company,
> value comes in the form of money from purchasers of the product.  Thus
> it's typical to think of customers == users who purchase.  Thus, you
> want to optimize to make it easy and worthwhile for users to purchase.
>
> However, in open source projects, things are different.  Value for the
> project comes in the form of contributions from users.  This could be
> patches for a software project, or new clipart in our case.  Thus,
> customers == users who contribute, and we want to optimize to make it
> easy and worthwhile for users to contribute.

This is true.

> From this viewpoint, I would like to see the quick upload tool remain on
> the front page permanently, even if it is felt to distract a little from
> the browse/download links.  It's worth it.

As I said, I can see advantages both ways (i.e., to keeping it and to
removing it).

> This is why it is important in wiki-based projects to have the edit
> link clear and visible.  If it was available only through a second
> click, then this severely cuts down the number of users who become
> contributors - they don't even think about editing.  Yes, it adds to
> the site's clutter, but for the wiki to work it's critical that it
> be there and easy to access.  It takes very few obstacles to turn a
> potential new contributor off.

The edit link on e.g. Wikipedia is very different in character from
our quick upload form, because it consists in many cases of just the
word "edit" next to a section, or the phrase "edit this page" in an
article's header or footer.  It does *not* consume more than a third
of the browser window (more than half at small window sizes).

When the user clicks the edit link, _then_ they get a page that
consists of a big fat edit form consuming most or all of the browser
window.  (Depending on browser window size, it may even have to be
scrolled.)  This IMO is more comparable to our full upload form that
the user gets by clicking the "Upload" link -- except that maybe our
"Upload" link would need to be more prominent and obvious if it were
taking the place of the quick-upload form.

If we're going to keep the quick upload form permanently, it has *GOT*
to take up less space.  It doesn't have to be as small as an "edit"
link in Wikipedia, but it needs to be a lot smaller than it is now.
Right now it's more than half whitespace -- lots of whitespace is good
for a major piece of page content, such as the news section, but for
the upload form it's too much bloat.  We'll probably need to rearrange
and maybe sacrifice some fields, too.

We should maybe do this (redesign the quick-upload form to be smaller)
now, as part of the site redesign.

>> Something else we should do before we forget:  dynamic pages that do
>> computation-intensive or disk-intensive stuff should check the HTTP
>> Referer and quickly dish out something static if it's slashdot.  I
>> really should make OpenClipart::Web check for this and use its static
>> cached copy of shell.php under such conditions.
>
> Yes, I notice the site can be quite slow, due either to the dynamic
> nature or perhaps to the hardware, but in any case, whatever we can do
> to help ease the load would be worth doing.

One of the things that's slowing down the upload script considerably
is the need to grab shell.php via http every time.  I should probably
rewrite OpenClipart::Web so that it uses a cached copy more often, if
not always.  That would mean we'd want some easier, more automatic way
to update its cached copy, but it would be worth it.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/