Week 8 Reading

In this wrap up chapter, Krug asks us to think about our own experience: the sites you enjoy using. Is it because they're “flashy,” or because they have content you want or need?

'Never say never' is a quaint thing to hear with regards to site design. But the explanation is better. It's reassuring to be told that almost any design idea—no matter how appallingly bad—can be made usable in the right circumstances, with enough effort. The flipside (also good to be reminded) is that almost any good design idea can be made unusable, by messing up the details of the implementation.

Rule of thumb: stay professional and attractive, but avoid flashy and what you may think is engaging –you’ll just end up either annoying or confusing your client from their task at hand. The only engagement you want to provide in a site is enough tools to assist in the goal and gain just enough information as needed so as not to distract or intimidate.

I will miss these mantras. The ending was sort of anti-climactic, but I guess it should read more like an instruction manual than a narrative. And it was odd to read such a short book over such a long period of time, but I appreciated the slow digestion.

All the theories and rules of application in the world is only matched with the tools to implement them. 

How do you get into Juilliard? Practice, practice, practice…

Week 5 Reading

Chapter 8 stresses that there is no substitute for site testing in the development stage, due to the infinitesimal attributes of users idiosyncratic behavior when using the internet. (Or in general, as I will explain below.) Chapter 9 follows suit and explains how to test a site cheaply, timely, and with few people. 

The odd thing in reading this chapter, it reminds me of why I am "a design person" and not a developer. And yet, ironically, I enjoy testing and troubleshooting logistics and functionality of websites (and other things, I'm a tinkerer too) way more than I do designing them. But this isn't about me. It proves Krug's point about testing via different sets of eyes and brains independently: one set of skills may overlook one aspect of a problem, while being able to identify and maybe even solve another. And these skills are not always obvious.

One guy might be "a design person" whose primary approach is visual, and conceptual, but that doesn't mean s/he designs a good site in the conception phase. It might be pretty, and yet basic and clunky. On the other hand, that person might be a problem solver, a tinkerer, seeing overlooked details of a set of problems, and not make the same assumptions or oversights during testing of a site as a developer might make, based off of his or her habits of "common sense" and lofty experience. So put variously-skilled persons in the test pilots chair and use their individual, perhaps surprising conclusions to gain multiple perspectives and insights. 

Same reason to get a developer to tell you what s/he thinks of your pretty website...

3 Sites related to reading:


1. Daniel Smith
Seems like we should come up with examples of sites that need, or could have benefited from user testing. (As one would denote that any good site surely was already...) So I'm still picking on Daniel Smith: Aside from what Matt and I have already pointed out being areas that need help, 2 things I learned yesterday which sealed the deal were, 1) I found out they had a blog, which has no links to or from their main site. It even looks different, in terms of fonts, logos, and header and footer. Very weird. 2) Matt discovered, while we were prodding in the code for font colors, just how much of it there was. Even I, with my feeble memory of HTML 101, could see what he was talking about. For example, you could click on a large ad image, and it would be composed of 9 frames sets. Huge globs of redundant code, probably due to them sticking with their original site skeleton, which most likely employed the use of a basic site builder with templates and place holders and....ask Matt. They just kept adding to it, rather then overwriting with better code.


2. Cafe Intl.
Pardon the geekage, but this feels like a robot trying to woo me. (Older model Cylon with a Flash fetish?) Okay, if the reference isn't understood, open it. Let it try and make love to you. Then, run. Run like hell. What do they sell?


3. My (poor old) Website
I'm tired of picking on everybody else.
2 blind dogs could tell you, after testing my site for about 45 seconds, that it's old, it uses just enough flash (header) that makes it not fully show (in entirety) on smartphones and old browsers. The back buttons are in all different places (if at all), and the slide shows are actually different-sized single documents that scroll sideways. There's no About page. There's no resume. No bio. Check the copy-write. (2006, as I never updated it even when I made changes to the site. I seriously thought that meant you could see how long it's been up, and therefore means experience and safegaurding against early material/copy-write infringement!) It was a long time ago...

Week 2 Reading

Okay, re-reading the syllabus…I’m going to give a response rather than a summary, as I did last week (in which 200 words was just inconceivable) –make it comprehensive and personal rather than regurgitative....

As guiding principles go (Chapters 1-5), I think Krug is spot-on. Our reading for this week summed up:

·      CHP. 3: Everything rests at a glance.

·      CHP. 4: “3 mindless, unambiguous clicks = 1 click that requires thought.”

·      CHP. 5: Clearcut the words like you should the content.

While I read I am reminded: as a designer, my two major weaknesses are a) prioritization and b) brevity. The former causes the latter. Choosing what to keep and what to throw away, when it is your own handmade material, is like choosing which child to drown in the bathtub. (you choose the scenario) But ultimately, it has to be done. Often, if it’s similar content, like multiple files of 1 kind of my work, I line up the ones that display the best work, most versatile, and wipe the rest. Then, as Krug says (“Get rid of half what’s left.”), I cut it down some more. This I do mostly arbitrarily, as again, I’m terrible at making these choices. They’re my babies.

But when it comes to prioritization in hierarchy, I feel intuitive enough to do this well. Once the stacking is in place, it’s a matter of managing visual cues, (e.g., “The more importantsomething is, the more prominent it is…”) maintaining a consistent and logical design, and editing while you go. As hard (yet swift in many cases) as it is, editing can be the most cathartic part of the process –when you realize and actualize simplicity in its most efficient form, you are left with elegance. And yet elegance –similar to how the trimmed characteristics of the shape of a jet can determine how maneuverable and thus powerful it can be– can make design more stunning, and functionally more effective. 

What I find most intriguing with this book so far, aside from its succinctness, is that it’s common sense that we perceive, but tend to forget to repeat to ourselves. It’s powerful information laid out in the most simple of terms, like a Daniel Pink or Malcom Gladwell book.

Week 1 Reading

Chapter 1 touches on logistical theory (“Why?”) and explores the question, “what makes good usability –and is thus good for both the user (them) and the website creator/author (us)?" 

The goal, he says, is to minimize cognitive workload so that a user goal may be easily achieved. Workload can refer to any element on a page that requires thought: the worse being ambiguity, arbitrary words or images or placement, obscure wordage, etc.

Minimizing space (vs. risking over-minimalism) requires a balanced approach: a logic between the dictum that ‘the competition is one click away,’ (client leaves) and the fact that many-a-user will doubt their own intuition and persistently toil (client stays).

“If you can’t make a page self-evident, you at least need to make it self-explanatory.“ Ultimately, what this means is, eliminating question marks (e.g., 5 W’s attributed to potential site) should be the overarching practice. i.e., “Brevity is the soul of wit” but don’t outwit your viewer...or yourself.

This is theory.

Chapter 2 focuses on practice: actual use and design application. (“How?”)

Krug reminds us we have to keep in mind that people tend to scan or glance, rather than absorb. It’s quicker, easier, and taking in an entire site is unnecessary in terms of getting to the goal/s. People are also obstinate and habitual. Often we do things the hard way, because we don’t take the time to figure out how things work, or “get it.” This irony lends itself to a dangerous (for us and them) duality of sticking around on a non-intuitive site, and yet getting frustrated by having to do so.

Best to make sure, by designing simply and unassuming of the intuition or savvy of the client, they can easily “get it.” If this is achieved, they get what they were looking for and got what you had to offer. They’ll explore your site with more confidence and thus afford more time and attention, and chances are better they’ll return.

This is (good) practice.