Subject: [Tools-discuss] Some initial thoughts on web site

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jul 2005 11:37:47 -0400

Hi all,

I've been doing some thinking about the IETF site in preparation for
the changes we want to make.  

I apologise that I don't have a sample ready.  I got hauled out of
working on this early this week in order to read a bunch of contracts
for technical correctness.  I can assure you that I'd have preferred
to work on this (or, in fact, to have worked on pushing a rock up a
hill).

Here are my initial thoughts.

1.	Site organisation

In re-reading the complaints from people about the web site, I have
come to the conclusion that one of the biggest sources of annoyance
is just organisation.  In looking at the site copy I made, it sort of
looks like the site just grew organically.  That's not too
surprising; but given the quantity of information there, it probably
is what is causing the user difficulty.

For example, the index.html page has on the one hand a link to an
"overview", a link to RFC 2026, and a link to stuff about the IESG on
the one hand; a bullet for meetings, a star for the upcoming meeting,
and a different bullet for proceedings on the other hand; and a bunch
of stuff about working groups on the -- um, foot, I guess, since I'm
out of hands.  The difficulty is that it's clear neither from the
titles, nor the underlying pages, nor the page layout what
relationship these elements have to one another.

As a first go, I'd like to suggest the following taxonomy; I'm sure
that others will have opinions of whether this is a good taxonomy, or
if another is needed.  Please feel free to correct me.

I've tried to arrange this in a tree diagram; please let me know if
my ASCII art is obscuring this.

top----------------- about the ietf (history, process, rules, ADs &c)
level        \     
[index.html]  \------ activities of ietf --- iesg, iab, &c.
               |                           \ 
               |                            \-- working groups
               |----- other related sites    \
                                              \-- meetings 
                                               |  and proceedings
                                               |
                                               |-- RFC pages
                                               |
                                               |-- getting involved
                                               |   (edu here? 
                                               |   or in "about"?)
                                               |
                                               |-- activity support
                                                    (tools site here)

Does that seem reasonable?

2.	Page layouts: recurring elements

Somewhat related to (1), I suspect that we need two elements that
recur on every page.  My suggestion is that at the top of every page
we have a little bar that navigates _within_ the area one is working;
so, for instance, if I'm looking at items under the "Activities"
section of the site, I have a bar for "IETF organisations" or
"committees" or something like that; for "Working groups"; for
"Meetings"; and for "RFCs".  On the left side, we have an overall
site navigation <div> that does roughly the same thing as the top
bar, except that it needn't be dynamic.

3.	General strategy

I thought about doing some sort of scripting fanciness or something
to make the navigation stuff a little more dynamic, so that it would
render pretty and all of that.  I've been disinclined to take this
tack for a few reasons:

a.	We want to be as compatible as possible, with as few
requirements as possible.  Simple <div> tags work in every browser
except the ones that have gone out of their way to misimplement
things (and we can work around that one^H^H^H^H^H^H^H^H those).

b.	I'm assuming that the staff who are doing this will not want
to spend a great deal of effort on maintenance.  The more
complicated we make it, the more work it will take to implement and
maintain.

c.	The site is sometimes accessed by people behind slow
connections; the less they have to download in any given access, the
better.

4.	No server-side "publication system" &c.

I thought about using one of the many available site-management
systems (my favourite is Bricolage, <http://www.bricolage.cc/>), but
I concluded that this would impose too much in the way of setup, and
also too much in the way of necessary infrastructure.  If you all
think I should re-investigate this option, though, please let me
know.  It does have the conspicuous advantage that site maintenance
as such becomes considerably easier.  But every case I can think of
requires, at least, a running DBMS of some sort, and some kind of
scripting language.  That means that setting up a new category of
pages, or whatever, requires more than just regular HTML familiarity.

If you're in agreement that this is a good way to proceed, I'll bang
together some samples, and we can discuss them.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 20 Jul 2005 18:50:00 +0200

Hi Andrew,

On 2005-07-20 17:37 Andrew Sullivan said the following:
[...]
> Does that seem reasonable?

Yes, I think so.  No red flags popping up when I read this, which is
a good sign.  

> bar, except that it needn't be dynamic.

Sounds good, provided you plan to make links to the level of detail
of your taxonomy above available here by default.  This would give
a menu structure similar to the one used on the left side of http://tools.ietf.org/ .

> connections; the less they have to download in any given access, the

I'm happy to have this designed so that the most advanced feature used
is server-side includes.  That incidentally also makes the pages nicely
static, and you don't have to update bloody everything every night if
you're mirroring the site, which is true for parts of the site today
because it is re-generated every night, with unchanged files getting
new timestamps...

> know.  

No, I fully agree with you on this.

> It does have the conspicuous advantage that site maintenance

I agree, with the provision of using some simple mechanism ( like
SSI) to make sure that the main menu and sub-menus are changed in
only one place, not needing re-generation or manual change on all
pages.

Seems we think alike on this, so I'm all for you continuing on this
path!

Regards,

	Henrik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2005 15:35:51 +0200

> Yes, I think so.  No red flags popping up when I read this, which is

It would be useful to know what are the things people most want when they
come to the site. Are there any tools for that that we could ask the
Secretariat to run? Alternatively, can we run a user survey?

      Brian

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 21 Jul 2005 18:05:00 +0200

on 2005-07-21 15:35 Brian E Carpenter said the following:
[...]
> Secretariat to run? Alternatively, can we run a user survey?

The simplest, most standard way would be to get the web server logs
from the last 4 months or so and run a standard log analyser on them.

That should show us both which pages were most visited; which pages
people reach without following a link - i.e., pages people have book-
marked; and which links people most followed from the current first
page.

I'll send a mail to Mike Lee and see if we can get them.

	Henrik

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Jul 2005 09:28:58 -0400

> Secretariat to run? Alternatively, can we run a user survey?

Well, we could count page accesses from the logs; that would at least
tell us where people are actually _going_, although it might not tell
us what they're looking for.

A