Mood Driven Development

Chris over at CSS Tricks, telling it like it is:

But what is highly prized in our industry is productivity, in whatever form it takes.

“Hey, I refactored some of our mixins to be more efficient and made sure they are used properly site-wide.”

“Good morning, I looked over a lot of the copy around the site and have some ideas on what we can change to make it more clear and cohesive.”

“This afternoon I closed out a couple of long-standing bugs that have been bothering me.”

Any place I’ve ever worked, any of these things would have been applauded. Especially if they relate to the current team/project at hand. That’s what productivity is.

The danger is that you fight against urges to work on something different. You feel like you should be working on converting some layouts, and you feel guilty for tweaking some color palettes. You’re kind of into cleaning your inbox out right now, but feel like you are being lazy for not getting the JavaScript scaffolded out for that new thing. You’re finding a funny image to respond to a playful customer with, but you’re a little mad at yourself for not updating those docs.

That’s too bad, since you are being productive anyway. You’re following your mood.

Chris Coyier, Mood Driven Development

Link: Why Learning to Code is So Damn Hard

Why Learning to Code is So Damn Hard over at Viking Code School. Nice article discussing the different phases of learning to code, and how to deal with each.

I usually wipe out somewhere in phase 2 or rarely phase 3, which is why I like to say I can read/figure out a fair number of languages, but not write them. Next time I take a stab at learning to program, I’ll try to bear this info in mind.

User Experience(d)

Last week, I was at a family reunion filled with fabulous, intelligent, talented people whom I’m glad to call family. One thing I noticed: as people pulled out laptops and iPads and smartphones, or discussed some of the current technological hurdles they’re facing in their day to day lives, there was still a lot of frustration and implied distrust of the hardware or software being used. It really hammered home to me that there’s still a long distance left between usable and intuitive. They were adding complexity and hurdles that didn’t need to be there, because they were used to a previous mental model that was more complex.

I work with software and computers every day, and have for years. Even a lot of my hobbies end up taking place on computers. It’s easy to take for granted the human-computer interactions I do on a daily basis, because I do them regularly, and generally even if it’s a new piece of software or hardware, it still behaves similarly enough to other software that I can get the hang of it pretty quickly. The thing is, even with the pervasiveness of technology these days, I am an anomaly, not the norm. Many people — highly skilled, capable people — simply don’t have that background and context for understanding, nor the time or interest to gain it. As far as I see it, this is a lot of what user experience design is all about: finding that line between simplicity and complexity, where people have enough detail to understand what is happening (at least a high level), but is still simple enough that they don’t have to invest cognitive energy to grasp how to use it.

Aiming for clarity is hard on its own, but what I was noticing is that it faces an additional hurdle: overcoming the complexities or mental models of previous designs. It seemed like a big problem in particular for older generations was that they’d fallen out of sync with what experiences were designed to be now, and were burdened with the expectation of complexity or failure from experiences in the past. It’s easy to say “oh, well they just need to retrain themselves,” but that implies they have the cognitive energy, time, and interest to do so.

That’s not to say we shouldn’t keep working on improving the user experience, but it is something to bear in mind when developing software or hardware. I have a few ideas on how to accommodate this, some of which may be more palatable than others:

  • Evolving UX: Going with more iterative, minor changes rather than a large shift. This already happens some (depending on the software), and sometimes it’s unavoidable that multiple changes will need to go in at once.
  • Documentation: Creating effective documentation can be invaluable for keeping older users up to speed on what’s happening. Three things I’d want to make sure to consider: keeping docs up to date to the current version of the software; keeping legacy docs for older versions; mapping the old user experience to the new user experience in change logs and within the docs themselves.
  • Usability Studies of Existing Users: Doing usability research has definitely become more prevalent, which is a good thing, but I feel like tends to focus on how to attract new users, and doesn’t really give a lot of attention to existing users (I suspect at least partially under the presumption that once a user is committed to your product, they are less likely to take the additional effort to switch). It would be really interesting to make sure to include existing long-time users when doing usability studies. If considering retention of existing users isn’t on your radar, maybe you should reconsider.

Obviously, it’s impossible to please all of the people, and maybe more of this is already in progress than I’m aware of, but it does feel like we’ve got a distance left to go on learning to effectively clear out the cobwebs of past experiences.

More on Cognitive Load and Decision Making

8 Things You Don’t Know Are Affecting Your Decisions Every Day: As a follow-up to the article I posted yesterday, here’s another article about cognitive load, and how we end up making worse decisions over time, over at Buffer. The more choices the user has to make, the more likely they’ll simply choose the default/easy/safe (but not necessarily correct) choice as time progresses. (Hat tip to Felicia Day for linking to it.)

Depleting Cognitive Resources

Your App Makes Me Fat: a neat essay over at Serious Pony discussing research into cognitive load and why it makes sense to avoid branding noise in your user experience.

But if it’s “content” designed solely to suck people in (“7 ways to be OMG awesome!!”) for the chance to “convert”, we’re hurting people. If we’re pumping out “content” because frequency, we’re hurting people.

Lions, Dashboards, and Calculators (Oh My!)

This summer, Apple is planning to release their next iteration of Mac OS X, 10.7 (codenamed “Lion”). From the looks of things, their primary focus this time around is interface improvements to make the user experience more fluid and effective. In general, I’m liking what I’ve been seeing, though looking at the system requirements that have been coming out suggests that I’ll be on the hairy edge of being able to run it at all (a Core 2 Duo or higher is required, of which I’m running the first Core 2 Duo Macbook Pro they offered), so I’m not sure how much real benefit I’ll be seeing in the near future. That said, one of the design changes they’re making seems like a horrible idea: they’re moving the Dashboard into its own space, rather than continuing to work as an overlay over whatever screen you’re on.

Given that the dashboard is for quick-reach, simple widgets, this seems remarkably backwards, and more like something you’d do to get people to not use it so it can be phased out of a later release. Think about it for a second: widgets are meant to show information at a glance, i.e. without significantly interfering or distracting the user from their task at hand. While several widgets seem like simply a bad idea to be shoved into their own space, there are a few that will have their usefulness significantly reduced, most notably the calculator.

To be clear, the dashboard calculator is not especially robust. It has no history or “tape”, no special functions, just your basic arithmetic. About the extent of its bells and whistles is that it accepts numeric input instead of being forced to use the buttons. But you know what? That’s the point. It’s a simple calculator for when you want to run some numbers really quickly, without interfering with the rest of your workflow. More often than not, these numbers will be pulled off a website or email, or chat. You aren’t particularly invested in running the numbers, you just want to check them really quickly. This, specifically, is the value of the dashboard calculator: just pull up the dashboard, and you can punch in the numbers, which are still visible, into the calculator for a quick total, without going through the process of loading up a separate application. I don’t want to have to constantly page back and forth between two screens just to run a quick number check. At that point, why not just use the actual Calculator app?

I doubt I’ll ever know, but I would love to find who made this particular design decision and ask them what on earth they were thinking.