Avoid Unnecessary Chaining

For example if a style references the id of an element, be sure to not add unnecessary information about its ancestry.

#page #header #navigation {} could just be #navigation{}

Since we’re already using an id for the element, there is no point to give an ancestry.

Caveat: When I want to change the navigation on a particular page I could do the following.

#home_page #navigation{}

Use Specific Class names

The further down the DOM tree you get the more specific the class naming should get to avoid possible conflict. I have adopted chaining the tree inline as it involves fewer lookups. Also, the style declarations are read in reverse order from right to left, having  just one class reduces the amount of pruning involved.

Instead of using something like #header #navigation .button we can describe the item using one class: .header_navigation_button

Use relative then absolute positioning, more than you’d like to

A lot of browser conflicts or oddities can be resolved using absolute positioning. Instead of relying on placements using floating or margins often times positioning an element in a relative block will fix spacing issues that might arise across browsers.  Examples of this are buttons with set icon sizes, header content, etc… Since placing things absolutely takes it out of the flow of that element, you don’t have to worry about how it will affect the other sibling elements. Then those siblings can be “fixed” using proper padding or margin.

Allow Block Elements to Fill Their Space Naturally

A huge problem for a lot of people when it comes to layout is how different browsers treat their width/height and their padding and border. Sometimes the border and padding are considered internal or sometimes external to the block element. To avoid this on elements where you need to set the width, do not use padding or border on the left or right, and vice versa for the top and bottom. Often times this will destroy your layout. Make sure that layout blocks retain the size you want them to and avoid overloading them with styles that will cause them to generate various widths and heights on different browsers. A blocks natural inclination is to fill the space available (e.g. width: auto;) much like a liquid.

Another situation you won’t want get in when styling a layout is to use percentages with a child element, where the parent has padding. For example setting the width of the child to 100% width and the parent to having a padding of 20px all around, might lead you to think that the child element will fill the area inside the padded area to 100%. However, what this actually means is that the child element will be 100% of the width of the parent and start from the (20, 20) mark of the parent element, and spilling outside of the parent block. A better solution would be to just let the child block default to automatically assign its width and height.

Speed Considerations

It is also important to consider the efficiency of your CSS, and the point behind using less verbose selectors and specific class names. For speed, it is important to keep in mind that the more selectors you use in the style declaration the less efficient the selector is. The best you can do is to avoid large chaining. It is also important to redcuce the number of elements on the screen at a given time, thus making the DOM faster to traverse. The less steep the tree the faster the interface will be. The practice of having to keep everything simple is in a constant struggle to meet the needs of the design, as sometimes the design will require more elements on the screen than is practically needed; creating more overhead.

Other ways to improve speed are to add inline styles to elements. Inline styles will override any styles in a stylesheet with the exception of styles with the !important declaration. A good example of inline styles are elements that either require dynamically generated placement, such as the slickgrid or its spiritual derivatives.

Garbage Collection

This is related, but not exactly on topic. But it is important to have a rudimentary form of garbage collection for your DOM elements. Make sure that when you’re done with an interface you take it off the view. If it’s more work to update the styles and content than to re-render a scene than it is advisable to just start from scratch and redraw it. This problem is a lot more obvious on sites that rely on ajaxian interfaces. For example, I was visiting twitter the other day and had left Firefox on overnight. The next day my computer was running insanely slow, and I traced it to twitter’s site. I counted how many DOM elements they had on the screen and it came out to roughly 200,000. I then refreshed the site and counted the number of elements on the page this time: approx. 600. Good websites can typically show their entire front page in about 500 – 600 elements.

On load Grooveshark uses about 550 elements. The real killers are content dedicated to displaying both large amounts of data and large amounts of “visual” data. To avoid that, things like the queue, pages, and lightboxes are all in charge of their own garbage collection. If it’s not going to be used or seen in the foreseeable future, kill it!

While on the server side you have free range; we can use nice languages and frameworks (or any of these for anyone of a more lambda persuasion).  We can use scripting languages where they make sense, and opt to use a fully compiled and typed language when and if the situation calls for it.

On the client side we have… well, just javascript.  JavaScript is a great little language to quickly hack something up, and make some nifty gadgets. I even enjoy making them.  The problem is that we’re no longer using javascript as that little bit of glitter to make websites shiny.  JQuery, Prototype, and other AJAX libraries provide a small extension to our honeymoon period with javascript, but now we’re wondering if he can still provide for our family.  We’ve been using it to build full fledged applications, and this is where it gets gross.

Software development is not a solved problem by any means.  We have learned quite a bit over the years, and modern languages and platforms have evolved to make development an easier and more maintainable endeavor.  Javascript was really never meant to be a full featured, cross platform language, and it shows.  Google, who you might have heard is in the business of web apps, realized that javascript alone would not fit the bill for creating these massive, long-term projects, so they created GWT.  Others followed suit and we now have frameworks like Cappuccino and Pyjamas.  These are impressive projects, but again, we’re dealing with the symptoms by patching over javascript.  They hide all the ugly cross-browser compatibility problems and lend us more maintainable languages and tools, but at the cost of performance.

So what can we do?

For now, frameworks like GWT, and libraries like JQuery can help make your life easier (and maybe help save the sanity of the next developer to take over your project).  In the long term, I propose that we begin moving away from javascript.  I’m not going to endorse my favorite fad language of the hour, but rather suggest that we look at ways to embed the LLVM into browsers.  This would allow developers to use any language supported by the LLVM, and by extension any libraries written in those languages (maybe a return to picking, “the right tool for the job”).  Client-side code would be distributed as LLVM bytecode, allowing fast JIT compilation (this also has the added bonus of opaqueness for those services which may require it).

Ok, back… nom nom nom…

As much as we’d like to not sell out or be sustainable by the viewers like you; it’s just not economical. There is always going to be some amount of whoring in order for us to pay the bills. What is putting the money in our pocket is someone not concerned about whether or not they can loan us money for a cup of coffee once in a while (payed subscriptions), but someone that’s concerned about a return on investment: monetary obligations. We all want someone to take us out to a nice restaurant and treat us right, but at the same time they’re trying to push their products on us… hard.  So what’s wrong with everyone? Just because you say you’re open, doesn’t mean you are. You praise it like a religion, and then peddle your wares.

So what I think everyone needs to understand is that solutions to problems are dependent on the PROBLEM. We can all bitch and moan about our fan-boy tendencies, but what matters is getting the job done as fast and be as fruitful as possible. Advertising is one of those cases that merits quick turn-around and the widest range of tools. We want to shock our customer into buying our product, leaving a lasting memory when the time comes and they’re at the check out line or being sure they have an incentive to pull your product from the shelf. This truth has made it from television to its spiritual successor, and will remain a large factor for much of the web.

Will the web standards ever catch up to advertisers expectations? In a sense it is trying; it’s constantly catching up. There will always be the cheap solutions to people’s advertising dollars. But, at the same time advertising will always push the market and create demand for high quality advertisements. I work on web advertisements all the time (approaching ~1 million in ad revenue), and the open and free solutions to the problems for advertising barely exist; they are always raising the bar, and it always needs to be done yesterday (the deadlines are literally missed by a day or two). Recently I was asked to animate all our advertisements in JavaScript, with nice slide in effects that are coordinated effortlessly. The reason to make it in JavaScript: it would be really cool if we could make it in JavaScript.

Coolness factor aside, the dev time needed to make all that work and not suck in everything besides Chrome (please get chrome, for the love of god) within a time window of two weeks, would’ve meant me wanting to kill myself from lack of sleep. Instead, I said, “yeah that would be cool, but I am going to be realistic, and work on that in flash inside a few days”. And we all won, because

1. I was happy because no one died
2. I nor my coworkers did not end up being placed through a life-debilitating wringer that left them scarred for life from choosing hard drugs to stay up
3. Most importantly the client was happy!!

In advertisement the most important thing is turn around time (and does it blur or rather poop smear). It’s important to know the limitations of the tools at your disposal especially when you do not have the time to mess up and switch course in the middle, when the middle means only a few days.

It is this panic-stricken conversation that drives many young art/illustration students—and hobbyists—into a manic pursuit of photo-realistic drawing skills. We think that in order to be respected by our peers, by our professors, by the “non-creatives,” we need to be able to produce a carbon copy of a pineapple. While skills like this are incredibly useful in any art practice, young and budding creatives often lose so much in attempting to chase down realism. When we could be developing our creative process, our imaginations, our risk-taking, we are instead painstakingly copying strands of hair.

But you know what? Photo-realism for the most part is really boring. We all know that person who can draw celebrities in stunning likeness. Their drawings are amazing at first, but it gets old really fast. If your work looks like something out of a Lee Hammond how-to-draw book, you should be very worried. Your best hope is to get a job in caricature, because very likely, your art lacks personality, voice. And in an increasingly technological world, people respond to a sense of humanity, not automaton-like reproduction. It is for this reason that I ask us all to stop screwing around with perfectionism and start experimenting with what we can tell the world in our own unique way.

Out of kindness, I won’t call out anyone working from a yawn-evoking style, but I do want to present a few illustrators who are incredibly successful in working from an imperfect style.

Our first Imperfectionist is Gemma Correll:

I would classify her work as little more than doodles, but Gemma is keeping busy, and I’m following her across several social media sites. Why? She’s funny, there’s a big market for “cute,” and her drawings really capture her subjects. It’s weird to see a picture of a person after you’ve seen one of her “doodles” of them; you realize how closely she examined their behaviors or physical attributes.

I can’t wait to see new work from David Fullarton (above). His handwriting is downright messy, but his images are so visceral, often scathing, so full of texture that they seem tactile. It looks like he just dumps his office supply drawer on his desk and goes to town.

Mike Perry’s work will look familiar to anyone following illustration. Mike has been crazy-big in the illo world for the past few years; he is one of the most-imitated illustrators out there right now. He has doodled on an EAMES chair for goodness sake. This guy is making bank off of his doodle-esque style because he loves it. He invests passion, and he has certainly benefited from being sincere (and kind, and humble; rarer than you’d think in creative fields).

So, what’s the difference between quirky and just messy?
There’s no formula, obviously. Quirky seems to happen when the illustrator/artist has a strong point of view. When they have a profound sense of self, that gift of capturing the “essence” of a subject, or the ability to truly make you laugh, that’s a successful Imperfectionist. It helps to know the rules too, in order to break them beautifully. Sloppy work happens when we borrow song lyrics and second-guess our composition. Don’t do that. Get your own ideas.

A challenge:
If you are passionate about art, and would love to design/illustrate/make personal art for a living, keep practicing. Keep honing your craft. But above all, work from a place that is honest, that is unique to who you are. People gravitate to sincerity. It serves the artist, the client, the viewer best when a touch of humanity is held in highest regard. Don’t let anyone sass you because you don’t draw exactly the way Joe Muscle-Cars does. Take a deep breath, return to your brushes or pens, and feel sorry for all the self-loathing haters.

All images used under the principles of Fair Use. Artists, please let me know if you wish to have your work removed.

Around this time others in the mobile group began planning the next versions of all the mobile applications so my teammate and I rushed to begin work on the 2.0 release of Grooveshark for Android. My primary responsibilities were with the player and its various systems–the player cache, offline cache, and other related things.

I learned Java and the Android framework at the same time and along the way encountered what I consider to be several annoyances and shortcomings with and of the Android platform. While on the whole I find both Java and Android a pleasure to work with, some things need improvement.

I initially wanted to compile a Top n list of problems but after writing the first few I found that I had too much for a single post so I’ve chosen to spread these out across multiple entries. Of any of my complaints I’m more than willing to admit to ignorance if it turns out that I’m just doing it wrong. So find fault if you can.

1. MediaPlayer doesn’t accept an InputStream

   Grooveshark for Android does much more with music than just play it. We save to cache recently-played songs, pre-buffer enqueued songs, and allow users to save songs to an explicit “offline” cache for listening when they’re not connected to a high-speed data network. Two of these, saving to a recent cache and saving to an offline cache require that we do more things with an MP3 than simply play it. The Android MediaPlayer object accepts only three sources of audio data, or rather, supports only three ways to play an audio file. One can give the MediaPlayer a URL to a file, open a local file, or use a ContentProvider, which is useful if the audio data is embedded into the application’s installation package (APK).

   It would seem that the first two methods, that of playing from a URL and from a file would suit the Grooveshark application’s needs well: for playing live streams we would provide a URL to the song on one of Grooveshark’s stream servers, and for playing offline cached songs we’d simply direct MediaPlayer to open a file on disk. However in both scenarios these input sources do not provide for everything we require.

   In the first instance we can play from a URL without problem but once this song is played, we cannot access the downloaded data in order to save it to a recently-played cache. Doing this is necessary because if a user has a few songs enqueued, plays one, skips to the next song, then skips back to a previously listened-to song, we do not want to download this song again. Users do not expect that we’d need to download the song again, having just listened to it. When skipping back there would be a noticeable lag as the song buffered again and we’d be unnecessarily transferring data that we’ve already downloaded. Not everyone has an unlimited data plan and it seems that in the near future unlimited data plans may become unavailable anyway.

   Because there’s no way to access the MediaPlayer’s data once downloaded, we could use a URL InputStream to download the file and pipe the stream both into the MediaPlayer and out to the disk. This would allow us to both play the song and save it for later use. But because MediaPlayer does not accept an InputStream, this cannot be done. The only thing you can do with a URL is to play it.

   In the other instance, that of saving a file to disk for offline playback, we could download the file then pass a FileDescriptor to the MediaPlayer. MediaPlayer does allow for this. However we need to encrypt the file because we wouldn’t want users to simply be able to mount their phones on their computer and copy their offline songs elsewhere. If MediaPlayer accepted an InputStream, we could wrap the File’s InputStream in a FilterInputStream which would decrypt the file as it is played. But again we cannot do this. Arguably we could first decrypt the file to a temporary file, then play this file, but this would make available an unencrypted MP3 for a time and on older phones would produce a noticeable lag as the file was decrypted and written-out to disk before playback could begin.

   Others have found this MediaPlayer deficiency to be a problem and a bug was filed with a supposed fix. InputStreams can now be played with the new AudioTrack object first made available in Android 1.5, but AudioTrack can only play raw PCM data, not an MP3 source, and as far as I can tell, to play an MP3 using AudioTrack the MP3 would need to be decoded in software as no hooks to the underlying MP3 hardware is provided (if there even is any, I really don’t know).

   A proposed solution to this shortcoming is to run a local HTTP server which can manipulate the incoming and outgoing data in any way it likes. Ultimately this is what I ended up implementing. The application runs a thread which downloads a song, encrypts it as it writes it out to disk, and passes it along to the MediaPlayer object, sending the necessary HTTP headers as it connects to localhost. A stupid fix but it works.

2. There’s a major bug in OpenCORE

   OpenCORE is the underlying media framework on Android. It’s what the MediaPlayer and other objects use to play audio and video data. Like other parts of the Android API it ships with the phone and save firmware upgrades and patches from Google (assuming Google sends patches over-the-air, which I don’t even know if they do, and they probably do not), what comes on the phone is what you get.

   Unfortunately there’s a major bug in OpenCORE that prevents high-bitrate files from playing.

   The MediaPlayer object has several states that it enters into and leaves when it is directed to play audio data. When you provide a data source to the MediaPlayer, it enters into its “preparing” state. At this state it buffers data until it detects that it has enough to play the data source, audio or video, uninterrupted. Or rather, that it has buffered enough data that it can start playback without playing past its buffered amount and then pausing while it fetches more data.

   When trying to play certain high-bitrate MP3s, MediaPlayer never leaves its preparing state, never enters into the “prepared” state, and so playback never begins. The song will appear to buffer forever. In some instances it will buffer the song almost completely but it never believes it has enough data. This is a documented bug and I don’t know if there’s any way around this.

   The Grooveshark “Now Playing” screen shows buffer progress and player progress and when this bug exhibits itself, to the user the application just looks broken. It’s infuriating, embarrasing, and unfortunately seemingly out of our control. This seems to affect upwards of fifty percent of high-bitrate files, but the most frustrating part is that this problem cannot be reliably reproduced for any given file. You can usually stop and start playback (by pressing pause and play) a few times and the song will eventually play. If the problem was because of how the MP3 is encoded, I could possibly manipulate the MP3 data as it comes across the wire before it is sent to the MediaPlayer, but I can’t seem to find a pattern or a trigger for this problem. So I’m stumped.

   In the eleventh hour before the release of Grooveshark 2.0 for Android I added a “prefer low-bitrate files” option, defaulted to enabled, to the application’s settings. This is only a band-aid of course, but it at least diminishes the problem. Unfortunately all songs on Grooveshark aren’t yet transcoded, so the problem still manifests itself from time to time. One possible fix is to run a watcher thread that monitors bytes downloaded and MediaPlayer state, and if the file is high-bitrate and a threshold percentage of the total file is downloaded but the MediaPlayer has never entered the prepared state, to start and stop playback until it does.

More to come in part two.

Here’s the guts of the email (obviously removed some content for privacy):

mood: Impressed
feedback report:
Nothing too contributary to say to be honest.

Just that your product is AMAZING.

It’s literally changed my entire view that every flash application is buggy and unreliable, you guys have done an absolutely stunning job. It’s so bug-less it’s suspicious!

Keep up the great work!

So, what are we supposed to take away from this? That we’re really good at what we do. Or maybe there’s something else we can glean from this comment. Users expect flash to be “buggy and unreliable”. Let’s review some common complaints that people (including myself) have thought about flash.

It takes forever to load

Typically a lot of flash applications have these front and center. But the problem is the typical programmer makes this dead simple and almost pummels the user visually with the “holy-shit-this-is-a-loading” screen. With the user unable to even perceivably able to interact with the site, the wait is made more apparent. I think primarily the difference between flash and other web applications is that the user already gets an instant layed-out interface and they see the page loading in, therefore it feels more responsive.

Realistically that up front cost of loading things in makes the application feel more responsive later in the applications session lifetime. If you were to compare the actual loading times between flash sites and normal sites I think you might be surprised if you used a stop-watch (or firebug).

It has annoying intros, with not a lot of content

I have to agree that this is super annoying. I simply loathe sitting through a preloaded intro with no perceptible way to skip only to be taken to a sub-par website. Intros have more or less faded in time, but watching horribly animated, boring segues has weighed on peoples perception of flash. There is a certain level of taste to be considered. Let’s not blame flash for others’ poor taste. Moving on.

It’s always Glitchy / Buggy

Pretend I am told to make a desk and I am provided with all the equipment I need and then some: hammers, screwdrivers, nice oak wood, etc… The problem is I have never made a desk and not a very good carpenter, so I hack it together. The desk I make turns out ok, is functional, but not quite what I wanted, and now the varnish is chipping off.

So, instead I buy a desk from IKEA, and have to assemble it. The desk is packaged in a really cool way (I recently bought a chair from their in a stair-case package) and it takes me a couple hours because it comes with dead simple instructions.

What I’m getting at is that Flash is a great set of tools. If I’m a great carpenter (hire me) the desk is going to come out better than something I bought, because I got to make the desk I wanted to from the beginning.  Heck, if I wanted to I could’ve made a matching bookcase and hutch, and with the scraps a stylish spice rack for my girlfriend. Sweet!

But, if you’re a bad carpenter, you’re going to have a horribly buggy misshapen turd. You have way more points of failure. IKEA is that package (e.g. wordpress) people get when they want a quick fix, and not a lot of customization. There are fewer ways to screw it up.

So, maybe what we need to take away from this is that programmers and not their tools which are “buggy and unreliable”.

I on the other hand am totally gay for flash, but that’s because when I originally wrote for the web in HTML/JS/CSS it was slowly killing my soul.  I have and still consider myself pretty darn good at writing clean well-formed markup, making some custom components for jquery (I actually liked mootools for a time), and awesome at skinning sites in CSS.  But, all while doing this it never for once felt like real programming.  And, that’s what makes me think that this particular trio is really good at: creating sloppy, unmaintainable spaghetti code. But sometimes, that’s ok.

Heck, most of the time that’s ok.  The web (initially) is supposed to be open and easy for people to get their message out there, and that’s exactly why HTML began as a dumb way to publish data.  Not everyone has to make mind-blowing applications.  HTML in its initial form never was about looking awesome or protecting content.  So what we have now is adding patches on top of a platform never intended to be commercial and flashy.

However, on the other side are the people that want to send a message, provide a product of content, and deliver a brand or platform.  It’s applications like these that defy the trend of openness and may never be able to reconcile with standards, which is what’s really funny about Apple: releasing a demo for HTML5, when it was more or less a demo for Safari.

I am not saying HTML5 and JavaScript is a bad thing; I’m saying it’s not something good for production of commercial code.  If HTML5 and JavaScript is so great, then my friends shouldn’t have to bother writing applications for the iPhone or iPad in XCode (sorry Adobe), when I can have them develop for Safari.

Things about flash that make me shit rainbows:

1. Compiled code
2. Object oriented
3. Distributed player with high market acceptance

So what is it that I want from standards? How about something better than and more “well-formed” than JavaScript; maybe even be able to send byte-code to the client, which is exactly why flash has been thriving for years: its been filling in the gap that HTML and JavaScript was never equipped to serve.

What is great about array collections is they handle all sorts of stuff for you, such as binding and updates. But what’s really great is the ability to differentiate a view from the underlying data, which allows you the use of filters for features like active searching on a collection.

So what I needed was a way to click show more and it would reveal the next set.

And extend and implement…

private var _pagesVisible:uint = 1;

[ChangeEvent("collectionChange")]
public function get pagesVisible():uint
{
     return _pagesVisible;
}

public function set pagesVisible(value:uint):void
{
     // allow it to be ready for soon to be populated data
     if (value <= (pages+1)) {
           _pagesVisible = value;
           this.refresh();
     }
}

private function feedFilter(item:Object):Boolean
{
     var isIncluded:Boolean
          = (source.indexOf(item) < PAGE_SIZE * pagesVisible);
     hasMorePages = !isIncluded;
     return (isIncluded);
}

Some people have already pointed out that Adobe has been moving Flash to be more and more open over time, including the open screen project, contributing tamarin to Mozilla, and Flex being completely open source. That’s all well and good, but people seem to be forgetting that historically, Flash had a very good reason for being closed. If one remembers back to the early days of the web, the wild west era as I do since it was such an exciting time for a young whippersnapper like me, one must only think back to what happened to Java to realize why making Flash closed was a very smart move.

For those who don’t remember or weren’t on the web back then, I’ll share what I remember which may be a bit off (that was quite a while ago now!). I’m talking about the hairy days when Netscape was revolutionizing the world and threatening to make desktop operating systems irrelevant and Microsoft was playing catch up. Java was an open and exciting platform to write once and run anywhere, promising to make proprietary operating systems even more irrelevant.

Of course, what ended up happening was that Microsoft created their own implementation of Java that not only failed to completely follow the Java spec, but added on some proprietary extensions, completely breaking the “write once, run anywhere” paradigm and helping to marginalize Java on the web, something it seems Java on the web has never fully recovered from, even though Microsoft has since settled with Sun and dropped their custom JVM after being sued.

This directly affected my personal experience with the language, when I took a Java class at the local community college while I was in high school. I wanted to write apps for the web, but even basic apps which compiled and ran fine locally would not work on IE, Netscape or both, the only solution being to spend hours fiddling and making custom versions for each browser. Needless to say, I quickly lost interest and haven’t really touched Java since I finished that class.

The atmosphere has certainly changed since those early days, and I don’t think it’s nearly as dangerous to “go open” now as it was back then, so Adobe’s choice to open up more and more of the platform now makes perfect sense, just as the decision to keep it closed until relatively recently also made sense.