Experience Planner » questions

Jeff Explains: How to Plan a Widget

Jeff — Wed, 18 Jun 2008 04:15:24 +0000

Q: What is a “widget”?

A: To understand widgets, we first need to consider the history of the word.

Originally, the word “widget” was used in business classes to describe a non-specific product. For example, business students might play a simulation game in which they were put into teams that sold “widgets”. It was their job to figure out how to differentiate their widget and market it to consumers.

More recently, the word “widget” has been adopted to describe any small application or tool, ranging from a blog badge to a Facebook application. This usage was originated by executives who were shown various small applications and tools and didn’t know how to describe them. So they used a nonsense word.*

The bottom line is that the term widget has been used to describe so many diverse things that it’s not really a useful word any more. If someone starts talking about widgets, or asks you to design one, the first thing you need to do is work with them to figure out what they really want.

*This is not actually true. To the best of my knowledge, the word “widget” was coined by the people who developed Konfabulator (now called Yahoo! Widgets), which was was one of original platforms for hosting small applications on a PC desktop. But I do think the term “widget” has been co-opted by executives and stretched to the point of uselessness.

Q: How do I help someone figure out what kind of widget they want?

A: There are three important attributes to every widget. If you define those three things, then you’ll be well on you’re way.

1. Purpose
2. Audience
3. Platform/Technology

Let’s look at each of those attributes in detail.

Purpose
It’s sometimes hard to know whether you should begin planning a widget by thinking about your audience or by thinking about the purpose of the widget (i.e. the business objective of the widget). My feeling in this case is that you need to decide on the type of activity you want to encourage in users before you go too far down the path of figuring out what your users want. But purpose and audience really go hand in hand, so you need to keep both in mind as you work.

Based on my own observation of widgets, I am proposing 4 high level purposes that a widget may have.

1. Perform a task
2. Provide information
3. Gather information
4. Connect people socially

Note: I will add a page of example widgets that demonstrate each of these purposes in the near future.

Actually, a widget might fulfill several of these purposes at the same time. The key is to ask questions that help determine which ones are relevant.

Example Questions

Can you do something useful for your audience, like perform some calculations or sound an alarm at an appropriate time?
Then maybe your widget is meant to perform a task.
Do you have content that you want to push out at relevant times?
Consider a widget that provides information.
Do your users want to provide feedback or give you information?
Maybe you want to design a widget that gathers information.
Would your users find it valuable to be connected with other users? Do they have something to say to each other, or do they want to compare themselves against each other?
Consider a widget to connect them socially.

Audience
Some widgets have only one audience and others have multiple audiences. It’s your job to figure out who the audiences are.

Possible Audiences

The user who installed the widget
In most cases, the widget is going to be used by the person who installs it. For example, if I add a widget to my iGoogle page, it’s because I want to see it every time I go to my home page. The widget should be designed solely to meet my needs.
The friends of the user who installed the widget
Many bloggers add widgets to the sidebar of their blogs. For example, on this blog I might add a widget that searches the email archives at IxDA. As the blog writer, I already know about IxDA, and I already know how to go there and search the email archives. I would only add it to my blog as a service to my readers. They are the real audience.
Both the user and her friends
A lot of Facebook application fit in this category. They provide some value to the user, but they also provide value to the user’s friends who visit her profile page. For example, a Facebook application might be useful to me because it helps me keep track my favorite recipes. But it’s also useful to my friends because they can see the kinds of recipes I like, and recommend more they think I would also like.

Once you have identified your audience(s), then you can start designing an appropriate UI. If your audience includes both the user and that user’s friends, then you want to enable both audiences to do the things they want to do, without making the interface confusing for either audience.

Platform/Technology
Platform is the third and final attribute for a reason. It should flow naturally from the first two attributes.

For example, let’s say you chose to design the following kind of widget…
Purpose: Perform a function
Audience: Only the user who installs the widget

In that case, you probably want to choose a platform like iGoogle or the PC desktop.

However, if the chose to design a widget more like this…
Purpose: Connect people socially
Audience: The user and her friends

In that case, your widget probably belongs on a platform like Facebook.

Since there are so many platforms, and their pros and cons aren’t well known, I’ll provide a brief overview of the most popular options here.

Yahoo Widgets
This is a framework that users download and install on their PC. The framework is for both Mac and PC, which is good, but it does require a separate installation process. So I tend to think this platform is only for people who really want widgets — not for average users.
Google Gadgets
Google Gadgets are a lot like Yahoo Widgets, except they can work in more places. A Google Gadget can be placed on a user’s iGoogle page, it can be installed as a PC desktop widget using Google Desktop (which is just as distracting as installing Yahoo Widgets). And I understand a Google Gadget can even be installed on any regular web page.
Facebook
Facebook is probably the most popular social network for widgets (Facebook calls them “applications”). Since so many people are already using Facebook, it’s almost ideal for any widget that needs to be social. The downside is that Facebook has been overrun by applications, so the managers are taking steps to minimize the role the applications play. Also, Facebook applications are often written in a proprietary language, making them more difficult to port to other platforms.
OpenSocial
Just about every social network that isn’t Facebook uses a Google technology called OpenSocial to power its applications. That includes MySpace, LinkedIn, Ning, and dozens of others. Although I haven’t seen many OpenSocial applications yet, it’s a good bet that they’ll become more popular in the future.
Blog badges
Most blogs give their owners a place to add “badges”, usually along the left or right hand side of the page. These badges are typically just a snippet of HTML and an image, offering minimal interactivity.
PC Desktop
Some PC widgets are actually just specialized applications. A common example is WeatherBug for the PC. It gets installed like any other PC application; it just has a small window and it hides in the Start bar when not in use. Alternately, you could develop a cross-platform desktop widget by compiling a Flash application, or transforming your Flash program into an Adobe AIR application, or by writing your application in any other platform-agnostic language.
Mac OS X Dashboard
The Mac operating system comes with a tool called Dashboard that overlays a set of widgets whenever the user presses a special key. Dashboard widgets are generally very popular with Mac users, but it does require you to build a widget just for the Mac platform.
Vista Sidebar
In Windows Vista, a tool called Sidebar provides a “dock” for widgets on the side of the screen. It’s actually very similar to Yahoo! Widgets, except it’s built into the operating system. However, Vista Sidebar has the same drawback as Dashboard: it only works for a single operating system.
iPhone
The Apple iPhone now allows developers to write 3rd party applications for the phone. Because the screen is small, these applications look like widgets, so they’ve been wrapped in under that term too.

This is not a complete list of widget platforms, it’s just the most popular options. All the same, it’s more than enough options. The good news is that many of these platforms use the same basic technologies (HTML, CSS, Javascript, Flash, etc.), so it’s usually not that hard to rebuild a widget so it works on multiple platforms. Once you’ve picked a platform (or a few platforms) that make sense for your purpose and audience, you need to talk with your developers to figure out which ones you can reasonably support within your budget and schedule.

So what do you think of this framework? So far it has made sense for my projects, but I’d love to hear some other opinions. How are you thinking about the widgets you’re designing?

Leveraging User Data (??)

Jonathan — Tue, 22 Apr 2008 13:09:01 +0000

So, I’ve been thinking a lot about leveraging of user data recently.
Actually, to be more specific, I’ve been thinking about how to add value and one possible method is to leverage user data (data you already have).

When I say user data I’m thinking about three things:

User Generated Data
User Imported Data
Captured Data (i.e. user account data, analytics, tracking, etc.)

There are probably better categories out there but this entire idea needs to be fleshed out more anyway…

Anywho,

Let’s start trying to use our data to provide some added value. Finding new ways to use data you already have can breathe life into an older digital ecosystem or it might allow one to build a whole new system (stand alone or complementary).

Maybe you already have what you need to make a good site into a GREAT one. Maybe, you just have to look and start planning for it. I’m thinking that talking to your measurement/research team is the logical first step.

I’m thinking that the backend has to do all of the heavy lifting, if the user needs to do most of the work then the new feature, the new site, etc. will not be sustainable in the long run.

Maybe I shouldn’t say leveraging user data, maybe it’s leveraging user input
Or
Maybe it’s more about add value and the different ways to do that

Still, i’m just thinking “out loud” at the moment

One caveat:
Emergent Properties

Examples:

Take Last.FM for example, for the SXSW conference they created a system that took their user’s music preferences and allowed them to filter through the SXSW music lineup. Last.FM also rolled out an “event calendar” of sorts that looks for music in your area that meets your musical tastes (as well as it can). Those are great value adds for an already strong site.

Group Recipes – food/cooking/recipe community
Different browse options (e.g. beauty, intereresting, stumbler, local; eateries), Roger the recipe robot, friend “recommender” – all based on the community’s input

Ravelry – knit and crochet community
Popular patterns, project finder (based on type of yarn and other attributes), flickr integration, public project tracking (what are people working on), project and resource tracking (e.g. needles, hooks, and yarn), pattern browser – all based on user behaviour and input

Facebook
Facebook introduced the ability to import friends from a myriad of different web applications and address books – is it a good thing? That’s another post but it did leverage User Data (albeit the fact that the data came from another site/application) – user initiated import

Etsy
Search by colour – based on user tagging

There was a review site a few months ago that had a really interesting navigation system. You could browse by a taxonomy and then refine results based on a folksonomy. Seemed like a great idea. I need to find that site again!

Design and Architecture of Social Web Experiences

Jeff — Sat, 12 Apr 2008 03:00:52 +0000

During today’s Design and Architecture of Social Web Experiences workshop, I took 5 pages of notes and designed a very simple, yet very cool social website. So, yeah, I’d say it was a good session.

Here are some of the highlights from my perspective…

The Webb/Butterfield/Smith Model

This is an illustration that shows 7 aspects of social networks in a way that makes it easy to describe the functionality of a social web site.

It’s not like this diagram does anything, so to speak, it just gives you a way of describing social features, and it serves as a reminder of the social network attributes you should consider when designing social software. Wodtke created an expanded version that includes some attributes she considers missing from this honeycomb, which hopefully I’ll be able to share later, along with an expanded description of the attributes.

Open design patterns

One of the presenters (Wodtke, I think) made a point about how, when you’re designing a social network, you don’t need to “own” the content your users create — you just need to aggregate it in a way that’s useful. For example, if your users already have blogs, maybe you just want to search that content for certain tags and aggregate the posts in a way that’s useful.

The presenters often hit on a similar idea: when designing social networks, open is good. Users are tired of entering in all their personal information, building their network of friends, and then having all that data locked inside your application. We need to build networks that allow data portability (through RSS, APIs, microformats, etc.) if we want to provide a product that’s easy to use from beginning to end and integrates with users’ whole digital life.

Trust and monitor

The phrase “trust and monitor” describes a good approach to maintaining editorial control over a social network. “Trust” means you assume your users are not criminals who all want to break the rules or game the system. “Monitor” means you still do your due diligence to make sure offensive content doesn’t crop up.

This stands as a recommendation for our corporate clients who often want to keep an iron fist around anything social on their websites.

The problem of the Cold Start

Near the end of the session, we talked about the problem of the “cold start”, which is when you build a social network, but nobody’s there. And nobody’s going to come until there are people there. Catch-22.

We talked about 2 ways of overcoming that problem. First is having content or functionality that’s valuable even if nobody is there. But in cases where the site isn’t meant to have its own content, the only real solution is to start the group yourself. You join the social network and get your friends to come, and get them to bring their friends. Or, if not you, then a chosen community manager. The idea is you have to start at home.

Group size

There was an interesting conversation about the right size for a group online. We talked about Dunbar’s number, and how that doesn’t directly apply to web experiences because the social information you would normally need to keep in your head can instead be kept on the computer. But we also talked about how “scale kills conversation”, meaning as groups get larger, the conversation becomes less meaningful.

At work, we’ve been discussing this issue for an upcoming social network, but I’m not sure today’s session really helped me figure out an answer. Does anyone really think there’s a “right” size for online groups? Or does it depend on the situation?