Working Out Loud in Hallways with Memory

by Thomas Vander Wal


I am deeply enjoying working out loud again with a team. There are so many great advantages to sharing what you are working on in progress. This is often how I worked with clients from 2005 through to early 2012 and it was so odd to move back into an email heavy work environment, and is now so refreshing to be engaged back with a team that shares works in progress.

As I pointed out in the latest, Shift Happens - Part3: Capturing Decisions in Social the results of the work are most often not the most valuable portions, it is the collective aggregate of the work that gets to that point, that has the most value. As we all regularly experience, what is today’s good decision often is not the best for tomorrow, nor a slightly different circumstance. But, teams, groups, and organizations not working out loud, even if just at group and team levels, don’t have any of these advantages of finding, integrating, nor reusing information and understanding shared along the way. Most often these transactions are lost in email. There is great value lost and buried (with not even the decency of a funeral) in email.

I caught a great tweet from Stewart Butterfield the CEO of Slack that drives home one of the great values of teams working out loud and having all the work collateral attached and searchable, not only is it great for the team or group, but is fantastic for the next member of that assemblage who is added in. Here, Stewart is responding to Chris Sacca asking about if Slack works well for a team of 3 people…

I’ve become a fan of Slack in the past year (it is less than a year old publicly) because it does for teams and groups what a tool I miss (SystemOne) did for larger organizations — it provides search across a collective’s work out loud contributions. Not only the conversations, but the linked to documents, code, sites, etc. to keep what is relative to the teams within easy digital reach. The conversations that used to be lost in meeting rooms and hallways are now captured, as a by product of working in a virtual team the hallways and meeting rooms now have memory.


Shift Happened - Part 3: Capturing Decisions in Social

by Thomas Vander Wal in , , , , ,


In the last 5 years many people have been working amidst a shift in how they work digitally and where they interact digitally with colleagues. They also realize the product of their work may have shifted as well. The work product has long been presentations, white papers, spreadsheets, general reports, etc. These deliverables are products of the work done and are often only a small representation of the thinking, considerations, and actual work put in to get to the final product. This final product has long been treated by organizations as the document of record, which is the model for the systems they have been working around for years.

The value of these output creations, or documents in a system of record are limited as the half life of their value is often rather short as the conditions and reality of the context they were created in and for is usually in continual flux. This means once the document is delivered not only is it (if all went well in the creation of it) correct for a relatively short period of time, but it is often just a transition point for other work. The deliverable is presented or handed over and others and then begin their work, it is just an interstitial between two or more sets of activity.

Realizing the Big Value

Many organizations have been realizing the value in their documents that are storing, while helpful, is only a small slice of the value captured from the work that went into it. Many organizations have employees doing their work with their colleagues in collaboration / social platforms and have been using these systems of engagement to capture the work in progress. When organizations start looking at the work that is captured in these tools and in formats that are relatively easy to use, they realize the value in them far exceeds the value in the outcomes document that is tucked away in they system of record, which often are rarely returned to.

What the systems of engagement offers is solid insight into the framing of the problem, the multitude of options, the researching and testing the options, thinking through the options, and often how the decisions for inclusion and exclusion were arrived upon. Much of this is captured in the service tacitly and / or explicitly. The key is to turn the tacit into explicit, or at least make it discoverable.

There is a wide valley between tacit and explicit knowledge. Capturing conversation and information flows was often enough to flip the tacit to explicit for some. But, this is far from binary as it really should be easily found and addressable. One system that for many years has provided the ability to point to and annotate at a paragraph level it Traction Software, which can be and is used to annotate decision inflection points as well as information of note that can be used to highlight and annotate likely highlights for decisions.

Systems of Engagement Meet Systems of Record

Systems of record are often the tools where outputs and outcomes are tracked. Document management and content management, Customer Relationship Management (CRM) that tracks sales and customer interactions, Enterprise Resource Planning (ERP) that tracks supply chain and product delivery, and more that are tied to business roles and / or lines of business. The systems of record are often the meta layer as the work is not done there, but the representation of that work is.

The systems of engagement are the various communication, collaboration, and social business network services. The discussions, sharing of resources in and around work, and often decisions regarding what moves forward and not often happens in these services. The ability to capture the decision points and the more minor inflection points is an incredible value. But, this takes a step beyond just purely capturing it, the inflection and decisions need to be easier to find than many services offer.

There are some work around solutions, which include the print a PDF of the pages / screens with inflections and decisions, then highlight and annotate the PDF and place it in the document repository. Ya, not so elegant, but it sort of works.


Shift Happened Series


Shift Happened - Part 2: Small Apps Loosely Joined

by Thomas Vander Wal in , , , , , , , , , , , , , , , ,


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


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

by Thomas Vander Wal in , , , , , , , , , , , , ,


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


Donna, Designed for Use, Closes

by Thomas Vander Wal in , , , , , , , ,


The impending closing of Donna has bumped a couple of thoughts to blog to the front of the queue.

First off, Donna is an iOS calendaring app that focusses on one’s agenda for that day and upcoming days with a targetted focus on the transportation timing and how that impacts your day. If your life has children that need transporting between activities or work that is out and about bouncing to meetings or work sites Donna is utterly indespensable. Donna puts a focus on the getting between places, so calculates the travel time to let you know when you really should leave, as it monitors traffic and weather conditions. The app offers four different modes of transportation and the related times for those: Driving, public transit, biking, and walking.

One of the best parts of Donna, which many other applications also do, is it reads your native calendar on iOS and augments it. It isn’t a separate calendar to lose things in if you forget. Content you may modify to help plan in Donna, like search to find the exact location for a meeting, is added to the calendar object and can be used in other calendar apps. I will focus a bit more on this in the following section on “Small Apps Loosely Joined”.

Not only will Donna give you a warning when it is approching time to leave, but it can send those you are meeting with notification that you are on your way and / or you are running late. Donna also monitors the weather and can advise on transportation changes should you be walking or biking. One other really helpful element is having the option to use Uber, if you are in a city that has it (Donna knows) and the event is that day (this was incredibly helpful this week).

One of the wonderful things is the evening of the day prior Donna provides a notification of how many meetings you have the next day, but if you don’t have any in your calendar(s) it tells you to enjoy your day, which is a wonderful little touch.

Designing for Use

The thing that stands out with Donna is not just its really good interaction design and really well designed information structures for easy to scan appointments, but it is designed to solve a pain point. Most specifically it is designed for use. The design is focussed on solving a problem and to be an easy to use solution for that problem, which is: I have meetings and activities in my day that take me out and around and sorting out the timing so I can optimize my day for my interests (get more time by driving, more health and environmentally focusse using bike or walking, etc.). Letting others knwo when you are late or on your way is really helpful and directly tied to the mobility of getting to meetings and activities. Having an app that pulls all the needed information around that task set is fantastic.

Donna isn’t designed to be a full replacement for a calendar, but is there to augment it and the use needs around the activities of getting between places.

Donna also understands what is needed as well as not needed. Allowing for modifying settings for alerts and notifications is really helpful. Understanding when alarms are not going to be helpful, understanding helpful user preferences when you are running late (auto send notes, how far ahead, or not to send at all automatically). Donna was built with the idea of a really helpful human assistant who looks after your schedule and is a step ahead of you. This framing of use and a helpful model really shines through in the app.

Small Apps Loosely Joined

Donna and many other calendar apps that are on mobile devices are not aimed at fully augmenting your native calendar service, but to integrate and augment that service. The model that is increasingly familiar is along the idea of small apps loosely joined model. This model puts a focus on using standard data structures, common object types, and a central app or service as a hub to provide a foundation for other apps and services to use the core object and augment it, often with data that fits the model type, and exends use.

With Donna the object is a standard calendar entry that has day, time, timezone, location, who are meeting with, notes, etc. But, the app can improve the data in the object, such as location. But, most of the apps not only improve the information within itself, but improve the core data so all other apps that use that object as well. The apps are often offering agency to do a task, or set of tasks, around the object. Donna puts the use focus on the use needs for getting there and communicating with others around that activity.

With calendaring, many using Mac or iOS opt for Fantastical to imput new calendar items as its native language parsing into a calendar data structure is incredibly good. Some people really like the interface from Fantastical and use it to view their day and upcoming events. There are an incredible amount of viewing your calendar / schedule options out there. Another smart agent for the calendar is Tempo app, which works to aggregate everything around a calendar item and pull it into easy reach (very much in the Come to Me Web model). Tempo pulls all the contact information for all participants in a meeting, all related email, all related files, weather, etc. all within easy reach as part of its view of the calendar entry. Tempo is as indespensable as Donna is for me personally (and I heavily rely on Fantastical for easy input, on my mobile I talk the calendar entry info into Fantastical and let it do its thing).

Who is Living the Small Apps Loosely Joined Life?

So who is working this way? Not so surprisingly, if one has been paying attention to how people actually are using devices and services, the user survey’s the past year or so have been asking about using more than one app for task types (calendaring, notes, reminders, text, etc.) and finding that 60% to upper 70% of those surveyed are using multiple apps for task types. Those surveyed have often been well outside of the geek and nerd camps that have worked this way for years, but regular folks who are not deeply adept technically. The focus on apps that do a task or set of tasks insanely well and easily trump a large app that does many things somewhat well. That one size fits all and category winner thinking has been dead for quite a while and is far from helpful model for thinking about much of anything.

The last few years, either in conferasions or listening to them, with people talking about their apps and how they do things on the devices (often mobile and tablet) it is increasingly common to hear, “I use a few apps to do…” what follows is calendaring, text documents, notes, mapping, driving directions, reminders, etc. and two or more apps stated and the specific tasks and user flow they have for each app. These were often non-geeks, but having surveys targeted at mainstream users and their habits and use patterns really brought home how mainstream this actually is.

Good Bye Donna

As Harry McCracken pointed out in Yahoo to Donna Users: We’re Dispensing With Your Indispensable App Donna has become indispensable for me. The great folks at Incredible Labs (that includes bud Kevin Cheng) did a fantastic job with Donna. Keeping Donna going was likely going to be a struggle as the computing to suss out location and needs as well as the and licensing the transportation times they used was not going to live a long time as an ongoing free app. The competition with other apps starting to incorporate similar time for transit models (yet clearly not designed from a perspective of use, but as a feature to add) likely was going to make things tougher as well as Apple adding transporation times and notifications based on that in Mac’s Mavericks version (adding it to desktop OS and not the mobile OS really was an odd move that is very un-Apple as it was not designed from a use in mind perspective).

It has been a while that I have been worried about the long run for Donna. A chat with Kevin about running a start-up in this space somewhat gave legs to that concern. Many start-ups have an exit in mind from the start and with any luck and perseverence it is a positive exit (not just shutting it and going bankrupt). I am really happy for Kevin and the other Incredible Labs folks as they got a positive exit for them and I wish them well at Yahoo (for all that are making that transition). Incredible proved they could nail a service that is designed for use, which leads to it becoming a really valueable part of people’s lives. Thank your for bringing us Donna as an agent to greatly improve our lives.


Responsive Design is Part of the Question not the Answer

by Thomas Vander Wal in , , , , ,


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.


Alexander Howard Interview with Christopher (moot) Poole from October 2011 Transcript

by Thomas Vander Wal in , , ,


Alexander Howard Interviews Christopher Poole (Moot from 4Chan) at Web 2.0 Summit in 2011 (October 18, 2011)

The video interview is at YouTube Christopher Poole Interviewed at Web 2.0 Summit 2011

4Chan is 8 years old and Christopher founded it when he was 15 years old.

Transcript of the core conversation:

Alex Howard: ... What have you learned along the way?

Christopher Poole: I think that I've learned more about what not to do than what to do. Because, 4Chan itself is modeled after this other community, it is modeled after this Japanese website community called Futaba Channel and when I was younger I watched a lot of anime and found Futaba and though this is fantastic and nothing like this exists for English speakers and Western culture. So I translated it and hosted it. A lot of its success has come from the fact that it was very different at the time and was this image based form of communication that wasn't quite popular in the U.S. and elsewhere. It has grown steadily and organically over all these years. There has been a lot of work put into it, like creating a homepage, doing news posts, recruiting volunteers, creating a ruleset, adding new boards, and trying to guide it. But, it was something that has grown as a natural process over the years.

I think that I've deserved more credit for not making mistakes and pulling a Facebook and pissing everybody off, like clockwork. I've done things that have upset people and there are times there are things that people didn't agree with. But, it is more about how do you try the happy medium than going to the extremes, that was part of my talk today as part of the message.

AH: The thing with Facebook is the users are upset, but the users aren't leaving, from what we can tell. What is going on there?

CP: I think it is lack of alternatives. It is very hard to migrate off of Facebook as that is where your [social] graph is. Frankly, for a lot of people for a lot of uses it is a good product. I use Facebook and 800 million users use Facebook. It is just that it is not great at everything and they are sometimes insensitive to these decisions they have made. Part of it is educational, as users will act negatively to things they don't understand, like the profile changes a couple months a to and people acted really negatively to it, but really nothing much had changed. They just needed to do a better job of communicating what those changes were. But, it is hard to leave, like any walled garden.

AH: Right. The costs of leaving become bigger and bigger as more people join.

Facebook has a "real names policy" in theory, in practice there is some wiggle here and there, but that is the standard. With Google+ there has been quite a lot of controversy around that famous "nim wars" online. What's the role and importance of anonymity online? Should that be held up as an important thing for communities, as they become created, to keep or countries to protect?

CP: It is absolutely important. It is more important as a contrast to [real names]. People paint this in black and white, when it really isn't. Nothing should be no one right way of doing anything. I think most people view anonymity as a natural opposite to something like a Facebook identity. With Plus I think Google really missed this opportunity to really innovate in a way that Facebook hasn't, and to support this idea that you are many people. I mean, Christopher Poole with a face is different than Christopher Poole without a little picture. Which is different than a Chris, than a Moot. We are all different people based on the context where we are faced. We are different people in front of different audiences. Google could have used that opportunity to support this fluid identity.

One of the things I talk about is this prismatic identity, that you are multi-faceted. You are not just who you are sharing with, it is who you are sharing as. It is really a piece of you is changing and people are seeing a different face of you. Google could have done a better job of "that is totally it, let's run with that". Instead they deleted accounts without real names. They don't even let you pick a vanity URL or user names. It is even worse than Facebook is, in that sense.

AH: So, constant back and forths in the media community is whether you need to have someone's real name to have a good community on a site. Is community about having real names on the Internet? Or is it something more?

CP: No, because identity is not real names. It is about having an identity or having some amount of accountability within a community. You can even have accountability in an anonymous community. I mean 4Chan is the most accountable place on the web, because if you are an outsider there are no structural barriers to using 4Chan, you can come in, enter it, and use it - and yet you can't. In lieu of these structural barriers the community has erected these socio-cultural barriers to understand the community, to understand the language, and how to act on the site. If you are a new user and you post, there is this is this concept of "lurk more", people will identify that immediately, and will reject you and will be like "you need to lurk more" and you need to understand more before you try to be one of us. So again you don't need a full name and a registration date for someone to say this person is new and needs to lurk more, they can tell by the way you interact. You can have accountability in anonymous communities and you don't need a real full name. Most people try to draw this as anecdotal evidence that is drawn from YouTube comments, that have been historically pretty horrible in the things that people say. But then again they have a user name that is persistent across YouTube as a service and that YouTube name is now linked to a Google address. So clearly they are very accountable to having a person identity to Google, and yet for what ever reason people choose to feel like they can be total jerks on YouTube. I think that has more again to do with the community, because that community has been accepting of that. There are many communities that are the ones you see the bad comments and they don't seem to discourage this the way you see on other sites. So, it is not a one to one relationship between a real name and an identity.

AH: When you look forward to this future of other people trying to create communities or trying to fix the ones they have, what are the things they should not do?

CP: I think to try and prescribe that there is this one you. That is Facebook's version of the world, that there is one you, and who you are online is who you are offline. An example I used earlier was, Google and Facebook think of you as a mirror and that you have one reflection. That reflection you see in that mirror is the one everybody else sees. Again, not true. People are multi-faceted, people are more like diamonds. You can look at a person or a diamond from any angle and see something different, and yet it is still the same.

I would encourage them to think about, it is not just about anonymity versus full names. Encourage them to think about choice is not necessarily a bad thing, giving your users the options to choose how they are identified on the service is something that you want to do. Again, you can incorporate something like Facebook Connect to use it to authenticate a user, to ensure they are not a troll or a spambot. But, just because you are using Facebook Connect doesn't then require that you post with a full name and a profile photo. I think being very aware of the fact that as humans identity is a complex concept and to allow that flexibility in a web product.

AH: So, last question. When another site on the internet, whether it happens to be a person, a blog, a media site, or whatever happens to invoke the wrath of 4Chan, they can sometimes receive a great deal of traffic or sometimes or more difficult attacks. Right? When I say attack I mean only in the technical sense, there are some technically able people that are part of your community.

To what extent can you look ahead to the way the web is evolving and shape that conversation with the amorphous group of people when something happens that the offline world doesn't understand, when there is a great deal of focus put upon another website. Is it the fault of the website owner or is it the community? How should we understand what is happening?

CP: This mob mentality or groupthink is something that has existed for hundreds and hundreds of years. You look at any war basically, particularly one motivated by religion. People are able to get riled up in mass quantities, given the right kind of spark.

I think now more than ever, it is not just 4Chan it is this group Anonymous that when you trace back is now something very separate from 4Chan, it is really its own distinct thing. Now more than ever we see it in the news we hear about it every day. It is not just then, we hear about Occupy Wall Street, that was a lot of different groups that came together. Now we are seeing this mobilization of online forces, not only online but also offline. That change happened so rapidly over the course of the past three years that we are still trying to come to terms with that.

The future of groups is so unpredictable. That is why with 4Chan I have felt that I am no more than the shepherd. I am the guy who only has a certain... I am at the wheel but I don't control the wind. Given the wind I can only have limited control over the direction of the site. I've always tried to maintain it as something where it had a very basic set of rules and believing there was this invisible hand, John Locke style of community moderation, where we can do some kinds of basic things and set some basic boundaries. But, more or less, it needs to come from the community itself. The community at some point needs to self regulate.

AH: Any principles for self regulation that exist come out of 4Chan?

CP: There are some basic rule, like don't be totally crazy and break the law. [chuckles] We are still figuring that one out.

AH: Okay. I think we are all still figuring this one out as we move forward.


Resonance in Sound and Design

by Thomas Vander Wal in , , , ,


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

by Thomas Vander Wal in , , , , , ,


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.


Broken Decade Precedes It Works Decade

by Thomas Vander Wal in , , , ,


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.


How to Tame the Daily Feeds

by Thomas Vander Wal in , ,


Link to original column: Personal KM: How to tame the daily feeds

Original post date: July 5, 2011

[Editor's Note: Thomas Vander Wal has spent many years as an infovore, gathering, reading, annotating and reusing the volumes of information he has run across. Over the years, he has searched for the ever-elusive one perfect solution, method or tool. But, this digging has surfaced many approaches that work for a variety of needs, and they are what he is sharing.]

Like many people, I struggle with a large amount of inbound information that has potential value today, but also value to myself and to others down the road. Being able to sift through the information and manage what is needed today, as well as keep potential future needs close at hand, is essential. A few approaches have helped me over the years, but a mix of personal practices and tools help keep some of this in check.

My practice started with a rather healthy RSS feed many years back where I followed 400 or so feeds. The daily new items in the feeds numbered well over 1,000. But in that flood, I found items of great value that I was not finding elsewhere, and that value still continues today. Those nuggets help me to be better informed for work, but also provide a solid repository for understanding and writing about the world around me.

The first round

The process still requires me to see things; it is a "who and what" pass through the information. I learned very quickly not to really read things on first pass, but to look at headlines of the individual feed items, and anything of remote interest gets opened into a Web browser with tabs. Paying attention to the source of the information, as well as to the headline, helps decide whether something gets opened in a browser tab, because certain people continually provide solid information that is worthy of attention. The first pass may have identified 60 to 70 items out of 1,000 potential ones. That step often takes 20 to 30 minutes, which indicates the depth of the review.

I found I could perform that portion of the process much more quickly in a desktop feed reader than an online reader because I could optimize the typeface size and only see headers, which allowed a view of 50 to 100 unread headers at a time to quickly skim through. Much of that was done on a Mac using NetNewswire.

A little closer look

After I have gone through all of the items in the inbound queue and things of potential value, I move onto a slightly deeper scan than just looking at the headlines. This pass assesses potential value and is a quick read of the first paragraph or scan of the whole piece to quickly assess if there is any value. If not, the tab is closed and I move on to the next item and skim it. At the end of this, I have removed duplicates and things that were not of interest or foreseen value, often in 10 minutes or so.

The last step is to go back to the remaining items (usually 10 items or so, with some days only one or two and others 30) in their open tabs and read them in more depth for current needs. Items that have current value I leave open. I will come back to them after I manage those with future value. I read the items with current value closely, summarize and add them to a work social bookmarking tool, as well as to a Web social bookmarking provider (if it is relevant and prudent).

I don't read as closely the items with future value, but I add them to a social bookmarking site, like Delicious, Diigo, or Pinboard (as well as to any work-related service), and tag them for my own context and others' needs, tie them to future needs as much as possible, and summarize them. I may also add those items to Instapaper to read at my leisure.

One nice benefit of Instapaper and Pinboard is that they work together. As I find things I want to read in depth in Instapaper, it will put the link into Pinboard as to-read, if you have the two services and accounts connected. That connection makes it relatively easy to update in Pinboard to add tags to put your context on it and a summary. I also can view the "from Instapaper" tagged items and read those I have not read, which have a tag "mark as read," if I have not read them in Instapaper.

This interwoven system is just one slice of keeping on top of the information that streams past us. As it is with many things these days, staying on top of the inbound information is essential. This approach is one of many options, but can make a good dent on staying current and informed today and tomorrow.  


Coming Out of Hiatus

by Thomas Vander Wal in , ,


Things have been a bit quiet here, but many changes on this side of the screen are settling and allowing idea and writing focus.

One of the things I am pulling together are my columns from KM World on Personal Knowledge Management (it unintentionally went into hiatus at the same time). One of the great things about writing for KM World was after a set time I have the rights to my own writing to do with as I wish.

Social Lenses Workshop

Also, those of you interested in the Social Lenses I have a half day workshop offered on April 3, 2013 in Baltimore at the IA Summit Workshop: Using social lenses to see social dimensions. The only way beyond our current less than optimal state of social software and service offerings is to see it differently, distinctly, and more deeply.