Category Archives: Interface/Design

Share what you’re reading

To bring in the new year, Open Library announced a new feature called the Reading Log which lets you keep track of the books you’re currently reading, have finished reading, or want to read. Over the last two months since we launched the feature, we’ve received promising feedback from our community. Our reading log stats page shows over 53,000 readers have logged more than 100,000 books! It’s even helped us learn which books our community cares most about. The biggest point of feedback we’ve received is that many readers wish there was a way to share their reading log with friends.

Continue reading

A Holiday Gift from Open Library: Introducing the Reading Log

For years readers have been asking us for a convenient way to keep track of the books they’re reading.

As we prepare to step through the threshold into 2018, we’re happy to announce the release of a brand new Reading Log feature which lets you indicate all the books you’d like to read, books you’ve already read, and books you’re currently reading.

You can now mark a book as “Want to Read”, “Currently Reading”, or “Already Read”, in addition to adding it to one of your themed reading lists.

Here’s how it works!

Continue reading

Lists are here!

Open Library is happy to report that the Lists feature is here, for your collection-building enjoyment! You can create and share lists that include authors, works (all editions of a specific title), specific editions, and subjects.

Add to List icon

While browsing around, you can see when an item has been added to somebody’s list – just look underneath the Add to List button.  Here are some items that have been listed so far:

Continue reading

Upgrading ‘Accessible’ to ‘Fully Accessible’

The Internet Archive wants to grant universal access to all knowledge. It’s important to note that ‘universal’ and ‘all’ in that sentence aren’t generalities. When we say ‘universal,’ we mean for everybody, and when we say ‘all,’ we mean everything. To that end, Open Library has been conducting ongoing testing with one of our most important audiences in order to create a website that allows blind and visually impaired visitors access to all available resources, and particularly to downloadable books.

Last Thursday, October 7th, George Oates (Open Library’s lead designer), Mike McCabe (our resident DAISY file specialist) and I visited LightHouse for the Blind and Visually Impaired here in San Francisco and sat down with three extremely patient and helpful volunteers to observe while they used our new site to find and download books to their book readers.

According to Lisamaria Martinez, one of our volunteers, blind and visually impaired readers generally read several times the number of books that sighted readers do, yet have access to only a small fraction of them. Newer titles in particular are hard to find in accessible formats – and these are the titles we’re starting to make available as “protected” DAISY files which can be loaded onto a variety of book reading devices like the Victor Stream or BookSense readers. It’s vitally important that we make them easy to find, easy to download and easy to use.

As a front-end coder and visual designer, I’ve often made assumptions about visitors to websites I’m designing or coding, but have rarely taken the time to consider those who can’t see the pages until now. How do you navigate without vision? How can we convey the same kind of visual codes about the page’s contents (headlines, colors, white space, keylines, and so on) to blind and visually impaired visitors?

We went in without any formal test plans because we wanted to watch as the testers – who hadn’t used the site at all – first encountered it and used its search features to find titles they wanted to read or find out more about. If you’re trying to make your site more accessible, here’s a few of the lessons I learned from just a few hours of observation and that we’ll be implementing in the coming weeks.

  • First, and foremost, code to web standards. This seems obvious and is just good practice, but if you’re ever tempted to cheat a little bit and use tags or elements for unintended purposes, resist that urge or find another solution. Just because a page “looks right” doesn’t mean it is.
  • Headers (H1, H2, etc.) are often used as page navigation in screen readers. Use them! Don’t fall back on resizing text and bolding text to mimic headers visually. Sprinkle them about liberally so visitors can skip down your pages to important parts.
  • Try to set font sizes at relative (em) measurements via style sheets. Visually impaired visitors often want to enlarge text for easier reading, and some browsers refuse to re-size fonts set to absolute pixel (px) sizes.
  • Page headers or sections are often implied by color or placement and don’t always have explanatory text to describe what the information is. For example, on our search results page, we provide search filter lists along the right side of the page with labels like “Authors” and “Subjects” but didn’t implicitly explain what they do. Adding a simple header with a line of explanation about their usage, with a link for search syntax, helps.
  • We often try to compress labels to as few words as possible, believing that the accompanying information was obvious – except if you can’t see the accompanying text and you’re navigating by header. We’re using more explanatory copy in our labels now.
  • As you probably already know, titles and image alternate text (the ALT element in the IMG tag) are extremely important when you can’t see the images – like book covers. We were inserting the book titles as alternate text, but that really didn’t explain that they were covers of the books. Think about what the image is, rather than what it conveys visually.
  • If we’re missing information about a work or one of its editions, we either don’t show the field at all or leave it blank. That’s usually okay, but in one special circumstance it caused some confusion. Editions of a work are originally presented by date of publication – which would be great, except that places editions with no known publication date first. Simply noting those cases by adding in “Published date unknown” rather than no text at all adds meaning.
  • Navigation between pages was sometimes problematic. In particular, in order to download a DAISY file to read the book, we move the site visitor to a dedicated page that provides some necessary explanations about protected DAISYs because anyone can download one, but you need a special license to actually open it. But the page was missing one key feature: a search field. This turns out to be the primary way in which visually impaired visitors (as well as sighted visitors) explore a site. We provide a search field on every page except the DAISY download page, which isn’t obvious if you can’t see it. Adding a link to the search page brought back a sense of comfort to our testers.

We still have some gaps and holes to fill in, and we’ll keep testing the site both formally and informally to further enhance accessibility for every visitor. If you’re in the business of building sites, I heartily recommend that you contact an organization for the blind and visually impaired in your own city or town and give it a run-through with an audience that is often neglected, if not ignored. I’ll bet they’ll be overjoyed to help you out and you’ll wind up with a better site in the end.