HIG is dead, long live HIG

At work on numerous occasions I’ve had debates with co-workers about what a good JavaScript library provides. Specifically we debate about “widgets”. Or rather I always chide about them đŸ™‚

Widgets are those things that the library creates for you like text box, button, drop-down and the infamous Calendar. And in doing so the library relieves you of some effort, and/or provide you some uniformity. That second bit is what my co-workers always bring to the table. Their point is that if you have 100 developers all building software for your website – you really want them building these widgets in the exact same way to help with maintenance/updating and general look and feel. And that’s a huge point. It’s critical. And on occasion they bring up companies like Apple to point to the fact that when you build software for the Mac you get these “widget” libraries built in, so that your app looks like a “Mac app”. If the core library gets updated to change the menu bars for example, your app receives the same treatment for free. No work on your part.

I always retort with “Ok but let’s not build every single widget out there for our library” or more often “we don’t need a library that has all that built in already.” And what I mean by that is, in my opinion, I’ve never seen websites in particular use the exact same widgets across multiple pages. Sure there are the few, staple widgets that in fact are the same across whole sites. But that list is small. No more than 10. Everything else is some variation of a staple. And if that’s the case it would be better to have a library that provides the absolute core set of widgets, but has huge extensibility built into it. Which is to say, a developer could start with the core widget, but extend it to add features for his/her own needs.

The bottom line is that there has to be uniformity across all the widgets (colors, button positions etc). Most often this is referred to as HIG (Human Interface Guidelines). However, it’s my opinion that HIG should not always be followed. Developers always start with HIG, but usually it falls away after a special new feature is requested and it doesn’t quite fit into whatever HIG they’ve adopted. What do you do? Do you change the intent of the new feature to match the HIG? Or do you side-step the HIG to get the new feature just right? And why would a JavaScript library be involved in that decision?

That last question is always where I end. Why would I use a library that caused me to choose one way or the other? If for example the library had “all the widgets I needed” with little extensibility, I’d be forced to look at reducing the feature possibly to fit into the capability of the library or because of the HIG. And is the HIG always the final answer? But if the library had all the extensibility I needed, is it more possible I could meet the HIG by developing a 1-off widget?

This is a tricky situation. There are a lot of ramifications in both directions. Generally speaking you’ll stay out of trouble with a library that “does it all”. And more often than most people would like to admit, you’ll encounter a circumstance where that library doesn’t do “this one thing”. I don’t claim to be right, but I stand by my style and philosophy. I usually lean on the side of “give the developers the room” instead of the other side “give the developers all they’ll need”.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: