Shift Happened - Part 2: Small Apps Loosely Joined

What are Small Apps Loosely Joined?

There has been a large shift in how many people work today and part of that is in the tools that they use to get work done. This shift in work patterns mirrors the shift that many had in their personal lives around social interactions and productivity.

Late one night many years ago (long before the iPhone), a group of us were talking about web and mobile and opportunities to work in a variety of similar tools that were all interconnected. The mash-up culture was a year or two behind us with Paul Radamacher’s first map mashup HousingMaps and the salient understanding that surfaced from that was the ability to have different interfaces for different needs and uses that could work as a workflow, or even similar interfaces for different personal needs of the users. We talked about Twitter and its heavy reliance on third-party developers to build web and mobile apps and services on top of its services and the Twitter API (the application programming interface, which is a standard data and interaction layer that sits behind the scenes bring data back and forth between the service). This approach allowed anybody to build an interface for seeing and interacting with Twitter or create an interface that provided greater ease of use for tasks. With tongue in-cheek (paraphrasing David Weinberger’s “Small Pieces Loosely Joined”), I said this model was small apps loosely joined.

What joined these apps together was a common data layer that fits a standard data model (or, as is common in APIs, a data model that self describes). The Twitter model allowed people to interact with the service through a mobile app with full functionality of the Twitter site, or to see many different Twitter lists in something like TweetDeck, or monitor and respond through different accounts in something like HootSuite, while tracking follows and drops in other monitoring services.

This same idea is more prevalent now across our mobile devices and the apps and services that they connect to and use. Not only are today’s mobile apps and services interacting with the APIs on the internet, but they are working with standard file formats on the backend and apps that meet the needs of users’ context and workflows. Some of the common app and service types that people have been shifting to the small apps loosely joined model are: Calendar, email, photos, text / documents, and to do lists / reminders (a closer look at these follows).

Who is Doing This?

The small apps loosely joined concept is nothing new in the technical geek and productivity nerd community (as part of both tribes, i use the words geek and nerd lovingly), as well as for early adopters. These uses and patterns with small apps loosely joined started surfacing around ten years on the web and mobile devices, all interconnected to the internet.

We understand innovation and broad adoption can take quite some time, roughly 10 years for innovations and new ideas to take hold broadly. We are about 10 years into this way of working and interacting with information and applications, so it was not exactly a surprise to hear research (done in-house to better understand the mobile market) that 60 to 70 percent of military members and their families surveyed use more than one app for a task types. They used calendars, email, and weather as examples. I checked with others who do surveys of employees inside organizations if they were looking at the question and found that they were. Their responses were also in the 60 to 70 percent range for calendar, to do, and text apps on mobile devices.

So, while this small app loosely joined focus and obsession within technology and productivity communities has been more than a decade old, it is something that is now rather mainstream. Over the last five years or so, when I am traveling or in a dank gym for club basketball, I often ask people next to me what apps and services they like the most on the mobile devices that is in their hand. Their answers often surface apps related to tasks and workflows for a data type (calendar, document, etc.) and the person would qualify how and in which circumstances they use it. Quite often, the app did one or two things really well that others didn’t cover or did not do well in their perspective.

Why are People doing this?

There are a lot of reasons why people started embracing small apps loosely joined. The primary driver has been mobility and looking for small mobile or tablet apps that do a specific, needed task. Mobile and tablet uses often have quite different contexts for use, including a mix of creation and consumption, but the affordances and agency in these apps is a driver too. Having applications work across platforms is helpful, but it is more essential to have open file formats and standards that work with apps that can pick up the file and provide use on another device with the constraints and augmented capability mobile and tablets provide.

There are additional relevant benefits of the file formats and standards working across devices. The ability to easily share files with others with whom you are working or communicating is a great benefit, as the platform doesn’t matter, just the ability to grab an app (often inexpensive and sometimes free) to read and modify the file is key. Being able to easily share files leads to always having needed files accessible, as they can be kept of an internet directory (the kids, okay grown-ups, call this cloud storage).

The last benefit that is driving people to the world of small apps loosely joined is the value of non-proprietary files, which isn’t as hippy and give-it-to-the-man as it sounds–it’s really about ensuring that the files will work on any device with an application that handles that type of object. Having to keep two or three versions of the same software around so one can work across file differences, or open files in a different version of the software so it can be saved down into an older version, is silliness we can leave in the inefficient old days. Many of the file structures that are based on around text, including calendars, can be opened in any text application and read and edited there.

Where are People Doing This?

Most people (particularly outside the geeks) started down this path when smartphones and the modern class of tablets entered their lives. They looked for ways to replicate how they worked on laptops and desktops, but often the same apps weren’t there and they had to improvise. Word of mouth also spread ideas and options for getting things done. But, often people go exploring small, focused apps that are inexpensive or free to see what they do. The small targeted apps, often in the “does one thing well” class of app or small app that is does a few things simply and easily, have filled made it easy to try quite a few different apps to find something that works. People often find a few apps that fit into a workflow that targets a few small tasks to get things done while standing in line, stuck in traffic, or sitting at your desk waiting for one’s computer to finish updating and reboot.

As a result, often people find that this small focused app model helps them do the things they need to do, and it can be more efficient than digging around large cumbersome software. Often this can be more efficient as the person is not digging around large cumbersome software. Once this becomes a habit or a way of working on mobile, the expectation is that it should also work on the desktop / laptop as well. People look for similar apps and services that fit their more efficient workflows that started on their “devices that are too small and limited to do any real work on” and want that same type of focussed application where they “do their real work”.

This change is also being driven by more than just shifts in devices–people are trying apps and services in their personal life to help manage their schedules or work simultaneously with club or event organizers crafting an email or newsletter. Our personal lives used to trail our work lives as far as technology and services
augmenting what we do, but now what we’re doing in our personal lives has greatly surpassed the capabilities of many of our work offerings.

The Types of Apps that Often Fit the Bill

The starting place for many people who try a variety of apps on their mobile and tablet devices are weather, text, and calendar. We don’t modify weather apps as they are mostly just a display of provided content, but there are much variety among the offerings, such as <give a good, standard example> and DarkSky, which offers micro-location weather with how many minutes until precipitation starts or stops.

Text apps

Text apps is where many start seeing the concept and value of small apps loosely joined. People want something more than just simple notes application to jot ideas and sync them to other devices. They want to be able to read and do a little editing of text that they or others started writing on their “work” devices, all while standing in line or during other available moments that permeate our day. Soon this “little bit of editing” seems like it isn’t all that bad to do and they start picking up things they started writing elsewhere and knock out more on their mobile device or tablet. Or, they have an idea when they are not near their “work” device and start jotting a few notes in a text app, and soon it has turned into a couple or few paragraphs. The accessibility and convenience of these capabilities has switched on a lightbulb. Talking and comparing notes with friends and colleagues, they find there are apps that are not just simple text, but can add annotations for structure (headers and outlines), hooks for style (bold and italics), and more. This often leads to learning that some apps have more robust writing tools (dictionary, thesaurus, writing analytics, etc.). Those who write with a workflow of first getting ideas out of their head and then working with them to hone them are often most prone to the small apps loosely joined way of doing things. But, others also like the ease of just getting words and ideas out in one app, then editing elsewhere by just opening another app and grabbing the same text file from a cloud sync service or sharing between apps directly. These text apps, particularly when those that are markdown friendly, can take that initial text and turn it into a styled PDF, a Word doc, HTML to post, RTF (rich text format), or more.

Calendar apps

Calendars are another gateway drug, er application type, that leads to embracing the small apps loosely joined way of doing things. The calendar files are a set file type that is easy to move from app to app (except when working across platforms that have proprietary hooks that break compatibility). Smartphones and tables all come with calendar apps, but they rarely fit the full range of needs. Some people want a calendar to have a certain look or layout format that helps them see and evaluate their day, and there is an abundance of options on all platforms for visual display. But, the real gems are the small apps that shine with certain tasks like Fantastical does on Apple products with its natural language parsing that turns spoken words into an almost always bang-on calendar entry.

Other calendar apps start adding other intelligence and agency (applications doing things on our behalf to ease our work). Donna (rest her digital soul) was a favorite of mine for evaluating time between events and different modes of transport and calculating time to leave based on weather and traffic conditions (and if you were really stuck in a jam, it offered to help you get Uber). Donna was a gem for the space between meetings, but was an incredible help with coordinating kid pick-up and leave times related to their various events. Other apps that are helpful agents are Tempo (it came out of the same SRI lab as Siri), which is one of the fullest featured and most helpful calendar apps around. Tempo monitors your mail not only for events, but pulls the relevant emails, documents, location and contact information, and relevant transportation needs into one simple calendar entry–and all you had to do was place it on your calendar or say yes to an event invite. Tempo offers the ability to send an “I’m running late” notification to those with whom you are meeting, as well as the expected arrival time.

One the the interesting things about calendars in the small apps loosely joined set is that most of these class of apps do something else–they augment and clean-up the calendar entry. Say I open Tempo and it doesn’t recognize the location that is in the calendar entry - say it only has Ray’s Pizza in NYC (oh, you too have gone down this crazy path of meeting somebody at Ray’s Pizza in NYC only to later realize (not soon enough) that there are more than one and nearly a billion permutations of Ray’s, Ray’s Original, Original Ray’s, etc.)… so Tempo offers suggestions to sort out the exact location and then enters the address in the calendar file’s location field. Bingo! We have clarity, but not only does your calendar have clarity within Tempo, but in all other calendar apps that read that event file. Not only does Tempo do this, but other apps may also do this. We learn quickly the apps that don’t play well with others and hoard the clean up information (Mynd app has done this in the past, but it seems to be more friendly after its last update). Additionally, some apps give you the option as to which mapping and directions app you would like the calendar to open when you are actually on your way.

Email apps

One of the things that mobile and tablets reinforce is how painful email is in our lives (on both the work and personal sides). Being able to live in email and work with it easily in some managed way from a mobile device or tablet is critical. The small apps loosely joined concept really takes hold with email for many people. Some tools work as easy, light triage, such as Mailbox, to quickly filter through your email based on importance and time-relative needs. Also, some tools that manage attachments in email (or, more appropriately, files that would have been attachments, such as Hightail (formerly YouSendIt), which stores files and documents for your email to link to securely. The only requirement for most of the email apps is the email account must run on IMAP, which is pretty much the norm these days.

Photo apps

The quality of photos has improved drastically on many mobile devices and even tablets. This along with the adage, “the best camera is the one you have with you” (and most people always have their phone with them), has led to the reality that a lot of photos get taken on mobile devices and tablets. The photos are a common file type and there is an abundance of apps that can take a photo and modify it to improve its quality, add filters to change the look, add text, or turn into something that looks a lot like a watercolor painting. The photos can also be scanned and OCRed, as well as uploaded as a document and later searchable (as many do in Evernote.

Standards and Access

The key to many of the apps loosely joined use types mentioned (and the many not covered here) is that the files passed among apps follow a set or ad hoc standard. Text files that use Markdown (or Multi-Markdown that extends the capabilities to add footnote, tables, and more) are all human readable, but also any text app can read them and edit them. The file sizes are small, which is incredibly important for mobile devices and tablets in limited mobile bandwidth locations (be that Manhattan at 5:15 on any weekday or the outer suburbs of Accra).

Access to the files is the other important characteristic of small apps loosely joined. Working between apps may not require internet access, but working between devices that are not in bluetooth range, or sharing files to collaborate requires data access (most often through the internet). Small file size, which those of us working with mobile a long time know is still an essential for actually getting things done reliably.

Common Use Traits

These apps have a core set of functionality that stem from the capabilities of:

• Viewing
• Creating
• Honing
• Agency
• Features / functionality augmentation

Viewing is a common characteristic of all the apps, but the ability to create is where the real difference in these apps start to have real value for people using these apps and working in a small apps loosely joined workflow. The small apps can also provide the ability to hone what has been done in another app or on another device. This honing may be editing or adding data or an element to improve use. Agents that look out for us and do work we would be having to do is quite helpful, particularly when they are getting to the near bulletproof reliability some are approaching these days. The features and functionality augmentation in apps really helps when working with light apps that are focused and easy to use. Adding grammar checks and tools that can improve our work or creations, much like we would at a laptop or desktop, have shifted many people to this small apps loosely joined life.

App Traits

There are a few core traits in these apps. First off, as mentioned, they work on open document types that are are commonly used as actual or de facto standards.

Another trait is the apps are light (a few features and functionality sets), focus on simplicity, and are easy to use. Mobile devices do not have the screen space for complicated or complex interfaces, and, in reality, given where and how these devices are used, the user’s full attention is not on the app or device. Good mobile and tablet designers and developers understand this limitation very well and understand just how far they can push the limited human constraints that come into play when interacting with the apps.

The last related trait is that the apps are focused. When listening to how people use and interact with their devices and apps, it is interesting how they understand and parse functionality that fits their needs across apps. With calendaring, some people love Fanstastical’s UI for display of the day’s and upcoming events, while other people love how easy it is to input information and create events from a chunk of copied, typed, or spoken text (and getting it right). It was interesting talking with other Donna calendar app users as many of us would open Donna to get just travel-related information and / or honing the address, then close it and open another calendar app for its different functionality. The apps do a few certain things really well and those that live in the small apps loosely joined workflow are quite fine with that.

Wrap-up

The small apps loosely joined workflow and expectation has moved from mobile devices to the laptop / desktop world. The small apps that were just on mobile devices are showing up on the more fully powered devices. The output created from these apps have supporting services on the web that can augment this practice much further. Many who work in small apps loosely joined have learned to like the focused task and mindfulness of that targeted approach–they get things done far more efficiently and are more productive more of the time, and, as a result, they can often get more uninterrupted time to focus on living life beyond devices and apps. The goal going in was just to get things done on the device I have with me, but it is not a bad benefit for those whom value it.

---

Shift Happened Series

• Part 1: More Productive Not Using Productivity Tools
• Part 2: Small Apps Loosely Joined
  
• Part 3: Capturing Decisions in Social
• Part 4: The One Social Way (Or not) to Doing Social Really Well in Enterprise

Shift Happened - Part 1: More Productive Not Using Productivity Tools

Over the past six months or so, I’ve been increasingly hearing from IT leaders in organizations who have been surprised by a shift in how people work digitally. The work patterns related to this shift are far from new and, in fact, are well over a decade old.

Nonetheless, some have been surprised by who, why, and how broadly and rapidly the change is happening. Those caught by surprise are often in IT departments, and they are surprised by the changing work patterns of sales, teleworkers, and others in the field and away from the office. Looking at these shifts in detail, how those who are surprised by these shifts came to be surprised isn’t so surprising.

Productivity Happened

Over the past 3 to 4 years, there has been a shift in how people work. Advancements in mobile devices and applications is part of it, but the prevalence of touch tablets has been a large contributor to the change. The light weight and ability use them for much of users’ daily work makes tablets a relatively good choice for those working on the road or away from the office. Initially, many thought that not having Microsoft Office was going to be a hinderance for tablet use, but that has not been the case.

But, the same time touch tablets were becoming a largely viable option, how and where information and knowledge work was happening shifted too. Work was increasingly happening in online services where text and data was entered into an online service, often one with collaborative or social functionality. The daily report was no longer a document completed in Word and then uploaded; it is now text that is entered in a service that connects colleagues and team members who do follow-on work with that input. The conversations happens around the information and the content shared initially can be edited, commented on, and linked to externally.

Those in the field may not be online all the time, but they are collecting notes and information throughout their day, often doing so in small, lightweight, text-focused apps. The small writing apps often have Markdown as their means to add structure (structure replaced style), including headers, bold, italics, bullets, links (to web pages, online spreadsheets, images, or other). Markdown isn’t new and many of the online services people are using have handled Markdown text for years. Up to this point, Markdown had mostly been in the geek domain, but now sales folks, admins, field workers, and other traditionally non-tech-centric workers are using it as well.

Frequent users say that the 6 to 8 regular Markdown annotations (such as heading levels, bold, italics, links, and pull quotes) were quick and easy to learn. MS Word has nearly 200 functions in its ribbons these days, but many people use only 15 to 20 of those, and most often use 6 to 10, for which they use keystrokes. Yes, the common 6 to 10 most used and easily found Word functions map to those provided within Markdown. Many text apps have buttons for Markdown for user convenience.

This shift to simplified text focus (that doesn’t require Microsoft Word) has delivered quite a few benefits. The first is that it is incredibly easy to share contents and files with anybody, as there are no “I have the wrong version of Word” or “I copied it into my document and my document is now a mess” problems. The files sizes are also lightweight and easy to email or upload, even in environments with network bandwidth constraints. Most of their work is going to be copied into text boxes in an online system anyway, or, if folks are working in a Word Document, it will likely be parsed and turned into plain text, rich text, or HTML (things Markdown-related tools easily output as alternate options).

But, of all these small benefits, the largest is the increase in productivity. Many of those working in this manner, mostly because they were on devices that didn’t have Microsoft Word, found they were “far more productive outside their old productivity tools.” Nearly every person I have talked with who has watched this shift happen has uttered this statement or something very similar about productivity. Workers are no longer battling their tools (Office / Word), but are simply producing.

Shift Sneaks Up When You are Headsdown Building Past Models

Without exception, every person in IT who has tracked me down to have this discussion (with the aim of finding out if they are alone and how to start thinking about it), is coming out of a very long SharePoint implementation. They were heads down on their (initially) 2 to 4 month Sharepoint project, that ended up being an order of magnitude longer, more expensive, and larger in scale and scope than expected, so they didn’t see this shift happening.

Often, these folks in IT were pointed in my direction by someone in a different division within the organization who I talked with or worked with on collaborative and social working projects to support their needs. These systems and services provide the text boxes into which their workers were pasting text from their tablet text-writing apps. Their work and work models shifted drastically while IT was heavily focused on a solution that wasn’t solving needs for large portions of the organization.

IT really wasn’t aware of this shift until they went to renew their Microsoft Office licenses and were being moved to Office 365, which seemed like it was going to meet the online working needs of the systems they had been asked to deliver years back. What IT was not expecting was that 25% to 40% (or, as I have been hearing over the past couple weeks, 60%) of their workers, many of whom are working out in the field or virtually, refuse to go back to using Office (often voicing this refusal loudly and strongly). IT found they had paid for seats that wouldn’t be used, an incredibly expensive proposition. Office 365 can be justifiable to many when it is being used, but to sit unused is another story. The senior IT folks have been saying their percentage of workers shifting to this new (Office-free) model is going up by 2% each month, as means of working more easily and efficiently in other ways spreads (e.g. 25% in April 2013 to 27% in May 2013).

More Productive Not Using Productivity Tools

This big shift relates to the fact that traditional productivity tools weren’t based on efficient productivity. Most standard productivity tools grew from a paper-based model and world moved to the digital world. As work has largely changed from passing documents around to posting and working on content in more open collaborative and group environments that align with what our modern work has became, the model of a “doc” disappeared. The document as an object was the focus of the “system of record,” but now, in a “systems of engagement” model, focus is on the milestones met and status marker activities in the online collaborative, collective, and team (including group / community / network) interaction systems.

Tools that got in the way of productivity and didn’t meet needs as people began to work more interactively in digital-focused and digital-appropriate environments are no longer the default tools of choice. We are working a little more like humans interact naturally and having technology adapt to these ways of working, rather than making humans learn a lot about how to adapt to traditional technology to do their work.

---

Shift Happened Series

• Part 1: More Productive Not Using Productivity Tools
• Part 2: Small Apps Loosely Joined
  
• Part 3: Capturing Decisions in Social
• Part 4: The One Social Way (Or not) to Doing Social Really Well in Enterprise

Responsive Design is Part of the Question not the Answer

Today’s New York Times redesign has lit up Twitter and other services with many saying “… but, it isn’t responsive”. I quickly recalibrated who knows mobile design / development and who is still learning. Responsive design has become the mantra the zombies repeat for mobile. Responsive is one of the five options for mobile and most often the end product doesn’t end up with responsive as the best answer, it is the intermediary stage answer if needed.

I am going to start with looking at understanding mobile and the user, then look at how we got to responvie design, then look at the New York Times (which, I think is the most important piece of this whole piece).

Understanding Mobile and the User

The history of mobile and designing and developing for it goes back far beyond the iPhone and Android. It predates the years of smart phones that came before this current iteration, and gets it starts about the Post-WAP age (it actually starts with WAP, but it was so bloody limited and poor most skipped it). Early mobile started with the PALM generation of devices and building web pages that worked on the go (often through AvantGo or similar) or network connected apps. The design and thinking process, as far as which to use route to go started with understanding a few things (I framed these in 2003 in presentations, workshops, and client work as Model of Attraction Receptors, which I realized never blogged so can’t point to it but will have that shortly as an active link): The user and their use (the intellectual, perceptual, and physical receptors) and the whole of the device system (mechanical receptor).

The user’s basic need is they want the content or tool/service capability on their mobile device. Since the early 2000s more than 60 percent of us in the, often referred to as, first world have had these devices on us to use content we find out where we need it (in the world) either in a Come to Me Web manner, or finding and creating the information out in the world. (For many today the laptop / desktop is now their secondary device not their primary).

The essentials for the user are have the information or service in the mobile device and work. The “working” is where the thinking comes in for options as the question of network connectivity, volume and velocity of change of the content or service changes, how often with the user interact and how long, and is this the primary service or is a just to get one through until they get to their desktop (and are you really really sure about this last one). These are the rudimentary questions to understand some of the use to start making the decisions about options. The largest issue in the set of questions relates to the reality about the network and capabilities of the device as both capabilities are assumed better than reality. Networks are far more limited that assumed and devices on the whole are not as robust nor consistent as hinted at.

The mobile user is most often looking for something that is quick, easy to load, and really easy to use.

The options we have before us on mobile are: Native app, web app, web app wrapped in native app, mobile site (often using media query), and responsive.

The questions and thinking needed to work though which option fits the need best are quite a few and usually best worked through by people who have designed and built through all of the options, and (most importantly as always) been responsible and had to fix the end results. These people questioning not only working with those wanting mobile site or service, but also the users. The decision trees and understanding which route to go can be learned, but takes a workshop of a day or two not a blog post.

How Did We Get to Responsive?

So, with these five options how is it responsive got to the front of the line, even when you walk through all the questions and would rarely end up with responsive as a viable answer?

The simple answer is content management systems suck. In 2009 / 2010 many organizations realized they were late to the game and their site use had relatively high mobile use and their users were complaining about how poor the site was on mobile. (This actually hit much earlier and work on solutions has been long brewing going back to early 2000s as to how to resolve this.) Mobile finally had tipped into the territory of something organizations needed to deal with.

In 2010 Ethan Marcotte shared his Responsive Web Design as a way forward to get mobile web up and running, somewhat as a hack to CMS that couldn’t support other options. Ethan is also one of the many who with Jeremy Keith and others of us from the (now shuttered) Web Standards Project (WaSP) focussed on web design from a progressive enhancement model. Responsive design is intended to be a progressive enhancement approach, it is one of a few “mobile first” design approaches.

A large chunk of Responsive design as it is today isn’t practiced from a progressive enhancement approach and there is a ton of bloat up front, which is very counter to mobile needs. Responsive design filled a gap and serious need. As Ethan points out Responsive is one approach and other business cases will lead to other solutions.

Responsive Design for Content Management Systems that Suck

Part of the need and fit for Responsive web design is due to content management systems that suck. Why do they suck? There are many, but with mobile in particular there are two issues: 1) Content is not stored in a manner that is far enough separated from the presentation of it; 2) The CMS adds incredible cruft into the page that there is page bloat.

User Centered Design and Responsive Design

As Ethan points out in his Responsive Web Design article:

That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.

The business case should follow the user needs. In the last few years if you spend a lot of time watching how people use their mobile and tablets (how we use them our selves isn’t that helpful other than as a base to watch the insane variety of different use patterns others have and the interaction models other’s use when they are out or even in meetings - something I started doing in the 90s when I got a Palm Pilot as I watched others to see what I was missing, which was an extension to always watching others interact with the world around them to learn for myself (moving a lot as a kid provides this potential)). How people use mobile and tablet has expanded greatly in the past four to five years. The expectations (often users are completely unaware of their expectations as it becomes as natural as breathing for many) for each device and the actual use vary quite a bit. This expansive shift makes honing in to device classes needed.

The last year or so I have been hearing many doing mobile and tablet design for years have been moving away from broad (one-site for all and Responsive) offerings with Responsive to targeted offerings for mobile, tablet, and desktop and using hints of responsive within those classes of offering. The user research finds the needs are different enough across the classes that full Responsive became unwieldy very quickly.

Users Live Across the Patforms

One of the realities of use is it is very common for multi-modal use of sites (mobile, tablet, and desktop) and the need for content to be there. One of the very important user context to always consider is spacial memory. People remember where on a page they saw something. This is really important for news sites as people will see the an article that doesn’t have much interest, but later in the day they find themselves needing that article and often their memory of where it was on a page (Business page on far right column, etc.) is how they know to get to the article (one of the reasons news publications for year have offered a “print view” of their offerings). With most Responsive design this ability to switch between these presentation modes is not there.

I have heard users and content owners talk about this problem for a few years, but it was a train from NY to DC where I saw the deep frustration this causes. A gentleman in front of me was working and had started out in Boston and needed to link to an article he saw on the Boston Globe site that he was reading on his laptop in the morning in Boston. He tried finding the article on his mobile device, which triggered anger as there wasn’t a way to get to the full front page on the Globe’s responsive site, he needed to fire up his laptop. The whole train car started helping him, mostly saying go to the “M dot” (m.bostonglobe.com) site and find the link to the full desktop version. The inability to get to the full site stumped the train (they were mostly New Yorker’s who read papers with mobile version and desktop versions, like the New York Times). Soon the whole car was angry.

The ability to jump to a full desktop site in Responsive is technically really easy, but it is an interaction and design messy festival with state and user desire and intent, which is far cleaner to deal with when there are distinct mobile and desktop versions, as a minimum. This issue is also how many started moving beyond Responsive as they saw their user needs move well beyond was was going to be straight forward with Responsive.

Never has a customer said they want Responsive, they want mobile and/or tablet usable formats that meet their needs. Responsive has been a design middle step to get to providing mobile options relatively quickly, but over time (often not much time) that moves beyond what makes sense. The need to design for user needs goes back to the old mobile foundation of thinking first about all the actual user needs and all the options properly.

The New York Times and Mobile

This started with the New York Times and its redesign. The New York Times has long had a mobile version of their site that is mobile specific. They have a CMS that makes it relatively straight forward to work their content not only into mobile site, but many other options. The New York Times has continually had some great folks who think across platforms that users are using and designing for needs there. The New York Times also has long running experiments that try many different things, like their Skipper Interface.

I bring up the Times not only because of how users actual use what they offer. I know a few Times digital folks and know many who have been part of the digital Times team of the years and even lead it.

The New York Times rough usage patterns for mobile split to roughly even thirds across mobile web (their mobile.nytimes.com) site, their mobile native apps, and full desktop use of the site on mobile devices. Another interesting piece is people bounce from one mode of reading and interacting to another (so read mobile web and shift to desktop or to mobile app) during their session (tracked with user login I assume). [These are from conversations with some current “not on the record” mentions and others at conferences who worked in that group have talked about roughly current use metrics third hand. I had them only roughly confirmed with a “that sounds about right”, but haven’t followed up with going through the New York Times press office to get official quotes.)

What is really interesting is there is no one dominant pattern for mobile users of the New York Times (this also applies to many other services who actually do user pattern research). Not only is there no dominant pattern, but users bounce between the different offerings. I have many times heard readers of the Times telling other readers they will find an article they are looking for in one interface but prefer to read it in another. Different interfaces of the different offerings resonate with people differently (the truth in “there is no one way proves true yet again”) and user patterns for discovery and use/consumption vary too.

Where Does This Leave Us?

One thing that has long been true is the New York Times understands mobile (has the data to influence design - not sure that is how it is used, so just guessing) really well. Also proving many who think they do shouting “Responsive” likely have a long way to go get to that understanding.

We are left, just like we were in the early 2000s, needing to understand mobile broadly and deeply as well as understanding how people actually are using mobile. We need to understand how to work through the questions needed to get to the needed solution for mobile and mobile use (as well as tablets, which need slightly different focus). When you walk through the questions and do the research likely Responsive is not the solution that best fits. It still could be a decent option as an in between step, but the essential first step is to learn the options and how to think through them.

Resonance in Sound and Design

Resonance:

• The quality in a sound of being deep, full, and reverberating: the resonance of his voice.

• The ability to evoke or suggest images, memories, and emotions: the concepts lose their emotional resonance.

Listening to the lovely and haunting Dead Already from the American Beauty soundtrack by Thomas Newman in high quality recording (lossless) and a compressed version (at 256 kbps) the beauty that is lost is in the resonance of the marimba / vibraphone and other instruments that make up the core of the musical experience. The this isn’t the white space between characters in print, but a grey space. It is beyond what is struck and to place a note in time and space, but what resonates out beyond that initial placement or use.

The last few years I have been reripping much of my musical collection as my main headphones improved, which are my main listening experience. The sound and experience is drastically different and exposes the gaps and the details that are missing in other listening environments. This combined with listening to music that is well produced and exposes and lets the musicianship and craft shine.

Resonance in Design

Thinking of resonance from an interaction design view is quite enlightening. The work of creation of usable interactions is good, but it is the first strike and it is not just white space that follows, but resonance of striking that interaction. This struck me a few years back when the iPhone came out (or one of its subsequent iterations) when I realized my Nokia E61i was faster at rendering pages and actions than iPhone, but what the iPhone did really well was manage and design the resonance after the person using the service clicked something. After striking for an action Nokia left white space and a void, but Apple crafted the grey space of resonance. Nokia would surface the result much more quickly, but with Apple that lag in the delay was not as perceivable unless you were watching the clock. Apple filled the empty space with fade-out, fade-in, activity notifications (windmill bars), which display for just a small amount of time usually. Much like the resonance of a marimba the sound and resonance can not last forever, nor very long, but it is enough to evoke beauty through filling the void.

The one or three second lag between clicking to trigger an action was painfully noticeable on a Nokia, but rather imperceivable on Apple devices. A longer delay is perceivable and painful no matter the interface and relies on engineering to resolve those issues. But, it is that resonance and understanding the design and crafting of it is what can separate a good experience from one that is more rough for the people who desire to use it and could find it of value in their life.

Everynow

We are living in a time where there are not only many concurrent realities existing at once, but our understanding of “Now” is perhaps broader and more broken than most any time since the Middle Ages started sprouting into the Renaissance. This is nowhere more prevalent in our understanding of the future, particularly the near future. Future technologies and future living have been part of reality in and around us for decades. But the time gap between the few edge cases who are living with what most consider future technology and life to when it hits mainstream is ever increasing.

The Future is Here…

This stretch of living with future technologies as a regular part of our lives and those who are not there yet, or even living a generation of reality behind all while living in the same culture is something I’ve called the everynow. Everynow started about 2004 as a tongue-in-cheek riff on Adam Greenfield’s everyware term use. Everynow is the breadth reality in William Gibson’s “The future is already here - it’s just not evenly distributed” statement from 2003, which is an idea many have discussed for years prior, but with out such nice phrasing.

Breadth of Adoption Reality

It seems the everynow is about 20 years in breadth.

For years it seemed it was about 10 to 12 years and it was nice to see it in Steven Berlin Johnson’s wonderful book “Where Good Ideas Come From”, he talks about the reality of ideas taking about 10 years from inception to getting them into relatively broad public use. When you think of internet based email in the 90s and the use of corporate email internally and out through internet gateways to better connect freely and more unencumbered, it took about 5 years for email to get to roughly 99% inside the organization (many organizations were much closer to that 10 year mark). But, in the last couple years in particular that 10 years.

Internet of Things

This past week with Tom Coates’ Twitter account for his house, @houseofcoates getting some mainstream media press the difference from what Tom is doing (and thinking and playing with for a very long time) rather echoes things like MisterHouse which started in the late 1990s using X10 devices and services and internet enabling them using Perl. The demo site for MisterHouse allowed those on the web to see the live status of lights, messaging, home music service, and things like window shade open status, but also for quite a while allows any of us to modify them right from the web. Tom’s long interest and work with his House of Coates is the latest iteration and extension of this and his long work on web of data and internet of things. (By the way Tom’s work is quite good and worth tracking down.)

The chatter around the Internet of Things, which is far from mainstream exposure and partial understanding is nearly 15 years old since its first usage by Kevin Ashton, really took off around 2002 and 2003. Bruce Sterling’s still incredibly valuable framing of the Internet of Things in his Shape of Things book from 2005 added the incredibly helpful concept of Spimes to conversations (actually he seeded this in 2004 in a SIGRAPH presenation, “When Blobjects Rule the Earth”), thinking through, and development many of us had been wading in for a few years.

Information for Use and Reuse on Mobile

Another example is around mobile… When I think about this mobile explosion that has “taken place recently” there is very little that is different from the thousands of handfuls of us living with smartphones in the early 2000s and thinking of the capabilities and potentials and building them and living them, all while the many many thousands of us were swimming in the same pool of live with the billions of others around us. Many of use in the U.S. and Western Europe felt we were deeply behind those living in Japan and Korea and their understanding and living the realities of living a life with mobiles that augmented their reality as the devices and services enhanced their lives lived with the devices in them. As we developed use of our web based information for use on internet connected Palm and other similar devices in the 90s

But, from a consumer and early adopter framing the reality of what is potentially doable in the future and having that in place and in use for some time know then trailing all the way back to those living in prior realities and the frustrations (although they think they are manageable, but not realizing how poorly the tools and services are working for them) is pushing that everynow to a very confounding nearly 20 years.

The Future is Now for Information Access

An interview with Microsoft's Steve Ballmer in the in the San Francisco Chronicle regarding Steve's thoughts about the future of technology, information, and Microsoft (including their competition) sparked a few things regarding the Personal InfoCloud and Local InfoCloud. It could be the people I hang out with and the stay-at-home parents I run across during the day, but the future Ballmer talks about is happening now! The future will more widely distributed in 10 years, but the desire and devices are in place now. The thing holding everything back is content management systems that are built for the "I Go Get Web" and people implementing those systems that see technology and not a web of data.

Let's begin with Ballmer's response to the question, "Ten years from now, what is the digital world going to look like? To which Ballmer responds: A: People are going to have access to intelligence in multiple ways. I'm going to want to have intelligence in my pocket. I'm going to want to have intelligence in my TV. I'm going to want to have intelligence in my den and in my office. And what I may want in terms of size, of screen size, of input techniques, keyboard, handwriting, voice, may vary.

I think what we'll see is, we have intelligence everywhere. We have multiple input techniques, meaning in some sense you may have some bit of storage which travels with you everywhere, effectively. Today, people carry around these USB storage devices, but you'll carry around some mobile device.

The problem is people have the devices in their pockets today in the form of Blackberries, Treos, Nokia 770s, and just regular mobile phones with browsing and syncing. The access to the information is in people's pockets. The software to make it simple with few clicks is where the battle lies. My Palm OS-based Treo 650 is decent, but it has few clicks to get me to my information. My friends with the Windows version of the same device have six or more clicks for basic things like calendar and address book. Going through menus is not simplicity. Going directly to information that is desired is simplicity. A mobile devices needs simplicity as it is putting information in our hands with new contexts and other tasks we are trying to solve (driving, walking, meeting, getting in a taxi, getting on a bus, etc.).

The Information

Not only does the software have to be simple to access information in our Personal InfoCloud (the information that we have stated we want and need near us, but have structured in our personal framework of understanding). We also interact with the Local InfoCloud with is information sources that is familiar to us to which we have set a means of easing interaction (cognitively, physically, or mechanically).

This "intelligence" that Ballmer refers to is information in the form of data. It needs to be structured to make solid use of that information in our lives. This structure needs to ascend below the page level to at least the object level. The object level can be a photo with the associated metadata (caption, photographer, rights, permanent source, size, etc.), event information (event name, location, date and time, permanent location of the information, organizer, etc.), full-text and partial-text access (title, author, contact info, version, date published, rights, headers, paragraphs, etc.).

These objects may comprise a page or document on the web, but they not only have value as a whole, they have value as discrete objects. The web is a transient information store for data and media, it is a place to rest this information and object on its journey of use and reuse. People use and want (if not need) to use these objects in their lives. Their lives are comprised of various devices with various pieces of software that work best in their life. They want to track events, dates, people, ideas, media, memes, experts, friends, industries, finances, workspaces, competition, collaborators, entertainment, etc. as part of their regular lives. This gets very difficult when there is an ever growing flood of information and data bombarding us daily, hourly, consistently.

This is not a future problem. This is a problem right now! The information pollution is getting worse every moment we sit here. How do we dig through the information? How do we make sense of the information? How do we hold on to the information?

The solutions is using the resources we have at our finger tips. We need access to the object level data and the means to attach hooks to this data. One solution that is rising up is Microformats, which Ray Ozzie of Microsoft embraces and has been extending with his Live Clipboard, which is open for all (yes all operating systems and all applications) to use, develop, and extend. The web, as a transient information store, must be open to all comers (not walled off for those with a certain operating system, media player, browser, certain paid software, etc.) if the information is intended for free usage (I am seeing Microsoft actually understand this and seemingly embrace this).

Once we have the information and media we can use it and reuse it as we need. But, as we all know information and media is volatile, as it changes (for corrections, updates, expanding, etc.) and we need to know that what we are using and reusing is the best and more accurate information. We need the means to aggregate the information and sync the information when it changes. In our daily lives if we are doing research on something we want to buy and we bookmark it, should we not have the capability to get updates on the prices of the item? We made an explicit connection to that item, which at least conveys interest. Is it not in the interest of those selling the information to make sure we have the last price, if not changes to that product? People want and need this. It needs to be made simple. Those that get this right will win in the marketplace.

What is Standing in the Way?

So, the big question is, "what is standing in the way"? To some degree it is the tools with which we create the information and some of it is people not caring about the information, data, and media they expose.

The tools many of the large information providers are using are not up to the task. Many of the large content management systems (CMS) do not provide simple data structures. The CMS focusses on the end points (the devices, software, tools, etc.) not the simple data structures that permit simple efficient use and reuse of the objects. I have witnessed far too many times a simple web page that is well structured that is relatively small (under 40KB) get turned into an utter mess that is unstructured and large (over 200KB). Usable, parseable, and grabable information is broken by the tools. The tools focus on what looks good and not what is good. Not only is the structure of the data and objects broken, but they are no longer addressable. There are very few CMS that get it right, or let the developers get it right (one that gets it right is Axiom [open disclosure: I have done work with Siteworx the developer of Axiom]).

The other part of the problem is the people problem, which is often driven by not understanding the medium they are working within. They are focus on the tools, which are far from perfect and don't care enough to extend the tools to do what they should. Knowing the proper format for information, data, media, etc. on the web is a requirement for working on the web, not something that would be nice to learn someday. Implementing, building, and/or creating tools or content for the web requires understanding the medium and the structures that are inherent to building that well. I have had far too many discussions with people who do not understand the basics of the web nor the browser, which makes it nearly impossible to explain why their implementation fails. Content on the web has requirements to be structured well and the pages efficiently built. The pages need to degrade (not with an $80,000 plug-in) by default. Media on the web that is for open consumption must work across all modern systems (this should be a 3 year window if not longer for the "modern" definition).

Summary

So what is the take away from this? Content needs to be built with proper structure to the sub-object level (objects need the metadata attached and in standard formats). The content needs to be open and easily accessed. Portability of the information into the tools people use that put information in our pockets and lives must be done now. We have the technology now to do this, but often it is the poorly structured or formatted information, data, media, etc. that stands in the way. We know better and for those that don't know yet the hurdle is quite low and easy to cross.

The Come To Me Web

Until May of 2005 I had trouble with one element in my work around the Model of Attraction and Personal InfoCloud (including the Local and Global InfoClouds as well) to build a framework for cross-platform design and development of information and media systems and services. This problem was lack of an easy of explaination of what changes have taken place in the last few years on the web and other means of accessing digital information. In preparing for a presentation I realized this change is manifest in how people get and interact with the digital information and media.

This change is easily framed as the "Come to Me" web. The "Come to Me" web, which is not interchangeable with the push/pull ideas and terms used in the late 90s (I will get to this distinction shortly). It is a little closer to the idea of the current, "beyond the page" examinations, which most of us that were working with digital information pre-web have always had in mind in our metaphors and ideologies, like the Model of Attraction and InfoClouds.

The I Go Get Web

Before we look at the "Come to Me" web we should look at what preceded it. The "I Go Get" metaphor for the web was the precursor. In this incarnation we sought their information. The focus was on the providers of the content and the people consuming the information (or users) were targeted and lured in, in the extreme people were drawn in regardless of a person's interest in the information or topic covered. The content was that of the the organization or site that provided that information.

This incarnation focussed on people accessing the information on one device, usually the desktop computer. Early on the information was developed for proprietary formats. Each browser variant had their own proprietary way of doing things, based around a few central markup tags. People had to put up with the "best view with on X browser" messages. Information was also distributed in various other proprietary formats that required software on the device just so the person could get the information.

The focus providing information was to serve one goal (or use) reading. Some of this was driven by software limitations. But it was also an extension of information distribution in the analog physical space (as opposed to the digital space). In the physical space the written word was distributed on paper and it was consumed by reading (reuse of it meant copying it for reading) and it took physical effort to reconstruct those words to repurpose that information (quoting sources, showing examples, etc.).

The focus was on information creation and the struggle was making it findable. On the web there were only limited central resources used to find information, as many of the search engines were not robust enough, did not have friendly interfaces. Findability was a huge undertaking, either to get people what they desired/needed or to "get eyeballs".

Just as the use of the information was an extension of the physical realm that predated the digital information environment, the dominant metaphor in the "I Go Get" web was based in the physical realm. We all designed and developed for findability around the navigation/wayfinding metaphor. This directly correlates to going somewhere. Cues we use to get us to information were patterned and developed from practices in the physical world.

Physical? Digital? Does it Matter?

You ask, "So what we used ideas from the physical world to develop our metaphors and methodologies for web design and development?" We know that metaphors guide our practices. This is a very good thing. But, metaphors also constrain our practices and can limit our exploration for solutions to those that fit within the boundaries of that metaphor. In the physical realm we have many constraints that do not exist in the digital realm. Objects are not constrained by the resources they are made from (other than the energy to drive digital realm - no power no digital realm). Once an object exists in the digital realm replicating them is relatively insignificant (just copy it).

Paths and connections between information and objects is not constrained by much, other than humans choosing to block its free flow (firewalls, filtering, limiting access to devices, etc.). Much like Peter Merholz desire lines where people wear the path between two places in a manner that works best for them (the shortest distance between two points is a straight line). Now, don't think of the physical limitation between two points, I need to go from my classroom on the fourth floor of building "X" to across campus, up the hill to the sixth floor office of my professor. Draw a straight line and walk directly. This does not work in physical space because of gravity and physical impediments.

Now we are ready to understand what really happens on the web. We go from the classroom to our professors office, but we don't move. The connection brings what we desire to us and our screen. In this case we may just chat (text or video - it does not matter) with the professor from our seat in the classroom (if we even need to be in the classroom). Connections draw objects to our screens through the manifestation of links. As differently as people's minds work to connect ideas together, there can be as many paths between two objects. Use of physical space is limited by limitations outlined in physics, but the limitations are vastly different in digital space, use of the same information and media has vastly different limitations also.

It is through breaking the constraints of old metaphors and letting the digital realm exist that we get to a new understanding of digital information on the networks of the digital realm, which include the web.

The Come to Me Web

The improved understanding of the digital realm and its possibilities beyond our metaphors of the physical environment allows us to focus on a "Come to Me" web. What many people are doing today with current technologies is quite different than was done four or five years ago. This is today for some and will be the future for many.

When you talk to people about information and media today they frame it is terms of, "my information", "my media", and "my collection". This label is applied to not only information they created, but information they have found and read/used. The information is with them in their mind and more often than not it is on one or more of their devices drives, either explicitly saved or in cache.

Many of us as designers and developers have embraced "user-centered" or "user experience" design as part of our practice. These mantras place the focus on the people using our tools and information as we have moved to making what we produce "usable". The "use" in "usable" goes beyond the person just reading the information and to meeting peoples desires and needs for reusing information. Microformats and Structured Blogging are two recent projects (among many) that focus on and provide for reuse of information. People can not only read the information, but can easily drop the information into their appropriate application (date related information gets put in the person's calendar, names and contact information are easily dropped into the address book, etc.). These tools also ease the finding and aggregating of the content types.

As people get more accustom to reusing information and media as they want and need, they find they are not focussed on just one device (the desktop/laptop), but many devices across their life. They have devices at work, at home, mobile, in their living space and they want to have the information that they desire to remain attracted to them no matter where they are. We see the proliferation of web-based bookmarking sites providing people access their bookmarks/favorites from any web browser on any capable device. We see people working to sync their address books and calendars between devices and using web-based tools to help ensure the information is on the devices near them. People send e-mail and other text/media messages to their various devices and services so information and files are near them. We are seeing people using their web-based or web-connected calendars to program settings on their personal digital video recorders in their living room (or wherever it is located).

Keeping information attracted to one's self or within easy reach, not only requires the information and media be available across devices, but to be in common or open formats. We have moved away from a world where all of our information and media distribution required developing for a proprietary format to one where standards and open formats prevail. Even most current proprietary formats have non-proprietary means of accessing the content or creating the content. We can do this because application protocols interfaces (APIs) are made available for developers or tools based on the APIs can be used to quickly and easily create, recreate, or consume the information or media.

People have moved from finding information and media as being their biggest hurdle, to refinding things in "my collection" being the biggest problem. Managing what people come across and have access to (or had access to) again when they want it and need it is a large problem. In the "come to me" web there is a lot of filtering of information, as we have more avenues to receive information and media.

The metaphor and model in the "I go get" web was navigation and wayfinding. In the "come to me" web a model based on attraction. This is not the push and pull metaphor from the late 1990s (as that was mostly focussed on single devices and applications). Today's usage is truly focussed on the person and how they set their personal information workflow for digital information. The focus is slightly different. Push and pull focussed on technology, today the focus is on person and technology is just the conduit, which could (and should) fade into the background. The conduits can be used to filter information that is not desired so what is of interest is more easily identified.

Europe Presentations from October

I am late in posting the links to my two presentations given in Europe. I presented the Personal Digital Convergence as the opening keynote to the SIGCHI.NL - HCI Close to You conference. I have also posted the final presentation, IA for the Personal InfoCloud, at the Euro IA Summit 2005.

Social Machines

Those of you that follow this site will also likely enjoy Wade Roush's continuousblog. Wade is the West Coast editor for the MIT Technology Review magazine. He has the August cover story in the TechReview titled, "Social Machines" and has posted Social Machines on his site as of today. Please be sure to pick up a print copy and/or read the article on the TechReview site when it is published there.

[I should mention I am quoted in the "Social Machines" article]

It is Getting Personal

One of the main concepts around the Personal InfoCloud is access to our information when we need it.  It has become relatively easy to find digital information on the internet these days, but keeping track of information for ourselves is a huge problem.  Not only do we have the problem of tracking our information on one device, but across our devices (our laptop and desktop at work, our mobile, our PDA, our desktop at home) it become nightmare.  We have gone from the scent of information (Xerox Parc term), to the current stench of information, and we are trying to get to the sweet smell of information.

One of the tools that has helped many manage some of the information they find on the web is del.icio.us.  Del.icio.us is a social bookmarking tool that give the person the means to save the bookmark in a web-based tool and add tags (keywords) to the link that are of their choosing for their own bookmark retrieval.  The tool really caught on as people can easily refind that information they stored because it is saved using their own vocabulary.  Other people can find the same object (it is a shared "social" tool) if they use the same vocabulary to describe the same object.

It is time we all start to focus on the person and how they use and reuse the information.  How do people  combine disparate information in what have been separate applications and separate devices?  Our design and development has to get personal.

It is these solutions an focus that are lacking from many approaches to web and application development today.  Yes, it is still lacking, but it may not be for much longer.

What has changed the environment?  Personalization has triggered much of this change.  No, not the giant portal personalization that the content management overloads want to sell for mega-bucks and still provide mini-returns.  This is personalization that allows the person to decide what information or information source is important to follow.  People and vendors (be it information or products) have a desire to strengthen their connection.  Vendors need to make it easy on the person who has an interest in the vendor and one or many of their products.

One of the tools that has caught on in the mainstream is RSS/Atom feeds.  This allows a person to subscribe to the information that most interests them.  This information can be news feeds that are targeted to specific genres or it can be a listing of products newly available, as Apple is doing with its new additions to iTunes each week and Amazon is doing for it product categories. In the past e-mail has been one of the few avenues that has been available to provide a personal connection.

So if it is getting easier to have the information from vendors easily subscribed to, how difficult should it be to  subscribe to our own information?  This is one of the del.icio.us solutions, well it seems to be targeted to others subscribing to our shared bookmarks, but we can easily subscribe to an RSS feed of our own bookmarks  or even our own specific tagged bookmarks, should we wish to.

With calendaring we have similar subscription options if we use the iCal standard.  There are even RSS event capabilities that can be incorporated (RSS with Dublin Core attributes as Upcoming does, or event module attributes).  Subscribing is one solution, but often I need to add calendar events into my mobile device (Treo 600 or Nokia Series 60 phone) with out having to rekey everything.  There are open standards for calendaring, why don't mobile device calendar applications just incorporate accepting these standard file types?  Using standard solutions to keep all of the facets of our life, or at least our calendar related facets, seems to be a wise and relatively easy solution. 

Good Bye to the User?

One of the side-effects of my focus on the Personal InfoCloud has been finding putting the focus on the person gets to more options than focussing on the "user". When doing user interviews for existing systems and sites, we are interviewing people. These people we ask: What works for them; what is missing; What are the devices they use; What locations do they use the information; In what context do they use the information; and How do they reuse and repurpose the information (as some of the questions). These are real people supplying the answers.

In the past we roll-up these people's answers and build an user persona. In rolling up we are building one or many common users and try to generalize. This simplification of the problem set we build to starts to limit our solutions. If one percent or less of our user base is using a mobile device to access information or our application do we throw them out of the persona? Normally, we would tend to do this and focus on a higher portion of our population.

But, in building a user-centered approach we can miss some of the easy solutions that will help the people that are part of the smaller populations. By keeping the person with the mobile needs in the mix, we are able to build scenarios and solutions that will work across many device needs. The steps between a desktop/laptop web browser only community and many mobile devices is relatively small. The difference to the desktop/laptop user is minimal, but to the mobile user it can be the difference between having access to information when it is needed and not having access at all when the information is needed most (like working remotely on a project that is 50 miles from the nearest landline and internet connection).

As we look at providing solutions we base our choices on users who make up a large percentage of our population. Lets take the 80/20 rule, we build for 80 percent of our users with 20 percent of the work. Sounds good, until we realize that one in five users are left out of the equation. By focussing on the person, we can look at extending our success. Often by building more than one solution into our products or one interface metaphor (folders versus tags for storing e-mail) we can provide better solutions that work for more people. Does this add complexity? Many times, yes it adds complexity on the design and development side, but knowing early enough in the process we can build more open and more flexible systems that lead to greater adoption. Not, only do we get greater adoption, but we open up the potential for uses beyond what we designed into being.

No two people are alike and we should build toward this reality so that there is choice, freedom, and ease. The more granular approach does not completely wipe out the user personas, but greatly enhances their functionality. Go back to the original people interviewed and use them in scenario planning for their needs across their contexts and tasks. How well does what we are designing work for them? How different will a solution need to be to have it work for them? Do these users have older technology? Do we want to rule people out categorically or can we do a little more work and be inclusive?

Focussing on the person and the granularity is where things get more difficult, but this is where we can make huge differences. This is what we get paid for right?

Keeping Found Things Found

This weeks New York Times Circuits article: Now Where Was I? New Ways to Revisit Web Sites, which covers the Keep Found Things Found research project at University of Washington. The program is summarized:

The classic problem of information retrieval, simply put, is to help people find the relatively small number of things they are looking for (books, articles, web pages, CDs, etc.) from a very large set of possibilities. This classic problem has been studied in many variations and has been addressed through a rich diversity of information retrieval tools and techniques.

This topic is at the heart of the Personal Information Cloud. How does a person keep the information they found attracted to themselves once they found that information. Keeping the found information at hand to use when the case to use the information arises is a regular struggle. The Personal Information Cloud is the rough cloud of information that follows the user. Users have spent much time and effort to draw information they desire close to themselves (Model of Attraction). Once they have the information, is the information in a format that is easy for the user or consumer of the information to use or even reuse.