<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Morville, Peter</title>	<link>http://tc.eserver.org/authors/Morville,_Peter</link>
	<description>A bibliography of works by Morville, Peter in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Morville, Peter</title>
		<link>http://tc.eserver.org/dir/Morville,_Peter</link>
	</image>
	<item>
		<title>Defining Information Architecture</title>
		<link>http://tc.eserver.org/35550.html</link>
		<guid>http://tc.eserver.org/35550.html</guid>
		<description>Bad buildings and bad web sites share similar architectural roots. First, many architects don’t inhabit the structures they design. They don’t fully understand the needs of their customers, and they’re not around to suffer the long-term consequences of poor decisions. Second, creating structures to stand the test of time is really difficult.</description>
	</item>
	<item>
		<title>Cos’è l’architettura dell’informazione</title>
		<link>http://tc.eserver.org/35551.html</link>
		<guid>http://tc.eserver.org/35551.html</guid>
		<description>Lo sviluppo di un’architettura dell’informazione prevede parecchie sfide, ma una biblioteca è un ambiente relativamente ben definito e sono disponibili molte esperienze e sapere collettivo da cui attingere. I siti web, d’altro canto, presentano un serie di nuove sfide.</description>
	</item>
	<item>
		<title>User Experience Design</title>
		<link>http://tc.eserver.org/29558.html</link>
		<guid>http://tc.eserver.org/29558.html</guid>
		<description>Is it more important for your web site to be desirable or accessible? How about usable or credible? The truth is, it depends on your unique balance of context, content and users, and the required tradeoffs are better made explicitly than unconsciously.</description>
	</item>
	<item>
		<title>Ambient Findability: Findability Hacks</title>
		<link>http://tc.eserver.org/26362.html</link>
		<guid>http://tc.eserver.org/26362.html</guid>
		<description>Findability is one of the most thorny problems in web design. This is due in part to the inherent ambiguity of semantics and structure. We label and categorize things in so many ways that retrieval is difficult at best. But that’s only the half of it. The most formidable challenges stem from its cross-functional, interdisciplinary nature. Findability defies classification. It flows across the borders between design, engineering, and marketing. Everybody is responsible, and so we run the risk that nobody is accountable.</description>
	</item>
	<item>
		<title>Bottoms Up: Designing Complex, Adaptive Systems</title>
		<link>http://tc.eserver.org/23073.html</link>
		<guid>http://tc.eserver.org/23073.html</guid>
		<description>Web design is under attack. Our enemy is a dangerous meme known as reductionism. This devious adversary is spreading the notion that we can fully understand Web sites as a combination of simpler components, and that we can break the process of design into lots of quick steps and clearly defined deliverables.</description>
	</item>
	<item>
		<title>Ambient Findability</title>
		<link>http://tc.eserver.org/23041.html</link>
		<guid>http://tc.eserver.org/23041.html</guid>
		<description>For an information architect with library roots, what&apos;s next is obvious: ambient findability. I want to be able to find anything, anywhere, anytime.</description>
	</item>
	<item>
		<title>Building a Synonymous Search Index (Thesaurus)</title>
		<link>http://tc.eserver.org/23055.html</link>
		<guid>http://tc.eserver.org/23055.html</guid>
		<description>The value of a thesaurus stems from the inherent problems of natural language indexing and searching. Different users define the same query using different terms. Document authors, indexers, and information architects describe the same concepts using different terms.</description>
	</item>
	<item>
		<title>Calculating the Cost of a Large-Scale Web Site</title>
		<link>http://tc.eserver.org/23056.html</link>
		<guid>http://tc.eserver.org/23056.html</guid>
		<description>A well-designed information architecture with intuitive organization, labeling, navigation, and indexing systems can significantly reduce the amount of time that users spend blundering through the hierarchies of Web sites and intranets. How much is this time-savings worth? The case is clearest for intranets where the users are your employees.</description>
	</item>
	<item>
		<title>The Definition of Information Architecture</title>
		<link>http://tc.eserver.org/23046.html</link>
		<guid>http://tc.eserver.org/23046.html</guid>
		<description>Is the widespread ignorance of information architecture our fault? Are we really such lousy communicators? What&apos;s up?</description>
	</item>
	<item>
		<title>Dynamic Dueling: Grappling with Java-Based Site Maps</title>
		<link>http://tc.eserver.org/23057.html</link>
		<guid>http://tc.eserver.org/23057.html</guid>
		<description>When I compare the usability of the highly graphical MAPA dynamic site map with that of a more traditional text-based table of contents, the traditional approach wins hands-down. You can scan the contents much faster and you don&apos;t need a fast connection or a Java-enabled browser.</description>
	</item>
	<item>
		<title>Enemies of Usability</title>
		<link>http://tc.eserver.org/23047.html</link>
		<guid>http://tc.eserver.org/23047.html</guid>
		<description>I know lots of usability advocates who speak the language of business quite fluently. Could we get better? Sure. But on the whole, we are the solution, not the problem. Let&apos;s not weaken our ranks with friendly fire. We have plenty of real enemies to keep us busy.</description>
	</item>
	<item>
		<title>In Defense of Search</title>
		<link>http://tc.eserver.org/23050.html</link>
		<guid>http://tc.eserver.org/23050.html</guid>
		<description>Jared Spool loves to slander search. He says &apos;searching stinks.&apos; He proclaims it&apos;s &apos;worse than nothing.&apos; He exhorts web designers to &apos;keep users from using search.&apos; And he backs up these defamatory accusations with $3,000,000 worth of user research data. Is Jared right? Do his research results tell the whole truth and nothing but the truth? Is browsing better than searching? No, No, and No!</description>
	</item>
	<item>
		<title>Information, Architecture, and Usability</title>
		<link>http://tc.eserver.org/23053.html</link>
		<guid>http://tc.eserver.org/23053.html</guid>
		<description>What is the relationship between information architecture design and usability engineering? This is a loaded question, and I wade into dangerous waters by addressing it, but the answer has significant implications for a variety of audiences.</description>
	</item>
	<item>
		<title>Innovation Architecture</title>
		<link>http://tc.eserver.org/23049.html</link>
		<guid>http://tc.eserver.org/23049.html</guid>
		<description>As the original end-to-end architecture of the Internet is increasingly compromised, and as copyright and patent law expand their reach, the commons of code, content and creativity that launched the World Wide Web is being quietly smothered.&#xD;&#xD;&#xD;While Lessig focuses on technology and the law, his dark prophecies are relevant to the practice of information architecture.</description>
	</item>
	<item>
		<title>International Information Architecture</title>
		<link>http://tc.eserver.org/23044.html</link>
		<guid>http://tc.eserver.org/23044.html</guid>
		<description>There are all sorts of idiosyncratic reasons why information architects should reach across borders.</description>
	</item>
	<item>
		<title>Pandora&apos;s Portal</title>
		<link>http://tc.eserver.org/23052.html</link>
		<guid>http://tc.eserver.org/23052.html</guid>
		<description>Is the portal a task-oriented platform for applications, e-services and cross-functional business process integration or a tool for enterprise-wide knowledge management? Is it a bottom-up enabler of communication and collaboration or a top-down channel for broadcasting official corporate propaganda? Inevitable consensus answer? It&apos;s all of these things and more, and the IT folks better be ready to support this exciting new paradigm!</description>
	</item>
	<item>
		<title>Social Network Analysis</title>
		<link>http://tc.eserver.org/23048.html</link>
		<guid>http://tc.eserver.org/23048.html</guid>
		<description>How do knowledge workers learn? How do they decide what to learn next? What motivates them to share?&#xD;&#xD;These questions are central to the challenges of knowledge management, and yet most corporate portals and online communities are designed in ignorance of their answers.</description>
	</item>
	<item>
		<title>The Speed of Information Architecture</title>
		<link>http://tc.eserver.org/23051.html</link>
		<guid>http://tc.eserver.org/23051.html</guid>
		<description>What bothers me most about web and intranet redesign projects is the widespread practice of throwing out the baby with the bathwater.</description>
	</item>
	<item>
		<title>Virtual Documents: The Challenges of Chunking</title>
		<link>http://tc.eserver.org/23054.html</link>
		<guid>http://tc.eserver.org/23054.html</guid>
		<description>Beware the virtual document! It may look harmless. It certainly looks helpful. It will lure you with a siren&apos;s song of reusable content components that enhance flexibility and improve efficiency. And then, if you&apos;re not careful, it will smash you into pieces upon the rocky shores of complexity.</description>
	</item>
	<item>
		<title>Defining Information Architecture</title>
		<link>http://tc.eserver.org/21736.html</link>
		<guid>http://tc.eserver.org/21736.html</guid>
		<description>What is information architecture? Is it a nascent field or a flash in the pan? What does an information architect do? Are you an information architect? Am I? Is that the right label for our discipline? Do labels and definitions matter?</description>
	</item>
	<item>
		<title>Educating the Information Architect</title>
		<link>http://tc.eserver.org/21733.html</link>
		<guid>http://tc.eserver.org/21733.html</guid>
		<description>The good news is that the job market for information architects is exploding. Searches on sites like Monster.com regularly turn up 200 to 300 postings for &quot;information architects.&quot; From consulting firms like Argus and Scient to e-businesses like LookSmart to Fortune 500&apos;s like Cisco, everyone is desperately seeking information architects.&#xD;&#xD;The bad news is that there&apos;s no established educational degree program geared specifically to meet the needs of aspiring information architects.</description>
	</item>
	<item>
		<title>Information Architecture and Business Strategy</title>
		<link>http://tc.eserver.org/21732.html</link>
		<guid>http://tc.eserver.org/21732.html</guid>
		<description>Information architects need a good understanding of business strategy and its relationship to information architecture.</description>
	</item>
	<item>
		<title>Information Architecture and Ulcers</title>
		<link>http://tc.eserver.org/21735.html</link>
		<guid>http://tc.eserver.org/21735.html</guid>
		<description>Being an information architect can be stressful. There are certain points in the design process that are more stress-inducing than others.</description>
	</item>
	<item>
		<title>Lessons Learned from the Dot.Com Crash: A Passenger&apos;s Story</title>
		<link>http://tc.eserver.org/21731.html</link>
		<guid>http://tc.eserver.org/21731.html</guid>
		<description>Describes the inner workings of the dot.coms during the high-speed transition from irrational exuberance to outright panic.</description>
	</item>
	<item>
		<title>Little Blue Folders</title>
		<link>http://tc.eserver.org/21734.html</link>
		<guid>http://tc.eserver.org/21734.html</guid>
		<description>The Web is big. A billion pages big, according to a recent study by Inktomi and the NEC Research Institute. It&apos;s the ultimate testing ground for information retrieval technologies.&#xD;&#xD;If your search engine can automatically bring order to this overwhelming global mess of stuff, just think what it can do for a single web site or intranet.</description>
	</item>
	<item>
		<title>Big Architect, Little Architect</title>
		<link>http://tc.eserver.org/21727.html</link>
		<guid>http://tc.eserver.org/21727.html</guid>
		<description>First came the primordial soup. Thousands of relatively simple single-celled web sites appeared on the scene, and each one was quickly claimed by a multi-functional organism called a &quot;webmaster.&quot;&#xD;&#xD;A symbiotic relationship quickly became apparent. Webmaster fed web site. Web site got bigger and more important. So did the role of the webmaster. Life was good.&#xD;&#xD;Then, bad things started to happen. The size and complexity and importance of the web sites began to spiral out of control. Mutations started cropping up.&#xD;&#xD;Strange new organisms with names like interaction designer, usability engineer, customer experience analyst, and information architect began competing with the webmaster and each other for responsibilities and rewards. Equilibrium had been punctuated and we entered the current era of rapid speciation and specialization.</description>
	</item>
	<item>
		<title>An Information Architect&apos;s Manifesto</title>
		<link>http://tc.eserver.org/21725.html</link>
		<guid>http://tc.eserver.org/21725.html</guid>
		<description>Information architects of the world, unite! The environment has changed. Now, so must we!</description>
	</item>
	<item>
		<title>Software for Information Architects</title>
		<link>http://tc.eserver.org/21726.html</link>
		<guid>http://tc.eserver.org/21726.html</guid>
		<description>Information professionals have a love-hate relationship with technology. We love IT because it has made our jobs necessary by enabling the creation and connection of tremendous volumes of content, applications and processes. We hate IT because it constantly threatens to replace the need for us.</description>
	</item>
	<item>
		<title>The Age of Findability</title>
		<link>http://tc.eserver.org/21283.html</link>
		<guid>http://tc.eserver.org/21283.html</guid>
		<description>It doesn&apos;t replace information architecture. And it&apos;s really not a school or brand of information architecture. Findability is about recognizing that we live in a multi-dimensional world, and deciding to explore new facets that cut across traditional boundaries.</description>
	</item>
	<item>
		<title>The Ethics of Information Architecture</title>
		<link>http://tc.eserver.org/18434.html</link>
		<guid>http://tc.eserver.org/18434.html</guid>
		<description>Are you aware that the practice of information architecture is riddled with powerful moral dilemmas? Do you realize that decisions about labeling and granularity can save or destroy lives? Have you been designing ethical information architectures?</description>
	</item>
	<item>
		<title>In Defense of Search</title>
		<link>http://tc.eserver.org/13662.html</link>
		<guid>http://tc.eserver.org/13662.html</guid>
		<description>Jared Spool loves to slander search. He says &apos;searching stinks.&apos; He proclaims it&apos;s &apos;worse than nothing.&apos; He exhorts web designers to &apos;keep users from using search.&apos; And he backs up these defamatory accusations with $3,000,000 worth of user research data. Is Jared right? Do his research results tell the whole truth and nothing but the truth? Is browsing better than searching? No, no, and no!</description>
	</item>
	<atom:link href="http://tc.eserver.org/authors/Morville,_Peter.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>