• I attended Future Insights Live in Las Vegas and live-tweeted the conference sessions I attended. (In short: this is a great conference you should attend, despite it being in Las Vegas. Yes, I said “despite”. I’m a shy introvert who’s allergic to cigarette smoke and that place was a new circle of hell for me.) 
• I built a new website called BorrowABlog.com. What’s that about? Well occasionally folks say they wish they had a blog to post to, but they only really have one or two things they occasionally want to write about. If that describes you, register, blog when you want, and link to your blog post from wherever.
• I built a website for close friends who lost their son to brain cancer, and are now raising money for cancer research. (I’d love to link to it, but the parents in question haven’t given it the thumbs-up yet.)
• I accepted a new position at work, moving from Interaction Designer back to Information Architect — with a lot of interaction design still in my future. I’m really excited to join my new team and stretch a bit more into the “UX generalist” role. It’s a little scary, too (what new job isn’t?) because I’ll be moving to a different division of the company and serving a different business group for the first time in thirteen years.
• I wrote two articles — like actual articles, not just tech writing — for aforementioned primary employer, which at some point will be published up on the main site. As an Engish major with heavy IT leanings (or a Software Engineer Poet, depending on the day) I’m really grateful to have the opportunity to communicate in words as well as designs.

In other words, life is full of change, but those changes are good.

Internet Explorer 8: OH HAI I see you want this last cell to be 110px wide. I can do that no problem but first Imma gonna shift the contents of the cell to align left, mmkay?

Me: What?!? No!

Internet Explorer 8: Yup.

Me: Okaaaaay, what if I add a class=”right”, will you put it back?

IE8: Nuh uh.

Me: Align right? tbody class=”right”?

IE8: LALALALA I CAN’T HEEEAR YOU….

Me: (searches web frantically….) OK, this makes NO sense, but this cell’s in a table with a width of 100%…. so if I set the width of the cell to 13% instead of 110 px…?

IE8: Hey, I see you want to make the width of this cell 13% so Imma gonna put this cell back to right alignment, mmkay?

Me: I hate you.

I’ve always seen that as a bit of a motto for my design work. As designers, it’s rare that we get handed a problem to solve that has a straightforward easy-to-implement solution. It’s all about the context of the problem, especially when we’re creating the context as we go. A thoroughly researched and implemented design requires capability strategy, iteration, research, iteration, design, iteration, testing, iteration, iteration, and iteration. You can try to cut off somewhere in the middle or skip a few steps, but you’ll usually come out of it with something that feels just a bit like you installed shelves with only some of the pieces that were supposed to be in the box. There’s nothing wrong with approaching complex problems with the mindset that the journey will be long, but the destination might be two blocks over from where you started.

Today, though, I’m thinking of rethinking the Zoo Story approach to this blog.

I’ve been going a long distance out of my way to design and develop a visually-attractive responsive theme for this blog, so I could come back the short distance of “provide evidence that you can produce a quality blog” correctly. I want to prove to myself that I could work on mobile-first content-first responsive design projects by making this a responsive-design (responsively-designed?) blog about design, development, and user experience.

I’ve hand-coded the theme(s) to my other blog since I moved to WordPress in 2004, and before that I hand-coded all the pages. I learned most of my CSS and all of my PHP developing for my now-sleeping comic. When I started, there was no good canned theme solution for comic presentation in WordPress. (There still isn’t. That’s a rant for another day and one that requires responsive images to be solved.)

The problems I ran into were threefold:

First, WordPress’s crack development team beat me to it. Their 2011 theme is already responsive. So to make my! very! own! responsive design theme, I had to cover my eyes and LALALALA a lot to pretend I hadn’t seen anything in their code. Even though it’s excellent, and it works for my site structure.

Second, the development of a responsive design layout takes a lot of work. It is an absolutely great experience from an educational standpoint, and one I plan to continue. It’s just not something I can produce fast enough to also blog on a regular basis, which was the point of having a blog.

Third, I’ve had a stubborn blind spot about using other peoples’ code for my website(s) since the beginning. I was “raised” in the world of apps producing truly crap code “for me” (see Microsoft Word, FrontPage, and even Dreamweaver to a certain extent). I struggle against using any code-generation system because my gut says it must be full of bloat. Why use WordPress’s image uploader when a simple <img src> declaration would be enough to meet my needs?

But the fact is that, for a responsive site with responsive images, they’ve got a damn good system going here.

It might be worth noting that in The Zoo Story the “right” solution involves forcing an unsuspecting stranger to knife you. So, y’know, there’s an argument to be made for staying local and not provoking others into violence.

Sometimes, you have to go a long way out of your way to come back a short distance correctly. But sometimes, sometimes you can walk two blocks and reach the same destination, without any fuss or heartache at all.

The big promise of Chrome is that browsing on the phone would shift to something that people do often instead of something only done when one has to.

“We can really take a leap forward on the mobile Web,” Chrome boss Sundar Pichai said in an interview. “Previously, it is something you would do once in a while. You would hesitate.”

Clearly, they are not reading Luke Wroblewski‘s twitter stream.

Avg smartphone user downloads .083 apps a day. Visits 24 different web sites a day.

Who are these supposed non-web-surfers and what are they afraid of?

I use this technique when I’m prototyping a multi-step form/application and I know what data I want to show on the page depending on whether I’m walking through scenario A, B, or C. It’s good in situations where you’re setting radio buttons on the previous page and just need to know which one was clicked. It’s lousy for situations where you don’t know what value your previous page might’ve sent. It’s best used when your “Review” and “Confirmation” pages are virtually identical except for one or two key pieces of data. There, it saves you time from building 3 review pages and 3 confirmation pages.

It is extremely breakable and probably shouldn’t be used in production code.

This uses forms submitted via GET so all the variables are in the URL.

First, on the page with the form, make sure the value you want to pass is in an input element in the form with a name (and the value) assigned to it. Input type=hidden is handy for this.

Second, make sure you’re submitting the form on the first page. Yes, this sounds obvious but when you’re prototyping sometimes folks take the quick way out and just code a button with a location.href Javascript on it, and that’s not a form submission.

Third, make sure that when you submit the form, the variable you want shows up as a name/value pair in the URL of the next page. That means the value is getting to where you’re going.

Now for the fun part. On the page receiving the value you need to do two things:

• Get the method out of the URL
• Tell the page to use it to do something

To get the method out of the URL, we do this:

function getMethod(){
var thisurl = window.location.href;
var locationOfValue = thisurl.search('TheValueYouAreHuntingFor');
if (locationOfValue = -1){
//write yourself an error condition handler in case your value's not there
} else {
//do the thing you want to do if you found it
}
}

(Please excuse WordPress’s built-in CodeMangler for the spacing…sigh)

So what’s that do exactly?

window.location.href grabs the href (URL) of the current window in string format so you can search it.

String.search(regex) tells you the position where a regular expression occurs in a string. If it’s not present, String.search() returns -1. So we take our string (thisurl) and search it for the value of the name/value pair we’re sending, and assign the result to a variable (locationOfValue). (Yes, you can definitely use shorter variables. This is a sanitized version of a function I’m using elsewhere. And it’s more readable this way.)

If locationOfValue is equal to -1 we didn’t find it. Either your value wasn’t passed correctly or you came into the page directly and the first page didn’t get the opportunity to pass anything. This is a good place to put a “if there’s no value here’s what I want you to display” clause.

If locationOfValue is NOT equal to -1 we found the value somewhere in the URL. Do whatever it was you were planning to do when you got it.

Obviously, once you have the tools to grab the location and parse it for a value or three, you can build more complex if/else if/else statements, but this is the simple version.

Now the final challenge is getting your page to call your function. Because we want to read in from the URL and use its results to modify the page, we want to throw a script block on the bottom of the page  that calls getMethod. Something like:

<script>
getMethod();
</script>

Write the page itself to be generic to whatever you want if it all crashes and burns spectacularly. (As they say on Mythbusters, failure is ALWAYS an option.) Then use the getMethod to read in your variables and modify your content accordingly.

I’ll try to build an example at some point soon.

*if you got the titular reference to the video game Catherine, w00t! Also, is that one creepy game or what?!

We have a set of design principles and heuristics at my primary employer, which I’m developing training for. I’m exploring concrete examples inside and outside of the web, since I’m the type that learns from those best.

Error handling: Make it easy to identify an error when it occurs.

I drive an 11-year-old 2001 Saturn SL 1, which I’ve owned since it was 12 miles old. That car and I know each other pretty well. (Her name is Fluffy.)

This morning, a new thing lit up on Fluffy’s dashboard.

Clearly a warning light, it was trying to tell me something, but I’d never seen it before. My first guess was “GO TO THE BEACH”, because it’s June and that’s where I want to be. My second guess was “oil is low” because oil burning is the biggest problem Fluffy has had in her later years, and thus it was fresh in my mind. But low oil hasn’t triggered a light before, so despite being this car’s expert user, all I really knew was what I didn’t know.

Fortunately, I keep Fluffy’s manual in the glove compartment. The manual describes all the obvious error messages and error conditions, what to do about them, and when to contact someone. It’s both unobtrusive in its home in the glove box, and accessible when I needed it, regardless of the error. (well, “passenger seat on fire” might have caused problems, but there’s no light for that anyway.)

I could have chosen to take out my iPhone, and Google the problem. But the book was easily accessible without power, without cell signal, and without searching a half-dozen websites for a solution. It fits perfectly in the lowest reaches of my glove compartment, where it doesn’t interfere with the napkins, pens, and (yes actually) gloves I’ve piled in there over the years. It was designed to be accessible when I need it and out of the way the rest of the time. It was easier for me to look up the light’s meaning than to drive away and worry, which is a triumph in designing against inertia.

(The light, by the way, is a warning that I’m low on engine coolant.)

Error handling design heuristics are tightly coupled with learnability heuristics. A novice user who learns where to look for help will eventually become an expert user that doesn’t use the manual for years, but might need to look up a random light on a sunny July morning. The language and icons need to be as understandable as possible for both the novice and the expert user. (Had I followed up on my first guess and added a quart of unnecessary oil, Fluffy would’ve been smoking for days!)

When we’re designing a process, we decide what the manual will look like. The manual can’t just be rainbows and puppies, regardless of how badly we want to give the impression that our sites will never fail. Everyone – even our expert users – will occasionally run into an event they weren’t expecting. It’s a task outside the happy path. The more obscure the problem, the better a chance we’re going to want to avoid building both the error notification and the follow-up steps altogether. That’s a temptation we should avoid.

Make sure that your messaging is findable and clear. If you can detect an error occurred, don’t just give a warning light, but also give instructions on what to do about it. Make choices on when to display that message immediately (“GET OUT YOUR CAR IS ON FIRE”) and when to put the error in the manual in the glove compartment. Make good conscious choices about all of the unhappy paths, and you’ll satisfy the people using your process even when things go slightly awry.

But while a <table> can have multiple <tbody> tags, they have to be stacked, they can’t be nested.

Good:
<table>
  <tbody>
    <tr>...</tr>
    <tr>...</tr>
  </tbody>
  <tbody>
    <tr>...</tr>
    <tr>...</tr>
  </tbody>
</table>

Bad:
<table>
  <tbody>
    <tr>...</tr>
    <tbody> <!-- ack! -->
      <tr>...</tr>
      <tr>...</tr>
    </tbody>
    <tr>...</tr>
  </tbody>
</table>

So what to do when someone designs a table that has multiple levels of expand and collapse and asks you to build it?

(A valid answer is “ask them if they really honestly truly need that much info at one time, because I mean c’mon really? There isn’t an information architecture solution better than that? Are they crazy?” but alas, sometimes that doesn’t cut it.)

If you knew that every time you needed to hide the subcategory’s rows you’d be hiding the same number of rows, you could write a function that accepted exactly that number of rows:

function hide3rows('ID1', 'ID2', 'ID3'){
  document.getElementById('ID1').style.display="none";
  document.getElementById('ID2').style.display="none";
  document.getElementById('ID3').style.display="none";
}

But I tell you as soon as you do that, some pest is going to come along and change the requirements to more rows or fewer rows, or sometimes six rows and sometimes eight. And you certainly don’t want to spend your time building a library of hide1row(), hide2rows(), etc. because you need that free time to follow around the person who wrote these requirements so you can keep asking them if they are in fact crazy.

This is where variadic functions come in. A variadic function is one that accepts a variable number of arguments. Generally, it does the same thing to all of the arguments, like add them together, or print them, or in our case figure out which elements they refer to and change their display attribute from visible to hidden. Different languages support variadic functions in different ways. JavaScript actually makes them pretty easy to use, by treating the arguments passed to the function like an array, so we can check the arguments/array length and iterate over its elements.

function hideThings() {
  for (var i = 0; i < arguments.length; i++) {
    document.getElementById(arguments[i]).style.display='none';
  }
}

Here’s our previous table modified to use this function.
Now we can call our hide function with as many or as few arguments as we need to hide. hideThings(‘mon’, ‘tue’, ‘wed’, ‘thu’, ‘fri’); is just as valid as hideThings(‘birthdays’); and we don’t need to clutter up our files with sixty five versions of the same function.

Let’s say you have a table, and you want to be able to toggle various rows on and off. So you write yourself a couple of simple Javascript functions to hide and show your stuff.

function hide(thingID){
document.getElementById(thingID).style.display = 'none';
}

function show(thingID){
document.getElementById(thingID).style.display = 'block';
}


Here’s the problem: display:block turns a table row into a block element — which is to say it compresses the whole table row into one big chunk and stuffs it into the space for your first table cell in that row.

If you do your research, you’ll quickly learn that the W3C says you’re supposed to use “display:table-row” for tables. But when you change your “show” function to use the preferred method, all the standards-compliant browsers start working, but IE 7 and the other annoying old IE browsers you’re forced to support just flat out drop the rows.

The secret? So obvious almost no one thinks of it until they’re told:

function show(thingID){
document.getElementById(thingID).style.display = '';
}


By setting the display to effectively “ain’t got one”, you tell the browser to display the row the way it would have if you hadn’t messed with it. Which results in what you were looking for:

To check the results in your browser(s) of choice, feel free to fiddle with this test page.

We’re all familiar by now with the security pattern where you set up 2-3 questions that “only you” will know the answer to (well, only you and people who know you really well, anyway) in addition to your username and password. It essentially sets up a two-password system. If you can’t answer the first password (your security question’s answer) you never get to the second password, thus securing it.

Or something.

I have a lot of problems with that security pattern, which I won’t get into here, because this post isn’t about the security, it’s about the stupidity. It’s security when you ask me to set up a double-password system. Since it’s critical information, it’s good design and good sense to ask me to review the information before I submit it, and print it for my records. One password is hard enough to remember, but this pattern essentially asks me to set up three.

It’s stupidity when you decide that your security policies need to be strong that when you ask me to review my information for accuracy, you obscure the answers to my questions.

And yet… that’s what we have here.

I’m willing to guess that the vast majority of people are not dumb enough to fill out a registration form for a medical billing website on the Jumbotron of their local stadium, or anywhere else that would allow a significant number of people to view the process. So why make that registration even harder by blocking the review of critical account-access-granting information? It’s security absurdity.