Tag: portals

Read­ers active in the enter­prise, intranet, por­tal, and syn­di­cated con­tent & func­tion­al­ity spaces might be inter­ested in The Build­ing Blocks of Effec­tive Por­tals that appears in the Novem­ber / Decem­ber issue of Intranets Today.
Intranets is one of the lead­ing pub­li­ca­tions focused on these top­ics, with reg­u­lar con­tri­bu­tions from the likes of Rachel Alexan­der, Jane McConnell, and James Rober­ston.
You will need a log-in to read the com­plete arti­cle on-line, but per­haps you were think­ing of sub­scrib­ing, and this will pull you in.

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!

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.

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!

Boxes and Arrows just pub­lished Part 4 of the Build­ing Blocks series, Con­nec­tors for Dash­boards and Por­tals.
We’re into the home stretch of the series — just two more to go!
Stay tuned for a down­load­able toolkit to sup­port easy use of the build­ing blocks dur­ing design efforts.

Boxes and Arrows has pub­lished part 3 of the Build­ing Blocks series, describ­ing the Con­tainer blocks in detail. Next in the series is part 4, which describes the Con­nec­tors in the build­ing block sys­tem in detail.
If you’re work­ing on a por­tal, dash­board, or tile based design effort of any kind, the build­ing blocks read­ily serve as a com­mon lan­guage and struc­tural ref­er­ence point that allows effec­tive project com­mu­ni­ca­tion across tra­di­tional dis­ci­pline bound­aries. These two arti­cles in tan­dem (parts 3 and 4) pro­vide details on how the Build­ing Blocks can pro­vide a strong, flex­i­ble, and scal­able usr expe­ri­ence and infor­ma­tion archi­tec­ture frame­work for the long term.
My cur­rent plan is to release a toolkit at approx­i­mately the same time as part 4 of the series. Part 4 is in the edit­ing stage now, so this a good time to ask read­ers for sug­ges­tions on what should be part of the toolkit, and what form it should take. Suggestions?

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!

The Lessons From Fail­ure Series (curated by Chris­t­ian Crum­lish) kicked off today at Boxes and Arrows, lead­ing with my med­i­ta­tion on being an entre­pre­neur and what it means to face fail­ure as a mem­ber of a rigidly defined soci­ety, titled It Seemed Like The Thing To Do At The Time. Stay tuned for three fur­ther install­ments from tal­ented fel­low pan­elists.
Also, look for part two of my series on design­ing healthy user expe­ri­ences for por­tals using the IA Build­ing Blocks in early July. Part one — The Chal­lenge of Dash­boards and Por­tals — describ­ing the struc­tural and usabil­ity weak­nesses of flat archi­tec­tures, was pub­lished in Decem­ber.
Many thanks to the hard work­ing vol­un­teers at B+A for cre­at­ing a forum for these ideas and the com­mu­nity around them!

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

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.