At the North American Web Developers' Conference earlier
this month, Bebo White - the designer who built the first web server in North America - talked about the changing role of the webmaster.
Surprisingly, page design and HTML make up a small part of today's webmaster duties. And technicians
often maintain the actual computer equipment. The webmaster today spends much time describing
what a web site ought to look like, and explaining how it ought to integrate into an overall
management or marketing strategy.
So much has the job as webmaster changed, said White, that the term 'webmaster' ought to change
as well. Thus, he proposed, a more descriptive term - like 'information architect' - might be appropriate.
This is the approach the MuniMall Project took, and in
March of this year I was hired as the project's information architect. More than a webmaster,
not really an HTML hack, I entered into this new role intrigued by the possibilities but unsure
of the duties.
Well - what is an information architect?
From my own experience, I would say that the practitioners are professionals, versed in every aspect of web design,
adept communicators, and gifted visualizers - they are people who eat, sleep and dream web design
and structure. But you can't put that on the job description.
Or - as I Sing the Body Electronic author Fred Moody observes: information architects are the
sort of people who understand that the instructions on the shampoo bottle are just wrong: "Lather. Rinse. Repeat."
*
The Information Architects Mailing List defines an information architect as "an individual who organises the patterns inherent in information, structuring the systems that will define the next century." I kind of like that one.
WebWord says, "Information architecture involves the design of organization and navigation systems to help people find and manage information more successfully."
HotWired defines information architecture as "the blueprint of the site upon which all other aspects are built - form, function, metaphor, navigation and interface, interaction, and visual design." This definition also agrees with what I do.
The Wired article continues, "Information architecture is the science of figuring out what you want your site to do and then constructing a blueprint before you dive in and put the thing together." Yup.
Cnet's Shel Kiman writes, " information architecture is a combination of organizing a site's content into categories and creating an interface to support those categories." That seems a bit narrow - it's not all about categories.
All that is very nice, but what does an information architect actually do?
in·for·ma·tion (in'f?r-ma'sh?n)
n. (Abbr. inf.)
Knowledge derived from study, experience, or instruction.
Knowledge of a specific event or situation; intelligence. See Synonyms at knowledge.
A collection of facts or data: statistical information.
The act of informing or the condition of being informed; communication of knowledge: Safety instructions are provided for the information of our passengers.
Computer Science. A nonaccidental signal or character used as an input to a computer or communications system.
A numerical measure of the uncertainty of an experimental outcome.
Law. A formal accusation of a crime made by a public officer rather than by grand jury indictment.
|
ar·chi·tect (är'ki-tekt')
n.
(Abbr. arch., archt.) One who designs and supervises the construction of buildings or other large structures.
One that plans or devises: a country considered to be the chief architect of war in the Middle East.
|
Combining those definitions, we get: One who designs and supervises the construction of knowledge derived from study, experience, or instruction, or knowledge of a specific event or situation, or a collection of facts or data.
The information architect's job is to define the nature and scope of an information
service or website before the first HTML tag is committed to disk. An information
architecture is like the plan for a website, similar to an architect's
drawing.
Typically, the output from an information architect will be a report - or as I have
been calling them, a Concept Paper. This report will contain several
identifiable components.
Identify Mission and Goals
The information architect will be the person who asks the first hard question of the
day: "Well, why do you want a web site to begin with?" He or she needs to learn about
the client and about the industry, to identify those tasks and functions which would
be facilitated with a web presence, and to articulate the purpose of the web site.
The site's mission and goals do not need to be grandiose statements. But they need
to clearly ascribe a function to the site. Perhaps the purpose of the site is to market
an agency or product. Perhaps it is to distribute information. Perhaps it is intended
to collect customer feedback. Perhaps it is to stimulate dialogue.
The site mission and goals need to be re-evaluated on an ongoing basis. Each step of the
process may force a rethink in the site's purpose. In the MuniMall project, we had to consider
input from a variety of sources, and as a result, the site's purpose changed from
being an all-encompassing portal, as first conceived, to an education and research
facility, as it is
now conceived.
Identify the Client's 'Vision'
Information architect's work for a person or group of people referred to
as the 'client'. The client is rarely one person; it is not always even
one organization.
But what all clients have in common is a concept or vision of what they think
the website should look and feel like. Clients sponsoring a site for the film
industry, for example, will want a very visual and animated site. Government
agencies tend to prefer a more businesslike approach.
Where there are multiple clients, there will be multiple (and sometimes
contradictory) visions. It is not always possible to identify common elements.
In such a case, a vision must be constructed out of elements of each client's
perspective and - in a way - 'sold' to the clients.
Define the Audience
The 'audience' of a web site is the group or groups of people who will
actually use the site.
It is important to identify an audience because it will be important to
determine what people will want to do when they're on the site.
If, for example, people will visit the site daily for news and current
events, then this information must be easily accessible, and not buried
in some deep recess.
Often, there will be more than one audience. A corporate site, for example,
may be intended to serve both employees and customers. And while their
interests may overlap (they may both need product information, for example),
they will often have different interests and priorities.
Create a Content Inventory
Having established an purpose and an audience, the next step is to identify
what the site should contain.
The creation of a content inventory is often subject to practical
considerations. If it is not possible to produce the content required -
daily activity summaries, say - then such content should not be
included in the inventory.
That said, a content inventory is often a 'wish list' of what all cleints
and all customers would like to see contained in the site.
Identify the Server Environment
At this point, hard decisions need to be made about the technology which
will deliver the content. This may include the selection of a service
provider, or it may include the selection of server operating system
and software.
These decisions are driven in part by the nature of the content - rapidly
changing content will require database support, for example, while visual
content may require a streaming media server.
The choice of technology is also driven by budget considerations. While
the information architect should be involved in the drafting of the
budget, he or she almost never determines the amount of money available
for the project.
This at this point the information architect must identify the range
of possibilities within the budgeted amount, and amend the
content inventory accordingly.
Create Site Maps
The 'site map' identifies the route that potential users of the site
will travel. Key to this is the identification of which resources will
be available from the front page, and which resources will be deeper
in the site.
A variety of site organizational styles is possible; the choice or an
organizational style will depend on the purpose of the site and the
site sudiences.
For example, a site which is primarily focussed toward group discussion
should provide frequent and quick links directly into the discussion
itself. Sites which focus on presenting information should place this
information front and center.
The design of a site map also draws upon elements of
usability. Any site map should be tested against actual users in
order to identify intuitive navigational flows.
Create Content Maps
A 'content map' is a description of the site content as it might appear
to a database. Content maps should sort the data by type and identify any
properties or relationships inherent in the data.
Content maps are sent to the database guru for programming. They
also suggest links which may not be obvious in the site map. For
example, the site map may suggest paths leading to corporate staff
and corporate products; the content map (which tells you that every
product has staff, and that all staff work on products) will suggest
links between product pages and staff pages.
The content map also serves to ensure that important content is not
omitted from the site. If an item in the content inventory cannot
be placed into a classification in the content map, then the content
map (and probably the site map) must be revised to reflect this gap.
Design Page Schematics
Once different types of content are identified, the information architect
much consider how it will be displayed on a web page. Elements of
usability are again considered, as well as the nature of the content
and the nature of the audience.
Page schematics may vary from drawing to sketches to block diagrams.
They are a first run at organizing the display of information
so it is easy to read and visually pleasing.
Define Constructive Processes
At this point, the site is ready to turn over to the programmers,
writers and artists. Each of these three groups of people will have
to work within the original plan.
The information architect should create a clear set of design
parameters for each group.
Writers should be informed not only about what they will write,
but also about the writing style they should employ, the length
and division of contributions, and even the font selection
likely to be used in the final version.
Graphic Designers should be given a set of objects for design -
everything from buttons to a logo to a masthead - and also
informed of the client's preferences, the architect's vision,
and the user's needs.
The HTML programmers and other coders need to know the desired
functionality of the site. If the architect expects the page to
resize for differerent browsers, for example, this should be
documented.
A production schedule identifying completion targets and dates
should be drafted, and communication between the three groups
of people facilitated. Ongoing testing and client review should
be performed to keep the design on track.
Would you like to be an information architect? You will have to eat, beathe and sleep
internet. You will have to see everyday objects - like highway intersections,
office buildings, or coffee shops - as types of data transfer (bulky, slow and
sometimes cranky data, but still data). You will have to look at every scene you
see - from the sunset last night to the jet taking off at O'Hare to the toddler
playing in the puddle (mother in the background, anguished look on her face) -
as a design concept or information matrix.
And the world is going to need more information architects, and information
architects are going to have to think in larger and larger terms. As Shel Kiman writes,
The future is, quite literally, what we make it.
