Hi,
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.
This site is a working tool, not a marketing asset. I am worried about
any rework by "professional" web site designers, who are usually obsessed
with marketing values. We don't need fancy appearance, attractive graphics
and colours, or anything like that. The SOW should be be very explicit
in avoiding changes of this kind.
I am against any significant or noticeable change in the organisation
of the site, or any significant or noticeable change in its look and feel
(on a traditional browser). As far as I'm concerned, it isn't very broken
so doesn't need much fixing.
As an example, I still use the old-style home page at
http://www.ietf.org/content.html, instead of the default home page,
because it's much more handy as a daily tool (more links to more
useful stuff). Just as an example, the /content.html page has visible
links for several useful topics under "About the IETF" which are lacking
or obscure on the default home page. I advocate the revamp reverting to
something more like the old-style home page.
Repeating my previous comments on the overall goals:
Modernizing the website style,
I don't see this in itself as valuable or desirable. At the last
revamp, there was a definite policy to keep the style plain and
simple, and avoid the then-trendy "style", whatever it was that year.
IMHO we should stick to this policy. We aren't trying to be trendy;
we're trying to be efficient. At the moment the site is a simple and
efficient tool. Please leave it that way.
Making the website work better for all classes of devices,
This is important. I think it's a strong argument for simplicity,
although small screens and a touch interface clearly need to be
supported as well as full size screens and a mouse/keybooard
interface.
Incorporating current best-practices in website design and implementation,
I see no need to do that except for accessibility issues. We are not
in the marketing business and don't need to hook users. I don't like
this sort of buzzword in IETF requirements.
Improving content maintenance processes.
Understood as a need, but I have never yet seen a CMS that produced sensible
static content with sensible static URLs, which we need.
Repeating earlier comments on URL stability:
Please ensure that URLs, in general, do not change and remain meaningful;
avoid pseudo-random strings in URLs (as generated by many CMSs).
Identify all URLs that MUST remain stable, because they are cited in RFCs,
liaisons to other SDOs, and elsewhere.
All basic functions should work properly without any of:
Javascript
Popups
Applets
Plugins
(And frankly, bells and whistles that need any of the above, except perhaps
some very simple Javascript, have no place on a site which is a working tool.)
Limit use of cookies to the bare minimum.
Now some specific comments on the language of the SOW:
As a front door, the IETF website needs to reflect and advance the position
of the
IETF as the premiere Internet standards organization that gathers a large open
international community of network designers, operators, vendors, and
researchers concerned with the evolution of the Internet architecture and the
smooth operation of the Internet."
That is marketing talk. If we want a marketing site, please put it somewhere
else than www.ietf.org. Here's what I would write:
"As a working tool for IETF participants, the IETF website needs to offer
a simple interface to a set of information and tools used by a large open
international community of network designers, operators, vendors, and
researchers
concerned with the evolution of the Internet architecture and the smooth
operation
of the Internet. It should also offer a simple introductory interface for
newcomers to the site. It is not a marketing site and must not be constructed
like a marketing site."
Then consider this paragraph:
Since the IETF community is focused on producing technically excellent
standards deployed in the global Internet, the website must embody the
excellent
implementation of open standards as it supports the requirements of active
IETF
participants, as well as the efforts of those who seek to implement them."
That seems to encourage complexity and fancy features. I suggest adding
"However, simplicity and efficiency are key goals. The website must avoid
complex features and be compatible with the widest possible range of
devices and browsers, as far as possible achieving this by using the simplest
and smallest possible subset of features."
2. Project Goals
The IETF website redesign will:
a. Improve ease of navigation,
Why? What is hard to navigate at the moment? I am very suspicious of this;
I've almost never experienced a website revamp that made navigation *easier*;
normally it's just *different* after the change. (This goes with not changing
any URLs, so that bookmarks still work.)
b. Modernize the website visual design,
Why does that matter? We have a simple, plain layout with clearly visible links.
What is the reason for changing it?
c. Make the website work better for all classes of devices, including smart
phones and those with low-bandwidth and high-latency connections.
d. Incorporate current best-practices in website design and implementation
(such as responsive design and accessibility),
Yes, good goals and IMHO the only valid external reasons for change. I suggest
deleting
goals a) and b).
e. Reflect and advance key IETF messages and goals, and
This is pure marketing balderdash. Delete it. (And I remind you that the
old home page has a direct link to the IETF mission; the current one
doesn't, another reason it was a step backwards.)
f. Improve the content maintenance processes.
Yes, IMHO the only valid internal reason for change. But as noted above,
the CMS must not lead us to indecipherable URLs, dynamic content for no
good reason, etc. (My personal experience of various CMSs rather than
just editing HTML files is uniformly negative, however, so be very
careful. Maybe there is a good CMS in the world, if you can find it.)
3. Audiences
a. Active IETF Participants
Of course.
b. New or Potential IETF Participants
Individuals who could participate in and contribute to the IETF. The revamped
IETF website will help candidate participants become active contributors.
I strongly support that, but it is not principally a site design issue.
It is a content issue. So apart from having a prominent jumping-off point
for newcomers (like the *old* home page but not the current one), why is
it part of the SOW? The relevant content will be mainly from the volunteer
community. The IETF EDU team would be the natural focus of the relevant
effort to improve this content.
[To avoid misperception of this comment: I originated the content at
http://www.ietf.org/newcomers.html and I have been involved in its upkeep.
However, it is far from good enough.]
c. Non-participants looking to find out more about the IETF
These individuals include policy makers, managers of current or potential
IETF participants, and C-level executives from the organizations of IETF
participants.
That's outreach, which we tend to leave to ISOC. Please please please don't
contaminate our working tool with this material. And, like the previous
point, it's a content issue, not a site design issue. Provide a jumping-off
point (which is currently missing) and set up a separate way to generate the
content, in collaboration with ISOC.
Key milestones and deliverables during the redesign process (e.g. site
architecture, technology, wireframes, page design, content updates) should be
identified in the proposal. These items will be reviewed and approved by a
committee comprised of representatives from IETF leadership.
Firstly, content updates are a completely different category from the
rest. Do we really want professional web site designers changing our
content? I don't think so.
Secondly, I *really* hope you meant to write "a committee comprised of
representatives from the IETF community as a whole."
I don't have specific comments on the technical specs at the end of the SOW,
but they do need to consider the general points about stable and meaningful
URLs, and useability of the CMS.
Regards
Brian