Subject: Re: Fwd: web pages (was: [Tools-team] Minutes from the 7 Sept. . .)

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Oct 2005 07:48:27 -0400

Hi,

On Wed, Oct 12, 2005 at 09:21:35AM +0200, Brian E Carpenter wrote:
> 1. In my mind a great virtue of the IETF web site is that it doesn't
> use anything fancy - simple fonts, no splashes, no coloured backgrounds
> and very litte use of images. For what is basically a working tool
> and not a sales or PR medium, this is how it should be. So I have
> a strong resistance to using almost any kind of middleware to generate,
> format or beautify the site.

I don't think anybody was suggesting that we make this a splashware
site.  The basic issue I'm concerned about is site rot.  It's
obvious, once you start digging, that the problems originate partly
from what amounts to organic growth of the site -- various people
deciding where to put things, and hand-editing files.  These combine
to entail a more or less unscriptable redesign of the site.  We were
originally proposing a very simple design, with nothing more
complicated than server side includes (to make mirroring less
expensive).  We're still planning that, but I'll continue to keep
some sort of CMS as a second option in case we discover that the
future site maintainers are uncomfortable with fairly rigid human
controls on site management.

That said, your points are all good, and precisely in line with what
we've had as a plan.  Re: number 6, the goal is certainly to follow
the W3C's recommendations on accessibility; we've also used (this far
anecdotal) knowledge of actual users' accessibility strategies, so as
not to inconvenience users.

> I wonder if the next stage shouldn't be a current site map
> (presumably some sort of crawler can create that) and a proposed
> new site map, so that we can compare the click paths.

Well, I have one in my head :)  But the trouble is mostly that
there's not much topography -- most of the primary site is all in one
directory, with a few very clear exceptions.

A

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Oct 2005 09:21:35 +0200

Hi folks,

Barbara kindly forwarded this to me as I was curious about
progress on this front.

I'd like to make a few comments of my own.

2. I also think we need to keep the ability to use and even
deduce deep links. I know that if we had a brrgf WG, its charter
would be at http://www.ietf.org/html.charters/brrgf-charter.html
That is a very valuable property. (We may have to accept that deep
links will be broken once by the refurbishment.)

3. The material we have on the site is almost all there because
it was found useful. So there is little to remove; the main issue
IMHO is structure and obvious click paths.

4. Of course, ideas for new material are always good, as long as they
come with an author :-) And the refurbished site must make it
easy to add new material at a logical place.

5. I'm very torn in my mind between a revolutionary model, where
we decide in common between the community and the secretariat
on a major refurbishment of the structure and do it over a weekend,
or an evolutionary model where we make a plan for the new structure
and bring it in step by step over a few months.

6.Important point not mentioned explicitly below - accessibility.
We must make sure that we meet the applicable requirements for
accessibility by people with disabilities. (We should ask
if there are any particular problems today.)

    Brian

Barbara B. Fuller wrote:
> 
>> Envelope-to: [email-masked]
>> Date: Tue, 20 Sep 2005 15:55:32 -0400
>> From: Andrew Sullivan <[email-masked]>
>> To: [email-masked]
>> Subject: web pages (was: [Tools-team] Minutes from the 7 Sept. . .)
>> User-Agent: Mutt/1.5.9i
>> X-SA-Exim-Mail-From: [email-masked]
>> X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
>> X-Spam-Score: 0.0 (/)
>> X-Scan-Signature: e5bfa71b340354e384155def5e70b13b
>> X-BeenThere: [email-masked]
>> X-Mailman-Version: 2.1.5
>> Reply-To: Andrew Sullivan <[email-masked]>
>> List-Id: "The purpose of the TOOLS team is to provide IETF feedback and
>>         guidance during the development of software tools to support
>>         various parts of IETF activities." <tools-team.ietf.org>
>> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tools-team>,
>>         <mailto:[email-masked]?subject=unsubscribe>
>> List-Archive: <http://www1.ietf.org/pipermail/tools-team>
>> List-Post: <mailto:[email-masked]>
>> List-Help: <mailto:[email-masked]?subject=help>
>> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tools-team>,
>>         <mailto:[email-masked]?subject=subscribe>
>> Sender: [email-masked]
>> X-Spam-Score: 0.0 (/)
>> X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235
>>
>> Hi all,
>>
>> >    * IETF Website re-vamp
>> >       - Andrew?
>>
>> Sorry for submerging over the past few weeks.  We've undertaken a
>> minor re-organisation here, whereby I moved out from daily operations
>> duties (into the fire of DNS, so it's not like the new assignment is
>> relaxing :-) ).  Anyway, the work leading up to that, along with the
>> handover, has meant mostly that I've been looking at these things in
>> approximately 10-minute increments.  Needless to say, that's not the
>> most efficient way to work.
>>
>> In any case, I have had a chance to look at the site some more, and
>> to attempt a whack at my first proposal.  And while I think that
>> proposal is still possible, I think we need to think twice about it;
>> or at least, understand what we're getting.  In the mean time, I've
>> attached a pathetic little sample I put together this morning.
>>
>> As I understand the plan, what we're doing is proposing some new
>> strucutre, but then the Secretariat's paid staff will come in and
>> handle both the actual implementation, and the ongoing maintenance.
>> (If I'm wrong about that, stop me now and correct me -- the rest of
>> this is a waste of time).
>>
>> If I'm right, we have a number of design goals here.  They're in no
>> particular order below:
>>
>>         * improve the site usability (navigation, &c.)
>>         * improve the site's recommendations conformance
>>         * improve, or at least leave the same, the site's
>>                 maintainability
>>         * allow obsolete browsers to use the site (in some degraded
>>                 mode)
>>         * allow text-only browsers to work
>>         * keep to a minimum the technical requirements for the site.
>>         * make mirroring easy and low-bandwidth
>>
>> Here's the problem I see:  the actual site files appear to have been
>> organised according to whatever principle was active at the time; or
>> at least, the principle isn't obvious.  That means that
>> implementation of any revamp is going to involve looking at, and
>> probably manually editing or moving, every file.  I worry about the
>> liklihood of implementation under that stricture.  (This sort of
>> depends on the technical sophistication of the staff, and I don't
>> have a feel for that.)
>>
>> In spite of our previous rejection of this answer, therefore, I
>> wonder whether we shouldn't investigate some sort of server-side
>> publication or templating system, which will allow more cut-and-paste
>> type migration.  It requires a much greater up front investment in
>> software and set up; but it couls still generate static sites that
>> will be relatively easy to mirror (hrm -- I'm assuming this; maybe
>> none of the publication systems really will do that).
>>
>> In any case, in the meantime, attached is a little tarball that
>> includes a basic outline of the approach I'd originally planned.
>> This one turns out to be even simpler than my original outline, but I
>> suspect it's (at least visually) enough, and still simple enough to
>> cause no trouble when using lynx, &c.  It validates, but it doesn't
>> do anything very interesting (and most of the links are currently
>> broken).  If this seems totally the wrong place for a bridgehead, I
>> guess it's best to move now.
>>
>> Again, apologies for the slow movement.
>>
>> A
>>
>> -- 
>> ----
> ------------------------------------------------
> Barbara B. Fuller
> Acting Executive Director
> Internet Engineering Task Force
> 
> Natick, Massachusetts Office:
> 
> Phone: +1-508-650-4020
> Fax:     +1-508-650-4639
> 
> Reston, Virginia Office:
> 
> Phone: +1-703-620-9053
> Fax:     +1-703-620-9071

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 13 Oct 2005 22:33:59 +0200

Hi Brian,

  I have very little to add to what you're saying below - basically
I agree all through.  I'll let Andrew speak for himself.

Some small additional comments inline, though:

> links will be broken once by the refurbishment.)

Maybe not.  Apache has several mechanisms which lets you re-organise
a site, and still make content available through the old links.  The
most appropriate is probably the redirect directive, which lets you
put in one file a list of the old and the new position of all the
pages you've moved, which makes the server provide the content at both
URLs, but with the suggestion to the browser that the content has moved
and should be fetched at the new URL in the future.

> and bring it in step by step over a few months.

If we're just changing structure and some very basic means of making
that consistent and consistently available (read server-side includes
for header, menu and footer) I think that both ways will work

> new site map, so that we can compare the click paths.

Sounds like a good idea once we have a proposal.

	Henrik