Dealing with Hidden Complexities
Mar. 14th, 2010 10:13 pmThe other day I had a conflict with a colleague. (I always tell people, when you gather together smart people who are really good at what they do and passionate about their work, there’s going to be conflicts. This is actually a good thing; I know I wouldn’t be nearly as good at what I do if it weren’t for being pushed out of my comfort zones.) The topic of the conflict wasn’t all that uncommon: she was advocating for great user interaction--which is what we are known for--and I was pushing back because I was worried about the aggressive development timeline which didn't leave any room for recreating complex interactions and designs. And I was frustrated because I didn’t have a way of quantifying my concerns in a meaningful way for her.
Ordinarily, my team is committed to taking the awesome interaction and graphic designs that our colleagues create and reproducing them exactly in browsers. About the only time we’ll usually push back is if there’s something the technologies simply can’t do, such as an issue with an older browser or something. Generally speaking, we can build just about any interaction or graphic design given to us, assuming we have enough time. And that was my worry here: not enough time.
Down the Rabbit Hole
In this case my main concern was hidden complexities. Even having done this sort of work for the better part of fifteen years, I’m still regularly caught off-guard by having something that sounds simple turn out to be a 40-hour job--40 hours that you didn’t plan for and have to come at the expense of something else.
HTML RIAs are particularly vulnerable to hidden complexities because the technologies involved (HTML, CSS, and JavaScript) are designed for fairly specific capabilities, and modern interaction and graphic design push those technologies to their limits. The more the technologies are pushed, the more brittle the solutions become and the more rabbit holes appear.
What’s worse, spotting these rabbit holes in advance is particularly hard to do, especially when approaching the problem from a design point of view. That’s what makes it so hard to quantify these issues in a meaningful way, especially when providing project estimates. It’s sort of a vicious cycle.
Uncovering the Complexities
One of the ways to mitigate the risk of hidden complexities is to be aware of the situations where they are most common. And really, there are only a few:
Customizing the Appearance of Form Fields Let’s face it, the default quality of the user interaction in standard HTML forms isn’t exactly stellar, and the problem has only grown worse as users have become used to more sophisticated interactions. And there’s not a graphic designer in the world who likes the default appearance of HTML form fields. They want rounded edges, and background gradients, and graphics inside of dropdowns and select boxes.
So you would expect use to have awesome control over the appearance of form fields using CSS, right? Wrong. CSS control over form fields is wonky at best. From browser to browser, from platform to platform, the same CSS rule will have varying effects on form fields. This is because of incomplete CSS specifications on the topic, which left CSS control of form fields up to the individual browser manufacturers, which in turn led to inconsistencies.
This is probably the largest minefield of rabbit holes, if I may mix my metaphors. Even something as simple as "we need to put graphics inside of our dropdowns" turns into a trip through browser hell.
Animation With a notable exception I cover below, HTML is not the right medium for animation. Anything more than simple stuff--fading or scaling elements, or simple motion--can not only be difficult to implement, debug, and maintain, but also prohibitively resource-intensive.
Interaction with the Local System Because of browser security limits, interacting with the local system is problematic at best. Simple drag-and-drop between a browser-based application and the desktop is an enormous undertaking.
If your project is moving through any of these minefields, focus on these areas as having potential hidden complexities.
Mitigating the Risks
So let’s say you know you’re wandering through a warren of potential rabbit holes. How can you avoid stepping in one and breaking your project’s proverbial ankle?
Use a Library JavaScript and CSS libraries are legion, and there are some really good ones out there. jQuery is my personal favorite, especially for dealing with custom form fields and random rabbit holes that don’t fall into the three main categories above. But I know people who swear by Prototype, or Dojo, or any of a number of other libraries. Just remember, libraries are abstractions, and as such they are subject to the Law of Leaky Abstractions. They can come with their own rabbit holes, so beware. A library can be as much of a hindrance as it can be a help.
Apply Tiered Browser Support A core concept in progressive enhancement, tiered browser support specifies different levels of support for specified groups or tiers of browsers. This differs from standard browser support methods, which generally specify a group of browsers and require exactly the same interaction and graphic design for all of them. Tiered browser support isolates older or less-functional browsers
Use Appropriate Technologies Sometimes HTML isn’t the best tool for the job. In those cases, consider using a tool better-suited to the needs at hand. Don’t be tied down to one set of technologies out of dogma, embrace your full toolbox.
Use New Technologies HTML, CSS, and JavaScript are constantly evolving, and are growing in response to our needs. CSS-3 specifies more rigorous (though still not 100% complete) control over form fields. HTML 5 has the canvas tag, which provides a useful API for 2-D animation. HTML 5 also specifies a native drag-and-drop interface that can even interact with the OS desktop and other applications. Of course, CSS-3 and HTML 5 support is spotty even in modern browsers, so be careful here as well. But chances are you only need one or two of the new capabilities. If you combine this with tiered browser support and a solid library, it can be enormously powerful.
For example, consider asynchronous interactions. Not too long ago we had to rely on hidden frames or other sleight-of-hand to create the illusion of asynchronous interactions. Today, we have AJAX interactions. One simple solution eliminated a huge headache and pretty much single handedly ushered in a new era in web-based user interfaces.
Work With Your Colleagues Depending on the sort of shop you work in, this is either a no-brainer or a laughable suggestion. I’ve worked in both kinds of places and I can tell you I certainly prefer the former over the latter. Either way it bears mentioning and is probably the most important tool for mitigating the risks of hidden complexities. In fact this is such an important tool that I won't work with people who aren't open to collaboration. I've tried it many times, and every single time it reduces project quality, results in angry clients, and irritates my blood pressure. Life is too short.
Climbing Back Out
Aside from the near-omniscience that comes from vast amounts of experience with a technology, I know of no way to really avoid having to deal with hidden complexities. Even with a thorough knowledge of the riskiest areas and a good set of mitigating tools in your toolbox, you are still going to fall down the occasional rabbit hole. What do you do then?
In my experience, it comes down to time management. You know, as a developer, when you’ve fallen down a hole and are spending too much time on something. (And here you have to be honest with yourself; sometimes it’s downright fun to tackle these problems, but your time is valuable and you need to spend it wisely.) When that happens on a project where you simply don't have the hours to spare, put a time limit on yourself. If significant progress isn’t forthcoming, it’s time to put the kibosh on it. Apply a new tool, work it out with the client or your colleagues, whatever, but do what it takes to pull yourself out of that hole.
Hidden complexities are a fact of our industry, but they don’t have to be fatal. With a good set of tools and an understanding of the risks and you can produce awesome user interfaces on an aggressive timeline.
Ordinarily, my team is committed to taking the awesome interaction and graphic designs that our colleagues create and reproducing them exactly in browsers. About the only time we’ll usually push back is if there’s something the technologies simply can’t do, such as an issue with an older browser or something. Generally speaking, we can build just about any interaction or graphic design given to us, assuming we have enough time. And that was my worry here: not enough time.
Down the Rabbit Hole
In this case my main concern was hidden complexities. Even having done this sort of work for the better part of fifteen years, I’m still regularly caught off-guard by having something that sounds simple turn out to be a 40-hour job--40 hours that you didn’t plan for and have to come at the expense of something else.
HTML RIAs are particularly vulnerable to hidden complexities because the technologies involved (HTML, CSS, and JavaScript) are designed for fairly specific capabilities, and modern interaction and graphic design push those technologies to their limits. The more the technologies are pushed, the more brittle the solutions become and the more rabbit holes appear.
What’s worse, spotting these rabbit holes in advance is particularly hard to do, especially when approaching the problem from a design point of view. That’s what makes it so hard to quantify these issues in a meaningful way, especially when providing project estimates. It’s sort of a vicious cycle.
Uncovering the Complexities
One of the ways to mitigate the risk of hidden complexities is to be aware of the situations where they are most common. And really, there are only a few:
Customizing the Appearance of Form Fields Let’s face it, the default quality of the user interaction in standard HTML forms isn’t exactly stellar, and the problem has only grown worse as users have become used to more sophisticated interactions. And there’s not a graphic designer in the world who likes the default appearance of HTML form fields. They want rounded edges, and background gradients, and graphics inside of dropdowns and select boxes.
So you would expect use to have awesome control over the appearance of form fields using CSS, right? Wrong. CSS control over form fields is wonky at best. From browser to browser, from platform to platform, the same CSS rule will have varying effects on form fields. This is because of incomplete CSS specifications on the topic, which left CSS control of form fields up to the individual browser manufacturers, which in turn led to inconsistencies.
This is probably the largest minefield of rabbit holes, if I may mix my metaphors. Even something as simple as "we need to put graphics inside of our dropdowns" turns into a trip through browser hell.
Animation With a notable exception I cover below, HTML is not the right medium for animation. Anything more than simple stuff--fading or scaling elements, or simple motion--can not only be difficult to implement, debug, and maintain, but also prohibitively resource-intensive.
Interaction with the Local System Because of browser security limits, interacting with the local system is problematic at best. Simple drag-and-drop between a browser-based application and the desktop is an enormous undertaking.
If your project is moving through any of these minefields, focus on these areas as having potential hidden complexities.
Mitigating the Risks
So let’s say you know you’re wandering through a warren of potential rabbit holes. How can you avoid stepping in one and breaking your project’s proverbial ankle?
Use a Library JavaScript and CSS libraries are legion, and there are some really good ones out there. jQuery is my personal favorite, especially for dealing with custom form fields and random rabbit holes that don’t fall into the three main categories above. But I know people who swear by Prototype, or Dojo, or any of a number of other libraries. Just remember, libraries are abstractions, and as such they are subject to the Law of Leaky Abstractions. They can come with their own rabbit holes, so beware. A library can be as much of a hindrance as it can be a help.
Apply Tiered Browser Support A core concept in progressive enhancement, tiered browser support specifies different levels of support for specified groups or tiers of browsers. This differs from standard browser support methods, which generally specify a group of browsers and require exactly the same interaction and graphic design for all of them. Tiered browser support isolates older or less-functional browsers
Use Appropriate Technologies Sometimes HTML isn’t the best tool for the job. In those cases, consider using a tool better-suited to the needs at hand. Don’t be tied down to one set of technologies out of dogma, embrace your full toolbox.
Use New Technologies HTML, CSS, and JavaScript are constantly evolving, and are growing in response to our needs. CSS-3 specifies more rigorous (though still not 100% complete) control over form fields. HTML 5 has the canvas tag, which provides a useful API for 2-D animation. HTML 5 also specifies a native drag-and-drop interface that can even interact with the OS desktop and other applications. Of course, CSS-3 and HTML 5 support is spotty even in modern browsers, so be careful here as well. But chances are you only need one or two of the new capabilities. If you combine this with tiered browser support and a solid library, it can be enormously powerful.
For example, consider asynchronous interactions. Not too long ago we had to rely on hidden frames or other sleight-of-hand to create the illusion of asynchronous interactions. Today, we have AJAX interactions. One simple solution eliminated a huge headache and pretty much single handedly ushered in a new era in web-based user interfaces.
Work With Your Colleagues Depending on the sort of shop you work in, this is either a no-brainer or a laughable suggestion. I’ve worked in both kinds of places and I can tell you I certainly prefer the former over the latter. Either way it bears mentioning and is probably the most important tool for mitigating the risks of hidden complexities. In fact this is such an important tool that I won't work with people who aren't open to collaboration. I've tried it many times, and every single time it reduces project quality, results in angry clients, and irritates my blood pressure. Life is too short.
Climbing Back Out
Aside from the near-omniscience that comes from vast amounts of experience with a technology, I know of no way to really avoid having to deal with hidden complexities. Even with a thorough knowledge of the riskiest areas and a good set of mitigating tools in your toolbox, you are still going to fall down the occasional rabbit hole. What do you do then?
In my experience, it comes down to time management. You know, as a developer, when you’ve fallen down a hole and are spending too much time on something. (And here you have to be honest with yourself; sometimes it’s downright fun to tackle these problems, but your time is valuable and you need to spend it wisely.) When that happens on a project where you simply don't have the hours to spare, put a time limit on yourself. If significant progress isn’t forthcoming, it’s time to put the kibosh on it. Apply a new tool, work it out with the client or your colleagues, whatever, but do what it takes to pull yourself out of that hole.
Hidden complexities are a fact of our industry, but they don’t have to be fatal. With a good set of tools and an understanding of the risks and you can produce awesome user interfaces on an aggressive timeline.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}