Web design – Page 8 – Learning (Lib)Tech

Branding the Library Website: Making a Flexible WordPress Theme

In moving our website to WordPress, I wanted to create a theme that could be used by our staff when working on online projects which would sit outside our main website, but in which we would host. Obviously they have the option of using other themes, but then someone (likely from our team) would have to make sure it meets accessibility guidelines, and as there are very few of those, I thought it best to just make our theme flexible.

No CLF

This is just a disclaimer that the main reason we could even do this is because we do not have a Common Look & Feel policy from the university administration, which most universities do. On the flip side, that’s one reason I wanted to do it. I would like that the library “products” are recognized as such. Doing it through a theme would also provide a more consistent user experience across the sites that use the library’s theme.

The Header

Our existing site already used a consistent header. However, it also includes the “Ask Us” logo, which would take you to the “Ask Us” page with all the myriad ways to contact the library for help. For other sites, it’s more likely that they will want to list specific contact instead, so I added an option to remove it.

new site header — New Header with Custom Menu and Google Search Bar

In addition, of course, for any sites using the theme, they will want the name of their site in the header, so I added a text box input for that in the options page and used font-face to pick a different font to make it stand out a little more.

The Menu

The navigation was built into the original theme so that you can either use a custom menu or it will fallback to using pages. However, the way our sites are made, some of the subpages menus would have been so long as to go past the end of the page, so I added the option to take out submenus.

new header with subsite title — Header with Subsite Title, Fallback Menu, and WordPress Search

Finally, the original website search bar redirects the user to the university’s Google search of the library’s directory, so I made the option to change it to the standard WordPress search bar to search within the current site.

The Footer

Since each site may have different links in the footer, I also made an option to include custom links in the footer, such that the ‘Home’ link is the only hard-coded link (which is always the link of the home page of the site you’re on).

Full Site Footer with Custom Links and Social Media Icons

While it’s possible to make the social media buttons customizable, until there is a demand or need, I decided to simply put in the option to take them all out.

Hardcoded Part of Footer

The rest of the footer (copyright) is always there. Again, unless there is a demand or need, I didn’t make the copyright holder changeable.

Templating

As many sections of our website (e.g. catalogue/OPAC, Research Guides) are not part of the CMS, I am currently working on taking the WordPress template (minus the options) and creating a plain HTML and then a ColdFusion template to use in those sections.

The Downsides of a CMS in Keeping Up: WordPress & HTML5

As a web developer, I cringe at deprecated code and try my best to keep up to date, which right now means familiarizing myself with HTML5 and CSS3. In reflecting on how best to update our website, I realized that with a CMS, naturally some things are out of my control.

Giving Up Control & Relying on Developers

Whether it’s the core or plugins, users of a CMS are reliant on its developers to keep things up to date. Is that lost of control worth the benefits? Generally, I would say yes, but that doesn’t stop me from wishing that the technology that we use to adopt new specifications.

WordPress & HTML5

Image Tags & Properties

I think it’s interesting that in HTML5 there is now the figure and figcaption elements. If they are taken advantage of, I think it definitely helps to parse information in a webpage and to identify text that is directly related to images.

One thing that does bother me about WordPress (which actually has noting to do with HTML5) is that it forces users to have a title, and leaves alt text blank by default. I don’t know what the best solution may be, but I would propose to insert the title text into the alt text by default and then allowing the user to change it. If they want to leave it blank, then there should be a checkbox to mark it “intentionally left blank” or something. Perhaps this could be an admin option, but I would definitely want something like that since I would really like to force our users to have alt text, but I don’t want to touch the WP core obviously.

Text Formatting Tags

It’s a bit of a minor thing and while some may argue the usefulness of the different semantic tags, users of the rich text editor would have no notion that they’re using <strong> instead of <b> or <em> instead of <i>. While I admit that even I struggle on the appropriate use of each (I have to look it up every time I think about it), if we want to see widespread adoption, then we need to get users to think about their writing and what they intend to do when using any of strong, em, b, i.

Tables

While we avoid tables and it should never be used for layouts, users will still want to insert tables to display data without resorting to an image. I’ve always wondered that WordPress doesn’t have a table insertion button even under the kitchen sink. What worries me is that then users who have a basic knowledge of HTML will insert it themselves using the HTML view with improperly formed code.

Layout & Forms

You might wonder why I’d lump the two, and that’s because, other than (using the default) comment form, both of these are dependent on a WordPress setup.

Forms will generally depend on the plugin. Similarly, whether the layout is in HTML5 is very dependent on the theme, along with many elements of accessibility.

Unfortunately, while HTML5 themes are relatively easy to find, most form plugins do not tell you whether they are using HTML5 or how much of it.

Why Not Adopt HTML5

I do realize that while there are a number of advantages to HTML5, especially in terms of structure, it’s still in development. Working in an educational institution, it’s also more work and sometimes difficult in some cases to ensure backwards compatibility.

In particular, screen readers do not necessarily support all the new HTML5 elements and will frequently ignore whole chunks of text or have difficulty with reading links, etc. Even the newest versions of screen readers do not necessarily recognize elements and properties designed to make webpages easier for screen readers to interpret.

I would like to think that since WordPress talks about trying to be accessible that anything in the WordPress core will be updated once there is widespread adoption not only among browsers, but also screen readers. Obviously, adoption will take time though. For example, many form input types have been adopted by most browsers, but has not been adopted by IE at all (will be in IE10).

One can only hope that adoption will pick up once various part of the HTML5 specifications are ‘cemented.’

Book Review: HTML & CSS: Design and Build Websites by Jon Duckett

I don’t normally do book reviews, but Jon Duckett’s HTML & CSS book was brought to my attention via twitter and it looked interesting, so I thought I’d give it a read.

If you’re the type that was discouraged from learning basic web programming because of the manual-like books, then I would definitely recommend this book. The information is presented in very visual ways and while there are a few pages here and there that have nothing but code on them (for full examples), almost every page has an image of some sort, whether as explanation or for decorative purposes.

While there are a couple of concepts I wish were explained in a little more detail with visuals (such as CSS selectors), I appreciate that Duckett will discuss deprecated tags and elements, which are still commonly seen, and point out which browsers do not support certain properties.

He also provides lists of practical websites or tools to use including commercial and open source alternatives. Code and extras can be found on the website, which can be useful even for those who never crack open the physical book.

The Conclusion

It’s what it purports to be. So, I highly recommend it for beginners and maybe even those that want an easy to digest review (it’s very easy to skip sections you feel you already know).

When CSS Positioning Kills Functionality: Changing the Look of a WordPress Comments Form

When editing our theme, I had an interesting time editing the styling of the comments respond/reply form.

I was essentially modifying the WordPress TwentyEleven comments form, which looks like this:

The form is huge though, especially since the blog posts we typically have are fairly short, I was afraid the comments form might end up bigger than the blog posts!

I figured the “quick” fix would be to simply lessen the amount of space between form fields. I did it the quick and dirty way, using:

#respond comment-form-field { margin-top: -30px }

Unfortunately, that broke the form fields. You could only activate the form field by clicking on particular areas of the field, which ended up being less than half of a field’s box.

It took me a while to figure out that the labels on each field would normally show above a field, but were repositioned on top of a form field. While this looks pretty, each label was taking up the equivalent space above a field; so if the whole field was repositioned to be closer to the above element, the space where the label would be overlaps the form field and thus block mouse behaviour. When a user tries to select the field, they’re actually selecting the paragraph element of the label:

In particular, this behaviour will happen any time an element overlaps another and its z-index is higher, literally positioned on top of the visible element below.

In the end, I restyled it with the labels above the fields so the gaps don’t look so big in between the fields. I also scaled it down somewhat, so that the end result is 243px shorter (in height) than the original and 123px shorter than even the ‘quick fix’ version. The end result:

It still seems too large in comparison to a short post, so it will probably be restyled again later to be less wide as well and possibly scaled down even more. UPDATE: I wrote another blog post on further modifying the comments form, mostly using PHP.

Additional Information

For more on styling forms, check out WordPress’ article on Styling Theme Forms.

For those interested, here are the changes I made (classes that weren’t touched at all are not included):
[sourcecode language=”css” collapse=”true”]
#respond {
padding: 1.625em 0 1.625em 1.625em;
}
#respond input[type="text"],
#respond textarea {
(no change except removed text-indent)
}
#respond .comment-form-author,
#respond .comment-form-email,
#respond .comment-form-url,
#respond .comment-form-comment {
margin-top: -10px;
}
#respond .comment-form-author label,
#respond .comment-form-email label,
#respond .comment-form-url label,
#respond .comment-form-comment label {
-moz-border-radius: 3px;
border-radius: 3px;
left: -10px;
top: 4px;
padding: 3px 5px;
(mid-width removed)
}
#respond .comment-form-author .required,
#respond .comment-form-email .required {
font-size: 1.5em;
top: 33px;
}
/* added */
#respond .logged-in-as,
#respond .must-log-in,
#respond .comment-notes {
margin: 0.3em 0 1em;
text-indent: 2em;
}
#respond .form-submit {
margin-top: -10px;
}
#respond input#submit {
font-size: 1.15em;
margin: 20px 0 0;
padding: 5px 15px;
left: 15px;
}
#reply-title {
font-size: 1.4em;
margin: 0;
(removed font-weight and line-height)
}
[/sourcecode]

ARLIS/NA 2012: Designing for Diversity

This morning, I attended the ARLIS/NA 2012 Conference workshop on designing for diversity presented/facilitated by the OCAD Inclusive Design Research Centre. There was a lot of discussion on barriers and challenges with some discussions on solutions. Honestly, I’m not sure I learnt anything new, but there were some interesting discussions that happened.

IDRC

Goal: digital inclusion

All their projects are open source, and include:

Engage: museum vistor experiences
CollectionSpace: collections management system, primarily by museum
Decapod: document digitization
Floe: inclusion in open education resources
Fluid: inclusive user experiences, umbrella project
Tecla via Komodo

User Experience Examples

We started with a discussion of general examples of good and bad user experience elements in our own personal experiences.

Bad

cord tangle
lack of browser interoperability
inconvenient touch keyboard layout
lack of flexibility in filling out forms e.g. 2 last names, accents
downtime
having to relearn interface of new version
can’t link direct to article
lack of search features
locked font sizes on email
meaningless error messages

Good

responsive design
transparency
alternative interactions i.e. touch
augmented reality layer
switch languages
filter searching
free wifi
autologin
RSS
cloud sync e.g. dropbox
social bookmarking
bibliographic managers
citation linking
security
consistency

Barriers

With respect to inclusion, what are some of the challenges or barriers at visual-based libraries/collections, image management, or other related products, services, organizations?

facilities concerns (i.e. older buildings)
alternative formats e.g. descriptions for image collections
cost/resources
expertise
attitude/awareness
vocabulary, translation
non-standardized vocabulary, but standardized doesn’t work as one size fits all
arranging physical collections to make sense
equipment/software inflexible

User Focus

Think about the user’s

goals
abilities and needs
expectations
pain points/frustrations
physical/environmental context
workflow context
current solution (if it exists)

User Modelling

While no linear or checklist, there are some important steps including working out scope (hunting and gathering of what are the possible problems), and behaviours (what happens when you interact, what want to achieve). Always a constant iterative work.

Personas

fictional, archetypal profiling of groups of users
humanizes abstract users

User states & contexts

enumeration of the various states and contexts users might be in
much more granular understanding of users
e.g. sensory, dexterity, cognitive, communication

One Solution Fits All

No one solution fits all, but if you’re restricted to one solution, then the key is to make a:

flexible, configurable environment.

Case Example

One of the situations we discussed is the physical reference desk. While the goal is for the desk to be a welcoming place where people know that’s where they can get help, the desk is frequently a place where there is a big standing only desk, which can be uncomfortable, tiring, and inaccessible.

Solution? Possibly, separate desks for different types of questions, with double monitors and possibly double keyboards for more in-depth or look up questions.

Do we need the desk? Particularly for directional questions, perhaps a desk isn’t even needed. For in-depth reference, the suggestion is to have two chairs on the same side of a table.

Media Access & Media Accessibility

Captioning is important to compensate to audio (poor, noisy background, not allowed), to quickly browse a video, catch details, show correct spelling, support for ESL, accessible, and it’s compliant. Description is important for similar reasons.

Captions and transcripts could greatly help with searching of media as well.

Few Media Players & Internet Plug-ins

Flash (DFXP, QTText)
Quicktime (QTText, SMIL, tx3g subtitles, CC tracks/Line 21 braodcast captions)
Windows Media Player
Silverlight
VLC

Flow Player – fallback to non-flash video
NCAM Player – find feature
JW Player – fallback to non-flash video

Magpie – Windows Captioning
Capcat (s?) -MAC Captioning

Information & Resources: Inclusivemedia.ca

Future Tools

HTML5 video with track tag once built into browsers