For a rather significant portion of my life, I’ve spent most of my time on the computer. After I quit playing sports in high school I developed a rather violent MMO addiction, so between homework, RuneScape, and Counter-Strike (1.6, not Source, because I’m not a noob) I did a lot of sitting, mousing, and typing. Then in college I naturally gravitated to a lot of programming, plus paper writing, later supplemented with freelance web development on the side. All of this has left me with a fun little Repetitive Strain Injury in my right wrist, which I have finally come to terms with and am making an effort to get rid of.

So I started thinking: what is the first thing I can change that will give me the most long term benefit? The answer to that was pretty clear to me, and if any of you have spent any length of time as a full time nerd you will probably agree. I do a LOT of TYPING. And because established standards are impossible to break, I’ve done all of this typing on a keyboard with the QWERTY layout. Chances are you have a QWERTY keyboard in front of you, so you can probably just look down to see it. However, here it is for reference:

A Brief History Lesson

In 1867, Christopher Latham Sholes filed a patent for the first typewriter (branded “Type Writer”). It worked pretty well, except for a small design flaw. When you rapidly pressed two keys that were adjacent to each other, the typewriter would jam. To combat this, Sholes designed a keyboard layout that placed common letter pairings (like st and th) so that they weren’t adjacent, ensuring this would happen as little as possible. Over the next few years he would refine this layout until eventually it became the QWERTY layout we are familiar with today.

That’s all well and good, except for the fact that this happened almost 150 years ago. Unfortunately, like the incredibly nonsensical system of imperial measurements, some things just stick. In a world where keyboards no longer have an issue with jamming, surely there is a better way!

Enter Dvorak

In 1936, Dr. August Dvorak decided to do something both logical and unprecedented – design a keyboard layout that made ergonomic sense. He studied the way people used their hands, as well as looking at letter frequency in the English language, and came up with the layout seen here:

This layout is designed for keystrokes to alternate between hands as much as possible (because that’s faster and more natural), for people to do slightly more typing with their right hand (because most people are right handed), and for your fingers to move in an inward motion (rolling from pinkie to index is far easier than index to pinkie. try it). It has gained some notoriety among the tech world, but hasn’t ever gotten any kind of widespread adoption.

Also, some guy named Coleman

Because there’s nothing I enjoy more than researching interesting things, I discovered another much newer keyboard layout, released in 2006 by Shai Coleman. It’s called Colemak based on the Unix->Linux naming scheme – that is, take your inspiration’s name (Dvorak) and splice your own name into the front of it (Coleman). It was intended to be an improvement to Dvorak, based on a few differences in their design philosophy. I will quote this from the Colemak website, rather than present it as my own opinion.

“Dvorak achieves significantly higher hand alternation in the expense of higher same-finger ratio, imbalanced hand load, heavy strain on the pinky, and less handroll combos (multiple keys hit on the same hand with one comfortable movement). Colemak wasn’t designed with hand alternation as a top priority.”

While I don’t personally see this as a benefit, the Colemak layout also doesn’t differ as dramatically from QWERTY as Dvorak does – only 17 keys are displaced, rather than 24. Still, that may make it easier for me to learn, and I’m all for that.

Here it is:

Decision 2011

Conceptually, I agree with the principles set forth in the Colemak layout, and I have read some statistics (various sources) that among the three keyboard layouts, Colemak is the most efficient in terms of finger movement. Also, since my RSI is in my right wrist, I want to reduce load on my right hand (especially the pinkie) rather than increase it. With this in mind, I’ve decided to try and switch to Colemak. I imagine it’s going to be quite a challenge, seeing that I have some really serious (~120 WPM) muscle memory for QWERTY, and I’m very interested to see how long it will take me to achieve that speed again (months, I’m guessing). Also, I can’t switch cold turkey since I still have to be productive during this experiment, so I will be moonlighting as a Colemak typist until I feel comfortable with all the letters, and I’m sure that will have a significant impact on my learning speed.

I plan on blogging about this somewhat regularly, although I expect the subject matter will wander between typing and learning in general. I’ve already spent some time with the Colemak home row (the rst and nei keys) and have noticed some really strange things going on in my brain. I’m excited to share them with everyone. Because brains are cool.

Preface: This ended up being half rant, half analysis. Still, I’d love for you to read it and feel inspired to not make things more difficult than they need to be when creating a developer platform.

Recently, I’ve been getting a lot of work making Facebook Pages for companies. More specifically, I’ve been developing tabs for the sidebar of their pages – essentially small websites inside of Facebook. Since February of 2011, Facebook recommends these pages to be built with standards compliant HTML, CSS, and Javascript, rather than the proprietary FBML (Facebook Markup Language, the cocky pricks) they’d been using before.

My thoughts: “Great! I already know how to build things in HTML, CSS and Javascript.”

Conceptually, this is a great idea. You build the page with technology you’re familiar with, host it wherever you’d like, and all Facebook does is embed your page in an iframe. Even in practice, the process is mostly smooth.

Unfortunately, I felt the need to emphasize “mostly,” and that means it wasn’t totally smooth. I ran into a few issues that fall into two categories. 1) Facebook’s confusing navigation, and 2) Facebook’s strange development decisions.

Confusing Navigation: Adding the app as a tab on your page

The instructions on Facebook’s developer documentation seem pretty clear about how to add the app to your page. It simply says “Facebook Page administrators can add your app directly to their Page by navigating to your app’s Profile Page and selecting ‘Add to my Page’”. Short and sweet. They even give you a screenshot of your app’s profile page with an arrow pointing to the link. “What’s the problem here?” you might be wondering.

The problem is a HUGE red herring thrown at you by the Facebook app creation process. When you create your app, you have to give it a name and a url (http://apps.facebook.com/example). One would naturally assume this URL was your app profile page, but that would be too easy. In fact, by default that URL brings you to Facebook’s 404 page.

Now it’s time to play a game called “what would you click on?” Looking at the page to the left, where would you click to try and find your app’s profile page after discovering that the obvious solution is the wrong one? If you answered “Edit Settings,” congratulations! You understand how to navigate confusing websites! Once you get to the “Edit Settings” page, on the bottom of the sidebar in a section labeled “related links” (which is something I’ve trained my brain to avoid, “related” often meaning “paid to be here”), below View Insights (what?), Promote With an Ad, and Translate your App, is a link to “View App Profile Page.”

Phew.

Fortunately for the future of Facebook app development, the “create a url” option has entirely disappeared, and its data has been put in a new field called “App Namespace” which you use to access their API (confusingly, called the Graph API. I ignored it for hours while looking for Facebook’s API, assuming it had something to do with creating graphs). Evidently Facebook didn’t know what it was for either.

Confusing Navigation: Choosing which page visitors land on by default

It’s time for another game of “what would you click on?” Looking at the navigation on the left, where would you go to choose what tab your users saw first when they visit your page.

A few logical answers:

• Your settings
• Basic information
• Featured

An illogical, but correct answer? Manage Permissions

Now, I understand that there’s a lot of options and you can’t possibly come up with a 100% self explanatory tab for each of them. However, did anyone stop to think for a moment how completely irrelevant “Manage Permissions” is to the page you want your visitors to see first? It’s not like this is a complex development task and they stuck it on a general settings page because they got lazy. In fact a general settings page would be better. Anything but Manage Permissions.

WTF Development Decision: Your app is a maximum of 800px high before . You can only remove this limitation with Javascript.

WHAT?!

There’s so many things wrong with this. Maybe I’m not being creative enough, but I can’t imagine a situation where you would want scrollbars inside your app (that is, in addition to Facebook’s scrollbars). It feels to me like having to specifically ask for utensils at a restaurant because you can eat some of the food on the children’s menu with your fingers. Wouldn’t it make more sense for the iframe to stretch to the size of its contents rather than being fixed at 800px high? It’s not like 800px is some kind of magical number on Facebook either, since both of its sidebars are taller than 800px most of the time.

There’s an easy solution to this problem, but it’s still more complicated than, say, not having to do it at all. There’s an option to make your app “auto-resize” rather than “show scrollbars,” which sounds like it would be enough, but it’s not. You also have to import a 143kb Javascript file, run a function at the head of your page, and run a function at the foot of your page.

I’m not saying that’s difficult. What I am saying is there’s absolutely no reason for it to be necessary. What designer would voluntary choose to have two sets of scrollbars on their page, completely confusing everyone whose mouse happens to hover in the wrong place at the wrong time? And it’s not like Facebook is exactly lightweight as it is, but a 143kb download just to remove unnecessary scrollbars? WHY?!

Conclusion!

The illustrious and inspirational Aral Balkan said it best in his talk at Future of Web Design NYC 2010: “At the very least, don’t infuriate the user.” Since I’ve just written an angry blog post about it, Facebook has utterly failed to do so. The thing is, when I first learned that you could make Facebook apps with the standard web stack I was legitimately excited to do so. As the process went on, my excitement turned to confusion, and then to frustration. The actually building of the app couldn’t be easier, but there’s a real problem when even the most simple integration requires the Googling of solutions.

There’s something magical about finally getting the opportunity to use a new technique you’ve been reading about for months. Since CSS3 has been all the rage for a while now, I’ve heard a lot about how powerful the border-image property can be but I’ve never really had an opportunity to put it to use.

Then, along came this design:

Immediately, my first thought was “how the hell am I going to make those tabbed boxes?” If the size was fixed it would be simple to add it as a background image, but they have to stretch horizontally AND vertically. So, I did what any good geek does in 2011; I tweeted about it.

“Web devs,” I asked, “I need some help. What’s the best way to implement these tabbed boxes with CSS?” Instantly, a wild Jenn Schiffer appeared, linking me to her excellent blog post, explaining how to make a variable-sized wooden frame with border-image. The problem was, the frame she created in the blog post had an equal width on all sides, and it framed the content entirely. We hacked at it for an hour or so, and these are the steps that led us to my final, working, awesome code.

Step 1: The Basics

<div class="boxModuleBorder">
     <p>...</p>
</div>

.boxModuleBorder {
    border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    -moz-border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    -webkit-border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    border-width: 15px 37px 15px 104px;
}

The first challenge was simply to get the box with the tab to appear at all. Border-image requires you to have a source image that contains all the elements you want to use (kind of like a sprite). Then, you pass four values to border-image that slices it into 8 pieces – the 4 corners that will stay fixed, and the 4 sides that will stretch. Here is the actual image the site uses. Blown up and sliced, this is how the browser sees it:

In order to make the slices show in their entirety, the border-width also has to be set to the same value. This is fine when you’re making something like a frame, but in this case, the text technically needs to go “over” the border. This is how it ended up looking:

Step 2: Making it useful

<div class="boxModuleBorder">
    <div class="boxModuleContent">
        <p>...</p>
    </div>
</div>

.boxModuleBorder {
    border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    -moz-border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    -webkit-border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    border-width: 15px 37px 15px 104px;
}
.boxModuleContent {
    margin: -7px -30px -6px -97px;
    position: relative;
    height: 100%;
}

In order to offset the gaps around the text created by the width of the border, we came up with a content div inside the border that uses negative margins to offset the exact amount of spacing created. The exact values of -7, -30, -6, and -97 just came with some experimenting because I needed to find what would offset just the spacing and not the entire border image. The end result was text tucked very snugly against the border, which was exactly what I was looking for. These boxes were intended to hold many different kinds of content, and their padding was significantly varied. I subscribe to Nicole Sullivan’s excellent “object oriented CSS” principles, so there will eventually be many “subclasses” of this module element that determines the behavior of the things inside.

This is the box after adding the content container:

Step 3: Matching the Design

<div class="boxModuleBorder">
    <div class="boxModuleContent">
        <h1 class="boxModuleHeader">Lorem Ipsum</h1>
        <p>...</p>
    </div>
</div>

.boxModuleBorder {
    border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    -moz-border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    -webkit-border-image: url('/images/blue-box-border.png') 15 37 15 104 repeat;
    border-width: 15px 37px 15px 104px;
}
.boxModuleContent {
    margin: -7px -30px -6px -97px;
    position: relative;
    height: 100%;
}
    .boxModuleContent p {
        padding:15px;
    }
.boxModuleHeader {
    background-image: url('/images/gradient-header-background.png');
    background-repeat: no-repeat;
    height: 20px;
    border-bottom: 1px solid #1e1e1e;
    padding-left: 30px;
    padding-top: 10px;
    font-size: 13px;
    text-transform: uppercase;
}

In the actual design, the boxes also have a header that’s nestled tightly into the corner. This is where the no-default-padding principle came in handy. The header is simply a heading element (h1 in this case because they wanted to go with the HTML5 model of hierarchy) with a background image containing the gradient and an arrow, and when it was dropped into place it immediately stuck into the upper left corner of the box. Simple, clean, and beautiful.

Also, when there’s only a paragraph element inside the box it’s safe to give it padding, so this is where the whole basic style comes together.

Step 4: Extending

.boxModuleBorder.small {
    width: 169px;
    height: 190px;
    float: left;
}
.boxModuleBorder.footer {
    margin-right: 14px;
}
.boxModuleBorder.sidebar {
    margin-bottom: 15px;
}
.boxModuleBorder.mainContentArea {
    width: 493px;
    margin-right: 15px;
    float: left;
    min-height: 210px;
}

Using the object oriented CSS approach allowed me to create a few quick classes that would easily make the boxes adapt to the various tasks I needed them to do on the site. For example, when there was a box containing the main content area of the site (http://mindsmack.tv/about/) it needed to be a minimum height of 210px to prevent the floated sidebar from wrapping underneath. The boxes were either 1/3 of the page width of 2/3 of the page width, but the ones in the sidebar needed a bottom margin while the ones in the footer needed a right margin. Only a very small amount of CSS was necessary to reuse the boxes in all those different places.

Step 5: Internet Explorer?!?!

html.ie .boxModuleBorder {
    border-left: 5px solid #01224f;
    border-right: 5px solid #01224f;
    border-top: 5px solid #0b5696;
    border-bottom: 5px solid #0b5696;
    border-radius:6px
}

Some of you are wondering: “sure this is nice, but what about Internet Explorer?!” I happen to be extremely lucky in the fact that MindSmack is an awesome client and doesn’t care about full Internet Explorer support on their portfolio site. They were perfectly happy with branded colors but absolutely nothing fancy, knowing what a task it would be to recreate the boxes in IE.

That kind of decision comes from knowing your target demographic, so people, look at your analytics! If you don’t have many IE-using visitors, don’t spend hours and hours perfecting your design in IE. It’s not worth it.

Conclusions

It seems that border-image is absolutely as awesome as people have been making it out to be. Without it, there would be dozens of “non-semantic styling divs of hideousness” scattered throughout the site to get things to stretch this way and that. Hopefully this post will be useful to someone trying to do something extra-fancy with border-image, since it’s really quite counter-intuitive and very-intimidating.

Let me detail a situation that happens to me too frequently when browsing the web.

On Twitter, someone links to an excellent blog post. I read the post and think that I would like to subscribe to this person’s blog. I glance around their site and see no RSS icon. I cmd-F and search for “RSS,” but nothing happens. I cmd-F again and search for “Subscribe” and find a tiny link hidden in the middle of a lot of other sidebar junk. I am relieved but frustrated.

Especially for small blogs like mine (and a few on my “the bad, the good, and some special exceptions” list coming up later in this post), every subscriber is precious. They are the magical gnomes who will read and comment on your posts, even when no one links to them. Please don’t make it hard for the gnomes.

Before I get into some examples, let me clarify a little bit what I am trying to demonstrate. Simply put: if you’re running a blog, it’s important for people to be able to subscribe to your blog. If you make it difficult for people to subscribe to your blog, you’re making it more difficult for your blog to be successful, and the difference is often a few simple design decisions.

Bad: Gizmodo

Gizmodo (as well as the other Gawker sites) is an excellent blog, but it has a horrible information hierarchy in the sidebar. Especially on a news site, subscriptions should be a top priority, but Gizmodo’s design doesn’t seem to take this into consideration.

Take a look at the screenshot on the left. They have a lot of great stuff at the top of the page – a popular posts section, a huge tips box, and a giant flash ad that probably nets them a lot of money. The top of the sidebar is another giant ad that also probably nets them a lot of money, and that’s okay. If it wasn’t for ads, most sites wouldn’t be able to survive.

The problems begin for me when you start looking for the feed link (which, of course, is what this post is about). For how important subscriptions and syndication are to a news blog, a “Subscribe to Gizmodo” link should be prominently featured in the header if at all possible. I would actually put it (and their other social media presences) underneath the Gizmodo logo in the black bar, but it’s not my decision to make.

Instead, you have to scroll an absolutely ridiculous 2819 pixels before you find “Subscribe to Gizmodo” and a very small RSS icon that you have to click (the text is not part of the link. nice). It is underneath the INTERN’S EMAIL ADDRESSES. I’m sure Casey Chan, Christina Bonnington, Adam Harris, and Andrew Tarantola are great people, and their internships are really cool, but emailing them isn’t a top priority to Gizmodo readers.

Here’s a nice composite screenshot showing exactly how far down the page 2819 pixels is.

Bad: MacRumors

MacRumors is definitely a site that benefits from RSS subscribers. Look at those navigation tabs! They’re very “Webmonkey” circa 2001.

This isn’t a design critique, however. MacRumors happens to have pretty good information and I often see their articles get picked up by Gizmodo, a fellow RSS offender. Similarly to Gizmodo, if I want to subscribe to MacRumors’ RSS feed I have to scroll down a whopping 2338 pixels. In fact, their “RSS/XML” link (which may confuse their visitors who don’t realize an RSS feed is actually just XML) is underneath a link to SETI @ Home and Folding @ Home. I’m all for the Search for Extra Terrestrial Intelligence and their distributed computing program, but it’s not more important to MacRumors than their RSS feed.

This is how far down the sidebar the RSS/XML feed links are.

Bad: AppStorm

I was debating whether or not I should include Mac.Appstorm in the “bad” category, but I specifically remember being confused by it. They do a really good job of hierarchy by putting their social media links and RSS feed link at the top of the sidebar in a nice offset box.

Unfortunately, they also do a really good job of designing their feeds box to look just like an ad in their sidebar that is otherwise entirely dedicated to advertising. Because of its position with relation to the post title, my eye enters the sidebar at the Chronicle and CleanMyMac ads and I immediately dismiss everything else in the column as ads also. It doesn’t hurt that the box has the same blue gradient, the same white text, and the same kind of colorful graphic.

Although the issue here is mostly the surrounding content, it doesn’t help that the actual RSS link is very small white text. There’s no trace of the iconic orange RSS Feed logo. If you’re going to make the text link hard to find, at least make sure the very noticeable logo is there to catch the user’s eye.

Good: CSS Tricks

I can’t say enough about how much I love the newest CSS-Tricks design. There are so many little design and animation treats that I find myself exploring the site just to find all the nice touches Chris Coyier put into it.

One of the things I particularly enjoy is the way he handles the subscription links. There are multiple feeds on CSS-Tricks to subscribe to, but there isn’t a clutter of eight feed links, and there isn’t a page entirely dedicated to feeds. Instead, there is a shaded box at the very top of the sidebar with the iconic RSS icon and a bold “subscribe now.” If you’re looking for it, it’s impossible to miss. If you’re not looking for it at the moment, you still realize it’s there.

Good: The Design Gnome

I promise I didn’t include this one purely because its mascot is a gnome.

The Design Gnome is a web design blog run by talented young designer Max Luzuriaga. This design perfectly illustrates the point I was making at the beginning of this post – if you’re site is a blog, make it easy to find the RSS link. There is a giant orange RSS button in the header of every page. That’s pretty hard to miss. There’s not really much else to say.

Other: Discover Magazine

Discover Magazine has an interesting dilemma – their design uses “RSS Orange.” That means they can do an excellent job of placing the RSS link, with the logo, in their top navigation, and still have it entirely overlooked. I think in order to overcome this issue they need to do something to make it stand out. They could make the font and icon larger or offset the link from the rest of the navigation, but especially on a site with so many feeds to subscribe to (I highly recommend Bad Astronomy), it’s really important that people find that page.

Other: Aral Balkan

I didn’t actually need to include a screenshot of Aral Balkan’s site because my point is about the absence of things, but I did anyway because it looks really nice. Aral is a wonderful User Experience designer who has inspired a lot of my interest in the field, and you should pay attention to everything he has to say.

Interestingly enough, Aral’s site doesn’t have a link to his RSS feed. When I mentioned this to him, he told me that it was a deliberate decision because of the browser’s ability to include an RSS feed link in the location bar. Unfortunately, Google Chrome does not currently have this functionality by default. There is an official extension written by Google to add it, but no extension is ubiquitous.

Hopefully Aral’s solution to this problem will be practical and ubiquitous in the future. If everyone can use their location bar to subscribe to blogs, it would eliminate this issue entirely. For now, though, you can’t be sure what shortcuts users will have available to them. So please, if you’re going to have a blog, put your RSS link where your users can find it.

I’ve been working on this story for the past few months as an assignment for a fiction writing course I was taking. Now that it’s finished, I thought I might share it here. I’ve included the first 2.5 pages, and at the bottom you can download a PDF of the story in its entirety (12 pages total). Feel free to leave any comments or criticisms (I can take it!), I’m always open to more revising.

If you’d like to read the rest, you can download it here:

Recursion-by-RyanGiglio.pdf

Enjoy!

I know I’m late weighing in on this issue, but I’ve been thinking about it for a while. Google Instant is a very cool idea and I really don’t want to dislike it, but its frustrated me enough times that I finally turned it off.

Pros and cons, shall we?

Pro: Instant feedback can be very useful

For situations where you aren’t exactly sure what to type in, instant feedback on your query is very useful. For example, the other day I was searching for the exact meaning of the phrase “canon,” since we were discussing it in a writing class and I like dictionary definitions. Searching for “canon” gives me nothing but cameras, but a few quick search refinements with Instant’s help led me to “literary canon” which was exactly what I was looking for.

Con: When I don’t need instant feedback (which is most of the time) it’s very annoying

Generally my Google searches are pretty straightforward and don’t require a lot of refining. I shudder at the phrase “touch typist,” but since I look at the screen rather than the keyboard while I type, I find the page’s automatic search results very distracting and quite annoying. For example: say I’m trying to search for the “screenplay for Toxic Avenger Part 2.” Typing at my normal speed (pretty fast, I am a programmer after all) the page gave me four incorrect auto-completed results before I was finished typing. When I slowed down just a little bit (a totally reasonable speed for the average person), it gave me eight different pages of results before I was finished.

This is what it came up with; it sounds like one of those Bing TV ads. You can click the term to see the results page.

• scrabble
• screenplay
• screenplay format
• screenplay for inception
• screenplay for toy story
• screenplay for toxic
• screenplay for toxic avenger
• screenplay for toxic avenger part 2

If you look at the images you’ll notice not only do the results change, but both sidebars change also. Sometimes there’s sponsored links, sometimes not. Sometimes the left column of search types includes 3 things, sometimes 4, sometimes 5. Seeing the content and structure of a page change eight times in a few short seconds, all while you’re concentrating on typing, is very annoying.

I understand that the point of Google Instant is to get results faster, but when the scenario above occurs, it feels to me like I’m getting them slower. There’s no way to scientifically test these millisecond differences, but feel is often more important than science. With Instant disabled I’m certain that the search performed is the search I had intended to make. However with Instant turned on I find myself reading the results over before I trust that they’re what I was looking for. On my painfully slow internet connection, it’s happened more than once that I’ve finished typing while a previous auto-search was still being displayed, and I had to wait for it to update.

Con: It’s very aggressive.

This is the nature of auto-complete, and I think as far as text input is concerned Google does an excellent job with this – press enter if you want to search for what you typed, press tab if you want to use the auto-completed word. However basing the auto-search results on the phrase they think you meant often defeats the purpose of using Instant. For example:

Say I want to search for “fire.” If I type in “fire” it tries to auto-complete it to firefox. As I mentioned, all I have to do to search for “fire” is press enter, but if I’m pressing enter at the end of my search results and some of the page has to reload, why am I using Google Instant at all? It would seem like this is a picky issue to take with it, but it’s happened to me enough times that I think it still deserves mention.

The funny thing is, most of my Google searches are done from Alfred (which every Mac user should use because it’s awesome) or the location bar of Google Chrome. Me and Google Instant don’t really rub elbows all that often. When we do though, it rubs me the wrong way.

When a user arrives at a webpage, there a number of assumptions they immediately make. For example:

User: “There’s a big logo at the top. That must be the name of this website.”

Obviously this is subconscious; no user would go around the web repeating that to themselves. Try it. It gets old fast. The point is, we’ve grown extremely accustomed to certain design patterns. One of these is having the site/company/individual logo and branding at the top of the page. Another, even older, is having your navigation at the top or down the left side of the page. When a user sees a list of links in one of these two places, they automatically assume it will lead them to new and exciting places.

Of course, all of this is common sense. As web designers and developers, we all know this information. That’s the point.

When a designer does something that drastically breaks this pattern, people have one of two reactions. Typically these get vented on Twitter:

User A: “Wow, (site here) is really outside the box. Brilliantly creative. 5 stars #loveit”
User B: “Wow, (site here) is really trying too hard to be outside the box. What happened to usability? #badUX”

Neither of these reactions is necessarily a problem; many people react negatively to change without thinking about it first. However, a lot more confusion can come from sites where the paradigm is only broken slightly. Take this conversation I recently had with myself when visiting this site:

*looks at the navigation at the top of the page*
“Oh, great. There’s 3 pages on this site. Let me read this one first, and then go to the others”

*reads all the way to the bottom of the page*
“Alright, I’m done with this page. Let me go to the others now”

*clicks on navigation. page scrolls me down to a section I already read*
“Wait, what? Oh. Damn”

And I leave the site disappointed. I don’t think it’s in anyone’s best interest to disappoint our users, especially when they’re interested in your content enough to want to read all of your site.

There’s absolutely nothing wrong with an everything-visible-on-one-page site. If you don’t have a lot of content, there’s no need to make the user go to three different pages to read three paragraphs. If you want to do some creative design to tie all the sections together, go for it. However, if you’re not doing anything else radical on the page, don’t change the navigation paradigm without telling us. Something as simple as a “jump to section” note next to the links is sufficient to tell the user “these links scroll you down the page, not take you to a new one.” That’s all they need to know.

Note: Thanks Kevin Fricovsky for letting me use the screenshot.

Update:

The official site of Alfred (which I happened to link to in my blog post about Google Instant as well…I’m really giving them some love) has a fantastic execution of what I complained about here. Their site is all on one page, yes, but there is a distinction between the different sections as you scroll down, especially between the “homepage” section and the “features” section. It’s clear both by the large heading and the drastic color shift from Purple to Grey that you are in a different section of the site. This successfully discourages the pattern of “read the entire page before clicking the nav links.” Well done, Alfred team.