I’ve written a good amount of articles, given a bunch of talks, taught a couple classes, and have even written a book. All accomplishments over the course of my 8 years as a Designer/Developer that I’m proud of, but probably not for the reason you might think. I don’t do it for Twitter followers, Facebook likes, a high Klout score, applause, Feeburner stats or even book royalties (believe me, there aren’t many). I do it to educate, improve to and give back to a community that we all take far too much from. At this point, I bet there are some folks calling BS.

Most of us have used systems, frameworks or libraries on projects that build up portfolios, which ultimately lead to better career paths.

A few years ago when I moved to LA (I’m in Boston now), I was at a party talking to someone who had been there much longer than I had been. He said to me, “Everyone who moves here wants something from someone, what do you want?” It made me think for weeks and I never came up with anything, because, what do I want from someone? Nothing at all, just to do my part. I’ve been told it’s weird because no one in an industry like this just wants to contribute for the sake of contributing – it doesn’t get you anything, trust me. Don’t get me wrong I want my name on my work like anyone else, but very often at the end of a talk I will offer up my presentation slides to anyone who would like to pass the information on. The focus is education; I’ve said before that building Web sites isn’t a noble profession, and I still mean it. There isn’t a whole lot we can contribute to the world, but we can, at the very least, help the free transfer of information the best we can.

Don’t tweet to be retweeted, it’s douchey and worst of all, transparent.

Read the full article

Read the full Article

Hey all, I realize I don’t post all that often any more, but I have a bit of an event coming up that I thought might be noteworthy enough for a blog post.

About 9 months ago I was approached by Pearson Education to write a beginner-level textbook about JavaScript. My first thought was, “oh crap, I need to get a lot better at JavaScript pretty quickly.” Well, I think it turned out to be quite a book with some interesting insight (if I do say so). I was able to write in a pretty casual voice and organize it how I felt the topic should be taught. After pushing through a few chapters I started to realize the value in learning JavaScript from a CSS guy, and I ended up really liking the angle at which I came at the topic.

Anyway, I won’t keep you too long, but the book is coming out tomorrow (maybe today by the time you read this) and will be available on August 5th. It’s called: “Learning JavaScript: A Hands-On Guide to the Fundamentals of Modern JavaScript” and it’s discounted pretty well right now.

Where you can buy it:

• Amazon (also for Kindle)
• Barnes & Noble (also for the Nook)
• I’ve heard that it’ll be on iBooks as well, but I don’t have the link yet.

If you want to learn JavaScript from a CSS guy, I hope you give it a read. I think a lot of us came into JavaScript from the CSS angle so I imagine it may be easy to connect with a lot of the topics. If you pick it up, first off, thank you and please let me know your thoughts. I’m definitely interested to hear thoughts on my first attempt in passively educating the masses.

The Description from Amazon

With the arrival of HTML5, jQuery, and Ajax, JavaScript web development skills are more valuable  than ever! This complete, hands-on JavaScript tutorial covers everything you need to know now.  Using line-by-line code walkthroughs and end-of-chapter exercises, top web developer and speaker Tim Wright will help you get results fast, even if you’ve never written a line of JavaScript before.

Smart, friendly, enthusiastic, and packed with modern examples, Learning JavaScript covers both design-level and development-level JavaScript. You’ll find expert knowledge and best practices for everything from jQuery and interface design to code organization and front-end templating. Wright’s focused coverage includes regular break points and clear reviews that make modern JavaScript easier to learn—and easier to use!

Learning JavaScript is your fastest route  to success with JavaScript—whether you’re entirely new to the language or you need to  sharpen and upgrade skills you first learned  a decade ago!

Table of Contents:

Part I. Welcome to JavaScript

1. Progressive Enhancement
2. JavaScript in the Browser
3. JavaScript Terminology

Part II. Coding with JavaScript

4. Accessing the DOM
5. Interacting with the User Through Events
6. Storing Data in JavaScript
7. Variables, Functions and Loops
8. Ajax
9. Code Organization

Part III. Taking JavaScript to the Next Level

10. Making JavaScript Easier with Libraries
11. HTML 5 JavaScript APIs
12. Moving Forward with JavaScript

One of the principles we build sites by is to never resize an image in HTML but rather size the image appropriately in Photoshop, Fireworks, or whatever you use. We do this so the user doesn’t have to waste bandwidth by downloading a larger image than is necessary for the situation. Sounds great right? Totally reasonable.

When media queries and responsive design began to get heavy traction images started to present a real problem because using a single image on a large screen with high bandwidth didn’t necessarily work on a small screen with low bandwidth (let’s face it, we’re talking about a phone here). Using a single image makes sense in theory, but maybe not so much in practice. The famous Boston Globe redesign was the first (notable) site to try and tackle this problem on a large scale. I’m not exactly sure why it’s apparently ok now to resize image with CSS, but still bad to do it in HTML, but that seems like a topic for another day.

I won’t get into the specifics about how they did it because I heard there were a lot of problems with the method (and I forget exactly what went on). The important thing that came out of successes and failures of that project was that it kick-started the discussion about what exactly we should do to deal with this image (or really asset management) problem.

Scott Jehl came up with an interesting solution via the picture element. While I don’t think inventing new standards is quite the answer, the method seems sound.

The Detection Stack

When I’m building a site I can generally boil an interface down to a couple detection points:

• detect screen size to modify the design
• detect for touch capabilities for modify the interface

I’d like to add one more to that: detect bandwidth level for asset management.

Detecting for Bandwidth

The focus of image loading, so far has been based on image dimensions and screen-size; I think what really matters there is file size and available bandwidth. Just because browser window is small doesn’t necessarily mean it can’t handle a high-res image.

On a recent project I was looking for a way to test online/offline state, I came across Using navigator.connection in Android. Which is a blog post covering the Network Information API.

I built out a simple demo based off the blog post which checks bandwidth and returns another image version. To set up the HTML, we’re using a normal <img> tag and loading in the small version of the image incase nothing works, you’ll get the small version:

HTML

<img src="images/small-fella.jpg" data-large="images/large-fella.jpg">

Using the data-large attribute let’s use store the image inside the <img> tag, so it feels more natural.

The JavaScript will check the bandwidth using the network information API, loop through all the img[data-large] and re-set the image src attribute.

JavaScript

(function(){
    
    // initialize some variables
    var connection,
        connectionSpeed,
        images = document.querySelectorAll("img[data-large]"),
        imageCount = images.length,
        i;
    
    // create a custom object if navigator.connection isn't available
    connection = navigator.connection || { 'type': '0' };
    
    // if statement checking for WIFI, ETHERNET or UNKNOWN
    if(imageCount > 0 && connection.type === '0' || connection.type === '1' || connection.type === '2') {
        
        // loop through each image with the data-large attribute
        for (i = 0; i < imageCount; i = i + 1) {
            
            var obj = images[i],
                largeImg = obj.getAttribute('data-large');
            
            // reset the image src to the larger version of the image
            obj.setAttribute('src', largeImg);
            
        }
        
    }
})();

In the demo there’s also a switch statement outputting a string for the connection type. I’m adding it to the HTML, but you could easily add it as a class to the body so it’s globally available and usable with the CSS.

Cool right?

Support

It doesn’t really work anywhere. There are rumors of Android support but I personally testing the demo I built for this write-up on the latest Android OS and it didn’t work. Hopefully we’ll get there soon because I think this a great API.

We’re not heart surgeons, or nurses, or even fire fighters; no one’s life depends on what we do and no one dies if we screw up. I try and remind myself of that fact when I get overly frustrated during a project as it helps keep complaining to a minimum and a little perspective (which is always good).

Yesterday was the first annual Global Accessibility Awareness Day (GAAD) and even though there was only about a month’s notice, cities around the world participated. Obviously, I wasn’t able to attend them all, but I was able to sit in on Boston’s version at The Carroll Center for the Blind, there really couldn’t have been a better venue.

I like to think that the sites and applications I build are as accessible as possible. I mean, it really doesn’t take any time to throw ARIA roles in there and make sure your alt text is meaningful. It’s actually one of my pet peeves when developers/designers take accessibility shortcuts. It’s so easy to dimiss these standards because we so rarely meet the people they effect.

Last night I met some of these people. I watched a visually impaired gentleman navigate New York Times with a screen reader. It was awful. I saw first hand why using “click here” and “read more” are terrible for link text (I had heard about it, but never saw it first-hand). I got confirmation that sometimes it’s best to leave alt text blank and why we leave the attribute empty rather than removing it (screen readers announce the file path if the alt attribute is missing).

Going into last night, I knew a lot about accessibility because it’s been a focal point of my career for years. But there is a huge difference between reading a blog post about Web accessibility and watching a visually impaired person go through 20 minutes of struggling to reach the main content of a Web site you would normally find in under a second if you could see.

I won’t lie, it’s pretty rattling to see folks with actual problems struggle to use a medium that we take for granted. Not just the Web either, we had a fairly full discussion about on-screen TV menus as well. A lot of things, I’ll admit, I don’t really think about in my day-to-day life.

Overall, I think the GAAD event was a great success and I hope it grows for years to come. It’s aways nice to have a reminder that even though we don’t save lives there’s one small part of our jobs that can positively effect the lives of others.

@media screen and (device-pixel-ratio: 1.5) and (device-width: 683px) and (orientation: landscape), screen and (device-pixel-ratio: 1.5) and (device-width: 400px) and (orientation: portrait) { /* css */ }

And that’s not even the whole thing, you still need vendor prefixes to get it to work. This brings me to my point.

This intense form of a media query is getting dangerously close to targeting a specific device, which defeats the entire point of responsive design. It’s all about setting breakpoints, but if your breakpoints get too granular, it’s no better than targeting an iPhone directly. We have starting points because you need to have starting points, something like 800px, 480px, 320px, right? Typical breakpoints for your media queries. We’re missing the mark a little with using them out of the box like that though.

Not to point blame at any boilerplates, I think they’re actually really great to get you started, but when you use them out of the box, you start to get in trouble. They’re meant to be customized. — and wow, at least change that pink highlight.

The intention of breakpoints is to identify points where your design gets a little messed up, let’s say at 600px wide your design gets too cramped. In that case your first breakpoint would be at 600px. It’s different for every design. If you follow that basic model, you don’t have to worry about what a reference pixel for a device is. If the resolution for a device is 800px and your breakpoint is at 600px, it will look at intended. Don’t worry so much, you’re already doing it right.

As some may know, I’ve been writing a JavaScript book and I’ve been studying a lot of the basic history of the Web. Since its early conception we (as a community) have been hacking things together to deal with a device market that is struggling to get its sea legs. Normally what happens is that we’ll have a period of instability followed by developers & designers scrambling to rethink what they do and hacking something together to make it 100%, then it will get standardized and all the work you did to take a project from 95% to 100% is seen as a pile of dirty hacks (anyone remember the war between JavaScript and jScript?).

Now we use something called feature detection, which is a million times better.

When you work in the browser vs. on the server there are certain things you can’t control and you need to manage bottlenecks in the process rather than forcing control over an uncontrollable situation. The devices will do what they’ll do and if you try and plan for them all you’ll:

1. Go insane
2. Go broke purchasing all the devices
3. Create so much extra code that it will be unmanageable
4. Bog down performance
5. Ruin your JavaScript
6. Get to a point where it’s more efficient to detect for a device and serve up new markup on the server (and nobody wants crap that again)

What the moral of the story? I don’t know, stop over-thinking everything. It’s great to explore new stuff, but even better when you can recognize when new stuff isn’t that much better than the old stuff.

Some of my favorite people to speak with about the Web are, ironically enough, non-techies. They’re just normal users, friends, my parents, whomever. Sometimes I just sit and watch them use Facebook (I bet it’s creepy as hell). They give a real insight into the future of the Web; if these people don’t get it, no level of fist banging by “us” is going to make something successful.

We can all see what Google did with Google+: they mashed up the models of Facebook and Twitter and rolled in some Google services that already exist. Facebook with the overall concept and Twitter with the friending model (circles). Don’t get me wrong, I think it’s a great effort and I applaud them for continuously trying to break into the social networking scene but the amount of time and effort they’re putting into the weakest part of their portfolio is mind-boggling. It’s an area that really doesn’t advance the Web at all. Not pushing any boundaries, just re-packaging something someone else had success in.

Google has some of the greatest services on the Web: Docs, Calendar, Gmail, Reader, Maps… the list goes on. Maybe focus on some of those?

I guess I’d like to see some advances in their strengths rather than a continuous focus in the social atmosphere. Breaking down Google +, we have:

• A profile
• Pictures (picassa)
• Circles
• Posts
• Games
• Huddles

I will say that I love being able to have group video conferences (huddle), it’s pretty awesome. I also like the idea behind circles (but dislike the implementation).

Most users don’t care or understand the circles concept, but other than that stuff, what’s the benefit to switching over from Facebook for most people? I don’t see it. It’s a lot of duplicated services: posting, pictures, friending, games, profiles no one reads, etc.

Whether the services over on Google+ are better or not is kind of a moot point because, at their core, both Facebook and Google+ (and Twitter) are broadcasting services. We use them to say “hey look what I did here”. And that’s totally fine. I’m not judging anyone who does that all, I do it myself every time I upload a photo to Facebook or Tweet something out. But the main crutch of a broadcasting service is it’s users and the users just flat-out do not exist in Google+ right now. I don’t see a clear user migration path from Facebook (or Twitter) over to Google+ especially for non-Gmail users.

Yahoo Fantasy Sports

On getting non-Gmail users over to Google+… I think Yahoo Fantasy Sports is a great model to look at for something like this.

I have a Yahoo account. The only thing I use it for is Fantasy Football (I really don’t use Flickr). Why? Because they produced the best (by a mile) service on the Web for that niche. Honestly, no one’s even close, its at a point where I won’t even play anywhere else. I’ve actually had the pleasure of sitting down with their team of developers. They ripped apart my JavaScript worse than anyone I’ve ever seen. It was impressive and humbling to scroll through hundreds of lines of code and have someone point out every missing semi-colon. They’re the best group of UI/Front-end people I’ve ever had the pleasure of speaking with and it really shows in the product(s).

If Google wants users to migrate to +, they need to do what Yahoo! sports did and not only be the best, but be the best by such a large margin that if doesn’t make sense for anyone to use anything else. It takes time, but it can be done. And they’ll need to take some more risks.

Taking on a giant: users

I’ve gone on the record a few times saying that I don’t think anyone is going to take down Twitter or Facebook with a similar application. I think we’ve evolved past that. Looking at all the “Twitter” killers that have come along, many of them were better services, I really liked Plurk; amazing interface. But no one used it. Why? Because no one was on it. Sounds circular, I know. But like I mentioned ^ up there, these are broadcasting services and when there isn’t anyone to broadcast to, what’s the point?

I do think both Facebook and Twitter will fall at some point, I don’t know to whom, but I do know that it won’t be Google+ in it’s current state. There’s nothing over there, the hype is gone and the users are bored (dazed) and confused.

Also, I think they should bring back Wave, it had a lot of potential, just a little too much noise. It could certainly be massaged into something awesome over time.

I’m really wondering what people think about this stuff, so let me know. Tell me I’m wrong.

The talk will be on the Future of HTML5, stuff coming down the line that we have to look forward to. All sorts of wicked goodness right? I’m really looking forward to working with the folks at Carsonified, who always put together a great conference. I personally attended the Future of Web Apps conference in 2010 (or ’09 maybe?), when it was in Miami. It really was the best conference I’ve attended and it’s a great honor to be on the stage this year. The formats and venues are so unique and the speakers are so great and dynamic, it really will leave you wanting more.

They have an amazing line up coming to New York and a crazy-awesome topic list.

My Talk Description

HTML5 is evolving very quickly and staying on the bleeding edge can sometimes feel like a full-time job. In this session we’ll talk about what’s coming down the pipeline, discuss where we’re headed on the Web and dive into some hand-picked topics about the HTML5 hotness you can expect to use in the future.

Kinda awesome right? I love talking about that bleeding-edge stuff, you should totally come.

They’ll also be recording the sessions and I think the videos should be available later on (not sure on the time-frame for that).

Hope to see you there.

The URL is an important piece of user experience in any Web site or application. We like using, what we call “talking URLs” so they’re easy to say and remember, like clearleft.com/is/richardrutter (one of the best all time).

But as we build complex ajax and javascript-base apps with wild interfaces, we sometimes forget about the URL and just how important it is.

The HTML 5 History API aims to deal with that problem by letting you access the address bar directly and create pushes to change the URL and inject (same domain) history into the browser.

Feature detection

Step 1 to using any of the new HTML 5 goodies is testing for support. The History API works where you would expect it to (Gecko & Webkit, not sure about IE9). Testing for support is pretty basic:

Regular JS

if (typeof history.pushState !== "undefined") {
    //history api is supported
}

With modernizr

if (Modernizr.history) {
     // history api is supported
}

The History Push

if (typeof history.pushState !== "undefined") {
     history.pushState([state to track], '[page title]', '[pushed URL]');
}

The pieces

State: This data will be passed into the “popstate”, which deal with things like when the user click the back button.

Page title: This is the title that you see when you click and hold the back button (the menu that pops up) – not totally supported yet

Pushed URL: this is the url you want to display in the address bar. It’s only limitation is that is has to be in the same domain (security).

Worked out history push

if (typeof history.pushState !== "undefined") {
     history.pushState(null, 'I love dogs', 'dogsrock.html');
}

In this demo, you can see the URL changing but the page not reloading.

This is basically a slimmed down version of the Dive in HTML5 documentation with some modifications to the history code, I slimmed down the detection a bit.

As usual, any comments, questions, criticisms are welcome. I left the back button broken so you can see it actually working.