Category Archives: Projects

The cost of our choices

Naga IT Services
Filed under: Industry, Process, Projects

Every choice we make as designers and developers comes with pros and cons. There’s always a cost that somebody pays, and I’m worried that some of the choices we make bring benefits to ourselves at the cost of our users.

Web Standards

Today seems like a great day to write this rant since it’s Blue Beanie Day, a celebration / reminder of web standards, and making the web open and accessible to all. It shouldn’t matter what device, network, or disabilities a user has. I completely stand by the idea that:

Progressive enhancement and accessible, semantic markup aren’t optional extras. They’re the foundation of a web that works for all people.

That means using Progressive Enhancement to add things in layers:

  • semantic HTML for our content;
  • CSS for our presentation;
  • JavaScript for our behaviour.

Visual Composer

I have recently refactored a site that was using the very popular Visual Composer plugin for WordPress. I believe that VC has several design decisions that provide convenience for the author, but at a great cost to the user.

First of all, it mixes content with presentation. The drag and drop interface allows you to apply presentational changes to the page, rather than apply them in the CSS.

WordPress’s Edit interface is for editing the content, and it does this job very well. For changing the presentation, there are Themes and Theme options, and these sit in a separate part of the interface. Higher-level presentation choices are possible, such as choosing a Template for the Page. These granular choices don’t belong in a content-editing interface, though.

Second, it uses blobs not chunks (see Karen McGrane’s excellent Adapting Ourselves to Adaptive Content for more on this): it treats the whole page as one entity, where we would should be treating the page as small pieces of content that we pull together in our templates. Here are a few problems with using blobs not chunks.

  • It’s harder to be consistent, because you have to make changes on every page, rather than in one place (the stylesheet).
  • You can’t use pieces as modules, so you can’t reuse them across pages.
  • VC produces not-so-great code: inline styles (rather than adding styles to a shared external stylesheet) and verbose, non-semantic, HTML.

Who pays the highest cost?

Every decision we make has a cost for someone: ourselves or our users. I believe that we should be more worried about our users, and their convenience, than our own.

Visual Composer, for example, provides convenience and flexibility for the content authors, but comes at a high cost for the user. Pages are heavier in weight, which means they load more slowly, and cost more data (and money!) to view. Making a lean and mean HTML, CSS, and JS Theme, and allowing only HTML inputs via the WordPress Dashboard results in a leaner, better, site that relying on VC or other WYSIWYG editors.

Opera mini and repaints

Naga IT Services
Filed under: Process, Projects

As part of a project, and using fufu as a sort of base, I got bitten by a particular bug: Opera Mini and repaints.

Opera Mini is awesome and has surprisingly good support for a lot of things (except, strangely, border-radius). Since it supports CSS3 selectors, and doesn’t support client-side JS, I decided to use :target for a bit of accordion-like User Interface.

I used a list-accordion class with a cunning combination of IDs and nested things, like this:

<ul class="list-plain list-accordion">
  <li id="list-item-1">
    <a href="#list-item-1" class="list-accordion-header">Accordion item header the first</a>
    <p class="list-accordion-item">Accordion item header the first</p>
  <li id="list-item-2">
    <a href="#list-item-2" class="list-accordion-header">Accordion item header the second</a>
    <p class="list-accordion-item">Accordion item the second</p>

Here’s an example of the list accordion in action, and here’s the (Sass-flavoured) CSS for it. Accordion items that are not the subject of a :target are hidden. That means that the one that is the subject of a target is shown (because the display: none isn’t being applied). Yes, it’s a bit odd.

Opera Mini Fights Back

This was working great, except on Opera Mini. After some poking and prodding, I remembered that I should just search and see who else has had this problem.

I found Zach Leatherman’s issue on Scott Jehl’s (currently quite quiet Device Bugs repo): Opera Mini doesn’t repaint :target CSS rules after page load #44. His suggested fix is to add an empty onclick, forcing a server request, and therefore a page load. It didn’t quite make sense to do this for these tiny accordions, so I searched a bit more.

I found another post, Nav toggle via CSS :target which seemed a bit better, and worked, but it felt like a bit of a hack.

In the end, I (slightly unhappily) settled on sniffing for Opera Mini (which Opera do in fact recommend), and over-riding the :target styles that worked for most other browsers.

I have learned a lot about about compromises. And that coffee and willpower can keep me coding even when I’m kind of ill!

jQuery vs JavaScript

Naga IT Services
Filed under: Projects, Workshops

At the recent CTFEDs workshop, I gave a lightning talk about jQuery vs JavaScript. You can view the slides on speakerdeck, or read a bit more detail here. I’ve also gathered some links on the topic under the tag ctfeds20150822 on my pinboard bookmarks.

I’m not picking on jQuery. I’m just choosing to talk about it because it’s so popular. These things can apply to libraries is general.

The TL;DR is: Think about it. Carefully. What’s the cost (of using jQuery, or the library of your choice)? The one thing I’d like people to do is not to use jQuery by default, but make it a conscious decision.

A good question to ask yourself is: Who does this help? Me or my users?

Good things about jQuery

  • It makes complex things simple(r). For example: ajax. That means it can be faster to write than regular JavaScript.
  • It’s well maintained and well tested. It has a big team working on it.
  • It helps you avoid bugs, even in modern browsers. Although that’s less of an issue these days.
  • It’s on a lot of Content Delivery Networks, so the file will be faster to download, or the user may already have it cached in their browser. The various versions of jQuery make this slightly less likely, though.

Bad things about jQuery

  • Parse and execution time can be slow. This one is important. Since the file is large, the time it takes a browser to read and execute the jQuery code can be slow, especially on low-powered devices. Older jQuery versions and plugins make this worse.
  • It adds a dependency to your set up. Now you (and future you, and other people working on the project) have to know about it and use it.
  • It can be overkill if you’re not using all of it, or if it’s something you could write quickly. These days jQuery lets you do modular builds (just pick the bits you need), which is great.
  • It can be painful to upgrade. You might need to rewrite sections of your code.
  • Like any library, it’s solving a particular set of problems, and these might not be the same as yours.

What are the alternatives?

Some really useful links:

And Now for Something Completely Different

Another important thing to think about is Cutting the Mustard: thinking about whether or not you send JavaScript to all your users. The team at BBC news decided to serve all users the basic (fast!) HTML and CSS, but only to send the JavaScript-enhanced, bells and whistles, version to browsers that they could say where “modern enough.” Here’s the test they use:

if('querySelector' in document &&
'localStorage' in window &&
'addEventListener' in window) {
	// load fancy js stuff

Think about using less JavaScript, and any that you do use: optimise the hell out of it.

CTFEDs workshop for Open Design Cape Town

Naga IT Services
Filed under: Projects, Workshops

This weekend just gone, two of the organisers of the CTFEDs meetup group (myself and Justin Slack of New Media Labs) ran a Future Friendly-themed workshop as part of the Open Design festival.

We wrote up the principles that we’d be following and a fairly extensive checklist of TODOs for workshop attendees to have a look through. We had a couple of sticky note activities to do during the day (yes, I use sticky notes for everything!) and Justin and I gave a lightning talk each (I talked about jQuery vs JavaScript (which I will do a short write up of soon) and Justin talked about Iconfonts vs SVG)..

One of my favourite things about the workshop was that we had a wide range of experience levels: from people writing their first lines of HTML and CSS to people tweaking performance metrics on their clients’ sites. It was awesome!

What went well

We gathered some feedback from the students about the workshop: the things that cropped up the most were that people enjoyed the lightning talks (yay!) and they were looking forward to the next one.

This was the first workshop event we’ve run: we usually just have presentations. I really enjoyed it, and I hope that we can run another one.

What didn’t go so well

The checklist could have been presented a bit better. We printed out the whole checklist on one piece of paper, and I think it was a bit overwhelming. The idea was to pick a few that piqued your interest and just look at those, but that wasn’t clear.

What we could change

If we run this workshop, or one similar to it, again, I think we’ll print each section of the checklist out separately: have just a handful of items on each page. It might also be interesting to have a limited number of cards: you take a page, do one thing, then put the page back for someone else to pick up.

I really dig stickers. We use them at RailsBridge as tiny Achievement Unlocked celebratory things, and I think I’ll bring them along next time. If you finish one of the cards (a print out of one small piece of the giant checklist) you get a sticker.