Over the past six years, as the iPhone, then iPad, and similar devices have caused a ripple within the technology sector, the industry and pundits have struggled to define what these devices are.

From the beginning, they were always classified as “content consumption devices”. But this was a misnomer then, and it’s definitely wrong today. Whether we’re talking about Apple’s devices, Android phones or tablets, Blackberry’s new phones, or devices running Windows 8/RT and Windows Phone, calling them content consumption devices is just plain wrong.

A while ago, I wrote about hero apps and promiscuous apps. I didn’t say it then, but I’ll clarify it now. Promiscuous apps hit first not because they are standout applications for a device to run, but rather because they’re easy!

Friends who know me well know that I’m often comparing the auto industry of the early 1900’s with today’s computing/technology fields. When you consider Henry Ford at the sunrise of the auto industry, the Quadricycle was his first attempt to build a car. This wasn’t the car he made his name with. But it’s the car that got him started. This car featured no safety equipment, no windscreen – it didn’t even have a steering wheel, instead opting for the still common (at the time) tiller to control the vehicle.

Promiscuous applications show up on new platforms for the same reason that Henry’s Quadricycle didn’t feature rollover protection and side-impact beams. It’s easy to design the basics. It’s hard to a) think beyond what you’ve seen and b) build something complex without understanding the risks/benefits necessary to build it to begin with.

As a result, we see these content portals like Netflix, Skype, Dropbox, and Amazon Kindle Reader show up first because they have a clear and well understood workflow that honestly isn’t that hard to bring to new platforms so long as the platforms deliver certain fundamentals. Also, most mobile platforms are “close enough” that with a little work, these promiscuous apps can get their quickly.

But when we look out farther in the future – in fact, when we look at Windows RT and criticize it for a lack of best-of-breed apps that exploit the platform less than 4 months after the platform first released, it’s also easy to see why those apps aren’t on Windows RT or in the Windows Store (yet), and why they take a while to arrive on any new platform to begin with.

Developing great new apps on any platform is a combination of having the skills to exploit the platform while also intimately understanding the workflow of your potential end-users. Each of these takes time, together they can be a very complicated undertaking. As we look at apps like Tweetie (Twitter for iPhone now) and Sparrow (acquired by Google), the unique ways that they stepped back and examined the workflow requirements of their users, and built clean, constrained feature sets to meet those requirements – and often innovative interface approaches to deliver them – are key things that made them successful.

The iPad being (wrongfully, I believe) categorized as a content consumption device has everything to do with those applications that first arrived on the device (the easy ones). It took time to build applications that were both exploitative of the platform and met the requirements of their users in a way that would drive both the application adoption and platform adoption. People looked at the iPad as a consumption device from the beginning because it is easy to do so. “Look, it’s a giant screen. All it’s good for is reading books and watching cat videos.” Horsefeathers. The iPad, like Windows RT, is a “clean slate”. Given built-in WiFi and optional 3G+ connectivity, tablets become a means to perform workflow tasks in ways we’d never consider with a computer before. From Point of Service tasks to business workflow, anytime a human needs to be fed information and asked to provide a decision or input to a workflow, a tablet or a phone can make a suitable vehicle for performing that task. Rather than the monolithic Line of Business (LOB) apps we’ve become used to over the first 20 years of Windows’ life, instead we’re approaching a school where – although they take time to design and implement correctly – more finite task oriented applications are coming into vogue. Using what I refer to as “task-oriented computing”, where we focus less on the business requirements of the system, and more on what users need to get done during their workday, this new class of applications can be readily integrated into existing back-office systems, but offer a much easier and more constrained user workflow, faster iteration, and easier deployment when improving it versus classic “fat client” LOB apps of yore.

The key in task-oriented computing, of course, is understanding the workflow of your users (or your potential users, if this is a new application – whether inside or outside of a business), and distilling that workflow into the correct discrete steps necessary to result in an app that flows efficiently for the end users, and runs on the devices they need it to. A key tenet here is of course, “less is more” and when given the choice of throwing in a complex or cumbersome feature or workflow – jettisoning the feature until time and understanding enable it to be executed correctly. When we look at the world of ubiquitous computing before us, the role that task-oriented computing plays is quite clear. Rather than making users take hammers to drive in screws, smaller, task-oriented applications can enable them to process workflow that may have been cumbersome before and enable workers to perform other more critical tasks instead.

When talking about computing today in relation to the auto industry, I often bring up the electric starter. After the death of a friend in 1910 due a crank starter kicking back and injuring him, Henry Leland pushed to get electric starters in place on his vehicles, and opened up motoring to a populace that may have shunned motorcars before then, do to the physical strength necessary to start them, and potential for danger if something went wrong with the crank.

When we stand back and approach computing from the perspective of “what does the software need to do in order to accommodate the user” instead of “what does the user need to do in order to accommodate the software” as we have for the last 20 years, we can begin to remove much of the complexity that computing, still in its infancy, has shoved into the face of users.