I just added a Meebo Me widget to this blog. Meebo is a great web IM service that allows me to sign in to multiple messaging services and manage them with one buddy list. I can chat with folks through a web browser, eliminating the need to run another app (I always have a browser open) and avoiding the firewall issues that plague typical IM clients.
They also enable you to create an embeddable chat widget that will not only let you know I'm online, but also allow you to send me an anonymous IM whenever I'm around. This could be very cool or very annoying- I'll post a followup when I decide which it is.
In any case, this is a glimmer of a Web where Presence is a embedded in every online experience- your presence, my presence, and the presence of every visitor to every site, in one way or another. There are interesting vectors in this space that are only beginning to indicate convergence... in a later post I'll describe one of those possible convergent futures. For now, I've got to go chat with someone claiming to be my dog....
Tuesday, July 17, 2007
Sunday, July 8, 2007
The Times Gets Usable
The New York Times has an entry-level article on the profession of usability, making it seem like an emerging field demanded by a greater level of human-computer interaction (I think someone over at the Times is jealous of my series concept, Job Descriptions From The Future).
In reality, the discipline of usability has been around ever since there have been things to use. Henry Dreyfus, who I am absolutely certain never designed a web site, defined a whole century of communication with his eminently usable Model 500 Telephone. One of the seminal volumes on usability, Donald Norman's The Design of Everyday Things (originally published in 1988), contains an appendix where he expresses doubt that humans would ever be able to design something as complex as a hypertext information retrieval system (for those of you with less nerd quotient than me: you're looking at one right now).
Lateness to the party aside, the Times does manage to skim the high level points of a usability professional's lot in life, and they even touch upon a point that I feel is often lost in the shuffle of user experience design- the presumption of knowledge on the part of the user. The author writes:
"The creator of a Web site may assume too much knowledge on the part of users, leading to confusion."
This happens more often than not. Designers leave off labels, navigational pointers, summaries, and explanatory text that would help users orient themselves within an application or site. They forget that not everyone using their site has spent the last three months poring over comps and wireframes like they have, and they often skip the crucial step of naive user testing, even though it could be as simple as walking down the hall and borrowing someone from another department to poke around your beta site for 15 minutes.
To combat this, I have declared that one of our team's required ingredients in any design is to be 'Obviousness.' The designers should look at a page or application state as a singular slice in time and ask some simple questions:
1. Assuming I've completely forgotten the context of my visit to this site, is it obvious what I'm supposed to do here?
2. If the inherent design of the page doesn't help direct me, is there obvious labeling that can help reorient me?
3. If I panic or don't have time to read the labels, is it obvious how I can 'punch out' and reset the experience to a familiar state without screwing something up?
'Obviousness' is one of several experience values I am requiring all our work to express. Over the coming weeks, I plan to do a series of blog posts on the top experience values that contribute to the success of a user experience design (unless the Times beats me to it, of course).
In reality, the discipline of usability has been around ever since there have been things to use. Henry Dreyfus, who I am absolutely certain never designed a web site, defined a whole century of communication with his eminently usable Model 500 Telephone. One of the seminal volumes on usability, Donald Norman's The Design of Everyday Things (originally published in 1988), contains an appendix where he expresses doubt that humans would ever be able to design something as complex as a hypertext information retrieval system (for those of you with less nerd quotient than me: you're looking at one right now).
Lateness to the party aside, the Times does manage to skim the high level points of a usability professional's lot in life, and they even touch upon a point that I feel is often lost in the shuffle of user experience design- the presumption of knowledge on the part of the user. The author writes:
"The creator of a Web site may assume too much knowledge on the part of users, leading to confusion."
This happens more often than not. Designers leave off labels, navigational pointers, summaries, and explanatory text that would help users orient themselves within an application or site. They forget that not everyone using their site has spent the last three months poring over comps and wireframes like they have, and they often skip the crucial step of naive user testing, even though it could be as simple as walking down the hall and borrowing someone from another department to poke around your beta site for 15 minutes.
To combat this, I have declared that one of our team's required ingredients in any design is to be 'Obviousness.' The designers should look at a page or application state as a singular slice in time and ask some simple questions:
1. Assuming I've completely forgotten the context of my visit to this site, is it obvious what I'm supposed to do here?
2. If the inherent design of the page doesn't help direct me, is there obvious labeling that can help reorient me?
3. If I panic or don't have time to read the labels, is it obvious how I can 'punch out' and reset the experience to a familiar state without screwing something up?
'Obviousness' is one of several experience values I am requiring all our work to express. Over the coming weeks, I plan to do a series of blog posts on the top experience values that contribute to the success of a user experience design (unless the Times beats me to it, of course).
Design, Intelligent and Otherwise
I find the ongoing debate between the proponents of evolution and the believers in intelligent design to be fairly ludicrous. I understand why the content of school curricula is important to both sides- education shapes outlooks for later in life and we all want our children raised with our values- but as an interactive designer, I'm trying hard to figure out why the two ideals are incompatible.
When my team sets out to create an interactive experience, we never come to the conclusion right out of the box. There's discussion, and questions, and discovery, and exploration. We'll create dozens of wireframes, selecting the best to go on to the next phase, and discarding the rest. Sometimes we'll travel down one path, only to discover it's a dead end- our interactive design has grown too complex for the needs of the project, or it has been rendered obsolete by a changing environment. We've had to scrap entire lines of thought and their attendant designs more than once, and start over with a clean sheet of paper and a fresh outlook.
Image: An extinct interface, from a company that has itself evolved into another form.
With all this fine tuning, and iteration, and exploration, our design process looks a lot like... an evolution of ideas. The much-loved rollover preview feature in our application turns out to be a trilobite in user testing and is finally excised; or the three extra configuration screens we reluctantly added to our interface turn out to be so vital they expand into their own family of applications.
For the record- I am a firm believer that our species and all others are the result of countless generations of evolutionary change over the unimaginably long gulf of time. I also understand the absurdity of comparing my team of all-too-human interactive designers to the concept of an infallible Designer creating the entire universe and all life therein... but I've also never met a designer who didn't iterate on their work, evolve their output, and believe that they could improve their creations with just a little more time.
When my team sets out to create an interactive experience, we never come to the conclusion right out of the box. There's discussion, and questions, and discovery, and exploration. We'll create dozens of wireframes, selecting the best to go on to the next phase, and discarding the rest. Sometimes we'll travel down one path, only to discover it's a dead end- our interactive design has grown too complex for the needs of the project, or it has been rendered obsolete by a changing environment. We've had to scrap entire lines of thought and their attendant designs more than once, and start over with a clean sheet of paper and a fresh outlook.
Image: An extinct interface, from a company that has itself evolved into another form.
With all this fine tuning, and iteration, and exploration, our design process looks a lot like... an evolution of ideas. The much-loved rollover preview feature in our application turns out to be a trilobite in user testing and is finally excised; or the three extra configuration screens we reluctantly added to our interface turn out to be so vital they expand into their own family of applications.
For the record- I am a firm believer that our species and all others are the result of countless generations of evolutionary change over the unimaginably long gulf of time. I also understand the absurdity of comparing my team of all-too-human interactive designers to the concept of an infallible Designer creating the entire universe and all life therein... but I've also never met a designer who didn't iterate on their work, evolve their output, and believe that they could improve their creations with just a little more time.
Wednesday, July 4, 2007
Job Descriptions from the Future: Director of Metadata
First in a series of jobs that don't exist today but will come into being as the interactive industry matures.
Metadata, for those of you not hip-deep in content management system (CMS) implementations, is most simply defined as 'data about data.' For example: you may have a movie file on your hard drive; its filename, "funny dog.mov" is a bit of metadata that gives you some information about what you might find in that movie. Pop open the 'get info' or 'properties' box and you'll find a field for description- a place where you can enter a longer bit of text outlining the movie contents.
Upload the movie to YouTube and someone might tag it with the word 'pets' or another descriptive term- these tags are now part of the metadata (within the environment of YouTube; they obviously won't extend back to the file on your hard drive).
Metadata is created and added to content (like video, photos, articles, etc.) in order to help organize it. It makes it possible for a system (such as a CMS) to search for it, to allow users to browse for it by some attribute, and for the system as a whole to generate reports about usage.
Metadata comes in pairs- the name of the attribute and the data itself. In my example, the 'file name' attribute is described by the data 'funny dog.mov.' Since these attributes are blank until they are filled in, they are referred to as 'fields.'
I outlined three types of metadata our video file might have- filename, description, and tag. In a typical implementation of a CMS, a video file might have thirty, sixty, one hundred or more fields of metadata, depending what the need is to categorize this content to a particular level of specificity and precision. When grouped for the use of a system, metadata is referred to as an 'ontology' or a 'schema.'
Some metadata is implicit- for instance, if you transcode the movie into a Flash streaming file, the format is 'FLV.' That's just what it is; your opinion on the file format is immaterial. Other metadata needs to be assigned- for instance, is the clip from a comedy show? You might assign 'comedy' to a field labeled 'genre.' At this point in time, a human being somewhere along the line needs to determine that the system needs to know the genre of the movie, and then make the proper assignment.
That's where our Director of Metadata comes in. This is a job position that is currently desperately needed by rarely created. Instead, this position is chopped up into multiple pieces and distributed among multiple people in an organization, each of whom has a definite interest in the metadata the business needs to operate, but not the clear ownership this gig requires.
Nowadays, you see the following disciplines saddled with one piece or another of this job:
Editorial team: These are the the most visible users of metadata, since they actually create and compose much of the information that will ultimately become metadata. However, their focus is informational and not necessarily operational- without support from other disciplines, they are likely to create extremely intricate descriptive fields and skimp on the system level fields that are needed for effective categorization and workflow control.
Operations team: Tasked with making sure that the metadata allows for day to day operations of the company, the Operations team tends to focus on fields that describe the 'state' of the item- which in some cases is not necessarily the job of the metadata, but rather should be managed by a system external to the item itself. Fleeting or temporary information like the type of ad campaign running against a piece of content shouldn't be tagged as part of the content itself since it will change frequently, but the Ops folks need somewhere to put it, and the metadata schema looks like as good a place as any.
Product team: As part of the product specifications process, the Product team will of course attempt to gather every other team's requirements for the metadata, but will not typically act as an effective filter for it; if Joe from accounting says we need to track the price in dollars, pounds, and lira, who are they to argue? What ends up happening is the Product team gathers an astoundingly long list of fields, many of them redundant or flat out unnecessary, and then watches as it's progressively whittled down by iterative review- which is fine in the end, but time consuming and ineffiecient.
Technology team: the group that actually needs to make the system happen. Their focus will typically flow toward system performance and stability, so they will be rooting for the least amount of metadata possible to make the system function, sometimes at the expense of flexibility or automation somewhere up the workflow chain. This attitude causes the other groups to try and stuff as much information in at the outset, so whatever ultimately ends up making it into the system is robust enough for their needs.
When there's no clear owner of a project or capability it typically limps along halfheartedly until deadlines or desperation shock it into frantic activity. In either case, decisions are not being made in a clear and methodical manner, and the ultimate result is not as well fashioned as it could be. Since metadata is at the core of so many operations, interactive businesses ignore this deficiency at their own peril.
There are metadata specialists today- taxonomy consultants, ontology experts- but they are typically brought in for a segment of the project, and not given the organizational heft necessary to solve the interdepartmental issues that make these projects so contentious and inefficient. What's needed is a strong internal owner for this crucial business segment- someone who can determine, define, and defend the decisions around the metadata schema that will serve as the engine for the company's information flow.
Let's start with the job description:
The Director of Metadata is tasked with managing the metadata schema for the Company's video products. DoM will work with the Business Development, Editorial Programming, Product, Operations, and Development teams to:
- Fashion metadata requirements for content partnerships
- Determine metadata needs for editorial programming interfaces
- Develop a schema that supports product capabilities for discovery and reporting
- build out the CMS and data entry methods to support the schema
- plan for future expansions and revisions of the schema as the business evolves
So now the tricky question: Where does the Director of Metadata work? In the Technology team, since that's where the development will ultimately happen? In the Product team, since their job is all about definition? In Operations or Editorial, since they're the ones that are going to have to live with it?
If there's a Chief Information Officer in an organization, I would roll the DoM up that line. Otherwise, I would drop them in the Product organization (which is cross-functional by definition) but give them a special dispensation and the independence to attach themselves to other teams in order to gain a properly broad and balanced outlook on metadata needs. Metadata is the language each internal group, and ultimately the consumer, uses to communicate with the assets of the business; it's too important a task to leave to someone who speaks only one organizational language.
Metadata, for those of you not hip-deep in content management system (CMS) implementations, is most simply defined as 'data about data.' For example: you may have a movie file on your hard drive; its filename, "funny dog.mov" is a bit of metadata that gives you some information about what you might find in that movie. Pop open the 'get info' or 'properties' box and you'll find a field for description- a place where you can enter a longer bit of text outlining the movie contents.
Upload the movie to YouTube and someone might tag it with the word 'pets' or another descriptive term- these tags are now part of the metadata (within the environment of YouTube; they obviously won't extend back to the file on your hard drive).
Metadata is created and added to content (like video, photos, articles, etc.) in order to help organize it. It makes it possible for a system (such as a CMS) to search for it, to allow users to browse for it by some attribute, and for the system as a whole to generate reports about usage.
Metadata comes in pairs- the name of the attribute and the data itself. In my example, the 'file name' attribute is described by the data 'funny dog.mov.' Since these attributes are blank until they are filled in, they are referred to as 'fields.'
I outlined three types of metadata our video file might have- filename, description, and tag. In a typical implementation of a CMS, a video file might have thirty, sixty, one hundred or more fields of metadata, depending what the need is to categorize this content to a particular level of specificity and precision. When grouped for the use of a system, metadata is referred to as an 'ontology' or a 'schema.'
Some metadata is implicit- for instance, if you transcode the movie into a Flash streaming file, the format is 'FLV.' That's just what it is; your opinion on the file format is immaterial. Other metadata needs to be assigned- for instance, is the clip from a comedy show? You might assign 'comedy' to a field labeled 'genre.' At this point in time, a human being somewhere along the line needs to determine that the system needs to know the genre of the movie, and then make the proper assignment.
That's where our Director of Metadata comes in. This is a job position that is currently desperately needed by rarely created. Instead, this position is chopped up into multiple pieces and distributed among multiple people in an organization, each of whom has a definite interest in the metadata the business needs to operate, but not the clear ownership this gig requires.
Nowadays, you see the following disciplines saddled with one piece or another of this job:
Editorial team: These are the the most visible users of metadata, since they actually create and compose much of the information that will ultimately become metadata. However, their focus is informational and not necessarily operational- without support from other disciplines, they are likely to create extremely intricate descriptive fields and skimp on the system level fields that are needed for effective categorization and workflow control.
Operations team: Tasked with making sure that the metadata allows for day to day operations of the company, the Operations team tends to focus on fields that describe the 'state' of the item- which in some cases is not necessarily the job of the metadata, but rather should be managed by a system external to the item itself. Fleeting or temporary information like the type of ad campaign running against a piece of content shouldn't be tagged as part of the content itself since it will change frequently, but the Ops folks need somewhere to put it, and the metadata schema looks like as good a place as any.
Product team: As part of the product specifications process, the Product team will of course attempt to gather every other team's requirements for the metadata, but will not typically act as an effective filter for it; if Joe from accounting says we need to track the price in dollars, pounds, and lira, who are they to argue? What ends up happening is the Product team gathers an astoundingly long list of fields, many of them redundant or flat out unnecessary, and then watches as it's progressively whittled down by iterative review- which is fine in the end, but time consuming and ineffiecient.
Technology team: the group that actually needs to make the system happen. Their focus will typically flow toward system performance and stability, so they will be rooting for the least amount of metadata possible to make the system function, sometimes at the expense of flexibility or automation somewhere up the workflow chain. This attitude causes the other groups to try and stuff as much information in at the outset, so whatever ultimately ends up making it into the system is robust enough for their needs.
When there's no clear owner of a project or capability it typically limps along halfheartedly until deadlines or desperation shock it into frantic activity. In either case, decisions are not being made in a clear and methodical manner, and the ultimate result is not as well fashioned as it could be. Since metadata is at the core of so many operations, interactive businesses ignore this deficiency at their own peril.
There are metadata specialists today- taxonomy consultants, ontology experts- but they are typically brought in for a segment of the project, and not given the organizational heft necessary to solve the interdepartmental issues that make these projects so contentious and inefficient. What's needed is a strong internal owner for this crucial business segment- someone who can determine, define, and defend the decisions around the metadata schema that will serve as the engine for the company's information flow.
Let's start with the job description:
The Director of Metadata is tasked with managing the metadata schema for the Company's video products. DoM will work with the Business Development, Editorial Programming, Product, Operations, and Development teams to:
- Fashion metadata requirements for content partnerships
- Determine metadata needs for editorial programming interfaces
- Develop a schema that supports product capabilities for discovery and reporting
- build out the CMS and data entry methods to support the schema
- plan for future expansions and revisions of the schema as the business evolves
So now the tricky question: Where does the Director of Metadata work? In the Technology team, since that's where the development will ultimately happen? In the Product team, since their job is all about definition? In Operations or Editorial, since they're the ones that are going to have to live with it?
If there's a Chief Information Officer in an organization, I would roll the DoM up that line. Otherwise, I would drop them in the Product organization (which is cross-functional by definition) but give them a special dispensation and the independence to attach themselves to other teams in order to gain a properly broad and balanced outlook on metadata needs. Metadata is the language each internal group, and ultimately the consumer, uses to communicate with the assets of the business; it's too important a task to leave to someone who speaks only one organizational language.
Subscribe to:
Posts (Atom)