Web Minimalism and Sucking at it

The original title to this post was “Everything New, Sucks”, but I thought I’d be nicer as to not take a complete 180 considering my last post. My New Year resolution to be less grumpy is looking shakier by the day.

Beyoncé style  = Whitney code?

I’m truly dismayed how some of the seemingly beautiful layouts are actually courtesy of HTML, CSS and JavaScript that look like the residue in a crack pipe. If the front page of your site is drafting more hobbled scripts than the average backend dashboard, then you’ve got problems son. It’s almost like no one really cares how it’s all put together as long as it looks good.

I know minimalism is the new in-thing in web design, almost to the point of being outright confusing or silly, but can we at least extend the sentiment to the scaffolding too? Or else, it kinda seems stupid, you know, hypocritical.

I also come across a lot of designers who quite loudly espouse their work is only meant for “modern” browsers and will actively block access from older browsers rather than encouraging them to upgrade or change them. The excuse is that older browsers “break” their carefully carved patchwork of copypasta.


If it makes your site unusable, go back and fix your work. It’s called pride in workmanship, you misanthropic troglodytes!

I know its fashionable to rag on the browser, but people aren’t going to change their browsers because your work doesn’t work on them. Deal with it.

Can I read the text? Can I see the images? Can I still “use” the site? Does your site have actual “content” that I can still consume? MOST websites will work in older browsers, even HTML 5 ones, once you stop giving it meaningless improvements, and “breaking” is acceptable as long as the content is still accessible. If you absolutely have to use the new functionality for something, then at least use Modernizr to make it usable on older browsers.

Which brings me to…

The HTML 5 Bug

Now slightly more infectious and deadly than H5N1. I’ve got nothing against it, but it seems it’s being abused by the same mindset that made the bad ol’ days of HTML 4 almost as unbearable. The fact that HTML 5 is new and hip doesn’t mean you stick every new tag in your design inappropriately and call it progress. The draft isn’t even finished yet and I’m already seeing designers making ridiculous uses of the footer, header and map tags.

I.E. I’ve  seen <map> still being used being used as a navigation bar instead of… and here’s a shock… the bloody <nav> tag. I’m sorry, is this 1999? Ah, but it’s OK, because the rest of the page is HTML 5.

<map> Is meant to be used for image maps and can designate clickable areas on an image for page interaction like photos identifying people.  I can accept that HTML 5 is here to stay and there’s nothing that can be done about it, but at least learn to use it properly!

I wouldn’t be this upset if it weren’t for the fact that the above abomination was the work of a “professional web designer”. Well, I’m not a professional web designer and even I know this. And if you still can’t get it, well then maybe you should be doing something else… like making soap.

Quit scripting your sites to death

There’s a post by Jim Dalrymple made last month that really puts into perspective how much rubbish is loaded asynchronously after the content itself has arrived. All the extra bloat just bogs down the browser until everything else arrives so even if the content is there, you can’t scroll to read it.

The real kicker is that the biggest load on that list was BGR and that’s a “minimal” layout. “The Biggest Letters in Tech”? Apparently.

And most of these aren’t even useful, but rubbish like Avalanche meant to drive traffic to content devoid of content. The rest are poorly engineered statistics widgets that have better use as browser stress tests than gathering user data on a production site. Or are ad widgets. These scripts are massively inefficient because they’re doing a lot of server-side work client-side in an effort to offload some of the burden on their own infastructure.

JavaScript isn’t C++ so quit treating it like so.

And what’s with designers and content managers not caring about what they include in the HTML sent to the visitor?

I checked the source on CNN.com and found the following buried in an HTML comment around line 200 :

	Last snapshot: 12/12/2011 11:30 AM
	IF auto generated include above stops working, uncomment the html below and manually update at hourly intervals:

<li class="pmNsStory">
    <div class="pmNsHeadline"><a href="http://www.cnn.com/2011/12/11/opinion/graham-debate-romney/index.html">Opinion: How Romney blew it</a></div>
    <div class="pmNsPopularity"><div class="pmNsPopImage" style="width: 98%"></div></div>
<li class="pmNsStory">
    <div class="pmNsHeadline"><a href="http://www.cnn.com/2011/12/11/sport/ryan-braun-drug/index.html">Spokesman: Braun will be 'exonerated'</a></div>
    <div class="pmNsPopularity"><div class="pmNsPopImage" style="width: 69%"></div></div>
<li class="pmNsStory">
    <div class="pmNsHeadline"><a href="http://www.cnn.com/2011/12/11/us/pennsylvania-paterno-hospital/index.html">Panama's ex-ruler Noriega returns home</a></div>
    <div class="pmNsPopularity"><div class="pmNsPopImage" style="width: 67%"></div></div>
<li class="pmNsStory">
    <div class="pmNsHeadline"><a href="http://www.cnn.com/2011/12/12/world/meast/syria-unrest/index.html">Ex-Penn State coach Paterno hospitalized</a></div>
    <div class="pmNsPopularity"><div class="pmNsPopImage" style="width: 59%"></div></div>

… Really?

And just for kicks, I went to MSNBC.com and discovered the actual “content” starts at line 716 :

And that's not even the real beginning.

Even after turning off word wrap, the first third of the source is nothing but inline JavaScript and CSS and so is a full half of the entire source.

Mind you, both are meant to be “minimal” designs far removed from their older, uglier, “less efficient”, versions.

I haven’t checked the mobile versions of these, but considering most people pay for their data plans by the MB, even if they’re half the size of their desktop counterparts, the designers of these and other bloated sites are doing a huge disservice to the very people who are paying their bills.

Any Browser is Dead. Long live bloat!

When did it become fashionable — respectable even — to design websites so poorly and with so much extra rubbish that it would be unusable? Forget people with special needs, I mean the average Joe with a decent computer, modern browser and a good internet connection would be in imminent danger of a face-full of glass shards or plastic splinters if he even dares to visit some of these sites.

The common excuse is that, well, you have to make sure that the site’s added features need a lot of capabilities that aren’t available on older browsers. I have news for you: The web has been around for longer than some of you designers have been alive and the core use is still the same. To consume content.

The vast majority of effort on any site should be on the backend. The core architecture, the security, the control panel, the security, the database, the security. Sort these out first and you will find yourself spending less time needing to make UI improvements. A good workflow will encourage a good UI.


Wikipedia Beta

Apparently Wikipedia is taking about a new initiative in usability. And it comes along with a fancy new theme as well.

The lines are a lot cleaner

The lines are a lot cleaner

Compare that with the current theme…

Boxy goodness

Boxy goodness

Of course I still have a problem with Wikipedia policy on exclusivity when it comes to what information is notable. This may be driven by their own technological limitations as we know there’s really no such thing as “unlimited”. I have a feeling this trend toward making knowledge spread like cocoa butter would similarly make it less intellectually nutritious.

Wikipedia may become what it despises the most… A collection of trivia.

New layout: Rockwell Accessible

This is the culmination of all of my accessibility experiments so far. I’ve combined elements from my previous experiements into one theme ready to be reused.

There are a few additional features like formatting for notifications and errors as well as text highlighting. There isn’t any additional scripting yet, but I hope to include some jQuery functionality soon.

Experimental accessibility theme

Experimental accessibility theme

This theme borrows elements from one of my older templates called “Rockwell” (select from the stylesheet menu).

How hard is web accessibility?

Pretty hard, apparently.

I’ve been trying to improve upon the Unified Template, an example of a static page that anyone can copy and reuse, as part of a continuing experiment. My primary goal is to get the main layout and stylesheet validated for XHTML 1.1 and accessibility (508 and WCAG Priority 3). There are two other variants of the theme, but I did those mostly for fun. You can tell just by looking at those that they weren’t meant to pass any accessibility guidelines at all.

The real trouble comes down to fixing little things that you didn’t even consider.

E.G. I needed description and keyword meta tags. I didn’t even think this was important, but apparently certain validators fail pages just on that. Also, the form inputs needed some dummy text inside because some “older browsers will not focus” on them if they’re empty. This is the first time I’ve heard of this.

Of course you can validate XHTML all you want, but no automated validation tool will ever be 100% certain the page is indeed accessible. That really comes down to someone actually using the page.

I followed all these pointers as best I could and came to one inevitable conclusion…
100% Validation is impossible if you want to be stylish. I know you should never say never, but I just can’t make the final layout work in these validators.

It will pass in some, fail in others or produce warnings (none were consistent). You just can’t win. What’s worse is that most of them claim to validate against the same standards.

Here’s a list of validators I used…

  • WAVE
  • OCAW (you only get a limited number of tests per month)
  • Truwex (this one was brutal!)
  • WDG
  • CSE
  • LinkScan (threw a warning due to a missing trailing slash after “.com”)
  • Dr. Watson (kept getting redirected. Needs work)
  • Accessibility Valet (this one gave me a “Probable pass”)
  • Color Contrast (still have warnings)
  • W3C for CSS (23 warnings!)
  • And, of course … W3C for XHTML

The validators are listed under various stages of completion and it would be easy to simply dump the page into the W3C validator for XHTML and Cynthia for accessibility and just walk away, but I know I’ll get a few angry emails regardless of any effort put into this.

I know for a fact, people will be wailing at the dropdown menues even if they don’t use JavaScript. After tweaking as much as I could, I think I’m done! Not that the layout is any more accessible, I mean I’m done trying to make it more accessible.

After some point it just gets ridiculous trying to make everyone happy.


Here’s the original for comparison. Apparently it was all but unusable for anyone with special needs.  I’m starting to think that, even though there are plenty of sites that could be vastly improved from the state they’re in, the zealous persuit of accessibility perfection in new designs is starting to impare otherwise able web designers.

Building (clean) dashboards for your web app

Update January 2nd 2012: This example was created in 2008. There’s now an updated version using jQuery UI Portlets.

This post was partly inspired by Francesco Sullo’s comment on the difficulties on finding a balance between functionality and accessibility, but the content is for whoever may find it useful.

I know its easy to whine and complain about a problem and not do anything about it, so I thought about being part of the solution. This can be applied to pretty much whatever you have in mind. I’m going to be as generic as possible so you can place whatever you want inside each of the content segments. From tables to lists to forms to images.

There are probably going to be a whole lot of bugs and such, but that’s because this whole thing was put together within the span of a couple of hours. With more time, I’m sure the bugs can be worked out. And since everyone’s going nuts for “widget” functionality, I’ll see what I can do.

Once again, this is only an example. Your situation will demand you take it apart piece-by-piece and put it back together. This is not meant to be a drop-in replacement for someone else’s project! I didn’t do any bug-testing at all on this. In fact, my coffee was still hot when I finished… So use it at your own risk!!


Believe it or not, the presentation of your content will be easy depending on how logical its arrangment is. That is to say, make the content logically partitioned ahead of time so you won’t need to work extra hard to present it later.

  • Title

  • Navigation

  • Content section

    • Segment1
    • Segment2
    • Segment3
    • Segment4
    • Segment5
  • Content footer

While you are building the page content, it’s ok to think about how you want it arranged. But don’t arrange it yet! Which means, don’t flood your page full of style elements and JavaScript. Leave that for the end, when your content is complete and you are ready to style the whole page.

In the content area, you can think of how you want to arrange your segments. In my case, I’m picturing a tab based page where each tab will have three columns. The content segments will go into blocks inside these columns. But I want to make the whole page accessible for people who may not have JavaScript enabled. The content should still be usable for anyone who browses the page.

The basic scaffolding I’m going to use.  As Phillip J. Fry would say, it looks like whale barf. But that’s because it hasn’t been styled yet.

The Styles

Tabs styles are are dime a dozen these days, but I’m going to use a technique similar to A List Apart Sliding Doors in that I will only use two images for the tabs and a couple more for the content background. I didn’t bother making them fancy or anything and it’s just a few minutes spent in Photoshop.

To apply the tabs, we need to give a few class names to the navigation list:

  <ul class="nav">
  <li class="active"><a href="">Home</a></li>
   <li><a href="">Articles</a></li>
   <li><a href="">Forums</a></li>
   <li class="na">
     <a href="">
     <img src="img/add_tab.png" alt="Add a tab" />

…And I’m reminded, once again, how much I dispise the WordPress text editor for typing code.

Notice that I changed the last “Add a tab” link into an image. If you do the same, just remember to give the image an “alt” value. Or else, people who have images disabled or are viewing in a browser that doesn’t have image capability will be left out.

Now let’s see what it looks like after we add the tabs.

Slightly better looking whale barf, I’d say. But there still aren’t any columns yet.

The Framework

One of the hard parts of building a dashboard is selecting your code libraries for rich UI functionality. There are literally thousands of code libraries that deal with this one way or another. But only a few that have gone into creating a complete set that you can use.

The two most popular are Prototype and jQuery. The least cumbersome and, as far as I can see, least intrusive of these is jQuery. Of course not everyone will agree, so flame away.

Instead of writing all of the widget functionality from scratch, I’ll be using the jQuery UI framework to build virtually all of it. When I’m done, I will only have two JS code files that I’ve written myself and only one of them will have true functionality in it. The other will just be a loader similar to the script.aculo.us loader in principle, but a hundred times simpler.

Specifically, I’ll be using the sortable plugin. Unfortunately, to use this plugin, we need to call 5 seperate code files including the jQuery main code file (this is one of the big reasons why I have an issue with JavaScript heavy sites).

To lessen the load a bit, I’m going to use a loader and a seperate JS file for the dashboard “stuff”. You’re probably thinking, “why would you add another JS file to this? Doesn’t that make the load size bigger?” Hold on, there’s a method to the madness.

Keep your head clean

I’m serious!

Even if you look at the source of this page, you’ll see a ton of junk in the <head> tag. That’s WordPress for ya! Granted, this is for all their dashboard stuff, but I think they could really use more streamlining.

For this example, I’m only putting one stylesheet and two JS files in the header. That’s all that you need and that’s all that’s acceptible. If your <head> tag is longer than 10 lines, then you’ve got more planning to do!

First, we include the jQuery base library and include a “Setup” JS file. This is what will call all subsequent JS files into the page. There’s no sense in downloading all those files if your browser cannot support it. If it does support jQuery, then it will download the rest. If not, the script ends there and you’re not downloading any more files.

function loadJS(p) {
     '<script type="text/javascript" src="'+p+'"></script>'


This code uses jQuery’s own “append” function to load the rest of the code files into the header. Notice the last line contains the “Dashboard” file.

The Code

The Dashboard JavaScript file contains everything we need to create our columns, convert all the “segments” into widget blocks and sort them into the columns.

Believe it or not, it’s actually much simpler to do it this way than to hard-code anything into your HTML file.

The first step is creating our columns…

$('.main').append('<div id="container1"></div>');
$('.main').append('<div id="container2"></div>');
$('.main').append('<div id="container3"></div>');
$('.main').append('<div style="clear:both;width:100%;"> </div>');

Again, we’re using the “append” function to load the columns to our page. The last <div> is there to clear our content. This is another reason why I prefer to keep this stuff in the code file and not clutter the HTML.

In our plain content page, you may notice a “title” and “description” class given to each of the titles and descriptions in each of the content segments. This is so jQuery has something to grab onto as we create our content blocks…

$('.main').find("div").each(function(i) {
  if(this.className == 'segment') {
    var t = '';
    var d = '';
    var c = '';

    $(this).find("*").each(function(j) {
      if(this.className == "title") {
        t += $(this).html();
    $(this).find("*").each(function(j) {
      if(this.className == "description") {
        d = $(this).html();
     c = $(this).html();
     var rcol = $(this).attr('rel');
     $('#container'+rcol).append(segBlock(t, d, c));

This code selects each and every “segment” in our content and loads the title, description and the content inside and then sends it over to the “segBlock” function. Once that’s done, there’s no reason to keep the segments on the page any more, so we use the jQuery “remove” function to get rid of them.

The “segBlock” function is basically a formatter. It can be anything you want. In my case, I wanted to create a block like arrangement. You can give it “widget” like functionality too by giving it a collapsible panel, an editable title and description and other stuff. I won’t go into the details of how to get all of that done. You can see how it’s done via the code file. All of these extra features can be added using jQuery.

Putting it all together

Finally, we can see what two codefiles, a stylesheet and a plain HTML file can do when you select the right tools for the job. There’s no need to jump through hoops to get any of this done. No reason why you can’t do this in a single evening or even a few hours.

The “Add a tab” link can be used to redirect the user to a control panel where new sections can be added. For this example, I haven’t used such a page, and instead used the “append” function again to add a new tab each time. In a real-life example, this should be done via a server-side personalization mechanism.

I’d recommend avoiding cookies for this purpose, since some people don’t enable them. Plus cookies are vulnerable to being hijacked. In fact, they are fare more susceptible than session hijacking. So that’s something to keep in mind while enabling personalization.

Also, the drag-n-drop functionality is completely optional. But as per my original description, I tried introducing some “widget” like behavior here and there.

Here’s a more realistic example. The images for the news widget were courtesy of the Tango Desktop Project.

Well, that’s all I have for you today…
Hopefully you carried something away that will help you put together a dashboard for your own app.