CivicActions' Owen Barton talked about the relationship between Information Architecture (IA) and Drupal Architecture, specifically how to go from the IA to Drupal. He went through how he goes through this, and how it works into wider processes.

He really dislikes the word "architecture" when it comes to information technology, b/c it brings to mind overpriced consultants full of BS.

There are lots of overlapping requirements,
and it answers these questions of:
* How does it met my requirements?
* What are my users' requirements?
* And how does it make it easy to find and do things?
* And how do you make a site that grabs your attention and makes you want to come back to it, that it's so easy to use?

Some of the inputs to IA are:
* The business requirements -- not necessarily for profit, but what is it going to do for your organization. What is the reason for why you have a website? And why is that important?
* It looks at the audiences, and the needs of the audiences in the form of User Stories: This Group X likes to do or needs to do Y.
* What content will be on the site -- content, and how is it organized and structured for the users
* What type of things do the users do on the site, and what are the key things they'll be able to do -- clicking on buttons and filing in forms
* User-cetnered design, User experience (UX) and usability -- they all relate to each and have their differences

What is the Value of IA?
* Make mistakes early and often -- NOT at the end when you deliver the site to the client, and the more you do that, it's easier to figure out the website that you're trying to build. And it usually deviates from the RFP. Get in on the iterative cycle of deciding what to do and how to do it should be done really early on. Really get that clear, and iterate towards some concrete plans. Even iterating, things will always change, but hopefully it'll change less and in more manageable ways.

* Users are important, because they're the one who will be using the site. Organize around their internal organization.
* Business needs
* Good organization of information, which usually meant strict hierarchy, but now means cross-functional categories that are more layered like tagging so to give multiple paths to the information
* Make usable interfaces, which is the hardest part and takes lots of time and lots of hours to figure out

What are the outcomes?
Depends on the project and when they come about, but there are four common outputs

1.) A site map, high-level structure

2.) Content matrix or listing -- not really a standardized way of doing this -- What do we have? And what do we have to store? It's a chance to look at approval process to see how to make it better. Content examples are important thing to have, and to also test the average length of the teaser for theming purposes, etc

3.) Cross-cutting content structures -- tagging, metadata and things that can be shared across the content to help link and relate content together.

4.) Wireframes -- This is really to nail down whether it's the site that the clients are thinking of. It involves bringing together page elements into a cohesive experience. There are different ways to doing them, some people skip wireframes and start prototyping their site in Drupal. But with a lot of clients, wireframes are easy to iterate quickly. It's basically a simplified map of how a page looks -- like where the regions and content are, but doesn't usually show any colors or theming. It shows the spatial relationship between content on a page, which is useful to make sure the site looks like for the way the client and the users. Wireframes are also useful for a designer, which hugely speeds up the design process. A lot of times the layout needs changing because some info isn't as important, and it should be quick and easy to change. Before it got popular, IA was still happening, it was happening with the visual designers. Most people will at least sketch what will go where to document it more and to make it a more complete entity.

Let's look at some examples.

Simplest type of wireframe is a MS Word wireframe, which is a good tool that the client is able to mock something on their own, especially when they don't have enough money.

Now showing a wireframe for a client, which is a lot more detailed. It was refined through client consultation, and provides a better tool for engineers. [Pointing out the different elements and regions and spatial relationship, page layout, where the content appears, how it's formatted, etc]

It's useful to say that there is an image that will go here on the page -- even though they don't even show the pages.

[Showing the final site] You can see that a lot of the wireframe layout made it to the final site.

Another example that often comes before the wireframe is the Sitemap, and most IA people have a detailed style with numbers pointing to certain items, which stay consistent between the sitemap and the wireframes. You don't have to draw a hierarchical tree, but a simple bulleted list is often good enough, but the org chart style is good if there are a lot of deep links.

QUESTION: Is the "Upload" is bumped up into the primary navigation sitemap for the Witness Hub human rights video sharing site?
Yeah, it was actually bumped up into the header, and they wanted to visually separate it out since the site revolved around user submissions.

Not going to wireframe every page, but just the ones are most important to users, or the ones that will be visited the most often.

One of the advantages of doing sitemaps and wireframes because you don't want to have too large of a variation of different layouts. It keeps your site simple and in control, which makes it a lot easier for the designers.

[Showing another example of Hub / Home]
Gives some more annotations of what different aspects of the site to give more context and meaning.

[Showing wireframe of a Hub video page, and then the final site] You can see that there weren't a lot of huge changes.

[Showing an example of a content map excel spreadsheet]
Showing a content matrix, which is created outside the context of Drupal. It collects what type of information they need to store, and then you start with that and things will change. The Y-axis rows are content types, and the X-axis columns are the various displayed fields for each content type.

Content Types:
* User registration
* Newsletter signup
* Board profile
* Staff profile
* Member profile
* Press release
* Events

Content Fields Fields
* owner
* author
* access
* section
* field 1 -- different for each content type, CCK field
* field 2
* field 3
* field 4

Other excel spreadsheet tabs
* Start to map out the content to content types
* Content Buckets, figure out some type of categorization. They came up with 60 different categories that they thought were useful. These were then split up into what is a tag, vocabulary or CCK groupings
* User Roles: Permissions matrix
* Site actions

It is usually better to do the content matrix before you look at the wireframes. Look at the previous content that they have on their website, and then look at what type of structure is there. And how does it relate to the other content?

It's usually better to go overboard and add as much structure as you can at the content matrix stage, and then not implement it all and weed out the non-critical stuff. Better to overthink than underthink at this stage.

Now What? We have some idea of what the UX should be and what the user might see on the site, where they might click, and some structure to make the content findability. And then we have the wireframes and sitemap. How do we start to map this to Drupal?

Step 1.) Worst thing you can do is work with an IA person who doesn't know Drupal, and put them in the room with a client for a month. You'll end up with wireframes that require a lot of custom code, and the client will get attached to various different usability customizations. So be sure that either the IA knows Drupal as at least a user or someone who is familiar with Drupal reviews the IA and helps meld it into the Drupal way. So this will help keep you within your allotted budget and time.

Step 2.) Keep IA focused on what is critical for the launch. There's no point on getting the Flickr-clone enterprise site that has every single desired feature rolled into one huge site -- you wouldn't want to do it all on once. Focus on the core business needs and the core needs of the users, and roll these features out for the launch. You can be sure to document all of the crazy features that won't make it into the first iteration so that you can launch those on different phases.

Step 3.) Map -- Connect this thing in the wireframes to how it's implemented in Drupal

Step 4.) Reduce -- Determine what is out of budget, and talk to the client to determine what makes sense and what doesn't.

Step 5.) Prototype -- Go out and build it.

Breaking it down.

In terms of a strategy for structuring content and presenting it to the user, here's four tips for mapping the IA and content:

1.) Managed Navigation
Set up bits of the menu by the site admin, who would determine whether the path should be linked to a more complex view or panels page. They can change later on, but that would need some planning to change.
The Drupal core menu.module is a lot of how this is approached, but don't think about it in an abstract sense, but look at the site map and the specific pages. Also determine whether it is organized by the content type or taxonomy, a menu, or a views listing of something. It helps you start to build up how the site would be wired together from a pretty low-level. The most important thing to think about are the URL path structures, and where are the path arguments being passed into a view, panel or into custom Drupal code.
You can build a lot of the site using URL path structures, otherwise you end up with a lot of views and a lot of panels, and it gets hard to manage and gets harder to export them into code. It's useful to think about the URL paths, and what specific information are going into the listings on the sites.

2.) User-driven categorization and metadata
This generally evolves and changes at a rapid rate, and have larger number of elements to consider:
* Taxonomy -- There's something very dynamic about these
* CCK -- Can add metadata to a content type or a specific type of nodes by adding arbitrary fields. You can add multiple ones and share ones between different content types. You can actually use CCK in your filtering and your organization of your content. It's usually used for storing structured data, but can also be used in views or in listing pages. There can be a multi-select in a text field, and there are lots of ways to use this info to structure your content.
* Node Reference -- It's different than how regular CCK fields are used. It's usually used as something similar to a taxonomy listing, but can be used a listing that has more information about a term. For example, with node reference, you can reference another node, and when you click on the link you will go to the node page, which can point to a more sophisticated views listing that has the same node reference. Whereas clicking on taxonomy term, it'll go to the example.com/taxonomy/term/123, but with node reference, it'll go to example.com/node/456 where 456 is the node reference that can be aliases to a view.
* Organic Groups -- There is a specific group, where you have permissions to post data, and more controlled access. So it's a content organization system for clustering meaning.

QUESTION: What about Book and child parent relationships and structures fit into it?
Some people use book really intensely, but with Drupal 5, he's used views for structuring the content a lot more. But if every page is a node, then book really works well, and it may have gotten better and more flexible in Drupal 6.

QUESTION: How do you talk to customers about these terms?
If you're talking to people who have built with Drupal before, then you can use these terms. But if you're talking to new clients, you probably wouldn't go into too much detail or Drupal jargon unless you absolutely had to.

3.) Displaying enhancing listing
This is ways for users to find content using user-driven categorization and metadata
Tools:
* Views
* Custom code

Look out in the wireframes for listings of content, and then that's probably going to be a view. Then ask how is it organized and categorized. Sort order usually isn't that obvious, and so you have to determine that. And there may not be a field that exists that can be sorted on, and so this is a good way to discover new fields that you need to create.

4.) Managing page layout
Ways of managing where on the page different navigational elements, listing and functional elements should go onto the page
Tools:
* Blocks/regions -- very simple, and less code to break
* Panels -- if you're building something more complicated, then using panels may simplify that a lot. Especially if content only appears in specific content types. Otherwise you'll end up with a lot of complicated PHP rules in your blocks.
* Theming -- You can have multiple-page layouts in your theme. You can have a node that dynamically pulls in content via a node reference.

[Looking at Just Cause site: http://justcauseit.com/]
Uses organic groups quite intensively, and uses the menu system and arguments
They're using Panels for the front page layout.
The Featured Articles view has some custom code, wrote a new views handler because the featured story has a larger picture and a longer teaser than the other listing items.
View with sorting order using nodqueue.
A lot of the page is theming, a two-column view down at the bottom.
Have to think about how you're going to execute it in Drupal: Is it a view? Or is it a panel?
Need on the user profile a way to display the real name of the user, and then you have to have a way to store and map the fields to the site.

[Looking at http://justcauseit.com/channels/civic]
Pay attention to the URL paths from the primary and secondary links. When you click on causes from the Home page vs. the Civic tab, then you're actually drilling down to different sections.
In an ideal world, the URL would be justcauseit.com/civic/causes, but going to just civic wouldn't.
Both panels and views need to have a home path element -- unless they're on the homepage. So you need to have the /PANELNAME or /VIEWNAME and that simplifies that a lot. And then it's easier to pass in the taxonomy term and content type in from there.

[Note: Time was up, and the final 10 slides were covered quickly in 5 minutes. The slides will be posted on the Drupalcon website.]

http://boston2008.drupalcon.org/session/information-architecture-drupal-...

Try to group together all of the similar function modules, and go through which is the best fit.

Think outside of the box, and check out all of the existing modules.
Abstract new functionality with what can be used and leveraged by other modules
"Phase 2" is a way to prioritize the fucntionality with your client

Always go with the simplest way if you can, and in a way that fits in with the rest of the site as well.

Figure out the best way for maintaining simplicity, consistency, upgradibility, and flexibility.

Be sure to document that plan with annotation and prototyping.

Think about your design process: waterfall vs. agile. Prototype the site first, and then do more IA as you go.

Risks: Be aware of clients with no clear business requirements.

IAs need to learn Drupal, IAs don't exist in a vacuum.

The slides should be posted here soon.