Any good examples of "mixed" IA structures?

13 Jun 2009 - 7:03am
5 years ago
3 replies
903 reads
DrWex
2006

I'm trying to design the IA for an application that has strong
elements of two different organizational patterns.

Looked at in one way the information very much resembles a directory
or phone book (primary use cases are things like "find the phone
number of $NAMED ORGANIZATION").

Looked at another way the information very much resembles a net- or
tree-like hierarchy (example case "find the company for which $NAMED
PERSON is the sales representative). Unfortunately, about 30% of the
data elements do not fit into the hierarchy. They'd be a very large
group of "others".

Preliminary interviews with users shows about a 50-50 split between
the two types of use cases, with no strong bias I can find. The users
are demand-driven, responding to unpredictable requests from other
people so they can't control ahead of time what requests or even what
types of requests they get.

I don't think I want to create two screens for the same person, nor do
I want to make things strongly modal. (But maybe I'm wrong about
that?)

I'm looking for any good examples of cases where people have blended
these two types of organizational schemes.

TIA,
--Alan

Comments

13 Jun 2009 - 11:59pm
DampeS8N
2008

Maybe I'm just not following. I don't see two use cases here. I see
two pre-existing interfaces that don't support the use cases that do
exist.

I realize it isn't always an option to go in a completely new
direction. Ok. I realize it is almost never an option. But perhaps
what you really need is not a blending of these two interfaces, but a
third one that actually does what the users need.

Retain the old ones, but offer cross connections that let them
naturally fall into the more useful method.

The questions you posed don't require anything like what you've
suggested. Both are exacting questions with one answer. For the
first, it would be a phone number. For the second, it would be a
company name.

What this suggests to me is a multi-field search. One of the more
nifty ways I've seen this done recently is through AJAX. Each field
is searched with a separate AJAX call. Some will come back quickly,
others more slowly. In your case, you would throw out searches that
come back empty and show the 'hopefully' one that came back with
information. And if more than one comes back, you'd need some way to
let the user pick which one they meant.

Wolfram Alpha works a lot like this.

Your examples would be searched like so:

"find the phone number of $NAMED ORGANIZATION"
- $NAMED ORGANIZATION
Which would return entries for said organization, most likely
including their phone number

"find the company for which $NAMED PERSON is the sales
representative"
- $NAMED PERSON
Which would bring back all of the records associated with that
person. Which should include where they work as a sales rep.

Along with many other use cases. Such as finding information on a
phone number, an address, or any other fields you'd like to expose
the same way in your system.

Including more complicated sets of data not contained in a single
table.

I'm basing this on the assumption that search isn't already a
paradigm for you because your tables would search too slowly. With
AJAX, your users will wait longer because there is the illusion of
feed back. And, if broken into parts, you won't have to wait for all
30 fields to be checked. The quick ones will come back first and give
the user rich feedback that holds them over even when some queries
take over a min. As is the case with some things in Wolfram Alpha.

Anyway. I could have completely missed your point also.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=42794

14 Jun 2009 - 6:42am
DrWex
2006

Thank you for the response. I probably did make the cases too narrow.
Currently the existing interface is an Access DB bit of hackery that
lacks several features. For example, it requires the user to search
on a particular type of field (company name vs contact name) that
exposes the internal structure of the storage.

Whatever we do I'm going to push the developers to add a full-text
index and a generalized search capability. But my observations of the
users indicates that not having the contextual structure for their
answers is frustrating them.

For example, we may have a contact in the DB named "John Jones". That
may be one of several John Jones. In order to find the right one, the
users need to know that one of the John Joneses is the CEO of Jones
Company. In tests with paper prototypes so far, people have indicated
a preference for presentation of some of the results in a hierarchical
context. But just blanket applying a tree structure to something where
30-40% of the data is a single node with no parent or child seems
inappropriate.

So I'm trying to mix my apples and oranges and come up with some kind
of fruit salad (if you'll excuse the stretched metaphor).

Best,
--Alan

14 Jun 2009 - 11:37am
DampeS8N
2008

Well. It looks more to me like you are mixing apples and oranges to try to
make something that tastes like a pear.
You've already hit on your problem. The software mirrors the internals of
the system. Users have trouble with that because they don't think in
databases.
In the search field they would type "Jones Company" and "John Jones", in or
out of quotes. And your software would float the John Jones that works at
Jones Company to the top of the results. Followed by Jones Company, because
it was the only result for the company search. Followed by the rest of the
John Joneses you've found.

I still don't see a need for nodes and trees.

The data you've described doesn't logically fit into such a structure. A
person isn't a node, or a branch on a tree. They are a person, who works at
X doing Y, with personal information Z. And X is a company that has
employees A-Z and details 1-10.

It would help to know what exactly this tool is used for. Because it seems
simply like a means for looking up information about people and companies.
Is there more too it? What is the most complicated result users will need?

Will

----- Original Message -----
From: "Alan Wexelblat" <awexelblat at gmail.com>
To: "William Brall" <dampee at earthlink.net>
Cc: <discuss at ixda.org>
Sent: Sunday, June 14, 2009 7:42 AM
Subject: Re: [IxDA Discuss] Any good examples of "mixed" IA structures?

> Thank you for the response. I probably did make the cases too narrow.
> Currently the existing interface is an Access DB bit of hackery that
> lacks several features. For example, it requires the user to search
> on a particular type of field (company name vs contact name) that
> exposes the internal structure of the storage.
>
> Whatever we do I'm going to push the developers to add a full-text
> index and a generalized search capability. But my observations of the
> users indicates that not having the contextual structure for their
> answers is frustrating them.
>
> For example, we may have a contact in the DB named "John Jones". That
> may be one of several John Jones. In order to find the right one, the
> users need to know that one of the John Joneses is the CEO of Jones
> Company. In tests with paper prototypes so far, people have indicated
> a preference for presentation of some of the results in a hierarchical
> context. But just blanket applying a tree structure to something where
> 30-40% of the data is a single node with no parent or child seems
> inappropriate.
>
> So I'm trying to mix my apples and oranges and come up with some kind
> of fruit salad (if you'll excuse the stretched metaphor).
>
> Best,
> --Alan

Syndicate content Get the feed