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.