BeanWorks

What if you could give a book to everyone on earth? Get an ebook and read it on any device, in any format, forever? Give an ebook to your library, for them to share? Own DRM-free ebooks, legally? Read free ebooks, and know their creators had been fairly paid?  –From About, unglue.it

Copyright is a round hole.  Paper publications are nice, round pegs.  Electronic items are square pegs.  Hard copies can be passed around, shared from person to person across time and space.  A copyright holder’s distribution rights are curtailed by the physical transfer of the copyrighted item (by purchase or gift) to another.

Electronic items can be similarly shared. Maybe.  Because they are square pegs, a new way to control distribution was needed, so a square hole called “licensing” was carved into the copyright landscape.  This pretty much upsets the shaky balance between the public right to knowledge and a creator’s right to profit from the work.

Enter the crowdfunding concept, which takes advantage of the ubiquitousness of the Interwebs and the ability to use that to more easily raise money for relatively small scale projects.  Kickstarter is a fairly well known example of a crowdfunding conduit.  And now comes Eric Hellman, using the crowdfunding idea to harmonize the ideals of copyright and licensing, to make that square peg fit in the round hole.

Welcome to unglue.it.  I love it.  Where else can you find the possibility of getting your favorite book released into the electronic domain?  I’m hoping when this catches on, I’ll see In the Night Kitchen moved into an active campaign by the time my new grandson is ready to read!

The Code4Lib Journal exists to foster community and share information among those interested in the intersection of libraries, technology, and the future.  –Mission Statement, Code4Lib Journal

A colleague on the Code4Lib Journal’s editorial committee has posted a defense of the Journal’s position on peer review, or more specifically, double blind refereeing.  I was tempted, several months ago, to address the topic in the opening editorial for Issue 16, but was too preoccupied with food.  I don’t always see things the way Jonathan does, although I’ve learned over the years he gets it right a lot more times than I do.  In this case, we both agree that the Journal is, in fact, peer reviewed, but not double blind refereed, and we both agree this is a good thing.

Jonathan has, from my perspective, a rather entertaining analogy of the process as open source software development.  He also makes the argument that the Journal’s purpose is to provide value to our audience, and, just to make sure the elephant in the room is not ignored, stresses in very blunt terms that the Journal is not here to validate librarians’ or library technologists’ work for purposes of tenure or advancement.  I’m not going to disagree, but I am going to address the elephant differently.

I understand how “peer review” has been a good thing.  It has provided outside confirmation of the relevancy and quality of scholars’ work.  This was not the reason we started the Code4Lib Journal, however.  We were looking for a way to encourage and facilitate the (relatively) rapid dissemination of helpful information to our audience (which we did not see as being limited to people self-identified as members of  the Code4Lib community).

Because of this goal, we do things a little differently at the Code4Lib Journal.  We don’t require entire drafts be submitted, but we do have a rather tight timeline to publication, so it is obviously a plus when we get a draft up front, or when the author is already working on a draft and can get it to us quickly if the proposal is accepted.  All of us on the editorial committee are library technologists of some kind, although not all the same kind.  We all consider each submission, sometimes engaging in lively and lengthy discussions about a proposal.  In that regard, I would argue that the Journal is not just peer reviewed, it is uber-peer reviewed, because it is not one or two “peers” who are making the call on whether to accept a proposed article, it is typically 7-12 peers who are making the call.

Again, because of the goal to encourage and facilitate rapid dissemination of information, we are committed to working with authors to get their articles ready for publication.  This typically takes the form of (electronically) marking up a draft with specific comments and suggestions that we, as peers, think would make the article more useful to our audience.  The process sometimes goes through several iterations.  It doesn’t always work.  We have had some fall off the table, so to speak.  But the consistently high quality issues we have published are a testament to the validity of the process. Double-blind refereeing here would be an inherently inferior process for achieving our mission and goal.

But back to the elephant in the room.  Why, today, given the current state of disruptive technology in the publishing  industry, are we even talking about refereed journals?  I’m waiting for the other shoe to drop regarding that process.  Why are libraries still hyper-focused on double blind refereeing and peer review as validating mechanisms in tenure?  Isn’t it time to rethink that?  After all, libraries have already registered their disgust at being held hostage by journal publishers:  Universities require their scholars publish, and their libraries have to pay whatever the publisher demands for a license to see that scholarship.

Double-blind refereeing is time consuming.  So is what we do at the Code4Lib Journal. But I would posit that our way is more effective in identifying relevant information and  ensuring its quality.  How much ROI is there, really, in sticking with the old vetting process for validating tenure candidates?  May I suggest letting that other shoe drop and cut to the core of

• Why is tenure needed in your institution?
• How effective is the current tenuring system in supporting your institution’s mission and goals?
• What value does scholarly publishing bring to your institution?
• What are you willing to do to ensure continued scholarly publication?

The Code4Lib Journal was started 5 years ago by a message from Jonathan Rochkind to the Code4Lib mailing list asking, basically,  ”who’s in?”  Change can be done.  It just takes someone willing to voice the call.  If publishing is important to tenure, send out a call to your colleagues to start a Code4Lib type journal.  If it looks too scary, ask.  I’m willing to help.  I’m sure there are others out there as well.

With a little help from the DrupalEasy folks in Orlando, the Miami and Fort Lauderdale groups are finally putting on a Drupal Camp! (Thanks Mike Anello, for giving it the final push!)

Nova Southeaster University in Davie is hosting the event on Saturday, October 22. Admission is a only $10 — if you are anywhere in South Florida, come!  There are corporate sponsors, but consider chipping in $40 to be an individual sponsor.  Details are at the Drupalcamp website.

For the Drupal wary:  there is a Beginner’s track, using Drupal 7, the easiest Drupal ever!

For experienced Drupalers, there will be plenty to chew on, such as drush awesomeness!

If you are somewhere in between, trust me, you won’t be bored.

What started out as a 3-4 month hiatus to do an intranet site redesign, is now winding down after 6 months.  After the first couple months when it became apparent no progress was going to be made, I regrouped and put together a different, motivated but novice team. It’s been a little over three months since that team started on the project, and the results are impressive.  Although we could go live with it, I decided to do some “beta testing” on our unsuspecting end-users.  That has been enlightening: there may be some revisions in store before we finally get this baby to bed.

The terms usually associated with Drupal are “steep learning curve.”  I was the only one in my organization who even knew what Drupal is, although some seemed to have a vague concept of “content management system.” But I recommended we go with Drupal over other options because of (1) it’s potential, (2) the growing and active group of libraries with Drupal, and (3) because it’s the CMS I was most familiar with.  Looking back, I’d have done some things differently (isn’t that always the case?), but I would still choose Drupal. We haven’t fully taken advantage of all Drupal’s potential, but that’s only because I decided to hold off development of more advanced features until after we completed the initial project.

I was fortunate to have 2 others who were eager to learn and undaunted by Drupal’s complexity.  In a little over two months, with 1 1/2 days of one-on-one training and many many hours of phone conferences with them, they understand Drupal better than I did after two years of playing with it. This is a good thing, since they will likely be the ones left with the task of maintaining the site over the long run.  But we needed more than us three to migrate the content from the previous site, so I recruited 4 others, 3 of whom were apprehensive about approaching technology at this level.  One had a Technical Services background, and provided us with the taxonomy structure we needed. Two added content directly into special content types I set up, and one tracked down copyright-free pictures we needed.  It was an interesting exercise in project management: finding the team members we needed by dividing the tasks by skill level required, configuring Drupal to be easier to use for technophobes, and by approaching prospects individually to ask for help on a limited scale.

About half way through the project, as I struggled with trying to get the site to display the same in IE7 and Firefox, I shifted gears and decided to do the layout completely in CSS.  Actually I was shamed into it after a query to the Drupal library group.  I finished those changes just about the same time everything else fell into place.  And it works just fine in both browsers, thank you!  But we had been designing with the assumption most end users would be using a set screen size and resolution.  This week we discovered those assumptions were way off.  The good news is that we have found a lot more real estate to work with.  The bad news is that while things aren’t broken, the site doesn’t look quite the way we envisioned.

There may be some more tweaking involved, but there are now two others who have enough experience to do the tweaking.  Life is good.  Now to get back to the digitization project.

Google has entered the tech support arena: http://www.teachparentstech.org/watch The short help videos are slick, and they’re appealing, at least to the target audience: a younger generation that is very tech savvy with parents or grandparents who are not.  One of my sons came across them and asked if I thought they would be helpful for his grandparents, who are in their 80′s.  I went to investigate.

The Tech Support care package is a set of quick videos intended to make using Google products easier.  It makes sense.  You have a product.  You do a market analysis.  Where can you expand? In technology, an obvious place to expand your market is the older adult population, which is the fastest growing segment of the population.  But there are problems with that market segment (see my Connecting the Disconnected series of posts, as well as the Computers, Older Adults, and Libraries page).  So Google, in a style very reminiscent of Apple, has created some help videos for basic computer tasks as well as for using Google products.  They are short (good idea), to the point (good idea), and friendly (good idea).  Some are good, some are fails.

The first issue is: how basic is “Basic”?  On the assumption that this is intended for someone who at least uses email (after all, the front page of the site is an invitation to email these helpful videos to the one you think needs them), how much existing knowledge does that presume?  Looking at the set of 6 basic videos, the following knowledge and skills are expected:

• How to use the mouse, including the right and left buttons (or right and left side of the mouse).
• How to click and drag
• What the various special function keys are (such as the Control Key or Command Key) and where they are .
• How to browse a computer’s file structure.
• What a computer file is, and what the different types of computer files are (such as jpg, pdf, docx)
• How to use email, including attaching files.

How reasonable are these expectations?  I fall back on the standard evasive answer:  That depends.   I have developed a lot of computer training and taught a lot of people how to use computers.  They have ranged in age from thirties to nineties.  They have had varying levels of computer skills across all ages (although, in general, the older they are, the less computer skills they have).  For those who had no experience with computers, my goal was to teach them how to use the internet, and how to use email.  Once they reached that level, I could teach them more advanced things like bookmarking web sites, basic computer skills and file structure, and sharing photos.  Some of these videos presume more skills than I did even for the next step beyond the new user level.  For example, files and file structure, and email attachments were elements in our more advanced user classes.

As an aside, Gmail was one of the email services we tested on the new user groups.  It did not work out well, because (1) Google kept changing the service and interface, and (2) it was too confusing for a typical older user to figure out.  I tried to contact Google about creating a user interface that would work for older adults.  Obviously, I didn’t get their attention.

So the videos really aren’t all that basic, except to technologists who find the featured tasks unbelievably mundane.  But how useful are they to their intended audience (the older adult who already has some computer skills)?  Again, it depends:

• How old is the recipient of the “Care” package?  The older the person is (generally, 55+), the more they need explicit instructions, using discete steps. The visuals are nice, but sometimes they move too fast and skip over steps.  Also, the language is often not explicit enough for an older adult.
• How experienced is that person with computers?  This question is actually tied to the next one.  Older adults do not tend to keep up with changes in technology as much as their children/grandchildren.  But generally, the more experience they have, the less difficulty they have learning new, related skills.
• What operating system, and what version of the operating system, is that person using?  Because older adults tend to not update their skills (learn why here), they are usually using an old computer and operating system (it was not uncommon to have students in my classes who were using Windows 98).  The changes from Windows 98/2000/xp to Win7 or OSX Snow Leopard are intimidating to an older adult (again, generally, 55+).  These videos assume the recipient will be comfortable using one of those operating systems.  That is a big assumption.

Bottom line: If the intended recipient of these cute care packages is under 55, and has some experience using a recent operating system, the videos will likely be both handy and useful. If the recipient is over 55 and/or is not using a recent operating system, a few of the videos would be useful:  How to Create a Strong Password, How to Know if an Email is Real, and most of the Search Information videos.  Also note, there are a lot more Mac-centric videos than Windows.

Would it work for my parents, in their 80′s, who have been using computers since the first Apples came out, and currently have Snow Leopard?  Actually, no.  They would have difficulty following most of them, and for the rest, they wouldn’t see the point.