The biggest barrier to UX implementation

14 May 2010

My personal experience has been that ignorance is the largest barrier to UX implementation. While there are many exceptions, too often do developers, marketers, executive management, or others with a large level of control over UX strategy and tactical development feel that user experience is simply “common sense.” They believe that they are users, and therefore they have insight into the process. This is natural.

It’s the responsibility of UX professionals to educate them and evangelize the value of user experience. (Though it’s nice if you can get executive support, it’s frequently not there.) At my current company, I approached this from several angles:

I held one-on-one meetings with stakeholders and others, seeking to understand their needs and start a conversation about possible UX solutions.
I wrote and presented brown bags, open to all, on subjects like Why Taxonomy Matters: Taxonomy and the User Experience, in order to promote understanding of UX and its considerations.
I introduced concepts designed to make people think more from the user perspective. For example, like many sites we’re interested in user-generated content (UGC). I expanded this to user-generated experience, or UGX, a concept I’d already developed from previous social media work and user analysis. UGX consists of both user-generated content and user-generated activity (UGA). I began tracking, reporting on, and discussing UGA whenever I mentioned UGC. This simple taxonomic switch (making UGC a subset of UGX, and adding the category of UGA) changed the context dramatically. It led people away from thinking about how to increase bits of stand-alone content, and got them thinking about user activity, which automatically increased awareness of things like user flow and perspective. Eventually key stakeholders and others were talking about UGA as a matter of course, and we even discovered ways to convert some UGA into UGC.

This was successful enough that UX became a standard consideration in not just design, but product strategy. It is of course beyond your control what others do with your information—but you have to provide it!

People understand success. Show your co-workers and management how UX solves their problems. Provide numbers, using performance indicators that matter to your audience. Present before/after case studies. Remember to focus on solutions, not problems (never show a problem for which you don’t have a suggested solution). In short, provide the best possible user experience for your internal customers.

This is from my response to a LinkedIn UX Professionals question, Why they don’t like to spend or invest in the User Experience tasks?

Albert Camus:
The evil that is in the world almost always comes of ignorance.

Historicity and UX

11 December 2009

Most people, if they had to think about it, would probably define historicity as historical authenticity. Not surprisingly, Philip K. Dick had a different take on the concept. From his alternate history The Man in the High Castle:

She said, “What is historicity?”

“When a thing has history in it. Listen. One of those two Zippo lighters was in Franklin D. Roosevelt’s pocket when he was assassinated. And one wasn’t. One has historicity, a hell of a lot of it. Can you feel it?” He nudged her. “You can’t. You can’t tell which is which. There’s no ‘mystical plasmic presence,’ no ‘aura’ around it.”

“Gee,” the girl said, awed. “Is that really true? That he had one of those on him that day?”

“Sure. And I know which one it is. You see my point. It’s all a big racket; they’re playing it on themselves. I mean, a gun goes through a famous battle, like the Meuse-argonne, and it’s the same as if it hadn’t, unless you know. It’s in here.” He tapped his head. “In the mind, not the gun.”

Dick’s character felt disillusioned by the concept, as if the mental associations a person had with an object were meaningless if not measurable in some external manner. But what humans associate with things is exactly what matters.

Click for larger image.

What does this have to do with user experience?

Historicity can be thought of as shared cultural meta-data. It’s a type of mental model, and designers can leverage this virtual meta-data to enrich user experience. I’d like to take Dick’s concept a step further, and think in terms of the personal historicity everyone brings to any given object.

Understanding historicity helps us understand what gives anything relevance; not just an object, but a product, a piece of user-generated content, a site, an app. Examples of personal historicity, brought by a user to a site:

A pregnant woman surfing for baby products, also carrying within her associations with a favorite toy, memories of helping her parents with her younger siblings, the kind of stroller she rode in when she was very young.
A person reading a news article about a major disaster, a tsunami, remembering a friend who drowned, a moment they were at the beach and felt the tug of a rip tide, even images from an action movie.
A person playing Freecell online, remembering the feel of cards when they played the gin and poker with their family, the elasticity of a childish brain at play, recalling the self-validation of their highest score.

In a sense, the associations of personal historicity are the self-created virtual meta-data of your site’s users. Provide a context that unlocks and leverages the virtual taxonomy in their minds. You’re interacting with a person at some point in their personal narrative; help them tell that story. Whatever you are designing, it pays to consider the experience users bring with them to your product, not just the experience you are offering.

Stephen Ambrose: Nearly every artifact has a story connected to it.

Lolcat-inspired naming conventions

24 November 2009

We all know that consistent, meaningful names are helpful in planning database architecture, but I wanted to bring to your attention this stunning, simple example of good naming convention at work:

Note the two key elements, helpful in developing nearly any taxonomy:

Highly usable mixed case

The mixed case of “Cheetah” makes text more readable. (The bucket was clearly labeled by someone other than the all-caps writer of the “ALL BUCKETS…” command.) No doubt a more detailed name would be in CamelCase, e.g., FelineCheetahKitten. (Any other ex-Pascal programmers out there? You’ll recognize this as Pascal style.) Naturally, naming conventions can vary from CamelCase and still be highly useful—much depends on the needs of the team and application being used.

Please note: if you’re naming web pages or directories, you might want to avoid mixed or CamelCase, as most users type URLs in lower case, and browsers are case sensitive below the domain level.

Meaningful text

The bucket identifies what’s in it simply and clearly, making it easier for others working in this architecture to know what to expect. No one will look for walruses in this bucket!

The goal in choosing a naming convention for your tables, columns, classes, directories, etc., is to make it clear what’s happening. It may be necessary to:

Implement a controlled vocabulary, to avoid misunderstandings.
Establish reserved words, to avoid confusion. For example, Active Directory reserves terms such as Users, World, Terminal Server, and Null.
Disallow specific characters. At my previous employer, HBX Analytics used to become confused by the pipe ( | ) character, so we stopped using it to separate browser title sections at an old workplace.

Whatever you’re working on, it’s good practice to establish a basic naming convention at the outset, readily understandable by current and new team members.

Blaise Pascal:
Continuous eloquence wearies. [Or, I can haz lolspeak?]

Evolutional UX

11 November 2009

I subscribe to the school of evolutional design. In evolution, species change not to reach for some progressively-closer-to-perfection goal, but in response to each other and their ever-changing environment. My user experience must do likewise.

Rather than reach for pixel-perfect, which is relatively unattainable outside of print, (and is probably only “perfect” to myself and possibly my client), I reach for what’s best for my users, which is in the interests of my client. I expect that “best” to change as my users change, and as my client’s services/products change. This approach makes it much easier to design for UX.

Part of evolutional design is stepping away from the graceful degradation concept. The goal is not degraded experience, however graceful, but differently adapted experience. In other words, it’s not necessary that one version of a design be best. Two or three versions can be equally good, so long as the experience is valuable. Think of the differences simply resizing a window can have on well-planned liquid design, without hurting usability. Are the different sizes bad? Of course not.

This approach strongly supports behavioral design, in which design focuses on the behavior and environment of the user. You might be designing for mobile, or a laptop, or video, or an e-newsletter; you might be designing for people being enticed to cross a pay wall, or people who have already paid and are enjoying your service. You might be appealing to different demographics in different contexts. Evolutional UX thinks in terms of adaptation within the digital (and occasionally analog) ecology.

Evolutional UX also reminds the designer that she herself is part of an evolving class of worker, with many species appearing and adapting and mutating and occasionally dying out. We must adapt, or fall out of the game—and the best way to do that is to design for your ever-changing audience and their ever-changing tools.

And now, some words of wisdom from that foremost evolutional ecologist, Dr. Seuss. Just replace the “nitch” spelling with “niche” and you’ve got sound ecological theory, as every hermit crab knows.

And NUH is the letter I use to spell Nutches,
Who live in small caves, known as Nitches, for hutches.
These Nutches have troubles, the biggest of which is
The fact there are many more Nutches than Nitches.
Each Nutch in a Nitch knows that some other Nutch
Would like to move into his Nitch very much.
So each Nutch in a Nitch has to watch that small Nitch
Or Nutches who haven’t got Nitches will snitch.

Some of the above was shared as a comment to idsgn‘s post about User Experience: The Future of Web Design.
Seuss, Dr. (1955). On Beyond Zebra.

Stephen Jay Gould:
Natural selection is a theory of local adaptation to changing environments. It proposes no perfecting principles, no guarantee of general improvement.

Shakespeare on taxonomy

9 August 2009

Shakespeare, discussing the value of a certain level of granularity in taxonomy design. From Macbeth:

1st Murderer: We are men, my lord.

Macbeth: Aye, in the catalogue ye go for men; as hounds, and greyhounds, mongrels, spaniels, curs, shoughs, water-rugs, and demi-wolves are clept all by the name of dogs: the valued file distinguishes the swift, the slow, the subtle, the housekeeper, the hunter, every one according to the gift which bounteous nature hath in him clos’d; whereby he does receive particular addition, from the bill that writes them all alike: and so of men.

An occasional challenge in designing a taxonomy, whether for back-end architecture, user permissions, catalog searchability, or any complex schema, is deciding how much detail to track. Too little, and like Macbeth, you find yourself unable to distinguish the good from the bad, the useful from the unwanted. Too much, and the relevant is hidden by the irrelevant, discouraging users.

How to know what to do? Like everything else, start with the user.

user-driven granularity

One of the simplest means of determining granularity is to leave it up to the user. There are several approaches, any or all of which can be helpful.

Conduct an audit of search terms, internal and external. Navigation flow should also be compared to path analysis. Observing how users look for information provides valuable insight into their internal categorization. The user’s mental model probably operates as an ideal level of relevant granularity.
Grant users the freedom to develop their own folksonomy via tagging. Many content management systems allow this with minimal effort. For large-scale enterprise endeavors, platforms such as Endeca can meet a broad variety of producer-driven and user-driven needs. User-generated metadata (UGM) is typically highly relevant.
If possible, perform concept testing. As always, design to test for purpose (as opposed to stimulus-response testing), and give the users every opportunity to do instead of say. Good techniques include structured brainstorming and user-driven card sorts. Insight into the user’s categories is your goal.

standards-driven granularity

User-driven research is not much help when you’re developing a taxonomy from the ground up, with a built-in need for shared elements, and no opportunity for user research. So, turn to those who have already solved the problem for their own users.

Is there an industry standard? Sometimes it’s simple. Library databases, for example, have a specific minimum of elements all items must be cataloged against, as well as optional metadata. If your product has an established standard taxonomy, chances are your users will expect it and you should incorporate it. This is not a recommendation of slavish adherence to tradition—rather, tradition can be a springboard for you, and a clue into the level of granularity your product will require.
If there is no industry standard, look to information management for inspiration. For example, the Dublin Core Element Set provides a highly useful metadata minimum standard.

refining granularity

Once you’ve fleshed out a basic schema, testing and observation will help refine it to the appropriate level of granularity. Don’t fit it all into one menu. Too much detail, and users will be overwhelmed by the options and abandon your site.

Instead, parcel out information into appropriate locations:

A global navigation for key areas, common to the entire site.
Anchor links within a section or page.
A search interface. There are advantages to offering different approaches. A simple search box can reveal interests you didn’t know your users had, and allow you to prompt them with recommended results for expected keywords. An advanced system (such as that used in a library, or a periodical) can be a good way of introducing your user to leverage key metadata. If your audience consists of expert users (researchers, for example), this could be ideal approach. You will definitely want to conduct research to optimize this search approach. And a faceted search can allow them to easily filter their options. This, paired with a simple text box search, meets most needs.
Tagging.
This allows depth of granularity within the appropriate context, so that unlike Macbeth, your users can find exactly what they need, when they need it.

Stephen Jay Gould:
Classifications are theories about the basis of natural order, not dull catalogues compiled only to avoid chaos.

Designing for purpose

3 August 2009

This is the first of several presentations applying different psychological systems to user experience.

Designing for users is a tough job. To optimize our designs and strategy, UX professionals frequently turn to concept/site testing. The problem is that most design strategy and testing thinks in terms of input → output. We provide input, users perform a desired response (click-through, purchase, content creation). How to break out of this mold?

Perceptual control theory (PCT) assumes that all output is based on the ultimate goal of improved perceptual input. If you replace “input” in the above with “experience,” you’ll see the direction this discussion is going…

Designing For Purpose

View more presentations from Alex O’Neal.

Clay Shirky:
You know you've got a good piece of software when people use it for purposes for which the designers never intended or designed.

Not just wireframed that way

22 June 2009

There was a discussion on the LinkedIn User Experience group recently about what constitutes a good wireframe, and after commenting I thought it would be worth exploring in more detail.

Like so much else, the definition of wireframe (also spelled wire frame; both are correct) has evolved over the past few years. In the web world I’ve seen them frequently presented as conceptual page layouts, typically not interactive, with comments. But things were not always thus.

My first encounter with wire frames was in 1990, doing CAD diagrams to be used designing jewelry displays. These were skeletons of the product to be created, sometimes fairly complex, sometimes not—precursors to more detailed exploded diagrams used for actual manufacturing in our process. (Oddly, I ended up doing a little jewelry structure wireframing in 2003 for Barse, through their Shannon Diego line. But that’s not relevant to the subject at hand.)

Then, early in my web career in the late nineties, wireframes were text-and-table layouts of web sites with working links. They existed in HTML format and were used to test functionality and information flow as well as overall page layout. They did not have to be black and white—in fact, this approach made it exceptionally easy to test color palettes by tweaking CSS, etc. Notes were made within the layout. This allowed for detailed flow analysis, layout evaluation, etc., and provided programmers with a great reference as they developed the actual web app.

Products like Visio quickly appeared to make this process easier, allowing the compilation of Visio work within one document into a linked screen flow. A Usability Interface article observed in 2000 that

…[Y]ou are not creating a true HTML prototype. Instead you are creating something that mimics a prototype but does not contain all of the HTML controls you normally encounter on a page (e.g., drop-down boxes, data entry, etc.). So, there are limitations to what you can easily do in this Visio export. However, you can create a reasonable prototype much quicker than if you coded the entire screens in HTML.

I’m not sure I agree with that across the board—a lot depends on your coding expertise—but it can’t be denied that Visio empowered quite a few IAs and UI designers.

Today, despite the prototyping capabilities of applications such as Axure, there is much less live wireframe use. While the work is done digitally, the consultation process is essentially paper prototyping using a printed diagram. The wireframe is a flat file, created in everything from the ubiquitous Visio to PowerPoint, and often saved as a pdf for easy distribution and printing. This seriously undermines the potential usefulness of wireframes in the architecture and design process, but is the nature of corporate life for many IAs.

Additionally, the style conventions of wireframes vary from department to department within a company, which can make it difficult to share ideas and development.

Here are some tips in creating useful wireframes:

Use consistent design cues so a non-IA, non-design person can make intuitive sense of it.
If at all possible, put your notes on the same page as the wireframe itself.
Incorporate text where possible and relevant, instead of limiting your page description to numbers that lead to a list. Which of these approaches seems more usable to you?
–A box with a (3) in it, directing you to a list that reveals (3) to be “Page header, h1 format for SEO, one per page.” Said list may or may not be on the same page as the diagram.
OR
–A box with “Page header (3)” in it, and an on-page list for a paper prototype, or a link in a web prototype to the same list item.
Leverage your notes to capture details such as SEO needs (”single H1 tag,” or “menu keyword analysis needed”)

If you can get your company to do interactive wireframes and share them on your intranet, or present them via projector, it empowers both your wireframes and you. You’ll also provide a place for your design team to test fonts, text, etc. on the fly, and give yourself a sort of “pre-QA” for your navigation design.

Wireframes are not all cut from the same cloth, and your needs will vary according to your company culture and project needs. But for me, knowing the options helps me provide the best possible experience to my team members when working on a project.

Frank Lloyd Wright:
Without an architecture of our own we have no soul.

Fun is fundamental

3 June 2009

Fun is a seriously undervalued part of user experience (perhaps of any experience). In fact, a sense of play may be a required characteristic of good UX interaction. But too often, I hear comments like the following, seen on ReadWriteWeb:

When you think of virtual worlds, the first one that probably pops into your head is Second Life, but in reality, there are a number of different virtual worlds out there. There are worlds for socializing, worlds for gaming, even worlds for e-learning. But one thing that most virtual worlds have in common is that they are places for play, not practicality. (Yes, even the e-learning worlds are designed with elements of “fun” in mind).

I was surprised to see the concept of play set in tension with practicality, as if they were incompatible, and to read that “even the e-learning worlds” employed fun. Game elements have been used to promote online learning for well over a decade, and used in offline educational design for much longer.

I certainly don’t mean to imply that every web site can be made fun. But it can employ the techniques of play in order to be more fun. As Clark Aldrich observes, discussing learning environments (emphasis his),

You cannot make most content fun for most people in a formal learning program… At best what you can do is make it more fun for the greatest percentage of the target audience. Using a nice font and a good layout doesn’t make reading a dry text engaging, but it may make it more engaging…

The driving focus, the criteria against which we measure success, should be on making content richer, more engaging, more visual, with better feedback, and more relevant. And of course more fun for most students.

It was while developing an educational site for Nortel Networks that I first discovered the value of game elements in design. Deliberately incorporating mini games, an ongoing “quest” hidden in the process, rewards (including surprise Easter eggs), levels, triggers, and scores (with a printable certificate) made the tedious process of learning how to effectively make use of an intranet database much more fun. We also offered different learning techniques, so users could learn by text, video, or audio, as they preferred.

This can apply to non-learning environments as well. Think about it: online games have already done all the heavy lifting in figuring out the basics of user engagement. Some techniques I’ve found valuable in retail, informational, and social media include:

Levels. These provide a sense of achievement for exploration, UGC (user-generated content) or accomplishment. Levels can reduce any possible sense of frustration at the unending quest.
Unending quest. There should always be a next step for users. This doesn’t mean the user needs to be told that they’ll never be through with the site. Instead, it should always provide something engaging, that leads them on to a next step, and a next, and so forth.
Surprise rewards/triggers. These include Easter egg links, short-term access to previously inaccessible documents, etc.
Mini games, which can result in recognition or rewards for the user and can provide research data and UGC for the site.
Scores, which can encourage competitiveness and a sense of accomplishment.
Avatars and other forms of personalization.
User-driven help and feedback. Users (particularly engineers, in my experience) love to be experts. Leverage this to support your help forums if you need them.

Online, offline, crunching numbers at work, immersed in a game, sitting in a classroom, or building a barn, a sense of fun doesn’t just add surface emotional value, it frequently improves the quality of the work and adds pleasant associations, making us more likely to retrieve useful data for later application. Perhaps this is why so many artists and scientists have been known for a sense of play. And for most of us, it’s during childhood – the time we are learning the most at the fastest rate – that we are typically our most playful.

All websites are to some extent educational. Even a straightforward retail site wants you to learn what they offer, how to choose an item, and how to pay for it. Perhaps we can take a tip from our childhood and incorporate more fun into the user experience. Then we can learn how best to learn.

Stephen Wright:
If you tell a joke in the forest, but nobody laughs, was it a joke?

function (& searchability) follows form

13 June 2008

I’m a big believer in form following function: understand your content, understand your users’ needs, understand your technological options, and form will naturally follow. But where search is concerned, form strongly drives searchability as function.

Until very recently, search engines have had to make a Heisenbergian choice. Heisenberg, you’ll recall, observed that when studying quantum particles, you could study position or momentum of a given particle, but not both. Position and momentum in quantum mechanics are determined in terms of probability, but this added another level of uncertainty to the problem. You could pick one or the other to measure, but not both.

In the same way, search engines could analyze the web to a high degree of precision, knowing a few pages intimately, or they could analyze on a large scale, knowing many pages on a limited basis. But Google has reached the point where it says both can be attained: knowing many pages, and knowing them well.

As a partial step toward this end Google and other search engines have agreed on XML protocol for site maps, and Google has begun offering internal domain search directly from their results for larger sites. Understanding the structure of a site provides a better context for guiding searchers to their goal.

As search engines become more precise, understanding the semantics of individual pages is likewise becoming more relevant. For those unfamiliar with the field, semantics is the study of linguistic meaning, not only of a word or phrase in and of itself, but of the meaning found in the relationships between words, sentences, phrases. Online semantics is the study of the meaning imposed on a page’s content by its metadata and structure (and the practice thereof).

Most web developers who think of semantics (if they think of it at all) think of metadata, primarily the meta tags found in the head portion of a page. Early in the internet’s development, these tags were viewed as highly important for searchability, but abuse of keywords diminished their importance to search engine algorithms and therefore their importance to developers. The other elements of semantics, particularly in the body section of the page, were frequently misunderstood or not attended to at all. For example, h tags are frequently used out of order merely for their graphic impact; and CSS makes it easy to transform the functionality of many tags intended for completely different purposes. (The dynamic menus on alexfiles.com, for example, are based on CSS enhancement of definition tags, another semantic tag. Don’t worry, I’m following my own advice and changing them soon!)

So here are updated semantic recommendations, gleaned not only from a decade of SEO experience, but also from working sessions with several search consultants (including Google, in 2006 and 2007) over the past year and a half.

If you want to test your semantics, the W3C offers a semantics validator. (Try it! Copy the URL for this page and insert that into the validator form.)

Head section optimization

Browser titles

Browser titles are strong indicators of the content of a page. To optimize their impact, browser titles should

Be individual to each page as much as possible (this may be difficult with catalogs and the like).
Go in reverse breadcrumb order, from specific to broad. For example, a retail catalog page might have the following browser title:
Blouses and Tops | Women’s Clothing | Store name
The browser title should be different from the h1 tag in the body section.

Metadata

Make your meta tags (keywords, description, etc.) as specific as possible. Make them individual to the pages. Do not make them overly long; a brief sentence or two should suffice for your description.

A note: try to avoid the meta refresh tag. The meta refresh tag has been abused so by unscrupulous designers that search engines dismiss them. Instead of using a meta refresh for a permanently changed URL, use a hard 301 redirect. Use a 302 for temporary changes.

Title tags

Your title tag should be unique to your page, reflecting its subject matter.

Body section optimization

H1 tags

Every page should have a single H1 tag. This defines the subject of the page, and should be specific to the page.

The H1 tag is the page title, but should be different from the browser title. The browser title serves as a reverse breadcrumb, putting the page content within the larger context of the site; the H1 tag is the smallest, most specific portion of that segment, although the wording does not need to match exactly. It tells the reader if they’re in the right place.

H tags in general

If your page requires structure beyond the top level, then turn to H tags. H1 – H6 tags are the increments of your outline, their inherent size clues to the reader as they move from broad to detailed information.

Many developers and sites use H tags as graphic tools, not outlines. Sites can be found with no H1 tag; with skips between the steps in tags (going from H1 to H3, for example); or with multiple H1 tags. With CSS and dynamic sites, H1 tags in a variety of appearances can be pulled into a page.

Among semantic-aware developers, there are a few misconceptions I’ve encountered.

It is not necessary to go beneath H1 for searchability. Just make sure that if you use lower-H tags, they are used properly.
Just as the H1 tag should not be the site name (don’t make all your H1 tags the store name, for example) the H1 tag also should not enclose a graphic. It should be readable text.
It is not necessary to use all the H tags if you create an outline.
It is not necessary to use the same number of tags at each level. You can have two H2 tags and one can have two H3 tags beneath it, while another has three. As long as they’re in order and don’t skip, you’re good.

Other tags

There are other semantic body tags, such as definition tags: DL (definition list), DT (definition term), and DD (definition defined). These have their own inherent formatting per the W3C, sometimes used (as I did) for other purposes. Your best bet is to simply familiarize yourself with the W3C descriptions, and use tags for their intended purpose. In this way the form of your page can enhance its functionality by making it possible for search engines to better understand it, and bring in more users.

Peter Morville:
Any architect (physical or digital) needs to have one foot in the past and one in the future.

Excluding data limits thought

20 March 2008

I have never understood the desire to delete articles in Wikipedia solely on the basis of the highly subjective concept of “notability,” and I’ve fought against deletion of such articles. It’s easy to store the information, and it’s useful to someone or it wouldn’t be there. To these reasons I would add another: the more information you have, the more freedom you have to think flexibly about a subject.

Nicholson Baker supports the concept of a Deletopedia, a wikimorgue where all the “nonnotable” articles removed by the frustrated book-burners on Wikipedia would reside. Baker describes it:

…a bin of broken dreams where all rejects could still be read, as long as they weren’t libelous or otherwise illegal. Like other middens, it would have much to tell us over time.

Why, exactly, is this useful? Because we need taxonomic freedom.

A taxonomy is only as free as its data. The more categories you have—the more data—the more ways a given piece can move from one category to another and be connected—then the more flexibly and creatively you can arrange and understand the data. Not only does the freedom to connect and associate a given piece of data help, but each piece of data increases the number of patterns possible.

How we understand information is driven by the taxonomies—the patterns—we place it in. As Marvin Minsky said, You don’t understand anything until you learn it more than one way. The biologists have known this for some time. Initially biological species classification was based primarily on anatomy and phenotype. But there are many ways to think about organisms: according to evolutionary ancestry (cladistics), according to geography, according to the niche they occupy ecologically, to name a few. What taxonomy you choose to use determines how you’re able to perceive and understand a given organism or system.

The moment you begin to exclude and include along any lines, you begin to enforce a taxonomy of sorts. The taxonomies we use determine and limit the direction and options of our thought. We need to apply them to look at things from a given perspective, but we need to be aware of them so we can change them and see different perspectives. So, thinking in terms of deleting what is not notable is implicitly applying a self-limiting taxonomy. You will not be able to change your perspective to one that makes use of the deleted information, because you will not have the information.

This tendency by some to ignore or remove information that does not fit into their personal taxonomy of relevance is present in library cataloging, too. As a former online cataloger myself, I’m also in support of keeping analog card catalogs as well as digital. Having project-managed teams that converted card catalogs into databases, I’ve seen first-hand how subjective the choices of what pieces of information on the card get migrated onto the database can be. I think every piece of data should be online, but there are plenty of catalogers who skip over descriptive items they find trivial.

Humans are linguistic souls (even the mostly spatial types like myself), and having a new word or symbol attached to a concept immediately adds a tool to our arsenal of thought. This is why one of the first things repressive regimes do is burn the books and suppress the intellectuals. “All the Nazi or Fascist schoolbooks made use of an impoverished vocabulary, and an elementary syntax, in order to limit the instruments for complex and critical reasoning” (Umberto Eco, 22 June 1995, New York Review of Books). We do ourselves a disservice when we close off possible avenues of thought by disregarding data currently not important to us.

Besides, as Flaubert observed, “Anything becomes interesting if you look at it long enough.”

Maybe Wikipedia should make that its motto.

Henri Matisse:
Personally, I think neither of these methods must be preferred to the exclusion of the other. Both may be used in turn by the same individual.