Code4lib Day 1: Design for Developers – Some Notes

by Lisa Kurt, University of Nevada

If you can get three things down, you can get a good design:

  • Typography – simple
  • Composition – a lot of white space, conventions
  • Colour – minimal

Study the designs that you love and those that you hate. What works and what doesn’t?

On Photos: If you use clip art, don’t use clip art that looks like clip art.

Look at designs with fresh eyes. Make sure it’s balanced.

Have fun too!

Really know your audience. Beware of decorative typeface: it can become hokey, very quickly because they look more like illustrations.

Designing for Mobile: Sans serif and white background with dark text is easier to read on mobile.

While you need to be careful of branding, you can use it to link different elements together.

Design by committee does not work! Provide three design and be firm that you will not combine them, etc. Usability can help support your design.

For more, check out Lisa’s website and the presentation slides below.

Code4lib Day 1: Kill the Search Button II – The Handheld Devices are Coming

by Michael Poltorak Nielsen, Statsbiblioteket/State and University Library, Aarhus, Denmark

Current Mobile Interaction Paradigm

You do a lot with your hands, everyday. Our hands are a really good tool, but currently, the handheld interaction is based on glass. That is you do functions by sliding your fingers, which means there is no feedback on what it does, i.e. it’s not intuitive.

Take a look at Pictures Under Glass: Transitional Paradigm dictated by technology, not human capabilities by Bret Victor.

An Alternative

  • direct manipulation
  • gesture driven
  • palpable
  • tactile

Smartphone Gestures

The near future may mean combining something like the Wiimote and the iPhone.

Mobile Projects

The idea was to build an HTML5 app that searches library data, favourites, view own items, renew, and request. Currently in beta, but to be published soon.

The search app can be augmented with gestures, gestures combined with multi-touch interactions.

Possible interactions with focus on

  • keyboard – typing
  • microphone speech
  • screen – touch, visuals
  • camera – pattern, movement
  • accelerometer – acceleration
  • gyroscope – rotation
  • compass  – direction
  • GPS – movement, position

Gestures

Might include simple ones using accelerometer data, including

  • tilt
  • flip
  • turn
  • rotate
  • shake
  • throw

The problem is that gestures are only really supported by Firefox, and partially supported by Chrome. Thus, it was decided that development would move to the native iPhone app environment with gestures, and HTML5 web app without gestures (but possibly later when supported). Features that are implemented include:

  • Restart search – face down
  • Scroll – tilt up and down
  • Switch views – tilt
  • Request items – touch and tilt left
  • Favourites – touch and tilt right

Check out the demo:

Challenges

  • no standard mobile gestures
  • gesture maybe individual
  • gesture may not be appropriate at all
  • sophisticated gestures are hard to code
  • Objective-C

Code4lib Day 1 Morning: HTML5, Microdata and Schema.org (and other takeaways)

I did not take notes on everything in part because some of it was very technical and it can be hard to do notes, but here are some takeaways from the morning:

  • Versioning Control: Use it, Git or Mercurial. Doesn’t need to be code, can be data too. – Description and Slides
  • Take library data and make it available to users, can’t expect them to search for it.
  • Linked Data doesn’t need to be a huge project. Start small.
  • Why RDF? It’s flexible with easy addition of new attributes or classes, and works cleanly with an iterative approach.

HTML5 Microdata and Schema.org

by Jason Ronallo

Other than getting good ranking, we need to provide rich results, i.e. rich snippets. Some digital collection have been providing rich snippets already, such as NCSU Libraries.

How do we get this?

  • embedded semantic markup
  • HTML5 Semantics include nav, header, article, section, footer
  • HTML5 Microdata is a syntax for annotating content to communicate meaning of data to machines
  • similar to RDFA, other microdata
  • Microdata comes back as tree based JSON and allows for DOM API

For example:

<div itemscope itemtype=”http://schema.org/Organization” itemref=”logo”>
<a itemprop=”url” href=”http://code4lib.org/”>
<span itemprop=”name”>Code4Lib<\span>
</a>
</div>
where: scope = about something
type = type of item
prop = properties

For the user, there is no difference as display is the same. This provides a complete data model.

Schema.org  is a one-stop shop for vocabulary in describing items on the web.

Apologies, I did not take extensive notes on it, but to read more, check out the slides below or the Code4lib article he wrote.

Code4lib Day 1: Keynote on Code4libcon

Daniel Chudnov from George Washington University was the first Keynote of the conference.

Dan began with a bit of an introduction and then went into a very touching overview of the story of his family and his life. His life lesson was that

things fall apart.

We Blew It

We have turned away too many people: way more than 100 people. That was a terrible mistake. If we don’t address this mistake, this [conference] is not going to last.

Code4lib was inspired by Access, with some key aspects:

  • single track
  • participatory
  • social
  • beer
  • fun

The difference the organizers wanted was a (possibly) geekier version in the USA in Spring (so as not to compete with Access). What might have really pushed this discussion is that

we turned away more people in 2012 than attended in 2007.

Why? The most common answers revolved around the capacity of venue. There were of course, some other concerns about keeping it a small, informal, participatory conference that were expressed, especially in the backchannels (IRC and Twitter).

Nevertheless, Dan asked the key question “Why do you come?” He expressed how he comes to connect with people, and hang out with the attendees, and there are many others that wanted to join, but were turned away.

He went on to talk about how while there is a chasm of techies vs. non-techies, there shouldn’t be. Plenty of people want to learn what coders do, and as a group, we should want to help respond to change constructively. They want to code, and we should connect and work more closely with them. We have one choice to make:

HACK OR DIE

We Must Expand

Dan used PyCon as a possible a good mode to follow. They have:

  • 2 days of pre-conference tutorial days
  • up front training for all levels
  • 4 days post-conference sprint days
  • back-end collaboration for all levels
  • plenary talks, plenary lightning
  • multiple tracks

Dan was against multiple tracks for many years, but not anymore, because

we need to connect or this thing we have will fall out from under us.

His point is that next year people won’t even bother if there is no clear statement to make things work.

Challenges

  • break complacency
  • lack of proposals to host
  • too heavy a burden on local organizers

Possible Solutions

Committees need to be formalized, especially an advisory committee of former hosts to help future hosts. The work needs to be done through the year, and more open like it used to be. Dan also suggested a formal program committee to replace the “diebold-o-tron”, but there was some disagreement because it’s less participatory.

Some other ideas included a multi-core code4lib where each regional group would be 1 hour live streaming on the same day, and the BarCamp approach where there are no pre-planned presentations, which might work for regional code4lib conferences. However, concern was expressed with having too many small conferences organized, burning out possible hosts for the annual code4lib.

The next code4lib conference should aim for 500 people.

Chicago is ready. Are you?