This is the presentation I gave at DrupalCon Boston on March 3, 2008. This was a talk that introduces the UCD lifecycle and proposes to developers methods for doing UX activities. We compare the more rigorous activities and artifacts of the process with the simpler things you can do right now that are painless and produce the majority of the improvements you are likely to get doing UX the hard way.
The videos on slides 24 and 25 could not be embedded in the slide player, so I've embedded them separately below. Thanks to all who attended and came up with their comments and questions.
Wireframing with OmniGraffle
Prototyping with OmniGraffle
This is a presentation given at Rutgers, School of Communication, Information and Library Studies on December 12, 2005.
The slides for this talk contain mostly diagrams and are rather short on bullet points and text. The slides were meant to help illustrate points during the talk, which was mostly conversational and encouraged discussion throughout. There are no speaking notes included with these slides.
This was a presentation on enterprise weblogging given at the American Society for Information Science & Technology, New Jersey Chapter, May 20, 2005.
The presentation combined slides from all of my past talks on weblogging for knowledge management, including the Los Alamos National Laboratory presentation which is unpublished. This is a distilled version of those talks and provides a summary of my ideas about reacting to client needs regarding weblogging and developing a strategy for dealing with increasing weblog output in the enterprise.
Publications and presentations on web design and development, enterprise and personal knowledge management, and library and information work.
- New and Up and Coming Rapid Wireframing and Prototyping Tools
IxDA New York and NYC-CHI (February 21, 2012)
- Wireframes for the Wicked
South by Southwest Interactive 2009 panel discussion about wireframes, with Nick Finck and Donna Maurer (March 16, 2009)
- "No Tears" Method for User Centered Design
Presentation given at DrupalCon Boston (March 4, 2008)
- Blogs and the Blogosphere: Definitions and reasons to care
Presentation given at Rutgers, School of Communication, Information and Library Science (December 13, 2005)
- Enterprise Weblogging: Using weblogs for communication & information management
Presentation on enterprise weblogging given at the American Society for Information Science & Technology, New Jersey Chapter (May 20, 2005)
- Blogging in the Labs: Using weblogs for information management.
Presentation on project weblogs given at the Los Alamos National Laboratory, Los Alamos, New Mexico. (April 28, 2005)
- Utilizing Weblogs for Project Efficiency
Presentation on project weblogs for the IQPC Weblog and Wiki Summit 2005.
(January 11, 2005)
- Supporting enterprise knowledge management with weblogs: A weblog services roadmap
This is a presentation I delivered at the Computers in Libraries 2004 conference in Washington D.C.
(March 15, 2004)
- Blogging in Corporate America
This is a presentation I gave to the Usability Professionals Association on 16 September 2003.
(September 17, 2003)
- Using a Wiki for documentation and collaborative authoring
Case study published in LLRX.com describing how a library organization is learning to use Wikis for project documentation.
(November 15, 2004)
- K-Logging: Supporting KM With Weblogs
Article in Library Journal explaining how K-loggers can advance knowledge management with the support of librarians.
(April 20, 2003)
- Weblogging and News Feed Aggregation for Knowledge Management
This is a presentation I gave to colleagues in the Lucent Integrated Information Solutions group. The purpose of the presentation was to define what weblogging is and discuss why knowledge logs (klogs) are starting to appear inside corporate enterprises. The presentation was meant to introduce some of the concepts and applications.
(October 1, 2002)
- Automating Diagrams with Visio
Turnaround time can be relatively quick if you push your tools to perform for you. Site maps and user flow diagrams are good candidates for automation. Originally published: Angeles, M. (2002, April). Automating diagrams with Visio. Boxes and Arrows.
(April 1, 2002)
- XSL (Extensible Stylesheet Language): Summary of Preliminary Research for Site Developers
This document defines and summarizes XSL at a high-level and takes a look at a few examples of XSL in action. The intent is to introduce XSL as a practical tool for transforming XML data and to discuss possible implications for site development.
(September 26, 2000)
- Case Study: A Museum Library Website
Electronic information resources have become attractive additions to the information services offered in special libraries. Many of these services are increasingly being offered via the Internet. The creation of websites as tools for making sense of the glut of information that is available on the Internet is becoming a sensible activity, not for controlling this information, but simply for being successful in facilitating access to it. This paper is a case study in using the world wide web to create a sense making tool within the context of an art museum library.
(December 19, 1997)
- Information Organization and Information Use of Visual Resources
Paper on human information seeking behavior in visual resources collections. The paper reviews the image use and user studies literature to determine whether or not image retrieval systems satisfy human image seeking behaviors. Originally published: Angeles, M. (1998, Fall). Information Organization and Information Use of Visual Resources Collections. VRA Bulletin, 25 (3), 51-58.
(December 15, 1997)
- Information Organization and Information Use of Visual Resources, Annotated Bibliography
Notes on print and online sources which relate to the study of users of image collections (art and non-art image collections).
(December 15, 1997)
- Analysis and Description of an International Visual Resources Index
Database design proposal. An effort to explore methods for representing art historical pictorial images from a Library and Information Science perspective. The paper was produced as an exercise in structuring an index to represent knowledge descriptions, the messages of documents, corresponding with a knowledge representation course taken in the Master of Library Studies program at Rutgers University -- School of Communication, Information, and Library Studies. Winner of the 1997 VRA Nancy DeLaurier Writing Award, in the student paper category. Originally published: Angeles, M. (1997, Fall). Analysis and Description of an International Visual Resources Index: A proposal for building an image indexing database. VRA Bulletin, 24 (3), 37-59.
(May 29, 1997)
- Creating Descriptive Records of Pictorial Images in the Visual Resources Library
Short paper written as an exercise for a cataloging and classification course. Paper is in the form of a memorandum to a visual resources library director. The premise of the paper is to give compelling evidence in support of a cataloging and classification system.
(December 5, 1996)
- In Pursuit of a Virtual Art Library
The Personal Statement I sent to Graduate School Programs in Library Studies in the winter of 1995/1996.
(January 7, 1996)
This is a presentation that was to be delivered at the IQPC Weblog and Wiki Summit on February 1, 2005. The Summit was cancelled, but I have published the presentation.
Weblog tools provide a low-cost, high value alternative to larger content management and systems in the enterprise. Grassroots publishing tools such as weblogs and wikis are finding use in projects ranging from communication, information management, collaboration and social networking in communities of practice, across medium to large sized business units and even at the enterprise level. This session provides a snapshot of selected projects within a large corporation that use weblog applications for different goals and purposes. Weblogs are suited to specific needs fulfillment, yet they also create other issues of manageability within their informations ecologies. We will discuss both the solutions they provide and the problems they create and will discuss a generalized roadmap for dealing with the growth of weblog output.
From this presentation, you should be able to:
1) Observe and evaluate corporate experiences in grassroots publishing and knowledge creation using weblogs
2) Identify issues that may arise with the organic growth of grassroots-created information
3) Establish best practices for your users, your goals and your information ecology
Note: These slides were updated in the Enterprise Weblogging: Using weblogs for communication & information management presentation.
Originally published: Angeles, M. (November 28, 2004). Using a Wiki for Documentation and Collaborative Authoring. LLRX.com.
Documentation may help to ensure efficiency, continuity and consistency in library operations. Library technical staff might consider the use of collaborative publishing software for documenting their internal processes and procedures. Wiki software for collaborative web publishing has emerged as one of the viable and inexpensive options to consider for maintaining group documentation. There are many inexpensive or free Wiki packages at our disposal and while they may not necessarily bend to meet our every requirement, with a little work can serve many of our needs.
A good fit
I had my first experience using a Wiki for project documentation when I participated in the formation of a professional association. The group was geographically dispersed, and after our first face-to-face meetings, it became clear that we needed a platform to supplement our email meetings and conference calls. We quickly set up a Wiki, and it became everything from the white board to capture our post-meeting ideas to the documentation repository for our initiatives. Wikis proved to provide a lot of publishing functionality to this organization with little financial investment. Since we had limited financial funds as a start up, this seemed the perfect fit for our needs.
Wikis can be both simple and complex. On the surface, the idea of the Wiki is simple and elegant, and conceptually this simplicity makes Wikis a good candidate for modest documentation needs or informal, shared notes capturing. Because they're hypertext publishing environments, however, they can also become quite sophisticated and complex. This duality is precisely what makes them attractive and compelling tools for documentation.
But when it comes down to it, they're only effective tools if you invest time and effort in making them work for your particular group of users. I've learned from the projects I've participated in that the greatest success factors for integrating technology into a business include building an understanding of users and removing the barriers to the use of the technology. The technology itself is really of secondary concern. The solutions that are most successful are often the simplest in execution. Understanding how people work and closely matching the system design is one step towards this type of simplicity.
In the end, whether we choose a Wiki or some other technology, we want our interactions with the finished product and the output it produces to match our understanding of user goals and needs. Keeping this in mind, we are going to take a look at how my organization is learning to utilize our StaffWiki.
My organization began testing a Wiki over a year ago as the platform for some of our internal documentation and collaboration needs. In the short time that we've been experimenting with our StaffWiki, the Wiki quickly replaced our previous documentation tool and is presently utilized on a daily basis, whereas the previous web site was characterized by a sense of stasis and link rot. But getting the organization to jump in wasn't easy at first. There were some obstacles to overcome and keeping the Wiki useful requires investing time in managing it.
In most cases, a Wiki is set up so that anyone with access can edit or create new pages. To edit pages, you click a link on the page that reads "Click here to edit this page". To create new pages, you usually create a WikiWord (also called a CamelCase word) on an existing page by removing spaces between 2 or more words, or you may use a special syntax such as enclosing links in [[double brackets]]. After you save the edited page, you click the question mark next to the WikiWord you typed and the Wiki forwards the browser to a web form for typing the new page contents. This description summarizes how Wikis work, but the reality for most people is that while simple on the surface, getting started still has a learning curve.
It seems like people fall into two camps when they meet Wikis for the first time. Either they fall in love with the use of hypertext on Wikis or they run away screaming. That is an exaggeration of course. Truth is, like many people I've encountered, I had a hard time at first understanding how to find things or figure out how to contribute to a Wiki. Some of the difficulty had to do with understanding the scope of the Wiki and figuring out how to explore and navigate. Wikis are often loosely organized. This means that hierarchy doesn't necessarily organize things and the path to a nugget or node within a Wiki may not be apparent on the home page. For information workers used to order and clearly outlined organization, that makes Wikis a findability nightmare. But once the organizationally fussy and Wiki-timid newbies like myself started to see how easy it was to add our opinions to these pages, we saw the light. Soon after, we realized that we could contribute new pages to the community and we got hooked on the idea of the publicly editable web page.
Getting people comfortable with "clicking to edit" pages is usually the first hump to get over. In our experience, that has not been the biggest obstacle to getting our Wiki used. Getting people to publish new pages, however, has required a bit more help and instruction.
To start our StaffWiki, I began by creating an outline of the categories of information we had on our old manually maintained Staff site. Our main categories are: Communications, Organization Information, Resources and Documentation, External Resources. Within these major categories we list pages that we create on the Wiki including project pages that list our meeting notes, documentation and deliverables. Creating this outline for the Wiki made it much easier for people to see where to start.
After our initial outline was in place on the home page, I then ported our static pages from the old site to the Wiki. Giving the staff something to react to rather than providing them with a blank slate for them to fill was necessary to encourage them to start using it. The idea was to present it as something familiar at first - web pages that they can browse through and read - and then demonstrate its usefulness for collaborative publishing later. I thought that proving the concept by using it myself would be more effective than evangelizing it. I started by posting commonly referenced information including the following:
- Organizational information -- our mission statement, marketing materials, links to group calendars
- Communications information - past formal communications to staff, links to email list archives
- Common files -- licensed software we use, forms and template
- Logistical information -- network printer IP addresses
- Group documentation -- tutorials, process documentation
I held informal training sessions within my department to get people comfortable with the idea of creating and editing pages on their own. Slowly, the process of emailing me to update the old web site began to whither away as I answered requests by reminding people of the "Click here to edit" functionality and giving step-by-step instructions if they chose to update the page themselves. Usually I would say, "Thanks, I'll update the page. Remember, that if you need to make further changes later, you can also update it whenever you need to by just clicking the 'Edit this page' link on the bottom of the screen."
With some time, my department slowly began to edit and add new pages on their own, starting with updating the essential worklife-related information we use occasionally and moving on to creating new pages to document project-related work. Eventually people outside my department started participating, but the number of active authors remains small, with perhaps 1/4 of the staff regularly updating wiki pages. Some people prefer to channel changes through a few selected gatekeepers.
Keeping pages organized might be the next major obstacle to familiarizing people with your Wiki. The organic growth of a Wiki can make findability difficult for people accustomed to hierarchical browsing and not using Search. Creating categories for the pages and keeping them organized in a hierarchical list on the home page may help to make them more easily findable and may therefore greatly impact Wiki use.
One of the roles of your Wiki administrator may be to have someone watch the "Recently updated pages" to find the new pages that appear and link to them on a category page or the home page. People will be able to create new pages anywhere on the site. They can also refer to other pages just by typing the name of a page using WikiWord format. For instance, I have a Wiki page for our library portal documenation. The page is called "InfoView". This means that anytime someone types the term InfoView into a Wiki page, that term is linked over to the InfoView page.
As you can see, although a Wiki page is usually created from another page, that page doesn't necessarily serve as it's sole parent. In the example above, every reference to InfoView creates a link between the pages, but that doesn't mean that they're really related as parent and child, so to speak. For the home page outline, I usually end up keeping the overview of the Wiki somewhat high-level and let these more subtle relationships be uncovered as you explore the sub-pages a bit more. But when I notice an important new page or a page that should serve as a new rubric, I surface it on the home page to emphasize our high-level categorization.
Once someone links to that page, the page is hypertextually related to it. So a page called MyPage that is linked from several other pages is related to all of them. This is true of all poly-hierarchical site organizations where a page falls under many parents. The trouble is, that for many users, the hierarchically organized sites look easy to understand on the surface, while the hypertext Wiki looks like a constantly growing, many tentacled hydra. To keep your Wiki under control you may need to create categories. Watch the growth of recently updated pages and try to assign pages to categories manually.
If you trust that your users will help a little to keep things organized, you may also try this trick. One of the unique things a Wiki does is allow you to see other pages that cite the page you are viewing. This is called a "backlink". Think of it as a reverse-citation. Usually you click the title of the page or a link that reads "Backlinks" and you are shown the citing pages. Backlinks are sometimes used to manage categories by linking up to a Category index. To do this, create a page on your Wiki for holding categories, e.g. SiteCategories. On every page that you view as a main category for the site, insert a link to the SiteCategories page. It's useful to put this in the bottom of the page, for example. Then when you navigate to the SiteCategories page, view it's backlinks to see which pages cite it. It's a little complicated, but it's a hack that works.
When we began to document our project related work, the value of the Wiki became more evident. Long ago, we began to create email discussion groups to archive and document the decisions we made by email. But decisions made in meetings and hallway conversations got lost. When we had to go back and recall why we made certain decisions, if they weren't formally documented in requirements or discussed on email discussion groups, we sometimes had to guess at our logic or recreate the conversations.
We continue to utilize email discussion groups to archive email conversations, and the Wiki serves as nice place to organize, outline and record thoughts that are hashed out in meetings and email discussions. Increasingly we are also using the Wiki to manage projects. In our project pages, you might typically find these types of information:
- Meeting notes
- Product specifications gathering notes
- Product requirements documentation
- Project deliverables, e.g. wireframes, content audits, etc.
- Technical documentation
- Style guides
This is typical of the types of information we're adding presently. We are still using traditional software for producing most of our documents (e.g. MS Word, Excel, Visio) and simply posting links to them. The organization of this information via the Wiki has made it easier to quickly post new information, annotate it and find it later. This is why we're growing to use the Wiki more every day. They are by no means seen as a replacement for the tools we use during our normal processes that are best suited to document creation, but they are enhancing communication and information organization by giving us a to for supplementing our processes and also serves as our organizational memory.
While it may be easy to get a Wiki up and running, the real test of a Wiki's value will be its ability to be continuously utilized. Below are some best practices that may help ensure the sustainability of your Wiki.
- Train your users -- Hold informal training sessions at the beginning of your project and make yourself available to help users on an ongoing basis
- Keep it organized -- Invest time in creating and maintaining category pages, and when you see uncategorized pages, talk to the author about putting them in a category
- Understand use -- Watch the recent changes page to understand how people are using the Wiki
- Lead by example - Use the wiki in all of your project work and to document commonly used staff resources, processes and procedures
- Protect -- Public Wikis may be open to edit-spam, so protect yours and back it up often
Observations of our progress
Library Staff have reported that the Wiki has worked very well so far as the solution for our self-publishing and collaboration problems. I am still surprised and pleased whenever I hear or read the term StaffWiki used in every day conversation and in emails with my colleagues. It has permeated our organization. Beyond the technical features that make the Wiki simple to use, there are other factors at play here that have made the Wiki so successful.
I've found that one of the elements that makes Wikis useful is that they bring back an aspect of knowledge work that we started missing when we stopped passing papers from person to person and annotated them. Malcolm Gladwell talks about the loss of the knowledge creation process in his New Yorker article, "The Social Life of Paper". (http://www.newyorker.com/printable/?critics/020325crbo_books) Gone with web pages are the visible comments, scribbles and modifications. On a Wiki, we simply add or annotate as we go and the revision history is saved for us to review at a later date. In a sense because Wikis allow us to view page history and allow us to add notes to pages within the context of particular words or sentences on the page, they bring back some of that visible collaboration that took place on the paper document. This is an important characteristic for community-authored documentation.
Perhaps what makes Wikis most compelling is both their democratic nature and their ability to capture the knowledge of those that contribute. A Wiki provides web authoring to the masses. It takes advantage of the flexibility of hypertext to create open, collaborative spaces for group authoring and editing of information. In open Wikis, you're not barred from having your say, though you may be edited after the fact on some Wikis if you're off-topic or offensive.
We've seen successful Wikis that have been used for large collaboratively authored bodies of information ranging from the Wikipedia, a Wiki-based encyclopedia, to smaller subject-specific knowledge repositories such as the Knowledge Management Wiki. What makes Wikis such as these so valuable is that the organic growth of their communal knowledge is recorded and visible and serves not only as document archive, but also as the communal memory of all who have participated. This, I think, is my reach goal for our StaffWiki. If we begin to look at it as a tool for more than just publishing logistical information and facts, and perhaps also for capturing and sharing some subject-area knowledge or expertise it may become even more useful to the organization.
Wikis can be an open, flexible platform for collaborative web page authoring. They reduce steps in workflow and work very well in small, controlled groups. But as with most projects that will depend on user contribution, its success depends on ensuring that you make the system bend to meet the processes and needs of your users and that you are able to invest time in training and in continually managing it.
This is a presentation I delivered at the Computers in Libraries 2004 conference in Washington D.C.
The talk proposed a roadmap for providing weblog-related information services and suggested approaches for dealing with the problem of making weblog output of use to the organization. The idea is that the library can position itself to support individuals and communities of practice that express the need to use grass-roots tools for knowledge capture and dissemination such as weblogs and wikis. The talk briefly covered the benefits of using weblogs for individual knowledge creation as opposed to using larger KM solutions selected from the top down, and the implications for IT of an information ecology with a diverse set of people using different technologies for publishing data in a distributed manner all over the intranet. In the near term it suggested first steps towards supporting knowledge creation with RSS. Methods are also discussed for providing access to aggregated blog output as next steps. As a far off goal, the roadmap addresses the integration of output from sources such as blogs with other enterprise information using social software and social network analysis.
Download the presentation below:
Slides with speaking notes, PDF (4.6 MB)
This is a presentation I gave to the Usability Professionals Association on 16 September 2003. The full title was "Making sense of weblogs in the intranet: What they are, why people are using them, making them useful for knowledge management". I talked about weblogs inside my company, their use in knowledge management, and how my organization is hoping to make them usable for enterprise knowledge work if the number of blogs in the company increases significantly.
The abstract from the UPA site:
Lucent Technologies' Information Specialist, Michael Angeles, believes blogging has evolved beyond "cool" and is moving quickly into the corporate world. In this presentation, Angeles will discuss who blogs, how and why.
He will also discuss how Lucent is supporting bloggers and at the same time keeping close watch over the resulting growth of information on the Intranet. Lucent's objective is to determine how the increased content that will result from blogging can evolve into a plan for making that information useful and usable for the enterprise."
Originally published: Angeles, M. (April 15, 2002). K-Logging: Supporting KM with Web Logs. Library Journal.
Web-logging software has received plenty of attention as a quick and easy way to post content to a web site. Web logs (blogs) tend to fall into two categories: personal web logs that function sort of like diaries, and informational blogs that target a readership with a shared interest. But web logging can also be used to support knowledge management (KM)—the effort within an organization to share knowledge and help the organization achieve its mission. This form of web logging, called knowledge logging, or k-logging, is emerging as an inexpensive alternative to large-scale KM solutions.
Within your organization—whether a corporation, school, or museum—there are individuals who either already maintain blogs or could be encouraged to do so. They may be researchers, faculty, curators, or students. The blogs may support research development, share industry information, capture and disperse project information among a team, or just annotate relevant literature for colleagues. Clearly, these k-logs are valuable information capital within your organization. How can librarians support k-loggers? What systems can the library create to make these knowledge assets—the content of the web logs—findable and accessible?
Diversity: a good thing
Bonnie Nardi and Vicki O'Day (Information Ecologies: Using Technology with Heart, MIT, 2000) define an information ecology as a system of people, practices, values, and technologies at work in a local environment. A healthy ecology is one that is dynamic and diverse—comprised of different types of people and technologies. Contrast this with ecologies where homogeneity is enforced through only one technology—where, for example, Lotus Notes is the only means available for knowledge creation.
The idea that diversity in information systems is good might seem contrary to what a lot of IT pundits, consultants, and systems vendors might proffer. But for many organizations, a single-solution KM package isn't practical. A recent market brief by Forrester Research suggests that organizations have begun to move away from single-solution KM packages. A report by Deloitte Research supports this opinion. The latter suggests that bridging the gap between people and systems depends on first creating conditions that allow people to participate in KM locally. This is in opposition to implementing an über-KM solution. These local activities are then connected through networked information appliances, via standard XML formats
Why this shift? A single-solution model requires people to push content into a centralized system in a specific format. The burden of contribution lies with the researcher, scientist, or faculty member. With a decentralized model, content—whether an e-mail, a Word document, or a k-log—can be pulled into a central depository. The burden of contribution is lifted from participants. This is key since the success of KM depends on the willingness of individuals to participate, using tools that are transparent to the knowledge worker.
There are many robust web log tools that are inexpensive or even free. Popular software includes MovableType, Radio Userland, any of the variations of Slashcode, and my favorite, Drupal. They allow individuals to publish content to a web site easily, and some packages even allow for categorization of entries. Most packages also permit authors to publish an XML feed of content. These low-cost tools help knowledge workers with two core concerns of KM: knowledge creation and knowledge sharing.
Web-logging technology is simple to install, typically requiring 15 minutes and no expertise in web publishing. More importantly, it personalizes knowledge development. This means that the software supports the individual's own knowledge capturing. By posting notes, annotations, links to pertinent articles, or just observations, researchers are pursuing their own interests while contributing to KM. In short, k-logging has a good chance of succeeding as a KM solution because it removes barriers to resistance, empowers individuals locally, and requires fewer resources.
The library role: support
Librarians may play different roles as an intermediary between k-loggers and the corporate environment, but the library should be responsible for certain basic actions: support k-loggers by providing content; provide access (taxonomies) to their content; and share knowledge through aggregation and publishing.
K-loggers often create new content by monitoring news feeds in their subject area. They sometimes do this in a news reader integrated with their k-logging tool. When they see a news item of interest, they k-log it and add commentary. Librarians can offer k-loggers XML (RSS) access to vendor-supplied data such as business news and market reports and internal data such as documents and e-mail discussion groups. This data allow k-loggers to monitor their industry or subject area without leaving the firewall. Libraries might also want to incorporate RSS feeds with any standard topic tracking e-mail alerts if they are offered.
Here's how this might work. My organization includes the standard XML/RSS buttons in some search results screens to indicate that results are available in RSS format (see Figure 1). When k-loggers execute a search on a source such as our news database or our market reports database, they see a variety of options for tracking that search. They usually set up an e-mail alert on this search and get search results in XML. Users can copy the URL for the RSS results and track those results via a personal aggregator or news reader such as Radio Userland, Feedreader, or NetNewswire. When they see something of interest in their personal aggregator, they can k-log it.
Figure 1: Presenting XML feeds of database search results
There may be copyright, content licensing, and distribution issues to resolve before you make this content available. You will probably want to offer only RSS feeds of bibliographic data—title, abstract, and URL are common in RSS feeds. We protect our feeds by requiring password authentication to URLs on our site, so usage is closely tracked on a user level. RSS aggregators such as Radio Userland support a login and password.
Subject taxonomies can be used for categorizing k-log entries. If libraries offer a subject taxonomy for enterprise use, k-loggers can tag new entries using the same controlled terminology. When collected by the library's aggregator, entries from different k-logs can then be viewed by subject. To take this even further, if the aggregate of k-log entries is redistributed with classifications intact, it can be redistributed for use in any application you might imagine, providing that it is capable of connecting content via the standardized taxonomy. Many web log tools offer the ability to export blog entries with subject headings using the latest RSS or XFML standards. These formats can be used for remapping individual subject headings to a centralized subject taxonomy.
How might this work from the k-loggers perspective? Imagine that a library maintains a taxonomy of subject headings for the pharmaceuticals industry in XML and HTML formats, along with scope notes and indications of broader and narrower (parent/child) relationships between terms. Users can select slices of this taxonomy, (e.g., pharmaceuticals vendors and families of medication) and enter these terms into their k-log application, later categorizing their k-log entries. Some packages, such as Drupal, will even allow you to insert entire polyhierarchical taxonomies into the k-log application so that k-loggers can do more granular classification of their entries. When k-loggers choose to k-log about a new arthritis medication being distributed by Johnson & Johnson, they can apply these terms from the subject taxonomy. The categorized entries will be distributed with their XML feed. When the KM aggregator reads that new feed entry, it can republish it with the category intact. In this way, readers can find stories about Johnson & Johnson and/or arthritis medications.
Aggregate and share
While this example briefly shows how k-log feeds integrate with our KM aggregator, it glosses over the complexity involved when the library undertakes an aggregator role. When aggregating XML from k-logs, we could just simply install aggregator software and display the stream of new data as it is collected. Figure 2A shows the process and result of this approach. This is serviceable, but shouldn't we add value to this archiving and redistribution by further classifying k-log entries?
Figure 2: Aggregation methods
Some k-loggers will use subject taxonomies to categorize k-log entries at the point of authorship, but not all will. While it's important to establish the conditions that allow creation and sharing, it's also important not to mandate behaviors that interfere with that process. Expect some indexing to be required on your end. After all, if knowledge isn't findable and usable, it's just more useless data in the organization's ether.
Open-source, server-based news aggregator software can collect and publish k-log entries on a periodic or on-demand basis. But most do not offer the classification features mentioned above. These features may be available soon, but if you want them now you will need to do some custom development involving text-parsing and automatic classification of newly collected entries. This can be a great undertaking. Furthermore, while improvements have been made to autoclassification in CMS tools, many believe that the best direction is to take a semi-automated approach using automated classification in conjunction with some manual classification. Figure 2B illustrates what this process might look like.
Another method requires watching news feeds as they arrive and classifying them manually, effectively acting as another k-logger but only watching the k-logs in your enterprise. This brute force method is fairly easy to implement providing you have the human resources. This is the process I used in the two years that I blogged information architecture news on the iaslash.org site.
Factors for success
There are a few additional factors to think about when considering how the library will get involved with k-loggers. These issues affect how your solution will be received, its success, and its sustainability. The greatest consideration is strategic. Do you have the connections and influence to insert the library into the minds and processes of k-loggers? If you build tools, it doesn't necessarily mean that people will use them; you must create awareness of the benefits of sharing knowledge.
Training is important as well. Do you have the resources to train staff to use the new tools? Most will not have experience using subject taxonomies.
Do you have the money and human resources to support taxonomy and information system development and maintenance? Manual classification will mean the use of human resources if you plan on a semi-automated system. When the push comes to extend the functionalities, custom programming will be required as well.
Web-logging is more than just a cool form of web publishing. Savvy corporate k-loggers have proven that it can be a useful way to capture and share knowledge, but the many tools that people will choose for k-logging are diverse. This shouldn't be a problem in your information ecology, however, because XML-formatted data feeds are the glue that will pull together content from disparate k-logs. The final message is not to fear the k-loggers but to embrace their willingness to share knowledge. Empower them to spread their message across the enterprise. Remember that if the right messages reach the right people at the right time, you will positively affect your organization.
This is a presentation I gave to colleagues in the Lucent Integrated Information Solutions group. The purpose of the presentation was to define what weblogging is and discuss why knowledge logs (klogs) are starting to appear inside corporate enterprises. The presentation was meant to introduce some of the concepts and applications to the staff because we are starting to support kloggers and also to discuss implications for our future involvement with kloggers.
Download the PowerPoint presentation. (1.4 MB)
Download PDF. (3.3 MB)