Sometimes, I’m a Wimp

Posted on

Web design is a thick-skin sort of discipline. In part, hey – it’s the internet: semi-anonymous bolstered computer geeks can and will pick apart your code, your design. Our community has for the large part turned this around, embraced rip-offs, forks, open licenses, pull requests. We know that the collective creativity and brainpower of the community can frankly just make things so much better. Sometimes it gets a little mean, but it’s really not a bug, it’s a feature.

Optimize the Critical Huh?

Posted on

There’s a problem with the all-in-one, mobile-first, future-friendly stylesheet. I think its days are numbered. For a short while this has been the best practice [for most situations]:

  1. Use just one external stylesheet in the head: not two, not three – one.
  2. Write mobile-first styles using media queries, loading only your most basic, crucial styles up-front.

This can be structurally tricky but two bullets makes for a pretty memorable maxim. The problem with loading any styles in the head is that these are “blocking” files, not deferred, which means that as the web page renders top-to-bottom the browser stops to load scripts and stylesheets before painting the content. When milliseconds matter–and they do–dropping <link rel="stylesheet" type="text/css" src="styles.css"> in the head as we’re conditioned is a disservice.

Performance Matters Because it is a User-Centric Concern

Posted on

I talk a lot about design and user experience and my favorite subjects are less about being elbow-deep in the markup and more–um–philosophical. A year or two ago I was more concerned with practical application–“behold! A mobile-first, modular stylesheet”–but as I go, I find I’m more concerned with the culture of the workplace, the [lack of due] priority attributed to the #libweb, and the ethics of–essentially–being a tax-or-tuition funded developer.

ARIA for the Spec Impaired

Posted on

This isn’t an exhaustive walkthrough for ARIA in HTML5, but I wanted to write one up for my own use. With microdata and accessibility in the mix, I find that HTML is getting increasingly tricksy. There’s more to remember than ever and there are often multiple correct interpretations of a usage. Serious folk should always refer to the spec – but specs aren’t always the quickest references. To complement my primer on Markup for Academics, this makes up a non-exhaustive skeleton for using ARIA consistently.

Markup for Academics

Posted on

It doesn’t immediately show, but for a secret future redesign of a popular library blog-turned-journal I put in a lot of time styling <figure> and <figcaption>, <blockquote>, <abbr>, <cite>, dynamic tables of contents and footnotes, and so on. A switch flipped and suddenly these were my favorite elements – even more than the wiggly menu. I pulled the same styles into the Sherman’s future redesign [I’ve been writing about ita lot].

I’m not exactly on the gung-ho side of the librarians-need-to-code movement. The popular push to teach librarians python is, um, probably not going to have any real return except for a philosophical appreciation (but hey, that’s good too); I do however think it’s important for librarians and other academic writers to know their markup.

Why? Well, we write a lot. I don’t know any other discipline where blogging is so integral to its culture, so much so that many of us have sort of self-branded ourselves (you may have heard of the front-end librarian). Librarian blogs tend to be more academic than not, often well-cited, even when we’re trying to be joe (or jill) cool. We spearhead the open access movement and write for an increasing number of online-only venues, and we have to assume the rest–the stuffy journals we suffer for tenure and cred–will make it to the web anyway.

On the web our footnotes, appendices, figures, and the like have more extensible meaning than in print. Meaning for the readers and meaning for the machines. Our content can be made richer with solid markup than it could ever in print. Thus this primer.

Article

Your article, blog post, and your article’s comments should likely use <article>. Basically, if this content is a self-contained, independent composition that, hey, you could pull totally out of context and republish somewhere, then it’s an <article>. This whole post is an <article>. Within is a <header> that contains my h1 title and time, and sometimes it might have a footer at the bottom of the article where I might keep endnotes. Additionally, you can split an <article> into logical sections or chapters with <section>.

Section

A <section> is a blob of content that, while it may not make sense out of context, can help section a larger <article> or page – hence <section> (yay, semantic web!). It’s not appropriate if either <article> or <aside> are more applicable. Your endnotes might be grouped as a <section> in a larger article.

End Notes

End notes here.

<section>
  <h3>End Notes</h3>
  // Content Here
</section>

Aside

Since I brought it up, <aside> is secondary content that can be used inside or outside an <article>, but depending on which it behaves differently. Inside an article, the contents should be specifically related to the article – like a pull quote or a gloss in the margin. Outside of the article, the <aside> is secondary content for the overall site. It’s a block-level element, which means there can be headers, footers, navs, and other markup within an aside – just like in <section> or <article>.

Abbr

<abbr> is an abbreviation for “abbreviation”! It’s an inline element, so you use it within paragraphs or whatever, can be italicized, emphasized, and so on. When we refer to an abbreviation we can wrap it in something sensible for reference. For instance, hovering your mouse over abbr should show what we’re abbreviating.

<abbr title="Hypertext Markup Language">HTML</abbr>

Block Quotes

I used to use <blockquote> all of the time because of its inherent formatting – always a bad idea, I guess. Anyway, sometimes you just need to quickly inset a quote (or, the way I was using it, anything :) ) from a regular paragraph. Here’s the thing: the blockquote element represents a section that is quoted from another source. Since it’s a block element, you can drop all sorts of headers, headings, and other tags inside. h1 - h6 don’t become part of the overall document’s outline; if you were so inclined you could also include the markup that is apart of the quote itself. Optionally, you can include a cite or an attributive footer.

This is a simple blockquote. I can bold stuff, or insert other kinds of markup.

Michael Schofield
<blockquote cite=http://link.com> 
 this is a simple blockquote.
 <footer>
  <cite>Author</cite>
 </footer>
</blockquote> 

Q

No, not the gadget geek. This is for inline quotations – and they have to be quotations, not “sarcastic quotes.” Anyway, the first time I will have ever used q is in this example. Let’s pretend I’m quoting something. Hey, could you tell that that was a quote? Let’s look at the X-Ray:

<q cite="http://link.com">Let's pretend I'm quoting something.</q>

Apparently, according to the spec, you shouldn’t use q with manually input quotation marks because the browser should render the quotation marks on its own. They didn’t render on mine O_o. I think this is markup I’ll just skip in favor of “quoting” things the good old-fashioned way.

Cite

cite references a creative work and must have either the title of that work, the name of the author, or a URL.

Figures

In print, a chart or an image used for reference would be accompanied with a caption. The <figure> element is markup for diagrams, illustrations, code examples, photos, and so on. A <figure> has to be independent content, meaning just that regardless whether its inserted within the main content or moved all the way down to the appendices, they still make sense. Optionally, within a <figure>, you can add one–just one!–<figcaption>, which could just as easily have been called <caption> because that’s what it is and makes more sense. But hey, we didn’t write the spec. Anyway, the caption can appear before or after the main content of the figure, but there can only be one caption, even though the figure can have all sorts of other stuff init (like images, lists, etc.).

A black-and-white portrait of a toddler with a curly-Q moustache.
Fig 1.4 | Tres mysterieux.
<figure>
  <img src="path/to/image.jpg" alt="Describe your image for screen-readers">
    <figcaption> <strong>Fig. 1.4</strong> | Tres mysterieuse.</figcaption
</figure>

Small Print

Use the <small> element for inline legalese, copyright statements, disclaimers, and caveats. Browsers by default treat <small> pretty literally (teeny tiny), I think something around 75% of the parent font-size (or 0.75em) – but it doesn’t have to be and you can override it with your stylesheet. Instead of thinking that small refers to relative size, think of it more in terms of small print. You really shouldn’t use it just for formatting, for making text itsy-bitsy, because, well, that just doesn’t do anyone any good.

A key thing to remember is that <small> is an inline caveat, which means you shouldn’t use it for a completely standalone statement or paragraph. For that, use an <aside>.

Definition Lists

The dl element is an alternative to the ol (the ordered list) and the ul (the unordered list), and it’s used for, um, defining things – in a list. Like a dictionary. Inside the dl is a definition term and a definition descriptiondt and dd respectively.

A Definition List
An alternative to ordered and unordered lists used for, um, definitions.
<dl>
  <dt>A Definition List</dt>
  <dd>An alternative to ordered and unordered lists used for, um, definitions</dd>
</dl>

Let’s call this a fluid resource

Well, as of now I’ve drummed-out as much as I care to drum-out, but there is a a lot of markup that could be covered. I’m making a lot of assumptions about starting knowledge, here. Am I missing something? Please comment and let me know.

Librarians aren’t talking about the DRM of the web. This vacuum and apathy isn’t without consequences. The encrypted media extension is working its way through the W3C standards body, which will allow for DRM native in the browser. The idea is that publishers and content providers deserve a native way to restrict downloads so they no longer have to rely on third-party plugins like Flash or Silverlight. To make his work in he browser, there must be constant processes monitoring whether your use of copyrighted files is accessible, a port through which your browsing is monitored in both directions.

This was originally posted to my defunct Not Safe for Libraries podcast in July 2012.

iTunes RSS MP3


Amanda–UX librarian extraordinaire–was trying to track down some anti-carousel stuff I’ve written, and I found this gem from a previous botched podcast back in July 2012. It’s more than a year old and can feel pretty dated, but I talk about being future friendly, when to ditch browsers, wisps about content strategy, and at the 18-minute mark I actually start talking about carousels. Here’s a still-relevant gem:

Forget about box-shadows and carousels. Ditch the library jargon. Come down to the casual level where the unstressed mind is most prepared for learning. Assume our patrons’ connections suck.

Show Notes

iTunes RSS


What topics should define the #libweb in 2014? With at least one book and an abundance of high-profile classes, workshops, and pre-confs to look forward to, I guarantee that “responsive web design for libraries” will rank – again. Should it? The classes and conf-talks especially have been and probably will continue to be about addressing the problem of layout, but I’m not sure that’s the problem to address. It’s a symptom of a larger bug.

Show Notes

A shaky first entry to A Front End Audioblog – but hey! What can you do–if anything–about a web design committee that is stifling or stuck in the early naughts? The answer, as it turns out, is data – lots and lots and lots of it. And jazz hands.

Sprawl Elegantly

Posted on

Hey there. Today my tunnel-vision bloated to the size of an expressway. All the little cards in my to-do app, the double digit reminder-badges on my phone, the buzz from a calendar-generated reminder email … – these usually carefully compartmentalized aspects of my psyche came together in a hallucinatory arrangement before me like a deck of cards thrown into the air. You see, today I hit 20 concurrent projects. Some are fairly long term–redesigning the OPAC (but, oh shit!)–some are small potatoes. Not honored among those 20 are the menial things–updating hours for finals–nor the unspoken timesucks – like monitoring and addressing usability or functional issues in already existing applications.

Paralyzingly sprawl.

A little context, though: I like having a lot of projects. Sprawl gives me a sense of purpose. I’m comforted knowing that each item could be a line on the resume, that each deadline met makes me a little more trustworthy and awards me a little more autonomy and authority not just in the libraries themselves but among you guys – the community. I am constantly awed by what you pull off, and I honestly just want to make sure that if we ever grab a coffee or a beer at a conference we can talk at the same level.

So, if I am going to take on a ton of projects, I just have to commit to sprawling elegantly. If all these tasks on Trello are disparate rabbit-holes then I’m slated for anxiety and failure. But if each card is part of a larger, single project – the organism of the #libweb – and each application or site is designed to talk with the others, then what at first seems to be an abyss of ceaseless Cthulhic busy-work becomes naught but new features in an inclusive changelog.