Interface design — fifth and final IA Summit 2007 theme

(Here’s the fifth and final post on the 2007 IA Sum­mit. You can find the first one that intro­duces the series and describes the first theme ‘tan­gi­ble’ here, the sec­ond one on ‘social’ here, the third one on ‘web of data’ here and the fourth one on ‘strat­e­gy’ here.)

It might have been the past RIA hype (which accord­ing to Jared Spool has noth­ing to do with web 2.0) but for what­ev­er rea­son, IAs are mov­ing into inter­face ter­ri­to­ry. They’re broad­en­ing their scope to look at how their archi­tec­tures are pre­sent­ed and made usable by users. The inter­est­ing part for me is to see how a dis­ci­pline that has come from tax­onomies, the­sauri and oth­er abstract infor­ma­tion struc­tures approach­es the design of user fac­ing shells for those struc­tures. Are their designs dra­mat­i­cal­ly dif­fer­ent from those cre­at­ed by inter­face design­ers com­ing from a more visu­al domain con­cerned with sur­face? I would say: at least a little… 

I par­tic­u­lar­ly enjoyed Stephen Anderson’s pre­sen­ta­tion on adap­tive inter­faces. He gave many exam­ples of inter­faces that would change accord­ing to user behav­iour, becom­ing more elab­o­rate and explana­to­ry or very min­i­mal and suc­cinct. His main point was to start with a gener­ic inter­face that would be usable by the major­i­ty of users, and then come up with ways to adapt it to dif­fer­ent spe­cif­ic behav­iours. The way in which those adap­ta­tions were deter­mined and doc­u­ment­ed as rules remind­ed me a lot of game design.

Mar­garet Han­ley gave a sol­id talk on the “unsexy side of IA”, name­ly the design of admin­is­tra­tion inter­faces. This typ­i­cal­ly involves com­ing up with a lot of screens with many form fields and con­trols. The inter­faces she cre­at­ed allowed peo­ple to edit data that would nor­mal­ly not be acces­si­ble through a CMS but need­ed edit­ing nonethe­less (prod­uct details for a web shop, for instance). Users are accus­tomed to think­ing in terms of edit­ing pages, not edit­ing data. The trick­i­est bit is to find ways to com­mu­ni­cate how changes made to the data would prop­a­gate through a site and be shown in dif­fer­ent places. There were some inter­est­ing ideas from the audi­ence on this, but no def­i­nite solu­tion was found.