Just add jcl-over-slf4j to your classpath and you’re golden. If you’re using Maven to manage dependencies, this is as simple as adding this dependency to your pom.xml:

<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>jcl-over-slf4j</artifactId>
   <version>1.6.4</version>
</dependency>

First of all, there seems to be a common misunderstanding as to what this chart actually represents. The chart is titled “U.S. Job Loss”, which is a half truth. Job Loss is actually just a subset of the data represented in this chart. The reality is, the figures behind this chart actually represent the 1-month net change in employment. A negative net change represents a loss in employment, and a positive net change represents a gain in employment. Since this chart largely depicts negative net change, it’s not wholly misleading to refer to it as a job loss chart, but it’s not 100% accurate either.

Now, the biggest issue with labeling this as a “Job Loss” chart, is that it means the vertical axis would have had to change. In the context of “Job Loss”, a negative figure would actually represent a gain in employment, since a loss is inherently negative. For the chart to be contextually accurate, the y-axis should have been inverted, as a positive value for job loss equals decline in employment. Although, to accurately communicate the true value of the chart, it should have been named like so:

These are pretty unforgivable errors from a data visualization standpoint. However, neither error alters the underlying message here, which is that under the Obama administration, the rate of job loss has decreased. The key observation here is that what we’re really looking at here is the rate of change, cumulative unemployment is a completely different story.

Unfortunately, bar charts aren’t really the best way to show the progression of a rate of change over time. A much clearer picture is illustrated with a line graph.

In this visualization, we can see that the rate of job loss under the Bush administration got progressively higher as time went on. Under Obama, the rate of loss, has decreased and almost leveled out. So, while the cumulative loss is high, the rate at which that cumulative loss is changing has gone from exponential increase, to plateau, and at the current rate of change should actually begin to decline.

My suspicion is that a committee sat down, looked at a “1-Month Net Change in U.S. Employment” chart, and worried about alienating Joe Blow with complexity. As a result, this chart is controversial because in attempting to over-simplify for the general populous, it has been badly/inaccurately implemented. This is unfortunate because the message it’s trying to send is valid, and is an important one.

Long story short, the chart is mislabeled, and isn’t the best way to visualize the net change in employment, but this does not mean the chart is intentionally misleading, or painting a false picture. The core message is true, albeit confusing because of this poor implementation.

Here are my responses to the five of the most common complaints I’ve heard as a result of unveiling of their latest creation:

1. No [insert technology port here].
   
   Are these the same people who complained when the laptops stopped shipping with floppy drives?

   We are very quickly moving into a world without wires, and in a world without wires what good are ports? I know, we’re not there yet, but isn’t that kind of the point? Why get upset over no HDMI, when you can stream to your TV, while holding the device on your couch to control the playback?

   Apple is imagining a world without wires, so it shouldn’t be surprising that they’re eliminating ports.

2. No multitasking.
   This is essentially a media device. Are you going to work on a spreadsheet while you watch a movie? Are you going to read a book while browsing your photos? Set aside the fact that the notion of multitasking in general is somewhat absurd, there are very few scenarios where it makes sense to have multiple applications running concurrently on this type of device, and far fewer that I’d be willing to sacrifice stability and battery life for.

3. No Flash.
   Let’s look at the value Flash brings to the table. Ok…I’m struggling. Flash was instrumental in the widespread adoption of online video, but it will become increasingly less relevant in that context thanks to HTML5. Advertisers love Flash banner ads, condo builders & nightclub owners love 40mb full Flash websites, but aside from these types of applications, which frankly, I can do without, Flash is on the verge of outliving its usefulness.
4. It’s just a big iPod Touch.
   Well yeah, of course it is. The point is consistent user experience. Apple does a good job of giving users what they expect when it comes to UI. When I explain OS X to non-techie Windows friends, I distill the conversation down to “If you can unlearn the insanity of Windows, and just play with the interface, it’ll usually do exactly what you think it should.”

   It would make no sense for the iPad to look, or feel different from Apple’s related devices. It would make no sense for it to have a dramatically different user interface. Many millions of us have learned how to use iPhone’s and iPod Touches, it’s what we’re familiar with, so why would they ever go out of their way to make us learn something new, consequently raising a barrier to adoption?

   The iPad technology is not new to us (conceptually anyway), but technology is never really the point with Apple. They see technology as a means to deliver a user experience, not as a feature list. In fact, if you go to any Apple product page, you’ll see that “Tech Specs” is always one of the last items in the navigation. This fact further illustrates the logic behind making “a big iPod Touch” – if a stellar user experience can be enabled by the same technology as an existing device, why change it?

5. The name sucks.
   Ok, I’ve got nothing here. The name sucks, and the alternatives aren’t much better. iSlate – technology that sounds like a rock.

To wrap up, come on folks, it’s Apple – you should know better by now. It’s their corporate mandate NOT to give the masses what they want. They spend a long time thinking about what we actually need, or better yet, what we will need, and they deliver time and time again. They create usable devices, then let the world figure out new ways to put them to work.

There are many things about Apple I love, and many I could do without. But I will praise them over and over again for their consistent refusal to submit to feature requests that aren’t in line with their vision.

Now that this is out of the way, let me say I think this is far from a perfect device. I do feel Apple really did it a disservice by omitting a camera. My guesses for the rational behind this decision are:

• they couldn’t get it to fit in a pre-determined case for the device
• the pictures produced by the iPhone’s mediocre camera look like crap on a 10″ screen
• it went directly on to the iPad 2.0 feature list as bait

It really is too bad, as I could think of endless business uses for the device…if it had a camera. It doesn’t take much to imagine the apps that could built for home inspectors, insurance field agents, physicians, trainers, landscapers, interior designers, journalists, etc. if the iPad had a built in camera. I guess we’ll have to wait until next spring when they release 2.0.

Here is the talk outline:

Programming Java applications is often viewed as less than pleasurable. This perception is exacerbated when enterprise Java frameworks are stacked up next to all the wonderful new web frameworks and methodologies available to developers today. Grails, a Java-based, agile web development MVC framework, may change all that.

In this talk, learn from a one-time skeptic how your team can use Grails to speed up project delivery, streamline maintenance and support, increase functionality and performance, allowing you to spend more time focused on business objectives in your next web project.

If this sounds like something that might interest you, register here!

Here’s a little video detailing my methodology, which includes, Evernote, and Preview with annotations to get the job done. Would love some feedback on my approach, and to hear about what works for you.

On the due date, you have the option of completing the task, or simply pushing the due date further out, but at least it has been brought to your attention that the task has been around for a while, and still isn’t complete.

I’m no expert, but I’ve had a few people ask me how I’ve been keeping my inbox empty, so here’s the strategy that has worked for me:

• I check email every 20-30 minutes, and I process it immediately
• processing means reading, determining if an action is necessary, then deleting or archiving
• sorting email sucks, so I use one archive folder and search
• if a follow-up action is required, I a) do it right away if I can do it in less than 5 minutes, or b) star the email for a reply, or move the task to a to-do list (I use Things)
• I don’t go back to my inbox until the email has been archived or deleted
• I set aside time before lunch and at the end of the day to write longer replies
• I write filters/rules for assigning labels to newsletters, digests, cron reports, etc. so they can be mass selected deleted

That’s it in a nutshell. It’s nothing revolutionary, it just takes some discipline, but I promise it gets easy, and makes staying organized much easier.

For the canonical source on email productivity, check out this guy.

That said, focusing on my design responsibilities, and ignoring the fact that application development is also a large part of what I do, I have struggled to describe what it is I do for quite some time. This is a particularly troublesome task when speaking to those who are not familiar with industry terminology. On a fairly regular basis, I see people who have similar responsibilities using a mishmash of acronyms as a title — UX, IA, IxD. The terms these acronyms represent are all completely valid, and represent distinct skill sets. I have nothing against these terms, and yet, aside from being a mouthful, they do little to help people (who are not in our industry) understand what we do. On the other side of the equation, we have people who are commonly referred to as graphic designers.

I propose that there are really only two types of design when it comes to software/web application development — Analytical & Emotional. Now, I realize the term “Analytical Design” would present itself as an oxymoron to some, but let’s come back to that in a moment. In design, how something functions, and how something makes you feel can be considered separate, but very tightly coupled aspects.

When we observe something on a superficial level, something about what we see (be it colour, imagery, or something much less obvious) sets off fireworks in the limbic system of our brain and we’re compelled to feel something. This is a subconscious reaction — we don’t decide that the colour red will make us feel passionate, it just does. This uncontrollable reaction is what makes design so powerful, and at the same time, so unpredictable. I consider these elements to be Emotional Design, or you may know them simply as art.

How an application works, how it’s organized, and how you interact with it will also elicit emotion, but in a much more obvious, and explicit way. As we’re using something, we expect it to work in a particular way. If it doesn’t function in the way we expect it to, we decide that it is wrong at some level, and this frustrates us. Unlike Emotional Design, when the inverse is true, and something works exactly as we’d expect it to, we usually have no reaction. Of course it works that way! Why would it work any other way? For this reason, most people cannot explain why an application works well — they just know that it didn’t frustrate them.  This is because someone took the time to stop and think about all the ways that an element could be used then logically calculated how it should be designed so that works intuitively. This is Analytical Design.

There is no question that there is spillover between the two disciplines. This concept is perhaps best thought of as a spectrum with Analytical Design at one end and Emotional Design on the other. Will these terms help people better understand design disciplines? Perhaps not, but I believe their meanings are more intuitively obvious and distinct than what we’ve been using.

I first became interested in the open data dialogue back in early 2009 at ChangeCamp in Toronto, which was an event aimed at re-imagining government and citizenship in the age of participation. ChangeCamp spawned ChangeEngine, a project where a group of citizens (including myself), imagined a geo-aware issue tracking system, aimed at bringing communities together to solve problems and to provoke systemic change.

As the launch of Toronto’s open data site approached, some of my colleagues at Architech Solutions and I, met with Mark Kuznicki (organizer of ChangeCamp) to discuss the possibility of building a community companion site to the city’s site. We all felt there was a need, and so DataTO was born.

The Monday following our Friday lunch marked one week to go until the city’s launch date and Mark and I met for our first planning session at the Centre for Social Innovation in Toronto. At this meeting we focused on nailing down our user roles, scoped out the feature set for the initial release and roughed out some layout concepts.

Having had a full-day meeting crop up for later in the week, I was now down to 3 days of build time. Time to get going. Given the time constraint, I decided that building the app with PHP/CodeIgniter simply wasn’t feasible, so I decided to go with Grails, a Java-powered web application framework, which I had been tinkering with for a couple weeks at the time. This decision was not taken lightly, as I would not classify myself as a Java developer, but the fact that Grails utilizes Groovy, an agile dynamic programming language for the Java platform, and that Grails is so well suited for agile development, I felt that it was the way to go.

For those of you who are not familiar with Grails, think of it as the Java equivalent to Ruby on Rails. I won’t get into Grails vs. Rails in this post, so suffice it to say they are comparable, each with pros and cons. While Grails is relatively unknown at the moment, I suspect it will gain in popularity very quickly due to it’s power, flexibility and ease of use.

Having decided on a framework, I quickly spec’ed out the app, and started the build. Since Grails makes it so easy to build object models and generate scaffolding, I had more or less completed a working wireframe by the end of the first build day. The biggest benefit to having such an easy build process is that more time is left for UI, which is clearly very important to me.

In fact, the second build day was spent largely on UI. It was clear to me at this point that some of the features we had planned on being in the initial release were not going to be ready in time. So I decided to pare back, and focus on making a select few features as solid as possible, rather than diluting my efforts, and producing a greater number of mediocre components.

Day 3 of the build came and went very quickly, and was focused on skinning the application and debugging. The week had come and gone, and one daunting task remained — deployment.

Not being a Java developer, I wasn’t familiar with the various containers, but decided to go with Tomcat based on reputation and available documentation. I installed Tomcat 6 on a MediaTemple Dedicated Virtual server behind Apache and deployed the application the night before launch. This is somewhat of a “budget” setup, but it has held up well for this proof of concept. Ideally, I’d like to migrate to Amazon AWS for the infrastructure, but that will require funding (hint, hint).

Since launch, the site has received thousands of visitors from all over the world. It currently has over 200 members, and is approaching 100 requests for datasets. It has been mentioned in numerous major publications, and was profiled on The Discovery Channel’s Daily Planet.

I was extremely reluctant to put the site out there in it’s incomplete state, as I’m somewhat of a perfectionist, and I was worried that it might be a poor reflection of what I do, but I really couldn’t be more pleased. I’ve really enjoyed this as a learning opportunity, and a chance to do something good for the community. The site still has a long way to go, but I am continuing to work on it and can’t wait to see where it goes.

There have been good times and bad, and many, many lessons learned. Ultimately, I’m proud of the path I took. Through pure stubbornness, I managed to bypass post-secondary education, by working my ass off to learn what I needed to know to get the job done (often after I had already sold it). In many ways, I attribute my success in this business to this fly or fall approach because it kept me on my toes, always learning, always hungry to improve my skills, and always ready to take on new challenges.

Looking back, I know that I went about things the hard way. A wiser, less obstinate person would have gone about things differently, but then I wouldn’t be the person I am today.

For the last year and a half, I have been working with The Blog Studio. My time with them has been very important to me for a lot of reasons. It freed me of my solitary home office, and got me out into the world, working face-to-face with people again. The life of a freelancer, especially in this industry, can be a hermetic one, and working with Peter, Lucia and Mike was a very welcome and necessary change.

Next week, I start a new era of my life as I leave the world of contract work and venture down a new, exciting path. A remarkable opportunity landed on my lap a couple weeks ago, and enticed me to make some life altering decisions.

On Monday, I will be starting work, as an employee (for the first time since directing cars in the parking lot at the Stratford Festival as an early teen), with Toronto-based Architech. Architech builds kick ass software. They are a team of people who are extremely passionate about building amazing applications for business and I could never make the jump into a full-time position like this without sharing core beliefs and passions like I do with Architech. I’m confident we will have a bright future together.

Needless to say, I’m extremely excited, and can’t wait to see where this new direction takes me.