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.

Browser Hell

While there are a variety of methods to view the web, the vast majority of people use only one of a few options: Internet Explorer, Firefox, Safari, Opera, and (johnny-come-lately but gaining market-share fast) Chrome. While it’s fantastic that each of these browsers are doing well enough to be considered major players, the problem is that they all have some pretty serious failings.

Internet Explorer LogoThe problems with IE are well documented, and frankly given that it’s Windows-only, I’m going to gloss over it here by simply saying: don’t use it unless you have to. Don’t support it unless you have to. Just. Don’t. This may change with the upcoming IE9, as there’s been a BIG push by developers to get Internet Explorer up to date and standards compliant. If even half the features and support Microsoft has promised actually make it into the final product, Internet Explorer may well be worth another look. In the meantime, take a pass.

Firefox LogoNext up is Firefox, a very popular open-source effort run by Mozilla. It’s free, it’s open source, it’s cross platform, there are lots of themes and profiles and extensions you can get for it to make the browser do more, all of which makes it the darling of the geek community. It isn’t without its faults, however: the same extensions that make Firefox useful often contribute to browser instability, but Firefox without extensions is… well, lackluster. Which is to say: a plain copy of Firefox is a perfectly serviceable browser, but lacks anything to set it apart from other major browsers. That coupled with one of the slower load times and a rather substantial resource footprint makes it a less than ideal solution for someone trying to run a lean, stable system.

Safari LogoWhile Safari doesn’t have anywhere near the usage rates of IE or Firefox, it’s still a major contender in the browser wars, for three reasons: 1) It’s the default browser on every Mac system, and has the highest browser rates on Macintosh computers; 2) It’s the default (and until Opera Mini managed to strongarm their way onto it, only) browser on the iPhone, iPod Touch, and iPad; and 3) It’s cross-platform and free. I’ve been a diehard Safari user since it came out, only occasionally switching to Firefox or Camino. However, as they’ve continued to add more features, the overall quality has (in my opinion) gone down. Reports of stability issues are prevalent on the Windows version, and I’ve been discovering massive resource consumption on my Mac. Since Safari 5, the memory footprint has grown significantly, causing repeated beachballs for the most basic browsing tasks because my laptop, with 2gb of ram, was out of memory. (My frustration with this is actually what has prompted this post.) I can only assume it’s a memory leak that slipped past them, because I cannot fathom how that sort of resource consumption would be acceptable for a shipping product.

Opera LogoOpera is a trooper from the old browser wars. While it has incredible market penetration on devices and globally, as a desktop web browser it didn’t really get a strong foothold in the U.S. They’ve continued to improve the browser over a number of years (the current version as of this writing is 10.60), and at this point boast one of the most standards compliant, fastest browsers on the market, with a ridiculous amount of features. Which is the problem: there are so many features and customizations and tie-in services like Opera Unite and Opera Link that it’s incredibly easy for the average user to get mired in unwanted complexity. Additionally, while they have support for widgets (which can even work as standalone applications from the desktop), I had trouble finding any plugins to fix some egregious oversights (despite all those features, Opera tends to only play with itself — service integration with third party options like Evernote or Delicious are non-existent). Some of the interface I found cumbersome, but I was willing to work through that (all browsers have some quirks, after all), but was off-put by the sheer number of browser themes that were for Windows only, leaving Mac users very few options to try and find a more suitable interface.

Chromo LogoThe last of the “big” browsers I wanted to mention was Google’s foray into the browser market, Google Chrome, and its development sibling Chromium. Despite being very new, Chrome has already gained a significant market share in terms of browser statistics, and not without reason: it’s fast; it breaks page viewing into separate processes to keep the entire browser from crashing when one page hits bad code; and, well, it’s made by Google. Frankly, while I appreciated some of the features of Chrome, I found it to be an incredibly slipshod application. The user interface was inconsistent and unclear on numerous occasions, with the preferences window being a morass of poorly explained buttons and hidden panels, and their handling of tabs becoming utterly useless once you get much over 20 tabs open. It’s easy to start cutting them some slack by saying “It’s a beta,” but let’s be realistic here. Google has made a point of hiring some of the smartest, most talented, capable people on the planet, and invested millions into the development and marketing of Google Chrome already. A product with that sort of backing feeling this slapdash is embarrassing for them and frustrating for the user. (Final gripe about this: despite their session-splitting to help prevent browser crashes, Chrome crashed on me when I tried to quit.)

So there you have it, the biggest, most popular browsers out there. The reality is that they all have MAJOR FLAWS, and there is major work that should be done on all of them. The bright side is that each of these browsers is under active development, so a lot of the work that needs to be done will be done. Until the problems are fixed, however, I’m inclined to look into one of the numerous smaller browser projects being developed out there, and hopefully find a diamond in the rough that blows the big boys out of the water.