Tag: design

Istanbul (Not Constantinople) Will Confuse Your Users

If you’ve never heard The Four Lads (or They Might Be Giants) sing “Istanbul (Not Constantinople)” you’re missing out on a great swing song. The lyrics basically dance around the fact that Constantinople was renamed Istanbul, but also how even New York was once New Amsterdam, saying things like “People just liked it better that way.” and “It’s nobody’s business but the Turks.”

Eventually you’re going to look at your website and think that you need to redesign it. In ages past, I would say things like ‘What would Amazon do?’ to indicate how people generally should not redesign their entire site. But those ages are long past and now, if you want to redesign your website, it’s an accepted standard of life. Both the code running your site and the look and feel of it have to be updated more than with just a slap of fresh paint.

Now that everyone’s accepted the fact that sites will update and change, the trick is how to make a change without forcing people to wonder why Constantinople got the works!(See? The song title had a point.) You can’t just assume your user-base is going to magically divine how everything works and know where to go to do things, after all.

Obviously you can make a blog post that explains where everything went, but eventually that will fall off your front page. So you could also make a new ‘page’ for your site features, and hope people saw that. Toss in some customization on your 404 page (and maybe some clever .htaccess redirects to send people to the right place), and you should be okay.

Should is the key-word there.

Science has proven to us that people like what they like, and changing it is a sure-fire way to cause problems. And once people make a decision that they like something, they will grow to actively dislike anything else. That’s why you get rabid Apple vs Windows fanboys. (Read The science of fanboyism by The Tech Report.)

At its crux, that is why bigwigs tell you not to redesign your site. Not because new layouts are bad, but because people are used to your site and, probably, like it the way it is. That tells me that when you make a change, and you will, you need to do it in a way that looks similar enough that while things have changed, the ‘feel’ remains the same.

The feel of a site is a terribly nebulous thing. The ‘feel’ has to be right for you, because if you don’t like your own site, you’ll never use it. The ‘feel’ has to be right for your target audience or they’ll never use it. Anyone who tells you they know all the answers, by the way, is lying. There’s a reason big companies hire folks to do tons of studies before changing the UX (User eXperience) of a site, after all. Generally speaking, as Matt Mullenweg said recently, “The software is wrong, not the people.”

Have you ever felt like a fool because you can’t remember the 16 special clicks and drags to get MS Word to do something? It’s not you, it’s the product. Your website is your product, and if even one person complains and says ‘This isn’t right!’ you need to stop and think about it. I’m not saying you have to change it, but I am saying you have to consider their point of view. Get out of your monkey house.

What it all comes down to is simple. If your site isn’t easy for your intended audience to use and understand, they won’t. If you change your site to something new and different and they don’t like it, they’ll leave. You need to understand what makes your users tick, and cater to them without kowtowing to their every whim. Sometimes learning that balance will make you take the wrong path. That’s okay. Mistakes are things to learn from, so don’t fear them.

On the subject of ‘big’ changes, there is a time and a place for them. When you look at how Amazon, Apple and Microsoft looked in 1999 and compare them to 2011, you feel like they’re the same sites, only grown up.

1999

2011

For the most part, color schemes are the same and so is layout. But if you were to jump from one to the other, it would feel like a big change. In reality, the move from 1999 to 2011 was all done in steps, slowly and carefully, so as not to jar the user too much out of their comfort zone.

This doesn’t just apply to site design. The GAP logo changed recently, and was universally panned. It was so bad that GAP actually had to change their logo back. Pepsi changed their logo and got more hate than Coke did for New Coke. (Actually I don’t know if anyone cared about the Pepsi logo. We drink Coke in my house.)

Some of the changes were pretty bold, and they all drive home the point that you do need to make changes. But they also remind us that the changes must be recognizable. “People just like it better that way.”

26 July, 2011
Get Out of The Monkey House

“I have this refrain about the monkey house at the zoo. When you first enter into the monkey house at the zoo, you think, ‘Oh my god this place stinks!’ And then after you’re there for 20 minutes you think, ‘it’s not so bad’ and after you’re there for an hour it doesn’t smell at all. And anyone entering the monkey house freshly thinks, ‘this stinks!’ You’ve been living in the monkey house.” (Quoth Tim Gunn, from the 2008 finale of Project Runway)

Bless Tim Gunn for saying it out loud. Sometimes you’re too deep in the monkey house to realize your idea stinks. This isn’t to say it’s a bad idea, but you’ve spent so long working on the project you lose your perspective, and can’t see how it looks to someone from the outside.

Being able to keep your mind open and see things from the perspective of the programmer as well as the end user is difficult, to put it mildly. When you write and design something, you know where you’re starting from and where you’re ending. You understand, instinctively, the journey it takes to get where you’re going.

This is true of webdesign as well as programming.

For me, I know how to navigate my sites and find what I’m looking for, because I know where to find everything! I have no problem popping around to where I need to be, to do what I need, because I built everything and I’m as familiar with it as I am my closet. Possibly more-so. So when someone mentioned, after I did a redesign, that they had just learned where everything was, and they would have to re-learn it all, I smacked my head and shouted, “Why is it always monkeys?”(That’s a Kim Possible joke.)

This sent me on a three day documentation binge, where I struggled to explain things about BuddyPress that I took for granted. Like how you edit your profile, what ‘activity’ was, and how you sent a PM. It doesn’t help me that BuddyPress and WordPress are in a weird in-between stage of their Admin Bar relationship (I’ve beta-tested Boone Gorges’s new code for it, and it looks lovely). But knowing well that I’ll implement it and be comfortable using it, regardless of my user base, drove me to sit down and explain.

It was in those explanations that I realized things were wrong. Things weren’t intuitive the way I’d designed them, not for someone new, and the layout could be better. It smelled bad, and by the way, did I forget to look at the site in FireFox? The only way to chase off those monkeys is to find a way to look at everything with fresh eyes. For me, I get there by documenting with pictures and explaining a process to someone with no basis. I get there by finding a specific error, bouncing between three browsers and wondering what the heck happened to my CSS?

I have to thank a teacher, Ms. Gallagher, who sat us down one day in Life Science class and asked this question: “Pretend an alien has come to earth and asks you ‘What does salt taste like?’ They have no concept of sweet and salt, they have never eaten any human food. How do you explain it?”

I was flummoxed then, and to a degree, I am now. The answer was that you cannot explain things without something to compare it to. The human mind, at least, needs an analogy, or a basis, to stand on and build their new concepts from. Even the greatest genius in the history of pyhsics said that explaining things in laymans terms was not simple at all, which when you think about, is a hell of a lesson to toss at a bunch of hormonal 12 year-old kids, but boy did that lesson stick!

Understanding the ‘why’ behind a website may not be as complicated as physics but the basic tenant, that a person is going to look at your website and ask ‘Why do I need to do that?’ and ‘How do I do this?’ we can accept as givens. Thankfully we don’t need to subscribe to the intense level of intellectual honesty that Richard Feynman does with science. We can say ‘BuddyPress groups are similar to FaceBook pages.’ We can assume that people have a basic concept of what a forum is. We can trust people know that when there is a text box for ‘Username’, people will fill in their user name.

And yet. These are all learned skills that we have developed over years of using the internet. Twitter makes perfect sense to some of use, while others need to read mom, this is how twitter works.

The deeper you get into your own work, be it a website, physics, or painting, you have to remember you are in your monkey house. Sometimes the house is clearly visible and understandable, sometimes the house locks you in. Be that as it may, get out.

18 July, 2011
Introducing HEO

We all know that SEO is ‘Search Engine Optimization.’ I humbly suggest we pay better attention to HEO – Human Experience Optimization.

After you spend hours and hours optimizing your site for search engines, you should sit back and think about how the humans who are reading your site. This should be blindingly obvious to everyone, but more and more we hear about how you should make your URLs SEO friendly, or your post excerpts/slugs/format/meta-data the best to get highly ranked in Google. At a certain point, you’re missing the goal of a website.

A website is not for search engines, a website is for humans.

Humans like to be able to find what they want relatively painlessly. They like to know when something was written (or when whatever it’s about took place). They like to be able to search, sort, surf and select. They like to know weird things. It’s your job to make sure that when a user hits your site, they stay.

Fonts

I’ve mentioned before that font choices matter on your site. Perhaps the most important thing to remember about fonts is that people have to be able to read them. A lot of sites make their fonts very small, which force viewers to hit Ctrl-+. This is one of Jakob Nielsen’s pet peeves. Users should be able to control their font size, but you should also set your font starting size to something legible.

Imagine my surprise when I went to a site and saw this:

I had to zoom in to read. That font is set to font: 11px/13px "Lucida Grande"..... Just by changing it to 12px/20px it was easier to read, but to make it a perfect starting point, it should really be 14px/20px. You’ll need to balance on your font choice with the size, though, as too-thick and too-thin fonts are equally painful for people to read.

Colors

I’m in my mid-thirties with the best worst vision you’ll find before someone gets classified legally blind (that said, I have fantastic night vision). I cannot read black backgrounds with white text for more than a few seconds without getting after-images. I’m not in the minority of the world. There’s a reason books, eReaders, newspapers and magazines tend to print dark text on light backgrounds, and it’s not just the cost. More people can read that setup. On top of that, don’t use background images. The busier the background, the more difficult it will be to read and you’ll draw the attention away from the text.

The colors on your site need to be easy to read, and not strain the eyes.

Layout

Did you know that users tend to read to the left? This sort of flow makes sense when you consider that most languages are read left-right. Jakob Neilsen points out that people spend “more than twice as much time looking at the left side of the page as they did the right.” (Jakob Nielsen’s Alertbox, April 6, 2010: Horizontal Attention Leans Left) Not only that, but people actually tend to read pages in a pretty distinct F-shaped pattern. (Jakob Nielsen’s Alertbox, April 17, 2006: F-Shaped Pattern For Reading Web Content)

So how do you best layout your website? I tend to think people read content better if it’s on the left, so I put the body of my text left and the sidebars right. I also take into account that newspapers and magazine break up text into columns for readability reasons, and set a fixed width to my site. That choice is somewhat controversial among my friends, but I like to look at the iPad and Kindle for examples as to why you want to not allow forever-width pages. Monitors are big, browser windows can be huge, but in the human head, eyes are spaced in a certain way. Making your page’s content too wide is a drain.

Page Length

There used to be a concept of ‘The fold’, which was basically that people didn’t scroll down on webpages in the early days of the web, so if they didn’t see your important content on the top half of your page (i.e. above the fold), they weren’t going to see it at all. It’s 2011. People know to scroll down a page.(Jakob Nielsen’s Alertbox, March 22, 2010: Scrolling and Attention) But you still need to make sure your site has the most important content ‘above’ the fold.

Where’s the fold these days, though? Monitor size is a lot more variable today than it was in 1995, and the break-point on a page is getting pretty difficult to figure out. Unlike a newspaper, where the ‘fold’ is pretty obvious (unless you’re the Chicago Sun Times), you have to take a pretty good guess at where the ‘top’ of your site is. Oddly, this is a lot easier with the iPad, which currently is my benchmark for ‘the fold.’

Keeping that in mind, page length matters! I try to keep each post no more than 1200 words, because of human attention span. If I happen to dip longer, I’ll consider breaking the post into multiples.

Permalinks/URLS

Samuel Wood (aka Otto) said it simply:

Humans care about dates. Leaving a date identifier (like the year) out
of the URL is actually de-optimizing the site for humans.

Not everything should have a date, mind you. Resources like WikiPedia or other sites that act as repositories for static, timeless material (like a book), certainly do not need date stamps. Deciding if your site needs to include the year in the URL (like I do here), or not at all (like I do elsewhere), is something you need to think long and hard about. If you’re making a ‘traditional’ blog, or a newspaper, or some site that acts as a repository for time-based information, the answer is simple: Yes you do.

In addition to sorting out if you need dates or not on your site, you have to think about the post format. I’m a huge proponent of pretty URLs, so I tend to lean to custom crafted URLs. On WordPress, I always review the permalink and, if I think it could be better shorter, I do so. MediaWiki defaults to whatever you want to name the page and puts that in as your page title(Oddly you can only override this with {{DISPLAYTITLE:Custom title}} , which has weird results in searches.), but WordPress uses the ‘title’ of your post and makes that your page title.

This is pretty easy to change, though. Just click on edit and make it shorter (which I strongly suggest you do in most cases).

What else?

I could go on and on. Like how you shouldn’t use too many ads (and whatever you use, they shouldn’t be bigger than your post content!), don’t use flashing images/text, and keep in mind your audience! What are your hot-button topics for making your site human friendly?

27 June, 2011
Website Viewability

The goal to make your site look cool, be easy for people to use, and be available for all, is a holy grail trifecta that is rarely achieved. Many times, you have to sacrifice one leg of the tripod in order to achieve your goals.

The advent of Typekit has led to a lot of websites using cool custom fonts in a way that is supposed to solve that age old problem of what happens when you design your site with a font the end-user doesn’t have. For a very long time I couldn’t understand what the big deal was, since I often read these sites from work, and their fonts were all jaggedy and ugly. Then I fired up a site from home and was astounded at the difference.

This is what I normally see when I go to TypeKit:

This is what you’re supposed to see:

I know it doesn’t look too bad, but basically what I don’t get are the nice, smooth, edges on fonts, so when I read a whole page like that, it’s hard on the eyes. TypeKit works by javascript, so arguably, it should work on all browsers with JS enabled (which is to say all modern browsers). I’m using Chrome (latest and greatest) and I get crap.

That’s from Ed Jeavons’ Beyond web-safe fonts with Typekit, which is a great article. But the whole thing is unreadable to me because of that.

So where is the break down here? TypeKit’s goal is to make their fonts work on every site, regardless of if you have the font installed on your server. Jeavons says “Typekit degrades gracefully so that anyone without JavaScript, or with a browser that doesn’t support the necessary features, will simply revert to your standard CSS rules.” If that was the case, shouldn’t I be seeing a better site?

According to TypeKit, the problem is that the sites I’m seeing didn’t make good standard CSS rules. My anecdotal evidence suggests otherwise. After all, every site I go to has the exact same problem. So I turned off javascript and went back to the site:

Now that looks like you’d expect graceful degradation! At this point, my answer is that something TypeKit does is unwelcome on my office computer. Or more likely, my office firewall. That’s a whole new kettle of fish. I can’t reasonably expect everyone to go find an office behind a firewall made of adamantium and test their site. But clearly this is not the fault of the individual site. Is it reasonable to expect TypeKit to look into this? I went on a search and found they have a cool little checker too typecheck which says I’m fine:

There’s nothing in their FAQ or help desk that mentions Firewalls having this issue, so I decided to check out Google Web Fonts. Lo and behold, I get the same problem. Some more digging and I found someone who ‘fixed’ the problem using css. My Twitter friend @cgrymala suggested I also try ClearType, since I’m on Windows XP at work. That actually helped a lot (seriously, I cannot tell you how much nicer things look) but the main problem is still there.

Where’s my problem? My problem is that TypeKit and Google Web Fonts, while they purports to be a one-size-fits-all/degrades-nicely app, are not. If you’re not on the forefront of technology, if you’re behind a firewall, if you’re on a weird setup, these things are not going to work. This is not really TypeKit’s or Google’s fault. They’ve done an amazing job setting things up so it works most of the time. At best, they could have their javascript detect browser and OS (yes, you can do these things) and if it’s IE 6 or Windows XP (for example), revert to the javascriptless version of the site.

It’s nigh impossible to solve the firewall problem. You can’t detect the firewall easily, and part of the point of them is they obfuscate who and what they are. And if the problem is a combination of OS, browser and firewall, then the best you might be able to do is somehow detect if any one of those three are on the known ‘possible’ trouble list, and shunt them off to a non-js version. And now you’ve added a lot more load to your server.

The best you can do is to avoid using these cool systems and features until they’re more supported, which is where the whole concept of sacrifice comes in. If it’s more important for you to have your site look cool than to work for everyone, you have to find a way to degrade better. For a long time I had an alert bar on my site to tell you that if you were using IE 6, you needed to upgrade. Going back further, we used to regularly make sites that said ‘Best viewed in Netscape Navigator.’ Thankfully sanity struck, web standards started to stick, and we began to design sites that looked good in most browsers.

I cannot advocate a return to ‘Best viewed in…’, but I can suggest that if you’re relying heavily on cool, cutting edge, features, you also have a printer-friendly version of your site that runs without any of the bells and whistles.

16 May, 2011
Every Site should have a Favicon
Imagine summing up everything a website is about in a 16x16px square. That’s the goal of a favicon (short for favorites icon). Pretty much every site out there has one, and it’s a devil of a task to make one that looks appropriate, identifiable and understandable in such a small space. As much time as I spend tweaking a design I spend on a favicon because they are that important for the look and feel of a site. A site without one is nearly naked.

Back in the days of IE 4 (yeah, 4, so 1997), Microsoft hit upon a great idea. If you made a teeny picture and saved the file as favicon.ico in your html root, their browser would pick it up and be the icon on your bookmarks menu. It didn’t take long for people to figure out microsoft.com was doing this, and they began implementing it all over for every site they could. As people got smarter, they figured out how to fake it, so you could have a different favicon for every page, just by manipulating the head of your html document.

Back in the day, you had to use .ico (Microsoft Icon) files as your favicon, but these days most modern browsers pick up .png, .gif and .jpg happily enough. This allows people to make animated favicons, which need to be shot and killed. For maximum compatibility, though, most people still use .ico, since IE doesn’t like the others. Or it didn’t. Someone on IE 8 will have to check.

The real problem boils down to size, for most people. At 16x16px, you don’t have a lot of room. This site actually has a non-recognizable icon (it’s the Xena/Gabby picture). Technically you can go up to 32×32 for an image, and I have one that’s 240×240, but in the end, they all render at 16×16 on 99.999% of browsers, so looking good at that size is your goal.

If you think I’m being silly, about a year ago, Google changed their favicon and admitted that it wasn’t final. Right away they basically started open submissions for a better one. When they changed it in January, it became the favicon heard ’round the world. Eventually, Google stepped up to explain the change. It’s important to have an icon that matches your site, as Google explains, as well as a unified look for all aspects of your design. Should you have a different look for each app on your site, or an all in one? How does it affect the other aspects of your site, like the iPhone’s new icons for saved webpages?

These aren’t simple answers, but to explain how I go about it, here are some favicons that I have made and use out there in the world. Not this site’s though. I need to come up with something better for it.

When I moved JFO from orange to green a year or so ago, I made a new favicon to reflect the design. The image is a cropped shot from the original header (which is now a full color photo, but still), and is a close up of Jorja’s face. It’s JUST recognizable as Jorja, I think.

Alternately, I came up with this image, which is a copy of the shot used on the header currently, done in greens to match the site. In a way, it’s both more and less recognizable, as the image is harder to make out (it’s a head and shoulders) but as it’s the same used in the header, people might make the connection. I’ve yet to use this on a live site, but it shows up on my test sites right now.

For the website ‘SCA Jews’, I had gone with a slightly eastern feel of a website, that evoked both the idea of camping with the concept of days gone by. Evening Sun came from spectacu.la, and took minimal editing to fit my plan. The problem was I had no favicon. Originally I put a little sun up there, but then it struck me that the ‘meaning’ of the site was to promote the meal plan “Meals on Camels”. What better way to express this than with … a camel.

I also helped design (or rather optimize the design for) my friend’s site, The Yeast I Could Do. She had no favicon and I spent a couple hours scrounging for something bread-ish, and eventually picked this one, even though it’s questionable. It does look a bit like a loaf of bread, and she recognized it, so I think it went okay. In it’s .ico format, it has a transparent background.

Finally there’s this one. Pony Wars is a joke site I made up with a friend for a “My Little/Pretty Pony RPG”. I mocked up the site because I was bored one day and finding an icon for it has been a bear. In the end, I went with this 33×33 (yes I know) icon of a pink pony. It doesn’t scale very well and looks weird on the site itself, but it’s a hard icon to shrink.

If, in the end, you’re stumped at making one, there are a lot of favicon collections out there to help you. Be warned, they can take a LONG time to load:
- favicoop, a favicon collection with over 43288 icons
- MpP’s Gallery, broken up into multiple pages
- Favourite Favicons, not as many, but easier to see
What are your favorite favicons?
22 July, 2009
I Haven’t Got Time For The Pain!

Two months ago (give or take) I mused over photo gallery options for my sites. For Ipstenu, I’m now using WordPress and treating it like a photoblog. For JFO, however, I couldn’t answer it that easily.

I really do like the Gallery project. I do! I learned a great deal about photography from it, and I’m thankful for it. But. I needed to move on as a user, a developer and a photographer. On that last one, I’m not a profession one, I’m just a goofy girl with a camera who likes to remember where she’s been. As a user, Gallery2 did the job well and without major issues. As a developer, it made me want to cry. Many times. Once I had to log into my friend’s server to fix his install. That just whomps.

Even the developers admit that Gallery2 suffered from bloat:

The code base is too complex and over-engineered because it was designed to fix every single thing that was wrong with Gallery 1 (Second System Effect) leaving its scope hazy and broad.

The whole idea of it was “Your photos, your website.” And personally I love that. I hate having flikr or picasa in charge of MY photos. Let alone FaceBook. I have a blog on my domain for that same reason. But Gallery2 was too much. I never used half of it and it was 16+megs at its slimmest install. That the developers agreed with my feelings delighted me. And the Feature List was also exciting. As soon as G3 popped out, I grabbed a copy and started playing.

With each version of Gallery3’s beta releases, I would get excited and then disappointed. Excited for the new toys and disappointed for how the overall effect felt. It just felt wrong for me. It wasn’t really Web2.0, even though it was, and the usage felt off. It didn’t make intuitively as much sense as G2, though it was still far better than Coppermine (which frankly I hate, and I know more people who argue with it than anything). At first I thought it was because I was so used to G1 and G2, but then I realized that over the last 10 years, I’ve used so many different systems that I’m fine with subtle differences. I’m savvy, I’m smart, I can code, so why did G3 feel wrong to me?

It was too hard. Too much was built in and not plugable. Too much was hard coded in itself. Theming was impossible in the first release, and way too hard in the third. Understanding the theme system in G2 was easy, though implementing it was hard. Understanding it in G3 was hard and implementing was horrific. And before someone reminds me, AGAIN, that this isn’t even a beta product but an alpha, quite frankly that’s not an excuse. The basic things you need to be able to do with a first public release (be it beta, alpha or whatever) is to use it: Upload photos, change options, theme. That’s it. Those are the three things at it’s most basic that photo gallery software has to have, or you may as well be using an off-site solution.

And while I may sound like I’m ranting, I’m not. I’m sad and frustrated and … You know, I really like Gallery! I really do. But it was starting to feel like Movable Type. They made a big shift and suddenly I wanted to know who peed in my coffee. The code felt wrong, it felt klunky, it felt raw. It was like starting over, and I didn’t like where it was going. And I realized the fact was that I was going to say goodbye to an old friend.

Personally I’m all about the simplest, best, tool for the job. I wanted a way to update news on JFO and, when that was ALL I needed, I used CuteNews. When I realized the site was going to need something more, I weighed my options, tested software, and decided that while WordPress was a bit of overkill, I knew how to support it and customize it to be what I needed. In the end, that proved to be a perfect choice. When I had a forum (the first time around), it was IPB, which I liked, but it always felt too big. Now I use the very basic bbPress and it’s what I need and nothing more.

If WordPress had PhotoPress, I’d probably have snagged that. Instead, I shopped around. I installed Coppermine, again, to test. I put up G3-alpha3 and then 4. I went to WikiPedia and dug out the compares and ended up in a head to head battle between ZenPhoto and Gallery3.

ZenPhoto won by feeling better.

Seriously, it’s asthetics at this point. There are only two features I miss: Being able to re-upload a picture and keep it’s MetaData, and having ‘new’ images show up with a different background color. But I can live without those.

12 May, 2009