Entries tagged “html5.”

Surf by Osmosis, a 10K Web App

This week I submitted an entry to 10K Apart, a contest sponsored by the fine folks at MIX and An Event Apart challenging web designers and developers to craft an HTML5-based application under 10 kilobytes in total file size (minus a few forgiven resources like jQuery and Typekit). Entries must be compatible with Firefox, either Safari or Chrome, and the Internet Explorer 9 Developer Preview, but thankfully not IE8 or below.

My entry, titled Surf by Osmosis, shows you the latest top content from Digg, Google News, Twitter and YouTube in as little as a minute, allowing you to absorb today’s trends quickly so you can get on with your life. You can view and comment on my entry on its 10K Apart page.

I took this contest as an opportunity to tackle a few challenges I hadn’t yet mastered, specifically:

  • Quickly fetching feeds. I already do a lot of JavaScript feed-fetching on Portwiture and TweetPlus, but this one had to get the lead out.
  • Time-sensitive events. For some reason, intervals and timeouts have always felt unintuitive for me to develop.
  • Drawing with the canvas element.
Originally I struggled with normalizing the way data was retrieved from the four disparate services, until I realized I could use the speedy and versatile Google AJAX Feed API to grab all of them. This minimized my reliance on outside APIs while leveraging Google’s relative lack of down-time to achieve a speedier experience.

Time-sensitive events turned out to be much less frightening than I thought they would be, at least until I combined them with the initially perplexing canvas drawing methods. Thankfully, the Mozilla Developer Community offers an amazingly helpful animated clock demo I was able to reference and simplify.

Surf by Osmosis went through a few design iterations before I settled on the current look. Unlike most of my projects, I didn’t start in a sketchbook or Photoshop. Due to the technical constraints, I felt my usual design tools would only invite more complexity, and thus more file size.

The original layout was inspired by the simplicity of my friend and colleague Chris Kalani, but the open, fluid composition was more complex to style and animate. Additionally, the lack of a container made the transition between each step feel too jarring and dramatic.

The second iteration was at one time considered “finished.” The fixed container made transitions more predictable and defined a focal point for the viewer, and the multi-layered look of it gave me plenty of opportunities to play with CSS3 gradients and shadows. Much to my dismay, the verbose CSS3 gradient syntax (duplicated for both Mozilla and Webkit compatibility) coupled with the extra logic needed to craft a dimensional animated clock pushed the file size a few kilobytes over the limit, forcing me to simplify.

As is often the case, these technical limitations pushed me to focus my design. In lieu of fancy-shmancy effects, I was now forced to rely on color and typography (specifically FF Cocon Web Pro) to inject Osmosis with personality, and I firmly believe that the end product is better for it. Lesson learned!

Voting appears to be closed as of today. I’m honored to have received an average rating of 4.06 (out of 5) stars with a total of 396 votes, my sincerest thanks to everyone who voted. I’ve already received many wonderful suggestions for how I could expand the application once the contest has ended. If you’d like to see Surf by Osmosis revised and built upon, please let me know.

If you’re curious, my favorite competing entries are probably the addictive canvas game Sinuous and the dead-simple-yet-attractive Inspired By.

Tune In to the Friends Electric Podcast

Peter Wooley is one of my most frequent co-conspirators. A while back we started working together on a super secret project (sorry, can’t talk about it yet) and had to think up a name for ourselves.

We deliberated without much success for weeks until my girlfriend Mallory suggested “Friends Electric.” Since Peter and I are friends, we make stuff that would be impossible without electricity, and we happen to be Tubeway Army fans, it just made sense.

We’ve kicked around the idea of recording a web designerly podcast for a while, so I was overjoyed when things actually came together. Recorded last Saturday, the inaugural Friends Electric podcast debuts today. We talk about Apple versus Flash versus HTML5. You can listen right away; if you dig it, consider subscribing via iTunes.

This is our first foray into podcast creation, and there are definitely things I’d like to remedy in future episodes. That being said, I’m actually pretty pleased with the end result. We had a blast making it, and we intend to make more, hopefully bringing in guests from in and outside our little Portland design circle. We hope you enjoy it.

Why HTML5 and proprietary platforms are both here to stay

Flash or HTML5? Choose your side.

That’s the tone seemingly set by much of the web community following the aftermath of Steve Jobs’ controversial Thoughts on Flash, exacerbated today by a thoughtful (yet apparently blasphemous) thread of Twitter commentary from influential Facebook developer Joe Hewitt.

These conversations have re-ignited a debate already intensified by the ever-increasing prominence of HTML5. While it may seem natural to regard this as a quarrel between proprietary technology and open standards, this is a gross oversimplification. Our feelings are merely the growing pains of a maturing Web.

The source of much of this tension is the difference of approach between the World Wide Web Consortium and companies like Adobe. The W3C is an important group tasked with an inherently sluggish goal: To corral, distill and encapsulate the opinions of a zillion developers and vendors  in order to produce hard-to-read documents detailing how the Web should be. While I’m sure more attentive observers may offer solutions for streamlining the W3C’s process, the result will never be analogous to that of a corporation. Great ideas (and profitable products) cannot wait for bureaucracy’s blessing.

Visionaries will always develop a means to forge ahead. That’s why Firefox, Chrome, Safari and Internet Explorer 9 all implement portions of an unfinished HTML5 specification. It’s also why platforms like Flash, Silverlight and the iPhone SDK have such a perceptible impact on the Web. Collectively, they are a crystal ball within which we may glimpse activities we’ll eventually take for granted. Remember how novel YouTube felt before embeddable Flash video became so pedestrian?

Not unlike the story of the tortoise and the hare, specifications eventually catch up. Like CSS and JavaScript before them, canonical experiences will “graduate” to full-fledged features of—or companions to—HTML. (Any Argo SSP or Netscape LiveScript loyalists out there?) Why? It’s all about accessibility.

The more accessible your experience, the larger your potential audience. HTML can be parsed fairly reliably by the majority of web-connected devices. But with each subsequent layer of complexity, your user’s device and/or browser must be sophisticated enough to interpret the additional technical requirements. It’s our job as designers and developers to weigh the benefits of each layer’s capabilities against the hurdle it may represent for the consumer. Many of us employ progressive enhancement to capitalize on the latest technology while leaving as little of their users behind as possible. Time/budget permitting, why wouldn’t you want to pursue a greater breadth of device compatibility?

Plugins must innovate in order to survive. If Flash stagnates, if it fails to shine a guiding light on the future of our industry, it will join its sibling Shockwave in an ever-growing graveyard of antiquated technologies, succeeded not only by HTML5 but by more innovative competitors (Silverlight) or a whole new paradigm (device-specific SDKs).

The Web needs these technologies. I believe (and wholeheartedly hope) that standards will continue to define the most prevalent form of the Web experience, but not without the guidance, foresight and bullheadedness of those who refuse to slow down.

HTML5 and CSS3 for the sake of tomfoolery

One of the biggest disappointments I continually encounter when teaching web design is losing students to rich media plugins, most commonly Flash. These closed, proprietary sirens singing talented designers and developers out to sea rob the Semantic Web of some truly creative minds.

Students often look at the Web and see a minefield of limitations. Several times I’ve approached students with stellar HTML/CSS/JavaScript-based work to ask about their career plans, only to hear “I’d rather pursue Flash work.” No matter how many times I offer tomorrow, many students are only interested in now.

I evangelize the Semantic Web clearly and passionately in my lectures, but arguments of principal, search engine optimization and accessibility often flounder in view of visually-engaging, rich web media. There is a fine line between designer and artist; in order to appeal to these minds, we must impress them on a more visceral level.

Given time, I think HTML5 and CSS3 are up to the task. My arsenal of compelling examples has been growing exponentially.

Mouse over the DVD cases when viewing For A Beautiful Web in Safari 4 and you’ll encounter some gorgeous and purposeful rotation-based animation that degrades gracefully for less-abled browsers.

In Mac OS X Snow Leopard, Guillermo Esteves has recreated the Star Wars Episode IV marquee for Webkit users (perspective and all).

Firefox 3.6 introduces support for the File API, making drag-and-drop file selection possible (thereby trumping Flash’s previously-superior selection capability).

Webkit users who opt-in to bleeding edge features can now experience YouTube and Vimeo sans Flash players using only HTML5’s built-in media support. The result is stunningly indistinguishable from Flash video playback.

These examples may appear to be small victories, but their importance cannot be overstated. We are watching the capabilities of HTML and CSS progress more rapidly (and with farther-reaching effect) than their rich media cousins. In a Web where the capabilities of Flash and HTML are roughly equivalent (or perhaps even lopsided), the choice will be abundantly clear.

Address all audiences via the Semantic Web, or keep playing in your sandbox. Which sounds more fulfilling to you?