Following the announcement of the iPhone 4S release, there has been an overwhelming negative response. Apparently the entire media (tech and mainstream), and most of the population, had convinced themselves that the form-factor of the iPhone was going to change yesterday. And it would seem that looks are all we care about.

To start, the iPhone having a drastically redesigned case only one year after it was initially released is pretty un-Apple. For how many products do you see Apple completely redesigning the form on a yearly basis? Correct: none. That’s not Apple. It may be what some people want from Apple (after all, when they do redesign something—or design something new—it’s almost always awesome), but that’s not how they work. They refine and iterate to a final design internally, then launch to the public and make incremental changes over time. If the initial form wasn’t elegant enough to stand the test of time (which isn’t very long in the cell phone market), it would not have been released.

So yesterday we were introduced to the latest and greatest iPhone: the 4S. Consistent with all of Apple’s products, it iterated on an existing design. Unfortunately, this is as deep as most of the analysis of iPhone 4S has gone. It looks largely the same, so it’s not a big deal. Yeah, maybe there are some little tweaks inside but it LOOKS the same! How will all the people you pass on the street know you have THE COOLEST, LATEST iPhone?!

But what was really announced yesterday was monumental. It’s obvious why Apple needed a slightly longer release cycle to get this iPhone to market. Everyone seems to be overlooking these major points:

World phone

Remember antennagate? Not only has Apple fixed the problem, they leap-frogged the concerns to offer a CDMA-GSM-capable world phone that intelligently switches antennae to optimize transfer performance. And it supports HSPA+, which means effectively 4G speeds (twice iPhone 4).

Camera

Sure 8 mega pixels is nice, but new optics and sensors, a collection of new software for facial recognition, and auto-leveling of 1080P video? I just bought a nice, new point-and-shoot camera a few months ago, but I wouldn’t be the least bit surprised if iPhone 4S out-performs it—particularly with video.

Processor

A5. Twice as fast a processor in a phone that was already universally considered to be the quickest, most responsive smartphone in the world. And if there was any doubt that iPhone was the greatest mobile gaming device available, that can be set aside now.

Battery

Not only is there a more powerful processor, heavier-lifting software and twice-speed data transfer, but battery life actually improved!

Interface

We saw hints of iOS5 over the summer and began to see how a new notifications center and deep Twitter integration could evolve how we use iPhone. Yesterday we saw how Siri could completely change how we interact with a device. This isn’t “read my touchscreen” voice control like Android introduced. This is intelligent, contextual, human language interaction. Remarkably, it was only 4 years ago that Apple redefined human-computer interaction with multi-touch. Now they have introduced the next major revolution in human-computer interaction. Siri alone would have been a monumental announcement. It will have enormous, far-reaching impacts in technology.

Sorry if you didn’t get your tapered case.

We can’t automate everything. But we can come close.

Often when we start a new project that involves applications or flows there is a baseline assumption that technology should handle everything–the user shouldn’t have to be bothered. As we diagram flows and sketch interfaces, there is a nagging thrust to push every bit possible off on the technology. Many times this is a good idea. I shouldn’t insist a user learn the format I use for dates and properly map it to the day they have in mind, or click repeatedly through a calendar to find their day. Technology is more than capable of parsing a date in almost any format the user prefers and converting it to the format I need. I put the onus on technology to automate the date formatting task.

But what about a more complex task? Or something that involves interpretation, reasoning, balancing alternatives and subjective thought? Where is the line–or is it even as clearly defined as a line?

There is a continuum from users doing the work (manual) to technology doing the work (automated). Historically, all processes start on the far left of the continuum as a manual activity. Automation is introduced when the manual process becomes tedious, repetitious, overwhelming or burdensome. The intention of automation is to make a process more efficient. Automation doesn’t inherently make processes more efficient, though.

How do you know when to automate?

Variability: how much repetition is involved?

Automation favors tasks that are repeatable. The more variability a task involves, the harder it will be to automate. Tasks with a limited amount of variability (<25% of instances involve an exception to the rule) may benefit from a partially automated interface that allows for adjustment at the user’s request. Tasks with no variability are excellent candidates for automation. Tasks with high variability (>25% of instances involve an exception) should probably be left to the user.

Volume: how many people do this thing?

The more people performing a task, the greater the benefit from automating that task. If a relative few have to perform the task, carefully consider whether the effort of creating a technological solution is going to be less than continuing with a manual process.

Effort: how much time does this thing take?

Tasks that consume a lot of time are good candidates for automation. Time is relative, though, as it can be compounded by volume. In a task with high volume, a few seconds may be a long time. In a task with low volume, it may take minutes, hours or days to have the same impact.

Bottlenecks: are current executors a bottle neck?

Generally, a task considered for automation is part of a larger process. If the task in question is the bottleneck–the step that slows down the whole process–it is a good candidate for automation. The effort of automating a task that isn’t a bottleneck may not be worth it.

Susceptibility: is an error more likely by lots of humans, or a few algorithm authors?

A manual process relies on each individual user to execute correctly. A technological solution doesn’t remove that susceptibility to error, it just transfers it to a small team of algorithm authors. Both groups are susceptible to making errors. When individual users make an error, it only impacts their instance of the process. If algorithm authors make an error, though, it impacts every instance of the process. Generally, a team implementing a technological solution will exhibit more care than a standard user, but it is still important to consider which group is more likely to fail in your task.

Critical: what are the ramifications of an error?

The potential consequences of an error go hand-in-hand with susceptibility. In the date picker example above, the ramifications are very minor. In other tasks, errors could result in much larger issues. If a task is critical, it makes consideration of susceptibility that much more important. If a task is not critical, the automation versus manual decision has much less impact.

In most cases, there is not a yes-or-no answer for whether to automate. The answer lies somewhere along the continuum from user to technological responsibility. Tend toward automation for that which is repeatable and known. Keep users involved when there is high decision-making variability or a degree of algorithmic complexity that would be cost-prohibitive to get right. Most situations will land between the endpoints: some components will be automated while others are manual. The trick is to find the ideal placement for your application along the continuum.

IA Summit 2011

This was the first time I’ve attended the IA Summit, and it came with some good, some bad and some in-between sessions. I love useful, actionable and applicable sessions, and many of the sessions fell short as they focused on theory and concepts but didn’t deliver something I could take back to my office and implement.  One session stood out.

How to make a DIY mobile user testing kit for under $200

Our friend Jakob Nielsen notes that the average success rate with a mobile experience is 59%. He notes that sites that are specifically designed for the mobile device are 64% successful – better, but not great. The numbers do go up depending upon whether they are “feature phones”, “smartphones” or “touch phones”. But the responsibility is on us, UX practitioners, to both create experiences that are appropriate for mobile devices and TEST them with real users on THEIR phones.

Why don’t we? Because testing on mobile devices is often expensive, awkward and not representative of real-life situations. You can buy complicated document cameras that cost thousands of dollars, screen capture software that doesn’t work on all devices or mounted table cameras that limit range of motion. But none of those options meets all necessary criteria: easy, cheap, repeatable, one-handed and flexible for various devices.

So, on the final day at the IA Summit I attended the “DIY Mobile Usability Testing” seminar. Belen Barros Pena and Bernard Tyers walked us through how to create a testing kit using pieces from an erector set, some blue tack and a couple cameras – all costing under $200. Now this is useful stuff!

The Ingredients:

• 4 Erector set pieces (think ebay)

• 1 Jubilee Clip (gotta like the name)

• 1 HUE Flexible Web Cam (they are cute)

• 1 Web Cam (any kind will do)

• Screen Flow Software

• Blue Tack (reusable adhesive-like clay)

The HUE Flexible Web Cam connects to the laptop via USB to capture the experience the user is having in real-time, while the desk web cam captures his expressions and comments. The device is easy to handle with one hand and doesn’t require that the user interacts with it while it is fixed to the desktop to capture video. The two video streams are captured simultaneously for easy playback with your team or clients.

So, “wahoo” to Belen Barros Pena and Bernard Tyers for presenting such a useful session. And, although they were few, I will share the other usable, useful and applicable lessons learned from the IA Summit over the next few weeks.

Today Google launched a new feature: Instant Previews (this hasn’t rolled out for all users, so you may not see this functionality yet). It is now possible to get a snapshot of each site in your search results before you actually visit the site (just click the little magnifying glass). This could be a useful feature. And Google has executed it in such a way that the previews show up remarkably fast. They also feature the sections of the page matching your search. Well done! More…

For years, Web designers had two choices when it came to choosing fonts for their sites: Web safe or graphical fonts.  There are obvious benefits and limitations with each one, and today there are also simple options that capture the benefits of both choices. Before diving into what these are, let’s take a small step back and find out why these new options are needed and long overdue. More…

At the moment, HTML5 is not an accessible specification. Granted, at the moment, HTML5 is not a completed specification.

Of course, HTML5 still contains the accessibility capabilities of HTML 4.01 so it isn’t necessarily a step backward. Where HTML5 is lacking is in the implementation of new elements that didn’t exist in previous versions of HTML. Most notably <canvas> and <video>. More…

You really should upgrade your browser.

We used to make nice little (actually they weren’t little, and as time went on, they became less nice) screens that suggested (demanded) that you upgrade your browser or risk having a less-than-optimal experience (or risk having absolutely no experience).  Then we (in my head, I keep referring to this as the royal We, but it really isn’t; it is “we” meaning the Web design/dev community (whatever that really means)) decided that we should be nicer to everyone visiting the sites we build and moved to the idea of graceful degradation. More…

Welcome to the M|Blog!

At Malenke | Barnhart, we’ve long clamored for a company blog–a place where we can all take part in sharing what we know and engaging with our peers, clients and friends to learn what we don’t. We’ve been around for 9 years now–through two recessions–which means we’ve created a name for ourselves and had LOTS of great clients to work with. As anyone in the agency world knows, though, client work comes before agency work…so it’s now 2010 when we’re finally launching our blog! More…

For nearly a decade, Flash grew on the web to a point of near pervasiveness. It offered itself as a plug-in for every major browser and every major platform. It even came pre-installed in a lot of situations. Flash came as close to a “standard” as any proprietary technology on the web ever had. Then came the iPhone and the first hints that there was another (better?) way. More…