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.

Broken Decade Precedes It Works Decade

I had long forgotten this Carl Steadman response to Michael Sippy's "Just One Question - What do you want for Christmas", but the response from 1997 is fantastic and frames the 1990s as the broken decade. (I'll wait for you to go read it)

I'm not so sure that Carl's broken decade got better in the first half of the 2000 decade, but it really started to. We are much farther along now. Our consumer world started to improve quite a bit and slowly business systems and services are slowly improving. The initial part of Carl's rant focusses on the number of steps to get something going. Once it is working the steps are still clunky.

Carl gets in a great rant about time and how broken it was in the 90s within technology (calendaring and syncing is still a beast and likely to for a bit longer - you understand the problem sets and pain points if you have ever tried to build syncing). With calendaring and its related activities we now have Tempo, which is freakishly close to the next step scenario I used in many of the Come to Me Web presentations and Personal InfoCloud presentations from 2003 through 2007 (I've been getting requests to represent them as this is what more and more developers and designers are dealing with today and need to have a better foundation to think through them). There was an internal Yahoo presentation (and follow on day of deep discussions and conversations) with a version of the Personal InfoCloud and Come to me Web flow that is nearly identical to the Tempo app video scenario and ones spelled out in Robert Scoble's interview with Tempo CEO, which is utterly awesome that it is getting built out some 10 years later (we had the technology and tools to do this in 2004 and beyond).

Carl's rant gets worn away over time though consumer devices, services, and applications. The refocus on ease of use and particularly the use through mobile, which requires a very different way of thinking and considering things. It thinking through design, the dependancies, and real user needs (all while keeping in mind the attention issues, screen size, networking, and device limitations). The past couple years mobile finally caught on with mainstream users and people doing real work on the mobile and tablets - Box 40% mobile access of files stored there over the last couple years. Many other business vendors have had mobile use rates of their services from mobile over the past two years. When talking to users they opt for mobile solutions over their full enterprise tools as they are much easier to use, which quickly translates into getting more work done. As Bernd Christiansen of Citrix stated in an onstage interview the employee's most productive part of the day is often the walk from their car to the front door of the office working on their mobile devices.

This world is not fully better and fully easy to use from the days of Carl's rant, but it is getting better. We still have quite a ways to go.

Stikkit Is a Nice Example of a Personal InfoCloud Tool

I have been using the newly launched Stikkit for the last day and rather enjoying it.  Stikkit, is a web-based postit with super powers of a notepad with bookmark, calendar, lite address book for people, tagging, to do, and reminders to SMS (in the U.S.) and/or e-mail.

Stikkit is the product of values of n start-up that is the founded by Rael Dornfest, formerly of O'Reilly.

This summer I was in Portland and got a preview of Stikkit and was really impressed.  It was a slightly different application at that point, but it had the great bones to be a really nice application for one's own Personal InfoCloud.  Much of the really good intuitive scripting that turns dates in text into calendar entries, text to do lists into ones that can be checked-off, and other text to real functionality is in the current version and just sings.

When I used the Stikkit bookmarklet it captured pertinent information from a page that I wanted to track, which had date related information that is essential to something I have interest in, it made a calendar entry.  The focus of the Personal InfoCloud is to have applications and devices that let people hold on to information that they have interest in and move it across devices, as well as add their own context.  Stikkit, really is a wonderful step in making a rather friction free approach to the Personal InfoCloud. It puts the focus on the person and their wants and needs for the use of the information in a page.  Stikkit can free the information from the confines of the web page and alert the person to important dates.  Stikkit also allows the person to share what they find easily.

I think the key to Stikkit is the term "easily", which is the underpinning of the whole application.  The only thing I would love to see is <

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.

Location? Location? Where am I?

I have been traveling more than usual this year to places in the United States and Europe. Some I have been to before and others I have not. Many of the trips are to places for only a few days and are set around meetings, conferences, or speaking engagements. I am often making plans at the last minute or having to make arrangements on the fly as ancillary meetings (not the prime reason I am there) get moved or cancelled. I am often looking for food, coffee, wifi, electronic stores, hardware stores, etc. in a location I am not completely familiar with. I am needing services of the local businessman, but I am not local.

The "Local Services"

You say, "there are many local services". Yes, there are Yahoo Local, Google Local, A9 Yellow Pages search, and other more local guides. But, none of them work on a mobile. There are Google SMS search and Mobile Yahoo, which has search that can tie to your local info, but if I am traveling I most likely have not save where I am looking for options.

Most modern phones know your location, they have to by law in the United States for emergency service calls. The phones do not provide easy access to that location software because the carriers providing the service do not want you to have it for free, they want somebody to pay for that information. If I call information they are not going to tell me where I am, nor the type of service or store I am seeking.

A Hack Finds "Where"

My current hack is to stand in front of a store, which I know the street name and I send the request for information about the place to Google SMS (ritual coffee. san francisco, ca) and I get one important piece of information back, the zip code. The zip code in the United States is the key to getting location information. There is nothing when driving (or actually riding as a passenger, because one never text messages while driving) or walking around that tells you the zip code (I have given up asking strangers on the street the zip code as it is more often than not incorrect). Once I have the zip code I can ask the mobile services for "coffee 94110" and get another place to get coffee and sit down because Ritual Coffee Roasters is utterly packed and already has seat vultures hovering.

Ministry of Silly Steps

Doing this little dance I get options, but it is a few steps that I should never have to take. The information most needed in a local search when mobile is location

Zip It, Zip, Z..

With the zip code I can dump that into my Mobile Yahoo! "new location" and get results. But, even because Yahoo! Mobile knows it is me (they offered me my stored locations (such as Home and Work)) it does not use that information to give me things I have reviewed and stored in Yahoo! Local. In the online version of Yahoo! Local I get reviews from people in my "community" (that really really needs to get a firm understanding of the granular social network), which is often helpful (if I know the person and can adjust my perception because I know how close that person's preferences are to mine on that subject). Sometimes I need an extension cord or an Apple Store (or a good substitution).

Elsewhere: Missing Even Partial Solutions

Additionally, this only works in the United States. The global local versions of Yahoo don't have fleshed out local services that are anything close to what is available in the United States and my "community" (as imperfect of an approach as it is at the moment) is still more helpful at filtering than nothing and I know I have many people in my "community" that have not only been to the same locations I am in, but have reviewed restaurants, local stores, etc. on the web and I want to be able to pull that information back in. Yes, this means the services need to grasp and embrace digital identity to make this work (or just build a social network capable address book that knows who my friend's identities are on various other services and social networking tools where this information may be sitting - not rocket science by any means). I heard some native language services were around, but those would not be fully helpful to me (I think I could get through it however), but if I tried a service that did not work it is not pointing me to one that does (now that would be insanely helpful and I would likely go to the kind service people for everything first as they would point me to just the right place every time).

Ya Beats Goo

Well at least Yahoo! understands there are places outside the United States. Google's services are not there, or any where on the mobile front it seems. In my last trip to Europe nobody knew that Google offered these services, which it seems they do not, in one of the most mobile use intensive cultures in the Western Hemisphere.

Enough

I know, enough. I agree. We need mobile information that works. WiFi is not here everywhere. Even if it were I am not foolish enough to pull out my laptop to try and get a signal and then get the information I need. I have a mobile device with the perfect capability to do just this. Actually there are more than double (if not triple - can not put my fingers on this info) the users with this capability on their mobile than laptop users in the United States (foolishly most laptops do not have locative hardware in them to ease this possibility if it was your last possibility). The technologies are here. Why are we not using them?

Bubble-up Folksonomies

Tom Coates has a great post on How to build bubble-up folksonomies based on the work he, Matt Webb, Paul Hammond, and Matt Biddulph had done for the BBC. I have been hearing about this work for a while from these Coates and Webb and it was really nice to see such a good write-up (very good to great write-ups are the norm for Tom).

These guys at the BBC have been doing stellar work the past few years around social software, emergent technologies, and mobile interaction. With Matt Webb gone (he has formed his own stellar design firm Schuze & Webb) and with Matt Bidulph moving on it will be interesting to watch how the BBC keeps up its pace of great work out on the forefront of technology and interaction design.

WebVisions Designing for the Personal InfoCloud Presentation

The presentation at WebVisions of Designing for the Personal InfoCloud went quite well yesterday. There is ever growing interest in the Personal InfoCloud as there are many people working to design digital information for use across devices, for reuse, for constant access to information each individual person desires, and building applications around these interests.

In an always on world peoples desires and expectations are changing for their access to information. The tools that will help ease this desire are now being built and some are great starts have been made in this direction. I will be writing about some of these tools in the near future.

I am more exited today than I have been in quite some time by what I see as great progress for the reality of a Personal InfoCloud. It is ever closer for the Personal InfoCloud being more automated and beginning to function in ways that really help people find efficient ways to use information they have found or created in their lives when they want it or need it.

Not only does the Personal InfoCloud need devices but it needs people designing the information for the realities of Web2.0, which is not the old web of "I Go Get", but the new web of "Come to Me". This change in focus demands better understanding of sharing digital assets, designing across platforms and devices, and information being reused and organized externally.

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?