Right off the bat I think it’s worth emphasizing: this system works for me. I’ve tried a bunch of different systems like GTD, pomodoro, online checklist tools like Google Keep, and others, and landed on this system for myself. I’m sharing it because maybe it will be helpful for you, but I’m going to write it as what I do and how it works for me. If you try it there’s a solid chance you’ll have to change it to work for you.

Should you listen to me? Am I particularly successful or productive? Perhaps not. But I am a regular dude who gets stuff done juggling work, side work, more side work, family, friends, household tasks, personal care, creative pursuits and hobbies, and the occasional leisure. I’d be able to do a lot of it without my system, but am confident I get more done with it than without it.

The format

This is the simple part: it’s an index card. One index card for each week.

1. At the top is the week in the format “Week of 2024-07-29”, where the date is the Monday
2. Rows of 5 checkboxes (for each weekday) for daily tasks. It could be 7 boxes, but I like to not be accountable for things on the weekend
3. Rows that start with a single checkbox, each something I’ve committed to doing eventually

So yes, it’s a checklist with a label. It seems like a pretty obvious system because that’s what it is.

I like an index card because it doesn’t take up much space on my desk. I like an index card because, unlike a planner or journal it doesn’t have all the baggage of previous weeks, nor the threat of unknown coming weeks. It just is.

An index card is also tangible and in-your-face. In combination with the rules, that means I can’t just write out a checklist like I can in some cloud software and then have it be out-of-sight and out-of-mind. I’m practically forced to engage with my list and continue it from week to week.

Mise en place

On Sunday night if I’m on top of things or think I’ll be extra busy in the coming week, or Monday morning if I try to break away for my desk for the weekend, I grab a blank index card (never the back side of a previous week’s card) and put the previous week’s card next to it.

I fill out the “Week of…” line and the daily task rows, then put any tasks from the previous week that remain unchecked after the daily tasks. This is part of “the rules” (below), and a key part of the system underlying the index cards: the act of having to transcribe a task to the next week is a nudge to get it done so you don’t have to keep transcribing it week after week.

After the known tasks I take a peek at my email accounts for anything task-ish there, plus check my clients’ various and sundry project management systems to see if I’m assigned anything I forgot to put on the lists. Then I just think about the week and if there’s anything for myself, my family, my friends, or my home that should get done this week.

Once all the tasks are entered on the new card:

1. I put the new card on the front-right corner of my desk and put the pen on top of it. I always know where a pen is, and never have an excuse not to write a new task on the card
2. I walk the old card over to a cardboard box in my closet and haphazardly place it there. The old card no longer serves a purpose but might be nice to reminisce about someday

Having a time and place for these routines, these habits is a big part of the system. It also feels like a ceremony to some extent, like I’m ridding myself of last week and becoming present in the new one.

Daily tasks

I really like the rows of daily tasks. They are all easy to accomplish, and even if I don’t accomplish some big task on the list for a day or two I’m still checking things off. That keeps momentum in the system all the time and probably does something science-y to my neurotransmitters. These are the daily tasks that have been sticky for years now:

• Morning routine
• Morning constitutional
• Hug wife
• Work out

Morning routine is the easy one. I wake up, check my phone and get caught up on emails and headlines before getting out of bed, use the bathroom (and always forget to take Seth Roberts’ self-experimentation advice and look at my face a while in the morning), get my water and coffee and optional protein-forward breakfast going, and take my allergy medicine + vitamin D supplement + multivitamin + lip balm. I do the lip balm last so I remember whether or not I’ve taken my medicine. Then I make our bed, which isn’t my favorite part of the day but I have checkmarks to make.

Morning constitutional is kind of a pain. Often I’ll sleep until nearly working hours and then have to wrangle 10 minutes between meetings to go outside and walk a little bit. Even if I do get up early, I don’t want to instantly go do stuff, but I chase that checkmark, darnit! They say there’s a benefit to walking (especially in nature) in the morning. I’ve been doing daily walks for the better part of a year and can’t say I feel a difference, but it’s part of my ritual now. It’s kind of wild how many T’s are in the word ‘constitutional’.

Hug wife is also easy. I feel a little self-conscious that I use a productivity system to remind myself to be affectionate with Shelby, and sometimes feel bad when there’s a busy day and we don’t have a hug and the checkbox is unchecked, but overall I love hugging my wife and like checking boxes, too. I’ve chosen to overcome the negative feelings and focus on the positive.

Work out helps me embrace the un-checked boxes in this world, haha. It’s a rare occasion that I jog two days in a row much less 5 weekdays, so I don’t think I’ve ever checked all 5 boxes in a given week. Working out is just something I’ve committed to doing. The ambiguity of “work out” rather than having rows for lifting weights and jogging separately also means that I can be a little loose about checking the box, and might be able to check off more boxes if I can convince myself to do a push-up or something.

Timesheets was a daily task when I was self-employed, but I retired it when I took a permanent full-time job. If you’ve had to submit your billable time to multiple client time-tracking systems every week and also invoice clients without their own systems, you know there’s no viable alternative to just staying on top of this boring admin work. Now that I bill low single-digit hours every week outside of my main gig, time tracking just isn’t important enough to have a scary line on my card.

The rules

Since this is a system you can make your own, please remember that these are just the rules for myself at this time, rather than unbreakable laws of productivity:

1. This week’s card should be ready before Noon Monday
2. If I put something on the card, I’m committed to doing it
3. Other people can cancel a task but only rarely can I decide not to do something on the list
4. If a task isn’t done by the end of the week, it goes on the next week’s card
5. Tasks on the list shouldn’t be fluffy filler like “Go to the bathroom”
6. Tasks on the list shouldn’t be ambiguous, massive, or un-checkable
7. If something should be on the list, put it on the list
8. Check off tasks when a reasonable person would say they’re done
9. Sometimes you have to make follow-up items for a task, but don’t try to un-check stuff
10. This list is for you

The whole idea of the card and the daily tasks and the rules is to have a single little place to keep track of what I have to do. It’s a thing that exists in time and space that begs to be engaged with and has useful and darn-near fun little boxes on it.

Changes to the rules should make the system more useful or engaging or should reduce the amount of time required. You can see I’ve already written a lot about this simple system and will be writing even more paragraphs. At core, though, the system should be quick and simple. I’ve not had success with systems that have cycles and extra fields and complex prioritization and reflection/meditation/journaling built in and all that jazz. Sure, meditation could be a daily task if I decide that’s important to me, but it doesn’t belong baked into my checklist.

Nuances and variations

I think philosophically that a checklist is part of your life in a sort of narrow way, so from time to time it’s worthwhile to consider what belongs there in the context of rules 5-7. Some things you write down so they stop bouncing around your head, and these things tend not to belong on the card. Other things are captured elsewhere even if you engage with them and are accountable for them, and that’s a category worth considering.

Calendar events

If I have to be somewhere or do something at a particular time/place, I tend to put that on a calendar that then notifies me on my phone. Since my phone/computer is doing the reminding, it’s a lot less important for calendar things to be on the card. Sometimes I put important events on the card, though, especially if it’s a light week otherwise.

Full-time job tasks

My full-time job duties are a series of calendar events and items in a single project-management system for the most part. All work stuff is on its own computer and walled off from my side work and personal tasks.

When there’s a task that’s not worth making a JIRA story for but that I intend to do, I’ll sometimes put it on the card. Sometimes those tasks I’ll put on the back of the card if they’re immediate and small.

I’ve had full-time contracts lasting around 6 months in the past, and for more than one of those gigs I’d put all the tasks on the card even if they were redundant to some project management system. Maybe the difference was that I was still doing those tasks as a business rather than as an employee, or maybe the difference was that the gig was impermanent (or the client wasn’t very organized lol). I don’t know for sure why I’ve made different decisions about similar tasks, but that nuance sort of speaks to how the rules are meant to work for you rather than being ironclad.

Sidebar tasks

For a long while I had a sidebar on each card that contained topics I intended to blog about. Since the topics were long to write out each week I’d shortened them to initialisms/acronyms like ‘WACI’ for “What a component isn’t”. And even though the point of transcribing them on the list was to motivate myself to write the blog posts so I’d be able to stop transcribing them every week, I was too busy to get to blogging. Transcribing those blog topics ended up feeling like a real bummer and made me not want to fill out my card for the coming week, so I eventually made a to-do list in Google Keep for “Someday blog topics” and ditched the sidebar.

That’s not to say that a sidebar will never return or that there aren’t things worth transcribing for months until they’re done. I try to be mindful of things that drag on the system, though, since I like to enjoy the index card and checking boxes.

Notes on the back

This is both a useful part about having a scrap of paper on my desk all the time, but also something to be careful with. If I have to take a quick note it’s great. If it turns out that note has lasting value for more than a week, though, all of the sudden there’s multiple index cards on my desk. I try to think of how long my scribbles will be useful beforehand, but the easy solve if I write something with long-term value on a card is to transcribe it onto a computer somewhere so I can ditch last week’s card.

The back of a card is a great place for really short-term sub-task lists.

Consistent pen

Writing small with a really fine-tip pen is useful for this system.

I’ve never truly considered getting a really fancy pen, but that’s the kind of thing you could do if it would motivate you.

I’ve used a super fine-tip Sharpie-brand pen for years now. It bleeds a little more than I’d prefer for how small I write, but I haven’t spent any time looking for a reliable fine-tip pen that doesn’t bleed, so I just stick with what’s familiar and consistent.

Colorful cards

They sell packs of index cards in different colors. The colorful cards can be a little harder to read because the contrast ratio with black ink is lower than with a white card, but as long as the card isn’t super dark it’s probably not a problem.

One thing that’s kind of fun about a multi-color pack of index cards is that you can look forward to a few weeks from now when you switch from purple to green. It’s also a bit more noticeable to have a colorful card on a white desk.

Other markings

Sometimes when there’s a high-priority task that I should do next I circle the checkbox.

Sometimes when I’m making a card for the week and there are tasks that are related to one another I group them inside a left-side square bracket.

Sometimes when a task is canceled (by a client per rule #3!) I mark it with an x rather than a checkmark. This helps show the task shouldn’t make it onto next week’s list at a glance. For daily tasks I fail to do I leave the box blank rather than marking an x, which is kind of arbitrary but it’s my system so whatever.

Daily cards

In 2021 I was really busy with a full-time contract and lot of smaller gigs, and would do a daily version of the index card system. Considering I ended up having to walk away from that full-time contract, I’m inclined to think if I’m tempted to do daily cards I have too much going on in my life.

Juggling multiple clients

I’ve found that having a consistent format for work tasks makes it easier to scan the card. Since most of my clients use JIRA I’ll write something like “MKTG-123 Fix email header” as the card task, and then I can find all the MKTG tasks at a glance. For clients without useful ticket numbers I’ll kind of fake it like “PTS LL Refactor tabs templates”, where PTS is the client, LL is the sub-contract, and then a short description of what I have to do in order to check off that box.

Negative tasks

So far I don’t think I’ve done a daily or other task that’s like “Don’t smoke” or something. It’s kind of an interesting idea. Would definitely be interested in knowing if it works for somebody.

Make it your own

So that’s my system. If you don’t have a system or the one you’re using now has big disadvantages, please give this one a try! If you do, please let me know how it goes.

And remember that it’s your system now, so tweak it how you need.

As an aside, I also love the following email newsletters:

• Links I Would Gchat You If We Were Friends
• TLDR
• Garbage Day
• Today in Tabs / Today on Trail
• Bad Astronomy Newsletter
• [Citation Needed]

If you’re also the RSS-subscribing type, please reach out and I’ll post a huge list of feeds I can’t live without.

What follows is my attempt at being choosy about my favorite laws and quotes to pull out at meetings.

‘Laws’

In a recent work conversation I was trying to remember which pseudo-laws were which, and went “There’s Betteridge’s Law of headlines, Atwood’s is the JavaScript one, Godwin’s is the Hitler one, but I can’t remember…”

(For the most part this section doesn’t have any laws of UX, though those are also worth a read.)

Goodhart’s law

“When a measure becomes a target, it ceases to be a good measure”

If you’ve read Freakonomics or accidentally took four years of Econ courses in undergrad, you’re likely quite familiar with perverse incentive, so this law probably speaks to you.

This comes up in a corporate context because companies are always trying to measure whether they’re doing well, who’s performing above average, and where they can improve. Measuring something is important for those purposes, but relying on any one measure can lead to unintended consequences:

• Maximizing shareholder value can lead to layoffs and a decline in product quality
• Relying on hours estimates can lead to burnout, which can lead to instituting story points, which can lead to gaming velocity
• Having a Continuous Deployment benchmark of x deployments per week might lead to (x-1) deployments for deployment’s sake
• Targeting 99.999%+ uptimes as a department goal might bring deployments and changes to a stop, for fear of even a blip of downtime

Once you know this law you see it everywhere, but figuring out what to do about it is a different story altogether. Some teams might try to avoid too many target measures, while others might have so many measure that the unintended effects are spread around. It’s a mixed bag.

Conway’s law

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

If you’ve ever heard “ship your org chart,” this is where that comes from.

The place I see this play out most is in Information Architecture. If you squint at any site’s main menu, there’s a solid chance you’ll see Conway’s law at play.

That’s not to say that this law doesn’t play out in software architecture, but it’s definitely more manifest in navigation. Perhaps you could make a case that microservices architecture or monorepos are a symptom of changing team dynamics at big companies, though that may be a topic for another day.

Abilene paradox

The Abilene paradox is a collective fallacy, in which a group of people collectively decide on a course of action that is counter to the preferences of most or all individuals in the group, while each individual believes it to be aligned with the preferences of most of the others.

This is less a ‘law’ than the consequence of a weird kind of groupthink, but I just had to include it. Ever since Prof. Holley showed an old video about “The road to Abilene” in the Intro to Library Management course I took in 2007, this paradox has made me a little paranoid during every group decision.

In my experience, very few people know about the Abilene paradox, which is a shame. If every group making a decision had at least one person who knew about it and was willing to speak up, there might be fewer miserable groups out there.

Bonus quote

“…it has been said that democracy is the worst form of Government except for all those other forms…”

—Winston S Churchill, 11 November 1947

No matter what you think of democracy, this is surely a clever quote. It appeals to me because lots of things are trade-offs, and often folks don’t appreciate what they’d be giving up by switching from the status quo.

If you worked on waterfall projects in the olden days, you have the context for agile’s strengths, for instance. Not a lot of people would say any form of agile is ideal or the best form of project management; some may say it’s the worst form of project management, except for all the others.

Hope you liked these laws and bonus quote! Ever the optimist, I hope to post here more frequently!

<rant>

As a big fan of inflationary language, I have a soft spot in my heart for words like ‘ponthreen’, where the ‘too’ sound in pontoon gets bumped up to a three, on account of rising prices, of course.

If you Google/Bing/Duck for ponthreen, though, there’s very little aside from a mention or three in reddit comments. I consider this a travesty and injustice and all sorts of mean, nasty things, not because ponthreen is a fun word to say (though it is!), but because a subset of pontoon boat enthusiasts and especially retailers will call a pontoon boat with three pontoons a ‘tritoon’.

Clearly this cannot stand.

Pontoons are the tube-y bits

A “pontoon boat” is a boat made with one or more pontoons, which can interchangeably be called pontoons, floats, or tubes. Obviously, despite the fun rhyme, you can’t call it a “float boat” because any boat that doesn’t float isn’t a very good boat (please don’t @ me about submarines technically being boats or something). I’d assume there’s a good linguistic/marketing reason that “tube boat” lost out to “pontoon boat”, but here’s where we are. An illustration of a stereotypical pontoon boat:

If each tube/float is itself a pontoon, and ‘pon-‘ is not a Latin or Greek numeral prefix in the singular or any other number, then you can’t chop up the word to end up with junk like:

1. unitoon or monotoon
2. dutoon or ditoon (which would be a standard pontoon boat as we envision them)
3. tritoon
4. quadritoon or tetratoon
5. quinquetoon or pentatoon
6. sexatoon or hexatoon

…and so on.

A “pontoon boat” is a pontoon boat, regardless of the number of pontoons that support its deck(s). This ‘tritoon’ usage clearly must be stopped.

It might be palatable, since single-pontoon boats are exceedingly rare to my knowledge, to call a pontoon boat with two pontoons a “pontoon boat” without qualification, and then boats with more pontoons could be prefixed (with or without a hyphen) like so:

• tri-pontoon boat
• “quad-pontoon boat” or “four-pontoon boat”
• …or something like that

But tritoon is just wrong. Wrong wrong wrong.

If you can’t beat ‘em, join ‘em

Since both tritoon and ponthreen are equally wrong for describing a pontoon boat with three floats, and tritoon is already more commonly-used than ponthreen, I believe the only recourse is to now spread the word, literally, and get people calling them ponthreens.

</rant>

(Also, not nearly enough people include an opening rant tag)

P.S. In an alternate universe, “tube boat” became common usage, and it didn’t take long for the ‘b’ sounds to compmanteau (a portmanteau of ‘compound’ and ‘portmanteau’) themselves into ‘tuboat’. Some silly midwestern boat dealer would then, in an insult to alternate-universe Brad, call a tuboat with three tubes a triboat. You can see this unfold in the cutscenes of Everything Everywhere All at Once.

If you were local to the Detroit tech scene around 2013, you know that 10 years ago Vince and I had a public debate about CSS preprocessors, so this is not the first — but hopefully will be the last — time I’ve engaged folks on this topic.

If I were to coin a tl;dr that doesn’t appear anywhere else in these 4000 words, it would be this: CSS preprocessors are productivity theater and technical debt, plain and simple.

Also…

The descriptor “CSS preprocessor” is incorrect

I’m grateful to u/Scowlface for engaging with me in good faith. The one mistake they made, in my eyes, is asking, “Okay, first, why be so pedantic?”, and then claiming:

“And it’s not a “css generator”, it’s a CSS preprocessor.”

By golly my new acquaintance Scowlface, I have not yet begun to be pedantic!

The existence of a CSS preprocessor like Sass or a postprocessor like PostCSS implies the existence of a middle step, processing, that is important in some manner or fashion. That’s simply not the case.

Both Sass and PostCSS do all their work before what is inevitably a CSS file getting loaded in a web browser to provide styles for a web page. You could almost just say PostCSS is a CSS preprocessor, too, and that the processing step is the browser parsing the CSS and applying the defined styles to the DOM, but as we’ll see shortly, that’s not technically true.

The words people use to describe CSS preprocessors (and more incorrectly, ‘postprocessors’) were made up by the people selling the software to the development community. Uncritically parroting that terminology not only does nobody any favors, but in the case of insisting Sass isn’t a “CSS generator” but rather a preprocessor, you’re exchanging a good descriptor for a crummy one. Tin-pot dictators will tell you they were birthed by the gods on a mountain peak and have gotten all holes-in-one when golfing — but saying those things do not make them so, and repeating them plays right into their hands.

Sass is not CSS, nor is the more CSS-like SCSS syntax (and the same goes for LESS, Stylus, any non-native PostCSS plugins, tailwind @apply, etc.). These are all DSLs (Domain-Specific Languages) that are parsed and interpreted into CSS. This distinction is important because Sass is called a “CSS Preprocessor”, which implies taking CSS, pre-processing it, and then ending up with pre-processed CSS. But that’s not what happens. A non-CSS language is used to make CSS, hence why it’s much more accurate to call Sass and its ilk ‘CSS generators’ because that’s what the tools do: they generate CSS from something else (even if SCSS looks very CSS-y in many ways, the other available syntaxes show that it need not be).

This entire section isn’t important in any real sense, except that if you’re going to accuse me of both being pedantic and saying something “patently false”, it behooves you to think about the accusations for a second or two.

A worse developer experience

The following example, like all Sass examples, is open to criticism for not being a particularly good use of the technology. The fact that so many Sass examples show bad practices should indicate to you that perhaps something is amiss.

Let’s say you want to generate utility classes for 14 named colors, so you could put background-color--grey-light on any element and have a light grey background, plus 13 other theme colors for the same concept.

The resulting CSS in either case will look like this:

.background-color--black {
  background-color: #000;
}
.background-color--grey-dark {
  background-color: #444;
}
.background-color--grey {
  background-color: #ccc;
}
.background-color--grey-light {
  background-color: #fafafa;
}
.background-color--white {
  background-color: #fff;
}
.background-color--main {
  background-color: #007599;
}
.background-color--main-dark {
  background-color: #002733;
}
.background-color--main-light {
  background-color: #ccf4ff;
}
.background-color--second {
  background-color: #E32416;
}
.background-color--second-dark {
  background-color: #331716;
}
.background-color--second-light {
  background-color: #ffcfcc;
}
.background-color--third {
  background-color: #00838a;
}
.background-color--third-dark {
  background-color: #003033;
}
.background-color--third-light {
  background-color: #ccfcff;
}

In Sass you might use an @each loop that would look like this:

$colors: ("black": "#000", "grey-dark": "#444", "grey": "#ccc", "grey-light": "#fafafa", "white": "#fff", "main": "#007599", "main-dark": "#002733", "main-light": "#ccf4ff", "second": "#E32416", "second-dark": "#331716", "second-light": "#ffcfcc", "third": "#00838a", "third-dark": "#003033", "third-light": "#ccfcff");

@each $name, $hex in $colors {
  .background-color--#{$name} {
    background-color: $hex
  }
}

The thing is, and this is true for darn-near anything you want to do in Sass, the toughest and most time-consuming parts are:

1. Typing out the map of names and hex codes
2. Getting the syntax right for loops and stuff, effectively learning another new language

In contrast, with the same map but using regex find/replace in an editor like Sublime Text, you can make the classes one time and get on with your life:

This is important because doing it the Sass way has a lot of disadvantages compared to making the classes as plain-old CSS, even if you took the time to type them all out rather than regex-ing up a map:

• Sass introduces overhead and delays to your build process
• Sass requires you to sink time into learning its syntax(es)
• With the @each loop, if you find the background-color--black class on an element via the browser devtools, searching the codebase won’t find anything useful
• Every time you make a change to your styling, even a trivial one, Sass has to re-iterate the loop to rebuild those classes
• What happens if there’s a breaking API change at some point? You’re at the mercy of the Sass maintainers
• What happens if the site is live for 5 years and then your client wants to make a change? See the dependency hell section below
• What if you test your site and find that text just on the second-light background but not the others requires a little text-shadow?

And what’s the benefit of all this inconvenience and overhead? Some zealots might claim that the @each Sass setup lets you quickly and easily add the 15th and nth background-color class, but, like…

FFS, copy and paste exists. It doesn’t matter how many items are in the map: looping is guaranteed to lose you time compared to writing CSS. It’s just tech debt for tech debt’s sake.

Weird attitudes

Judging by all the downvotes I got in the reddit thread and posts like this one by Rob O’Leary on dev.to, it kind of feels like there’s a cult around Sass. If you use Sass and have a good opinion of it, have you ever taken a critical eye to it? Do you feel a sunk-cost resistance to abandoning a tool you like and a skill you spent time learning?

The thing I hear people say is something along the lines of “CSS doesn’t have certain features, but Sass adds them in. Sass makes CSS into something more like a programming language.” You can accuse me of building up a straw man here, but I’ve heard that exact sentiment a lot. And the problem is, it’s 100% a misconception: Sass does no such thing. Sass itself is like a programming language, sure, but all it ever outputs is plain-old CSS. There’s no escaping that. It doesn’t add features to CSS or make CSS more like a programming language: it just generates bloat for you.

I really don’t know where the mentality comes from, but it’s wild to me. Writing ‘vanilla’ CSS and not having to deal with the nodejs ecosystem just to style pages is a great feeling, so if you’ve only ever done CSS by way of Sass, I strongly encourage you to try modern CSS without the Sass crutch (and yes, clearly I’ve learned Sass and used it on many projects throughout the years, so no hypocrisy here in asking you to try something new).

Modern CSS is better than the Sass facsimiles

The original comment by u/aguycalledmax I replied to that started the scowly exchange said:

“Even with nesting coming to native css I really don’t see any reason not to use scss or sass. The DRY and maintainability benefits of your code far outweigh the imperceptible negatives of a tiny build time on your local machine.”

We’ll get into why both the DRY/maintainability and build time arguments are hogwash later, but for now I’d like to touch on why we should wholeheartedly embrace CSS Nesting specifically (when browser support is up to snuff for your project) and wholly abandon the same concept in CSS preprocessors.

Creating a similar example to those from a post on the Sass blog, here is some nested CSS that’s valid in native CSS now, and is also valid SCSS nesting:

.base-class {
  padding: 20px;

  .foo {
    color: #eee;

    &.fighters {
      color: green;
    }
  }

  .bar {
    color: #ccc;

    &.fighters {
      color: red;
    }
  }

  .fizz {
    color: #fc0;

    .ylifting-drinks {
      color: #cf0;
    }
  }

  .buzz {
    color: rebeccapurple;
  }

  .fizzbuzz {
    color: #c0ffee;
  }
}

In native CSS, the nesting is interpreted with an implicit :is() wrapping the parent, keeping the selector specificity very flat, which allows less-specific selectors if/when you need to override any selector. In contrast, all the selectors generated by Sass in the build step have a specificity of at least 2. This isn’t a big difference for a single level of nesting, but can make overriding a lot more pleasant for deeper levels of nesting in native CSS.

The other factor here is payload size. Even prior to minimizing, the CSS example above is 341 characters. That’s what you’d send over the wire and the size gets no bigger. It could get smaller with minimization and compression, but not bigger.

In contrast, the Sass build process takes the nesting above and turns it into:

.base-class {
  padding: 20px;
}

.base-class .foo {
  color: #eee;
}

.base-class .foo.fighters {
  color: green;
}

.base-class .bar {
  color: #ccc;
}

.base-class .bar.fighters {
  color: red;
}

.base-class .fizz {
  color: #fc0;
}

.base-class .fizz .ylifting-drinks {
  color: #cf0;
}

.base-class .buzz {
  color: rebeccapurple;
}

.base-class .fizzbuzz {
  color: #c0ffee;
}

The resulting CSS is 383 characters, or 12.3% larger. Yes, gzip would be very effective on those repeated base-class strings, but this is a small, simple example. More nesting makes both the specificity and the payload size issues worse for Sass.

Similar arguments exist for CSS custom properties, calc(), CSS Color Module Level 4, and the whole gamut of newer CSS features that have advantages over former Sass features. In the long run you benefit from embracing web standards over third-party tools.

Dependency hell is other people… ‘s build steps

There’s this relief you feel whenever you’ve fought with npm or yarn to install the dependencies you want, then ran your script successfully to do what you wanted it to. It’s a familiar feeling for anyone who’s ever done computer programming.

But dependencies are introducing technical debt into your project, sometimes to a greater extent than you considered at first. If you’ve installed Sass and got it working, then done some stylesheet work for a while, then ran into a dependency issue later, then fixed it to get Sass working again, you may be feeling something more like Stockholm Syndrome than actual satisfaction.

With vanilla CSS, you can make a file named styles.css or similar, put some style directives in it, then reference the file in a <link> tag in the head of your HTML documents, and you’re off to the races. Yes, you can definitely make the CSS building and attachment process a lot more complicated, but the minimum-viable example is pretty easy.

With Sass you have to do all the aforementioned things, but also:

• Install Sass (locally, in dev containers, on remote servers, or perhaps all three)
• Likely use nodejs and npm/nvm/yarn/whatever to bring in bundlers, frameworks, libraries, linters and analysis tools, watchers, and gosh knows what else
• Glue all your build chain stuff together with scripts
• Learn the Sass syntax
• Run your script over your Sass files, or keep a watcher running
• Wait for Sass to build and your other build process to complete every time you make a change
• Maintain this dependency chain over the long term, including rewriting the bundler configs to support the new version of grunt/gulp/webpack/rollup/parcel/etc. when they needlessly change their API once every two years or so
• Document how all of this works, well enough that the next person to join the team only loses a day to setting it up
• Install helpers for your text editor or IDE
• Learn the tricks for searching partial strings to find useful SCSS code, rather than whole strings in regular CSS
• Learn, and continuously navigate, the function/mixin/library/framework Sass version of callback hell where it’s not clear how a particular CSS declaration inherits various property:value pairs because the Sass feature doing it is 3+ levels deep and probably a million directories deep in node_modules
• Keep up with both new CSS features and changes to Sass/SCSS

This is all textbook technical debt. In order for any of it to make any sense, Sass would have to save you a ton of time and/or produce much better code in order to justify all the time lost doing all the above-listed frustrating junk over the lifetime of your project. The thing is: there is no way you’re making the time back up. You’re gonna lose time messing around with Sass, and your frontend stack is more brittle for the privilege.

‘Artifact’ merge unpleasantness is a perennial team issue

At least once in your project you’re gonna have to decide: should we commit build artifacts?

If you commit generated and minimized CSS output by Sass, the advantage is that you don’t have to set up your servers to do your front-end build process. Deployment is simpler, faster, and less error-prone. However, committing your build artifacts is effectively setting yourself up for merge conflicts way more often than with regular CSS, as a team of even two developers would create conflicting artifacts almost every time they touch the Sass on a feature branch.

If you don’t commit build artifacts, your server will have to be set up to be just as capable as your local machine of building CSS from your Sass source files. This, of course, is additional overhead just to get stylesheets working, and introduces its own headaches.

Do you do frontend builds directly from a local machine? Or are you using containerization like docker-compose to have a local simulation of a server? If you do use a container on your local, is your local dev container the same spec as containers used for production? If not, then there’s a solid chance that you have at least two different sets of tooling with subtly-different versions for the various constituent parts.

As frustrating as it can be for the dependencies not to install locally or for a syntax error to fail the build, it’s even more frustrating when it works on your machine but fails on the server. Tracking down what the heck must be different is a solid way to lose an afternoon. And to reiterate, none of this is required — you’re volunteering to use this optional tool for some murky reason!

It ain’t gonna work later

It’s pretty common for frontend work on a particular site to go quiet for years at a time, then for the site owner to shift focus and want updates to their existing site. With plain-old CSS you’re sure to encounter some weird old stuff, but you can be pretty sure it’ll just work. With Sass the opposite is true: I’m comfortable claiming with 95% certainty that you’ll spend at least an hour fixing dependency issues before you can get back to writing styles.

This comes down to both the commonly-paired-with-Sass nodejs ecosystem for build processes being brittle as eff and pretty irresponsible with notions like backwards compatibility (and yes, I get it, the ecosystem is getting more mature, and it’s not exactly fair to say it’s Sass’s or node’s problem if gulp changes their config format every five minutes) and with the coin toss of whether your project was set up with the Ruby version of Sass, the C/C++ version, or the Dart one.

It’s easy to brush this concern aside, since the pain won’t be until 5 years later, but it’s something you should know before you sign up: as surely as the Sun will rise tomorrow, you will spend a significant fraction of your Sass-ing time getting it to work anew when you revisit an older project. It will take up a lot of your time and it will likely be unpleasant.

Death by a thousand builds

The beginning of this section already touched on how choosing Sass is signing up for more setup time, learning, and overall difficulty than using plain CSS. One last point along those lines is the relatively-small slowdown of having your stylesheets build whenever you make a change to your Sass source.

The site you’re reading this post on uses a static site generator, Jekyll, to put the pages together when the code is deployed or during development when any file is modified and saved. Fully building the site can take between 10 and 30 seconds today, with the amount of content and assets the site builder has to process (perhaps ironically, the stylesheets technically get processed by Sass, as Jekyll kind of makes you do that, even though the SCSS file contains vanilla CSS).

20-ish seconds is a long time to wait to be able to look in my browser window and see the changes reflected on the dev site. The thing is, most of the activities like writing a blog post take a lot of time in the text editor between reloads. With CSS, often you’re writing a line or two and then checking your work, since the little increments and test tweaks all build on each other. When you’re changing two or three lines over the course of 30 seconds, an extra build time for Sass to complete of a second or two (hopefully not more!) quickly adds up.

Any one build feels imperceptible, and might be a welcome micro-break similar to the old-school trope of getting coffee while your code compiles. But taken in the aggregate, and especially combined with the startup and maintenance costs of using Sass, those build times turn into significant productivity loss.

Again, you’d have to see time savings in another way, or benefit significantly from code quality improvements, to justify the kind of time lost to all this setup and waiting. Somebody please show me the benefit. Please email me with a good example that makes this make sense!

Many Sass features encourage bad behavior

Much of what I argue in this section is predicated on one simple principle: The less CSS sent over the wire the better. Writing CSS directly and seeing exactly what you’re serving the user is helpful toward avoiding bloat, technical debt, and bad practices. In contrast, using Sass’s leaky abstractions more often than not means never seeing the mess it’s making on your behalf.

One of Scowlface’s last arguments went like this:

“If your argument is that since sass outputs css, that you can just write the css that sass would output, then yeah, sure, obviously. But it’s not as easy, and that’s the entire purpose of sass. That’s like saying, “don’t use PHP, just write C. Why write C when you can just do it in assembly? All these higher level languages just add bloat and slow down your program.”

I see a few big problems with this line of reasoning:

• Why is there merit in making it easy to generate CSS that’s necessarily more bloated than if you had written it directly?
• There are absolutely times when you’d want to choose Assembly over C, and even more for C over PHP. Not every circumstance, but when performance and executable size are important, for sure. Love and respect to developers writing in low-level languages
• Vanilla CSS vs. Sass is not an apples-to-apples comparison to C vs. PHP. CSS is a stylesheet language that only has Turing-complete features incidentally rather than being intended as a programming language in the usual sense (please note I’m not making a gatekeeping argument here — folks who write CSS are developers for sure. Y’all are my people!), so Sass cannot and should not be considered a higher-level language than CSS: Sass does something entirely different than what CSS does
• Sass is only easy if you’ve already learned it and sunk the time into setting it up, two things that are hard. From scratch it’s a tremendous hassle compared to just writing CSS

Let’s look at Sass’s feature set with the less-is-more concept in mind, and a healthy appreciation for utility-first architecture that keeps your project’s specificity graph nice and flat.

Flow control

See the Sass docs for an index of flow control items

Variables and conditionals, plus other primitives, all define logic that operates entirely within the Sass context rather than the resultant CSS.

These features are all inside baseball and can give you a deceptive impression of what the tool is doing. They’re helpful, insofar as if you’re using Sass you need these primitives to accomplish anything, but are useless outside of Sass because they’re build-time resources rather than render-time.

To go back to an earlier example, you could use an @if to put a text shadow on just the second-light background-color utility class. It would really ugly up that @each loop, and would require more time and effort than just pasting the text-shadow property:value pair into the class in plain CSS. And note: no trace of the @if would show up in the CSS. Not to sound like a broken record, but Sass features aren’t CSS features — they only exist to generate plain old CSS.

By comparison, CSS custom properties — or CSS variables as they’re commonly known — work in the render context, making them useful and interchangeable between systems. Similarly, the calc() and other functions, plus render-time CSS flow control structures like @supports and @media accomplish what’s needed in real-world styling.

These flow control features aren’t actively harmful like some of the following examples, but they certainly help enable accomplishing bad things.

Nesting

See the “Modern CSS…” section above.

The entire purpose of nesting is to write something succinct that generates way more code than you wrote. It also, by definition, is a way to chain specificity, which is also a questionable thing to do when a utility-first approach keeps your CSS payload small and makes overriding easier. The whole feature (moreso in Sass than the new native CSS equivalent) encourages you to do something bad.

Mixins and @extend

A blockquote earlier in this post alluded to DRY (Don’t Repeat Yourself) and maintainability benefits of using Sass over vanilla CSS. Both @mixin and @extend illustrate how being DRY in Sass makes your CSS very… wet? Well, whatever you’d call it, these features make it really easy to irresponsibly duplicate code in your CSS. @extend is also a good example of how maintainability is an illusion.

In the reddit thread, I gave as an example a mixin for applying an old-school clearfix (which in the age of flexbox and grid is far more of an edge case than years ago), which Scowlyface dismissed as a “bad example”. Keeping my pedantic streak alive, by the GitHub search numbers I’d rebut that it’s a good example of how Sass features are commonly used to do bad things.

Scowlyface was right that clearfix should be a utility class that gets applied in markup where needed, rather than repeating the same property:value pairs and pseudo-elements all over the codebase. This is a classic trap, of course, since the @mixin and @extend features are only useful for duplicating the output code while giving the illusion of not repeating yourself if you only look at the Sass source. You simply can’t provide a good example where duplicating code in this manner would result in a healthier CSS codebase.

When applying a clearfix class would require clicking around your IDE sidebar to find the directory holding the correct application logic or template file and then pasting the class in the correct place, then testing that the class is applied and the styles are working, if you’re already looking at the nested code block for the .new-container declaration and can’t be bothered to click, copy, and paste in another file, the lazy developer will be happy to throw a

  @include clearfix;

…at the problem and call it a day. Nevermind that at best it’s making a big comma-separated list of selectors that should all repeat the same code, and at worst is repeating the same combinations of properties and values in pseudo-elements all over the output CSS, because it ‘saved’ the developer precious time versus doing the job correctly.

Moreover, these features are among the Sass features that obfuscate the source of style directives, requiring a loss of time for developer to track how many mixins and functions deep you have to go and how many variables and parameters you have to parse (being mindful of the variables’ scope, of course!) just to find where a particular line of output is coming from. Time-savers these features are not.

Can you look at the example above and credibly say there’s any advantage to inserting a @mixin to make three little classes? Isn’t the CSS on its own a lot easier to understand and work with? Why on earth would you do this to yourself willingly?

With @extend, additionally, you’re often declaring an unenforced dependency. Let’s say you have a class,

.padded-box {
  padding: 20px;
}

and then in your SCSS later you want to make a padded box that has some more properties:

.fancy-padded-box {
  @extend .padded-box;
  background-color: #ffccff;
}

Depending on how you have your SCSS structured, .fancy-padded-box might be miles away from the original .padded-box. If a new member of the team sees the original .padded-box declaration and searches the markup for usages, not finding any, and decides to delete it, the .fancy-padded-box class will error out. The new developer might not even see the failure in their terminal window until an hour or two later, and by that time they’ve made so many changes that the notion of Sass making the stylesheets less delete-key-friendly will have turned into a lot of time lost adding the extended class back. That’s the opposite of a maintainability benefit.

Encouragement and a narrow use case

This has been a lot of words, many of them very negative, about Sass and other CSS preprocessors. Given that, and that I bear no ill will toward my fellow humans, I wanted to take a second to acknowledge that the folks who made Sass and have maintained it for over a decade has done a great thing — and I don’t want to discourage either them or somebody thinking of releasing their open-source tools in the future. The more tools the better, and for that matter the more debate the better!

Having gone through lots of features and showing ways they can easily be misused, now might also be a good time to point out two use cases where using Sass might be a net benefit:

1. If your codebase is already using Sass: if you’re maintaining an existing front end, swapping Sass for vanilla CSS probably wouldn’t save you time for the remaining life of the frontend. But if you go to re-theme, all bets are off
2. If your team makes lots of BEM(-like) components: personally I see this as something of an anti-pattern, given the utility-centric direction frontend development has gone, but big teams with big applications with lots of components and especially an existing Sass setup might benefit from the setup. Then again, if you’re doing a BEM or SMACSS kind of thing from scratch in 2023, firstly… why? And second, you might consider native CSS nesting instead

Lastly, it’s worth noting that the features of CSS preprocessors led the way to many of the CSS standards we embrace today, so we owe a debt of gratitude to the Sass team for that.

Rebuttals welcome

Did I get something wrong? Is there something great about CSS preprocessors I missed that justifies putting up with all the crummy things I’ve highlighted here? Am I a doodyhead with a butthole for a face? If you’ve got an opinion and an ax to grind because this site doesn’t have a comment section, tell me all about it. There’s a solid chance I’ll update the post with your rebuttal or link to your post.

Oh! Also, while I have you: if you any web development or strategy needs, please check out Solve it once, my Drupal-focused web dev shop.

It didn’t take long for friends to reach out, seeing if I could do some freelance website work, which ended up being a lot of fun and taking up a decent chunk of April and May 2020 when I wasn’t catching up on Star Trek.

That freelancing experience made me believe I could go into business for myself, so on June 2, 2020, I filed the business name Solve it once LLC with the State of Michigan and got started trying to drum up clients.

Highlights from 3 years of so1ve

Here are a few cool things that have happened while being my own boss the last few years:

• First client: zenput.com (now a crunchtime brand)
• First full site build: iqstrategix.com
• Did Drupal support for the former version of Bowers & Wilkins, a prominent pro-sumer audio brand, as a subcontract with Human Element
• Embedded full-time with the digital experience team at New York Public Library for 7 months in 2021
• Worked on numerous projects with Provisio Technology Solutions
• Did full-time subcontract work on government sites like Prince George’s County, Maryland and the US Department of Justice for Tactis
• Subcontracted with Casual Astronaut to make a cool STEM teachers site for Arizona State University
• Launched my own website, plus way too many open source projects, like frost

As the highlights show, I’ve spent a decent amount of time embedded on other teams, helping deliver big projects for big brands. While I love this kind of work, and especially the variety that comes with it, I’m also aiming to build more sites as Solve it once rather than on somebody else’s team.

My next big thing, outside of client work, is trying to build interest around frost, an easy-to-use free-and-open-source head start for making excellent Drupal 10 websites:

What Solve it once does

If you or someone you know is in the market for a website or other website-related services, so1ve may be for you:

• Full Drupal (a content management system) websites
• Two-week fixed-fee web development sprints
• Affordable static ‘JAMstack’ websites that are hosted for free
• Annual support plans
• “Drop everything” emergency work
• Consultation, contracting, work by the hour, and sub-contracting

Friends, family, friends of friends, family of friends, and all other permutations can get a 10% discount buying online using the discount code familyandfriends10 at checkout.

How to help

There are a lot of ways to help out, so I’ve categorized them below, depending on if you’re technical, if I’ve ever done work for you before, or if you only have a minute or two. Anything you can do helps, and I want to thank you in advance!

If I’ve done work for you before

If I’ve made you a website or done web work for you in the past, you have the power to make the biggest impact to my future business. Your honest reviews on any of the following sites (please don’t lie or leave a fake review) would be a huge boost:

• Leave a review on Google
• Review on Yelp
• Review on UpCity
• Review on Clutch
• Endorse my skills or leave a recommendation on my personal LinkedIn

If you’re into tech

It’s wild how much software is a popularity contest. Sometimes it feels really tough selling folks on free software! Every like and share of one of the following project pages could mean the next visitor will see the project as growing in popularity, rather than just some abandoned repository. Please like, or star, or fork, or otherwise show approval, for any of these open source projects:

• frost on drupal.org
• frost on github
• follow Solve it once on GitHub
• Or follow my personal GitHub profile
• .github template for organization profiles and defaults
• static website starter, finished-starter
• static resume template with lots of metadata

The last two repos on the list are technically from Lower barriers, a nonprofit started by me and a couple good friends. We’ve put LB on hiatus for the last few months, but if you’re interested in joining and participating, please reach out to let me know your interest.

If you only have a minute or two

Likes and follows on various social media sites go a long way for showing legitimacy and juicing the algorithm (or whatever the kids say these days). If I’ve never done work for you and you don’t know what a GitHub is, leaving a like or a follow on any or all of these pages would be a massive, quick help.

• Solve it once LinkedIn (I mostly post about lunch and music. HEY, it’s a strategy lol)
• Brad LinkedIn
• Solve it once Facebook
• “Friends of Solve it once” Facebook group (?)
• Solve it once Twitter (abandoned-ish)
• Solve it once YouTube

If you saw this post linked on social media, you can also share it or make your own post linking to this blog, which would be hero-level awesome.

And of course, any time someone mentions they need a website or web developer, please send them my way: for business use brad@solveitonce.com and (313) 509-7214.

Thank you very much!

So busy, in fact, that despite re-platforming this site to use finished-starter in 2020, I haven’t truly posted anything new since 2014. This post isn’t exactly a means of catching up on the last 9 years, but is a commitment to post far more frequently.

The next post, likely in the next 2 weeks, will assuredly be an overview of my business’s website once launched, with a call to action: to help me get the word out about our affordable Drupal 10 websites. For now, though, if you somehow still have this feed in your reader, first: thank you! I guess this is hello.

Hi! Talk to you soon.

Btw, I’ve added an About page. It’s pretty barebones for the time being, but I’d love to know what you’d like to see there. Hit me up at ao5357@gmail.com with suggestions.

tl;dr

• Install the Development favicon extension in the Chrome webstore
• The code on GitHub

Or read about the extension below.

About

Here at Commercial Progression we live in a bunch of environments: our local development environment, the staging ecosystem, the QA habitat, and of course production. It’s a pretty common thing for website developers; your setup is probably similar.

If you have a whole bunch of tabs open, it’s often difficult to tell which tabs are which. You might have three different versions of the same site open, and the only way to tell the difference is to click into the tab and look at the address bar.

Well that simply won’t do! There’s got to be a better way. Preferably an automated system built on an open source foundation. That’s where Development Favicon comes in.

Style your favicons

Development favicon lets you select a color and apply one of eight effects (stripes on top, bottom, left, or right, plus background, replace, cover, and xor-top) to the existing favicon for a given site.

You target sites using Regular Expression match patterns.

This setup lets you create patterns once, and have them apply to each new project (assuming the projects have a common pattern). If all your local sites end in “.local”, you can add a green stripe to the top in 10 seconds and have it work from now on. Same goes for staging. Sometimes production too.

The settings page (accessible from chrome://extensions) uses the HTML5 color picker, and features a slick drag-and-drop interface. Your settings get saved as you enter them, and they work wherever you’re signed into Chrome.

###Recipes

Here are some ideas for favicons you could colorize:

###Contribute The source code for Development Favicon is completely open and available on GitHub. If you’d like to contribute back to the project, we’re open to pull requests.

Looking for expert Drupal website design and development? Learn more about Commercial Progression.

I believe the ability to flex is an affordance. In the same way that touchscreen gestures and device orientation-detection have become UI standards, device torsion will enable new ways to interact with a device.

Device Realities

While flexible displays are a reality, many other device components won’t be practically bendy in the near future. This leads to two primary design decisions:

Rigid + Flexy

In this model, shown by prototypes at trade shows, one edge of the device is a solid housing for non-flexible components. The screen emerges from this edge, being the only flexy part of the device. I see this going two ways:

• A rounded base with the screen rolling around it for storage, making a “scroll” when not in use
• Some other, terrible design

Semi-flexy

In this model, the non-flexible components are spaced out underneath the screen somewhat-evenly, and the device’s chassis limits the amount of flex in order to prevent the non-flexible components from being damaged. This leads to a device that can bend, but not one you can roll up or crumple.

This is the overwhelmingly better idea. It will be especially practical if the battery (the most volume and mass inside any given device) can be made flexible. A semi-bendy device still allows for flextures and may be more resistant to damage, while remaining a familiar and useful form factor

Flexture Types

The variety and complexity of flextures depends on the operating flexible range of a device. Early semi-flexy devices may only have crude flexture support.

All the flexture types below can be toggled either way; bending either toward or away from the user. Where my imagination allows, I speculate on common uses for each flexture.

Vertical Bend

If a user bends the device “hamburger style” (assuming a phone form factor that’s taller than it is wide when held the usual way) toward themselves, this might perhaps trigger the iOS notification pane — or other tasks that might use a top edge swipe nowadays. Maybe this could become a flexture similar to the “pull-to-refresh” pattern.

There are at least two ways to accomplish a vertical inward bend, each with its own caveats:

1. Thumb pressing the center of the screen, index finger pushing the top of the back and pinky pushing the bottom
2. One hand grabs the top of the device, the other grabs the other

The first method involves touching the screen, which might interfere with tapping gestures. The second method requires two hands. Neither of these are show-stoppers necessarily (pinch-to-zoom requires two hands), but they’re an indication of the care required to implement successful flextures.

The user can also bend the device away from themselves hamburger style. This would almost certainly require two hands. I could see this as an alternative method to close an app, triggering a split vertical wipe animation from the center of the screen.

Horizontal Bend

A horizontal bend inwards, especially one biased slightly to the lower end of the device, could be the most-used of all the flextures. It’s just how you naturally hold the device, so activating this flexture is faster and more natural than even hitting a button or tapping the screen.

For this reason, it’s important that this be the most-standardized flexture for handheld devices. It should do something useful and significant, but not distracting in the case of false positives.

I think this flexture should toggle an app’s fly-out menu or navigate OS panes. By design standards, apps and sites will tend toward menus that wipe in from the side. It should be encouraged by OS makers that menus be fairly static and cached in memory, allowing them to fly in and out quickly.

A horizontal bend outward might be rare. It really depends on the bezel, use case, etc. Bending different directions likely won’t indicate on-screen directionality, since bending one way is substantially more tough than bending the other.

Corner-to-corner Twist

If you pinch the top-left corner (with your left hand) and the bottom-right corner and twist your hands in opposite directions, it will increment/decrement the contextually-approriate volume slider. Turning your right hand left (and left hand right) will turn down the volume. Turning it right will crank up the volume.

If you pinch the opposite corners and perform a twist, it slides the device brightness. The increase-decrease motion is always indicated by the bottom corner in a righty-tighty-lefty-loosie fashion.

Individual Corner Bends

Bending individual corners could also trigger certain actions. One cool action would be bending the corner opposite the camera, thereby taking a picture. It’s cool because not only does it make taking a picture more convenient, but it also prevents your hand from getting in the way of the lens.

Games

Up to this point I’ve talked about flextures from a conventional UI perspective. A pinch gesture does roughly the same thing in most apps by convention, for instance, so it’s reasonable to believe there will be conventional flextures. This isn’t necessarily what happens in games, though…

We’ve seen some pretty cool games that use device orientation: to steer a car or to orient a player in a 3d world. Flextures can extend these movements and allow for more dimensional movements or even distortion of the virtual worlds. I’m pretty excited about this aspect.

Torsion Detection

Along with having the ability to flex, a device that uses flextures would also need a sensor to detect the direction(s) and intensity of the flexing that occurs. Not being an engineer, I have no idea what this would entail. But I assume it’s something that can be done with current technology for the most part.

I believe torsion detection is a practical necessity for devices. If the device’s gyro is flexed one way, but the rest of the device is oriented another, the software may orient the screen the wrong direction. The same reasoning also has implications for compasses and other internals. Only by having the software be aware of flexing activity can the user experience not be negatively affected. The potential problem is dependent on the physical locations of sensors in the device, as well as by the overall device size.

tl;dr

It would be pretty cool if flexing your phone different ways was a type of gesture.

• Does this create better designs?
• Does it help me work faster?
• Does it produce cross-compatible styles?
• Does it fit into my current workflow?
• Does it avoid sprawling stylesheets?
• Does it use selectors sensibly?

In keeping up with tons of CSS-related blogs, I’ve learned about techniques that seem like good ideas on the surface, but which often fall short in the questionnaire.

OOCSS is kind of just status updates

OOCSS itself was branded “CSS Circa 2009” by its creator. In 2009, we were on the cusp of HTML5/CSS3, and perhaps a majority of web designers still fretted over IE6 backwards-compatibility. As we approach 2013, it’s probably a good idea to revisit both the conceptual framework and the CSS framework it spawned.

To me, the biggest takeaway of OOCSS is the media class. This is a class for a block element that tends to hold a thumbnail along with some text. It literally came from (re-)designing the boxes in facebook’s timeline. It’s often paired with comments, likes, or other attachments. Media-classed elements can be extended and augmented with multiple classes for particular applications. The innards of such elements can be targeted for further customization.

The media construct stems from the OOCSS recommendation to use classes near-universally. This allows an input of type “button” and an anchor to both take the same class and benefit from common styling. However, it also decouples the document semantics from the stylistic semantics, leading to lots of redundant classes in the HTML rather than redundant styles in the CSS.

What we’ve found in the mean time, from the HTML5 camp, are elements specified to enhance document semantics. Likewise, WAI-ARIA allows us to take HTML elements and assign role-based semantics (among other cool things ARIA does). The <article> tag, for instance, is a suitable container for design projects that require a box like the media class. When a style convention with arguable semantics appears, it’s probably time for a new HTML element

In the OOCSS Google Group, stubbornella explained that designing the wrapper for a site isn’t necessarily where OOCSS shines. OOCSS, by merit of OOP principles, is most useful for reusable elements; which tend to be in the main content area of a page. This is a perfectly-reasonable way to do your CSS, but it limits the purview of OOCSS principles.

Preprocessors are unhelpful

Look at the home pages for all the common CSS preprocessors. They all advertise auto-nesting rules. This might give you the impression that nesting is a good or useful practice. It is not, for two reasons:

• Overly-qualified selectors aren’t necessary for inheritance in the cascade
• Nesting is an incredibly leaky abstraction

Another issue is one of workflow. If you design and tweak using Firebug or Chrome DevTools, a preprocessor’s generated styles may not match up with the line numbers in the inspector. And if you make a change, you often have to translate it into the new syntax before putting it in your stylesheet. By avoiding a preprocessor altogether, what you see is what you get.

Stylus fucks with the syntax just for the fuck of it.

In most cases the right tool isn’t a preprocessor, it’s a text expander.

Bootstrap makes no sense whatsoever

If you’re prototyping but (as many claim) should restart from scratch for production, what’s the point?

Elements ship with default styles for a reason

Goes to obscene lengths to avoid semicolons in JavaScript (not a CSS thing, but is dumb)

A fool with a tool is still a fool — and it shows in the shoddy one-off sites made in bootstrap

H5BP gets it most right

Normalize, then extend

Quick note: you really only need/want 1 apple-touch-icon.png in most cases

The One-size-fits-all Answer for CSS Development

Start with a normalization stylesheet and HTML slug

With media queries for mobile-first responsiveness

With media query for print

With basic layout (role=”main” and HTML5 elements)

Take H5BP’s advice and get friendly with backspace — delete the conditional-comment head and modernizr if you’re not using it

Implement, then fight, your layout

Layouts aren’t always easy

Remember to pad the main container for thumb scrolling on mobiles

Grids help some people, but are they truly a time-saver?

Set ‘skin’ defaults at the base tag level and try not to override

Avoid classes in favor of tags > roles > other attr

This might sound contrary to other advice, but it’s meant to make you think about semantics. Anyone who tells you classes should be semantic isn’t really thinking about semantics at the right level

If you have fewer rules, individual selector performance is less of a concern

The cascade should be used mostly/only for special cases

Note: The speed enhancements below are mostly about optimizing files and client-side stuff. You can also speed up your catalog on the server side with hardware and database optimization, though doing so is likely to require assistance from Innovative.

Why

Faster-loading pages make users happier. Some speed-enhancing techniques also increase server performance and decrease the amount of bandwidth used. Page speed also factors into search engine rankings, though that is less of a concern for our catalog than our website.

How

Most of the improvements came from Google Page Speed recommendations.

Sprites

Fact I found interesting: Before I applied the catalog changes, the directory contained 682 files. It now has 49. Having fewer files doesn’t inherently speed up the app, but it does speak to the nature of the changes.

There are two types of images in a Millennium “example set”: icons (or whole buttons as images) and media type indicators. A typical setup, until recently, had 145 or so button images. The most recent example set available from Innovative has 45 icons and a couple support images for making buttons. These images are coupled with some crufty markup to make the buttons work. The latest set also ships with 39 media indicators (in fairness, we’d use maybe 13 of those for our library).

CPL now has one image for all the icons and one image for all the media indicators. In total, the catalog screens have 8 images: one is required but never used, another never seen, and two others used infrequently. Yes, we grab book jackets from an external service, but that’s the extent of the catalog graphics.

An individual example icon weighs in between 600 bytes and 1.3K. Our icon sprite is 5.44K. It can be loaded once and cached on the user’s machine. For pages with many buttons, this results in far fewer HTTP requests and a smaller total payload. The same goes for media indicators.

How do we pull this off? We use two spriting techniques: ‘traditional’ sprites and pseudo sprites. The styles to makes these work can be found in the catalog stylesheet. What’s novel, and how you can pull this off in Millennium, is in carefully crafting what’re called ‘wwwoptions’:

# pseudo sprite example
ICON_BUT_REQUEST=<span class="but icon request">Request</span>

# traditional sprite example
IMAGE_MATTYPE3=/screens/spacer.gif" class="media-icon bookmp3

As you can see, in both cases activating sprites involves appending classes to a particular HTML element. In the case of the pseudo sprites, there’s a class that makes anything look like a button, one that pads the left-hand side and loads the icon sprite image into the space, and one (‘request’ above) that stipulates where in the sprite image the request icon appears. In the traditional sprite, the “IMAGE_MATTYPE3” option must be an image. Since there’s no getting around that, I used a spacer gif. It’s 43 bytes — the smallest practical image for the web. I then circumvented the wwwoption to add the classes to the image. Those classes set the background size and position the sprite image.

Be advised that pseudo sprites only work in standards-compliant browsers and IE8+. If a substantial number of your users are on IE7-, you may want to wait. Users with non-supporting browsers can still see the button style we use, but the icons won’t appear. Sites that work for everyone but look better for modern browsers are considered progressively-enhanced; that’s what you can consider these buttons.

Distrusting Bowker

We use Syndetics Plus, Librarything for Libraries, and Google Books previews on our bibliographic record pages. That’s a lot of stuff to load. As part of an overall improvement in JavaScript performance, we changed the way we pull in those resources.

Syndetics Plus, by default, loads onto a page something like this

• Page calls widget.js directly, via a script tag
• widget.js loads jQuery from Google’s CDN
• After jQuery is loaded, widget.js loads widget_connector.js
• widget_connector.js gets ready, finds ISBNs on the page, and requests an ISBN-specific widget_response.js
• widget_response.js writes to the page and asks widget_connector.js to do stuff

This is a mess. It’s a long chain of serialized resources that aren’t well-cached by the browser, aren’t served minified and/or gzipped, can’t be served over SSL, and that block full page rendering until they’re complete (whether or not there’s a result). Total payload for this process is 49K.

Librarything for Libraries is even worse (here I go again). It goes:

• Page calls widget.php (served as javascript) directly, via a script tag
• widget.php loads connector.php
• connector.php pulls in connector_LB.css
• connector.php gets ready, finds ISBNs on the page, and requests an ISBN-specific widget_response.php
• widget_response.php writes to the page and asks connector.php to do stuff

What makes this process so awful is connector.php. It’s over 150K all by itself, and it includes the sizzle selector library and a bunch of other utilities. Which makes one wonder: why not just use jQuery? Moreover, why does a file that loads a comprehensive selector engine need to define getElementsByClassName()? connector.php’s JavaScript is a Frankenstein’s monster of code that pollutes the global namespace. I’m afraid that some people might be having nightmares over it. This file also includes all functionality for all different ILSes (not just Millennium, the one we’re using) and all LTfL features (a small fraction of which we’re using). This massive file is unminified and uncompressed and is part of a call chain that doesn’t support HTTP keep-alive. Minifying the file wouldn’t solve all the problems, but it would be less than half the size (mostly because their variable names are massive). Ditto on gzip compression, which could make it less than a quarter of its heft over the wire (without minification!).

We pull in jQuery from Google (the old-fashioned way, so it client-side caches for just about ever) and use it for almost all the (CPL-made) JavaScript on the page. The code for us to replace Syndetics Plus’s payload (25K without jQuery) is 150 bytes before compression. The nearly 200K for LTfL? Less than 1K, and I could probably optimize further.

CPL-specific code pulls the primary ISBN from bib record pages, validates it, then makes sure the page is served as regular HTTP. All of this occurs after the page has already loaded. If the conditions are met, we then feed the ISBN to the widget_response files from the two services, getting back just the results specific to the bib record. The widget_response files handle writing to the page all by themselves, so the service-specific code just adds things those scripts expect to find and handles certain on-page actions. Since we do this all asynchronously, the page loads (and feels like it loads) as quickly as Millennium allows.

Being careful with the three widget services provided the biggest overall improvement to payload size and page rendering speed. Google Page Speed eliminated the warnings about redirects, uncompressed resources, request serialization, unminified javascript, and undeferred scripts.

What’s funny about the terribleness coming from Bowker’s servers is that a big part of improving the situation is both easy and a big sack of win. Users would get faster pages and Bowker’d save on bandwidth and hardware specs. Some quick apache config of mod_expires and mod_deflate is all that’s required to pay dividends. A deployment scheme involving minification and/or a refactor of the connector scripts would be more time-consuming, but could make the widgets substantially faster. Serving out static scripts without query strings would be a huge help, for instance.

More JavaScript Optimization

I was more diligent about jQuery best practices like using fast selectors, caching selected objects, and delegating events to their appropriate containers.

Millennium has its own JavaScript library. It’s ordinarily served out as 3 files, but we weren’t having any of that. Our Millennium setup prevents the default files from loading, and instead serves a single file with all three components minified. iii.js is just under 20K before compression, and 5.2 over the wire. That’s 2 fewer HTTP requests and 4.4K less payload on every page.

Image Optimization

I ran all the catalog images through PNGGauntlet, which uses PNGOUT to reduce file size — sometimes by 25% or more. For high-use files, I also weighed the quality reduction of making them 8-bit PNGs; the sprites, for instance, get served out as 8-bit files, making them substantially smaller.

Web Server

I also rolled out a sprite for the site’s layout and theme, optimized the chat widget, and combined and minified CSS files for use by the catalog. Our web server, in contrast to the catalog, is pretty aggressive about caching. Files are served with far-future expires headers. APC for PHP caches the opcode to minimize file reads; this results in faster execution speed across the board, but not necessarily faster serving to the end user. We have drupal caching set up, which benefits from MySQL query caching. Apache gets some love from the OS’s buffer cache. Altogether, the website is a layer of caches.

What’s Next

I’d like to reduce the payload of every page on our site by rolling out a new theme. There’s a lot of extraneous markup and styling that can get cut out pretty easily. Other possibilities:

• Optimize images as they’re uploaded
• Minify CSS and JavaScript on theme deployment
• Defer jQuery and other scripts on page loads
• Put stuff into a cache manifest
• Investigate mod_pagespeed to do some of this stuff automatically

For the catalog, a few squeaks of extra speed could come from moving static files to our web server (which has longer cache lifetimes), combining the (minified) catalog CSS into the site CSS, and working with Syndetics to get book jackets from URLs without query parameters.

tl;dr

Google Page Speed.

Notes

You’ve got the wrong guy

I originally proposed this session not because I have a ton of experience on the topic and all the answers, but because I wanted to use presenting as an excuse to learn about git.

If you’ve been using git for a long time and/or have memorized large portions of the Drupal APIs, chances are you won’t be able to learn much from me.

WTF is a git!?

The word git was first a British slang word for an annoying or stupid person. The software was named self-deprecatingly from that word. I like to think git stands for something else though: good shit.

Git is a fast, distributed version control system.

It was originally developed by Linus Torvalds in 2005 to be used for developing the Linux kernel

If you’ve used another version control system, you might wonder what sets git apart.

From what I’ve gathered, the most important differences between git and other systems are:

• Git is distributed נthis is important, because having a local copy of a repo lets you access the version history easily, commit whenever it makes sense, and push it to one or more repositories, or remotes, based on the structure of your project
• Git reduces the pain of merging, which means that you can make lots of branches without worry

Other systems, like CVS, subversion, and others, are also considered slow for accomplishing certain tasks. While I don’t have a great means of comparison, git seems pretty quick to do most everything.

Drupal and Git

The Drupal project switched from CVS to git in February 2011. The changeover is a 3-phase process, of which they’re on phase 2.

1. Phase 1 was a git mirror, so that people could test and develop in git without affecting the project
2. Phase 2 is a centralized model based entirely in git
3. Phase 3 will be a decentralized, GitHub-like model that will change the Drupal.org contribution workflow. Details are still being hashed out on that front

Local Tools

Locally, there are a few tools that can make routine tasks fast and can integrate with the tools you already use.

I’m a visual, GUI guy, especially for menial tasks. So I like TortoiseGit on Windows, along with a Git plugin for Notepad++. TortoiseGit makes pushing changes a job of a few clicks. The Notepad++ plugin lets me press Ctrl+Alt+C, type a commit message, and click a button to commit changes to one or more files. If you think vi is a pain in the butt, tools like these are for you.

Remote Tools

It’s probably not just you doing development. Even if it is, there’s a compelling reason to have at least one central place for your repositories, which I’ll explain later.

But a side reason to have bare remote repositories is that you can use tools intended for remotes, like redmine. Tools like this add another layer for project management. You can do project planning, bug tracking, wiki documentation, and other such tasks from a web interface, letting either you or your team keep track of things. And if your project is out in the open, you can leverage a much larger community using sites like GitHub, Google Code, or SourceForge.

Your First Repo

Let’s say you have a directory of files that you want to put under version control at that path. You’d go there in your terminal, then initiate a new repository. Next you’d add all the files. Those files are queued up and ready for the first commit, which you then perform.

If you don’t use the ‘m’ option to add a commit message, the commit command will show the log entry for the commit in vi, and you put the commit message at the top. It’s at this point that I’d like to reiterate that vi is a pain in the butt.

So that’s how you create a new repo from bash

Commands

These are the git commands you might use in day-to-day work

Point at commands and explain what they do ^ Learn what the commands do

These commands are used less frequently (in general), but it’s good to know about them

bisect lets you determine where a bug began in the revision history, using a binary search to split the possibilities in half each time.

These are also git commands, though you might not use them very often or ever.

stash is commit for wusses

Workflow

So let’s talk workflow.

At my job I’ve got two Drupal sites: “Beta,” which isn’t really the right name for it, since at times it’s a dev box and at others it’s a beta-slash-QA machine.

And the live site.

The design and development parts of my job revolve around creating modules and themes to add functionality and enhance the design of just those two properties.

I’m guessing that’s NOT what your jobs are like. I’m guessing you make lots of sites. And those sites in various states exist in multiple places, like your local dev machine, an internal server for testing, and external hosting that you don’t necessarily control. I don’t envy you.

Wherein I Tell You Not To Hack the Core

A site is Drupal core, plus contrib, plus the data in your database.

Since Drupal is modular and nearly everything can be changed via hooks, it’s really pretty rare that you have to change anything in core. And if you do, I’ve found from experience that it’s usually for temporary debugging rather than for permanent changes.

Do not hack core.

Avoiding Temptation

So from Do Not Hack Core we can take away that all the things on the left are things you shouldn’t mess with, and the thing on the right is the only place that customizations go (unless you have a weird multisite setup, which is cool, but your workflow’s going to be different).

A repo at the whole site level is redundant, and reinforces the opposite of the number 1 best practice of the Drupal site-building community.

Drilling Down

What about at the ‘sites’ level?

This is workable, but you might notice something immediately.

Look at the sites/all/modules directory.

You’re probably not going to be hacking contrib either! All of those modules are version tracked in git on the drupal.org site. The vast majority of those modules require zero coding to work exactly as expected. Putting them under version control doesn’t accomplish much.

Then there’s sites/default

sites/default/files contains uploaded and attached files. Those files are site-specific and are subject to database dependencies. The files also tend to be images and other files that are unlikely to change. There are a number of reasons why version controlling those files is impractical.

On the other hand, sites/default/settings.php is a good candidate for revision control individually, as it’s something that you have to work on in the development process, and some of the settings will likely have to change depending on where the site lives. The branching model of git could be really useful for this purpose.

.gitignore Files

One way to wrangle sites/default/files and streamline the process is with .gitignore files. With a well-made, well-placed .gitignore file or two, you can continue using git add . and git commit -a without adding stuff you don’t want to your project.

.gitignore files let you choose files to omit from the versioning index, based on wildcard notation. So instead of omitting /sites/default/files wholesale, for instance, you could just selectively ignore boring images and junk while preserving the directory structure wherever the repo might end up.

What You’re Controlling

Conceptually, the two components that you’re likely to work on that can most benefit from version control are:

1. Customizing the theme to the client’s needs
2. Developing custom modules or modifying one or more contrib modules

If you start with a working theme, like Zen, you can clone down a repo from Drupal.org and use the history of that particular part of the project if you need it. You can create your own branch for your theme and develop from there.

If you code up a custom module, it might only be useful for a single site a single time. But maybe the functionality you add is something that other clients might want, or that can be contributed back to the Drupal community. Modules are reusable pieces, so structuring your repository environment to make them accessible for all sorts of projects is a plus.

Hypothetical Model

Here’s an example of what repositories on a central server might look like.

I made the directory structure here very flat, putting core, modules, themes, and the site_projects repositories all within a single folder. This would work well if you always use the same base theme along with a limited number of custom modules. This particular setup plays nice with management software like redmine, which is one reason a flat structure is attractive.

If you’re going to have lots of distinct themes and modules, it might be helpful to create big repos called modules and themes, then use git’s submodules functionality to manage the individual drupal modules contained within. Thanks Ben for the submodules tip!

Now that we have a central place for all the things we’re working on related to building our sites, we can optimize our workflow to play nice with version control.

Leveraging Synergy

One way to do that is to set up pushing and pulling.

If you don’t already have ssh keys set up between your development box and your repository server, setting that up will make it a lot quicker to push and pull from git. If you want to deploy via git from the repo server to other machines like your site testing server or even live web server, you’ll also want to set up ssh keys between the those boxes.

On your local dev box, use the clone command to make a local version of the repo on your server. When you do that, the source repo becomes a ‘remote’ called origin.

Make some changes to the local copy (you can branch if you want to, you can leave master behind). When you’re done making changes and they’re ready for other people in your shop to see/use them, use the push command to send them back to the origin.

Drush Make and Install Profiles

Once the changes are on the server, you can pull them to your deployment boxes, or…

You can get fancy.

It’s a common use case: you end up using the same base theme, modules, configurations, and other tweaks on most of your projects. You might already have an “install profile” informally; Drupal with all the stuff you use all in one place.

The “drush make” command lets you generate makefiles that turn your informal install profiles into the real deal. In Drupal 7 it’s easier to make profiles that configure things on install, but technically it should be possible in D6 too. Some combination of the features, strongarm, context, and other helper modules could let you automate some impressive stuff — like pre-built views.

Hint: it might be manual coding work, but if you install a whole bunch of similar sites, writing a (profile name).install file could be a time-saver in the long run. Especially if you swipe one from an existing public profile and suit it to your needs.

You can use the drush make command to import all the dependencies for your profile wherever you need them. Then just run the installer (which if you’re super fancy you could get working with drush site-install) to have a functional site in the time it takes to make a pot of coffee because your junior dev doesn’t know proper coffee machine etiquette.

The makefiles are really flexible, so you can choose particular version numbers of modules for compatibility, apply patch files to change modules or core code, or grab external libraries from tarballs.

Nailing down a “holy grail” workflow for this sort of development takes time and effort, and I certainly don’t have all the answers.

Over the next few weeks, Alex Fisher and I will be working on drush make and workflows, and will report useful findings to our respective blogs.

You may also ask about how to go from local dev to testing to quality assurance to live, all while easily managing your databases. You may ask that, but I don’t have an answer. Sorry.

Pay it Forward

If you’d like to become a core developer or get involved in a contrib project, a working knowledge of git will help.

I’m fighting the urge to give nitty-gritty details here, as the instructions are both technical and well-documented. If you’re not a project maintainer, contributing code involves creating patch files based on numbers from the issue queue. If you are a project maintainer, you can interact directly with the remote repo (albeit while following the guidelines).

One reason I’m avoiding an in-depth explanation is that the Phase 3 git migration could very well change how things get developed on Drupal.org.

But here’s how to create a patch file, just in case.

Just one commit is the easiest for contributing back patches.

The Version Control tab on project pages gives really good instructions for grabbing source repos and other contibution tasks, including the specific clone command you need to grab a local copy of the repository.

So now that you’re a git expert, go out there and contribute back to the Drupal community!

Thanks for putting up with me!

This tendency has led to me using them for my slide presentations. I’ve had two in the hopper that I presented at the Michigan Library Association’s Tech Escape workshop in May. As is always the case with my presos, be forewarned that they contain a lot of salty language: If you have any dry erase board art requests, please leave them in the comments and I will try my best.

Over the last year, I’ve done some other transliteracy-related stuff that might interest you:

• Further attempted to explain the usage of the word ‘language’ in the context of the model
• Asked for feedback on a draft of Redefining Transliteracy and stirred a cauldron of nastiness
• Demonstrated how badly the word ‘medium’ is misused in writings about transliteracy
• Put the “Blueberry Smoothie video” into a language model context to show a practical application
• Showed that the term Information Literacy is a dumb name for the good stuff done under that umbrella
• Really drove home that talking about media rather than language is distracting as hell
• Started a community bibliography of transliteracy-related links on reddit

Starting out, and despite my first tweet calling transliteracy bullshit, I was conciliatory and downright friendly. After putting some positive work out there and being ignored, I chose to approach the topic differently and talk about the controversy. The L&T librarians told me that I had gone too far, so before publishing Redefining Transliteracy I scaled back and was only semi-controversial (if you consider pedantically listing problems with a definition controversial).

Thing is, that post was probably the most popular of the whole lot. It was even the subject of an assignment for a Digital Media Communication class at Rider University (co-instructed by the truly inspirational John LeMasney). I hope most of the post’s appeal was that it offered a compelling case for the adoption of a model for transliteracy that people find useful. I suspect that part of the appeal was the oh-no-you-didn’t out-calling of the PART definition. So screw it, this stuff’s been bugging me…

PART of the Problem

If the original “working definition” of transliteracy were claimed to be proprietary, it wouldn’t be a big deal that my criticisms (let’s call them “bug reports”) and suggested improvements (‘patches’) have fallen on deaf ears. But the seminal First Monday paper on transliteracy refers to it as open source thinking. Professor Thomas calls transliteracy an open source concept in a well-circulated video:

We see it as an open source concept, and we offer it up for you to think about, develop, write about, go to Wikipedia and argue about the definition…

One immediate problem is that Wikipedia is a bad place to argue about the definition, since it’s a place for things notable outside of itself, not original research or discussion leading to development of new ideas. While it might be acceptable to have a discussion of wording on an article’s talk page to some extent, arguing about the definition using Wikipedia as the sounding board will generally lead to NOR, NPOV, and/or CoI issues. It’s precisely why I haven’t personally made any edits to the transliteracy page. If you don’t already have your hat in the ring, I encourage you to edit on the language model’s behalf.

Calling transliteracy open source is really quite hollow. Is the transliteracy blog really all the source? Where’s a clear explanation of licensure for applicable source, besides a CC icon on the First Monday article? Where’s the mechanism for reporting bugs and submitting patches? The fact of the matter is that there is very little open source about PART’s work on transliteracy. It’s a buzzword in a sea of buzzwords.

Call to Action

PART, if you do not wish to explicitly put the transliteracy concept under an open source or open creative license, release source material in the same manner, and ideally explain the mechanism by which the community can contribute to the project, you should publicly clarify that transliteracy is actually a proprietary concept.

Neither PART nor Libraries and Transliteracy have posted about the language model. Since I’m certain that prominent posters of both those blogs have read Redefining Transliteracy, it’s curious to me that they haven’t talked at all about the language model on their respective blogs. To me that’s a lie of omission, or worse yet a faith-based lapse of intellectual honesty. After all, they’ve been presented with evidence to the contrary of their claims:

1. The things listed in the definition (signing, orality, handwriting, etc.) aren’t established to be platforms, tools, or media either individually or as a group
2. The property of platforms, tools, and media that allows a literate person to go across or between them is not explained (and I contend, _cannot be explained _– a single unit is necessary for comparison)
3. All other criticisms aside, the order of the list is nonsensical, yet easy enough to change to chronological, alphabetical, or to delete altogether
4. Interaction is just a series of reading and writing acts as it applies to literacies, so including it is redundant
5. Talking about literacy as a function of platforms, tools, and media is akin to telling an auto mechanic over the phone that your car is yellow. Sure, color is an important attribute of a car, but the mechanic is more concerned with the make, model, and mechanical attributes of the vehicle. Literacy is about reading/writing stuff (ie. messages in languages), not where the stuff’s written (ie. medium)

Unless there is some means of reconciliation to which I’ve not been made privy, believing transliteracy can operate under the PART definition requires faith: belief in the absence of (or in the face of contradictory) evidence. That’s not a leap I’m willing to make. I’ve proposed a patch for a definition based instead on language (with thorough explanation of what language means in that context) that eliminates all 5 of those problems. Of course, if there were problems with the language model, I’d be interested in exploring those as well.

Maybe the silence on those blogs is because of personality conflicts with me. But that only goes so far; at some point pointing at me and saying I’m being arrogant or condescending just ends up being a distracting Argumentum ad hominem. If you think I’m an asshole and don’t want to subject your readers to my douchitude, just don’t mention me by name or link to my blog. I don’t care – all I care about is furthering the discussion of transliteracy by putting ideas out there. If you’re unwilling to tell your readers about ideas because they conflict with your pre-formed assumptions, who’s the real asshole?

One thorny problem, though, is over-riding the style of certain elements that use the width of the screen liberally by default. One such element is the venerable data table.

Coyier’s solution is great in that each table cell is labeled. However, doing this requires either writing CSS manually for every data table on the site (which is near-impossible for large sites) or having the same thing done with scripting on either the server or client side:

I propose a generalized solution that requires no scripting whatsoever. The drawback of this method, though, is that the cells are not individually labeled. The example is also more compact, but this aspect can be tweaked by marrying the two methods:

@media screen and (max-width: 720px) {
  table {
    display: block;
  }

  td,
  thead th {
    border-color: #444;
    border-style: solid;
    border-width: 0 2px 0 0;
    display: inline;
    float: left;
  }

  td:last-child,
  th:last-child {
    border-right: 0 none;
  }

  thead th {
    background: transparent;
    font-size: 1.1em;
  }

  tr {
    display: block;
    float: left;
    clear: left;
    padding: 6px 0;
    width: 100%;
  }

  thead tr {
    border-bottom: 4px solid #444;
    margin: 0 0 .3em 0;
    padding: 0 0 .2em 0;
  }

  tbody tr:nth-child(even) {
    background: #ddd;
  }

  td:nth-child(5n+1),
  th:nth-child(5n+1) {
    background: #FFD8D8;
  }

  td:nth-child(5n+2),
  th:nth-child(5n+2) {
    background: #FFE8D8;
  }

  td:nth-child(5n+3),
  th:nth-child(5n+3) {
    background: #FFF8D8;
  }

  td:nth-child(5n+4),
  th:nth-child(5n+4) {
    background: #D8FFD8;
  }

  td:nth-child(5n+5),
  th:nth-child(5n+5) {
    background: #D8D8FF;
  }
}

Open the working demo and resize your window to under 720 pixels wide to see the effect. I call this approach the “Rainbow Tables” method :-)

Thanks to Chris Coyier for posting a thoughtful working solution, and thereby motivating me to post about my approach after sitting on it (in production no less!) for almost a year.

It’s with that goal in mind that I’m releasing these 65+ documents. This release makes up only a fraction of the electronic documents that could tentatively be shared, but it’s a start. There’s some good stuff in there; also, some pretty useless stuff.

I look forward to continuing this exercise as the year goes on.

Given that turnabout is fair play, and that Lane specifically requested feedback, I have a definition-based question regarding his recent post:

What definition of medium is used in this context?

Mean Medium? Mode?

To me, a medium is a go-between over time and space used to convey information:

• An artist’s medium might be oil on canvas
• A telegraph’s medium is electricity over wire
• At the endpoint of a telegraph (or phone, or radio) is another medium — waves of sound over air

Medium can inform us about a lot of things. It can also confuse the issue. The reason I’ve pushed so hard for literacies to be defined as language skills is that many languages are relatively medium-agnostic. A letter written in ink on paper and one written in marker on posterboard are different in many ways, including both medium and aspects of visual language; but if the textual content of both is the same, the written language of both is equivalent. If that same text is on a computer screen or a television or a tattoo, the written language portion remains congruent.

In usage, people also tend to conflate medium with mode (semiotic modality). Modality is nearly a sensory means of categorization. Except it’s not.

Whether medium or modality, questions arise:

• Is there any difference between watching a video on television or on YouTube? Is it the video that’s different? The screen? Or is it the non-video stuff that surrounds a YouTube video?
• What about a watching a film on an old CRT and a new HD LCD? Different literacies?
• Isn’t print literacy a visual literacy? If medium or mode is important, what is the necessity of the distinction?
• If someone reads text on a computer, is it print literacy or computer literacy or both? Why?
• If both the medium and the mode of spoken word and of music is the same, in a medium-or-mode-literacy world can they be considered the same literacy?

Languages

Language requires a medium. Communicating (over time and space) constitutes information being encoded into signs and symbols and sent over a channel, then decoded by the receiver(s) to be interpreted. Often, though, changing the channel has little effect on the integrity of the semiotics. McLuhan’s stickiest mind-virus, “the medium is the message,” is widely misunderstood, and is dead wrong much more often than it is right.

Since literacies are abilities for a sender to write and a receiver to read a message, rather than abilities of either party to grok a medium, it makes more sense from a literacy taxonomy standpoint to define and categorize literacies by linguistic properties rather than media.

Also, I think the literacy ecosystem would be a lot cleaner if we could agree that, whether “information literacy” is actually a literacy or literacies or not, its name is a really crappy mistake.

Otherwise, the diagram is fantastic. It’s especially astute because it shows how literacies named and in common use can be grouped, even if those named literacies are themselves problematic. Literacy sucks indeed.

For one thing, most library websites are really outdated and bad. Comparing the design/development workflows of Apple and Google (nice!) or Amazon and Netflix (not exactly gems of design) to how libraries maintain their sites is apples-to-oranges. If a library has a flat-file website (Not a straw man: this is common in libraries!), performing a complete redesign/redevelopment is probably advisable. A “slowly evolved” CMS developed in-house at a library is likely to be slapdash, and there are tons of available CMSes that are well-designed, secure, free, and supported.

What’s not mentioned in the original post is that redesigns don’t have to be long, painstaking processes. Bad redesign processes are that way, but a sufficiently-experienced and talented designer can ease those woes. The solution for doing a good redesign is to have a good designer.

Likewise, iterative design isn’t always a breezy process, and it often isn’t design. Design needs control; website creative control is often lacking in library environments. What often ends up happening under the guise of “iterative design” is actually a patchwork; sometimes from having too many cooks in the kitchen, sometimes from having one crummy cook. We’ve all seen these websites; they start out clean and freshly-designed. Then someone pastes in a widget and it clashes with the design. Then comes more widgets ad nauseum until the site looks and works awful. As such, the solution for doing good iterative design is to have a good designer.

Library folks: don’t resist redesigns. If a well-designed website is important to you, hire a good web designer. Trust their judgment to decide whether the best course of action is to iteratively improve your site or to do a full redesign.

tl;dr

Information Literacy is a bad name for really good concepts. Let’s change the name (again!) to avoid confusion.

Plausible Fallacies

Rothman’s post starts with the two most common definitions of literacy:

• an ability to read and write
• knowledge of a specific subject

Nothing wrong there. However, it’s implied that for the purposes of transliteracy the second definition is the important one. I don’t see how one would reach that conclusion, given that the definition of transliteracy quoted later in the post starts “Transliteracy is the ability to read, write and interact…,” pointing to the first definition rather than the second. Transliteracy is about reading and writing (or their equivalents in other senses/contexts); working from some different assumption is a straw man.

The second problem is that Information Literacy is not a literacy per his own criteria. If a literacy is an ability to read and write or knowledge of a particular subject, where does “Information Literacy is the set of skills needed to find, retrieve, analyze, and use information”  fit? The common definitions of IL as critical skills are incompatible with the extended-but- conventional literacies of transliteracy. As such, comparing IL to transliteracy in such a manner has no bearing.

Implications

This framing of transliteracy as a subset of Information Literacy was implied by Lane Wilkinson’s post Transliteracy and Incommensurability, further implied by Rothman’s, and elaborated upon by Meredith Farkas, Lane Wilkinson, and others.

The second problem I mentioned — that Information Literacy isn’t a literacy — underlies the growing misconception. IL requires conventional literacies, but is not encompassing of them by definition. IL advocates apparently consider IL to be all- encompassing, but that’s a difficult-to-defend position. As such, the topics important to transliteracy, at least before last week, are distinct from IL.

The ensuing discussion has led to confusion over the practical boundaries of these terms. For instance, it isn’t clear how big transliteracy’s domain is per this newly-thin-air-pulled definition. In Why Transliteracy?, Lane insinuates transliteracy encompasses the Venn diagram of IL:

For me, transliteracy is the bridge between isolated spheres of information literacy,…

But on his personal blog, he writes:

I’m only using transliteracy as a catch-all for one particular slice of information literacy that I haven’t seen before.

This leads me to wonder: is transliteracy an umbrella over Information Literacy and other literacies as most everyone seemed to agree prior to last week, or just some small sliver of IL?

Call to Deprecate

It’s neither, of course! Information Literacy is the notable exception to the transliteracy umbrella. I hinted at this in my Redefining Transliteracy post and a smidge on twitter; here are the charges against IL’s compatibility with transliteracy:

1. Transliteracy is an ability to read and write across things (which I frame as languages, while others prefer platforms, tools, and media for some unknown reason), whereas IL is an ability to find and critique information
2. From a reading/writing lens, or any lens for that matter, all literacies are information literacies. IL as a term is redundant and overly-broad
3. However an information literate entity interacts with information, that interaction is indirect, as information does not exist in any raw form. IL as a term is non-specific to the point of triviality

I cite these charges as more than just a reason not to compare Information Literacy and transliteracy directly; I also contend that it’s reason to deprecate Information Literacy and call its skills something else.

We’ve done this before. As a field of study, Library and Information Science effectively deprecated the term “Bibliographic Instruction” in favor of “Information Literacy.” The reasons behind this switch, it appears to me, were fourfold:

1. Proponents of Bibliographic Instruction became entrenched in out-moded concepts and techniques, and were unwilling to adapt BI to new technologies and methods
2. The word ‘Bibliographic’ itself implies books. Library-ish instruction is about much more than books
3. Information Literacy as a term focuses on the skills of the learner, whereas Bibliographic Instruction as a term was about teaching those skills
4. Information Literacy sounds really frickin’ good

If David Rothman is correct about anything, librarians are pedants of language . As such, clarity in the terminology we use for our core principles should be paramount. Additionally, re-re-coining this set of skills might cure what many seem to agree is cyclical entrenchment (per #1).

Here’s what I’m proposing: From some point in the near future on, people talking about the useful, respectable principles currently referred to erroneously as “Information Literacy” should instead use the term (insert term here). Previous references to Bibliographic Instruction, Information Literacy, and other less-than-ideal terms should be considered (insert term here) by implication.

Conclusion

I think transliteracy and Information Literacy are like peanut butter and jelly. You can have one without the other, but they’re usually better together. If we can remove the myth that IL is a literacy of comparison (through deprecation or social agreement), we can more effectively work to develop a helpful instructional ecosystem for our patrons. We can look at transliteracy for all the different ways people encode and decode information, and Information Literacy for the critical skills associated with that information parsing.

One thing came to mind when thinking of examples: Brian Hulsey’s Everyday Transliteracy video. It’s known as the “blueberry smoothie” video to many; it shows how someone might communicate the same message (a blueberry smoothie recipe) using different websites and other forms of communication, and all in a concise, friendly manner.

Let’s look at the examples through a linguistic lens.

Written Language

Most examples involve some form of written language. In many cases, though, communication via a particular website or other form requires subtle changes of dialect or language variant.

Email

In many ways, the language used in email is most like that of a written letter from perhaps a century ago. If a writer wished to ignore clear, concise business style, he or she could write an email of flowery prose or any other style you might otherwise encounter in written language. To me, the written language of an email is something of a baseline for comparison to other language usage.

Twitter

Linguistically, twitter is an interesting variant. Where you might devote a whole paragraph in an email for a stand-alone idea, the standard on twitter is for one tweet (at 140 characters or fewer) to do the same. As such, someone familiar with the letter/email baseline might develop a workflow for converting their verbose ideas to tweet-appropriate length:

1. Write a sentence or two. See that it’s a number of characters over the limit
2. Shorten any URLs (more on that later) to preserve space
3. Use common abbreviations
4. Go over entire text looking for places to re-word, perhaps with chat/SMS lingo
5. Start removing things like pronouns and the vowels from certain words
6. Remove punctuation that isn’t absolutely necessary
7. Begin to question whether the idea(s) might require multiple tweets

There’s more to it, such as @replies, but the above workflow is the gist. It’s interesting, anecdotally at least, that tweets and text messages diverge somewhat in linguistic usage, despite their similarity in imposed length restrictions. Whereas it’s common to use instant message-type lingo (lol, brb, stfu, etc.) in an SMS message, it’s at least somewhat less common on twitter. It’s also more accepted to go over the character limit in text messaging, while quite impractical on twitter.

Facebook

Facebook doesn’t formally impose stringent length limits like twitter. A savvy facebook user, however, knows that a long status update will get cut off at a certain length; and the cut off text is only viewable after clicking a “read more” link. This leads to a subtly different usage than twitter. Facebook users are more likely to use full words in full sentences.

The combination of “read more” links and quoting the first three or so words of comments on profile pages means that effective facebook users avoid “burying the lead.” Such users communicate in pithy, concise posts, with their thesis statement within the first few words.

Facebook users may sometimes forgo leading personal pronouns since their name is displayed before their status. This is a less-likely occurrence on twitter, where users are represented by short usernames rather than their actual names.

Blog

Blogs are similar to emails from a written language perspective. There are nuances, of course, but it’s long-form writing with the optional addition of hypertext elements, just like rich email.

Telephone (or face-to-face)

Talking on the phone obviously isn’t written language. However, I think it’s a great basic example of transliteracy. Brian, in the video, reads the necessary amount of orange juice aloud off the screen. This is him reading (decoding) written language and speaking (writing, encoding) the same message into oral language. This is a basic transliteracy that many of us possess that we often take for granted.

A Post-It Note

Similar to long-form written language. For a message longer than originally intended, someone writing a post-it message might employ chat lingo and abbreviations, or might start writing smaller near the end of the message.

Other Languages

URLs

URLs are a written language construct all their own. I learned what URLs looked like, how they worked, and the intricacies of their syntax and semantics from using them, rather than by any formal instruction. However, an internet user can gain a lot from being instructed in URLs.

For instance, Brian was 100% correct to shorten the URL for the recipe before posting it to twitter, as that’s common practice. On the other hand, he didn’t show how he used the full URL for the resource in facebook. It’s knowing usage rules like these that make URLs an important language literacy.

Hypertext

Written language is a special subset of visual language. Hypertext is where, on the web, written language and what we usually consider visual language intersect. Hypertext elements have default styles per user agent stylesheets in the browser, making them visual elements. They are also semantically- defined markup elements per their SGML syntax. So bold text or italic text or a link or a heading appear different from text not wrapped with any markup; the elements’ semantics precede their appearance.

A web user who doesn’t know how to identify the common appearance and function of hypertext elements would be at a great disadvantage. Often the appearance of form elements, for instance, are derived from similar UI elements from the base operating system’s toolkit. However, sites will often style or re-implement elements like buttons, so the** essence of button-like symbols is a useful** and transferable visual language skill.

Note that in the video, Gmail, twitter, facebook, and Wordpress all have similar, but at least somewhat-different, representations of buttons, text fields, text areas, rich text boxes, etc. I think it’s in the subtleties of hypertext visual language that it’s most practical to use the language model instead of the platforms/tools/media model.

Visual Language

Each site uses layout conventions involving columns, proportion, color, contrast, and other precepts of visual language. How they are similar and different is a teachable thing for those we might instruct. Knowing basic visual language of websites is a transferable skill.

Besides site layout, another interesting form of visual language are symbols, often used as icons. The Noun Project is a cool resource for exploring this aspect of visual language.

Conclusion

I’ve written a lot about a little, and have still managed to leave out a lot! The literacies at play when doing seemingly-simple things are often complex and varied.

What I wanted to demonstrate more than anything else is that the language model allows us to talk about all the same transliteracy things, but in a way that actually gets to the core literacies.

I think these language literacies allow us to work from a common set of terminology. They let us proceed quicker to developing more-universal and more useful curricula for instruction.

A point to ponder: Brian’s video, many (myself included) contend, is a wonderful example of transliteracy. It does not, however, focus in any way on the critical abilities normally associated with Information Literacy.