design – Boon Yew Chew

CSS Rite of Passage

Once again, I am getting my hands dirty with CSS. And I’m no expert, but having read through numerous articles from A List Apart, I’ve been fairly sensitive to how “designer-y” people think and react to CSS issues.

For one, I am currently working with rey who’s coding up the front-end for a site we’re building. And bad habit of hacking up layouts with inline styles has driven him up the wall. I’ve recently made the effort to migrate my styles into our stylesheets, but only when I was styling up a panel quite seriously (as opposed to just using HTML markup and existing styles).

Reusable CSS isn’t quite like reusable code

The gap that I had crossed was this idea that it’s okay to create a style that’s never going to get re-used.

For the longest time, I was using inline styles because it was quick and dirty, and for the most part, many styles were bespoke. I felt that only reusable styles should be put in a stylesheet. It’s one of those coder things where we like to build reusable components and keep them organized and use them in what we call an architecture. But I had to put that coder thinking aside for awhile, when it came to CSS.

The reason is because styling up a div one way doesn’t mean it looks right when it gets placed in another section of the page. The effect of one small change in one component can and will affect the feel of the other components. This is not just true in terms of the visual layout, but also in CSS – because there are cascading styles that will enforce itself upon any child components.

In an object-oriented programming paradigm, extending a class or object is often an act of empowering (decorating) that object based on elements inherited from its parents (a very bottom-up approach). But in CSS, it almost seems like the reverse when you don’t necessarily want to inherit from a parent element, unless you had a very intimate understanding of the way it was styled from the top-down.

Approaching a user model

Rey uses the term “semantic” a lot when he’s talking about CSS, referencing the act of naming a class based on the purpose of the component that was being styled. Again, this is partly contrary to the way system-thinking works, where you often name it based on a process (e.g. Data Access Object, FileFactory). This other gap I had crossed was about having a user model vs. a system model (which Norman talks about).

The issue here isn’t so much about whether I was naming a CSS class inappropriately, but about the way I viewed my styles with respect to the design of the site. In short, I would be thinking of the site the way a viewer would think about it – an about page, a contact list, a article side-quote, and so on.

Interestingly, CSS would ‘encourage’ me to think in terms of how different components looked and ‘felt’, nested in other components or on a different markup tag. For example, an article side-quote within a blog post vs. outside a blog post. Or a quote within a div or a span, or as a link. Or as a link within a span? Or as a list?

To a programmer, there’s a point where all these elements look like plain-old boxes. But to a designer, they’re like specialised tools that are meant to be used one way and not another. And I believe it’s because designers have a greater empathy for human beings – how we view, organize interact with and consume information.

What the books don’t tell you

I’ve been frustrated by many books on the subject of technical languages like PHP, CSS, and so on. Simply because many of these books completely ignore the fact that there’s an art of programming that can’t be communicated by instruction. It is this art that sets apart good designers and expert designers, good programmers and expert programmers. And this makes the difference between Ruby and Kohana and Django – not that one is particularly better than one another (trying to avoid flame bait here), but that the frameworks have been designed to appeal to a specific type of programming “art”.

Although there’s only “one” CSS (albeit with multiple revisions), there’s still many books on how to write CSS, and different authors will present their formulas based on their own design habits. Some are comfortable using CSS hacks, while some are strong advocates of reusable patterns, but this quote from Alan Cooper keeps coming back to me – that programming is craft and all software is bespoke.

So, there’s never going to be a one-size-fits-all solution. Ultimately, all programmers and designers have to lean on their craftsmanship in order to determine the right solution.

And I still haven’t found a book that helps me do that.

The reason why I feel this is frustrating is because many other crafts like painting or architecture or photography actually have books like that. About the art of the craft. Even some business books are dedicated to just that – the art of business. But almost 99% of the books out there on CSS, HTML, etc. are instructional, not inspirational.

Community as our last hope

Alas, one thing developers and designers do have is the technology itself, not as a solution itself, but as an enabler. I think that if we are going to reach a level of maturity in designing applications the “right” way, it will most likely be facilitated by community interaction, rather than plugins, frameworks or cut-and-paste code snippets.

The reason I say this is because every few months or so, a new browser version is released, a new styling standard has been established, or Microsoft continues to fail in delivering standards-based compliance and even makes it inconsistent with its previous browsers. And the only way we can survive this madness is if we work as a community.

But I am finding it difficult to meet (or fearful of meeting) people who might be willing to mentor me in CSS, of all things. And I assume experts think most web designers out there want cut-and-paste code. In fact, most articles I come across, with a few exceptions, are like that – catering for the cut-throat, deadline driven, plugin-frenzied, shock-effect designers and developers who want all of life’s problems handed on a silver platter.

There’s a lot to be said in the world of CSS, but as long as it’s not catering towards proper craftsmanship, I’ll be doing it the hard way with my bare hands and peering through the grapevines.

Practice Seminars at UCLIC

A List Apart recently published several articles about Web Education, spelling out the inherent difficulties for students to come out prepared for jobs in the web industry. While I can surely sympathize with that, myself being a practitioner for several years, I can also see how academic institutions struggle to reconcile pressure from the perspectives of research, teaching, and learning.

Contrast this to simply “learning on the job”, there’s a huge amount of tacit knowledge that you can acquire in a relatively short period of time, but only if the conditions are right. Surely, in industry, you do it every single day. But in class, it’s quite hard to teach that to students who haven’t quite grasped what it’s like to work on websites or other interactive systems on a daily basis.

The Interaction between Academia and Industry

The HCI program at UCL tries very hard to give students a good flavor of not just the academic and theoretical side of things, but the practical side as well. And because of its strong background in psychology and computer science, there may be a tendency to think they lack the kind of practicalities designers live by on a daily basis – but the people who run the program understand this and design does have its place in the program.

Certainly, in the academic community for HCI, design is seen as a black box – as though some kind of magic takes place whenever you design a website. But there’s a whole lot that goes on in the design process. And I’m glad to be given the opportunity to not just learn the skills that are required, but to see the history of both industry and academic trends evolving over the years, which tells you a lot about the different perspectives of the industry, which is probably why we have so many terms for practitioners (e.g. information architect, usability engineer, interface designer, etc.).

However, there has been significant contributions and conversations from both sides. Norman and Nielsen have a long history in the HCI community, whose works are often cited. On the other hand, you have folks like Alan Cooper and Steve Krug who are more known in industry.

Straight from the Horse’s Mouth

One of the things that UCLIC has done from the very beginning (back when it was more strongly associated with Human Factors and Ergonomics), was to have people from industry come in and give their perspectives of what the ‘real world’ is like. It’s an optional session and we don’t get slapped for not coming in, but it’s such a good way to hear so many different perspectives from people in industry.

We’ve had ergonomists who’ve done work on air traffic control centers, information architects who have done work on massive knowledge systems and even simple sites for financial institutions, interaction designers and user experience researchers from Microsoft and Google, all-rounders from small design companies like Clearleft, usability practitioners who do work on game testing…

It’s just amazing to see the spectrum and application of HCI in industry.

They come in different shapes and sizes

Although this sounds like a plug for the program that I’m attending, I really don’t know what other programs are like. I certainly considered a more design-focussed program like the ones offered at the University of the Arts, London or Savannah College of Art and Design. Even my alma matter, the University of Kansas, has begun offering modules in interaction design. But since my background is deeply technical, I went for something more HCI-based, and hoped that it would give me some exposure regarding design (it has).

I appreciated that the different terms (IA, UxD, UX researcher, etc.) meant something specific, even if one person seemed to be doing all of them. An information architect may be doing usability work, but not the other way around sometimes. Also, if you’re a designer, you’re not always equipped to do good qualitative research about user behavior, even though it may be extremely helpful to your work – while anthropologists do this every day. Engineers have insight to how technolgy works, but psychologists are needed to show how the mind works.

It’s during the practice seminars that I got the sense that I don’t have to box myself in a particular category, but that it’s just learning to use my skills and presenting them appropriately to whoever is consuming my services – and to embrace the constantly changing nature of the field.

Change Blindness and Short-term memory buffers

The duration of the flickers (not flickrs) that are used to demonstrate Change Blindness in the video posted in the link below only last a few miliseconds, but it’s a powerful visual tool to demonstrate just how easily it is to lose a reader or viewer’s attention.

This means that visual clutter can have a major effect on interface design, if not used in a purposeful way. More so because of the interactivity of sites – how is the site designed for the user’s goals? And issues like whether distraction is appropriate, and even branding and immersion can affect the overall experience for users.

link

Okay, so maybe pages aren’t designed with milisecond lapses of flashing gray blobs, but what if a sidebar that presents new information keeps getting missed? What about ad placements? A good place to start might be theory, so some Gestalt psychology might help:

Basically, these funny shapes just mean that people tend to group things together to form some kind of meaningful unit (the closure pattern looks like a circle, the proximity pattern makes the four blocks look like one unit, the continuity pattern makes the user want to fill in the blanks, and there’s some kind of vertical order in similarity vs. a vertical one). There are more laws, but the basic gist is – things need to make sense, and here we have visual representations that are more likely to be in one order than another.

In summary of these laws, the law of Pragnanz is sort of an overriding principle – one to rule them all.

Couple this with Change Blindness, and you might wonder how these patterns may help to either diffuse or illuminate particular elements. Visual clutter can be easily achieved by dumping a random collection of these patterns into one thick slush.

Add to that the tendency for users to leave your site within seconds of not finding what they want.

Caveat emptor. Design isn’t just a pretty thing.

The value of practice in design methodology

I’ve been exposing myself to more literature surrounding the way design works. In some ways I could call them design literature, but that’s much too broad. Or, I could say it’s about how designers work, but again – not all designers work the same way.

In a way, I’m searching for something about the way design works that’s more tacit – implicit, yet indispensable.

The reason is because working from a methodology or a process vs. coming up with a really good idea isn’t quite the same thing. Speaking to a classmate recently about the way design works, he found it hard to articulate why he designs the way he does. But we both agreed that there are bad designs, and bad designers, and things designers shouldn’t do. And it seems you could put that into a list of things to tick off, but it’s not quite like that.

I stumbled across an article by Michael Beirut on the Design Observer site about his design experience. The honesty in which he admits that design is not too far from a ‘magic spark’ is indeed revealing about the sort of work that goes behind the scenes.

He borrowed the analogy presented by Rob Austin and Lee Devin regarding theatre innovations – how the collaboration of stage crew and artists both handle minute by minute executions within a tightly controlled environment and time span in order to deliver an impact to the audience. The synergy, well-executed, is hardly a random exercise, but isn’t easy to put down in books or spreadsheets.

It’s easy for me to say a piece of software has to be built this way because it requires so-and-so features, but it’s another thing to create something from scratch, and say ‘this is going to work best for the user experience’.

This analogy is clearly based on my own background as a software engineer, and it’s causing me to be more sensitive to how designers learn and apply their “tricks of the trade”. In this sense, Buxton’s Sketching User Experiences book has been extremely insightful – but only if you truly appreciate that what the book is really offering is a peek into the mind of a designer, and not just another tool to whack together a pretty interface.

I’m not discounting the fact that building software relies on tacit and practical knowledge as well, but in the realm of design – this seems more magic than method – hence the question put forth in the ixda discussion board. While good software can most certainly be replicable, can good design be replicable too?

The more I read into it, the more I’m realizing that the answer lies in practice, and the understanding of it.

ACM’s Interactions magazine – Jan/Feb ’09 online

ACM publishes a fantastic journal on human-computer interaction. They’ve made the Jan/Feb ’09 edition publicly available online.

Interesting article titles I skimmed from the “Contents” page:

Social Network Sites and Society: Current Trends and Future Possibilities
90 Mobiles in 90 Days: A Celebration of Ideas for Mobile User Experience
The Washing Machine That Ate My Sari—Mistakes in Cross-Cultural Design
Design Versus Innovation: The Cranbrook / IIT Debate
Can “Wow” Be a Design Goal?
The Value of Visual Design in Software Development
What is Interaction? Are There Different Types?

Link source from experientia.

Beyond the browser: Usability in Mobile Interaction

I was at a UXCorner meeting last night, and it was organized by the kind folks at UXMedia. They had some interesting speakers come share their experiences about mobile user experience.

Mobile Design

One of the speakers, Anthony Ribot, gave some insightful bits about user experience from a mobile perspective. Maybe it’s the fact that I haven’t spent that much work on developing real-world mobile applications – but he’s right in saying it’s really competitive to be in this space.

“A single early failure = non-returning user”

… it said on one of his slides. That’s enough to put shivers down a lot of developer’s spines.

“data snacking”

was another term he mentioned, referring to a common european trend for users to log-in to check for new messages, posts, news, updates. “simple but repetitive”.

Another 2 tips for mobile developers/designers:

miniaturization != mobilization
design reward-based exploration (he mentions Opera Mini a lot here) – using convenient keys to allow for more direct access (hotkey-like, almost) to useful functionality (e.g. tree menu traversal)

The slides are here.

UX in London vs. US

I was chatting with Scott Weiss from Human Factors International, who was also one of the speakers, about his experience between the UK and US user experience industries – which one did he think was more “ahead of the game”. To my surprise, he seemed to think that UK has it together a little more than in the US. And I think he may have been referring to how tons of companies still aren’t very into this kind of stuff, not counting most of the major cities.

In fact, speaking to one of the folks from UXmedia, I didn’t realize that they’re not based in London, although they do a lot of work in the city. The Southampton-based agency is certainly getting more active in London, but I was humbly surprised to find so many small but great agencies doing this kind of stuff around the country.

2009 – a UX year?

This is one of three UX events that area already taking place the first month of the year. Can’t wait to see what’s in store for the rest!

Web Without Words – the danger of using wireframes

UX Magazine posted a short note about Web Without Words, a site that strips down popular websites like Yahoo.com and CNN.com to its wireframes. Everyone in the IxD community knows what wireframes are used for, and this approach is sort of the reverse-engineering attempt of that.

My question is – does anyone really rely on wireframing to determine the quality of information architecture? When I compare CNN and its wireframe, I get the sense that typography makes a lot of difference here, as well as text colour.

While wireframes are useful in providing structure to an initial layout, but is hardly ever used again to evaluate the quality/usefulness of a site unless there’s something really wrong with it.

In terms of human perception, color tends to dominate shape. And in this case, I feel that wireframes should only be represented in grayscale instead of having multiple colors to influence a design decision.

Take for example the following experiment, which I grabbed from this site:

The “Stroop Test” is a good example of how color dominates shape. The test works by taking a color term, such as “Blue,” and showing it printed in either blue or red ink:

Blue Blue

When asked to read the word, people take longer to read the word “Blue” in red ink than in blue ink. Color perception is fast and automatic.

This is a good example of how color can greatly influence a decision, and while wireframing seeks to inform how users evaluate priorities of information according to shape, the dominant influencer here is not shape but color.

Hence, I feel that you can probably treat wireframes in various levels:

1. layout areas

Have separate containers marked completely in grayscale, with specific parts in color if they are indeed going to be in that color (for the purpose of prioritizing that area).

2. layout areas with blocked out text

Blocked out text should be indicated with its intended colors, to communicate how specific colors are used for communication (blue for links? red for errors?).

3. layout areas with subtle design trims (with or without text)

This is based on another human perception observation that shape dominates texture. Design cues such as color gradients, drop shadows, tiled backgrounds, and the like – can be present in a wireframe to observe the balance of shape vs color vs texture.

Obviously you don’t want to overdo this. The whole purpose of color vs shape and shape vs texture is to use it as a design tool to help users navigate your content or to communicate your content effectively.

Design is a holistic process. Which is why I feel sometimes a part of it gets a lot of attention while others doesn’t. But that’s what design is all about – making something clear, specific, focussed, articulate. In this sense, it’s hard to realize that design elements that are unpronounced in a particular subject could be there for a very good reason.