Posted by & filed under programming, publishing, xslt.

Twice in the past couple of weeks I’ve needed to solve this problem:

We have content provided as individual displayable pages, but we need a document for those pages to refer to, with a table of contents so that a user can navigate between them. In one case it was a set of articles in a journal issue, in another it was entries in an encyclopedia. I solved both of these problems with the same general XSLT structure, so I thought I’d write it up for others to use. Read more »

Posted by & filed under news.

Safari was founded in 2001, as a joint venture between O’Reilly Media and Pearson, two publishers that care deeply about learning, innovation, knowledge, and personal growth.

Today I’m thrilled to announce that O’Reilly Media, Inc., has acquired the Pearson stake in Safari, and Safari is now a wholly-owned subsidiary of O’Reilly Media, Inc. Safari will continue to operate as an independent company, and Pearson Education will remain a strategic content partner of Safari.

Safari - O'Reilly Read more »

Posted by & filed under Information Technology, infrastructure, IT, tools.

If you’ve used Chef, you’ve probably used a community cookbook. Community cookbooks are helpful because someone else has figured out how to solve your problem, be it installing nginx or configuring postgresql. While community cookbooks are great, they sometimes don’t include everything that you need. That’s where wrapper cookbooks come in. If you want to change or extend the functionality of a cookbook without having to rewrite it from scratch, a Chef wrapper cookbook is the way to go. Read more »

Posted by & filed under Content - Highlights and Reviews.

You’ve probably noticed we’ve made some changes around here, including a brand new design and sharp new logo.

New Safari Logo

Safari began more than 13 years ago as “Safari Tech Books Online,” with the promise of replacing the collection of IT and programming reference books on your shelf with something online and searchable. (As the saying goes, “You can’t grep dead trees.”) Read more »

Posted by & filed under java, programming, testing.

A few months ago I noticed the JUnit Attachments Plugin and was inspired.  Recording pictures and other files after test failures is such an obviously good idea, especially if you’re the one who has to fix the tests.

Unfortunately, the JUnit Attachments Plugin has some rough edges. I wrote a small library that handles the busywork while keeping tests readable.  Since we are awesome, we open sourced it so you can use it too!

Read more »

Posted by & filed under Tutorials.

Safari is seeking help in usability testing for Safari Tutorials, our curated learning paths based on Safari books and videos. You will be speaking with folks from our product development team, and your input will directly influence how the product evolves in the next few months. That’s pretty cool, don’t you think?

fisheye image of UI books

Photo by loureiro, used under CC-By A / Cropped from original

The Details

Tests will be performed remotely via a Google Hangout video chat, running for 30 to 45 minutes. Session times are available on June 18 and June 19.

If you are interested in participating, we ask that you take a few minutes to complete this short questionnaire.

Those selected for usability testing will receive a $25 gift card (iTunes or Amazon) upon completion of the session.

Thank you for considering participating in our study. Feedback from our community is essential as we build products that help our users learn and grow. Plus we just like speaking with you.

Posted by & filed under accessibility, authoring, book design, css, design, Digital Publishing, ebooks, epub, html5, talks.

I originally presented this talk on ebook markup to an audience of ebook developers and publishers. As someone who cares deeply about accessibility and discovery, it’s a subject that tends to get me agitated, but I tried to be extra-polite because my audience was Canadian.

My hope is that as web-based book resources like Safari continue to proliferate, publishers will take advantage of the opportunities afforded by many years of research by the web community into what makes content semantically rich, accessible, and competitive with the wealth of free material available on the open web.

The craft of ebooks

Read more »

Posted by & filed under analytics, content, Product Updates & Tips, search.

We’ve made quite a few changes lately to the search engine and interface on Safari Flow. These changes were motivated in no small part by the evolution of the application itself. When Flow launched last summer, it included a highly curated collection of approximately 250 books and videos, primarily aimed at web developers. We’ve more recently decided to expand the scope of that content, and the original 250 has increased 100-fold — almost exactly, in fact: today, we’re rapidly approaching 25,000 titles on a myriad of topics from dozens of publishers.

The evolution of searching in Flow

Searching across 250 titles is not the same as searching across 25,000. We’ve addressed this shift with a number of refinements, some small and some large. Among the smaller changes we’ve made are adding autocomplete, giving users the option to search across specific indexes (author, title, published, and ISBN), and some retuning of how search results are weighted (one example: book titles are now weighted slightly more heavily than chapter titles).

More drastically, we refactored the interface of the results page. When we had fewer titles, the results page was quite simple and emphasized individual chapters over complete titles.

Search results for 'just enough research' showing two book covers and and links to three chapters in each book.

Search results in the new interface are much richer. Because users have so many more results from which to choose, we aimed to provide tools and information to make choosing easier. For example, results are shown in context, and the user has more filtering options. A user can filter out specific types of media, and sort on relevance or publication date. She can drill down further by clicking on a specific author or publisher. And perhaps the best part: search results are returned twice as quickly.

Search results for 'just enough research' showing bold text of the results in context

Reviewing the results

Our hypothesis was that providing users with a richer search experience would make the site easier to use and generally more engaging. Roughly 81% of logged in visits include a search of some kind (40% of which originate on the home page), so it’s important to us that we get it right. So how are we doing?

The new search interface has been on the site for a couple of weeks now, and we’re encouraged by the some of the early analytics. For example, the number of times users search again after the initial search has decreased by 7%. So they are finding what they want more often. Great!

We’ve also seen an uptick in engagement. For example, the amount of time a user stays on the site after searching has increased on average by over a minute. The average number of pages a user views after searching has gone up by a full page. We see these data points as signs that we are doing something right.

Not all of the analytics are unambiguously good or bad. One of the more perplexing data points is related to a new autocomplete feature. Specifically, autocomplete has not consolidated the search terms. Before we added autocomplete, we saw 17,824 unique search terms and 26,814 unique searches, which is 66% unique. Since we added autocomplete (using a smaller sampling size), we’ve seen 10,689 unique search terms and 13,262 unique searches, which is 81% unique. We’re not quite sure to make of that!

This is of course not the end of the story. We know we still have a lot of work to do so that Flow’s search serves users accurately and quickly. Our users regularly write in to suggest changes, and we’re listening. And as you can see in this post, we’re making sure to measure the results of the choices that we make. In addition to the usage on Flow, we have the further benefit of over a decade’s worth of search-related data from our Safari Books Online platform.

Posted by & filed under talks.

Fletcher Nichol – Kitchen CI


We use Test Kitchen to test our continuous integration software at Safari Books Online. We run it on LXCs on both vagrant and testing nodes in our continuous integration pipeline. I was curious to see what was new with Kitchen CI and what Fletcher had to say. We use the framework in a standard way, though I learned the

kitchen diag

command, which is short for ‘kitchen diagnose’, and helps diagnose errors within Test Kitchen. I also learned how easy it is to test operating systems outside our current production systems with Kitchen CI. This would be useful to test cookbooks that we planned on releasing to the community. We could get a sense of what other OSes were already supported and what work would need to be done in order to support them if not.

Jamie Windsor – Berkshelf

We use Berkshelf to manage our cookbook dependencies. We love it and it works well. Jamie talked about the vision for Berkshelf 3.0 and how the product has been improved. I downloaded and installed the new Chef DK to play with which included both Berkshelf 3 and Kitchen CI. His talk details how artifacts are more strictly regulated in Berkshelf 3. Jamie also spoke about an online game platform he build using Elixir. He will be speaking more about it at the Atmosphere Conference in Poland.

Rachel Chalmers

Rachel said something that has stuck with me and I have repeated many time since. To paraphrase,

Automation Software is the Codification of Institutional Knowledge

I love that idea. Chef recipes are self-documenting processes for other engineers to learn from. What was once stored inside one person’s head is now codified with recipes. I love the concept!

John Esser

My big take-away from this talk:

Automating everything allows your business to pivot.

Big and small companies need to pivot; markets change and businesses change. If your infrastructure creation is automated, you can pivot from one direction to another more easily and in a safer, testable way.

Justin Arbuckle


Justin gave a great talk on automation software in our contemporary corporate culture. He used the story of Moby Dick to illustrate different struggles we face. This was a delightful talk with fantastic artwork by Matt Kish.

The Take-Away


It is easy for departments to live in silos. The current trend is to find ways to diminish the time wasted handing off tasks from one department to another. We’ve taken some of the recommendations to heart at Safari Books Online already. Historically, we’ve supported two Jenkins servers: one for IT and one for Engineering (Development). We have two source control repositories. We did this with good intentions: to stay out of each other’s way. For new projects that involve both departments, we try to consolidate source control and testing to the Engineering infrastructure. We now have software developers writing deployment cookbooks, which is exactly the direction we want to go. We have a long way to go, but this is a start.


Posted by & filed under accessibility, design, programming.

Happy Global Accessibility Awareness Day!

Last summer I taught an accessibility tutorial at OSCON with Denise Paolucci. After the tutorial (which has training materials on GitHub), I was speaking with attendees about what else they wanted from accessibility training, and I had an epiphany. An OSCON epiphany.

We don’t need more accessibility experts telling you how to make pages accessible[1]; that’s easy to find if you look. There are some fantastic resources out there already[2]. What we need is for the products out there – both proprietary and FLOSS – to become accessible. Making products accessible can be easy from a lines-of-code standpoint — sometimes the difference between Totally Unusable and Awesomely Accessible can be just tiny changes to the JavaScript and HTML. But it requires knowledge and vigilance of a sort that many developers and designers don’t have allocated for them in the course of a normal coding cycle.

To maintain accessibility, we need more people choosing to become the accessibility owner for a product. So I challenge you, the accessibility advocate or coder looking for a home, to become the accessibility advocate for your product at !DayJob, or to pick an open source project you use and become its accessibility hero. If you have an open source tool or platform you use all the time, I bet you dollars to boston creme donuts they either don’t have a contributor dedicated to accessibility, or their existing accessibility people want resources. And they likely would love an accessibility manager — especially if you volunteer to write the patches!

What you can contribute depends, obviously, on your skill set. But you don’t need to be a developer or a designer to be the Accessibility Hero at your organization.

You’re a coder, and you care about accessibility, but you don’t know much about it

Now is a great time to start! Start reading on the WebAIM mailing list and website until you have a handle on the interaction between theory and practice. Once you’re comfortable, work with the project leads to focus on what you and they agree are some nice, high-value low hanging fruit. You don’t have to start with the tougher stuff: visualizations, mapping, animated games. Pick something straightforward to begin with (adding alt text to the product logo?), and build up from there.

You’re an accessibility advocate, but don’t know much about coding

You will be a huge asset to an project by becoming the accessibility wrangler. Create and garden the accessibility section of the bug tracker. Find devs to fix those bugs, and put them in touch with the best documentation or with potential testers. Write documentation explaining why and how. Create project best practices. Learn how to test for accessibility yourself (it’s harder to test for than it is to code for), and become a QA tester. Seek out users with disabilities and convince them to become programmers, QA testers, and active bug reporters. I can’t overstate the importance of having someone like that on your project team. [3]

All-purpose tips

  1. Pick a project you care about! One you use all the time — an IRC client, an editor, a social media tool, a learning management systems, an IDE — will make each of your fixes more rewarding for you. I promise you there is not a single software product out there (including the platform where I co-lead the Accessibility Team, Dreamwidth) with perfect accessibility.
  2. Don’t just appear out of nowhere and start pestering existing contributors about accessibility. You want buy-in from the existing team, so approach the contributors in their forum of choice and tell them you’re ready to start committing accessibility patches or testing existing code, and you want to know if they have anywhere in particular they’d like you to begin. If this is for a project at !DayJob, speak with project managers and team leads and make sure you have their support.
  3. Seek out users with disabilities who have expressed the kind of interest that makes it seem possible they might be willing to be testers, coders, or bug reporters. They might already be there and organized, in which case, hooray! Your job is that much easier.
  4. Make a forum where developers, designers, and users can talk exclusively about accessibility issues. The type of forum doesn’t matter. IRC, mailing list, twitter, or a blogging platform are all fine, as long as your users with disabilities can access the platform.
  5. If users with disabilities report something that sounds like it’s not a bug to you, listen anyway. They might be mistaken, but trust that you don’t have their experience. Using computers with adaptive tech can be exhausting, and the tiniest roadblocks become major.


[1] Making AJAX-y pages accessible (after you’ve dealt with the basics of text alternatives for images, thoughtful use of headers, color contrast, and form labels):

  • Remember to code for keypress, keyup, keydown, and focus events when you are looking at hover, mouseclick, etc events.
  • If you create fake links or other HTML elements using spans or divs plus JS, make them accessible by adding a tabindex attribute, a role attribute, and coding for keyboard access as in point the first. But default to native HTML wherever possible.

There, how to fix 98% of inaccessible JavaScript in two bullets. BOOM. [Back]

[2] Try WebAIM and their great mailing list, as a good starting point. If you spend some time on the #accessibility and #a11y hashtags on twitter you’ll see some great conversations, as well. Learn what WAI-ARIA can and can’t do for you. Start there and branch out to the resources most useful to you. Understanding the Web Content Accessibility Guidelines (WCAG) and other standards is important for experts, but if you begin by reading standards, you’ll get overwhelmed, bogged down in details, and be distracted from the balance between following standards and creating usable, accessible sites.[Back]

[3] Well, I can overstate it. Having an accessibility wrangler won’t help you defeat giant lizards attacking the Pacific Coast or defend your Death Star from those pesky rebels. But it will make coding for accessibility a pleasure and delight. [Back]