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’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.

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.

However, it’s important to note that validation errors should only be shown at the appropriate time. Today, I was adding a new contact in Gmail and I noticed something odd when I was typing in the contact’s email address. The background of the email field immediately went bright red as soon as I had typed the first letter.

Obviously, this caused some confusion. I quickly realized that I was being notified that the field did not contain a valid email address (because I was in the middle of typing it).

The point I’m driving at here is that you shouldn’t tell your users they’ve done something wrong until they’ve actually done it. Field validation is usually best left until the user has moved on to another field or performed another action which signifies that they believe they’ve completed the field in question.

Note: One exception to this general rule of thumb, is when a user enters an invalid character in a field (eg. a letter in a phone number field). In that case, it may make sense to let them know right away.

Update: Luke Wroblewski just wrote a great article on inline validation on A List Apart. The portion on testing when to show inline validation
 bears particular relevance to this post.

What’s in a name?

For the longest time I was intensely frustrated that I couldn’t find available domain names in the project management realm. Before long I found that I was starting to settle for names that didn’t really mean anything, and were hardly memorable.

Then I started to take a more systematic approach to finding a name. Aside from all the standard naming criteria, I decided that I wanted the name to represent:

1. More than just tasks. What I’m building is not a to-do list manager, it’s a much more intelligent project management assistant (a lab partner, if you will).
2. More science than art. Typically, project management is a lot of guess work. I aim to replace much of that guess work with tangible, data-supported analysis.
3. Simplicity & fun. Ok, it’s not likely that managing projects will ever be “fun”, but if it’s not “painful”, that’s a start.

So, with these objectives in mind, I started looking for words, which related to projects, planning, and organization. In the English language, there are few (ok, none), which are short, memorable and fun. So, I started looking at other languages—all of them.

Kito (key-toe) • is a Japanese word, which means “project” or “plan”. I thought, how ideal is it to use a word, which comes from a culture of organization, simplicity, and structure to represent a project management application?

Lab • alludes to the fact that this is a place, not only where work is done, but where it is done in a consistent, measured manner. It’s a place where there’s method to the madness that is project management.

Now that I have the name chosen, I will be writing much more about the development of this app. Please feel free to follow www.twitter.com/kitolab for updates.

Also, I’d love your feedback on the name/logo!

Let’s first assume we’re dealing with a client who is open to stepping outside their comfort zone and adopting a new engagement framework with you. Let’s assume they’re willing to make themselves available for regular planning sessions and demo/review periods. Let us also assume that they’re willing to be held accountable for their role in the project’s completion. Let’s assume our client meets all these requirements, what do you do when the cost of educating the client on the methodologies, the processes, and the language of Agile is greater than the reward of putting those tools to work?

To make matters worse, I have found that the majority of the organizations I’ve dealt with in my career were not willing, or in some cases even capable, of meeting the afore mentioned requirements, nor did their projects posses what I deem to be the characteristics of a project, which would benefit from Agile.

I am by no means an expert on Agile, in fact my working experience with Agile is minimal — largely due to these substaintial stumbling blocks. Agile gurus, here’s your cue to jump in and tell me why I’m wrong. Please demonstrate how Agile addresses the issues I’ve raised. I’d love to be way off base on this, it’d sure make my life a lot easier.

In the meantime, enough about why Agile doesn’t work in these scenarios. Let’s get to the fun part: What does work?

Setting out to design a better way of managing small to mid-sized projects, I believe there are several criteria which must be met, on top of several of Agile’s parameters:

1. It must be easily, and quickly adoptable. When I say quickly, I mean pick up and go with no prior knowledge.
2. It must utilize familiar language. Part of easy adoptability means we must avoid new terms wherever possible. Terms, processes and tools must totally self-explanatory because no one wants to go back to school for the pleasure of working with you.
3. It must cater to different levels of client involvement. No company is the same and trying to force a client to do something that is dramatically different than what they do routinely does not work in the course of short term engagements. We can’t always have dream clients who can provide continuous, and timely feedback so we need a system that minimized the expense of less than timely interactions.
4. It must come with a tool. I truly admire the spirit of Agile’s “individuals and interactions over tools” notion, but let’s face it, even the most skilled carpenter isn’t very useful without his tools. The tool must be flexible and capable of adapting to meet the needs of variable of usage, but the tool must exist.

In my next post, I will begin to isolate the bottlenecks I see in the Agile process, discuss how they adversely affect small projects and start to explore alternatives. Until then, aside from the four criteria I mentioned here today, which characteristics must a process posses to work for your business?

Download: 2560px x 1600px