<div class="gmail_quote">On Thu, May 21, 2009 at 10:01 AM, John Olsen <span dir="ltr"><<a href="mailto:johnny_automatic@mac.com">johnny_automatic@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><br><div><div class="im"><div>On May 20, 2009, at 2:25 PM, chovynz wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Thu, May 21, 2009 at 1:25 AM, John Olsen <span dir="ltr"><<a href="mailto:johnny_automatic@mac.com" target="_blank">johnny_automatic@mac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div>This sounds like a nightmare to me.  So our current practices of making PNG files and uploading them first will make almost every existing submission fail to generate a PNG off of the svg file.  That I assume would then leave us with a PNG, a PNG from the PNG and the SVG in almost every case.  Based on this I would stop uploading PNG files all together since it looks like I'll end up cleaning up this mess in the future.  Why are we building a system that so directly conflicts with our current practices and makes so much wasted double work?</div>
 </blockquote><div><br>That's why I think we need the Help page to explain things like this.<br> Believe me, I don't want to go down this path either (redoing all that we've done in the last couples of months of librarian work - and beyond that the way you guys have been working for years.)<br>
 <br> That's why I brought it up now, so that we can come up with an automatic way of doing so. <br></div><div><br>Unfortunately I think, the old way of doing it was broken. I think the new way is better, BUT it does mean our work is reversed at the most, and misdirected at best. <br>
 The new way is better because:<br>1) I suspect it'll work better (no proof yet) with the Inkscape import clipart feature. To me that is a huge bonus. </div></div></blockquote><div><br></div></div>rarley use Inkscape, so really don't care one way or the other.</div>
<div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div><br>2) It's less work for the uploaders, which means potentially less mistakes on uploading.<br> 3) In the long run it will mean less work for admins and librarians. It's just this short term collection of 10k+ clipart that we need to redo or re-look at the way we do things. Any new clipart will be fine, as long as we educate long term clipart uploaders (people who currently use OCAL) in the new way of doing things.</div>
</div></blockquote><div><br></div></div>you make 10k+ sound like such a small number.  I agree about the single upload and generating a PNG - long overdue.  I guess the issue is that if it only generates the PNG as part of the upload process.  If so then I don't know how you generate PNG files for all the ones that don't have them now and replace the ones from old files.  Ideally it would be nice to toss all the existing PNG files and then just generate new ones from the whole library as part of the switch over.  But whether that can happen is the question.</div>
</div></div></blockquote><div><br>That's what I want to happen. At the moment I think Michi said<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>The new Page generates thumbs on upload AND <u>if a user
browse threw the cliparts.</u> If there is no thumb the site generates the
thumb. It always uses the first file. If the first file is a PNG it
generates a thumb out of the PNG.</div></div></blockquote><div><br>So those files that only have svg's NOW are fine. The problems ones are those with png's.<br><br>I think we should make a copy of the database, and test it on the BETA site to see what would happen. I don't want BETA live until we've sorted out many automatic ways of doing things. Like you said, it is almost opposite of how we are doing things right now, but I do think the new way is better.<br>
<br></div></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div>I suggest we do an education campaign soon, perhaps driven by the admins and librarians with news and stuff that Jon can upload to teh News page, so that people are prepared for teh new Beta site. Quite a few things will change, some of them being moving from Bugzilla to Launchpad, Using tags better, Uploading only the SVG, using Sets for difficult to tag groups of clipart, One Upload = One entry, etcetc. <br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div><br></div><div>Same issue with the current way we have files collected into groups.  The authors already collected items that they felt belonged together.  Now we need to undo all that work and set it all up in a new format.  A forat that has no instructions on how to use currently.</div>
 </div></blockquote><div><br>That's what the Help page will do - give clear instructions. I'd value your input when I finally have a mock up page of it. (Note: "Help" page is different to "Volunteer your time work or skills Page"). Part of the problem currently, is the Guidelines are on a separate website. And they are 'hidden' on the left side, not very visible. I intend on the "Help" page being in the main nav, very visible with "Help" quite prominant.<br>
 <br>One of the things on the Help page will be the One upload = One entry "rule".   </div></div></blockquote><div><br></div></div><div>Seems to me that making it impossible to upload more than one svg per page would be better than a "rule".  People love to break rules.  If the system doesn't let you upload more than one SVG per page then the problem (as you see it ) is solved.  This could be combined with a file checker  so that we don't get people uploading jpegs of their dog and such.  Just bounce those back and say "sorry, not the right file type"</div>
</div></div></div></blockquote><div><br>This is true, and one possible solution.  How does that work with Zip files though? If we stop multiple downloads, we stop zipped/collections altogether.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div><div></div><div><br></div><div>Still I'm not sold on SETS as the answer to something like Gerald G's many files where he uploaded a color and black and white version.   The few places where i have done group uploads like National Park map symbols, I could make a set.  I just think that makes perfect sense to being all on one page forever.  But if the single file per page is what's going to make galleries work then so be it.</div>
<div class="im"></div></div></div></div></blockquote><div><br>Again how about Zip files on offer in the downloads section? I don't have a solution to the clipart collections yet. SETS fill in the gap until we find a better way. <br>
<br>Sort of related issue: I want to see a feature that allows users to download marked or tagged clipart. For example if someone wants to download all cliparts with the tag "fruit" then they click on the download button and the OCAL website makes a zip file for all those. Or if Gerald's cipart is in a set we can download all the cliparts in that set (Theoretically named "Gerald's Hotel Icons") then the original uploader doesn't need to upload them into that one entry.<br>
<br>This means clipart can be uploaded singly (or via the future-mass-upload feature), and downloaded enmasse, as relevant sets. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div><div class="im"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<div>I don't even see anything explaining how sets work in the new system.  When I pick an item - mine or someone else's - I get two choices.  Either "Add to my favorites" or "Add to new favorites list"  Adding to new favorites list appears to do nothing.  I se no options for creating sets based on any other criteria.  I'll second the feeling that I have seen others express.  If anyone can make sets of anything based on any criteria and share them with others then I think this will create so much noise as to make sets unusable.  Web 2.0 at it's worst.  5,000 "things I think are cute" making the search for sets of real value a real chore.</div>
 </div></blockquote><div><br>I intend on making a few sets first and continually adding to them as relevant clipart appears, this will be a new librarian task (volunteerily of course). For example, "Black outlines Iconic style" and have many of those Pitr food icons in them, alongside any other icons that have a cartoony feeling to them. Maybe then we can make a page later on for special or important "Sets". Most people are lazy so if there is a "continually being-updated" "black outline cartoon" Set, I think most people would just browse in that instead of making their own.<br>
 <br>Also, the Set usage is quite experimental. The Help page will help explain how to use them. I intend on steering people away from making sets like "Fruit" because they can use the tags for that. With the new gallery it wont be difficult to find what they are looking for. I want "Sets" to be used for clipart that won't appear together based on a common tag. So for example, in the "Black outlined, colour clipart" set, these cliparts might appear together: a ninja with black outline, Pitr's Watermelon, my fruit, a petrol machine....none of these have anything in common, except the black outline. The style of the clipart (which is often untaggable or the uploader won't know.)<br>
 <br>It might get messy at first, but I'm all for seeing how it goes. We can always remove it if it gets too ugly, but I would prefer we find a way to make it useable. There's alot of potential for a Good Thing in the sets.<br>
 <br>But again, now that we have a gallery, I really do think people will just use tags. Speaking of tags, I intend of letting people know how to do advanced searches. I've played around with advanced searches and it's quite exciting what you can do with them.</div>
</div></blockquote><div><br></div></div>So sets aren't working as they will even for admins now?  There are some, were they hand coded?</div></div></div></blockquote><div><br>As far as I know the SETS are working as intended. I meant "experimental" as in, we don't really know how to use them in the best way yet. We haven't used this feature before on the current OCAL. No, they weren't handcoded. <br>
<br>We still need to test the site for admin features as there are lots of admin abilities missing at the moment.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><div><br><div>We already have advanced searches with the tag and sub-tag system.  But some people don't seem to like this model.  A good search function would almost be as useful as thumbnails.</div>
</div></div></div></blockquote><div><br>We do have a good search now on the BETA site. :) Better than current anyway. The only thing missing at the moment is the ability to search in the "Featuring" field ( -that is the "collaborating artists" field on the old OCAL.)  But again, testing the BETA on actual data would be better than guessing - even if it is an educated guess.</div>
</div><br><br clear="all"><br>-- <br>Cheers<br>Chovynz<br>