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


Closing Delicious? Lessons to be Learned

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


There was a kerfuffle a couple weeks back around Delicious when the social bookmarking service Delicious was marked for end of life by Yahoo, which caused a rather large number I know to go rather nuts. Yahoo, has made the claim that they are not shutting the service down, which only seems like a stall tactic, but perhaps they may actually sell it (many accounts from former Yahoo and Delicious teams have pointed out the difficulties in that, as it was ported to Yahoo’s own services and with their own peculiarities).

Redundancy

Never the less, this brings-up an important point: Redundancy. One lesson I learned many years ago related to the web (heck, related to any thing digital) is it will fail at some point. Cloud based services are not immune and the network connection to those services is often even more problematic. But, one of the tenants of the Personal InfoCloud is it is where you keep your information across trusted services and devices so you have continual and easy access to that information. Part of ensuring that continual access is ensuring redundancy and backing up. Optimally the redundancy or back-up is a usable service that permits ease of continuing use if one resource is not reachable (those sunny days where there's not a cloud to be seen). Performing regular back-ups of your blog posts and other places you post information is valuable. Another option is a central aggregation point (these are long dreamt of and yet to be really implemented well, this is a long brewing interest with many potential resources and conversations).

With regard to Delicious I’ve used redundant services and manually or automatically fed them. I was doing this with Ma.gnol.ia as it was (in part) my redundant social bookmarking service, but I also really liked a lot of its features and functionality (there were great social interaction design elements that were deployed there that were quite brilliant and made the service a real gem). I also used Diigo for a short while, but too many things there drove me crazy and continually broke. A few months back I started using Pinboard, as the private reincarnation of Ma.gnol.ia shut down. I have also used ZooTool, which has more of a visual design community (the community that self-aggregates to a service is an important characteristic to take into account after the viability of the service).

Pinboard has been a real gem as it uses the commonly implemented Delicious API (version 1) as its core API, which means most tools and services built on top of Delicious can be relatively easily ported over with just a change to the URL for source. This was similar for Ma.gnol.ia and other services. But, Pinboard also will continually pull in Delicious postings, so works very well for redundancy sake.

There are some things I quite like about Pinboard (some things I don’t and will get to them) such as the easy integration from Instapaper (anything you star in Instapaper gets sucked into your Pinboard). Pinboard has a rather good mobile web interface (something I loved about Ma.gnol.ia too). Pinboard was started by co-founders of Delicious and so has solid depth of understanding. Pinboard is also a pay service (based on an incremental one time fee and full archive of pages bookmarked (saves a copy of pages), which is great for its longevity as it has some sort of business model (I don’t have faith in the “underpants - something - profit” model) and it works brilliantly for keeping out spammer (another pain point for me with Diigo).

My biggest nit with Pinboard is the space delimited tag terms, which means multi-word tag terms (San Francisco, recent discovery, etc.) are not possible (use of non-alphabetic word delimiters (like underscores, hyphens, and dots) are a really problematic for clarity, easy aggregation with out scripting to disambiguate and assemble relevant related terms, and lack of mainstream user understanding). The lack of easily seeing who is following my shared items, so to find others to potentially follow is something from Delicious I miss.

For now I am still feeding Delicious as my primary source, which is naturally pulled into Pinboard with no extra effort (as it should be with many things), but I'm already looking for a redundancy for Pinboard given the questionable state of Delicious.

The Value of Delicious

Another thing that surfaced with the Delicious end of life (non-official) announcement from Yahoo was the incredible value it has across the web. Not only do people use it and deeply rely on it for storing, contextualizing links/bookmarks with tags and annotations, refinding their own aggregation, and sharing this out easily for others, but use Delicious in a wide variety of different ways. People use Delicious to surface relevant information of interest related to their affinities or work needs, as it is easy to get a feed for not only a person, a tag, but also a person and tag pairing. The immediate responses that sounded serious alarm with news of Delicious demise were those that had built valuable services on top of Delicious. There were many stories about well known publications and services not only programmatically aggregating potentially relevant and tangential information for research in ad hoc and relatively real time, but also sharing out of links for others. Some use Delicious to easily build “related information” resources for their web publications and offerings. One example is emoted by Marshall Kirkpatrick of ReadWriteWeb wonderfully describing their reliance on Delicious

It was clear very quickly that Yahoo is sitting on a real backbone of many things on the web, not the toy product some in Yahoo management seemed to think it was. The value of Delicious to Yahoo seemingly diminished greatly after they themselves were no longer in the search marketplace. Silently confirmed hunches that Delicious was used as fodder to greatly influence search algorithms for highly potential synonyms and related web content that is stored by explicit interest (a much higher value than inferred interest) made Delicious a quite valued property while it ran its own search property.

For ease of finding me (should you wish) on Pinboard I am http://pinboard.in/u:vanderwal

----

Good relevant posts from others:


The Future is Now for Information Access

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


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.


Mash-ups and the Model of Attraction

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


I have been thinking a lot about web2.0 mash-ups like Housing Maps since I was on a panel with Paul Rademacher. Particularly I have been trying to make sense of mash-ups in the context of the Model of Attraction. It was not difficult to use these models as a lens to better understand what is going on in these mash-ups. The irony is I needed to do a tiny mash-up of my own to better understand what is going on.

Let us use the Housing Maps as our sole example. Housing Maps takes the housing listing information from Craigslist and displays them by location as a layer in the Google Maps. Paul had built the tool in his spare time as the result of showing up at the same location to rent twice. The visual representation of the listings on a map helped him keep from doing this again. The visual representation also helps others better discern proximity and location (next to a freeway is why it is cheap, or near playground for junior, etc.).

The interpretation of this mash-up and other web2.0 developments require using a slight mash-up of the Model of Attractions's receptors (the receptors are intellectual (cognitive), perceptual (sensory), mechanical, and physical). One uses the receptors as a whole to design and develop information/media access for people in different contexts, with different devices, varying needs, and in different contextual needs. In the case of understanding the Housing Maps we know what the mechanical receptor is, it is a desktop/laptop computer as that is what the interface requires to use the tool. Housing Maps implicitly requires full visual capabilities, and the means to control a pointing device (mouse, etc) for the physical receptors.

The two receptors we will look at are the Intellectual Receptor and the Perceptual Receptors. The Intellectual Receptor is used in the design and development phases to understand how a person thinks about the information/media by understanding vocabulary, information structures, complexity of conveyance (what level and style of writing are used to convey the ideas), level of detail used, the amount of explanation given, use of metaphors, etc. The Perceptual Receptors are used to understand what sensory elements are understood by the people using the information/media. The sensory elements are comprised of visual, auditory, motion/animation, touch (haptic), etc.

The Housing Maps requires understanding the limitations of the resources being used prior to Paul's remixing. The information that Paul was using was Craigslist to find a new place to live. Craigslist is a rich information source that has a large variety of things for sale or giving as well as social connective communities (personals pages). Paul was using the housing section in the San Francisco Bay Area as his information source. The housing entries have descriptions of the properties for rent/let/buy, much like the old classified real estate ads in the newspapers (remember those) but with a little more detail and often including photos of the property. One element that many of the properties include is a location variable (address).

While the Craigslist information is rich and robust and a fantastic resource, Craigslist has a simple interface. This interface, much like that of a classified ad is about providing the information and using the space efficiently. The reality is no mater what is done to the visual appearance of Craigslist the information in text form and the photos are just those simple elements. A map included in each of the entries would be a little more helpful, but it is still rather limiting as it does not give an idea of what is really on the market and where all of the properties of interest are located (in the given parameters of the person's query). We have the Intellectual Receptors largely sated. The Perceptual Receptors (what does the page look like how does a person interact with the information (passively/actively)) could use a little more tweaking, but within the context of the static HTML page the information interface offers little opportunity for improvement.

The missing element in the Craigslist information is not data that is missing (except where locative data is not included in the Craigslist entry). The missing element is in the Perceptual Receptor which then augments the Intellectual Receptor. The contextual framework for locative information is missing from the interface. The array of information provided in the Craigslist interface needs another vector to view the information (Craigslist limits by price, rough geographical area, type of property arrangement (rent/lease/sublet/buy/share/own), animals, and keywords). This vector is a more fine grained view of the location information and put into a context that helps make sense of the information easily. The context is a map, which works well for displaying location-based information.

The Google map is used for the visual representation layer, which provides the context to the location information. The Google map is an open interface that is available to use for the display of location relevant information from external data sources. The interface if very helpful for this type of information and it is freely available for those with the skill sets needed to parse and feed the information into the Google maps interface.

The web2.0 mash-ups extract information from one source and display that information in a different interface. Tools like Bloglines do this with feeds and display the information in an interface separate from the website's interface from which the information was posted by the content creator/owner.

These mash-ups serve to provide the person consuming the information a tool that works for their needs. In a "come to me web" this is very important. The content provider/owner would have to invest many resources to provide a broad array of interfaces to search each person and each person's needs and desires for information. Additionally, as it is with nearly everything on the web the interface that aggregates information from a broad variety of information sources provides a richer set of information for the person to use and analyze for their own needs. Not only are the Intellectual Receptors augmented by the network effect of the information, but offering the personal consuming the information a means/lens (for their Perceptual Receptor needs) to view the information/media in means that adds value for their need is required for people to better embrace the web as a source of information that is a layer woven into their life rather than technology tools that augment their lives.


WebVisions Designing for the Personal InfoCloud Presentation

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


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.


Stitching our Lives Together

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


Not long ago Jeffrey Veen posted about Will you be my friend, which brought up some needs to better stitch together our own disperse information. An excellent example is:

For example, when I plan a trip, I try to find out who else will be around so I have people to hang out with. So my calendar should ask Upcoming.org, "Hey, Jeff says he's friends with Tim. Will he be in New York for GEL?"

This example would allow up to interact with our shared information in a manner that keeps it within our extended Personal InfoCloud (the Personal InfoCloud is the information we keep with us, is self-organized, and we have easy access to). Too many of the Web's resources where we store our information and that information's correlation to ourselves (, Flickr seems to use. The advent of wide usage of RSS feeds and RSS aggregators is really putting the user back in control of the information they would like to track. Too many sites have moved toward the portal model and failed (there are large volumes of accounts of failed portal attempts, where the sites should provide a feed of their information as it is a limited quantity). When users get asked about their lack of interest in a company's new portal they nearly always state, "I already have a portal where I aggregate my information". Most often these portals are ones like My Yahoo, MSN, or AOL. Many users state they have tried keeping more than one portal, but find they loose information very quickly and they can not remember, which portal holds what information.

It seems the companies that sell portal tools should rather focus on integration with existing portals. Currently Yahoo offers the an RSS feed aggregator. Yahoo is moving toward a one stop shopping for information for individuals. Yahoo also synchs with PDA, which is how many people keep their needed information close to themselves.

There are also those of us that prefer to be our own aggregators to information. We choose to structure our large volumes of information and the means to access that information. The down side of the person controlling the information is the lack of common APIs and accessible Web Services to permit the connecting of Upcoming to our calendar (it can already do this), with lists of known or stated friends and their interests.

This has been the dream of many of us for many years, but it always seems just around the corner. Now seems to be a good time to just make it happen. Now is good because there is growing adoption of standards and information that can be personally aggregated. Now is good because there are more and more services allowing us to categorize various bits of information about our lives. Now is good because we have the technology. Now is good because we are smart enough to make it happen.

(Originally posted at vanderwal.net.)


Upcoming.org and Others Understand Ease of Information Reuse

by Thomas Vander Wal in , , ,


Some sites are getting that helping the user with date related information by providing the information in a standard format that allows the user to drop the information into their calendar tool. One such site is Upcoming.org's iCal Integration.

The I recently ran across a similar tool, but for vCal, on the Hilton site. When you book a room on the Hilton site the site provides a standard calendar format data chunk that drops right into Outlook or other vCal ready application. This is a no fuss and no error means of helping the user get the information right and dropping it right into their Personal InfoCloud so they can synch that with their mobile phone or PDA and have the correct information (with the confirmation number) within ready reach at all times.


Information Structure for Information Reuse

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


John Udell's discussion of Apple's Knowledge Navigator is a wonderful overview of a Personal Information Cloud. If the tools was more mobile or was shown synching with a similar mobile device to have the "knowledge" with the user at all time it is would be a perfect representation.

Information in a Personal Information Cloud is not only what the user wants to have stored for retrieval when it is needed (role-based information and contextual) but portable and always accessible. Having tools that allow the user to capture, categorize, and have attracted to the user so it is always with them is only one part of the equation. The other component is having information that is capable of being captured and reused. Standards structures for information, like (X)HTML and XML are the beginnings of reusable information. These structures must be open to ensure ease of access and reuse in proper context. Information stored in graphics, proprietary software, and proprietary file formats greatly hinders the initial usefulness of the information as it can be in accessible, but it even more greatly hinders the information's reuse.

These principle are not only part of the Personal Information Cloud along with the Model of Attraction, but also contextual design, information architecture, information design, and application development.


RSS on PDAs and Information Reuse

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


Three times the past week I have run across folks mentioning Hand/RSS for Palm. This seems to fill the hole that AvantGo does not completely fill. Many of the information resources I find to be helpful/insightful have RSS feeds, but do not have a "mobile" version (more importantly the content is not made with standard (X)HTML validating markup with a malleable page layout that will work for desktop/laptop web browsers and smaller mobile screens).

I currently pull to scan then read content from 125 RSS feeds. Having these some of these feeds pulled and stored in my PDA would be a great help.

Another idea I have been playing with is to pull and convert RSS feeds for mobile browser access and use. This can be readily done with PHP. It seems that MobileRSS already does something like this.

Content, make that information in general, stored and presented in a format that is only usable in one device type or application is very short sighted. Information should be reusable to be more useful. Users copy and paste information into documents, todo lists, calendars, PDAs, e-mail, weblogs, text searchable data stores (databases, XML respositories, etc.), etc. Digital information from the early creation was about reusing the information. Putting text only in a graphic is foolish (AIGA websites need to learn this lesson) as is locking the information in a proprietary application or proprietary format.

The whole of the Personal Information Cloud, the rough cloud of information that the user has chosen to follow them so that it is available when they need that information is only usable if information is in an open format.

Syndicated from Off the Top :: vanderwal.net