An ongoing difficulty in design discussions is finding reliable/agreeable words to describe or identify key concepts. Whatever label we choose for an idea may have different connotations for different people. The term ‘Information Architecture Space’ (or ‘IA Space’) is certainly subject to varied interpretations so I want to take some time here to describe what I’m referring to more fully.
What is IA Space?
Behind the label ‘IA Space’ there is a fairly simple idea: a web site is a virtual ‘space’ that is made up of specific URLs. As with good architecture, the various locations within this space have specific purposes. The purposes or intents are either oriented around the ‘business’ goals (for the front end) or the administrative tasks (for the back end).
I believe the business end of a web site (the public front end) can be envisioned and planned to a significant degree by the client (the business owner). They may express this as a set of goals for the site or even as a napkin sketch of the IA as they see it. I’m not saying their vision is faultless but simply that they often can picture something in their mind’s eye and they can speak about it in terms of their business goals.
I think it’s important to note that clients often tend to approach web site production this way - from the outside-in. I’ve also noticed that some clients seem to regard a web site as purely the thing that they see on the screen and exhibit almost no understanding of any aspects that are ‘behind’ the screen.
I think we have evidence of this screen-oriented perspective in the recent user testing done at Google where users seemed to resonate strongly with the things that ostensibly would produce immediate, visible results. At Myplanet we’re currently doing an examination of these videos from that point of view to test this theory. We’ll present those findings later on but, for now, here are some excerpts…
Interpreting User Feedback
User 1 on Task 3: Create an article about your subject, tag this content with relevant keywords. (introduction to taxonomy and tagging)
Quote: “There’s no tab called ‘Our Songs’ but there is a page named ‘Our Songs’ and it’s not in this left nav which I expected it to show up in.”
Interpretation: The user is trying to build the site from the visible elements. He seems unaware that the menu on the side is a developer menu. He seems to assume it would be the menu that an end user would see.
Quote: “I assume this ‘add content’ link means add a link to the navigation and not the content itself.”
Interpretation: He speculates that the side menu link ‘Add content’ will take you to an editor for the menu itself. He appears to be thinking about building a menu directly on screen – in the same way that one might draw it in a design sketch.
User 2 on Task 1: Orient yourself. (get them comfortable at first with exploring)
Quote: “If you click on this it will open up and you’ll see different kinds of options for what you want on the page”
Interpretation: He seems to want things to appear in the space that he is working in. This is a direct approach, rather than an abstracted approach, to content building.
Quote: “Menu bar looks like some of the bigger level functions. What do you want it to look like? The theme. People to include, to give access to. Pretty much all the other background as far as customizing the data to actually look a certain way.”
Interpretation: Despite the wide variety of functional areas in the top admin menu bar, the user seems to resonate almost exclusively with the concept of making the site ‘look a certain way’. Again, this is a direct, rather than abstract, approach to site building. When guessing the meanings of the admin menu items, he speaks only when he mouses over ‘Appearance’ and ‘People’ – arguably, the least abstract and most tangible things in that set.
User 2 on Task 2: Put up some background information for your site. (see if they can add a page)
Quote: “I’m trying to think of what to call it.”
Interpretation: He is referring to the content item for his ‘basic page’. He knows he wants a page. He doesn’t necessarily know what is on the page. There are many ways to interpret the word ‘basic’. The term ‘basic page’ may have been construed as ‘first steps’ or ‘starting point for me to get going on this web site project’.
Outside-In Site Building
It’s as if non-technical users, when tasked with building a web site, seem inclined to ‘mould’ the web site into existence by modifying the visible aspects of it that they find on screen. This is quite opposite to Drupal’s current administrative techniques for building sites which involve abstractions (such as nodes, views, modules, etc.) that require overcoming a substantial learning curve. But the tendency, I believe, is to try to directly manipulate the tangible elements as they are found (or looked for) on screen as if it were some sort of putty. This is an outside-in approach. This is the pull model.
A pull model, to me, is simply about creating that ‘tangible’ space first by defining the URLs that identify all the intended pages. This placeholder structure is the space that we pull content into. The mechanism that facilitates this pulling would, I assume, be a Layout Manager.
A Layout Manager allows those business intents to be realized by assigning appropriate content retrievers (i.e. smart blocks) for each business-oriented context to each identified URL. In relatively complex sites this may involve usage of views and other sophisticated components. In a simple site it may be just dropping a node into each location.
Somewhere prior to that, the IA Space locations (URLs) need to be defined. I see that as coming from a Page Manager interface. Perhaps this is the same component as the Layout Manager. Secretly, I’d call that interface an IA Space Manager but I don’t think that’s the terminology we want to use in an end user UI.
Note: Being based on the Panels/Page Manager model the D8 Layout Manager will presumably be creating a highly spatial model of the site. With such a spatial model in place, there could be an entirely new basis for providing UIs for various back end administrative Roles. I’ll talk about this more in a later post.
Building Intentional Sites
In all the sites I’ve ever worked on, the ability to conceptualize the purpose of the site can be established through early discussion with the client and can happen long before we ever see real content. For example the business owner, or someone acting on their behalf, can describe to a site builder that they want an introduction to their organization on page X, some sort of product browsing on page Y, a checkout on page Z, etc.
In current site building processes on Drupal, producing any tangible evidence of such a structure requires a lot of back end work with very abstract mechanisms. The client has to wait it out and hope we get it right. The poor non-technical user who is trying to build their own site is dashed against even sharper rocks. It can be a frightening experience. In the meantime, Wordpress sails through on the small scale web site front with their stupendously easy-to-use site building interfaces.
But of course what we have that Wordpress and so many other platforms don’t have is amazing power and flexibility. We have to find the UX that allows our site builder users to bend it to their will – to match the business intentions. How about an interface that allows direct manipulation of tangible, easy-to-understand parts? How about a UX that is shaped around the screen oriented mindsets that we seem to see in the Google user tests?
Isn’t this what we lust for when we think of in-line/in-place editing? Isn’t that where Drupal has to seriously catch up with commercial products? My view is that this is achievable if we begin by recognizing the power of a site building process that allows creation of a container space that matches the business intentions, before the creation of actual content, before the mention of nodes, even before the consideration of content types. That is the IA Space hypothesis.