by Rob Larsen
I’m a big fan of the Graded Browser Support table from the fine folks at Yahoo! It was the official foundation for our browser support policy at Cramer and I still look to it now for hints into what one of the most mass-market of all sites thinks about the browser landscape.
Read the rest of this entry »
by Rob Larsen
We’re hiring in my group.
Cool, right?
So, I’m once again interviewing. Yay me.
Since I’m no longer running a group I don’t have to worry about any of the administrative type things (“this is what the company is about,” “this is what we do,” etc.) That’s good as it just allows me to test people on technology. That’s really my favorite part of the interview process anyway. Win.
The following is a tiny snippet I’ve been using to test people’s knowledge of JavaScript fundamentals.
Why share it here? For one thing it’s kind of interesting to me since it’s a very small snippet but it can expose a lot about the way the person approaches the language. Basically, if you can get this and you’re still pretty inexperienced you’ve probably read a book, taken a class or read a blog post or article written by someone smart. That’s a bonus.
And then there’s the Easter Egg part. Meaning, I’m still going to be using this going forward with the answer sitting right out here in the open. Why?
Here’s how I see it. If a candidate:
Read the rest of this entry »
by Rob Larsen
We continue with our examination of CSS with some real basics- formatting, writing rules, organization and the like. Nothing groundbreaking, but the basics are important in any endeavor, so here they are.
During development I format my CSS with selectors on one line and then each property on its own line. The declarations are indented 4 spaces. I like this style because my interest is always in the properties, not the selectors. I can find any selector I need with CTRL+F and then I can easily scan down the list of properties to do my business.
It looks like this:
Read the rest of this entry »
by Rob Larsen
One of the most important things in CSS is understanding the way rules are inherited and applied in the browser. This is one of those things that many developers “get” intuitively but don’t necessarily understand at a granular level.
There’s actually an algorithm, so if you’re stumped, you can actually count it out. It works like this:
by Rob Larsen
One of the reasons I’m drawn to the performance side of the business is that it’s one of the few pieces of of your site or application where you can really know when you’re doing the right thing.
There are a lot of questions that can run through your head during a site build. Is the design right? How about the feature set? do these labels make sense? Is the language correct for my audience? Does this visualization truly illustrate the underlying data and add meaning? Was I right to use canvas? Should we be using web storage?
Those (and many other examples) are the things that can (and should) your thoughts. You can leverage experience and best practices throughout, but there are always mistakes, miscommunications and surprises waiting around the corner, so sweating the details of a design or interaction model can make or break an application.
One aspect that brings a little bit of certainty is the question of speed.
The site is either fast, or it isn’t.
There are certainly degrees of “fast,” a full featured application won’t be as fast as Google.com, but once you’ve defined a speed goal there are plenty of ways to know if you’re hitting your marks which makes it a bit more satisfying than the stuff that’s a little more nebulous (or takes a little longer) to measure.
by Rob Larsen
We’ll finish up our tour of the body tag with several posts featuring general notes about common content elements. I’ll be taking my time with these as getting this stuff right will go a long way towards getting the most out of your site.
Comfy?
On with it then.
The link is the engine of the web. The concept of Hypertext (the H in HTML) itself is expressed in the power of the link. Google is Google because of the power of links. There is no better place to start.
<a href="http://www.drunkenfist.com/"
class="contact"
title="my personal site"
rel="me">DrunkenFist.com</a>
For body copy you want to write link text that is descriptive of the link destination. generally this means a short phrase (5-10 words, depending on who you ask) that clearly describes the link. For that reason “click here” is generally not the greatest link text. For a live example and more on this topic take a look at link chapter of the the US Government’s Research-Based Web Design & Usability Guidelines. It’s full of really interesting tips on handling links.
For the SEO-minded, the above advice has the added bonus of generally including keywords which flow link juice and context to the targeted page.
Read the rest of this entry »
by Rob Larsen
The body is clearly going to take a while, since it contains all of the content on the page. I’ll be breaking it out into chunks. This first post will focus on how I use the body tag itself.
I generally use the body tag to hold basic information about the page to use with both CSS and JavaScript. I want to capture the general type of page (home pages, landing page, gallery page, tertiary page, form page) and then the style of the page within the general type (e.g., art, movies, blog.) Coming up with a good, logical scheme for this kind of thing can generate plenty of unexpected benefits throughout a site build.
It can also help with planning as these classifications can be used as part of the estimation process- “I’ve got 5 major templates and 10 variations, that’ll be 2 weeks of work.”
Here are some examples from the ongoing redesign of DrunkenFist.com. These might help to crystallize what I’m trying to do.
Read the rest of this entry »
by Rob Larsen
There’s a lot of content this week, including about 5 hours of video embedded right in the page for your viewing pleasure. Enjoy.
Peter Merholz from Adaptive Path talks up analytics. Don’t I feel like a smart guy with all my fancy analytics experience?
That’s probably something I don’t talk enough about here- analytics. I’ve got a ton of experience with both Omniture and Google Analytics, doing some pretty advanced work. I should share that.
Anyway, good article talking about the UX benefits of analytics data. Check it out.
This is a little resource page from one of the WordCamp Boston Ingite talks. WordPress Short Codes are clearly awesome and I don’t use them enough. I aim to change that.
I’m actually using them for the table of contents on my ongoing How To Make a Web Site series.
Read the rest of this entry »
by Rob Larsen
Last time out we looked at the Anatomy of a Web Page. Using that, let’s move on and look at the first of the two major sections, the head.
For the sake of this blog post, the head includes two pieces of code that are actually before the head. Sue me 
Using the head from my (recently updated) starter assets project as an example, let’s look at the code in detail. First, what it looks like in total:
Read the rest of this entry »
by Rob Larsen
Okay, okay… I’m guilty. The title is provocative and slightly misleading. I do care about developers. Developers are my people and I want nothing but the best for them.
That said, when I’m sitting down planning a site, application or component, my first thought isn’t about making things easier for developers. It’s about making things easier for users. If I can do both, great. The world is just that much nearer to perfection. If not, whenever possible I’m going to err on the side the user by trying to make the site they see better/stronger/faster.
(well, maybe not stronger…)
That’s why I cringe when people enthuse about how easy something was to implement.
“That was great. I just had to write two lines of JavaScript and I’ve this cool Ajax component.”