Archive for December 2006

Suggested Tag for Building Blocks Stuff

December 31st, 2006 — 2:19pm

I’ve cre­ated a sug­gested (and highly orig­i­nal) tag for book­mark­ing items related to the build­ing blocks:


I’ve tagged a few items on — my default book­mark­ing ser­vice — and will mon­i­tor tag streams from some of the other book­mark­ing ser­vices.

Comment » | Building Blocks, Enterprise, Information Architecture

Enterprise Information Article on Portal Usability Problems

December 9th, 2006 — 2:08pm

Janus Boye (of CMSWatch) just pub­lished an arti­cle called The trou­ble with por­tal dash­boards… in Enter­prise Infor­ma­tion, in which he dis­cusses the usabil­ity prob­lems of enter­prise por­tals.
Janus iden­ti­fies the essen­tial prob­lem of cur­rent por­tal design approaches built on flat tiles:
Today most organ­i­sa­tions blindly adopt the default ‘build­ing block’ approach to lay­out found in enter­prise por­tals — a relic from the early days of pub­lic inter­net por­tals. But users com­plain that while such an inter­face may look slick in early sales demon­stra­tions, in pro­duc­tion it typ­i­cally only facil­i­tates work for tech­ni­cally adept super-users. The occa­sional user eas­ily gets con­fused and frus­trated work­ing with a clut­tered screen of lit­tle boxes show­ing many dif­fer­ent portlets. Get­ting ade­quate value from the por­tal typ­i­cally requires sub­stan­tial train­ing.
This is a good snap­shot of the long term weak­nesses of a flat por­tal user expe­ri­ence, what Janus calls “the default ‘build­ing block’ approach” [empha­sis mine]. It strongly par­al­lels my recent post out­lin­ing some of the inher­ent usabil­ity weak­nesses of por­tals, and is a great lead in for the build­ing blocks. (Note: Janus uses the term build­ing blocks dif­fer­ently.)
In another high­light worth men­tion­ing Janus iden­ti­fies six dis­tinct types of por­tals, refer­ring to them as use cases. I think of these as types of infor­ma­tion envi­ron­ments. The dif­fer­ence is a seman­tic one that’s shaped by your con­text for the term por­tal. Janus is speak­ing from the busi­ness per­spec­tive, thus his focus on the busi­ness prob­lem solved by each type of por­tal.
They are:

  • Dynamic web pub­lish­ing; the sim­plest use case and a com­mon entry point for por­tal developers
  • Self-service por­tal; enabling staff or cus­tomers to help them­selves and obtain ser­vice on their terms
  • Col­lab­o­ra­tion por­tal; enabling dis­persed teams to work together on projects
  • Enter­prise intranet; help­ing staff work more effi­ciently, often via mul­ti­ple spe­cialised por­tal applications
  • E-business por­tal; enabling enter­prises to extend com­mer­cial infor­ma­tion and ser­vices to exter­nal trad­ing part­ners, sup­pli­ers and customers
  • Enter­prise inte­gra­tion; link­ing sys­tems to achieve greater effi­ciency and agility.

What’s impor­tant to under­stand from this list is that the default flat tiles approach under­ly­ing these dif­fer­ent envi­ron­ments is the same, and so are the result­ing usabil­ity prob­lems, with their atten­dant busi­ness costs. The build­ing blocks will sup­port all six por­tal types handily.

Comment » | Building Blocks, Dashboards & Portals, Information Architecture, User Experience (UX)

Usability Weaknesses Inherent In Portals

December 8th, 2006 — 4:33pm

In a recent com­ment, Joe Sokohl asked about usabil­ity in por­tals, specif­i­cally if design­ing with the build­ing blocks improves usabil­ity.
Here’s his ques­tion:
One topic I hope you cover is any usabil­ity test­ing results you might’ve come up with. How usable is this approach, for exam­ple? How suc­cess­fully are execs using these tiles? I think it’s a neat way to short­cut the dev process, too.
Por­tal user expe­ri­ences suf­fer from a num­ber of inbuilt usabil­ity weak­nesses that the build­ing blocks are designed to elim­i­nate. For instance, flat tile schemes assume all tiles are struc­turally the same, and that they have no rela­tion­ship to any other tiles. This makes all tiles of equal impor­tance to the portal’s infor­ma­tion archi­tec­ture. [Wel­come to Flat­land…] Yet any designer or infor­ma­tion archi­tect address­ing diverse user needs and goals knows that the pri­or­i­ties of users make some con­tent more impor­tant than oth­ers, and that the struc­ture of the user expe­ri­ence should reflect these pri­or­i­ties and any nec­es­sary rela­tion­ships.
Flat­ness also ham­pers inter­ac­tion design and infor­ma­tion design, obstruct­ing the estab­lish­ment of good visual flows and path­ways lead­ing the eye to the right areas of a por­tal page. The eye and brain (visual sys­tem) inter­prets the fea­tures and “ter­rain” of the cur­rent field of view, a process that occurs when users look at a por­tal page. The absence of con­cep­tual dif­fer­ences between tiles in flat por­tal expe­ri­ences makes it dif­fi­cult to cre­ate sup­port­ing visual cues that direct the eye to the appro­pri­ate fea­tures of the field of view. Effec­tively, it’s a fea­ture­less land­scape lack­ing depth that the eye and brain can­not eas­ily inter­pret, an effect sim­i­lar to dri­ving through white­out con­di­tions (an extreme exam­ple).
Fur­ther, tight sched­ul­ing and bud­get real­i­ties often mean design teams inherit the default user expe­ri­ence aspects of tiles from the por­tal plat­form, with lim­ited or no lee­way for change. In these sit­u­a­tions cases, the default designs and nav­i­ga­tion become a tech­nol­ogy con­straint, instead of a point of depar­ture, as intended!
The most com­mon solu­tion to these inbuilt weak­nesses is to rely on the con­tents of tiles to solve all three prob­lems at the same time: indi­cate struc­ture and rela­tion­ships, lead users to the right area of the page, and over­come the user expe­ri­ence design con­straints of the tech­nol­ogy plat­form or pre­sen­ta­tion frame­work.
This is the wrong approach, for many rea­sons. It counts on con­tent to do the job of struc­ture. It con­tra­dicts the pur­pose of inde­pen­dent tiles. It decreases usabil­ity over­all, because in many por­tals, syn­di­cated tiles appear in many dif­fer­ent places and con­texts where the rela­tion­ships assumed and expressed in their con­tent are nei­ther present nor valid.
By con­trast, the goal of the build­ing blocks is to pro­vide a sim­ple vocab­u­lary for cre­at­ing use­ful struc­tures and rela­tion­ships obvi­at­ing the need to over­load tiles. Using the build­ing blocks elim­i­nates these sorts of emer­gent usabil­ity prob­lems rooted in the weak­nesses of flat por­tal user expe­ri­ences.
Time and space allow­ing, I’ll talk more about some of the usabil­ity find­ings in the case study / exam­ple mate­r­ial that’s planned for the series. A brief note about exec­u­tive dash­boards, as opposed to por­tals: Dash­boards often serve very small user groups, which means that usabil­ity con­cerns and find­ings end up being closely tied to the usage pat­terns and pref­er­ences of that small group (some­times a sin­gle user). In sev­eral instances, after some very puz­zling usabil­ity feed­back, we dis­cov­ered the pre­ferred way of using the dash­board was to have an assis­tant print out a page assem­bled from a com­plex set of tiles struc­tured with the build­ing blocks.

3 comments » | Building Blocks, Dashboards & Portals, Information Architecture, User Experience (UX)

Forthcoming Boxes and Arrows Series on Portal Building Blocks

December 7th, 2006 — 2:41pm

Hur­ray for vol­un­teer pub­lish­ing: Next week, Boxes and Arrows, is pub­lish­ing the first install­ment of a series of arti­cles on infor­ma­tion archi­tec­ture for por­tals and tile-based user expe­ri­ences. It intro­duces a sys­tem of reusable build­ing blocks that pro­vides con­sis­tent struc­ture for and low­ers the costs of design­ing and main­tain­ing por­tals.
The build­ing blocks are a por­tal design toolkit I devel­oped while work­ing on sev­eral exec­u­tive dash­board projects in close suc­ces­sion. I’ve used the build­ing block sys­tem in por­tals, Web appli­ca­tions, busi­ness intel­li­gence tools, dash­boards, and con­tent man­age­ment sys­tems: essen­tially any design rely­ing on or incor­po­rat­ing tiles or portlets. The build­ing blocks play nicely with RIA, AJAX, and other evolv­ing user expe­ri­ence and devel­op­ment approaches, because they address infor­ma­tion archi­tec­ture con­cerns with­out requir­ing any spe­cific tech­nol­ogy or plat­form.
Fol­low up arti­cles will explain the build­ing blocks in detail, and how to use them quickly and effi­ciently.
The series will cover:

  • Basic prin­ci­ples and assumptions
  • Guide­lines for assem­bling blocks into larger units
  • Mod­u­lar build­ing blocks of all sizes (Containers)
  • Mod­u­lar nav­i­ga­tion com­po­nents (Connectors)
  • Stan­dard­ized Con­ve­nience Func­tion­al­ity for blocks
  • Com­mon Util­ity Functionality
  • Sug­gested meta­data attrib­utes for blocks

Assum­ing the response to the first pieces is pos­i­tive (be sure to read and com­ment!), we’ll pro­vide a case study, and cre­ate a set of sup­port­ing mate­ri­als to make it easy to use the build­ing blocks for your own projects. The goal is to offer a com­plete pack­age for some­one who needs help cre­at­ing an effec­tive and scal­able user expe­ri­ence for a por­tal or tile-based envi­ron­ment.
Aside from being a resource for the design of por­tal user expe­ri­ences, the build­ing blocks are the first attempt (dis­claimer: that I know of…) at cre­at­ing a reusable IA design frame­work for a com­mon type of busi­ness prob­lem / user expe­ri­ence / infor­ma­tion envi­ron­ment. It’s not as broad in scope as Jesse Jame Garrett’s Visual Vocab­u­lary, because it works at a more gran­u­lar level of detail, but it should sup­port design efforts in a wide vari­ety of set­tings.
Those who enjoyed the 2005 IA Sum­mit in Mon­tréal might remem­ber I pre­sented a poster on the build­ing block idea. The poster is essen­tially a pre­view of what the series will cover fully.
And it’s a per­fect excuse to try out Rashmi’s new Slideshare ser­vice.

I’ll be on hol­i­day (in Jamaica: did some­one say Red Stripe…?) next week, but will try to log on to catch up on com­ments and ques­tions.
Hope every­one enjoys the arti­cles.
The first arti­cle The Chal­lenge of Dash­boards and Por­tals is live as of Decem­ber 14th

3 comments » | Building Blocks, Dashboards & Portals, Information Architecture

Presenting for the Taxonomy Community of Practice: IA and Taxonomy

December 1st, 2006 — 11:15am

I’m pre­sent­ing for the Tax­on­omy Com­mu­nity of Prac­tice web sem­i­nar today. I’ll be talk­ing about a long-term, enterprise-level strat­egy and design engage­ment for a finan­cial ser­vices client, shar­ing work that com­bines infor­ma­tion archi­tec­ture and tax­on­omy efforts over the past year.
The agenda for the call includes sev­eral other speak­ers; it should be a strong show­case of infor­ma­tion archi­tec­ture and tax­on­omy work from dif­fer­ent set­tings.
If you’d like to lis­ten, some details are below. Reg­is­tra­tion and more infor­ma­tion is avail­able from
Date and time: Fri­day, Decem­ber 1st, 2006 — 2:00 to 3:30 PM EDT

Dura­tion: 90 minutes

For­mat: Teleconference

Cost: $50 per attendee

Reg­is­ter for the ses­sion (you will receive dial-in instruc­tions and slides the day before the call)
User Expe­ri­ence design is often thought of as dis­tinct or dif­fer­ent from tax­on­omy design. What are good IA prac­tices and how do they influ­ence tax­on­omy design? In this ses­sion you’ll hear from three expe­ri­enced IA’s who will share spe­cific exam­ples from their orga­ni­za­tions and con­sult­ing projects that will illus­trate prin­ci­ples that you can apply in your tax­on­omy projects.
In this ses­sion, hear about:

  • a user expe­ri­ence design effort that com­bines infor­ma­tion archi­tec­ture and tax­on­omy approaches for a major finan­cial ser­vices client
  • spe­cific expe­ri­ences apply­ing IA with Com­paq and HP and “busi­ness tax­onomies” — tax­onomies that live within strict busi­ness limitations

Seth Ear­ley, Ear­ley & Associates

Joe Laman­tia

Bob Good­man

Andrew Gent, Hewlitt Packard

Comment » | Enterprise, User Experience (UX)

Back to top