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.

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/

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.

The first article this year is “Working with RGBA Color” by Drew McLellan.

Key points:

• This is one technique for setting the opacity/transparency of HTML elements
• The CSS opacity property is available starting with CSS3
• opacity adjusts opacity for all parts of the selector (HTML element), so if opacity is set to 0.5 for a heading element, the opacity of both the text color and background color are 50%.
• Using RGBA color specification allows finer control. The “A” part = “alpha channel”, which controls opacity, and can be applied to each color declaration as opposed to the entire selector. RGBA allows you to specify different opacity values for the text color vs. the background color.

Quick CSS terminology review, CSS syntax:
Selector {declaration1; declaration2;}
declaration = property:value;

example:

h1 { color: #000000;}
selector = “h1″
declaration = “color:#000000;”
property=”color:”
value=”#00000;”

Back to Working with RGBA color:

• To specify RGBA, use rgba(0-255, 0-255, 0-255, 0-1) as the value in your CSS declaration instead of hex codes, see the article for examples
• RGBA is supported by the latest versions of Firefox, Safari, Chrome and Opera, but is not supported by IE (of course)
• See article for ways to specify fallback colors or PNGs when RGBA is not supported (important)
• Opacity/RGBA can be changed on :hover or manipulated with JavaScript for elegant rollover effects
  
• RGBA can be applied to text color, background color, and border color

An Event Apart Boston 2009 “the design conference for people who make web sites” just wrapped up today, and that was a strong message from no less than four of the fifteen presenters. In the past there has been a tacit assumption in the web design community that web sites should look the same, pixel for pixel, in the web browsers used by the majority of web site visitors. That would currently include Internet Explorer 8 (IE8), IE7, IE6, Firefox, Google Chrome, and Safari. One of those six browsers are used by approximately 97% of web site users according to the W3 Schools browser statistics page as of May 2009.

The new trend is a more realistic approach to web site design and development issues. “Different does not mean broken” said Andy Clarke, one of numerous presenters at the conference making the point that it is okay for web sites to not look identical in different web browsers.

What matters is that the content and functionality of a web site be made available to the largest number of web site visitors possible. If a button has rounded corners in Firefox but not in IE6, it’s not a big deal.

This approach allows web developers to start using some of the new features available in CSS3 right away, including creating rounded corners and drop shadows on both text and containers. Implementing these style elements in CSS saves time in the development process when initially creating a web site, and over time when maintaining it. The problem is that CSS3 features are not supported by IE7 and earlier. Many CSS3 features are supported by IE8, Firefox 3.5 and above, and Safari 3 and above. So going forward, support for these features will continue to improve.

Web site owners will be interested to know that implementing these features, like rounded corners, using CSS3 saves them money both in the short term (during development) and in the long term (considering web site maintenance). Design elements like rounded corners can be made to work in older browsers that don’t support CSS3, but that requires the designer to create separate special background images for each of the four corners of the box, and requires the coder to use extra HTML markup to apply those images. These images mask the “natural” square corners of the box giving them a rounded appearance.

While this looks great in more browsers, there are many downsides. In addition to taking more labor to create the effect in the first place, if changes need to be made to the corners in the future it takes more time than changing a few digits in a style sheet. There is also a slight performance hit to the web server, as more graphics have to be downloaded to the user’s computer in addition to a slightly more complex and therefore larger HTML file.

I am very much in favor of the new direction. What it does is focus our attention on what matters more as web site owners and web site designers: the content of the web site and the functionality of the web site. That is what we should be striving to deliver effectively to our web site visitors. Using the new techniques, if web site visitors are also using modern software, they will be rewarded with an enhanced appearance to the page.

I agree with this comment on usability advantages of styling visited links differently from un-visited links, emphasis mine:

“Visited links not only help users avoid pages they don’t want to go to, they help users find pages they want to get back to. Styling the visited links in your site’s content will vastly improve your users’ experience.” [Source]

I think this point is often overlooked.

More articles I found useful:

• Mostly solid advice that has stood the test of time: http://www.designbyfire.com/deye_web/alertbox.htm
• Thoughts on using a background image next to a link to indicate that it has been visited: http://www.colly.com/comments/ticked_off_links_reloaded/
• Using symbols to indicate visited links, good points in the comments too: http://www.mikeindustries.com/blog/archive/2004/06/radical-links

I’m a big believer in using an underline as well as color to display links in general (with exceptions). I’m leaning toward using a washed-out version of the link color to display visited links in the main content for a web site, and possibly a background image or symbol to indicate visited links in a side bar or list.