Category: Dashboards & Portals

The Architecture of Discovery: Slides from Discover Conference 2011

April 16th, 2011 — 1:11pm

Endeca invites cus­tomers, part­ners and lead­ing mem­bers of the broader search and dis­cov­ery tech­nol­ogy and solu­tions com­mu­ni­ties to meet annu­ally, and show­case the most inter­est­ing and excit­ing work in the field of dis­cov­ery.  As lead for the UX team that designs Endeca’s dis­cov­ery prod­ucts, I shared some of our recent work on pat­terns in the struc­ture of dis­cov­ery appli­ca­tions, as well as best prac­tices in infor­ma­tion design and visu­al­iza­tion that we use to drive prod­uct def­i­n­i­tion and design for Endeca’s Lat­i­tude Dis­cov­ery Framework.

This mate­r­ial is use­ful for pro­gram and project man­agers and busi­ness ana­lysts defin­ing require­ments for dis­cov­ery solu­tions and appli­ca­tions, UX and sys­tem archi­tects craft­ing high-level struc­tures and address­ing long-term growth, inter­ac­tion design­ers and tech­ni­cal devel­op­ers defin­ing and build­ing infor­ma­tion work­spaces at a fine grain, and

There are three major sec­tions: the first presents some of our tools for iden­ti­fy­ing and under­stand­ing people’s needs and goals for dis­cov­ery in terms of activ­ity (the Lan­guage of Dis­cov­ery as we call it), the sec­ond brings together screen-level, appli­ca­tion level, and user sce­nario / use-case level pat­terns we’ve observed in the appli­ca­tions cre­ated to meet those needs, and the final sec­tion shares con­densed best prac­tices and fun­da­men­tal prin­ci­ples for infor­ma­tion design and visu­al­iza­tion based on aca­d­e­mic research dis­ci­plines such as cog­ni­tive sci­ence and infor­ma­tion retrieval.

It’s no coin­ci­dence that these sec­tions reflect the appli­ca­tion of the core UX dis­ci­plines of user research, infor­ma­tion archi­tec­ture, and inter­ac­tion design to the ques­tion of “who will need to encounter infor­ma­tion for some end, and in what kind of expe­ri­ence will they encounter it”.  This flow and order­ing is delib­er­ate; it demon­strates on two lev­els the results of our own efforts apply­ing the UX per­spec­tive to the ques­tions inher­ent in cre­at­ing dis­cov­ery tools, and shares some of the tools, insights, tem­plates, and resources we use to shape the plat­form used to cre­ate dis­cov­ery expe­ri­ences across diverse industries.

Ses­sion outline

  1. Under­stand­ing User Needs
  2. Design Pat­terns for Dis­cov­ery Applications
  3. Design Prin­ci­ples and Gudielines for Infor­ma­tion Inter­ac­tion and Visualization

Ses­sion description

How can you har­ness the power and flex­i­bil­ity of Lat­i­tude to cre­ate use­ful, usable, and com­pelling dis­cov­ery appli­ca­tions for enter­prise dis­cov­ery work­ers? This ses­sion goes beyond the tech­nol­ogy to explore how you can apply fun­da­men­tal prin­ci­ples of infor­ma­tion design and visu­al­iza­tion, ana­lyt­ics best prac­tices and user inter­face design pat­terns to com­pose effec­tive and com­pelling dis­cov­ery appli­ca­tions that opti­mize user dis­cov­ery, suc­cess, engage­ment, & adoption.”

The pat­terns are prod­uct spe­cific in that they show how to com­pose screens and appli­ca­tions using the pre­de­fined com­po­nents in the Dis­cov­ery Frame­work library.  How­ever, many of the product-specific com­po­nents are built to address com­mon or recur­ring needs for inter­ac­tion with infor­ma­tion via well-known mech­a­nisms such as search, fil­ter­ing, nav­i­ga­tion, visu­al­iza­tion, and pre­sen­ta­tion of data.  In other words, even if you’re not using the lit­eral Dis­cov­ery Frame­work com­po­nent library to com­pose your spe­cific infor­ma­tion analy­sis work­space, you’ll find these pat­terns rel­e­vant at work­space and appli­ca­tion lev­els of scale.

The deeper story of these pat­terns is in demon­strat­ing the evo­lu­tion of dis­cov­ery and analy­sis appli­ca­tions over time.  Typ­i­cally, dis­cov­ery appli­ca­tions begin by offer­ing users a general-purpose work­space that sat­is­fies a wide range of inter­ac­tion tasks in an approx­i­mate fash­ion.  Over time, via suc­ces­sive expan­sions in the the scope and vari­ety of data they present, and the dis­cov­ery and analy­sis capa­bil­i­ties they pro­vide, dis­cov­ery appli­ca­tions grow to include sev­eral dif­fer­ent types of work­spaces that indi­vid­u­ally address dis­tinct sets of needs for visu­al­iza­tion and sense mak­ing by using very dif­fer­ent com­bi­na­tions of com­po­nents.  As a com­pos­ite, these func­tional and infor­ma­tion­ally diverse work­spaces span the full range of inter­ac­tion needs for dif­fer­ing types of users.

I hope you find this toolkit and col­lec­tion of pat­terns and infor­ma­tion design prin­ci­ples use­ful.  What are some of the resources you’re using to take on these challenges?

User Expe­ri­ence Archi­tec­ture For Dis­cov­ery Appli­ca­tions from Joe Laman­tia

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

Frameworks are the Future of IA: A Case Study and Example

August 20th, 2008 — 7:43am

Sep­tem­ber in Ams­ter­dam approaches: in addi­tion to the inevitable mix of clouds, rain, more rain, and tiny sliv­ers of sun­light, Sep­tem­ber means EuroIA 2008, where yours truly will speak about design frame­works.
In case you can’t make the con­fer­ence, here’s a text only sum­mary of my talk. Pic­tures will fol­low the pre­sen­ta­tion — promise!

It’s a DIY Future
The Web is shift­ing to a DIY [Do It Your­self] model of user expe­ri­ence cre­ation, one where peo­ple assem­ble indi­vid­ual com­bi­na­tions of con­tent gath­ered form else­where for expres­sive, func­tional, and (many) other pur­poses. The rapid growth of wid­gets, the resur­gence of enter­prise por­tals, the spread of iden­tity plat­forms from social net­work des­ti­na­tions to blog­ging ser­vices, and the rapid increase in the num­ber of pub­lic APIs syn­di­cat­ing func­tion­al­ity and data, are all exam­ples of the DIY shift.

Archi­tects of the Future
For design pro­fes­sion­als, the defin­ing char­ac­ter­is­tic of DIY future is co-creation: the par­tic­i­pa­tion of a broad spec­trum of peo­ple in cre­at­ing expe­ri­ences. In this new world, the role of design­ers is to define the tools co-creators use to assem­ble expe­ri­ences for them­selves and oth­ers. These tools will increas­ingly take the form of design frame­works that define the mod­u­lar com­po­nents of famil­iar struc­tures such as social net­works, func­tional appli­ca­tions, col­lab­o­ra­tion plat­forms, per­son­al­ized dash­boards, and man­age­ment con­soles.

Why Frame­works?
Frame­works are the future for three rea­sons. First, every­one can cre­ate sophis­ti­cated infor­ma­tion struc­tures now, and design­ers no longer serve as a gate­way. Sec­ond, the def­i­n­i­tion of frame­works allows design­ers to con­tinue to pro­vide valu­able ser­vices and exper­tise in a cost effec­tive man­ner: It’s some­thing design­ers can sell in a com­mod­i­fied dig­i­tal econ­omy. Third, design­ers have an good com­bi­na­tion of human insight and archi­tec­ture design skills; this hybrid way of think­ing can serve as a dif­fer­en­tia­tor and strength.

One exam­ple of the sort of design frame­work infor­ma­tion archi­tects will cre­ate more of in the DIY future is the Por­tal Build­ing Blocks sys­tem described herein. Prov­i­den­tially, this design frame­work addresses many of the prob­lems inher­ent in the cur­rent archi­tec­tural schema for DIY self-assembled expe­ri­ences.

His­tory Repeats Itself: The Prob­lem With Por­tals
The rise and fall of the Web 1.0 por­tal form offers a use­ful his­tor­i­cal les­son for cre­ators of the new gen­er­a­tion of design frame­works under­ly­ing DIY self-assembled expe­ri­ences.
Despite early promises of util­ity and con­ve­nience, por­tals built with flat portlets could only grow by expand­ing hor­i­zon­tally. The result­ing expe­ri­ence of low-density infor­ma­tion archi­tec­tures was sim­i­lar to that of nav­i­gat­ing post­war sub­ur­ban sprawl. Like the rapid decline of many once-prosperous sub­urbs, the incon­ve­nience of these sprawl­ing col­lec­tions of portlets quickly over­whelmed the value of the con­tent they aggre­gated.
The com­mon prob­lem that doomed many very dif­fer­ent por­tals to the same fate was the com­plete lack of any pro­vi­sion for struc­ture, inter­ac­tion, or con­nec­tion between the self-contained portlets of the stan­dard por­tal design frame­work.
Look­ing ahead, the co-created expe­ri­ences of the DIY future will repeat this cycle of unhealthy growth and sprawl — think of all those apps clog­ging your iPhone’s home screen right now — unless we cre­ate design frame­works that effec­tively pro­vide for struc­ture, con­nec­tion, and inter­ac­tion.

The Build­ing Blocks — An Exam­ple Design Frame­work
The build­ing block frame­work is meant to serve as a robust archi­tec­tural foun­da­tion for the many kinds of tools and func­tion­al­ity — par­tic­i­pa­tory, social, col­lab­o­ra­tive — that sup­port the vision of two-way flows within and across the bound­aries of infor­ma­tion struc­tures. This means:

  • Allow for rapid growth and struc­tural change
  • Estab­lish a com­mon lan­guage for all co-creation perspectives
  • Encour­age con­struc­tion of scal­able, reusable structures
  • Cre­ate high-quality user experiences
  • Enable shar­ing of assets across boundaries
  • Enhance social dynam­ics, such as 2-way con­ver­sa­tion flows

The Build­ing Blocks frame­work defines two types of infor­ma­tion archi­tec­ture com­po­nents in detail — build­ing blocks (or Con­tain­ers), and nav­i­ga­tion com­po­nents (or Con­nec­tors) — as well as the sup­port­ing rules and guide­lines that make it pos­si­ble to assem­ble com­plex user expe­ri­ence archi­tec­tures quickly and effec­tively.
The Con­tain­ers and Con­nec­tors specif­i­cally pro­vide for struc­ture, inter­ac­tion, and con­nec­tion at all lev­els of the infor­ma­tion envi­ron­ment; from the user expe­ri­ence — visual design, infor­ma­tion design, inter­ac­tion design, infor­ma­tion archi­tec­ture — to func­tion­al­ity, meta­data, busi­ness rules, sys­tem archi­tec­ture, admin­is­tra­tive processes, and strate­gic gov­er­nance.
Case Study: Evo­lu­tion of an Enter­prise Por­tal Suite
The Build­ing Blocks began life as an inter­nal tool for low­er­ing costs and speed­ing design dur­ing the course of sus­tained por­tal work done for a For­tune 100 client. Over a span of ~24 months, the Build­ing Blocks pro­vided an effec­tive frame­work for the design, expan­sion, and even­tual inte­gra­tion of nearly a dozen dis­tinct por­tals.
The design frame­work evolved in response to changes in the audi­ences, struc­tures, and con­tents of por­tals con­structed for users in dif­fer­ent coun­tries, dif­fer­ent oper­at­ing units, and sev­eral orga­ni­za­tional lev­els.
The por­tal suite went through sev­eral stages of evo­lu­tion and growth:

  • Exper­i­men­ta­tion
  • Rapid expan­sion
  • Con­sol­i­da­tion & integration
  • Sta­bil­ity and continuity

Lessons In Design­ing Frame­works
Suc­cess­ful co-created expe­ri­ences — Flickr (com­mer­cial) and Wikipedia (non-commercial) — com­bine delib­er­ate top-down archi­tec­ture and design with emer­gent or bottom-up con­tri­bu­tion and par­tic­i­pa­tion in a new kind of struc­ture Kevin Kelly calls the “hybrid”. Frame­works sup­port hybrids!
Hope to see many of you in Amsterdam!

Comment » | Building Blocks, Dashboards & Portals, Information Architecture

IA Summit Slides: Effective IA For Enterprise Portals

April 17th, 2008 — 3:34pm

I’ve posted slides for my recent Effec­tive IA For Enter­prise Por­tals pre­sen­ta­tion at the IA Sum­mit in Miami. Por­tals are not a tra­di­tional space for user expe­ri­ence prac­ti­tion­ers, so many thanks to the packed house that turned out, and stayed as we both started late to accom­mo­date the crowd, and then ran long.
These slides include a sub­stan­tial amount of case study and exam­ple mate­r­ial that I didn’t cover directly in the talk. For the repeat ses­sion on Sun­day, I showed addi­tional exam­ples beyond those included here in the start­ing slides.
Stay tuned for a more detailed writeup of both pub­lished and unpub­lished exam­ple mate­r­ial — one that shows the build­ing blocks in action at all lev­els of a multi-year por­tal effort from ini­tial strat­egy through design and into gov­er­nance / evo­lu­tion — in part six of the Build­ing Blocks series run­ning in Boxes and Arrows, due out once the post-summit flurry set­tles down.

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

"Enhancing Dashboard Value and User Experience" Live at Boxes and Arrows

March 5th, 2008 — 5:12pm

Boxes and Arrows just pub­lished Enhanc­ing Dash­board Value and User Expe­ri­ence, part 5 of the build­ing blocks series that’s been run­ning since last year. This install­ment cov­ers how to include high-value social and con­ver­sa­tional capa­bil­i­ties into por­tal expe­ri­ences built on top of archi­tec­tures man­aged with the build­ing blocks. Enhanc­ing Dash­board Value and User Expe­ri­ence also pro­vides an explicit user expe­ri­ence vision for por­tals, meta­data and user inter­face rec­om­men­da­tions, and as tips on mak­ing por­tals eas­ier to use and man­age / admin­is­trate.
Thanks again to all the good peo­ple who vol­un­teer their time to make Boxes and Arrows such a high qual­ity publication!

Comment » | Building Blocks, Dashboards & Portals, Information Architecture

Portal Building Blocks Intro on Boxes and Arrows

July 24th, 2007 — 10:36am

Boxes and Arrows just pub­lished part two of the Por­tal Build­ing Blocks series — Intro­duc­tion to the Build­ing Blocks. This sec­ond install­ment cov­ers the design con­cepts behind the por­tal build­ing blocks sys­tem, and guide­lines on how to flex­i­bly com­bine the blocks into a well-structured user expe­ri­ence.
If you are work­ing on a por­tal, dash­board, wid­get, social media plat­form, web-based desk­top, or any tile-based design, this series should help clar­ify the growth and usabil­ity chal­lenges you will encounter, as well as pro­vide a pos­si­ble solu­tion, in the form of a sim­ple design frame­work that is plat­form and ven­dor neu­tral.
Stay tuned for the third install­ment in the series, due out shortly!

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

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

Three Contexts for the Term "Portal"

June 27th, 2005 — 3:37pm

I’m work­ing on a por­tal project at the moment for a health­care client, so I’ve heard a great deal about how the con­cept of ‘por­tal’ is so diluted as to be effec­tively mean­ing­less. Fol­low­ing a series of sur­pris­ingly mud­dled con­ver­sa­tions with tech­nol­o­gists, busi­ness types, and end users rep­re­sen­ta­tives around the con­cept for this new por­tal, I real­ized that much of the hand-wringing and con­fu­sion comes from sim­ple lack of per­spec­tive — on the dif­fer­ent per­spec­tives rep­re­sented by each view­point. Ambi­gu­ity or dis­agree­ment about which per­spec­tive is the frame of ref­er­ence in any given dis­cus­sion is the biggest source of the con­fu­sion and fric­tion that makes these projects need­lessly dif­fi­cult.
There are (at least) three dif­fer­ent per­spec­tives on the mean­ing of the term por­tal.
To tech­nol­o­gists and sys­tem devel­op­ers, a por­tal is a type of solu­tion deliv­ery plat­form with stan­dard com­po­nents like authen­ti­ca­tion, an appli­ca­tion server, inte­gra­tion ser­vices, and busi­ness logic and pre­sen­ta­tion lay­ers that is gen­er­ally pur­chased from a ven­dor and then cus­tomized to meet spe­cific needs. Exam­ples are Plumtree, BEA, IBM, etc.
To users, a por­tal is a sin­gle des­ti­na­tion where it’s pos­si­ble to obtain a con­ve­nient and — likely, though not always — per­son­al­ized com­bi­na­tion of infor­ma­tion and tools from many dif­fer­ent sources. Some exam­ples of this sense of the term include Yahoo, MSN, and a well-developed intranet.
To a busi­ness, a por­tal is a bounded vehi­cle for aggre­gat­ing infor­ma­tion and tools to address diverse con­stituent needs in a coör­di­nated and coher­ent way, with low­ered man­age­ment and admin­is­tra­tion costs real­ized via frame­work fea­tures like per­son­al­iza­tion, cus­tomiza­tion, and role-based con­fig­u­ra­tion.
One case where all three of these frames of ref­er­ence inter­sect is with Exec­u­tive Dash­board projects. A dash­board is a por­tal in all three of these senses (unless it hap­pens to rest on a dif­fer­ent archi­tec­ture / tech­nol­ogy stack, in which case I main­tain that it’s some­thing else, so as an IA it’s pru­dent to keep in mind the dif­fer­ing impli­ca­tions and assump­tions asso­ci­ated with each per­spec­tive while deal­ing with their representatives.

1 comment » | Building Blocks, Dashboards & Portals, Information Architecture

Executive Dashboards Poster From The IA Summit

March 11th, 2005 — 5:16pm

Thanks to all who stopped by to ask ques­tions and express inter­est in some of the con­cepts cen­tral to exec­u­tive dash­boards, por­tals, or to sim­ply say hello dur­ing the poster ses­sion at the IA Sum­mit in Mon­tréal. Many of you took cards, and I look for­ward to hear­ing from you soon. Based on the level of inter­est, I’m talk­ing with the good peo­ple at Boxes and Arrows about how to share some of this expe­ri­ence and these ideas in more depth. Stay tuned.
Mean­while, until the sum­mit site offers a full set of pre­sen­ter mate­ri­als, you can find the.pdf ver­sion (it’s a lar­gish ~6MB) here.
The pubished descrip­tion of the poster is below:
Exec­u­tive Dash­boards: Sim­ple IA Build­ing Blocks Sup­port A Suite of Sophis­ti­cated Por­tals
This poster depicts how a small set of stan­dard­ized Infor­ma­tion Archi­tec­ture struc­tures and ele­ments was used to cre­ate an effec­tive suite of inter­con­nected Exec­u­tive Dash­boards at low cost and with­out sub­stan­tial redesign effort.
This suite of dash­boards meets the diverse infor­ma­tion needs of senior deci­sion mak­ers work­ing within many dif­fer­ent busi­ness units in a global phar­ma­ceu­ti­cal com­pany. These dash­boards incor­po­rate a wide vari­ety of data types and func­tion­al­ity, but present every­thing within a con­sis­tent and usable User Expe­ri­ence by employ­ing mod­u­lar tiles and nav­i­ga­tion struc­tures.
This set of mod­u­lar tiles and nav­i­ga­tion struc­tures met the diverse infor­ma­tion needs of senior deci­sion mak­ers oper­at­ing within sev­eral dif­fer­ent busi­ness units.
The poster shows how the basic IA com­po­nent or ‘atom’ of a tile or port­let, with a stan­dard struc­ture, ele­ments, and label­ing can con­tain a tremen­dous vari­ety of con­tent types. The con­tent types include qual­i­ta­tive and quan­ti­ta­tive visual and tex­tual data dis­plays, as well as com­plex func­tion­al­ity syn­di­cated from other enter­prise appli­ca­tions. It also shows how tiles are eas­ily com­bined with other tiles or portlets to cre­ate larger scale and more sophis­ti­cated struc­tures that are still easy for users to com­pre­hend, allow­ing them to syn­the­size and com­pare for­merly siloed infor­ma­tion views to guide strate­gic deci­sions.
The poster shows how sim­ple infor­ma­tion archi­tec­ture com­po­nents com­mon to all the dash­boards allow rapid access to a tremen­dous amount of infor­ma­tion, from many sources. The poster shows how this IA frame­work scaled well and responded to chang­ing busi­ness needs over time, allow­ing the addi­tion of large num­bers of new tiles, views, and types of infor­ma­tion to exist­ing Dash­boards with­out sub­stan­tial redesign or cost.
The poster demon­strates how a set of IA com­po­nents allows design­ers to present crit­i­cal busi­ness infor­ma­tion by oper­at­ing unit, geog­ra­phy, topic, or spe­cific busi­ness met­ric, at vary­ing lev­els of detail, based on the needs of spe­cific audi­ences.
The poster shows how this set of IA com­po­nents allowed numer­ous design teams to inno­vate within a frame­work, thus cre­at­ing an exten­sive library of reusable tiles and views avail­able for syn­di­ca­tion through­out the suite of Exec­u­tive Dash­boards.
The end result of this approach to solv­ing diverse design prob­lems is a series of well inte­grated User Expe­ri­ences offer­ing sub­stan­tial busi­ness value to a wide audi­ence of users.

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

Back to top