IA and Social Networks/Web 2.0 functionality

11 Jun 2008 - 10:14am
5 years ago
10 replies
835 reads
tdellaringa
2006

Good Morning,

My current project is a social network. I'm actually having some trouble
putting together a good site map because so many features seem to either
overlap, or more importantly, one page will support multiple features. There
is much less of a "page" paradigm, it's so much more the interactive
behavior of the users. For example, on Facebook's profile page, I can do so
many different things - especially if I have added any applications.

Have any of you faced this, and if so, how did you tackle site mapping? It's
not that I find the site map such a huge crucial piece of the puzzle, but
it's something our stakeholders will want to see. It's also been tricky with
the wireframing and organizing each page as well. Any tips are appreciated.

Tom

Comments

11 Jun 2008 - 10:28am
Scott McDaniel
2007

Tom,

I've been faced with this and agree it's a tough thing to tackle,
especially if more straightforward
applications and pages make up most of one's experience. I've been
largely approaching components
and behaviours as the page-level items, but this splinters quickly and
starts looking more like a user flow than
site map.

So...I look forward to further input from our fellows here.

Scott

--
(The key to joy is disobedience
There is no guilt and there is no shame) - COIL

11 Jun 2008 - 10:32am
bminihan
2007

I'm in the same situation, and have worked with enterprise portals
over the past several years, which share the same problem (lots of
things on each page, and each person can add/remove/change widgets/
pages/gadgets and whole environments if they want).

For the pre-work on our current project, I put together a concept map,
instead of a direct site-map. I divided the site into distinct
"clouds" and placed common tools into each according to roles. My
main site map gave a high-level overview and delineated all of the
"locked down" pages that help with site admin and general company
information, but when it got down to the user-interaction level, the
"clouds" illustrated which tools were available to each group, without
trying to show they were in specific pages at any given time.

The site map served well to plan the development for the project, and
helped the execs & user groups make sure we didn't forget anything in
certain areas, because they could see where their roles were in the map.

Don't know if that's what you're looking for, but hopefully it helps...

Bryan Minihan
bjminihan at nc.rr.com

On Jun 11, 2008, at 11:14 AM, Tom Dell'Aringa wrote:

> Good Morning,
>
> My current project is a social network. I'm actually having some
> trouble
> putting together a good site map because so many features seem to
> either
> overlap, or more importantly, one page will support multiple
> features. There
> is much less of a "page" paradigm, it's so much more the interactive
> behavior of the users. For example, on Facebook's profile page, I
> can do so
> many different things - especially if I have added any applications.
>
> Have any of you faced this, and if so, how did you tackle site
> mapping? It's
> not that I find the site map such a huge crucial piece of the
> puzzle, but
> it's something our stakeholders will want to see. It's also been
> tricky with
> the wireframing and organizing each page as well. Any tips are
> appreciated.
>
> Tom
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

11 Jun 2008 - 10:36am
tdellaringa
2006

On Wed, Jun 11, 2008 at 10:32 AM, Bryan Minihan <bjminihan at nc.rr.com> wrote:

> For the pre-work on our current project, I put together a concept map,
> instead of a direct site-map. I divided the site into distinct "clouds" and
> placed common tools into each according to roles. My main site map gave a
> high-level overview and delineated all of the "locked down" pages that help
> with site admin and general company information, but when it got down to the
> user-interaction level, the "clouds" illustrated which tools were available
> to each group, without trying to show they were in specific pages at any
> given time.

I've actually done that exact thing, it was the first thing I did. I have
circles around each main "idea" with satellites of functionality around
them. Lines connect things that interact.

Maybe that is a better tool, I'm not sure. When it comes down to "hard
pages" I end up with very few items on the site map. Maybe I'm seeing a
problem where there isn't one, I'm just not sure.

11 Jun 2008 - 10:43am
bminihan
2007

I approached the site-map as a "whos' going to use it" problem, so my
concept map communicated the approach and goals of the project, but
the wireframes and user navigation illustrated how each tool fit into
each separate area. Our site contains the overall sitemap in each
page's footer (a little crowded, IMHO), but the user's map is front
and center on each of their home pages (twice, actually).

I agree that the desire to illustrate where to find just about
anything is very strong, and if I had it to do over again, would have
fleshed out each user's experience a little more. Just one of those
things, I guess...I did most of the design work, with just a few other
developers on the team, so some things got pushed to the side.

One other reason for starting with the concept map - we weren't going
to have half of the functionality until some months into the project
(it's constantly evolving), so I knew I was going to have to redesign
each user's experience several times until we got to 80% of the
features we wanted. We've held off on several of those and introduced
several new ones in their place, so if I had created a master site
map, it would have been rebuilt 8 times by now =]

Bryan Minihan
bjminihan at nc.rr.com

On Jun 11, 2008, at 11:36 AM, Tom Dell'Aringa wrote:

> On Wed, Jun 11, 2008 at 10:32 AM, Bryan Minihan
> <bjminihan at nc.rr.com> wrote:
> For the pre-work on our current project, I put together a concept
> map, instead of a direct site-map. I divided the site into distinct
> "clouds" and placed common tools into each according to roles. My
> main site map gave a high-level overview and delineated all of the
> "locked down" pages that help with site admin and general company
> information, but when it got down to the user-interaction level, the
> "clouds" illustrated which tools were available to each group,
> without trying to show they were in specific pages at any given time.
>
> I've actually done that exact thing, it was the first thing I did. I
> have circles around each main "idea" with satellites of
> functionality around them. Lines connect things that interact.
>
> Maybe that is a better tool, I'm not sure. When it comes down to
> "hard pages" I end up with very few items on the site map. Maybe I'm
> seeing a problem where there isn't one, I'm just not sure.

11 Jun 2008 - 1:17pm
Karri Ojanen
2008

Hey guys,

I've been faced with this same situation too with enterprise portals
that use widgets/pages/features for different groups. Like Bryan, I
created a concept map that divided the site into different groups of
features according to roles. The wireframes then showed how the
features fit into each seperate area (by user group). The portal we
built had a relatively small amount of widgets and features, so it
was easy enough to wire everything, but obviously the bigger the
portal/site and the more flexible/modifiable the features are, the
more demanding it gets to wire them properly.

Karri Ojanen
karri dot ojanen at publicis.ca

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

11 Jun 2008 - 1:27pm
bminihan
2007

You just reminded me of the extra difficulty we had at my last
company. We allowed open gadget development, and had a whole suite of
"content server" gadgets that people could customized however they saw
fit. All told, we had over 9000 widgets in the portal, about 1/3rd of
which were "standard". No two pages were alike, and we even had 12
different "home pages" for different business units and countries.
Every attempt we made to catalog the entire portal wound up with a
taxonomy 20 pages long.

Good luck =]

Bryan Minihan
bjminihan at nc.rr.com

On Jun 11, 2008, at 11:17 AM, Karri Ojanen wrote:

> Hey guys,
>
> I've been faced with this same situation too with enterprise portals
> that use widgets/pages/features for different groups. Like Bryan, I
> created a concept map that divided the site into different groups of
> features according to roles. The wireframes then showed how the
> features fit into each seperate area (by user group). The portal we
> built had a relatively small amount of widgets and features, so it
> was easy enough to wire everything, but obviously the bigger the
> portal/site and the more flexible/modifiable the features are, the
> more demanding it gets to wire them properly.
>
> Karri Ojanen
> karri dot ojanen at publicis.ca
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=30139
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

11 Jun 2008 - 1:44pm
Dante Murphy
2006

Tom-
Our solution is to create a "statemap" instead of a sitemap, and catalog
the various relevant states of each module or behavior. So if you have
a "poke someone" module, you describe how it behaves independent of any
surrounding content that does not impact that module's behavior or
presentation.

You can also use abstraction to simplify contextual relationships; for
instance, suppose that you can "poke" someone and also include a piece
of content from the page that you "poked" them from. That abstraction
("piece of content") simplifies the description to include an article,
link, widget, vCard, or whatever.

Is this something that a lot of people are challenged with? If so, I
might be able to put together a "statemapping" presentation online. Let
me know if you all would be interested in such a thing.

Dante

Dante Murphy | Director of User Experience| D I G I T A S H E A L T H
229 South 18th Street | Rittenhouse Square | Philadelphia, PA 19103 |
USA
Email: dmurphy at digitashealth.com
www.digitashealth.com

11 Jun 2008 - 1:46pm
tdellaringa
2006

I would definitely be interested in taking a look, if you wouldn't mind
putting it together.

Tom

On Wed, Jun 11, 2008 at 1:44 PM, Dante Murphy <dmurphy at digitashealth.com>
wrote:

> Tom-
> Our solution is to create a "statemap" instead of a sitemap...
>
> Is this something that a lot of people are challenged with? If so, I
> might be able to put together a "statemapping" presentation online. Let
> me know if you all would be interested in such a thing.

11 Jun 2008 - 1:48pm
bminihan
2007

Same here, would love to see how you've tackled this...

Bryan Minihan
bjminihan at nc.rr.com

On Jun 11, 2008, at 2:44 PM, Dante Murphy wrote:

> Tom-
> Our solution is to create a "statemap" instead of a sitemap, and
> catalog
> the various relevant states of each module or behavior. So if you
> have
> a "poke someone" module, you describe how it behaves independent of
> any
> surrounding content that does not impact that module's behavior or
> presentation.
>
> You can also use abstraction to simplify contextual relationships; for
> instance, suppose that you can "poke" someone and also include a piece
> of content from the page that you "poked" them from. That abstraction
> ("piece of content") simplifies the description to include an article,
> link, widget, vCard, or whatever.
>
> Is this something that a lot of people are challenged with? If so, I
> might be able to put together a "statemapping" presentation online.
> Let
> me know if you all would be interested in such a thing.
>
> Dante
>
> Dante Murphy | Director of User Experience| D I G I T A S H E A L T H
> 229 South 18th Street | Rittenhouse Square | Philadelphia, PA 19103 |
> USA
> Email: dmurphy at digitashealth.com
> www.digitashealth.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

11 Jun 2008 - 11:19am
Santiago Bustelo
2010

Social network websites are web applications, rather than web sites.
In a web site, users browse to access contents. In a web application,
users perform tasks to access application states.

Stakeholders and people involved in the design, development and
documentation of a web application, need to freely access the
different states of the application, without actually performing the
tasks that drive the application to that particular state.
For these actors, a flow chart of the tasks/functions, with links to
the "pages" of the web application, would be appropiate. A way to
quickly reveal what "pages" are shared by different functions (page
names, color coding) needs to be thought out.

End users cannot freely "navigate" the application to a particular
state without performing required tasks. Therefore, web applications -
as desktop applications- don't usually offer a site map. What end
users need and can use, is a well-written help section answering what
steps are required to perform their goals. Copywriters can use the
flow chart as a reference to develop that documentation.

--
Santiago Bustelo // icograma
Buenos Aires, Argentina

On 11/06/2008, at 12:14, Tom Dell'Aringa wrote:

> Good Morning,
>
> My current project is a social network. I'm actually having some
> trouble
> putting together a good site map because so many features seem to
> either
> overlap, or more importantly, one page will support multiple
> features. There
> is much less of a "page" paradigm, it's so much more the interactive
> behavior of the users. For example, on Facebook's profile page, I
> can do so
> many different things - especially if I have added any applications.
>
> Have any of you faced this, and if so, how did you tackle site
> mapping? It's
> not that I find the site map such a huge crucial piece of the
> puzzle, but
> it's something our stakeholders will want to see. It's also been
> tricky with
> the wireframing and organizing each page as well. Any tips are
> appreciated.
>
> Tom

Syndicate content Get the feed