The “information architecture” infrastructure is how we establish a common interface to data entities that are shared across multiple applications within the enterprise.

In the interactive Web environment, this is handled primarily though management of Cascading StyleSheets (CSS) tags.  We also identify and maintain the HTML Form Elements (fields, forms and buttons) which appear with regularity.

The Shared Data Entity Design Structure allows UxP to

  • manage the user experience
  • maintain design interface continuity through a central source and
  • pass workable, reusable HTML elements on to the Code Development team

Organized, self-evident

The development team can concentrate on creating usable code, rather than re-inventing the wheel.

The business team knows that business rules will be implemented with consistency.

The management stakeholders understand that we are presenting a common, branded, usable interface.

A definition of ‘architecture’ is “the complex or carefully designed structure of something”

 

Architecture and Styling Are Linked

CSS (Cascading Style Sheets) is the “semantic tagging” tool by which we identify Information Architecture.

In this example, we were working with a complex process that covered the Trading Contract process from initial record creation, through Execution, Settlement and Accounting.

IA = CSS

 

Presentation Continuity

… is displayed and maintained in the Table:

  • Form Element Label (consistent terminology)
  • Type (s.a. text field, picklist)
  • Size (s.a. Maximum # of Characters, pixel width)
  • Identifier (s.a. CSS tag name or ID)

Business Rules

… are “embedded” in the HTML elements themselves:

  • Default state (s.a pre-populating the field with appropriate data)
  • Behaviors (s.a. “To” date cannot precede “From” date)
  • Whether the field is Required
  • Support Tools (s.a. a Calendar or Picklist popup)
  • Follow-thru Actions (s.a. Adding or Deleting an item)

View the case study: Bunge Global Markets

The label “IA” has had quite a history

I believe that the term “information architect” became more surface design-y when the industry needed to proactively evolve the packaging of the product (UI, interaction design, and styling, of course).

The marriage of underlying Content to design Context has always been implicit – and ‘architect’ kind of provides the cachet. For a while there, “IA” actually meant designer.

My first job labeled “Information Architect” was in 1993 – my actual work was as an interaction designer). Organizational skills were definitely part of my toolset, but I gained skills in actual Data Modeling (ERwin) only later.

Labels & Meaning

I’ve always felt that ‘librarianship’ is an unappreciated aspect of the mix. There seems to be a lot of industry noise these days about “Content Management” and “Content Strategy” … driven, I think, by a market appreciation for under-the-hood techniques like semantics, ‘dark data’, tagging, metadata, #hashTag, etc.

As for the label itself: If you’re a “Solution Architect”. See what happens when you describe yourself as a “Content Strategist” … I find myself using “the architecture of information” as a way of describing what I do: less label / more meaning

“Organizing things” fosters Librarianship and Information Architecture, which lie at the heart of UX.

Making it Personal

The Information Architect in me agrees that the helpfully invasive bots we design are definitely part of the mix. An early-on insight for me (during the Booz Allen Hamilton project in 1981) was to realize that truly integrated and ‘responsive’ interactive systems would have to include something I called “infoTote“: the ability to maintain – and leverage – the attributes of your unique personal profile.

It was a crude insight, but fairly accurate. My concern was (and is) that the individual should own, be able to maintain – or at the very least have access to – the unique personal data about themselves.

 

© The Communication Studio LLC

Advertisements