Bootstrap Responsibly

Bootstrap is the most popular front-end framework used for websites. An estimate by meanpath several months ago sat it firmly behind 1% of the web - for good reason: Bootstrap makes it relatively painless to puzzle together a pretty awesome plug-and-play, component-rich site. Its modularity is its key feature, developed so Twitter could rapidly spin-up internal microsites and dashboards.

Oh, and it’s responsive. This is kind of a thing. There’s not a library conference today that doesn’t showcase at least one talk about responsive web design. There’s a book, countless webinars, courses, whole blogs dedicated to it (ahem), and more. The pressure for libraries to have responsive, usable websites can seem to come more from the likes of us than from the patronbase itself, but don’t let that discredit it. The trend is clear and it is only a matter of time before our libraries have their mobile moment.

Library websites that aren’t responsive feel dated, and more importantly they are missing an opportunity to reach a bevy of mobile-only users that in 2012 already made up more than a quarter of all web traffic. Library redesigns are often quickly pulled together in a rush to meet the growing demand from stakeholders, pressure from the library community, and users. The sprint makes the allure of frameworks like Bootstrap that much more appealing, but Bootstrapped library websites often suffer the cruelest of responsive ironies:

They’re not mobile-friendly at all.

Assumptions that Frameworks Make

Let’s take a step back and consider whether using a framework is the right choice at all. A front-end framework like Bootstrap is a Lego set with all the pieces conveniently packed. It comes with a series of templates, a blown-out stylesheet, scripts tuned to the environment that let users essentially copy-and-paste fairly complex web-machinery into being. Carousels, tabs, responsive dropdown menus, all sorts of buttons, alerts for every occasion, gorgeous galleries, and very smart decisions made by a robust team of far-more capable developers than we.

Except for the specific layout and the content, every Bootstrapped site is essentially a complete organism years in the making. This is also the reason that designers sometimes scoff, joking that these sites look the same. Decked-out frameworks are ideal for rapid prototyping with a limited timescale and budget because the design decisions have by and large already been made. They assume you plan to use the framework as-is, and they don’t make customization easy.

In fact, Bootstrap’s guide points out that any customization is better suited to be cosmetic than a complete overhaul. The trade-off is that Bootstrap is otherwise complete. It is tried, true, usable, accessible out of the box, and only waiting for your content.

Not all Responsive Design is Created Equal

It is still common to hear the selling point for a swanky new site is that it is “responsive down to mobile.” The phrase probably rings a bell. It describes a website that collapses its grid as the width of the browser shrinks until its layout is appropriate for whatever screen users are carrying around. This is kind of the point – and cool, as any of us with a browser-resizing obsession could tell you.

Today, “responsive down to mobile” has a lot of baggage. Let me explain: it represents a telling and harrowing ideology that for these projects mobile is the afterthought when mobile optimization should be the most important part. Library design committees don’t actually say aloud or conceive of this stuff when researching options, but it should be implicit. When mobile is an afterthought, the committee presumes users are more likely to visit from a laptop or desktop than a phone (or refrigerator). This is not true.

See, a website, responsive or not, originally laid out for a 1366×768 desktop monitor in the designer’s office, wistfully depends on visitors with that same browsing context. If it looks good in-office and loads fast, then looking good and loading fast must be the default. “Responsive down to mobile” is divorced from the reality that a similarly wide screen is not the common denominator. As such, responsive down to mobile sites have a superficial layout optimized for the developers, not the user.

In a recent talk at An Event Apart–a conference–in Atlanta, Georgia, Mat Marquis stated that 72% of responsive websites send the same assets to mobile sites as they do desktop sites, and this is largely contributing to the web feeling slower. While setting img { width: 100%; } will scale media to fit snugly to the container, it is still sending the same high-resolution image to a 320px-wide phone as a 720px-wide tablet. A 1.6mb page loads differently on a phone than the machine it was designed on. The digital divide with which librarians are so familiar is certainly nowhere near closed, but while internet access is increasingly available its ubiquity doesn’t translate to speed:

  1. 50% of users ages 12-29 are “mostly mobile” users, and you know what wireless connections are like,
  2. even so, the weight of the average website ( currently 1.6mb) is increasing.

Last December, analysis of data from pagespeed quantiles during an HTTP Archive crawl tried to determine how fast the web was getting slower. The fastest sites are slowing at a greater rate than the big bloated sites, likely because the assets we send–like increasingly high resolution images to compensate for increasing pixel density in our devices–are getting bigger.

The havoc this wreaks on the load times of “mobile friendly” responsive websites is detrimental. Why? Well, we know that

  • users expect a mobile website to load as fast on their phone as it does on a desktop,
  • three-quarters of users will give up on a website if it takes longer than 4 seconds to load,
  • the optimistic average load time for just a 700kb website on 3G is more like 10-12 seconds

eep O_o.

A Better Responsive Design

So there was a big change to Bootstrap in August 2013 when it was restructured from a “responsive down to mobile” framework to “mobile-first.” It has also been given a simpler, flat design, which has 100% faster paint time – but I digress. “Mobile-first” is key. Emblazon this over the door of the library web committee. Strike “responsive down to mobile.” Suppress the record.

Technically, “mobile-first” describes the structure of the stylesheet using CSS3 Media Queries, which determine when certain styles are rendered by the browser.

.example {
  styles: these load first;
}

@media screen and (min-width: 48em) {

  .example {

    styles: these load once the screen is 48 ems wide;

  }

}

The most basic styles are loaded first. As more space becomes available, designers can assume (sort of) that the user’s device has a little extra juice, that their connection may be better, so they start adding pizzazz. One might make the decision that, hey, most of the devices less than 48em (720px approximately with a base font size of 16px) are probably touch only, so let’s not load any hover effects until the screen is wider.

Nirvana

In a literal sense, mobile-first is asset management. More than that, mobile-first is this philosophical undercurrent, an implicit zen of user-centric thinking that aligns with libraries’ missions to be accessible to all patrons. Designing mobile-first means designing to the lowest common denominator: functional and fast on a cracked Blackberry at peak time; functional and fast on a ten year old machine in the bayou, a browser with fourteen malware toolbars trudging through the mire of a dial-up connection; functional and fast [and beautiful?] on a 23″ iMac. Thinking about the mobile layout first makes design committees more selective of the content squeezed on to the front page, which makes committees more concerned with the quality of that content.

The Point

This is the important statement that Bootstrap now makes. It expects the design committee to think mobile-first. It comes with all the components you could want, but they want you to trim the fat.

Future Friendly Bootstrapping

This is what you get in the stock Bootstrap:

  • buttons, tables, forms, icons, etc. (97kb)
  • a theme (20kb)
  • javascripts (30kb)
  • oh, and jQuery (94kb)

That’s almost 250kb of website. This is like a browser eating a brick of Mackinac Island Fudge – and this high calorie bloat doesn’t include images. Consider that if the median load time for a 700kb page is 10-12 seconds on a phone, half that time with out-of-the-box Bootstrap is spent loading just the assets.

While it’s not totally deal-breaking, 100kb is 5x as much CSS as an average site should have, as well as 15%-20% of what all the assets on an average page should weigh. Josh Broton

To put this in context, I like to fall back on Ilya Girgorik’s example comparing load time to user reaction in his talk “Breaking the 1000ms Time to Glass Mobile Barrier.” If the site loads in just 0-100 milliseconds, this feels instant to the user. By 100-300ms, the site already begins to feel sluggish. At 300-1000ms, uh – is the machine working? After 1 second there is a mental context switch, which means that the user is impatient, distracted, or consciously aware of the load-time. After 10 seconds, the user gives up.

By choosing not to pair down, your Bootstrapped Library starts off on the wrong foot.

The Temptation to Widgetize

Even though Bootstrap provides modals, tabs, carousels, autocomplete, and other modules, this doesn’t mean a website needs to use them. Bootstrap lets you tailor which jQuery plugins are included in the final script. The hardest part of any redesign is to let quality content determine the tools, not the ability to tabularize or scrollspy be an excuse to implement them. Oh, don’t Google those. I’ll touch on tabs and scrollspy in a few minutes.

I am going to be super presumptuous now and walk through the total Bootstrap package, then make recommendations for lightening the load.

Transitions

Transitions.js is a fairly lightweight CSS transition polyfill. What this means is that the script checks to see if your user’s browser supports CSS Transitions, and if it doesn’t then it simulates those transitions with javascript. For instance, CSS transitions often handle the smooth, uh, transition between colors when you hover over a button. They are also a little more than just pizzazz. In a recent article, Rachel Nabors shows how transition and animation increase the usability of the site by guiding the eye.

With that said, CSS Transitions have pretty good browser support and they probably aren’t crucial to the functionality of the library website on IE9.

Recommendation: Don’t Include.

 Modals

“Modals” are popup windows. There are plenty of neat things you can do with them. Additionally, modals are a pain to design consistently for every browser. Let Bootstrap do that heavy lifting for you.

Recommendation: Include

Dropdown

It’s hard to conclude a library website design committee without a lot of links in your menu bar. Dropdown menus are kind of tricky to code, and Bootstrap does a really nice job keeping it a consistent and responsive experience.

Recommendation: Include

Scrollspy

If you have a fixed sidebar or menu that follows the user as they read, scrollspy.js can highlight the section of that menu you are currently viewing. This is useful if your site has a lot of long-form articles, or if it is a one-page app that scrolls forever. I’m not sure this describes many library websites, but even if it does, you probably want more functionality than Scrollspy offers. I recommend jQuery-Waypoints - but only if you are going to do something really cool with it.

Recommendation: Don’t Include

Tabs

Tabs are a good way to break-up a lot of content without actually putting it on another page. A lot of libraries use some kind of tab widget to handle the different search options. If you are writing guides or tutorials, tabs could be a nice way to display the text.

Recommendation: Include

Tooltips

Tooltips are often descriptive popup bubbles of a section, option, or icon requiring more explanation. Tooltips.js helps handle the predictable positioning of the tooltip across browsers. With that said, I don’t think tooltips are that engaging; they’re sometimes appropriate, but you definitely use to see more of them in the past. Your library’s time is better spent de-jargoning any content that would warrant a tooltip. Need a tooltip? Why not just make whatever needs the tooltip more obvious O_o?

Recommendation: Don’t Include

Popover

Even fancier tooltips.

Recommendation: Don’t Include

Alerts

Alerts.js lets your users dismiss alerts that you might put in the header of your website. It’s always a good idea to give users some kind of control over these things. Better they read and dismiss than get frustrated from the clutter.

Recommendation: Include

Collapse

The collapse plugin allows for accordion-style sections for content similarly distributed as you might use with tabs. The ease-in-ease-out animation triggers motion-sickness and other aaarrghs among users with vestibular disorders. You could just use tabs.

Recommendation: Don’t Include

Button

Button.js gives a little extra jolt to Bootstrap’s buttons, allowing them to communicate an action or state. By that, imagine you fill out a reference form and you click “submit.” Button.js will put a little loader icon in the button itself and change the text to “sending ….” This way, users are told that the process is running, and maybe they won’t feel compelled to click and click and click until the page refreshes. This is a good thing.

Recommendation: Include

Carousel

Carousels are the most popular design element on the web. It lets a website slideshow content like upcoming events or new material. Carousels exist because design committees must be appeased. There are all sorts of reasons why you probably shouldn’t put a carousel on your website: they are largely inaccessible, have low engagement, are slooooow, and kind of imply that libraries hate their patrons.

Recommendation: Don’t Include.

Affix

I’m not exactly sure what this does. I think it’s a fixed-menu thing. You probably don’t need this. You can use CSS.

Recommendation: Don’t Include

Now, Don’t You Feel Better?

Just comparing the bootstrap.js and bootstrap.min.js files between out-of-the-box Bootstrap and one tailored to the specs above, which of course doesn’t consider the differences in the CSS, the weight of the images not included in a carousel (not to mention the unquantifiable amount of pain you would have inflicted), the numbers are telling:

File Before After
bootstrap.js 54kb 19kb
bootstrap.min.js 29kb 10kb

So, Bootstrap Responsibly

There is more to say. When bouncing this topic around twitter awhile ago, Jeremy Prevost pointed out that Bootstrap’s minified assets can be GZipped down to about 20kb total. This is the right way to serve assets from any framework. It requires an Apache config or .htaccess rule. Here is the .htaccess file used in HTML5 Boilerplate. You’ll find it well commented and modular: go ahead and just copy and paste the parts you need. You can eke out even more performance by “lazy loading” scripts at a given time, but these are a little out of the scope of this post.

Here’s the thing: when we talk about having good library websites we’re mostly talking about the look. This is the wrong discussion. Web designs driven by anything but the content they already have make grasping assumptions about how slick it would look to have this killer carousel, these accordions, nifty tooltips, and of course a squishy responsive design. Subsequently, these responsive sites miss the point: if anything, they’re mobile unfriendly.

Much of the time, a responsive library website is used as a marker that such-and-such site is credible and not irrelevant, but as such the website reflects a lack of purpose (e.g., “this website needs to increase library-card registration). A superficial understanding of responsive webdesign and easy-to-grab frameworks entail that the patron is the least priority.

 

About Our Guest Author :

Michael Schofield is a front-end librarian in south Florida, where it is hot and rainy – always. He tries to do neat things there. You can hear him talk design and user experience for libraries on LibUX.


Redesigning the Item Record Summary View in a Library Catalog and a Discovery Interface

A. Oh, the Library Catalog

Almost all librarians have a love-hate relationship with their library catalogs (OPAC), which are used by library patrons. Interestingly enough, I hear a lot more complaints about the library catalog from librarians than patrons. Sometimes it is about the catalog missing certain information that should be there for patrons. But many other times, it’s about how crowded the search results display looks. We actually all want a clean-looking, easy-to-navigate, and efficient-to-use library catalog. But of course, it is much easier to complain than to come up with an viable alternative.

Aaron Schmidt has recently put forth an alternative design for a library item record. In his blog post, he suggests a library catalog shifts its focus from the bibliographic information (or metadata if not a book) of a library item to a patron’s tasks performed in relation to the library item so that the catalog functions more as “a tool that prioritizes helping people accomplish their tasks, whereby bibliographic data exists quietly in the background and is exposed only when useful.” This is a great point. Throwing all the information at once to a user only overwhelms her/him. Schmidt’s sketch provides a good starting point to rethink how to design the library catalog’s search results display.

Screen Shot 2013-10-09 at 1.34.08 PM

From the blog post, “Catalog Design” by Aaron Schmidt

B. Thinking about Alternative Display Design

The example above is, of course, too simple to apply to the library catalog of an academic library straight away. For an usual academic library patron to determine whether s/he wants to either check out or reserve the item, s/he is likely to need a little more information than the book title, the author, and the book image. For example, students who look for textbooks, the edition information as well as the year of publication are important. But I take it that Schmidt’s point was to encourage more librarians to think about alternative designs for the library catalog rather than simply compare what is available and pick what seems to be the best among those.

Screen Shot 2013-10-09 at 1.44.36 PM

Florida International University Library Catalog – Discovery layer, Mango, provided by Florida Virtual Campus

Granted that there may be limitations in how much we can customize the search results display of a library catalog. But that is not a reason to stop thinking about what the optimal display design would be for the library catalog search results. Sketching alternatives can be in itself a good exercise in evaluating the usability of an information system even if not all of your design can be implemented.

Furthermore, more and more libraries are implementing a discovery layer over their library catalogs, which provides much more room to customize the display of search results than the traditional library catalog. Open source discovery systems such as Blacklight or VuFind provides great flexibility in customizing the search results display. Even proprietary discovery products such as Primo, EDS, Summon offer a level of customization by the libraries.

Below, I will discuss some principles to follow in sketching alternative designs for search results in a library catalog, present some of my own sketches, and show other examples implemented by other libraries or websites.

C. Principles

So, if we want to improve the item record summary display to be more user-friendly, where can we start and what kind of principles should we follow? These are the principles that I followed in coming up with my own design:

  • De-clutter.
  • Reveal just enough information that is essential to determine the next action.
  • Highlight the next action.
  • Shorten texts.

These are not new principles. They are widely discussed and followed by many web designers including librarians who participate in their libraries’ website re-design. But we rarely apply these to the library catalog because we think that the catalog is somehow beyond our control. This is not necessarily the case, however. Many libraries implement discovery layers to give a completely different and improved look from that of their ILS-es’ default display.

Creating a satisfactory design on one’s own instead of simply pointing out what doesn’t work or look good in existing designs is surprisingly hard but also a refreshing challenge. It also brings about the positive shift of focus in thinking about a library catalog from “What is the problem in the catalog?” to “What is a problem and what can we change to solve the problem?”

Below I will show my own sketches for an item record summary view for the library catalog search results. These are clearly a combination of many other designs that I found inspiring in other library catalogs. (I will provide the source of those elements later in this post.) I tried to mix and revise them so that the result would follow those four principles above as closely as possible. Check them out and also try creating your own sketches. (I used Photoshop for creating my sketches.)

D. My Own Sketches

Here is the basic book record summary view. What I tried to do here is giving just enough information for the next action but not more than that: title, author, type, year, publisher, number of library copies and holds. The next action for a patron is to check the item out. On the other hand, undecided patrons will click the title to see the detailed item record or have the detailed item record to be texted, printed, e-mailed, or to be used in other ways.

(1) A book item record

Screen Shot 2013-10-09 at 12.46.38 PM

This is a record of a book that has an available copy to check out. Only when a patron decides to check out the item, the next set of information relevant to that action – the item location and the call number – is shown.

(2) With the check-out button clicked

check out box open

If no copy is available for check-out, the best way to display the item is to signal that check-out is not possible and to highlight an alternative action. You can either do this by graying out the check-out button or by hiding the button itself.

Many assume that adding more information would automatically increase the usability of a website. While there are cases in which this could be true, often a better option is to reveal information only when it is relevant.

I decided to gray out the check-out button when there is no available copy and display the reserve button, so that patrons can place a hold. Information about how many copies the library has and how many holds are placed (“1 hold / 1 copy”) would help a patron to decide if they want to reserve the book or not.

(3) A book item record when check-out is not available

Screen Shot 2013-10-09 at 12.34.54 PM

I also sketched two other records: one for an e-Book without the cover image and the other with the cover image. Since the appropriate action in this case is reading online, a different button is shown. You may place the ‘Requires Login’ text or simply omit it because most patrons will understand that they will have to log in to read a library e-book and also the read-online button will itself prompt log in once clicked anyway.

(4) An e-book item record without a book cover

Screen Shot 2013-10-09 at 12.35.54 PM

(5) An e-book item record with a book cover

Screen Shot 2013-10-09 at 12.48.33 PM

(6) When the ‘Read Online’ button is clicked, an e-book item record with multiple links/providers

When there are multiple options for one electronic resource, those options can be presented in a similar way in which multiple copies of a physical book are shown.

Screen Shot 2013-10-09 at 12.35.22 PM

(6) A downloadable e-book item record

For a downloadable resource, changing the name of the button to ‘download’ is much more informative.

Screen Shot 2013-10-09 at 12.35.13 PM

(7) An e-journal item record

Screen Shot 2013-10-09 at 12.47.31 PM

(7) When the ‘Read Online’ button is clicked, an e-journal item record with multiple links/providers

Screen Shot 2013-10-09 at 12.41.56 PM

E. Inspirations

Needless to say, I did not come up with my sketches from scratch. Here are the library catalogs whose item record summary view inspired me.

torontopublic

Toronto Public Library catalog has an excellent item record summary view, which I used as a base for my own sketches. It provides just enough information for the summary view. The title is hyperlinked to the detailed item record, and the summary view displays the material type and the year in bod for emphasis. The big green button also clearly shows the next action to take. It also does away with unnecessary labels that are common in library catalog such as ‘Author:’ ‘Published:’ ‘Location:’ ‘Link:.’

User Experience Designer Ryan Feely, who worked on Toronto Public Library’s catalog search interface, pointed out the difference between a link and an action in his 2009 presentation “Toronto Public Library Website User Experience Results and Recommendations.” Actions need to be highlighted as a button or in some similar design to stand out to users (slide 65). And ideally, only the actions available for a given item should be displayed.

Another good point which Feely makes (slide 24) is that an icon is often the center of attention and so a different icon should be used to signify different type of materials such as a DVD or an e-Journal. Below are the icons that Toronto Public Library uses for various types of library materials that do not have unique item images. These are much more informative than the common “No image available” icon.

eAudiobooke-journal eMusic

vinyl VHS eVideo

University of Toronto Libraries has recently redesigned their library catalog to be completely responsive. Their item record summary view in the catalog is brief and clear. Each record in the summary view also uses a red and a green icon that helps patrons to determine the availability of an item quickly. The icons for citing, printing, e-mailing, or texting the item record that often show up in the catalog are hidden in the options icon at the bottom right corner. When the mouse hovers over, a variety of choices appear.

Screen Shot 2013-10-09 at 4.45.33 PM

univtoronto

Richland Library’s catalog displays library items in a grid as a default, which makes the catalog more closely resemble an online bookstore or shopping website. Patrons can also change the view to have more details shown with or without the item image. The item record summary view in the default grid view is brief and to the point. The main type of patron action, such as Hold or Download, is clearly differentiated from other links as an orange button.

richland

Screen Shot 2013-10-13 at 8.33.46 PM

Standford University Library offers a grid view (although not as the default like Richland Library). The grid view is very succinct with the item title, call number, availability information in the form of a green checkmark, and the item location.

Screen Shot 2013-10-13 at 8.37.37 PM

What is interesting about Stanford University Library catalog (using Blacklight) is that when a patron hovers its mouse over an item in the grid view, the item image displays the preview link. And when clicked, a more detailed information is shown as an overlay.

Screen Shot 2013-10-13 at 8.37.58 PM

Brigham Young University completely customized the user interface of the Primo product from ExLibris.

byu

And University of Michigan Library customized the search result display of the Summon product from SerialsSolutions.

Screen Shot 2013-10-14 at 11.16.49 PM

Here are some other item record summary views that are also fairly straightforward and uncluttered but can be improved further.

Sacramento Public Library uses the open source discovery system, VuFind, with little customization.

dcpl

I have not done an extensive survey of library catalogs to see which one has the best item record summary view. But it seemed to me that in general academic libraries are more likely to provide more information than necessary in the item record summary view and also to require patrons to click a link instead of displaying relevant information right away. For example, the ‘Check availability’ link that is shown in many library catalogs is better when it is replaced by the actual availability status of ‘available’ or ‘checked out.’ Similarly, the ‘Full-text online’ or ‘Available online’ link may be clearer with an button titled ‘Read online’ or ‘Access online.’

F. Challenges and Strategies

The biggest challenge in designing the item record summary view is to strike the balance between too little information and too much information about the item. Too little information will require patrons to review the detailed item record just to identify if the item is the one they are looking for or not.

Since librarians know many features of the library catalog, they tend to err on the side of throwing all available features into the item record summary view. But too much information not only overwhelms patrons and but also makes it hard for them to locate the most relevant information at that stage and to identify the next available action. Any information irrelevant to a given task is no more than noise to a patron.

This is not a problem unique to a library catalog but generally applicable to any system that displays search results. In their book, Designing the Search Experience , Tony Russell-Rose and Tyler Tate describes this as achieving ‘the optimal level of detail.’ (p.130)

Useful strategies for achieving the optimal level of detail for the item summary view in the case of the library catalog include:

  • Removing all unnecessary labels
  • Using appropriate visual cues to make the record less text-heavy
  • Highlighting next logical action(s) and information relevant to that action
  • Systematically guiding a patron to the actions that are relevant to a given item and her/his task in hand

Large online shopping websites, Amazon, Barnes & Noble, and eBay all make a good use of these strategies. There are no labels such as ‘price,’ ‘shipping,’ ‘review,’ etc. Amazon highlights the price and the user reviews most since those are the two most deciding factors for consumers in their browsing stage. Amazon only offers enough information for a shopper to determine if s/he is further interested in purchasing the item. So there is not even the Buy button in the summary view. Once a shopper clicks the item title link and views the detailed item record, then the buying options and the ‘Add to Cart’ button are displayed prominently.

Screen Shot 2013-10-09 at 1.21.15 PM

Barnes & Noble’s default display for search results is the grid view, and the item record summary view offers only the most essential information – the item title, material type, price, and the user ratings.

Screen Shot 2013-10-09 at 1.24.05 PM

eBay’s item record summary view also offers only the most essential information, the highest bid and the time left, while people are browsing the site deciding whether to check out the item in further detail or not.

Screen Shot 2013-10-09 at 1.28.47 PM

G. More Things to Consider

An item record summary view, which we have discussed so far, is surely the main part of the search results page. But it is only a small part of the search results display and even a smaller part of the library catalog. Optimizing the search results page, for example, entails not just re-designing the item record summary view but choosing and designing many other elements of the page such as organizing the filtering options on the left and deciding on the default and optional views. Determining the content and the display of the detailed item record is another big part of creating a user-friendly library catalog. If you are interested in this topic, Tony Russell-Rose and Tyler Tate’s book Designing the Search Experience (2013) provides an excellent overview.

Librarians are professionals trained in many uses of a searchable database, a known item search, exploring and browsing, a search with incomplete details, compiling a set of search results, locating a certain type of items only by location, type, subject, etc. But since our work is also on the operation side of a library, we often make the mistake of regarding the library catalog as one huge inventory system that should hold and display all the acquisition, cataloging, and holdings information data of the library collection. But library patrons are rarely interested in seeing such data. They are interested in identifying relevant library items and using them. All the other information is simply a guide to achieving this ultimate goal, and the library catalog is another tool in their many toolboxes.

Online shopping sites optimize their catalog to make purchase as efficient and simple as possible. Both libraries and online shopping sites share the common interests of guiding the users to one ultimate task – identifying an appropriate item for the final borrowing or access/purchase. For creating user-oriented library catalog sketches, it is helpful to check out how non-library websites are displaying their search results as well.

Screen Shot 2013-10-13 at 9.52.27 PM

music

themes

Once you start looking other examples, you will realize that there are very many ways to display search results and you will soon want to sketch your own alternative design for the search results display in the library catalog and the discovery system. What do you think would be the level of optimum detail for library items in the library catalog or the discovery interface?

Further Reading

 

 


The Mobile App Design Process: A Tube Map Infographic

Last June I had a great experience team-teaching a week-long seminar on designing mobile apps at the Digital Humanities Summer Institute (DHSI). Along with my colleagues from WSU Vancouver’s Creative Media and Digital Culture (CMDC) program, I’ll be returning this June to the beautiful University of Victoria in British Columbia to teach the course again1. As part of the course, I created a visual overview of the process we use for app making. I hope you’ll find it a useful perspective on the work involved in crafting mobile apps and an aid to the process of creating your own.

topological map of the mobile app design process

A visual guide to the process of designing and building mobile apps. Start with Requirements Analysis in the upper-left and follow the tracks to Public Release. (Click for full-sized image.)

Creating the Tube Map:

I’m fond of the tube-map infographic style, also know as the topological map2, because of its ability to highlight relationships between systems and especially because of how it distinguishes between linear (do once) and recursive (do over and over) processes. The linear nature of text in a book or images in slide-deck presentations can artificially impose a linearity that does not mirror the creative process we want to impart. In this example, the design and prototyping loops on the tube-map help communicate that a prototype model is an aid to modeling the design process and not a separate step completed only when the design has been finalized.

These maps are also fun and help spur the creative process. There are other tools for process mapping such as using flowcharts or mind-maps, but in this case I found the topological map has a couple of advantages. First and foremost, I associate the other two with our strategic planning process, so the tube map immediately seems more open, fun, and creative. This is, of course, rooted in my own experience and your experiences will vary but if you are looking for a new perspective on process mapping or a new way to display interconnected systems that is vibrant, fun, and shakes things up a bit the tube map may be just the thing.

I created the map using the open source vector-graphics program Inkscape[3. http://inkscape.org/] which can be compared to Adobe Illustrator and Corel Draw. Inkscape is free (both gratis and libre) and is powerful, but there is a bit of a learning curve. Being unfamiliar with vector graphics or the software tools to create them, I worked with an excellent tutorial provided by Wikipedia on creating vector graphic topological maps3. It took me a few days of struggling and slowly becoming familiar with the toolset before I felt comfortable creating with Inkscape. I count this as time well spent, as many graphics used in mobile app and icon sets required by app stores can be made with vector graphic editors. The Inkscape skills I picked up while making the map have come in very handy on multiple occasions since then.

Reading the Mobile App Map:

Our process through the map begins with a requirements analysis or needs assessment. We ask: what does the client want the app to do? What do we know about our end users? How do the affordances of the device affect this? Performing case studies helps us learn about our users before we start designing to meet their needs. In the design stage we want people to make intentional choices about the conceptual and aesthetic aspects of  their app design. Prototype models like wireframe mock-ups, storyboards, or Keynotopia4 prototypes help us visualize these choices, eventually resulting in a working prototype of our app. Stakeholders can test and request modifications to the prototype, avoiding potentially expensive and labor intensive code revisions later in the process.

Once both the designers and clients are satisfied with the prototype and we’ve seen how potential users interact with it, we’re ready to commit our vision to code. Our favored code platform uses HTML 5, CSS 3, jQuery Mobile5, and PhoneGap6 to make hybrid web apps. Hybrid apps are written as web apps–HTML/JavaScript web sites that look and performlike apps–then use a tool like PhoneGap to translate this code into the native format for a device. PhoneGap translates a web app into a format that works with the device’s native programming environment. This provides more direct and thus faster access to device hardware and also enables us to place our app in official app stores. Hybrid apps are not the only available choice and aren’t perfect for every use case. They can be slower than native apps and may have some issues accessing device hardware, but the familiar coding language, multi-device compatibility, and ease of making updates across multiple platforms make them an ideal first step for mobile app design. LITA has an upcoming webinar on creating web apps that employs this system7.

Once the prototype has been coded into a hybrid app, we have another opportunity for evaluation and usability testing. We teach a pervasive approach that includes evaluation and testing all throughout the process, but this stage is very important as it is a last chance to make changes before sending the code to an app marketplace. After the app has been submitted, opportunities to make updates, fix bugs, and add features can be limited, sometimes significantly, by the app store’s administrative processes.

After you have spent some time following the lines of the tube map and reading this very brief description, I hope you can see this infographic as an aid to designing mobile web apps. I find it particularly helpful for identifying the source of a particular problem I’m having and also suggesting tools and techniques that can help resolve it. As a personal example, I am often tempted to start writing code before I’ve completely made up my mind what I want the code to do, which leads to frustration. I use the map to remind me to look at my wireframe and use that to guide the structure of my code. I hope you all find it useful as well.


Making Your Website Accessible Part 2: Implementing WCAG

In Part 1, I covered what web accessibility is, its importance, and the Web Content Accessibility Guidelines (WCAG). This post focuses on how to implement WCAG into the structure and layout of the website (including templates/themes, plugins, etc.). While I will be referring to WCAG, I have based this post on what I have found in terms of general best practices, so hopefully this post is applicable to any site.

Using a Template for Layout

First off, I’m going to assume that at the very least your website uses a template even if it doesn’t use a content management system (CMS). Whether your site is developed in-house or not, the points below should be true, otherwise you’re making your website inaccessible for everyone (not just those with accessibility needs).

A template will help you with:

  • consistent navigation (3.2.3)
  • consistent identification of the different parts of each page (3.2.4) – i.e. you assign ids consistently
  • avoiding tables for layout purposes
  • providing multiple ways to discover content (2.4.5)
  • meaningful order to content (1.3.2) – more details below
  • keyboard accessibility (2.1) by insert bypass blocks (2.4.1) – more details below

To provide multiple ways to content, I’m partial to providing links to related pages (local nav) and a search bar, but there are other options.

  • Ordering Content

A template layout is particularly important for the second to last point, ‘meaningful order to content’. Screenreaders, much like people, read top to bottom. However, people generally read in the order that they see text, but screenreaders read in code order (think when viewing ‘page source’). For example:

<body>
  <div>
    <!-- your main/primary content -->
  </div>
  <div>
    <!-- secondary content, this may be a number of things e.g. local nav -->
  </div>
</body>

If you want your secondary content to show up before your primary content, you can just use CSS to move the divs around visually.

  • Keyboard Navigation

Your site also needs to be accessible by keyboard, and to help screenreader users (and those that use text based browsers), you can allow bypass blocks by inserting an anchor link that would allow users to skip blocks of content that are repeated on the various pages of a website.

For example, you might have a link at the very top of the page to skip to the main menu (global nav) or the content. At the main menu , you again might have something similar. This is just one possible example:

<style type="text/css">
.assistive-text {
    position: absolute !important;
    clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
    clip: rect(1px, 1px, 1px, 1px);
}
a.assistive-text:active,
a.assistive-text:focus {
    background: #eee;
    border-bottom: 1px solid #ddd;
    color: #1982d1;
    clip: auto !important;
    font-size: 12px;
    position: absolute;
    text-decoration: underline;
    top: 0;
    left: 7.6%;
}
</style> [...]
<body>
  <header>
    <a href="#access">Skip to main menu</a>
     <hgroup>
        <h1>Your Library</h1>
        <h2>Tagline</h2>
     </hgroup>
     <nav>
        <!-- Allow screen readers/text browsers to get right to the good stuff -->
        <h3>Main Menu</h3>
        <a href="#content">Skip to content</a>
        <a href="#secondary">Skip to page navigation</a>
        <!-- global nav -->
     </nav>
   </header>
   <!-- rest of page -->
</body>
Responsive Template

A responsive site allows all your users to access and view your site on any size device, screen resolution, and browser window size (within reason). For example, take a look at Grand Valley State Libraries’ website in the desktop and mobile views below.

screenshot

GVSU Libraries’ Website Desktop View

screenshot of GVSU Libraries' Website

Mobile view

If you’re unfamiliar with responsive web design, you may want to take a look at Lisa Kurt’s Responsive Web Design and Libraries post to become more familiar with the topic.

The basic technique to make a site responsive is by using media queries shift the look of the content depending on screen size. Making a site responsive already provides greater access to all your users, but you can take this farther with a simple difference to make your site even more accessible. If you use ‘em’ (instead of pixels) for your media queries (see Matthew Reidma’s Responsive Web Design for Libraries) in your responsive template, you should be able to resize your page up to 200%  without any problems (1.4.4).

As part of your responsive design, also consider that touch screens don’t have the highest precision, so links and any other interactive pieces should not be too small. In general, this also helps users who have difficulty with fine motor skills to navigate your site.

Valid & Proper Markup

Using valid markup is part of the guideline (4.1.1), but you can go further than that by using HTML5 structural tags to define the roles of the various sections of a webpage (4.1.2, 1.3.1). For example, the basic structure of your website might look something like this:

<!DOCTYPE html>
<html lang="en"><!-- every page should specify the language of the page (3.1.1) -->
  <head>
    <title>Every Page Should Have a Title (2.4.2)</title>
  </head>
  <body>
    <header>
      <hgroup>
        <h1>site name</h1>
        <h2>tagline</h2>
      </hgroup>
      <nav>
        <a href='#'>Global Nav Link</a>
        <a href='#'>Second Nav Link</a>
        <a href='#'>More Nav Link</a>
      </nav>
    </header>
      <section>
        <article>
          <!-- your content, a blog post for example -->
          <aside>
            <!-- might have something like quick facts -->
          </aside>
        </article>
        <article>
          <!-- another standalone piece -->
        </article>
      </section>
    <footer>copyright and other info</footer>
  </body>
</html>

You may optionally include more metadata, not only for the benefit of screen readers, but also for indexing purposes.

Presentation

A number of guidelines deal with presentation aspects.

At the very basic level, presentation and layout should be separate from content. So layout control (such as sizes, floats, padding, etc.), colours, fonts, and practically anything you would put in ‘style’ should be done in CSS, separating it from the HTML (1.3.1). Screen readers (and other tools) can override CSS rules or turn CSS off completely, allowing the user to customize the font, colour, link colour, etc.

As the basic colour scheme is determined through the site’s general style sheet, you will also need to make sure that you fulfill the colour specific guidelines. Colour contrast needs to be at least 4.5:1, except logos and large text (18+pt, 14+pt bold), which require a minimum 3:1 ratio (1.4.3). I recommend using the WCAG Contrast Checker Firefox add-on. Here’s an example:

ColorChecker screenshot

It will highlight errors in red, and you can click on any line which will highlight the related element. The only problem is when you have multiple elements layered on top of each other. As you can see in the example, it’s checking the colour of the text ‘Research Help’ against the yellow you see bordering the menu (global navigation), rather than the element right behind the text. So, you do have to vet the results, but it’s a great little tool to help you quickly check the contrast of your text colours, and for images, you can enter numbers manually yourself to easily check the ratio.

Additional Tools

For more tools, like the colour contrast checker, check out the W3C Web Accessibility Tools list. My picks are WAVE (gives you different views, such as text-only) and Fangs (screen reader emulator).

Other Techniques & Reference

There are a lot more techniques that I haven’t covered in the WCAG Quick Reference, but be cautioned that some of these techniques are already obsolete. Follow the guidelines as those are the requirements; the techniques are ways that do fulfill the guidelines, but not the required way to do so.

Scripting & Custom User Interfaces

As this post focuses on HTML/CSS, it does not cover scripts, Flash, or PDF. The WCAG Quick Reference covers these and more.

For custom interfaces, WAI-ARIA should be used in conjunction with WCAG. There are some UI modules that are web accessible already, so I encourage you to use these:

If you’re using plugins, then at least make it a feature request, and consider contributing to the plugin to make it accessible.

Expectations

Libraries in particular use a multitude of tools and services. No one can expect your organization to make all your tools and services web accessible, especially when you likely don’t have full control over all of them. Nevertheless, do what you can, and request/advocate for web accessibility to companies that you have dealings with when it’s not controlled in-house. Even asking whether web accessibility guidelines have been considered or met can start the conversation going, as the developers may have simply not thought about accessibility. There are also some workarounds, such as providing an overlay (which I will cover in the next post in regards to video), but most workarounds I have seen take away functionality for some users, while making it more accessible for others. Always best to have accessibility built-in to a product or site.

The Bottom Line

While there are a few techniques that are specially to make sites accessible for people with disabilities, good, solid design principles will go a long way in making an accessible site for all your users. You also don’t need to redesign your whole site. Consider using the agile development idea and implementing one technique at a time to improve your site over time.

Next Time

In this post, I have focused on the structure and layout of the website, i.e. the elements that you would typically have in themes or templates. I have purposely left out guidelines that deal with the content of a website as many organizations rely on various staff members to populate the site with content (usually through a CMS), including content that might be done  either by IT or non-IT staff, such as forms and audio/visual content. However, all the content related guidelines also apply to any template or generated content (links, images, forms e.g. search bar), which is what I will cover in the third and final post.

About our Guest Author: Cynthia Ng is currently the Web Services Librarian at Ryerson University Library and Archives. While she is especially interested in web development and services, her focus is on integrating technology into the library in a holistic manner to best serve its users. She is a recent MLIS graduate from the University of British Columbia, and also holds a BEd from UBC. She can be found blogging at Learning (Lib)Tech and on Twitter as @TheRealArty.


Mobile App Use Studies Across a Decentralized Research Library

The University of Illinois’ team of IT diversity interns are working on departmental-specific mobile app modules and user studies of those app modules this Fall semester. The Illinois library is a decentralized system of nearly thirty departmental libraries serving diverse needs of staff, researchers, scientists, graduate students, and undergraduate students. Given such a diverse population, we wondered if it was possible to turn our prototyping pipeline to connect with other unit specific needs outside of our own space, the Undergraduate Library.

Specifically, this fall we wanted to understand how departmental collections and other library locations would use our already developed RESTful web services –which serves as the core component of the prototyping pipeline– for departmental and subject based mobile application modules.

This blog post describes the methods we used to quickly gather feedback on new and exciting features for department collections.The mobile application modules we studied include enhanced wayfinding support of multi-story buildings and collections (originally designed for an undergrad space of one level of collections), a reserves module for all libraries, and hours integration into book information data elements.

Enhanced Wayfinding in a Departmental Library

library wayfinding help

We studied the implementation of feature requests in mobile wayfinding apps

 

This module includes a navigation rose in the upper left corner of the mobile interface. Included is functionality for line segments that draw your current location to the location of your desired book in the stacks. The user can get their current location in the book stacks by using the barcode scanner module to scan the book nearest them, which then sets their current location. After setting their current location, any additional book that is then searched for in the library will generate a line segment path to the location of the searched for book.

Turn by turn directional support based on user location is a new enhancement, though we’ve been getting requests a few times in our previous user studies, from 2010-2011 use studies on maps and library wayfinding using mobile devices.

Reserves Module

Reserve access is one of the most requested mobile app features

Reserve access is one of the most requested mobile app features

This reserve program offers the student access to library reserves from an Android device. The multiple drop downs allow the student to select her course reserves by either course, department, or major.

Hours of library locations integrated into book data

hours module

If the item is in a library that is closed, this item may not useful to a student.

Most OPACs will let you know if the book is available. This is not always so straightforward in OPACs that inventory multiple locations. Some of the departmental collections actually have business hours of 9-5, or other limited hours during the weekend, yet the OPAC will show an item as Available so long as the book is not checked out. We tried to address the problem in our display module by adding a location status to the library — this checks against an hours database to let the user know if the library is actually open for the student to check out an available book. 

Rapid use studies

With a number of feature enhancements to our core set of mobile app modules, we wanted to gather empirical data that could inform production services. The fastest way to get user input into modules that may be in the early design phase is to approach users who are currently in the building. In the case of these modules, we were experimenting with the idea of location services in department collections, and the wayfinding support was specific to the ACES library and so we made this our test location.

Once here we approached users with a test set of questions around the modules. We asked what parts of the app are useful for helping the students integrate library resources into their work. We also asked and observed what doesn’t help, and additionally what features would be worthwhile to further develop.

We asked these questions about app modules:

  • Please describe any previous experience finding items in the Funk ACES Library?
  • What software modules help students integrate library content into their course work?
  • How easy to use is the application?
  • Does the student need time to learn how to use the software?
  • What unexpected things occur?
  • How do students react when the application does not work as they expect?
  • Do students make use of the location-based features?

Follow up

After collecting initial use data the team is reshaping a few of the modules to make them easier to use while at the same time brainstorming ideas for making some of the features more evident. One of the key findings of this last round of user studies was that although we implemented a number of requested features, students could not always locate, and then use or in some cases understand the features and how they would help. So we need to think about making the help features more helpful, and more engaging, overall. We theorize that another reason they couldn’t always find the help tools we designed into the ACES modules was the fact that the modular offerings of our experiment have become a bit cluttered.

If you take a look at any of the above screenshots you will notice their were eight included modules in the bottom of the mobile interface for this study. We did put many options in front of the study participants, so the next round of user studies will be more focused on areas we think are worthwhile to develop: particularly the engaging elements of wayfinding, but also the reserves module was called out as the one part that students considered would be most helpful for integrating library resources into their work.

Finally, as we poured over a few of the software choices we made to construct the Android layers, we realized they were not quite modular enough, and so this caused errors in overall functionality of the app during the study. To correct this we are thinking about definitions for the core aspects of modular design.

A final step for our work this semester is to showcase all of our software prototypes to the library staff at the University of Illinois. To that end we are having an open house during finals week, where we are inviting all staff members into our prototyping space and asking also for their feedback on the software developed, and ask staff to try out some of the newest ideas in mobile technology, including our in-development augmented reality shelf browser, which is being coded with funds from a Sparks! IMLS grant. A user study for mobile augmented reality applications is planned this Spring 2013.

Another information technology problem we will work on in the Spring 2013 semester is how to incorporate our RESTful feeds into the library discovery layers. The Music and Performing Arts library location is likely our next collaboration for stacks based wayfinding support inside of the OPAC.

We would like to integrate our wayfinding feed into the OPAC to help students get from the book information to the stacks location, using the RESTful web-services we’ve designed for system efficiency from the onset. The next step for our fledgling prototyping initiative is system integration, which involves taking this prototype work and injecting its most useful and used components into production environments like our VuFind search and our Primo discovery layer.

 

See also:

Huang, Y.M., Wu, D.F., Guo, Q. (2009), “Build a RESTful Web service using Jersey and Apache Tomcat,” http://www.ibm.com/developerworks/web/library/wa-aj-tomcat/

Jones, T. & Richey, R. (2000), “Rapid Prototyping methodology in action: a developmental study,”Educational Technology Research and Development 48, 63-80

Prototyping as a Process for Improved User Experience with Library and Archives Websites: http://journal.code4lib.org/articles/7394

Rapid Prototyping a Collections-Based  Mobile Wayfinding Application:
http://hdl.handle.net/2142/24001

 

 


Learning Web Analytics from the LITA 2012 National Forum Pre-conference

Note: The 2012 LITA Forum pre-conference on Web Analytics was taught by Tabatha (Tabby) Farney and Nina McHale.  Our guest authors, Joel Richard and Kelly Sattler were two of the people who attended the pre-conference and they wrote a summary of the pre-conference to share with the ACRL TechConnect readers.

In advance of the conference, Tabby and Nina reached out to the participants ahead of time with a survey on what we the participants were interested in learning and solicited questions to be answered in the class.  Twenty-one participants responded and of them seventeen were already using Google Analytics (GA).  About half those using GA check their reports 1-2 times per month and the rest less often.  The conference opened with introductions and a brief description of what we were doing with analytics on our website and what we hoped to learn.

Web Analytics Strategy

The overall theme of the pre-conference was the following:

A web analytics strategy is the structured process of identifying and evaluating your key performance indicators on the basis of an organization’s objectives and website goals – the desired outcomes, or what you want people to do on the website.

We learned that beyond the tool we use measure our analytics, we need to identify what we want our website to do.  We do this by using pre-existing documentation our institutions have on their mission and purpose as well as the mission and purpose of the website and who it is to serve. Additionally, we need a privacy statement so our patrons understand that we will be tracking their movements on the site and what we will be collecting. We learned that there are challenges when using only IP addresses (versus cookies) for tracking purposes.  For example, does our institution’s network architecture allow for you to identify patrons versus staff using IP address or are cookies a necessity?

Tool Options for Website Statistics

To start things off, we discussed the types of web analytics tools that are available and which we were using. Many of the participants were already using Google Analytics (GA) and thus most of the activities were demonstrated in GA as we could log into our own accounts.  We were reminded that though it is free, GA keeps our data and does not allow us to delete it.  GA has us place a bit of Javascript code on the pages we want tracked. It is easier to set up GA within a content management system but it may not work as well for mobile devices.  Piwik is an open-source alternative to Google Analytics that uses a similar Javascript tagging method.  Additionally we were reminded that if we use any Javascript tagging method, we should review our code snippets least every two years as they do change.

We learned about other, less common systems for tracking user activity. AWStats is installed locally and reads the website log files and processes them into reports.  It offers the user more control and may be more useful for sites not in a content management system.  Sometimes it provides more information than desired and will be unable to clearly differentiate between users based on IP.  Other similar tools are Webalizer, FireStats, and Webtrends.

A third option is to use Web Beacons which are small, invisible transparent GIFs embedded on every page.  This is useful for when Javascript won’t work, but they probably aren’t as applicable today as they once were.

Finally, we took a brief look at the heat mapping tool, Crazy Egg.  It focuses on visual analytics and uses Javascript tagging to provide heat maps of exactly where visitors clicked on our site offering insights as to what areas of a page receive the most attention.  Crazy Egg has a 30 day free trial and then it costs per page tracked, but there are subscriptions for under $100/month if you find the information worth the cost.  The images can really give webmasters an understanding of what the users are doing on their site and are persuasive tools when redesigning a page or analyzing specific kinds of user behavior.

Core Concepts and Metrics of Web Analytics

Next, Tabby and Nina presented a basic list of terminology used within web analytics.  Of course, different tools refer to the same concept by different names, but these were the terms we used throughout our session.

  • Visits – A visit is when someone comes to the site. A visit ends when a user has not seen a new page in 30 minutes (or when they have left the site.)
  • Visitor Types: New & Returning – A cookie is used to determine whether a visitor has been to the site in the past. If a user disables cookies or clears them regularly, they will show up as a new user each time they visit.
  • Unique Visitors – To distinguish visits by the same person, the cookie is used to track when the same person returns to the site in a given period of time (hours, days, weeks or more).
  • Page Views – More specific than “hits,” a page view is recorded when a page is loaded in a visitor’s browser.
  • User Technology – This includes information about the visitor’s operating system, browser version, mobile device or desktop computer, etc.
  • Geographic Data – A visitor’s location in the world can often be determined to which city they are in.
  • Entry and Exit Pages – These refer to the page the visitor sees first during their visit (Entry) and the last page they see before leaving or their session expires (Exit).
  • Referral Sources – Did the visitor come from another site? If so, this will tell who is sending traffic to us.
  • Bounce Rate – A bounce is when someone comes to the site and views only one page before leaving.
  • Engagement Metrics – This indicates how much visitors are on our site measured by time they spent on the site or number of pages viewed.
Goals/Conversion

Considering how often the terms “goals” and “conversions” are used, we learned that it is important to realize that in web analytics lingo, a goal is a metric, also referred to as a conversion, and measures whether a desired action has occurred on your site. There are four primary types of conversions:

  1. URL Destination – A visitor has reached a targeted end page.  For commercial sites, this would be the “Thank you for your purchase” page. For a library site, this is a little more challenging to classify and will include several different pages or types of pages.
  2. Visit Duration – How much time a visitor spends on our site. This is often an unclear concept. If a user is on the site for a long time, we don’t know if they were interrupted while on our site, if they had a hard time finding what they were looking for, or if they were enthralled with all the amazing information we provide and read every word twice.
  3. Pages per Visit – Indicates site engagement. Similar to Visit Duration, many pages may mean the user was interested in our content, or that they were unable to find what they were looking for.  We distinguish this by looking at the “paths” of page the visitor saw.  As an example, we might want to know if someone finds the page they were looking for in three pages or less.
  4. Events – Targets an action on the site. This can be anything and is often used to track outbound pages or links to a downloadable PDF.

Conversion rate is an equation that shows the percentage of how often the desired action occurs.

Conversion rate = Desired action / Total or Unique visits

Goal Reports also known as Conversion Reports are sometimes provided by the tool and include the total number of conversions and the conversion rate.  We learned that we can also assign a monetary value to take advantage of the more commerce-focused tools often used in analytics software, but the results can be challenging to interpret.  Conversion reports also show an Abandonment Rate as people leave our site. However, we can counter this by creating a “funnel” that identifies the steps needed to complete the goal. The funnel report shows us where in the steps visitors drop off and how many make it through the complete conversion.

Key Performance Indicators (KPIs) were a focus of much of the conference.  They measure the outcome based on our site’s objectives/goals and are implemented via conversion rates.  KPIs are unique to each site.  Through examples, we learned that each organization’s web presence may be made up of multiple sites. For instance, an organization may have its main library pages, Libguides, the catalog, a branch site, a set of sites for digitized collections, etc. A KPI may span activities on more than one of these sites.

Segment or Filter

We then discussed the similarities and differences between Segments and Filters, both of which offer methods to narrow the data enabling us to focus on a particular point of interest.  The difference between the two is that (i) filtering will remove the data from the collection process thereby resulting in lost data; whereas (ii) segmentation hides data from the reports leaving it available for other reports. Generally, we felt that the use of Segments was preferable over Filters in Google Analytics given that it is impossible to recover data that is lost during GA’s real-time data collection.

We talked about the different kinds of segments that some of us are using. For example, is Joel’s organization, he is using a technique to segment the staff computers in their offices from computers in the library branches by adding a query string to the homepage URL of the branch computers’ browsers. Using this, he can create a segment in Google Analytics to view the activity of either group of users by segmenting on the different Entry pages (with and without this special query string). Segmenting on IP Address also further segregates his users between researchers and the general public.

Benchmarking

As a step towards measuring success for our sites, we discussed benchmarking, which is used to look at the performance of our sites before and after a change. Having performance data before making changes is essential to knowing whether those changes are successful, as defined by our goals and KPIs.

Comparing a site to itself either in a prior iteration or before making a change is called Internal Benchmarking. Comparing a site to other similar sites on the Internet is known as External Benchmarking. Since external benchmarking requires data to make a comparison, we need to request of another website their data or reports. Another alternative is to use service sites such as Alexa, Quantcast, Hitwise and others, which will do the comparison for you.  Keep in mind that these may use e-commerce or commercial indicators which may not make for a good comparison to humanities-oriented sites.

Event Tracking

Page views and visitor statistics are important for tracking how our site is doing, but sometimes we need to know about events that aren’t tracked through the normal means. We learned that an Event, both in the conceptual sense and in the analytics world, can be used to track actions that don’t naturally result in a page view. Events are used to track access to resources that aren’t a web page, such as videos, PDFs, dynamic page elements, and outbound links.

Tracking events doesn’t always come naturally and require some effort to set up. Content management systems (CMS) like Drupal help make event tracking easy either via a module or plugin or simply by editing a template or function that produces the HTML pages.  If a website is not using a CMS the webmaster will need to add event tracking code to each link or action that they wish to record in Google Analytics. Fortunately, as we saw, the event tracking code is simple and easy to add to a site and there is good documentation describing this in Google’s Event Tracking Guide documentation.

Finally, we learned that tracking events is preferable to creating “fake” pageviews as it does not inflate the statistics generated by regular pageviews due to the visitors’ usual browsing activities.

Success for our websites

Much of the second half of the conference was focused on learning about and performing some exercises to define and measure success for our sites. We started by understanding our site in terms of our Users, our Content and our Goals. These all point to the site’s purpose and circle back around to the content delivered by our site to the users in order to meet our goals. It’s all interconnected. The following questions and steps helped us to clarify the components that we need to have in hand to develop a successful website.

Content Audit – Perform an inventory that lists every page on the site. This are likely to be tedious and time-consuming. It includes finding abandoned pages, lost images, etc.  The web server is a great place to start identifying files.  Sometimes we can use automated web crawling tools to find the pages on our site.  Then we need to evaluate that content. Beyond the basic use of a page, consider recording last updated date, bounce rate, time on page, whether it is a landing page or not, and who is responsible for the content.

Identifying Related Sites – Create a list of sites that our site links to and sites that link back to our site.  Examples: parent site (e.g. our organization’s overall homepage), databases, journals, library catalog site, blog site, flickr, Twitter, Facebook, Internet Archive, etc.

Who are our users? – What is our site’s intended audience or audiences? For us at the conference, this was a variety of people: students, staff, the general public, collectors, adults, teens, parents, etc. Some of us may need to use a survey to determine this.  Some populations of users (e.g. staff) might be identified via IP Addresses. We were reminded that most sites serve one major set of users with other smaller groups of users served. For example, students might be the primary users whereas faculty and staff are secondary users.

Related Goals and plans – Use existing planning documents, strategic goals, a library’s mission statement to set a mission statement and/or goals for the website. Who are we going to help? Who is our audience?  We must define why our site exists and it’s purpose on the web.  Generally we’ll have one primary purpose per site. Secondary purposes also help define what the site does and fall under the “nice to have” category, but are also very useful to our users. (For example, Amazon.com’s primary purpose is to sell products, but secondary purposes include reviews, wishlists, ratings, etc.)

When we have a new service to promote, we can use analytics and goals to track how well that goal is being met. This is an ongoing expansion of the website and the web analytics strategy.  We were reminded to make goals that are practical, simple and achievable. Priorities can change from year to year in what we will monitor and promote.

Things to do right away

Nearing the end of our conference, we discussed things that we can do improve our analytics in the near term. These are not necessarily quick to implement, but doing these things will put us in a good place for starting our web analytics strategy. It was mentioned that if we aren’t tracking our website’s usage at all, we should install something today to at least begin collecting data!

  1. Share what we are doing with our colleagues. Educate them at a high level, so they know more about our decision making process. Be proactive and share information; don’t wait to be asked what’s going on. This will offer a sense of inclusion and transparency. What we do is not magic in any sense. We may also consider granting read-only access to some people who are interested in seeing and playing with the statistics on their own.
  2. Set a schedule for pulling and analyzing your data and statistics. On a quarterly basis, report to staff on things that we found that were interesting: important metrics, fun things, anecdotes about what is happening on our site. Also check our goals that we are tracking in analytics on a quarterly basis; do not “set and forget” our goals. On monthly basis, we should report to IT staff on topics of concern, 404 pages, important values, and things that need attention.
  3. Test, Analyze, Edit, and Repeat. This is an ongoing, long-term effort to keep improving our sites. During a site redesign, we compare analytics data before and after we make changes. Use analytics to make certain the changes we are implementing have a positive effect. Use analytics to drive the changes in our site, not because it would be cool/fun/neat to do things a certain way. Remember that our site is meant to serve our users.
  4. Measure all content. Get tracking code installed across all of our sites. Google Analytics cross-domain tracking is tricky to set up, but once installed will track users as they move between different servers. Examples for this are our website, blog, OPAC, and other servers. For things not under our control, be sure to at least track outbound to know when people leave our site.
  5. Measure all users. When we are reporting, segment the users into groups as much as possible to understand their different habits.
  6. Look at top mobile content. Use that information to divide the site and focus on things that mobile users are going to most often.
Summary

Spending eight hours learning about a topic and how to practically apply it to our site is a great way to get excited about taking on more responsibilities in our daily work. There is still a good deal of learning to be done since much of the expertise in web analytics comes from taking the time to experiment with the data and settings.

We, Kelly and Joel, are looking forward to working with analytics from the ground-up, so to speak. We are both are in an early stage of redeploying our website under new software which allows us to take into account the most up-to-date analytics tools and techniques available to us. Additionally, our organizations, though different in their specific missions and goals, are entering into a new round of long-term planning with the result being a new set of goals for the next three to five years. It becomes clear that the website is an important part of this planning and that the goals of our websites directly translate into actions that we take when configuring and using Google Analytics.

We both expect that we will experience a learning curve in understanding and applying web analytics and there will be a set of long-term, ongoing tasks for us. However, after this session, we are more confident about how to effectively apply and understand analytics towards tracking and achieving the goals of our organization and create an effective and useful set of websites.

About our Guest Authors:

Kelly Sattler is a Digital Project Librarian and Head of Web Services at Michigan State University.  She and her team are involved with migrating the Libraries’ website into Drupal 7 and are analyzing our Google Analytics data, search terms, and chat logs to identify places where we can improve our site through usability studies. Kelly spent 12 years in Information Technology at a large electrical company before becoming a librarian and has a bachelor’s degree in Computer Engineering.  She can be found on twitter at @ksattler.

Joel Richard is the lead Web Developer for the Smithsonian Libraries in Washington, DC and is currently in the process of rebuilding and migrating 15 years’ worth of content to Drupal 7. He has 18 years of experience in software development and internet technology and is a confirmed internet junkie. In his spare time, he is an enthusiastic proponent of Linked Open Data and believes it will change the way the internet works. One day. He can be found on twitter at @cajunjoel.


Making Your Website Accessible Part 1: understanding WCAG

With more and more services and resources becoming digital, web accessibility has become an ever increasingly important topic. As a result, I thought a summary of my findings would be useful to others that are involved with web services.

What is Web Accessibility?

Some define web accessibility to mean making the web accessible to those with disabilities (including visual, auditory, motor, and cognitive) 1. However, I prefer the more general meaning of making the web accessible equally to everyone, including those with disabilities 2. To take this further, regardless of whether someone has a disability, they should be able to access information in their preferred manner including using any browser, operating system, or device.

A quick (but common) example of a problem is how a user is expected to control a video if they cannot use a mouse to click on buttons (they may depend on a keyboard or be visually impaired), especially when most videos still use some form of Flash. Try it sometime, and see what happens. Web accessibility guidelines, such as WCAG, attempt to address these issues.

What is WCAG?

The Web Content Accessibility Guidelines are just that, a set of guidelines, written by the Web Accessibility Initiative (WAI) group of the W3C. Currently, it’s at version 2.0, but many organizations still use version 1.0 (usually with modifications to make it more current).

  • The Breakdown of WCAG

Many (myself included) find WCAG to be difficult to navigate and comprehend. To get a better idea of ideas behind the guidelines, reading a summary can be of great help. The WCAG part of the Web Accessibility Initiative (WAI) site provides a good summary of the guidelines:

Perceivable

Operable

Understandable

Robust

-WCAG 2.0 at a Glance

Even if you don’t follow the specifics of WCAG, these are good general guidelines for web accessibility. While many of these might seem like common sense, the average person will not be detrimentally affected by not following guidelines. Also, some actually can have grave consequences (I always like to point out that content should not cause seizures).

WCAG 2.0 as a Mind Map by Avoka

The specific guidelines expand on these ideas and provide more detail on how each guideline might be met. To wade through the specifics, I suggest using the quick reference, How to Meet WCAG 2.0, and use the customization based on your current technologies and focus. By unchecking everything, except the level(s) you expect to meet, it also provides a good checklist.

  • A Note on Techniques

In most cases, the sufficient techniques and failures listed under each guideline are quite useful as examples of how you might meet (or fail) each guideline. On the other hand, the techniques are “informative” and are not necessarily the best method in fulfilling a given guideline. (See my critcism below.) You might also give advisory techniques a glance if you’re keen on knowing how to further enhance accessibility, but then my view is that there is enough to deal with without getting into even more detail.

Criticisms & Lessons Learned

WCAG is not without criticism. The wikipedia article on web accessibility gives a nice short blurb and links to articles of interest. From what I’ve read, the three most compelling arguments against WCAG2.0 specifically are that:

  • Level AAA is impractical to meet,
  • even at Level AAA, meeting WCAG2.0 does not make your website accessible, and
  • the documentation is difficult to navigate/understand.

To briefly explain the second point, as I mentioned, part of web accessibility is to make your website easily accessible on any device, but WCAG does not directly address this issue (which you could address for example through responsive design, as explained by Lisa in the last TechConnect post).

My biggest criticism though of WCAG2.0 is that the documentation (in particular, the techniques) is not current.

For example, under Sufficient Techniques for 1.3.1, Technique H73 tells you to use the summary attribute in table elements to provide an overview of what a given table is about. However, the summary attribute in HTML5 is deprecated (which I didn’t discover until I put a page with a table through the W3C validator).

Why Should You Care?

Despite its shortcomings, WCAG provides an excellent (base) set of guidelines to follow. Even if you choose not follow WCAG, consider customizing it to fit your organization’s needs.

  • Increased Access

If you’re reading this, you’re more than likely working at a public institution of some sort. Public institutions serve a very diverse group of people, and while persons with disabilities is a minority, we’re to serve one minority as well as any other and the majority as well (at least ideally).

Improving web accessibility helps a diverse audience in and of itself. Everything from mild to more extreme cases, the guidelines help to serve:

  • blind users, who will use screen readers
  • low vision users, who may use screen readers or magnifying tools
  • colourblind users
  • mobility impaired users, who might only use a keyboard
  • users with cognitive or learning disabilities
  • and more…

While in many cases serving one minority can mean taking away from another, that’s not the case here. You can easily improve your site to meet web accessibility requirements without negatively impacting the rest of your audience in any way (it simply might not make any difference).

  • Legislation: AODA Regulations

Legislation and regulations are additional reasons to adhere to a set of web accessibility guidelines. Even if it’s not legislated, most institutions (public and private) will have policies and/or mandates that require or promote equal/equivalent access to all users.

In Ontario, Canada we have the Accessibility for Ontarians with Disabilities Act (AODA), which states that under Section 14, subsection 4:

  • By January 1, 2014, new internet websites and web content on [public sector] sites must conform with WCAG 2.0 Level A.
  • By January 1, 2021, all internet websites and web content must conform with WCAG 2.0 Level AA, other than,
    • success criteria 1.2.4 Captions (Live), and
    • success criteria 1.2.5 Audio Descriptions (Pre-recorded).

Different countries and provinces/states obviously have different regulations, and I’m not really familiar with others, but I know that many of them use WCAG as well.

If you’re in the US, check out the Section 508 Government website. It focuses on the government regulations for their own departments, but includes lots of resources.

In academic libraries, I would also highly recommend contacting the equivalent disabilities support office (frequently called Access Centre), as they will provide support for staff dealing with accessibility issues.

  • Better for Everyone

While web accessibility generally focuses on providing and improving access for persons with disabilities, making sure your site follow a set of guidelines can also improve the experience of your other users as well.

Even something as simple as providing alternative text for images can help ‘regular’ users. What if their internet or your site is slow? What if they blocked (larger) images because they’re on a data plan? What if they’re using a text only browser? (While rare nowadays, not completely unheard of.) Much like when using a screen reader, having alternative text for images means a user would know what they’re missing and if it’s important.

Provided the ideal circumstances, some guidelines can still provide a better user experience.

Make text readable and understandable. -Guideline 3.1

Who wouldn’t want their user to be able to read and understand their site? Making content consistent across the site also improves navigation and browsability of a site.

We all access the web differently. Heck, I have a script blocker, flash blocker, and ad blocker all installed on every browser I regularly use. I really like sites that allow me to use them without unblocking any of those, because I believe that users should be able to do at least the basic things of any given website without ads, scripts, and flash. Web accessibility guidelines can help you make your site more accessible for everyone, and provide a better user experience.

The One-Liner

Basically, WCAG is a good source of information and a good set of guidelines to follow. While you need to be cautious of some of the finer details, making your site meet web accessibility guidelines can improve your site not only for those with special needs, but for your regular users as well.

 

About our Guest Author: Cynthia Ng is currently the Innovative Technologies Librarian (and also filling in for the Web Services Librarian) at Ryerson University Library and Archives. While she is especially interested in web development and services, her focus is on integrating technology into the library in a holistic manner to best serve its user. She is a recent MLIS graduate from the University of British Columbia, and also holds a BEd from UBC. She can be found blogging at Learning (Lib)Tech and on Twitter as @TheRealArty.


Responsive web design and libraries

Brad Frost's This is Responsive Website

Brad Frost’s This is Responsive Website via desktop browser

Responsive web design is not really a new concept, yet libraries and many websites in general, still have a way to go in adopting this method of web design. ACRL’s Tech Connect has covered various web design topics, including mobile applications, hybrid mobile applications, design basics, and website readability. Consider the responsive web design approach and its benefits another tool in your toolbelt and yet another option for libraries to present themselves online to their users.

So what is it?

As the number of devices in which we are able to view and interact with websites grow, it becomes more cumbersome to keep up with the plethora of laptops, desktops, mobile devices, and potentially devices or platforms that don’t yet exist. As our users view our websites and online resources in these various ways, we must ask the simple question- what does this look like and what is the user’s experience? If you have a smart phone or tablet, you may recall viewing a website and being annoyed that it is merely a shrunken teeny version of the site you’re used to seeing rather than adjusting nicely to accommodate the device you’re using. In many cases it requires you, the user, to do something to make it work on your device rather than accomodate you; a rather unappealing way to treat users I think. Here’s an examples from the New York Times website:

New York Times displayed on a desktop browser

New York Times displayed on a desktop browser

New York Times displayed on the iphone

New York Times displayed on the iphone aka the Barbie sized website

To avoid these awful Barbie-sized websites on our devices, the solutions we often see are: develop a mobile website, develop a mobile app, or create a website that is responsive and can handle most anything that comes it’s way. All of these are great solutions to developing a mobile presence however the responsive approach is fast emerging as a winning solution.

What makes it great?

The very basic benefit to creating a responsive website design is that you have one site for all devices- it’s intended to be inclusive for desktop machines and a variety of devices. A responsive site does not require anything of the user; no downloading or additional buttons to click, the result is immediate. That’s it. Rather than separate approaches for mobile through either a mobile site or mobile applications and then another approach for desktop machines- this method is flexible and covers it all under one design.

Responsive websites in the wild

The best way to experience responsive web design is to try out some websites that are designed in this way. Here are a few great examples with screenshots included- I recommend checking them out in your browser and then shrinking your browser window down to get the full effect or how this technology works. If you’re even more invested in the experience, bring the site up on any number of devices to see the benefits of responsive design done well.

Graphic designer, John Boilard, showcases his portfolio website using responsive design:
http://jpboneyard.com/ As you can see the images are flexible and each project displays very well on many devices. The images adjust accordingly and the performance of the site is easy to use and easy to view.

JP Boneyard Design viewed on a desktop browser

JP Boneyard Design viewed on a desktop browser

JP Boneyard design viewed on an iphone

JP Boneyard design viewed on an iphone

Web designer and the founder of responsive design, Ethan Marcotte, http://ethanmarcotte.com/ showcases not only his design but also his publications. There is a variety of content on his website and the responsive design works extremely well. For a quick article on responsive design from the graphic design perspective, see his article on A List Apart.

Ethan Marcotte website via desktop browser

Ethan Marcotte website via desktop browser

Ethan Marcotte website via the iphone

Ethan Marcotte website via the iphone

Matthew Reidsma, web services librarian at Grand Valley State University, also has a fantastic flexible site where even videos are responsive: http://matthew.reidsrow.com/ He is a web librarian to watch as he often writes and presents on responsive design (more on that below) and he is always creating really awesome and interesting web projects. The Grand Valley State University Libraries have a fantastic responsive site: http://gvsu.edu/library/

Matthew Reidsma's website via desktop browser

Matthew Reidsma’s website via desktop browser

 

Matthew Reidsma's website via iphone

Matthew Reidsma’s website via iphone

Grand Valley State University Libraries website via desktop browser

Grand Valley State University Libraries website via desktop browser

Grand Valley State University Libraries website via iphone

Grand Valley State University Libraries website via iphone

The website TitleCase, co-founded by designers and type experts, Jessica Hische and Erik Marinovich; this is an elegant example of showcasing this side project with a focus on type while all giving users a pleasant experience through responsive design.

TitleCase website via desktop browser

Title Case website via desktop browser

TitleCase website via iphone

Title Case website via iphone

Scribble Tone, the Portland, OR based design studio, created this responsive website for Design Week Portland: http://www.designweekportland.com/#footer With the gorgeous flexible images, the bold colors, and clear typefaces- all created and designed responsively- this website is pleasant and fun to use.

Portland Design Week website via desktop browser

Portland Design Week website via desktop browser

Portland Design Week website via iphone

Portland Design Week website via iphone

Resources

If you were like me and did not attend ALA Annual this year and get to see Matthew Reidma’s fantastic talk on Responsive Web Design for Libraries: Get Beyond the Myth of the Mobile Web, you are still in luck because he posted the talk and slides on his website here. He covers quite a lot and he provides a fantastic list of resources within that post. It’s a great presentation and truly worth watching all the way through.

To delve in more deeply into the details of designing with responsive web methods, I highly recommend Responsive Web Design by Ethan Marcotte. He not only provides good examples and techniques for designing this way, but he also explains the flexible grid and flexible images as well and displays his balanced approach between good design and good functionality. His website is also responsive and he’s designed complex websites: http://ethanmarcotte.com/

Another option, particularly for those who use WordPress as a CMS, there are a number of free responsive themes available that are already designed. Simply selecting the theme or taking a further step by creating a child theme that you could then customize would be a fairly simple way to make your website design responsive and more enjoyable.

The website, This is Responsive has a wide variety of tools to develop your own responsive website as does Bootstrap. So even if you don’t think of yourself as a designer, there are a lot of ways to get started in creating good design that is also responsive.

Whether you are interested in responsive design, mobile websites, or creating mobile apps, it is critical for libraries to be aware of the user experience as our customers use our websites and online resources on a variety of devices. The bar is being raised with responsive designed websites and users will come to expect this kind of experience. As the web, platforms, and devices evolve, it will be crucial for libraries to be already poised to offer a positive experience through good thoughtful design.

Brad Frost's This is Responsive Website via iphone

Brad Frost’s This is Responsive Website via iphone


Big Type and Readability

The Big Type

Jeffrey Zeldman published a post that explains his choice of big type in his website/blog last week. If you are curious about how huge the type is in his site, see below my screenshot (or visit his site: http://zeldman.com). It is pretty big. Compare it to any Web site or this current site of mine. Yea, the type is huge.

zeldman.com

He says people either hate or love the big type and the simplistic/minimalist layout of his site or just spends time processing them. I found myself loving it because hey, it was so fr**king easy to read without any other distraction in the site. As Zeldman himself says, It’s over the top but not unusable nor, in my opinion, unbeautiful.” And in my opinion, being fully functional counts to a great degree in favor of beauty.

Readability

The strange satisfaction that I felt while reading the articles in his site set in the big type has led me to realize how hard it is to read the main content of any common web page. It is usually so hard that the first thing I do before reading any Web page is to increase the font size inside a Web browser (thereby also removing the top navigation and all other things on both sides except the main content out of my sight). Sometimes, I also use the ‘Print’ preview, just to read, not to print anything (since this removes all ads and images etc.). Also handy is a plugin like Readability. Zeldman’s site was the first site where none of these actions was necessary.

The Web design convention with must-have items such as a top navigation, header image, navigation on the left, ads and numerous links on the right forces us to take out those very items by manually manipulating the browser in order to make the main content simply readable! This is an irony that is more than fully appreciated by those who build and manage Web sites in particular. We (the universal we as Web workers) follow the convention as something canonical because we want to build a Web site that is usable and pleasant to interact with. But while interacting with any such conventional site, our own behavior reveals that we try to eliminate those very canonical elements.

It’s not that we can or should eliminate right away all those conventional items. They are useful for various purposes. But the point is that no matter how useful they are, those things are also great distractions in reading. In a Web site or a page where reading is the primary activity, the readability of its content is a greater problem than other sites or pages. Zeldman’s Big Type experiment would be simply bizarre if it is applied without any modification to, say, the WSJ homepage. But it probably is not a bad idea to apply it to an individual article page in the WSJ Web site.

Zeldman’s experimental design with the big type reminds me of what the application, Flipboard, does. (See below the demo video if you are not familiar with the Flipboard app.) It strips off elements that are distracting to reading and re-formats the page in a way that is attractive and functional. Where the design fails to help one to read a Web page, an app comes to rescue.

Now you may ask how all these relate to libraries. My question is: (a) how much of the main function of a library Web site is reading, and how much is not, (b) what parts of a library Web site is to be read and not, and (c) how we can balance and facilitate those different uses of a library Web site. Rarely a Web site is designed solely for reading, but reading is an important part of almost always a certain section of any Web site. So this is an issue that is worth thinking about and matters to not only library Web sites but also any other Web site. Just asking these questions could be a good step towards making your Web pages more usable.

In the next post, I will discuss how we read on the Web and how to design and serve the content for the Web in a user-friendly manner.


Design 101: design elements, part 1

Previously, I wrote about the importance of design in libraries and the design process.  Next I’d like to delve in deeper and talk about the elements of design. These elements, or components, are the pieces that make up a whole design. Design elements work together to create a successful design that communicates to your audience if used well.

Most designers would agree, the elements of design are essentially the following:

  • color
  • shape
  • line
  • space or composition
  • value
  • size
  • texture

I am also going to add typography. Though not traditionally an element, choosing type carefully and in some cases even showcasing it within your design, can transform something that meets the status quo into a higher quality design. In carefully crafting your design with an understanding of the elements, your design may be considered not only professional, but memorable.

Rather than talk about all of the elements in this post. I’m going to focus on three to get you started and then I’ll come back to typography and perhaps others in future posts.

With color, composition, and size down, you can create a strong design whether you are making a flyer, sign, promotional materials, or webpage. To create a design considered high quality, nuanced, or sophisticated by design standards, you will need to push further and understand all of the elements. This post is just to get yourself started and able to make something professional that will add to your credibility as a professional organization.

http://frankandjan.com/WIT/?tag=comic-sans

Some have asked me in the past, what credibility has to do with design and libraries and it’s a good question. Without delving too deeply, you can see the above photo where someone has made a simple sign using the typeface comic sans and in response someone calls them out for being unprofessional in using it. Honestly, I have mixed feelings about this image but it still illustrates a valid point: in creating bad design or making poor design choices, you may look unprofessional to your audience. Good design will build trust and credibility with your users. I’ll be including examples throughout this post to show different elements and where they work.

Color

Starting with color, there is an enormous amount of resources on color theory and designing with color. There are scholars who have made a living on researching color alone. To have a successful design, you don’t need to be a color expert but it helps if you have some basics down to understand how color works and doesn’t. It’s a choice to include color in your design- plenty of successful designs are black and white or have minimal color and it’s part of the aesthetic and the message they want to convey.

Sometimes one color is enough; this is called a monochromatic color scheme.

Employing the use of opposite colors on the spectrum together is complementary.

There are numerous ways of combining colors and using them effectively in design. When using color the most important piece to keep in mind is using color consciously, thoughtfully and being aware of individuals who may have vision impairments. You can use many colors in a design, but if not done so with care, it may not achieve the look or convey the message intended. In some cases, misuse of color may not be readable. There are a number of resources available that can assist in putting together a good color palette as well ensuring your colors are accessible.

The designer Luke Beard applies color well on his website. While Beard uses color minimally, as you stay on his website, the color rotates revealing various color combinations in a fun and eye-catching way. The selected colors compliment his website and overall design. If you don’t stay on the page long enough to experience the change in color, you don’t lose much value since the colors work well and the design itself is successful and strong. The change in color is an additional feature intended to delight his audience.
http://lukesbeard.com/

Composition

Composition is where the pieces lay on the page in relation to the page sides, edges and other pieces. Composition may include: an illustration or a logo, title text, headlines, or a call to action, and smaller elements such as a block of text or links. There is a decision to be made about what the most important elements are. Not every element should have the same amount of weight in importance.

In laying out the composition, you’ll want to pay attention to what is referred to as alignment. Often in design you’ll see a strong left alignment where several elements begin at the same starting point on a page; this is fairly conventional and a good choice. Left alignment is certainly not the only successful way to create a composition, but it rarely fails. As the design is being formed it’s good to think of the elements and pieces you are working with abstractly. Imagine them as puzzle pieces or building blocks. Many designers use methods such as the grid, wireframing, or abstract sketching to get a rough sense of the composition. The grid is a good place to start and is a current design trend. My best advice is as you build together the pieces, keeps things somewhat loose and flexible so that you think of the overall page and the pieces in relation to each other, rather than get bogged down by one piece.

http://www.jessicahische.is/designing

On Jessica Hische’s website, she balances a lot of information on each page without losing the quality of the overall design. She showcases portfolio pieces and allows those designs to shine while the composition, typography, and color compliment her efforts and don’t compete for attention. To the right of the large image, Hische aligns the subheading and links to the left, along with the various elements below the link list. Organizing the site in this way creates order and contributes positively to the overall design. Hische devotes a good deal of the composition to white space. Doing so allows the viewer’s eye to rest and directs them back toward the focus, in this case the photo and information on the portfolio piece she is showcasing.

Size

Size is related to composition in that the size of one shape or block of text will relate to others around it.

So, for example, if you have a title, subtitle, author, and publisher and you want to emphasize the title above everything else, then the title will naturally be larger in size. Next, you may want the subtitle to be less than the title but larger than the author or publisher. In some cases, you may want to make the author name the largest element- these are all design decisions relating to size that will convey different things to the audience who sees it.

http://trentwalton.com/2011/05/10/fit-to-scale/

On Trent Walton’s website, he’s making a point about responsive web design (a topic I hope to delve into in a future post). To communicate his message, he’s using size and color. The bold color and size of the title, Fit to Scale, captures viewer’s attention. There is also variation in size within the text block, drawing out the first sentence for emphasis. The navigation is also a different size, easy to see when it’s needed but not in the way of the message of the page.

Putting design into practice

Now that we’ve gone over some basics, I recommend exploring what designs out there speak to you. Develop a collection of designs you like; whether they are websites, flyers, posters, etc., if there is something you like about the design then study it. Much like writers who read a lot to become better writers, designers will study good design and analyze what makes it good in order to become a better designer.

Get feedback from other designers or others who understand design. There are a number of excellent portfolio websites out there that have extremely rich communities willing to offer a critique in exchange for a critique. These are excellent resources that are invaluable to designers, as meaningful feedback is very difficult to find:

Look more deeply into what elements the designer has employed to make the design successful and ask yourself some questions: what colors did they use? what is the balance between the different colors used? is there whitespace? how is the composition set up? can you identify alignments? how did the designer break apart size?

If there is a design you don’t like it is worth exploring why you don’t like it. Ask the same kinds of questions. What makes it fail to you? Figure out what it is that makes you react strongly

This is a way to get yourself to really think in a design way, observe, and subsequently learn about design. In seeing, you will be a step closer to designing well.

If you can recognize, study and thoughtfully employ these elements and make them work together harmoniously you can make a good design. Keep things simple- better to err on the side of restraint than give too much.

Don’t forget that in designing, you are communicating. Think about the message. What do you want to say and how can you attempt to convince your users to believe you? Are you earning credibility? Trust? What kind of atmosphere are you creating?

Design is an opportunity to give our users a positive experience and perhaps even to delight them.