ietf
[Top] [All Lists]

Re: IAOC Seeks Community Input on IETF Website Revamp SOW

2014-03-22 10:26:59
On Tue, Mar 18, 2014 at 12:17:02AM +1300, Brian E Carpenter wrote:
This is long, and I'm sorry if it sounds crabby, but I think there
are some real risks in this effort. First some general comments, and
then some specific comments on the SOW text.

First, I concur in such large part with Brian's comments that my
differences aren't worth mentioning.

Second, here's the list that I came up with after reading the SOW.

Text, text, text.  All-singing all-dancing web sites are heavyweight,
slow, hard to use, bandwidth-intensive, security and privacy-hostile,
and difficult to maintain/use across browsers.  If anything can be done
in text, it should be. Graphics and scripting should be a last resort
only when no other effective means of communication will suffice.

It has become quite fashionable to "modernize" sites, as the ISC has
recently done.  The aggregate affect of their changes has been to make
their site LESS usable.  Please don't follow in their footsteps.

Black on white text, please.  Readability is everything.

No "social networking".

No pop-ups.

Text, text, text.

No trackers.

No applets.

In the name of humanity, no Flash.  Ever.

Minimal (preferably zero) reliance on any/all outside content.
Everything that can should come from an IETF source.

Site must be navigable with a text-only browser.

Site must be navigable with Javascript disabled.

Static content wins heavily over dynamic content.  (Static content which
is periodically refreshed from a backing store is fine, and in fact it's
a great way to maintain a site.)

Time/datestamps (in UTC) on pages that need them so that we can all tell
how recent something this.

Text, text, text.

Direct "mailto" links.  Email address obfuscation is worthless voodoo.

Working "webmaster@" address which reaches the relevant people.  (Yes,
I know this exists today.  Keep it.)

Revision control.  (This can be combined with the previous item.
It's really quite impressive how a large site can be efficiently
maintained and updated with simple tools like make(1) and rcs(1).
There's no need for heavyweight monolithic content management systems in
many cases.)  That isn't to that a CMS isn't appropriate: it MIGHT be.
But I caution against reflexively choosing a heavyweight tool (with all
its attendant problems) when a much simpler one (or two) will suffice:
I've run a web site with 35,000 pages using make, rcs, rsync and a
little bit of perl.  It wasn't flashy or fancy but updates were easy,
fast, trackable, repeatable and undo-able.

Site should work on mobiles, not make *excessive* concessions to mobile
devices.  Nothing the IETF does is so time-critical that it can't wait
for someone to get to a real computer with a real display and a real
keyboard and a real web browser.  Good design practices should take care
of most of this anyway.

Keep in mind that many of us do not use closed-source operating systems
or web browsers.  The site must work with Firefox on OpenBSD or Chromium
on Linux or other similar combinations.

Browser neutrality is of course desirable, but please don't put even
one extra minute into making sure the site works with IE.

Text, text, text.


---rsk

<Prev in Thread] Current Thread [Next in Thread>