When I worked at a large company, one of the things that stood out to me was the level of specialization everyone had. All my previous jobs were at smaller organizations where everyone had to know broader sets of skills often outside what might be considered their individual job description. A larger company allows for individuals to hone in on a specific area and become true "experts," and from that point of view, as any project moves through its development cycle, you'd ideally be handing it from expert to expert.
This approach has its pros and cons. It allows individuals to devote their time, energy, and learning to a very specific area to presumably become better at it, but it also means that they may not understand the implications their well-researched ideas may have on later stages of development. They may be torn between two ideas for a website interaction that seem equally valid, not realizing that one is a coding nightmare and the other is straightforward and simple code. In fact, when it came to web design, I would say that probably 70-80% of the people at the large company I worked at had no idea how to code.
As someone with a decently broad set of web knowledge, I worry that sometimes I suffer from the opposite problem -- I think so far ahead to the later coding stage about how I'm going to do something, that in the early design stages I may stop myself from creating certain designs because I know they'll be a coding headache, even if ultimately the overall experience/design might be better by going the more "difficult" path.
In the end, I think the best way to handle this is to try to focus on getting each step of the process right in itself, but with an idea in the back of your mind about how, for example, interaction may affect the visual design or how the visual design may affect the coding. Whether that is multiple people on one project or one person doing the whole thing, don't let yourself think TOO far ahead, but don't have blinders on either. It's a tricky feat of compartmentalization but, at the very least, it's worth taking a look at and being aware of how each step in your process affects the others.
Thursday, July 31, 2008
Tuesday, July 22, 2008
Using breadcrumbs to define IA
"Breadcrumbs" is a technique used to let visitors know where they are in a site as they get deeper into content. An example might be:
Home > About the Company > Staff > Creative Director
Usually all but the current page is also a link, which lets you go up how ever many levels you want in one click. Generally it's a rather useful technique, particularly in large sites with many layers to them.
Rottentomatoes.com has an interesting take on breadcrumbs. In addition to setting up the hierarchy in a left-to-right manner, they also scale the text to match the relative "size" of each section. It's a good way of enforcing a mental map. Just as the United States is bigger than Massachusetts, which in turn is bigger than Boston, RT shows that the "Movies" section is bigger than "In Theaters" which is also bigger than the individual page for "The Dark Knight."
While there are a couple potential issues with how they have set this up (the breadcrumbs themselves don't really look like links, the / is not necessarily the best separator, and it is a bit odd that the movie name is in a different font), the overall concept is one I hadn't seen before and quite appreciate. It not only tells you where you are but reinforces the hierarchy and information architecture of the site.
Kudos, RT.
Monday, July 21, 2008
Starbucks misses the mark
If you've visited the Starbucks website recently, you may have noticed the floating "Got a great idea?" link that follows you around the site. Generally I don't like floating elements like that which appear without you asking for them, but it gets people's attention, and at least this is a somewhat benevolent gesture.
The major problem? There's no "Close" button. This thing will follow you around on every page forever -- there is no way to make it go away.
They've turned an effort to increase customer satisfaction into a creepy widget that won't leave you alone.
Tuesday, July 15, 2008
The Hurdle of Visuals
You've worked your heart out on a project, coming up with a great site structure, smart placement of content on each page, and a solid outer shell of basic fonts and colors, and you present the work to your client. What's the first thing you hear? "I don't like the photos." Many of us have been there before. After all your hard work, the only thing the client can see are the images (which usually they have provided and you have no control over). How do you get people to look at the right things?
One of the biggest challenges facing anyone in the field of information architecture/interaction design/usability (etc.) is the careful line of visual fidelity. Human beings are naturally extremely visual people. Look at the stats for most product sites, and you'll probably find that the most visited portions are photo galleries and other high-visual/low-text areas.
Unfortunately, strictly speaking, much of the work in this field is not particularly visual. Yes, a good information architect lays out where things lay on the page, but in many (most?) situations they are not the ones creating the graphics files, choosing colors and fonts, writing copy, taking (and choosing) photographs, etc. One of my favorite sayings comes from the field of film, and basically states, "a good editor has done his job when nobody notices his work." The point being, a bad editing job is going to be obvious and annoying, but a good editing job is going to be completely overlooked as the viewer is immersed in the film itself rather than the editing. The same goes for many user experiences. People notice when it's frustrating, but a seamless, intuitive experience lets the user focus on the content, not the process.
I bring this topic up now because I am wrestling with the best way to present work, both at an internal wireframe level and at a client-facing presentation level. I remember a project at my last job where five members of my team were independently presenting wireframes to a client -- the idea was to treat it almost like a pitch meeting as if we were different firms rather than just members of the same team. It was a fun challenge as we all got along well, but the differences in our approaches were stark. Some of us made ultra-simple wireframes, just black and white boxes with Arial text. Others added a layer of polish with gradients, nicer fonts, and drop-shadows. Some used photographs, others used representative "silhouette" images, some just used placeholder boxes. Before our client presentation, our boss looked across our examples and decided we shouldn't be biasing the client toward or against any design based on the fidelity of the wireframes. Let the IA speak for itself.
This posed a problem for me -- my design was very sparse, and was intended to highlight the imagery of the product itself by minimizing navigation and text. Removing images meant that there were large areas of blank space now in my presentation. Would the client be able to "project" the imagery in their own mind and see how it looked? Would she end up preferring a presentation that was heavy on text and navigation because there was no imagery competing for visual attention?
It's a tricky question. My boss could have suggested the opposite -- everyone HAD to add photos and gloss up their wireframes. But then would the client focus on images chosen rather than the IA? How do you make a client look at the right things? And on that note, how do you get your co-workers to even look at the right things when presenting internally?
The answer all depends largely on who your audience is. You could have a super-savvy client who can envision the finished product just from a wireframe, or you could have a client who sees a wireframe and dismisses the work entirely because it doesn't look like the polished, finished sites they're used to seeing. And on an internal level, particularly in firms where different people work on different aspects of sites -- such as an IA building wireframes and a designer creating the actual visuals -- you can find yourself stepping on toes. Does a high-fidelity wireframe make the designer feel like you're dictating their job? Conversely, does a low-fidelity wireframe make you look sloppy? Can you make something that projects a polished, dynamic end product while still respecting that technically, the visual polish is someone else's job?
In general, I think I tend to over-design wireframes and under-design comps. Most of my wireframing is in an agency environment, where it helps to have nice fonts and clean lines, but inserting sample imagery and venturing into the land of colors and graphics are going too far. Meanwhile, as a freelance designer, clients often can't see the finished product if they don't have imagery in place as well, although I think it's best to use different imagery from what they might see on their live site today, just to underscore that the imagery may change frequently but the structure and visual design will be constant.
One of the biggest challenges facing anyone in the field of information architecture/interaction design/usability (etc.) is the careful line of visual fidelity. Human beings are naturally extremely visual people. Look at the stats for most product sites, and you'll probably find that the most visited portions are photo galleries and other high-visual/low-text areas.
Unfortunately, strictly speaking, much of the work in this field is not particularly visual. Yes, a good information architect lays out where things lay on the page, but in many (most?) situations they are not the ones creating the graphics files, choosing colors and fonts, writing copy, taking (and choosing) photographs, etc. One of my favorite sayings comes from the field of film, and basically states, "a good editor has done his job when nobody notices his work." The point being, a bad editing job is going to be obvious and annoying, but a good editing job is going to be completely overlooked as the viewer is immersed in the film itself rather than the editing. The same goes for many user experiences. People notice when it's frustrating, but a seamless, intuitive experience lets the user focus on the content, not the process.
I bring this topic up now because I am wrestling with the best way to present work, both at an internal wireframe level and at a client-facing presentation level. I remember a project at my last job where five members of my team were independently presenting wireframes to a client -- the idea was to treat it almost like a pitch meeting as if we were different firms rather than just members of the same team. It was a fun challenge as we all got along well, but the differences in our approaches were stark. Some of us made ultra-simple wireframes, just black and white boxes with Arial text. Others added a layer of polish with gradients, nicer fonts, and drop-shadows. Some used photographs, others used representative "silhouette" images, some just used placeholder boxes. Before our client presentation, our boss looked across our examples and decided we shouldn't be biasing the client toward or against any design based on the fidelity of the wireframes. Let the IA speak for itself.
This posed a problem for me -- my design was very sparse, and was intended to highlight the imagery of the product itself by minimizing navigation and text. Removing images meant that there were large areas of blank space now in my presentation. Would the client be able to "project" the imagery in their own mind and see how it looked? Would she end up preferring a presentation that was heavy on text and navigation because there was no imagery competing for visual attention?
It's a tricky question. My boss could have suggested the opposite -- everyone HAD to add photos and gloss up their wireframes. But then would the client focus on images chosen rather than the IA? How do you make a client look at the right things? And on that note, how do you get your co-workers to even look at the right things when presenting internally?
The answer all depends largely on who your audience is. You could have a super-savvy client who can envision the finished product just from a wireframe, or you could have a client who sees a wireframe and dismisses the work entirely because it doesn't look like the polished, finished sites they're used to seeing. And on an internal level, particularly in firms where different people work on different aspects of sites -- such as an IA building wireframes and a designer creating the actual visuals -- you can find yourself stepping on toes. Does a high-fidelity wireframe make the designer feel like you're dictating their job? Conversely, does a low-fidelity wireframe make you look sloppy? Can you make something that projects a polished, dynamic end product while still respecting that technically, the visual polish is someone else's job?
In general, I think I tend to over-design wireframes and under-design comps. Most of my wireframing is in an agency environment, where it helps to have nice fonts and clean lines, but inserting sample imagery and venturing into the land of colors and graphics are going too far. Meanwhile, as a freelance designer, clients often can't see the finished product if they don't have imagery in place as well, although I think it's best to use different imagery from what they might see on their live site today, just to underscore that the imagery may change frequently but the structure and visual design will be constant.
Tuesday, July 8, 2008
Why are hosting admins so awful?
One of the new challenges I've faced in expanding my freelance work is that I have to interact with a variety of admin interfaces for different clients' web hosts. And they pretty much all suck. Why is that?
To be fair, web hosts have a tricky line to walk -- in many cases, experienced coders will be the ones interacting with the admin interface, and it is appropriate to use more advanced knowledge and to reduce the number of "walk you by the hand" tools. But at the same time, you may be dealing with staff members at smaller organizations who know next to nothing about web coding and yet are in charge of doing things like setting up email addresses and uploading files. Ideally, this would never really be the case -- but in those situations it does make sense to have a few tools and wizards to help.
So why do these hosting companies build interfaces that confound everyone equally? I just logged into one that instructed me NOT to use FTP to upload files (an incredibly simple procedure that is basically "drag and drop"), and that I was required to use FrontPage for fear of corrupting files. Of course, I'm ignoring this, as there's no logical way I'd be corrupting anything, but it's bizarre that this was set up this way in the first place. I'd figure that if you are in charge of a hosting company, you'd probably be an expert on how that sort of thing works, and I can't imagine any expert would set things up to require a particular software program to function (unless there is some devious co-branding going on here).
The worst case I saw was a company that actually professed to be comprised of usability experts. Not only was their administrative back-end completely unusable, but just finding out how to get help was confusing. They listed different methods of help contact for different "plan" levels, but nowhere (even after logging in) did it tell you what plan you were on.
Hosting companies could take a serious lesson from the variety of new admin interfaces that have popped up -- whether it's Facebook or Blogger or Flickr -- and note how simple and clear those interfaces usually are. One might argue they are not as complex as a full hosting package, but that is no reason to bury tools and functionality in unfamiliar terms or to overcomplicate simple processes. If these interfaces are confounding me, someone who works in the web industry and knows how to code a site, I can't imagine how confusing they must be to those less versed in web technologies.
As a side note, this seems to be a persistent problem I find whenever I am researching new ways to do things. When I am lucky enough to stumble on to a tutorial for a new technique, it invariably turns out to be an overly detailed process for something much simpler than what I was looking for. Conversely, when I actually do find information about the technique I'm looking for, it's frequently presented with the expectation that the reader already has an advanced understanding of the subject at hand, thus offering little value to someone who is actually trying to learn something genuinely new to them.
Much like bad hosting admin interfaces, bad tutorials fail to think about their prospective audience. Either cater your instructions to multiple types of users, or say upfront what the user should already know before reading (and if possible, link them to where they can learn that information if they don't already know it).
To be fair, web hosts have a tricky line to walk -- in many cases, experienced coders will be the ones interacting with the admin interface, and it is appropriate to use more advanced knowledge and to reduce the number of "walk you by the hand" tools. But at the same time, you may be dealing with staff members at smaller organizations who know next to nothing about web coding and yet are in charge of doing things like setting up email addresses and uploading files. Ideally, this would never really be the case -- but in those situations it does make sense to have a few tools and wizards to help.
So why do these hosting companies build interfaces that confound everyone equally? I just logged into one that instructed me NOT to use FTP to upload files (an incredibly simple procedure that is basically "drag and drop"), and that I was required to use FrontPage for fear of corrupting files. Of course, I'm ignoring this, as there's no logical way I'd be corrupting anything, but it's bizarre that this was set up this way in the first place. I'd figure that if you are in charge of a hosting company, you'd probably be an expert on how that sort of thing works, and I can't imagine any expert would set things up to require a particular software program to function (unless there is some devious co-branding going on here).
The worst case I saw was a company that actually professed to be comprised of usability experts. Not only was their administrative back-end completely unusable, but just finding out how to get help was confusing. They listed different methods of help contact for different "plan" levels, but nowhere (even after logging in) did it tell you what plan you were on.
Hosting companies could take a serious lesson from the variety of new admin interfaces that have popped up -- whether it's Facebook or Blogger or Flickr -- and note how simple and clear those interfaces usually are. One might argue they are not as complex as a full hosting package, but that is no reason to bury tools and functionality in unfamiliar terms or to overcomplicate simple processes. If these interfaces are confounding me, someone who works in the web industry and knows how to code a site, I can't imagine how confusing they must be to those less versed in web technologies.
As a side note, this seems to be a persistent problem I find whenever I am researching new ways to do things. When I am lucky enough to stumble on to a tutorial for a new technique, it invariably turns out to be an overly detailed process for something much simpler than what I was looking for. Conversely, when I actually do find information about the technique I'm looking for, it's frequently presented with the expectation that the reader already has an advanced understanding of the subject at hand, thus offering little value to someone who is actually trying to learn something genuinely new to them.
Much like bad hosting admin interfaces, bad tutorials fail to think about their prospective audience. Either cater your instructions to multiple types of users, or say upfront what the user should already know before reading (and if possible, link them to where they can learn that information if they don't already know it).
Monday, July 7, 2008
Desiging for iPhones
At my last job, for quite some time the place was abuzz with the word "mobile." Mobile apps, mobile this, mobile that. Every client wanted to have some sort of mobile aspect to their sites, and they threw the word out often with little regard for how mobile would be used and whether their visitors even had any need or desire for it.
Somewhat oddly, this seemed to have largely been triggered by the launch of the iPhone, which doesn't actually require any special "mobile" version -- it can access sites just as any computer can. Some folks internally thought that, as things continued moving in a "computer in the palm of your hand" direction, the distinction between mobile and desktop versions of sites would become a moot point.
But a year after the iPhone launched I think it's clear that you can't just plan for the iPhone version of the site to be the same. I don't own an iPhone myself, but I remember using a friend's iPhone last summer to check my Gmail. The process was clunky, and although Google tends to have fairly lightweight sites, it still was rather slow, probably due to the AJAX going on. Recently I borrowed a friend's iPhone and realized that Google had created an iPhone-specific version of Gmail, which showed a marked improvement. I've seen other sites create iPhone versions with far less success -- Fandango tries to get it right, but their decision to spread showtimes for a single movie theater over multiple pages, rather than just keeping them on one scrollable page, was a serious misstep ("scroll fear" really needs to be ditched completely) -- it made me have to memorize showtimes from one page to the next if I wanted to compare multiple movies, and slowed things down by requiring the iPhone to load multiple pages.
All this got me wondering about what sites are worth making iPhone versions available? What sites are users most likely to visit when a regular computer is not available? A few things come to mind -- email, maps, movie times, cafes and restaurants -- the sorts of things where you might want to get a little information about a place while you are out and about.
I don't have any statistics to back those things up -- they are based on guesses and about the kinds of things I think people might want to find when not near a computer. But I think it's important that whenever a company is looking at their own website that they think strategically about what their iPhone users might need. Do they really need an alternate version of the site? Can you design your site in such a way so that it works without needing separate versions for the iPhone? Are there particular tools that iPhone users may be more apt to use (i.e., a Starbucks.com iPhone visitor may need a store locator but not care at all about company info)? And since, to my knowledge, iPhones still do not support Flash, are you making sure to have your site available in a non-Flash version?
I'll be curious to see how sites evolve as the iPhone age soldiers on, and if the upcoming 3G iPhone will have any design ramifications. It is key, however, to remember to view any new web aspect -- whether it is iPhones or social networking or RSS feeds -- in light of your particular company's needs. A poorly executed (or unnecessary) implementation of features often do far more harm than leaving those features out and waiting until there is a clear need for them.
Somewhat oddly, this seemed to have largely been triggered by the launch of the iPhone, which doesn't actually require any special "mobile" version -- it can access sites just as any computer can. Some folks internally thought that, as things continued moving in a "computer in the palm of your hand" direction, the distinction between mobile and desktop versions of sites would become a moot point.
But a year after the iPhone launched I think it's clear that you can't just plan for the iPhone version of the site to be the same. I don't own an iPhone myself, but I remember using a friend's iPhone last summer to check my Gmail. The process was clunky, and although Google tends to have fairly lightweight sites, it still was rather slow, probably due to the AJAX going on. Recently I borrowed a friend's iPhone and realized that Google had created an iPhone-specific version of Gmail, which showed a marked improvement. I've seen other sites create iPhone versions with far less success -- Fandango tries to get it right, but their decision to spread showtimes for a single movie theater over multiple pages, rather than just keeping them on one scrollable page, was a serious misstep ("scroll fear" really needs to be ditched completely) -- it made me have to memorize showtimes from one page to the next if I wanted to compare multiple movies, and slowed things down by requiring the iPhone to load multiple pages.
All this got me wondering about what sites are worth making iPhone versions available? What sites are users most likely to visit when a regular computer is not available? A few things come to mind -- email, maps, movie times, cafes and restaurants -- the sorts of things where you might want to get a little information about a place while you are out and about.
I don't have any statistics to back those things up -- they are based on guesses and about the kinds of things I think people might want to find when not near a computer. But I think it's important that whenever a company is looking at their own website that they think strategically about what their iPhone users might need. Do they really need an alternate version of the site? Can you design your site in such a way so that it works without needing separate versions for the iPhone? Are there particular tools that iPhone users may be more apt to use (i.e., a Starbucks.com iPhone visitor may need a store locator but not care at all about company info)? And since, to my knowledge, iPhones still do not support Flash, are you making sure to have your site available in a non-Flash version?
I'll be curious to see how sites evolve as the iPhone age soldiers on, and if the upcoming 3G iPhone will have any design ramifications. It is key, however, to remember to view any new web aspect -- whether it is iPhones or social networking or RSS feeds -- in light of your particular company's needs. A poorly executed (or unnecessary) implementation of features often do far more harm than leaving those features out and waiting until there is a clear need for them.
Wednesday, July 2, 2008
Dominant Design
One of the most interesting concepts in design that I've come across covers all sorts of media, and that's the concept of dominant design. My understanding, in short, is that something is a "dominant design" when it becomes so ubiquitous that it is virtually impossible to replace it with an alternative. A good example is the QWERTY keyboard. There was certainly logic behind its creation (although the rumor that part of the design was based around being able to type the word "typewriter" using only the top line of keys is sure to make any usability person frown), but I've heard that testing other layouts has shown that there are, in fact, better ways to arrange the keys. But if you try to sell a computer with a non-QWERTY keyboard, you will fail. The design is too omnipresent to be challenged.
I find this issue particularly interesting lately because it seems a lot of things long considered dominant design are being challenged. The most compelling example I can think of is how the standard gasoline-powered car engine is now being challenged mightily by hybird, electric, and fuel-cell alternatives. The whole "green" movement is having an impact on dominant designs in a number of other fields too, from architecture to food to energy production (one of the most fascinating stories I've heard is how some engineers are attempting to collect the energy generated by footsteps in a building's lobby and use it for power -- a wonderful example of conservation, if it is achievable).
In the world of design, trying to "break the rules" is a perennial goal of many designers. Tell a designer something has to be a certain way and they almost always will want to do it a different way. I met many creative folks at my last job who were always trying to come up with new and "exciting" ways to handle website interactions - a headache for me from a UI perspective as generally "new and exciting" translates to "confusing and annoying" to users. Designers may love change but most people hate it, and many actions are so ingrained that trying to break those habits is generally not worthwhile.
But that doesn't mean that challenging a "dominant design" is a bad idea. It's just important to make sure it's being done in a way that doesn't put off users, and that the impetus for change is coming from the point of view of "there's a better way to do this" rather than "I just want to be different."
Designs often become dominant for very good reasons, and in a pinch, it's generally safe to assume that if everybody else is doing something a certain way, it's fine to follow suit. But stepping back and heading to the drawing board from scratch occasionally is definitely a worthwhile exercise. You may end up realizing that the "standard" way is the best way after all, but it's worth making the occasional challenge to dominant design. You may just end up finding a better way after all.
I find this issue particularly interesting lately because it seems a lot of things long considered dominant design are being challenged. The most compelling example I can think of is how the standard gasoline-powered car engine is now being challenged mightily by hybird, electric, and fuel-cell alternatives. The whole "green" movement is having an impact on dominant designs in a number of other fields too, from architecture to food to energy production (one of the most fascinating stories I've heard is how some engineers are attempting to collect the energy generated by footsteps in a building's lobby and use it for power -- a wonderful example of conservation, if it is achievable).
In the world of design, trying to "break the rules" is a perennial goal of many designers. Tell a designer something has to be a certain way and they almost always will want to do it a different way. I met many creative folks at my last job who were always trying to come up with new and "exciting" ways to handle website interactions - a headache for me from a UI perspective as generally "new and exciting" translates to "confusing and annoying" to users. Designers may love change but most people hate it, and many actions are so ingrained that trying to break those habits is generally not worthwhile.
But that doesn't mean that challenging a "dominant design" is a bad idea. It's just important to make sure it's being done in a way that doesn't put off users, and that the impetus for change is coming from the point of view of "there's a better way to do this" rather than "I just want to be different."
Designs often become dominant for very good reasons, and in a pinch, it's generally safe to assume that if everybody else is doing something a certain way, it's fine to follow suit. But stepping back and heading to the drawing board from scratch occasionally is definitely a worthwhile exercise. You may end up realizing that the "standard" way is the best way after all, but it's worth making the occasional challenge to dominant design. You may just end up finding a better way after all.
Tuesday, July 1, 2008
"The New Trends" (or "Why Web 2.0 is a Worthy Term")
Recently a client asked me the fairly benign question, "so what are the new trends in web design?" My initial thought was that this was so broad a question that even listing a few dozen trends would barely scratch the surface. But upon further reflection, I realized it wasn't such a tough question after all. As a corollary, I imagine fashion editors are posed such questions daily, and any one of them could probably spit out a reasonably accurate soundbite. "Bright colors and loose, flowing garments cinched with thick belts are all the rage." I have no idea if that is actually what is popular in fashion right now, but it's certainly the kind of answer one might expect to plausibly hear, and that kind of answer would probably be sufficient for a casual observer.
There are a few different aspects to web design -- functionality, visuals, and programming among them -- and you can name quick responses to all of them. Social networking and interactive "make it your own" experiences are popular from a functional point of view. Visually, gradients, larger text, and reduced visual clutter are becoming widespread. And from a programming point of view, although I admit this is where I am least familiar, there is a renewed emphasis on semantic markup, open-source programming, and lightweight applications (basically, yes we almost all connect via broadband these days, but we can still make things move even faster). As someone in the field of usability, I'm tempted to say these are all ways of saying the same basic thing, a la the fashion editor soundbite: Web design is shifting from a "look what we can do!" showiness to a "look what you can do!" utility focus.
This is somewhat inevitable. As such a young medium, web design was really flopping around without a clue in its formative years. Since there were very few clear "right ways" to do things, trends came and went, and as anyone who has ever worked in a design agency knows, often the first thing a design team does when starting a new project is just look at everything the competition is doing, sometimes emulating work without really knowing if it's genuinely the best approach (this is not entirely without merit, however -- a key tenet of good usability is standardization).
This era of web design feels like the clean-up period after a major project's initial launch. Everyone is going back and looking at how they used to do things and seeing if there is a better way (there almost always is). Perhaps this is why the unquantifiable notion of Web 2.0 has caught on. It really does feel like the second phase. We get how this works now. We know the ground rules. Now it's time to make everything better.
There are a few different aspects to web design -- functionality, visuals, and programming among them -- and you can name quick responses to all of them. Social networking and interactive "make it your own" experiences are popular from a functional point of view. Visually, gradients, larger text, and reduced visual clutter are becoming widespread. And from a programming point of view, although I admit this is where I am least familiar, there is a renewed emphasis on semantic markup, open-source programming, and lightweight applications (basically, yes we almost all connect via broadband these days, but we can still make things move even faster). As someone in the field of usability, I'm tempted to say these are all ways of saying the same basic thing, a la the fashion editor soundbite: Web design is shifting from a "look what we can do!" showiness to a "look what you can do!" utility focus.
This is somewhat inevitable. As such a young medium, web design was really flopping around without a clue in its formative years. Since there were very few clear "right ways" to do things, trends came and went, and as anyone who has ever worked in a design agency knows, often the first thing a design team does when starting a new project is just look at everything the competition is doing, sometimes emulating work without really knowing if it's genuinely the best approach (this is not entirely without merit, however -- a key tenet of good usability is standardization).
This era of web design feels like the clean-up period after a major project's initial launch. Everyone is going back and looking at how they used to do things and seeing if there is a better way (there almost always is). Perhaps this is why the unquantifiable notion of Web 2.0 has caught on. It really does feel like the second phase. We get how this works now. We know the ground rules. Now it's time to make everything better.
A Beginning
This is not the first time I've attempted to start a blog. I had one going for about 4 entries several months ago, where I was trying to present usability and design advice in a Jakob Nielsen-esque "this is how you should do things." But I realized rather quickly that limiting myself to usability design (and then requiring myself to write in a prescriptive manner) was far too restrictive.
So I'm letting myself branch out a bit. I want to focus on talking about design, but not limit myself. I tend to let my mind wander on to vaguely philosophical topics and I don't want to stop myself from talking about those things if I think others may find it interesting. And, more importantly, I don't want to write from a "do things this way" point of view because, while I have skill and experience, I don't know everything, and I don't think it's particularly responsible of me to claim that my ways of thinking will work for others.
I'm also letting myself (temporarily) disregard the visual design of this blog. I spent some time customizing templates the last time I tried to make a blog and, in retrospect, I realize I was valuing style over content. Maybe that's the first lesson I learn as a blogger: a good-looking nothing is still nothing.
So I'm letting myself branch out a bit. I want to focus on talking about design, but not limit myself. I tend to let my mind wander on to vaguely philosophical topics and I don't want to stop myself from talking about those things if I think others may find it interesting. And, more importantly, I don't want to write from a "do things this way" point of view because, while I have skill and experience, I don't know everything, and I don't think it's particularly responsible of me to claim that my ways of thinking will work for others.
I'm also letting myself (temporarily) disregard the visual design of this blog. I spent some time customizing templates the last time I tried to make a blog and, in retrospect, I realize I was valuing style over content. Maybe that's the first lesson I learn as a blogger: a good-looking nothing is still nothing.
Subscribe to:
Posts (Atom)