The first is by Jeremy Keith and discusses conditional loading of content for websites designed using Responsive Web Design techniques. The technique Jeremy describes allows you to have one web page for mobile devices and desktop browsers alike, show just the necessary content on the small form factor mobile web browsers, but show additional content for the larger sized browsers too loading that additional website content only when needed. This saves on bandwidth for people viewing your website using a mobile web browser allowing your site to load quickly and not cost them more time or data than necessary.
http://bit.ly/siNiYY

Two solutions to the RWD Image Problem. One challenge when designing using Responsive Web Design techniques is the issue of serving appropriately sized images for different devices. The basic RWD technique is to use the largest images required for any device in the HTML, and just change the scale at which the image is displayed to make it smaller for smaller devices. The problem with this basic approach is that it’s not very mobile-friendly. All devices would be downloading images with large file sizes. This is particularly an issue with mobile devices that are likely to have slower internet connections and caps on bandwidth. Your site will take longer to load than necessary and for users who are paying for every bit of data as they go, downloading all those large images can add up to a substantial penalty.

Techniques continue to be refined for downloading small images for mobile devices and the largest images only when appropriate. Here are two of the latest techniques available:

The first by Matt Wilcox is a server-side solution involving PHP, cookies, and Javascript on the client:
http://bit.ly/uEioLu

The second by Jake Archibald is a client-side only solution with fascinating benefits. But in the words of the author, it’s a dirty, dirty solution:
http://bit.ly/vJlbcy

Check them out and comment. Which method do you like better?

Flash isn’t dead.

I’m feeling personal sadness with the Adobe’s mishandling of the announcement, as Flash deserves an elegant path through the future, whatever that future may be. It was my classmate at Harvey Mudd College ’89, Jonathan Gay, who invented Flash. Jon wrote the application SmartSketch which was published by FutureWave Software, founded by Jon and Charlie Jackson. The product eventually evolved into FutureSplash Animator. In 1996, FutureSplash was acquired by Macromedia and released as Flash. Flash was acquired by Adobe Systems in 2005 when they purchased Macromedia. [Historical references excerpted from Wikipedia: http://en.wikipedia.org/wiki/Adobe_Flash]

Jon is a wonderful and brilliant person (he put himself through Harvey Mudd College in part by programming Dark Castle – remember that one? Yeah, that was Jon too). I would argue that Flash was an incredibly innovating influence on the World Wide Web and has touched nearly everyone who uses the web. As a browser plugin, I’ll bet it has been the most widely adopted plugin in history and may retain that title for some time. Flash provided a stable solution to cross-browser problems when those were the biggest problems facing website designers and developers. Useful, powerful, and innovative, Flash is a tremendous achievement. Flash and Jon deserve tremendous respect.

So what’s really going on with Adobe and Flash? Mike Chambers of Adobe wrote a clarifying blog post to answer that question: Clarifications on Flash Player for Mobile Browsers, the Flash Platform, and the Future of Flash.

My summary of Mike’s blog post:
– Adobe is discontinuing development of the Flash Player for mobile web browsers only
– Flash will continue to fix bugs and support existing versions of the Flash Player for mobile browsers
– Adobe is continuing development of the Flash Platform for desktop web browsers
– Adobe AIR will continue to play a central role in mobile app development
– Adobe Flex will continue to exist and be developed for the indefinite future, but in a different environment

Without a doubt Adobe should have framed things much differently. Perhaps Adobe could have written a manifesto describing where they saw the future of the web going and exactly how their products would fit into that future. HTML5 has a major place in the future of the web, and Adobe is adapting to that reality in very effective and realistic ways.

Flash is incredibly powerful and capable. There really isn’t anything else out there that can do all Flash can do. HTML5 and CSS3 are several years away from “replacing” Flash. Those newer technologies can handle some of the simple things Flash has been able to do for more than a decade, but they are no where near the whole package yet. We’re in a transition period between the Flash era and the dominance of HTML5. As a web developer I’m extremely excited about HTML5, CSS3, and Responsive Web Design. We are working in those technologies every day. The future is very bright. I’m just sad that a leader like Adobe stubbed it’s toe and is now bleeding on the map that shows the path from Flash to HTML5 and newer technologies.

Mike Chambers’ post is a bandaid intended to help stop the bleeding. Though it’s long, it’s well written and explains Adobe’s position fairly clearly. Below are some key excerpts, the full article can be found here.

Excerpts from Clarifications on Flash Player for Mobile Browsers, the Flash Platform, and the Future of Flash:

First, I want to make it very clear that we are continuing to work on Adobe AIR for mobile applications, and have seen an increasing number of successful applications created with Adobe AIR. What we are halting is further development on the Flash Player plugin for mobile browsers. We will continue to provide critical bug fixes and security updates for existing device configuration, as well as continue to distribute the current player. At the same time, we are further increasing our investment (both in resources and engineers) in HTML5. I am not going to go into too much detail on this today, but, in general, we are shifting some resources from the Flash Platform and towards HTML5.

[…]

What does this mean for the Flash Platform in General?
While there was some frustration around our dropping development of the Flash Player for mobile browsers, the main thing I saw was concern and confusion about how this would affect the Flash Platform as a whole. Were we still committed to it? Would we stop developing the Flash Player for the desktop? Is Flash really dead?

So, just to be very clear, contrary to what many have declared, Flash is not dead. It’s role and focus has shifted but we feel that it still fills important roles both on the web and mobile platforms.

Adobe AIR
We are continuing to develop Adobe AIR for both the desktop and mobile devices. Indeed, we have seen wide adoption of Adobe AIR for creating mobile applications and there have been a number of blockbuster mobile applications created using Adobe AIR. Some recent examples of applications created for mobile devices using Adobe AIR are Machinarium, Watch ESPN and my personal favorite, tweet hunt.

Flash Player for Desktop Browsers
We feel that Flash continues to play a vital role of enabling features and functionality on the web that are not otherwise possible. As such, we have a long term commitment to the Flash Player on desktops, and are actively working on the next Flash Player version.

Of course, with the growth and continued improved browser support of HTML5, the role of Flash will change. We feel that for the foreseeable future, Flash is particularly strong in delivering advanced video, as well as providing a robust, and graphically rich gaming platform. We are focusing our Flash Player efforts around these areas.

[…]

The key point is this. If a Flash feature is successful, it will eventually be integrated into the browser, and developers and users will access it more and more via the browser and not Flash.

A lot of the things that you have done via Flash in the past, will increasingly be done via HTML5 and CSS3 directly in the browser.

I am not suggesting that all Flash content should or will be done in HTML5. You have to look at each project on a case by case basis and make a decision based on development costs, target platforms and user experience. Regardless, your customers are going to ask about HTML5, and you should put yourself in a position to best meet their needs, regardless of technology or platform.

Thanks Mike for the helpful blog post about the future of Flash.

#&*@

I hate losing jobs or projects. As the company owner, one of my most important responsibilities is to bring in new business. This has to happen regularly, consistently, reliably. As we’ve grown since incorporating in 2002, our monthly financial responsibilities have grown substantially. I need to bring in enough business every month so that our cash in at least equals the cash out (at least as an average over time).

Losing a project hurts. The circumstances around this one were interesting. The job was a medium-sized project, the client was a large state organization. We’d been in discussion for a couple of weeks and everything was falling into place. We’d met in person and had a very good meeting, we’d established an excellent rapport with our wonderful contacts at the client organization. The work was the kind of work we do day-in and day-out in the website development world. Our proposed scope of work and budget were accepted verbally.

Now, we’ve done work with other divisions of this organization before and learned that for a variety of reasons it’s very difficult (in fact nearly impossible) to get signed contracts. So I had chosen to proceed with this project based on a verbal agreement and forego the signed contract we normally require. I can imagine what you may be thinking: “what a dumb-a**, he didn’t have a written contract?” Correct. We didn’t have a written contract, and I’d do again the same way tomorrow with this client. Based on past experience it’s always worked out fine with this organization, and my gut instinct was that the people I was working with in this division had integrity. As I mentioned, the rapport we had established up to this point was excellent.

The kickoff meeting was scheduled. Less than one hour before that meeting, our contact called us and said they had just come out of a meeting with another division at the organization, one that does website design and development, and totally out of the blue they offered to do the work we were going to do. For free.

It’s hard to compete against free.

Our contact was caught in a tough situation. I could tell they genuinely felt conflicted. They felt they did have a verbal agreement to send the work to us, but they also knew the higher-level managers in their division would want the lower cost (i.e. free) solution. I could understand their position and shared as much with them.

To me, it’s usually the better choice to maintain good relationships in these types of situations than to get all huffy about a verbal contract. The fact is in any business that somedays you win the job and some days you lose the job. I’ve been in the web design and development business long enough to know that a project isn’t real until you have the initial check in hand and a signed contract. We had neither and that’s part of the risk.

I asked if they would be willing to pay for the time we had spent so far preparing for the project – the client had sent all deliverables due to us the week before and we’d spent the required time reviewing all their materials and mapping out our plan for implementation. Thankfully, they were willing to cover the time we had spent so far. I felt grateful for that. One small success there.

In the end, I feel very good about how I handled myself and the relationship between my company and our possible client. Who knows, the other division implementing their website may run into trouble and want our help. There could be future projects from this division that could come our way. And there very likely could be other work from the organization as a whole and in my playbook keeping all the relationships positive only has upsides. I’ve also learned over the years of running several businesses that it’s almost never a good idea to burn a bridge. In Fort Collins our population is so very interconnected. I see this as a successful opportunity to have strengthened my own network, as well as (to a smaller extent) the reputation of all web designers and developers in Fort Collins. The web development community in Fort Collins is even more connected and we’d be doing our colleagues a disservice if we had acted with anything less than grace in this situation.

Like it or not, losing jobs is a part of business. A successful business doesn’t win them all. (If you do, then you’re most likely lowering your price too far on some jobs which is a good way to go out of business down the road. For more on this and other highly useful business tip I recommend “The Knack: How Street-Smart Entrepreneurs Learn to Handle Whatever Comes Up” By Norm Brodsky and Bo Burlingham.)

About 20 years ago an elderly and very wise friend gave me a huge gift. I was standing next to him with a group of people and he leaned toward me and said, “Ron, I’ve figured out the secret to life.” Ok, that got my attention. “Do you want to know what it is?” he asked. I of course said I did. He said to me “The secret to life is to give thanks for all things.” So simple, and in my experience so true. I’ve done my best to see my world through that lens all these years and it has made a huge difference. This particular situation was a challenging one to give thanks for as it was unfolding, but I came around to it. I for one believe my wise friend, now deceased, was right.

I’m curious how you’ve handled business disappointments in your life? Why don’t you share your story or thoughts in a comment below:

• OMG this is *awesome*. Couldn’t stop laughing: http://gmail.com/motion
• Ok, Google is topping themselves. Here’s a job listing for “autocompleters”! http://bit.ly/dMDZ3O
• Another: Go to Google.com, type “helvetica”. You don’t even have to finish typing! Must be those autocompleters they just hired.

If you know of others, post a comment!

Here’s one solution: https://github.com/filamentgroup/Responsive-Images#readme

The technique explained and demonstrated enables “developers to start with mobile-optimized images in their HTML and specify a larger size to be used for users with larger screen resolutions — without requesting both image sizes, and without UA sniffing.” Pretty nifty.

The technique should work for Safari (desktop, iPhone, iPad), Chrome, Internet Explorer (8+), and Opera but results in larger bandwidth overhead in Firefox as well as IE 7 and earlier.

I’d like to hear if you give this a try, send me a link to your site or demo.

I’m cautiously optimistic about this approach. While is has limitations, it’s a good start on solving an important problem.

“A really nice example of responsive web design from an unexpected source.” – via http://adactio.com/links/tags/responsive

A photo gallery website using responsive web design techniques.

What I’m talking about is creating potential website layouts to show a prospect how their new website might look during the sales process. It’s not uncommon in our experience for a prospect to ask for this type of work, especially when they are talking to several web design agencies and making a decision about who choose as their new web designer.

We recently won some web design work where the client asked exactly for this. It was a competitive bid process, and we had been informed that we made the cut to the final three agencies. At this stage they asked if we could create a wireframe mockup or examples of what we envision the site would look like…

The Explanation

Here’s how we explained to them why we don’t do speculative design work:

We would be pleased to show you and your team sites we’ve designed in the past, as well as review other existing sites with elements that could be useful. I’m sorry to say that one thing we don’t do as a matter of policy is create speculative wireframes or rough layouts. There are quite a few reasons why we find this doesn’t work.

- Creating wireframes and design layouts for a business is precisely what our designers do, and they have an established process for creating fantastic work. To get those fantastic results, we need to go through the whole process. If we attempt to do something “quick”, it’s not going to be representative of what they would actually come up with after completing our process.

- If we were to spend the proper time to create initial layouts, well, that’s a large amount of the time you are hiring us to do. Doing that speculatively would be a large expense, and given that no agency wins every job they bid on, adding that labor to every estimate or bid would drive up the cost of every website we do. So by not doing speculative design or wireframes we are able to keep your costs lower.

We believe that our extensive portfolio of past work will provide evidence of our capabilities and give you the confidence that we can create a perfectly-fitting web site for your unique company. We are more than happy to demonstrate that during our upcoming meeting.

Strengths and Differentiators

We further shared that one of our key strengths is that our design team is capable of creating a wide variety of layouts, each appropriate to the company we are serving and specifically designed to meet the needs of their website visitors. Many designers are good at one type of layout, or creating variations of one general look and feel of a website. Our designers have a very wide range of design styles which is a key differentiator for us compared with our competitors. We shared examples across the range of our designs with the prospect, with the goal of giving them the confidence that we could create a design that would be perfect for their company and the constituents of their website.

This can be a scary approach to take, knowing that one or both of the other agencies competing for the job may very well create some speculative designs and “wow” the client. We stuck to our guns, and in the end, won the work.

More Resources

While I was crafting our response, I recalled listening to an article about this on the Boagworld podcast some time ago. Here’s an excellent blog post from their website that shares some additional reasons why speculative design work isn’t a good idea.

Even the browsers were getting easier. Webkit and Mozilla based browsers were the most standards-compliant we’ve ever seen. IE8? Not bad for a Microsoft browser. IE7 was a bit of a mess, but nothing like IE6 which finally fell below 10% usage. Mobile? To some extent there were so many different phone operating systems and phone browsers that many of us had given up bothering. Call it a head-in-the-sand approach. But it sure made things nice.

Then Apple sold 3 million iPads in 80 days.

#*@&!

Oh yeah, and the iPhone4 is out with a super high-res screen. And mobile seems to be consolidating. The big three (in no particular order) are Android running Chrome (webkit), iOS running Safari (webkit), and Blackberry running who-knows-what but people who care can download Opera which is right there with webkit when it comes to web standards. So guess what. Mobile matters. It matters a lot. And the mobile space is clearly not as fragmented as before.

All of this adds up to a big problem. People are viewing our web sites on all kinds of screen sizes. 1024 is no longer a magic number. Not when mobile growth is 8x that of desktop growth. The pace is so hot that it looks like mobile web access will eclipse desktop web access in just 3 to 5 years. So yeah mobile matters. And size matters. The number of screen sizes we should care about just jumped through the roof given the variations of phones, iPads, tablets-yet-to-come, netbooks, laptops, desktops and external monitors that are already out in the field.

So what’s a designer to do? How can we avoid being thrown back to the horrid days of browser-sniffing and coding completely different HTML layouts for different browsers and devices?

The answer is blowing in the wind, and it’s called Responsive Design.

The core principles of Responsive Design for the web are using a flexible grid, sizing design elements as proportions (%) rather than pixels, and using CSS3 media queries to make your design responsive to the size of the viewport or device.

Wait wait wait you say: this sounds a lot like fluid layouts which have been around forever. Sort of, but in the words of Jeffrey Zeldman “It’s what some of us were going for with ‘liquid’ web design back in the 1990s, only it doesn’t suck.”

The lynchpin in this technique that doesn’t suck is the use of media queries, a CSS3 feature, that allows you to change how elements are displayed based on the size of the viewport. This even works dynamically while you are dragging the corner of your web browser around. This lets you create a design that morphs into a one column layout for small viewport or device sizes, and a three column layout for large viewports, but not TOO wide if you are on a 1920px wide browser. Yep, you can even keep line lengths readable.

But CSS3 isn’t supported by IE8. Or IE7. Or IE6. No problem. Turns out there a Javascript workaround that enables IE5+ (yes, that’s right, IE5+) to interpret media queries. http://code.google.com/p/css3-mediaqueries-js/ Now we’re talking!

Media queries are supported in the latest versions of all the other browsers that matter including: Opera 9.5+, Firefox 3.5+, Safari 3+, Chrome and Mobile Webkit.

And to sweeten the deal, the Javascript workaround mentioned above also allows Firefox 1+ and Safari 2 to use media queries

Ready to learn more? Start with the definitive article by Ethan Marcotte:
http://www.alistapart.com/articles/responsive-web-design/

Follow up here, which includes links to some related articles, shares the history of the very recent evolution of the technique, and includes links to several sites already using the technique:
http://www.zeldman.com/2010/06/23/responsive-design-is-the-new-black/

I’ll be demonstrating the techniques at the upcoming Fort Collins Internet Pros Meetup on Thursday, August 12. Learn more and RSVP here:
http://www.meetup.com/goFCIP/calendar/12297128/

Wordcamp is a one-day conference for WordPress developers, designers and enthusiasts.

I’m interested in the following talks so far:

• Creating a Blog Community with Dave Taylor, Doyle Albee, Aimee Giese, Holly Hamann
• Caching in WordPress with Chris Scott (same time as Blog Community, ugh!)
• WordPress Development with Alex King, Shawn Parker
• DIY Usability Testing with Steve Martin (I’ve seen Steve’s presentation and it is AWESOME! I highly recommend attending this one. His live usability test is enlightening and eye opening in ways you wouldn’t expect. And it’s different every time. No end to what you can learn here. If you want to make your websites better whether they are built in WordPress or not, this is a talk not to miss.)
• BuddyPress 101 with Lisa Sabin-Wilson (same time as Steve’s talk, ugh!) – BuddyPress is a plugin that turns your WordPress website into a Social Networking site.
• What’s Next for WordPress with Jane Wells

Two of us from CodeGeek.net will be attending (me, Josh Mulligan) as well as Steve Szczecina from Social Media Pilots.

As a web design and development company that uses WordPress as one of our main Content Management Systems (CMS) I’m especially interested in getting up to speed on the new features in WordPress 3.0, expanding our skill set, and meeting lots of other WordPress designers and developers. I love collaborating with others and staying in touch with other Internet professionals. If you are going, please be sure to say “hi” to us and give us your contact info and Twitter handle. You can follow me on Twitter at @ron_z.

Remy reviews two HTML5 features:

1. Storage including localStorage and sessionStorage which are local data storage capabilites that surpass the capabilities of cookies (to say the least), and
2. Offline Apps: specific techniques so you can tell an offline browser to load required files for a web site or web app from a local cache, thus making the web site renderable or the web app functional without a connection to the Internet. Supported presently by Safari and Firefox though the applicationCache methods.

Pretty interesting stuff to keep an eye on. These capabilities alone are a good reason to me to start using HTML5 now. As more browsers support these features we can create web sites using just HTML5 and Javascript with capabilities of full blown web apps. And they’ll work even when not connected to the Internet. Awesome.

I’ve been fascinated with the idea of “occasionally connected apps” since Macromedia Central was introduced in 2003 (since discontinuted, Adobe Central Developer Support Center, Anatomy of a Central App, Central Blog). Adobe AIR is making good inroads as the present platform of choice for occasionally connected apps. It would be a major improvement to have this capability without the requirement of a proprietary pluigin, i.e. the Flash Player. I’m excited to see active progress in that direction.