Sometimes it’s the Browser, not your Code

As a beginner coder, I generally assume that if something goes wrong it’s my code. While it’s true that a website needs to be coded in such a way that it’s interoperable, sometimes the problem originates in the browser. This may seem obvious to any web programmer, but it wasn’t to me, mostly because the assumption really is, “I’m not an expert, so the mistake must be something in my code.”

Font-size Chrome Bug

In my case, I was having issues with font sizes, and this is such a basic part of CSS that it never occurred to me that it was a browser issue. Lo and behold, it turns out the current version of Chrome (17.0.963.79) rounds font-sizes to the nearest whole number, and I was doing calculations based on Chrome. Because of this bug, the site I was formatting looked very different.

For example, say I have:
h2 { font-size: 1.2em; }
h3 { font-size: 1.17em; }

Firefox: h2 = 19.2px , h3 = 18.7167px
IE9: h2 = 19.2px, h3 = 18.68(?)px
but Chrome: h2 and h3 = 19px

See jsFiddle example.

While these differences are so small you can barely tell in the example, you can imagine that on an entire website, it has a pretty big effect especially if it’s a base font size. In the end, I filed a Chrome bug report and it’s being looked at.

Sometimes it’s a Mystery

In our website’s book banner, there is a little styling trick in order to make it look nicer. What really got me was that it was using absolute positioning (which generally I avoid). However, if you make it relative, it no longer does what it’s supposed to.

Have something like this in the CSS:
span {
position: absolute;
top: 1em;
left: 1em;
border: 10px solid transparent;
border-right: 10px solid blue;
}
span+span {
position: relative;
left: 2em;
}
the HTML should then have an empty block: <span></span><span></span>

Result: results in one arrow and one trapezoid
If you want to play with it, it’s on jsfiddle

So far, I haven’t found an answer, so I’ve simply recoded it to make it work in the new layout. Now the strange thing is that it works on MAC, but breaks using the same browsers on Windows.

Guidelines on Making Websites Accessible (for Persons with Disabilities)

This week, I started creating a WordPress theme for our website, and in doing so, spent a lot of time reading on making a website accessible for persons with disabilities. While we do have legislation stating that all university websites need to be accessible by next year (?) (Accessibility for Ontarians with Disabilities Act (AODA)), our university and library take pride in being accessible. For some reason though, our website is not all that accessible.

Web Content Accessibility Guidelines

Now on version 2.0, most government and public organizations are being held accountable in being compliant with the Web Content Accessibility Guidelines (WCAG). The guidelines divides up the requirements into three levels: A, AA, AAA. While the guidelines themselves are a little hard to decipher, w3 provides a customizable quick reference to break the guidelines down into a more readable document.

The Design

When it comes to the general design of the website, it’s actually fairly simple.

  • Order and use of elements should make sense even in text only (1.3)
  • Minimum contrast (1.4.3)
  • Text resize up to 200% in the browser without lost functionality (1.4.4)
  • Keyboard accessible and easy to navigate (2.1, 2.4.1, 2.4.5) – have different ways to get to your content
  • Make your site predictable (3.2)
  • Provide error identification, suggestions, and instructions (3.3)
  • Make it compatible with assistive technologies (4.1)

The bottom line: your website should work (and make sense) even without JavaScript and CSS, and in text-only mode.

The Difficult Part: Making A/V Content Accessible

I don’t think a lot of people realize that designing a website to be accessible is not the hard part. The hard part in an organization is making sure that the content posted on the website is accessible. In particular, audio/visual elements should have text alternatives, whether that be closed captions, alt text or transcripts.

In order to ensure that content is also accessible, web developers need to work with other staff whether inside their own department or in the greater institution to educate staff who are creating content, because even something as simple as images need text alternatives.

At a college or university, best to contact the accessibility centre/unit on campus to work with them. They might already have the tools or know-how to make a/v content accessible.

Making a WordPress Accessible Theme

So, why reinvent the wheel? That’s what I thought anyway, but there are some issues with using an existing theme and modifying it. I wanted one that was in HTML5/CSS3, and then I later discovered that it should also be using the WordPress Settings API (which was difficult because it was only added in 2.7 so not everyone is using it).

Long story short, I didn’t find any, but then in looking through the files, it turns out the built-in/sample WordPress theme TwentyEleven fits all of these requirements! They do not tout that the theme is accessible, but many of the elements are present in the theme.

I will be posting more once the theme is done (or mostly done anyway) with more details on any changes I will have to make, but I’m thinking they will be very few if any.

A Few Tools

You can find a rather extensive list of tools for evaluating accessibility on the w3c website, but one of the most useful I found was: WAVE, which provides different views of a webpage with alerts and errors (there is also a browser plugin version). There are also a number of good colour contrast checkers browser plugins.

Code4lib Day 3: Notes and Takeaways

You know, it’s hard to MC, follow twitter, pay attention, and blog, so as usual, only notes and takeaways for some of the presentations.

Full posts:

Your UI Can Make or Break the Application

  • software developers are creative
  • Prototyping: fail early and fail fast
  • user involvement: screenshots along with requirements
  • creates user buy-in
  • warning: don’t make demos look done!
  • don’t be afraid to “borrow” ideas
  • help the user be successful
    • stick with familiar designs
    • use simple language
    • keep labels/functionality consistent
    • give instant feedback
      • provide inline validation
      • some feedback through AJAX
  • Helpful Sites:
  • designmodo.com
  • thinkvitamin.com
  • ajaxload.info
  • uxdesign.smashingmagazine.com

Quick and Dirty Clean Usability: Rapid Prototyping with Bootstrap

by Shaun Ellis, Princeton University

Important to get user feedback, meaning to get things in front of them. Use drawings to keep people from getting bogged down by aesthetics.

Twitter released Bootstrap, an open source style guide that will put your feet in your shoes. It allows you to get really quick feedback on static images and interactive pieces, but will not make your site “instant delicious”.

Allows a lot of customization based on grid system.

Prototype yourself out of the cave.

Some References:

Wrap-Up

Some archive/relevant links:

Code4lib Day 2: How People Search the Library from a Single Search Box

by Cory Lown, North Carolina State University

While there is only one search box, typically there are multiple tabs, which is especially true of academic libraries.

  • 73% of searches from the home page start from the default tab
  • which was actually opposite of usability tests

Home grown federated search includes:

  • catalog
  • articles
  • journals
  • databases
  • best bets (60 hand crafted links based on most frequent queries e.g. Web of Science)
  • spelling suggestions
  • loaded links
  • FAQs
  • smart subjects

Show top 3-4 results with link to full interface.

Search Stats

From Fall 2010 and Spring 2011, ~739k searches 655k click-throughs

By section:

  • 7.8% best bets (sounds very little, but actually a lot for 60 links)
  • 41.5% articles, 35.2% books and media, 5.5% journals, ~10% everything else
  • 23% looking for other things, e.g. library website
  • for articles: 70% first 3 results, other 30% see all results
  • trends of catalogue use is fairly stable, but articles peaks at the end of term

How to you make use of these results?

Top search terms are fairly stable over time. You can make the top queries work well for people (~37k) by using the best bets.

Single/default search signals that our search tools will just work.

It’s important to consider what the default search box doesn’t do, and doubly important to rescue people when they hit that point.

Dynamic results drive traffic. When putting few actual results, the use of the catalogue for books went up a lot compared to suggesting to use the catalogue.

Collecting Data

Custom log is being used right now by tracking searches (timestamp, action, query, referrer URL) and tracking click-throughs. An alternative might be to use Google Analytics.

For more, see the slides below or read the C&RL Article Preprint.

Code4lib Day 1: Design for Developers – Some Notes

by Lisa Kurt, University of Nevada

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

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

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

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

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

Have fun too!

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

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

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

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

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