archive.Joe Lamantia.com

Update: Version 1.1 of the Intranet Review Toolkit is available as of 03/20/2006, and now includes a summary spreadsheet.
Thanks go to James Robertson for very gently reminding me that the licensing arrangements for the Intranet Review Toolkit preclude republishing it as a summarized form, such as the spreadsheet I posted earlier today. In my enthusiasm to share a tool with the rest of the community, I didn’t work through the full licensing implications…
Accordingly, I’ll be removing the spreadsheet from harms way immediately, while hoping it’s possible to make it available in a more legally acceptable form.
Apologies to James and the rest of the Toolkit team for any unintended harm from my oversight.

Related posts:

I can’t take credit for writ­ing this para­ble about the rela­tion­ship of infor­ma­tion archi­tec­ture and inter­ac­tion design — that goes to another mem­ber of the IAI — but I can help share it.
»»
A scor­pion who was an Infor­ma­tion Archi­tect and a frog who was an Inter­ac­tion Designer were stand­ing on the bank of a rag­ing river of infor­ma­tion.
“Let’s define the prob­lem” said the IA. “I can’t swim, but I need to get across that river.“
“Well — I can swim” said the ID “I could take you across, but I’m afraid that when we get halfway, you might pull out a Venn Dia­gram and hit me over the head with it.“
“Never!” cried the IA. “Let us brave the river of infor­ma­tion together!“
And so they dived in.
When they were halfway across the river, the IA took a out a wire­frame and stabbed the ID in the back with it.
As they both slowly sank beneath the waves, the ID cried “Why did you do that? Now we’ll both drown!“
Replied the Infor­ma­tion Archi­tect: “Because I was defined that way.“
»»>
I think the mes­sage is clear: What truly mat­ters is get­ting across the river. But that can be very hard to see, if your per­spec­tive doesn’t allow it.
Case in point: Spring of 2001, lit­er­ally a week after the bub­ble burst, I was in Vegas with the rest of the Expe­ri­ence Design Group from Zefer. We were in the mid­dle of one of those impos­si­ble to imag­ine now but com­pletely sen­si­ble at the time 150 per­son design group sum­mit meet­ings about the company’s design method­ol­ogy, prac­tice, group struc­ture, etc.
Our IPO had just gone south, very per­ma­nently, but that wouldn’t by clear for sev­eral months. After a mini-rebellion at which we the assem­bled design con­sul­tants voted to skip the summit’s offi­cially sanc­tioned train­ing and dis­cus­sion activ­i­ties in favor of lots of self-organized cross-practice some­thing or other ses­sions, I ended up sit­ting in a room with the rest of the Usabil­ity and IA folks from the other offices.
Who promptly decided to define all the other design spe­cial­i­ties in detail, because doing so was the key to under­stand­ing our own roles. From here we were to move on to item­ize all the tasks and design doc­u­men­ta­tion asso­ci­ated with each dis­ci­pline, and then define the implicit and explicit con­nec­tions to the spe­cific IA deliv­er­ables. In alpha­bet­i­cal order. Using flip charts, white boards, stick­ies, and notepads.
After five min­utes, I went and to see what the Visual Design­ers were doing. They were sit­ting in a cir­cle in a large and quiet room, dis­cussing their favorite exam­ples of good design in prod­ucts, expe­ri­ences, typog­ra­phy, inter­faces; their goal was to help show the value of design prac­tices to clients. Some of them were also prac­tic­ing yoga, though I’m not sure that was related. The over­all expe­ri­ence was quite a bit more — engag­ing. And use­ful / effec­tive / rel­e­vant, espe­cially out­side the bound­aries of the group. The visual design­ers wanted to get across the river, while the IA’s were taken over by the com­plu­sion to be dili­gent infor­ma­tion archi­tects.
Maybe it’s a per­spec­tive difference?

No related posts.

Getting coffee this afternoon, I saw several packages of tasy looking madeleines sitting in front of the register at Starbucks. For the not small number of people who don’t know that shell shaped pastries made with butter are called madeleines – not everyone has seen The Transporter yet – the package was helpfully labeled “Madeleines”.

Proving that tagging as a practice has gone too far, right below the word madeleines, the label offered the words “tasty French pastry”.

Just in case the customers looking at the clear plastic package aren’t capable of correctly identifying a pastry?
Or to support the large population who can’t decide for themselves what qualifies as tasty?

JP Morgenthal of DMReview.com offers a snapshot of the process for defining enterprise semantics in Enterprise Architecture: The Holistic View: The Role of Semantics in Business.
Morgenthal says, “When you understand the terms that your business uses to conduct business and you understand how those terms impact your business, you can see clearly how to support and maintain the processes that use those terms with minimal effort.”
Not a surprise, but how to make it happen, and how to explain that to the business?

Related posts:

In the same way that information architecture helps take users’ understandings of the structure, meaning, and organization of information into account at the level of domain-specific user experiences, information spaces, and systems, the complex semantic boundaries and relationships that define and link enterprise-level domains is a natural area of activity for enterprise information architecture.
Looking for some technically oriented materials related to this level of IA – what I call enterprise semantic frameworks – I came across a solid article titled Enterprise Semantics: Aligning Service-Oriented Architecture with the Business in the Web Services Journal.
The authors – Joram Borenstein and Joshua Fox – take a web-services perspective on the business benefits of enterprise-level semantic efforts, but they do a good job of laying out the case for the importance of semantic concepts, understanding, and alignment at the enterprise level.
From the article abtract:
“Enterprises need transparency, a clear view of what is happening in the organization. They also need agility, which is the ability to respond quickly to changes in the internal and external environments. Finally, organizations require integration: the smooth interoperation of applications across organizational boundaries. Encoding business concepts in a formal semantic model helps to achieve these goals and also results in additional corollary benefits. This semantic model serves as a focal point and enables automated discovery and transformation services in an organization.”
They also offer some references at the conclusion of the article:

• Borenstein, J. and , J. (2003). “Semantic Discovery for Web Services.” Web Services Journal. SYS-CON Publications, Inc. Vol. 3, issue 4. www.sys-con.com/webservices/articleprint.cfm?id=507
• Cowles, P. (2005). “Web Service API and the Semantic Web.” Web Services Journal. SYS-CON Publications, Inc. Vol. 5, issue 2. www.sys-con.com/story/?storyid=39631&DE=1
• Genovese, Y., Hayword, S., and Comport, J. (2004). “SOA Will Demand Re-engineering of Business Applications.” Gartner. October 8.
• Linthicum, D. (2005). “When Building Your SOA…Service Descriptions Are Key.” WebServices.Org. March 2005. www.webservices.org/ws/content/view/full/56944
• Schulte, R.W., Valdes, R., and Andrews, W. (2004). “SOA and Web Services Offer Little Vendor Independence.” Gartner. April 8.
• W3C Web Services Architecture Working Group: www.w3.org/2002/ws/arch/

Related posts:

A recent post on the IAI mailing list asked how common it is for IAs to define page shapes or “…wire frames from 10,000 feet, with names for each of the “zones” (n.b. not “elements”, “zones”). …Any given site may have a handful of page shapes, and each page shape has a handful of page zones. Each page and each shape would be named for easy reference.”
I’ve used a very similar approach based on the defining a limited number of ‘screen types’ that show standardized page structures and layouts for documenting browser based applications. I’ve posted an example of this kind of schematics or wire frames packet done for a small content managment system. This packet includes a conceptual overview of the user domain, as well as a set of defined screen types, screen flows, and wire frames. Here’s the full packet, exported from Visio as html.
Page shapes or screen types look like this:

Or this:

These are the accompanying wire frames or schematics:

Related posts:

“An artist, a guru, a coach, and a spy” is how David C. Baker and Michael Janiszewski describe enterprise architects in their article 7 Essential Elements of EA.
The full quote is, “An enterprise architect requires a unique blend of skills. At various times he or she needs to employ the characteristics of an artist, a guru, a coach, and a spy.” Besides being pithy because it sounds like the intro to one of those ‘____ walk into a bar’ jokes, this rings true for enterprise information architects. However, humorousness aside, this isn’t terribly useful. And overall, the article is a fine breakdown of what’s required to put enterprise architecture into practice, but it only offers the pioneer’s perspective on where enterprise-level architects come from.
Their take, “Enterprise architects grow from within the technical architecture ranks, learning how to be artists, gurus, coaches, and spies as they work their way from being technical specialists, through application or infrastructure architects, eventually to enterprise architects.”
This is an honest if after-the-fact apprasial of a self-directed career growth trajectory that is no stranger to veteran IAs. It’s not adequate as a way to expand the understood scope of information architecture roles to address the enterprise perspective. I feel comfortable saying Information Architecture is accepted as relevant and useful in many areas of business activity, from user research and experience design to product development and strategy, after a few lean years following the dot com crash. But I’m not comfortable saying we have appropriate representation or even access to the enterprise level. It’s here that the business and information perspectives come together in an architectural sense, and also here where we should strive to make sure we’re valued and sought out.
We need to discover, create and define the paths that lead Information Architects to enterprise level positions.to action>
The alternative is being left behind.

Related posts:

I’m working on a portal project at the moment for a healthcare client, so I’ve heard a great deal about how the concept of ‘portal’ is so diluted as to be effectively meaningless. Following a series of surprisingly muddled conversations with technologists, business types, and end users representatives around the concept for this new portal, I realized that much of the hand-wringing and confusion comes from simple lack of perspective – on the different perspectives represented by each viewpoint. Ambiguity or disagreement about which perspective is the frame of reference in any given discussion is the biggest source of the confusion and friction that makes these projects needlessly difficult.
There are (at least) three different perspectives on the meaning of the term portal.
To technologists and system developers, a portal is a type of solution delivery platform with standard components like authentication, an application server, integration services, and business logic and presentation layers that is generally purchased from a vendor and then customized to meet specific needs. Examples are Plumtree, BEA, IBM, etc.
To users, a portal is a single destination where it’s possible to obtain a convenient and – likely, though not always – personalized combination of information and tools from many different sources. Some examples of this sense of the term include Yahoo, MSN, and a well-developed intranet.
To a business, a portal is a bounded vehicle for aggregating information and tools to address diverse constituent needs in a coordinated and coherent way, with lowered management and administration costs realized via framework features like personalization, customization, and role-based configuration.
One case where all three of these frames of reference intersect is with Executive Dashboard projects. A dashboard is a portal in all three of these senses (unless it happens to rest on a different architecture / technology stack, in which case I maintain that it’s something else, so as an IA it’s prudent to keep in mind the differing implications and assumptions associated with each perspective while dealing with their representatives.

Related posts:

Thanks to all who stopped by to ask questions and express interest in some of the concepts central to executive dashboards, portals, or to simply say hello during the poster session at the IA Summit in Montreal. Many of you took cards, and I look forward to hearing from you soon. Based on the level of interest, I’m talking with the good people at Boxes and Arrows about how to share some of this experience and these ideas in more depth. Stay tuned.

Meanwhile, until the summit site offers a full set of presenter materials, you can find the.pdf version (it’s a largish ~6MB) here.

The published description of the poster is below:

Executive Dashboards: Simple IA Building Blocks Support A Suite of Sophisticated Portals
This poster depicts how a small set of standardized Information Architecture structures and elements was used to create an effective suite of interconnected Executive Dashboards at low cost and without substantial redesign effort.

This suite of dashboards meets the diverse information needs of senior decision makers working within many different business units in a global pharmaceutical company. These dashboards incorporate a wide variety of data types and functionality, but present everything within a consistent and usable User Experience by employing modular tiles and navigation structures.

This set of modular tiles and navigation structures met the diverse information needs of senior decision makers operating within several different business units.

The poster shows how the basic IA component or ‘atom’ of a tile or portlet, with a standard structure, elements, and labeling can contain a tremendous variety of content types. The content types include qualitative and quantitative visual and textual data displays, as well as complex functionality syndicated from other enterprise applications. It also shows how tiles are easily combined with other tiles or portlets to create larger scale and more sophisticated structures that are still easy for users to comprehend, allowing them to synthesize and compare formerly siloed information views to guide strategic decisions.

The poster shows how simple information architecture components common to all the dashboards allow rapid access to a tremendous amount of information, from many sources. The poster shows how this IA framework scaled well and responded to changing business needs over time, allowing the addition of large numbers of new tiles, views, and types of information to existing Dashboards without substantial redesign or cost.

The poster demonstrates how a set of IA components allows designers to present critical business information by operating unit, geography, topic, or specific business metric, at varying levels of detail, based on the needs of specific audiences.
The poster shows how this set of IA components allowed numerous design teams to innovate within a framework, thus creating an extensive library of reusable tiles and views available for syndication throughout the suite of Executive Dashboards.
The end result of this approach to solving diverse design problems is a series of well integrated User Experiences offering substantial business value to a wide audience of users.

I’ve added a batch of photos to the Flickr group for the IA Summit here. More coming soon…

Related posts: