Information-Architecture (IA)

Vielleicht ist diese Argumentation ja mal für jemanden nützlich:

Portraitseiten von Mitarbeitenden sind im Forschungskontext zentral für eine Hochschule, denn meist kennen (und suchen) andere Menschen primär Mitarbeitende und nicht pauschal die Hochschule. Es ist somit sinnvoll, wenn die Profilseiten der Mitarbeitenden einer Hochschule rasch und einfach abgerufen werden können.

Profilseiten von Mitarbeitenden werden aber nicht nur via Suchmaschine oder per Verlinkung von anderen Webseiten aufgerufen. Oft werden solche Links auch manuell kommuniziert und eingetippt.

Drei Begründungen für kurze URLs ohne technischen Ballast:

  • Cognitive Load: Wenn ich jemandem im Gespräch sagen will, wie die URL einer Portrait-Seite lautet, dann will ich sagen können: hochschule.tld/vorname-nachname. Sonst muss ich nämlich auswendig wissen, ob es /person/, /personen/, /people/ oder sonstwie heisst.
  • Platzbedarf: Portrait-URLs stehen mitunter auf Folien und oder Berichten. Kurze URLS benötigen weniger Platz und machen weniger Probleme beim Umbruch.
  • Tippaufwand / Vertippgefahr: Wenn solche URLs auf Folien stehen, werden sie abgetippt. Auch hier sind kurze URLS wünschenswert.

Seit Dezember 2005 gibt es an der ETH Zürich einen Lehrstuhl für information architecture (Biblionetz:w01789), der durch Gerhard Schmitt (Biblionetz:p00803) geleitet wird. Erster und bisher einziger Mitarbeiter ist Remo Burkhard (Biblionetz:p03042).

Science-City-E-ZH_Mag1_600.jpg

Es lohnt sich sicher, die Aktivitäten dieses Lehrstuhls zu beobachten..

Neues Webportal Educatech

28 August 2006 | Beat Döbeli Honegger | Information-Architecture (IA)

Gestern habe ich die zweite Auflage des Buchs Don't make me think (Biblionetz:b00718) von Steve Krug gelesen. Nichts aufregend neues, aber immer noch empfehlenswerte Lektüre für Neueinsteiger, die einen Webauftritt planen oder umsetzen müssen.

Heute lese ich nun die Ankündigung von http://www.educatech.ch und besuche die Site:

Meinem Biblionetz droht Ungemach, bzw. mir Arbeit: Der kommende Firefox 1.5 und der bereits verfügbare Opera 8.5 (siehe auch OperaKostenlos) interpretieren SVG-Objekte in HTML-Seiten als Frames. Links in den SVG-Objekten werden auf den Frame bezogen, sprich beim Klicken auf einen Link im SVG-Objekt wird das Ziel im Frame geöffnet. Das SVG-Plugin von Adobe macht dies anders (ich liebe Standards...), dort wird ein angeklickter Link im gesamten Fenster geöffnet.

Ich habe noch nicht herausgefunden, wie ich den Target der Links in SVG-Objekten auf "_top" setzen kann. Entsprechende Hinweise nehme ich dankend entgegen.

Solange ich für dieses Problem keine Lösung gefunden habe, ist das Biblionetz mit Opera 8.5 (weniger schlimm, weil weniger verbreitet) und mit dem kommenden Firefox 1.5 (schlimmer, weil verbreiteter) nicht vollständig nutzbar.

 
<a xlink:href="w01237.html" xlink:title="Amygdala" target="_top"> 
wird von Firefox 1.4.1 ignoriert.

 
<a xlink:href="w01237.html" xlink:title="Amygdala" xlink:target="_top">
wird von Firefox 1.4.1 ebenfalls ignoriert.

<base target="_top">
im HTML-File bringt bei Firefox 1.4.1 ebenfalls nichts.

xlink:show="new"
führt immerhin zu einem neuen Fenster beim Klicken.

grummel Update 16.5.2006: Unter http://blog.codedread.com/archives/2005/12/01/guide-to-deploying-svg-with-html/ ist das Problem ebenfalls dokumentiert, aber nicht zufriedenstellend gelöst (Javascript-Gebastel...).

,

Letzthin bin ich wieder einmal über ein webbasiertes Kooperationstool gestolpert, welches den Rest der Welt ignoriert. In diesem Tool kann man wunderschön Nachrichten an alle möglichen Usergruppen senden, seine eigenen Interessen kundtun und entsprechend Abos lösen für Informationskanäle usw. Alles sehr durchdacht und komplex aufgebaut, eine kleine, feine Welt für sich im wahrsten Sinn des Wortes. Auf das System kann nur per Web zugegriffen werden, es sind keinerlei Notify-Funktionen nach aussen vorgesehen.

Ich empfinde im 21. Jahrhundert ein Kooperationstool, das nur das Hol-Prinzip (Biblionetz:w00793) kennt, als sehr arrogant. Es geht davon aus, dass die User nur mit ihm arbeiten und beliebig Zeit haben, immer wieder untertänig anzuklopfen und nachzufragen, ob wohl neue Nachrichten eingetroffen seien. Für Leute mit mehreren Engagements sind solche Kooperationstools nicht brauchbar. Wer hat schon Zeit, regelmässig alle die Tools mit ihren unterschiedlichen user interfaces zu besuchen und die Nachrichten in x verschiedenen Systemen zu pflegen?

Liebe Kooperationstools: Höflich ist das Bring-Prinzip (Biblionetz:w00794). Ihr fragt Eure Nutzer/-innen, auf welchem Kanal sie denn gerne wie oft informiert werden möchten. Als Kommunikationskanäle bieten sich E-Mail oder RSS-Feeds an, wenn Ihr Geld habt, sogar SMS. Könntet Ihr in einer ruhigen Minute mit Euren Entwickler/-innen darüber reden? Das wäre nett.

P.S.: Falls Eure Entwickler/-innen die Notwendigkeit von Notify-funktionen nach aussen beim ersten Gespräch nicht sehen, könntet Ihr die Aufmerksamkeits-Ökonomie erwähnen, die sonst vielleicht dazu führt, dass Ihr aus dem Fokus der Aufmerksamkeit der Nutzer/-innen fallt. Das wäre ja schade.