June 15th, 2010 | Categories: News, Rant, Web Development | Tags:

I just stumbled upon this opinion column in Smashing Magazine, which claims that Web Designers should not use ad blockers. Along with a bunch of lousy arguments, the author fails to account for my two biggest reasons for using ad blocking:

  • Resource Consumption (time and bandwidth) - it makes the web faster
  • Ads Mostly Suck (and are equally ineffective)

First, let me say that rather than adding adblocker software or plugins, I use Dan Pollock's host file: http://someonewhocares.org/hosts/. Instead of blocking ads directly, it redirects ad server domain resolution to localhost. It's fast, it's free, and it doesn't take up resources running any extra processes.

A note from his file explains a bit of why it's useful:

# Use this file to prevent your computer from connecting to selected
# internet hosts. This is an easy and effective way to protect you from 
# many types of spyware, reduces bandwidth use, blocks certain pop-up 
# traps, prevents user tracking by way of "web bugs" embedded in spam,
# provides partial protection to IE from certain web-based exploits and
# blocks most advertising you would otherwise be subjected to on the internet.

I started using this when I moved to Germany and ended up with a mobile internet connection for my main line, which is dirt slow. I couldn't afford to waste my 5GB/month capped usage on ads--or slow down my general use with waiting for all the analytics and ad servers to resolve and load (yes, I block analytics too but that's another post with a whole new topic).

But now that I've been using the hosts file for a while I've started to think that this is like when I abandoned television in favor of the internet for viewing videos. I got sick of the commercials. So much that I joined a revolution in a new medium that allowed me more fine-grained control over what I consume and how I consume it. I can't watch TV anymore--the commercials are insufferable.

Yes, I'm a Web Developer, and yes, I use ad services on my sites--and I feel genuinely icky about it (but it pays for my hosting and gives me pet-project freedom). So, please, block my ads. If you don't want them, I don't want you to have to suffer them. You probably aren't the person who makes me money on my ads anyway.

But here's the kicker: When I find that there's an ad company I like, who does things right, I allow them through my hosts file filter. Sadly, I haven't found a decent service for sporting ads that don't suck on my websites.

Commercials need to be better. Ads need to be better. Ad services need to be a hell of a lot better. A few ad agencies have caught onto this, creating viral advertising that people actually WANT to consume. I'm sure you remember the Sonia Bravia superball video. People didn't block it. Instead it got passed around.

Here's another ad-woth-watching by Nokia that gives me goose bumps, which I found at the end of a TED.com talk:

In closing, if you don't want people to block your ads, make them not only worth consuming but sharing, make the ad servers fast and don't put them in the way of what users actually want to consume. Make your ads into content that is served with the other content users want--so they can't block it without blocking everything else they came to see (all of it hopefully as good as the rest). If your ads are the content that consumers want, consumers won't worry about blocking it. Besides, if consumers want to block your ads, face it, your ads suck.

June 7th, 2010 | Categories: Rant, Web Development | Tags: ,

Situation

A user initiates an action that will take some time to complete. This happens all the time, in all sorts of applications. The most common places you will find this are downloading and installing. Downloading is the easiest target for improvement so this is what I will focus on here.

The system wants to report to the user how long they will have to wait before the task is complete. This is usually presented with a progress indicator, a speed report and some form of time remaining.

Problem


If you've seen progress indicators like this before, you've no doubt suffered watching the time remaining report shift from 10 minutes to 1 hour, back to 10 minutes, up to 2 hours in what looks like an endless loop of uncertainty.

What the System Knows

  1. The total amount of data to be processed
  2. The current processing speed
  3. The total remaining amount of data to be processed
  4. The total time spent processing so far

The problem is that programmers tend to only pay attention to the first 3 pieces of information available. The fourth is outright ignored, which is sad because it allows us to write much, much better progress indicators.

Solution

What we tend to show is Time Remaining = Data Remaining / Data Speed
Example: 200MB / (1.2MB/s) results in 166.67 seconds remaining (or 2.8 minutes).

While this is valuable for the user to know the current speed and the time remaining at the current speed, and presents a fairly accurate report for users with constant download speeds, it's often an unrealistic estimation of the real time to completion for anyone with variable rate downloads. In the case above where I was downloading a trial of the Adobe CS5 Suite, I was on a broadband connection (at a cafe) with a variable availability in transfer speed. My download shifted constantly between 50KB/s and 3.2MB/s, causing the weak progress indicator to jump back and forth between almost a day and less than an hour. But if the download manager calculated my AVERAGE speed, it could give me a much better indication of how long I can expect the action to take. And the great thing is that as the download progresses, it has the option of capturing and calculating a much more realistic number. In the end, the download took about 2 hours and 40 minutes, which ended at a time that the progress indicator never seemed to even come close to reporting.

Although, it could factor in some quite complex numbers, calculating variations in rates, all of that complexity is unnecessary--and probably not that useful. Really you just need this:

Rate = Time Spent / Amount Complete
Average Time Remaining = (Rate * Total Data) - Time Spent

Example:
We've downloaded 100MB / 200MB and, so far, it's taken 12 minutes:

var totalData = 200; // constant
 
// vars to be updated at intervals
var timeSpent = 12;
var dataComplete = 100;
 
// calculate an estimate for the average time remaining
var dataRemaining = totalData - dataComplete;
var rate = timeSpent / dataComplete;
var avgTimeRemaining = (rate * totalData) - timeSpent;
 
// show it
console.log(avgTimeRemaining);

So the avgTimeRemaining would be 12 minutes. The current speed might be different (probably is) so it would really be nice to see both the current rate and estimate at the current speed and the overall rate with an estimate that considers the shifting variation in speed. The closer you get to completion, the more accurate this second calculation becomes.

In Closing

It's great to know how long I can expect something to take at my current speed, but it's much better if I can also see my average speed along with an estimate based on that information. Often, for people with variable rates of processing and downloading, the second calculation is much more helpful.

June 3rd, 2010 | Categories: CSS, JavaScript, jQuery | Tags: , , ,

So, I drank a whole pot of coffee yesterday. And it was a black, black, pot of coffee--like the soul of an exploded quasar, black. Twelve hours later (midnight), I was buzzing. So, what did I do? I wrote a jQuery library.

Check out the project on github: jquery.playingcards.

Check out a demo here. The demo just writes the cards to the page and allows you to click them to flip the cards. Will add buttons for the other behaviors (shuffle, pile, etc) soon.

How?

I used jQuery as a base (it's a jquery plugin). However, this code could easily be extracted out to be used with any other JavaScript framework or even stand alone.

The cards are drawn mostly in CSS, using images only in the case of face cards--though, I have committed an open source card font that will eventually be implemented as a configuration option in place of the css/images. The images are courtesy of David Bellot with his awesome SVG card set.

Why?

  1. I wanted to use github since just about every cool project I've seen in the last 6 months is hosted there.
  2. I wanted to make a public jQuery plugin (made a few before but only proprietarily for companies so I couldn't share them)
  3. When interviewing developer candidates, I frequently ask that the person code a deck of cards with a few simple methods (init, shuffle, deal) and I realized that although I had thought a lot about this problem and seen other peoples code, I hadn't taken the time to write my own
  4. Doesn't everyone need a deck of cards? Why not have one in your JavaScript arsenal?

Get Involved

There's still a lot that can be added to this library. If you want to develop a game pack extension for it, let me know. Wouldn't it be cool to have a generic deck of cards and set of rules for every card game known to man, all written in JavaScript? I think so.

ToDo

  • Buttons for running demo methods (shuffle, deal, pile, etc)
  • Handling for including card.ttf as a font replacement for the css images (if set in config)
  • Keeping track of hands/players? -- probably an extension along with game rules
  • Game rule packs (maybe these will extend a board that keeps track of hands, players, score, etc

Let the games begin!