[Sigia-l] Categorization/Classification vs. "Headlines"

Beau Lebens beau at dentedreality.com.au
Wed Mar 12 05:43:21 EST 2003


Hi Mike,
a couple things to consider here;

1) you should be trying to reduce the numer of clicks required/available for
   the user, between home/entry point and the information they happen to be
   looking for

2) page load times are often an issue (combine this with point 1) and thus
   less pages (to a certain extent - watch the size of each one!) is better

3) it's very easy to program into a system like what you are talking about,
   that you might actually check for each level of classification and if
there
   are < 5 (or whatever) sub-cats, then just don't supply a link to that
title.
   That way the sub-sections/pages are classified, but you remove the link,
   thus indicating that the user will derive no further value by navigating
to
   that page, so they should just click one of the sub-sections.

This is of course assuming that you are actually automating the creation of
the index pages, which I *think* I read properly from your email :)

Hope that sparks some ideas for you, or helps you reach a consensus with
your designers.

Beau

//  -----Original Message-----
//  From: sigia-l-admin at asis.org [mailto:sigia-l-admin at asis.org]On Behalf Of
//  MJJAIXEN at up.com
//  Sent: Wednesday, 12 March 2003 7:15 AM
//  To: sigia-l at asis.org
//  Subject: [Sigia-l] Categorization/Classification vs. "Headlines"
//
//
//  I'm currently having a mild argument (not quite a full blown
//  holy war) with
//  our designers over how we want to automate our index pages,
//  especially when
//  it comes to categorized content.  Perhaps someone has some
//  perspective or
//  some experience to lend here.
//
//  We are working with our IT group to develop a way to automate the
//  maintenance of our index pages with our content management system.  When
//  content is added, the editor will be asked to categorize the
//  content in a
//  content hierarchy.  (Eventually, I hope these hierarchies can
//  be supported
//  with multiple facets, but that's another battle for another day.)   My
//  intention is that each category will have it's own sub-index
//  page.   Each
//  index page (and sub-index page as well) would list all of the
//  content items
//  in the current category, as well as all of the subcategories of that
//  category.  In addition, each subcategory would also show all of
//  the content
//  items in that subcategory and the sub-categories of that
//  sub-category.  In
//  essence, you would see 2 levels of the current hierarchy on any
//  index page.
//
//  An example would be an organization like this
//  * Introduction page
//  * Chapter 1
//     * Section A
//     * Section B
//  * Chapter 2
//     * Section C
//     * Section D
//     * Section E
//     * Page X
//     * Page Y
//
//  Click on "Chapter 2", and it would take you to a page with
//  links like this:
//  Chapter 2
//  * Section C
//     * First Page
//     * Another Page
//     * Yet Another Page
//  * Section D
//     * More Stuff
//     * Even More Stuff
//   * Section E
//     * Finally, important stuff
//     * And even more important stuff
//  * Page X
//  * Page Y
//
//  The design staff seems to think that this is fine when you have a deep
//  organization structure, but not when it's not deep.  When you
//  only have a
//  list of a few links, they would like to classify the links, but
//  not create
//  sub-category index pages.  For example, if you have 10 content
//  items in a
//  section of the web site, and were to categorize those links into 3
//  categories, they don't want to have those 3 category index
//  pages.  They say
//  they'd like to be able to "classify" links without having to
//  "categorize"
//  those links.  Which is where my confusion and frustration ensues.
//
//  Their arguments center on:
//  1)  It's not necessary to create the sub-index pages.
//  2)  It's confusing to the user to give each category a
//  sub-index page that
//  merely lists the links that are listed on the higher level
//  index page.  It
//  makes them think that there is something more on that category than is
//  shown on the higher level page.
//  3)  It lengthens the URL, since the classification scheme will be also
//  reflected in the URL space.
//
//  My counter-arguments are:
//  1)  Since we are automating the creation and maintenance of these pages,
//  it's easier to create these pages than it is to create exception cases
//  around using these pages.
//  2)  By always creating these sub-index pages, we are ensuring the
//  consistency of our site - especially if the content expands
//  down the line
//  and the categorization increases.
//  3)  If we really have a business need for this, we could either (a)
//  manually maintain those pages (probably best if there are only a few
//  exceptions and the content doesn't change much) or (b) change the
//  presentation design of those specific templates and make the sub-index
//  pages unlinked.
//  4)  This shouldn't make or break the length of our URL's; we
//  probably need
//  to look at our URL scheme anyway if this is a big problem.
//
//  Mike Jaixen
//  Union Pacific
//
//
//  ------------
//  When replying, please *trim your post* as much as possible.
//  *Plain text, please; NO Attachments
//
//  ASIST IA 03 Summit: Making Connections
//  http://www.asist-events.org/IASummit2003/
//
//  Searchable list archive:   http://www.info-arch.org/lists/sigia-l/
//  ________________________________________
//  Sigia-l mailing list -- post to: Sigia-l at asis.org
//  Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
//




More information about the Sigia-l mailing list