Snook.ca

HTML in a Flash World

jonathan@snook.ca (Jonathan Snook) — Wed, 08 Jul 2009 10:40:44 PDT

Last night, I had the pleasure of presenting a short little session on HTML development within Adobe AIR and what the perks and pitfalls were. The feedback I got afterwards was very positive and I hope everybody there got something out of it.

As promised, I'm providing the slides in both PDF or Keynote.

Here are the resources that I talked about and have linked to in the slides:

Adobe AIR SDK
Adobe AIR Developer Center
Ext JS has AIR interface
BlackBookSafe
Also mentioned in the questions afterwards: Badger

Adobe and HTML5's Canvas

jonathan@snook.ca (Jonathan Snook) — Tue, 07 Jul 2009 09:49:27 PDT

I had an epiphany and I hope somebody at Adobe has been paying attention to the HTML5 developments. Adobe is well positioned to take advantage of emerging browser features, most specifically canvas.

As great as canvas is, having a visual tool to assist in taking advantage of that would be ideal. Such a tool would smooth out the rough spots of cross-browser issues and could provide a set of pre-designed widgets and interactions that could be quickly dropped into any project.

Flash developers would likely find it an easy transition to building canvas-based tools. It'd be easier because of their knowledge of animation and because of the similarities between ActionScript and JavaScript.

Adobe is also well positioned to integrate a solution across existing applications such as allowing "Export as Canvas" from Flash, or the ability to build a canvas editor for Dreamweaver.

This isn't a Canvas vs. Flash issue. There are still advantages to both. Building a tool such as this doesn't sabotage their Flash marketshare any more than Dreamweaver does. In fact, having a tool such as this would further entrench Adobe as the de facto provider for web design tools.

Behind the Process: Snitter Icon

jonathan@snook.ca (Jonathan Snook) — Fri, 22 May 2009 10:39:51 PDT

I built this desktop application a while back called Snitter. It's a desktop Twitter client that runs on Adobe AIR. Alas, it fell by the wayside during my freelance tenure. Recently, I've had the inclination to start working on it again and bringing forth to reality ideas that I've had for over a year now.

One of the things that always bothered me was the rather rushed icon. A rather boring S. I was just happy that I had a desktop app with its own icon. I knew I'd get around to getting a new, more polished icon at some point.

Who can? A Toucan.

Being a Twitter app, I wanted to stick with the bird motif but also wanted a bird that had some colour to it — especially green. The toucan came to mind, as images of Toucan Sam and his colourful beak filled my head.

In doing research on toucans, I came across a page on Toucan totems.

The toucan represents communication and showmanship. The toucan's colorful appearance and large bill indicates a strong desire to be seen and heard.

If anything sounded more appropriate for a Twitter app, I haven't heard it. The toucan was now the bird.

Initial Sketches

I'm not an icon designer, so I enlisted the help of Mike Rohde. The fact that he said yes to a free project was music to my ears. I gave him some simple direction that I wanted the icon to be a toucan and he came back with some initial sketches.

Check out all the sketches.

I was definitely starting to get excited. I had started to provide Mike with some further direction, indicating that I really liked the bird looking over the shoulder. I felt it provided more balance and would be easier to work into an icon.

Alas, a year had gone by and my ability to work on Snitter had disappeared. Sadly, so had Mike's free time. Mike had to bow out. Having been in his shoes, I completely understood.

Inspiration

Now on my own, I thought I'd give icon design a try.

One thing I did differently than any other design project I've done before was to create an inspiration document where I threw in a bunch of photos and icons that I liked.

When you see the final icon, I'm sure you'll see where much of the inspiration has come. I started by actually tracing out the shape of one of the birds that was looking over his shoulder. Using the pen tool in Fireworks, I traced out the beak, the head, the chest and the body. The shapes had flat colours and I really just wanted to get the basics of the shape in place.

Circle-bound

Two things that I was missing were a tail and feet. As I started to put the tail in, I begun to see the circle shape come into play. I drew a circle and placed it behind my vectors and tried to lock everything into that shape. I was drawn to using the circle based on the Twtterrific and Firefox logos. (I was tempted to have my bird circle a globe but thought against it.) This is definitely where the most progress was made.

I had a tail in place and then started on shading. I layered vectors over top of what was there, playing with gradients and colours to create the effect that I wanted. It was after this point where I really started liking how things were coming together.

When I posted this version to Flickr, a few people mentioned its similarity to the Aviary Toucan. They did a fantastic job with that toucan. One thing that was extremely evident was how tightly they stuck to a circle for the beak, head and into the body and then breaking out of that with the wings.

I took that inspiration and went back to tweaking my toucan. I still didn't want to stick too close to the circle but I did lengthen the beak, having it follow the edge of the circle, instead of having a more defined hook nose. Where the beak meets the head, I decided to leave it as-is. I didn't want to stylize the bird too much.

Stay on the ground or fly?

I still had no feet and I wasn't really loving the wings. Trying to play with the circle, I tried to get the wings to complete the left side of the circle but everything I tried felt unbalanced, leaving a large space right in the middle of the logo.

Starting to grow weary of using the pen tool to shape things, I switched to use circles to punch shapes into crescents for the wings. It was at this point that I used a circle to punch the shape of the toucan's back. I liked it.

When I rotated the crescents I had, I tried shifting them into the middle of the space between the head and the body. The crescents were so large that they inadvertently popped out on the other side of the bird. Wait, it looks like wings on the other side! This happy accident got me exactly what I wanted.

With the bird in flight, I no longer had to worry about the feet. I tried a couple different things earlier to get feet but they all looked hideous. Feet are not my forté, it seems. No worries, as I was really happy with how things were shaping up. (a little vector humour there...)

I continued to adjust the shadows, adding highlights to the bottom and the wings to give the bird a little more depth. Finally, I was happy with the result. Like, really happy.

Let it fly!

This will be the icon for the next version of Snitter, which I'm hoping to have out in a couple weeks.

As an added bonus, I'm linking up the final Fireworks PNG. Download it and check out how it's all put together. The design is copyright so don't go throwing toucans over everything but pick it apart and use it to inspire your next design. The Fireworks file was created in CS4 and uses the Pages feature where I have an earlier version on page 1 and then the final version on page 2 (a cheap way to do versioning).

The Elephant in the Room

jonathan@snook.ca (Jonathan Snook) — Thu, 21 May 2009 07:49:07 PDT

Almost a month ago, I wrote about supporting older browsers — how and whether we should even support them.

We draw a line in the sand that says, "You popular browsers, stand over here. Everybody else, just be happy you got content."

More specifically, a base style sheet would declare some default font styles but no float or other layout tricks. Just linear content. This default would look decent in any browser, no matter from what era. It makes a great print style sheet, too.

The general consensus that came from that was to ignore old browsers like they don't exist. Testing in every browser is impossible. Therefore, we test for what we know and hope for the best with the rest.

Today, Andy Clarke (and all that malarkey) released a Universal Internet Explorer 6 CSS. The idea behind it is to provide a simple style sheet devoid of any layout tricks but that still provides a designed experience. Just linear content. This default would look decent in any browser. It even makes a great print style sheet, too.

I, personally, prefer this approach of providing a minimalist experience over the idea of preventing people from accessing it altogether. Or berating them for their choice of browser, assuming they have any choice at all. We should stop making fun of the kid who dresses funny because his parents can't afford nice clothes.

This still doesn't solve the problem for those browsers we no longer want to test in. What of those 83 people that visited my site in the last month with Safari 2? Or the 2500 people that were still using Firefox 2? I can only assume that what I've designed looks half decent. I mean, Firefox 2 has decent CSS support, right?

I guess we just hope for the best.

Fixed Position and Opacity Filter Bug in Internet Explorer

jonathan@snook.ca (Jonathan Snook) — Thu, 07 May 2009 11:11:34 PDT

I think I have a knack for discovering weird edge cases but here was a wacky one that had me scratching my head for awhile. In working on some interface development, I wanted to have an element with fixed positioning, locking it to the viewport. In this particular case, it quickly animates in by adjusting the opacity of the element from 0 to 100. Straightforward enough, right?

But in Internet Explorer 7 and 8 (even in standards mode), I wasn't able to scroll and while I could type in my form inputs, nothing was showing up. Resizing the browser forced a redraw and everything looked okay but you still couldn't scroll or see anything you typed into a text field.

Here is the CSS that was causing all the ruckus:

.fixed { 
   position:fixed; 
   filter: alpha(opacity=100); 
   top:15px; right:15px; bottom:15px; 
   width:150px; 
   overflow:auto; 
}

I've put together a simplified test case that demonstrates this. Check it out in IE7 or 8 and you should see the unfortunate side-effect. Click on the Remove Filter button and the functionality of the fixed area should return to normal.

Putting the test case together for this was a hassle. Because the filter was being applied via script, all my original assumptions weren't working. It was only when I started pasting in rendered HTML from IE (using IE's developer toolbar in IE8) that I was able to recreate the issue (since the rendered HTML had the filter applied).

Shifting my Opinion on CSS Animations

jonathan@snook.ca (Jonathan Snook) — Tue, 05 May 2009 21:36:08 PDT

When CSS animations were first introduced in Webkit back in 2007, I expressed my concerns that CSS may not be the best place for it.

Sound cool? I don't think so. Not only does it make CSS more complicated, it makes JavaScript more complicated, too.

Having actually taken some time to implement CSS animations in an example, a light bulb clicked. The way I looked at how animations were declared and in what situations you would declare them suddenly changed. I believe I have done a 180 on this. Why and how, you might ask?

Understanding Transitions

The first hurdle for me was understanding how animations were declared. Where do you define them? How do you set the type of animation, the duration, and what should happen? What finally clicked is not that I'm defining an animation.

I'm defining that when an element (based on the CSS selector) has a style property change, that the change happens gradually instead of instantly.

When I looked at it in this way, it was no longer about JavaScript or behaviour, or anything else but simply defining that property changes shouldn't be instant.

Here's a quick example:

a { color: #039; }
a:hover { color:#333; }

I'm sure you've seen code like this a zillion times. But what if you wanted the property change to be gradual?

a { color: #039; -webkit-transition-duration:.4s; }
a:hover { color:#093; }

Try this in Safari 4 and you'll notice some really nice soft fading between the two states. Imagine declaring this in JavaScript? How cumbersome.

Separation of Presentation

Which made me make the connection to the separation of content, behaviour and presentation.

One thing I've advocated for awhile is representing state changes within JavaScript by changing an element's className instead of changing numerous style properties. For example, let's say you have a bunch of tabs and you want to indicate that a particular tab is the active tab. The easiest way to do that is to attach a click event handler to a tab and then apply an active class to it (while at the same time removing the active class from any element that may already be active).

If the active tab was to be 10 pixels higher, then it'd be easy enough to declare this via CSS:

.tab { position:relative; top:10px; -webkit-transition: top .4s; }
.tab.active { top:0; }

When the active class is applied to the tab, its position is automatically transitioned from 10px to 0. In this case, I also explicitly indicated that the transition should only apply to the top property.

Detecting when an animation is complete

One of the other hesitations I had with CSS animations was the uncertainty of how animations would conflict with other JavaScript code that may be running at the same time. As I understand it, inspection midway will report accurate computed styles at the point of animation.

To detect whether an animation has completed, you need to be on the lookout for the transitionEnd event which fires on the element that was transitioned. For now, the event needs to be prefixed with webkit, which is a little unusual in the world of JavaScript.

myElement.addEventListener('webkitTransitionEnd', myFunction);

Progressive Enhancement

Finally, one of the things that I like about this is its ability to be applied quickly while still allowing the same interaction in all other browsers, albeit minus the animation — an animation that is purely presentational in this case.

I don't believe this is the solution for all browser animations. Far from it. While more complex animations can still be handled via JavaScript, I like the declarative way of describing that an element's properties are transitionable.

I've seen plenty of people jump on the text-shadow, box-shadow, or rgba bandwagon. I now see transitions as being yet another tool to soften the experience for a segment of your visitors.

While I was reluctant to see this gain traction, I'm much more receptive to it now and would like to see other browsers get this implemented.