Subject: IAOC Seeks Community Input on IETF Website Revamp SOW

From: IETF Administrative Director <[email-masked]>
Date: Tue, 11 Mar 2014 11:41:36 -0700

The IETF Administrative Oversight Committee (IAOC) desires community input on a Statement of 
Work (SOW) for redesigning the public-facing IETF website (www.ietf.org) before pursuing a Request
for Proposals (RFP).

Goals for the project include:

·       Modernizing the website style,
.       Making the website work better for all classes of devices,
·       Incorporating current best-practices in website design and implementation, and
·       Improving content maintenance processes.

The redesign aims to improve how the website works for IETF participants, support new and 
potential IETF participants in becoming successful active contributors, and better inform 
other interested individuals about the work of the IETF. Usability testing and other forms of input 
from key audiences, including current IETF participants, will guide the project. The broader IETF 
community will be kept informed as the project progresses.

The complete draft Statement of Work is available at:
http://iaoc.ietf.org/documents/IETF-Website-SOW-20140205.pdf

The IAOC appreciates any input from the community and will consider all input received by 25 March.

All information submitted in response to this announcement is voluntary and may be used in the 
development of the SOW.

Thanks for your continuing advice and support.

Ray Pelletier 
IETF Administrative Director

---

From: Juliao Braga <[email-masked]>
Date: Tue, 11 Mar 2014 19:14:38 -0300

Hi Ray,

How and to whom we must submit suggestions on the document "IETF Website
Revamp Requirements"? Directly to you? In a separate document or can
simply make suggestions in an email?

Thanks,

Julião

---

From: Ray Pelletier <[email-masked]>
Date: Wed, 12 Mar 2014 05:45:45 +0000

> On Mar 11, 2014, at 10:14 PM, Juliao Braga <[email-masked]> wrote:
> 
> Hi Ray,
> 

You can reply on this list and begin a discussion of the points or  reply to me directly. 

Ray

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Mar 2014 12:31:57 +0000

Hi Ray,

These are motherhood and apple pie things but just
in case they got lost in the process..

Please ensure that the IETF web site is minimally
intrusive on visitors' privacy. I don't think its bad
right now (but haven't tried to check) but let's make
sure we don't go all analytics-mad for no good reason:-)

In a similar vein, please ensure it renders reasonably
for those who run without JS/cookies/+NoScript etc.
Its fine if those who run more open-kimono get to see
dancing whatsits, but those shouldn't be core to the
site being useful.

Thanks,
S.

---

From: Ofer Inbar <[email-masked]>
Date: Wed, 12 Mar 2014 08:11:28 -0500

Please make existing URLs continue to work to the extent possible.
If the page layout changes, have appropriate redirects rather than
just redirecting to the front page or the main page of a section
when someone followed a link to something more specific.  Keep those
redirects in place for the long term, not just temporarily.  Even
better would be for as many paths to stay as is so they don't need
to redirect.
  -- Cos

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Mar 2014 18:44:18 -0400

> for those who run without JS/cookies/+NoScript etc.

In particular, if some part of the site requires additional JS, then it needs
to become obvious that this is the case, and that part of the site MUST be
tolerant of a reload.

A number of sites (most annoyingly, payment processing, for which JS ought to
be exactly what you don't want),  will mysteriously stall halfway through the
"checkout", because some *new* source of JS is necessary.  Often loaded by
some other JS.

This is something people who use NoScript see regularly.
So far, I've not had this problem with ietf.org sites, and I think that
Henrik made a decree (perhaps not so strongly worded...) that all JS files
should come from IETF servers.  (Here is a place for ni: urls..)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: George Michaelson <[email-masked]>
Date: Thu, 13 Mar 2014 03:18:21 +0400

please, stick to text-mostly. text-overwhelmingly.  The current site is
almost perfect in that regard, and it would be a huge shame to wind up with
bloat, flash, movies, images, for appearance sake.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Mar 2014 21:35:58 +1300

> Please make existing URLs continue to work to the extent possible.

There are quite a number of URLs that MUST continue to work and
to point to completely static content. Those are URLs that are embedded
in various documents, notably RFCs of course. These need to be identified
spelled out in the SOW.

   Brian

> .

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Mar 2014 16:38:09 -0500

> in various documents, notably RFCs of course. These need to be identified

Do you have any particular URLs in mind that a grep over the RFCs for 
"www.ietf.org" would not likely find?

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 14 Mar 2014 14:05:27 +0900

Hello Ray,

Here are my comments:

Substantial:

Please add something about URI stability, i.e. that the Revamp should 
not change existing URIs. Some CMSes have the weird tendency to replace 
any and all URIs with long sequences of letters and numbers. It would 
e.g. be a pity if http://www.ietf.org/about/note-well.html would no 
longer exist, and instead the same text would be at 
http://www.ietf.org/ABCDEF1234567890 or so, because that will break many 
links.

7.d.vii: "For pages that require the use of applets, a link to the page 
where the user can obtain the plug-ins will be provided.": Do we really 
want/need to go that far? What about just saying "no use of 
applets/plugins"?

Editorial:

4. Process: "input from by groups" -> "input from groups" (or "input by 
groups")

7. c Navigation: I'd suggest "add/edit/delete/reorder" rather than 
"add/edit/delete/sort"

7.d.vii: "Pages with forms that require a timed response": maybe better 
"timely response"?

7.f.i: "Administrator: administers the site and configuration, 
edits/deletes and publishes content all high level functions.": 
Something seems to be amiss near "content all".

Regards,   Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2014 20:40:24 +1300

> "www.ietf.org" would not likely find?

I suggest ".ietf.org" to be sure, and it also occurs to me that we have
URLs in liaison statements etc. that need to be stable but are
not necessarily in RFCs. These will be hard to find. The less we change
the better.

I strongly agree with Martin: "the Revamp should not change existing URIs."
It should be a very strong goal not to break people's bookmarks or
to replace sensible URIs by pseudo-random strings.

I haven't had time yet to analyse the SOW in detail, but while I'm
here I will comment on the high level 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. 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 please see Martin's comments. I have never
yet seen a CMS that produced sensible static content with sensible
static URLs, but we need that.

>>> better would be for as many paths to stay as is so they don't need

What he said.

    Brian

---

From: "John Levine" <[email-masked]>
Date: 14 Mar 2014 15:23:04 -0000

>want/need to go that far? What about just saying "no use of 

Yes, please.  Many of us use neither Windows nor Mac nor Android nor
iOS, which means that applets rarely work.  Anything useful you can do
with an applet you can do, perhaps slightly slower, by sending
requests back to the host.

Also, you can do a lot of useful stuff with no applets at all.
Etherpad works fine on my FreeBSD box, for example, where I've used it
to take notes for many WG sessions.

R's,
John

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 14 Mar 2014 16:28:36 +0000

Hi,

I think the applets thing is a red herring.

The more interesting question is whether we should assume Javascript support in browsers. (Your FreeBSD box browser probably had that, hence Etherpad works.)

I would personally say "yes" here, but I am pretty sure there will be some folks out there using lynx...

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Mar 2014 09:24:32 +1300

I understood that mandatory Javascript is unacceptable for accessibility
reasons. afaik the site is currently fully useable without Javascript
except for a few bells and whistles. This had better not change.

   Brian

---

From: Hector Santos <[email-masked]>
Date: Sat, 15 Mar 2014 02:04:37 -0400

> except for a few bells and whistles. This had better not change.

I should note the new archive web-based search tool has a near total 
breakdown with its dependency on javascript.

At the very least, the tool and the revamped IETF web site should have 
detection to go either way or if required, use the <NOSCRIPT> HTML tag 
to display a "browser" requirements page.  This sort of design note 
should also be part of the functional requirements and SOW.

<noscript>
   [ADVISE USER JS IS DISABLED or use WEB 1.0 UI method]
</noscript>

-- 
HLS

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 15 Mar 2014 11:16:38 +0000

Hi,

On 2014-3-14, at 21:24, Brian E Carpenter <[email-masked]> wrote:
> reasons.

I'm not sure this is fully true. The Boostrap framework, for example, discusses ARIA issues in a number of places, and certainly depends on Javascript. In other words, I think you can obviously totally mess up accessibility with Javascript on a site, but you can also build a site that is accessible. 

> afaik the site is currently fully useable without Javascript

If the site remains as accessible as it is now (or gets better), why not? 

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Mar 2014 05:23:33 +1300

> If the site remains as accessible as it is now (or gets better), why not? 

Of course. But I suggest having this aspect reviewed by some people
who personally have some accessibility requirements.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 15 Mar 2014 13:33:42 -0700

> who personally have some accessibility requirements.

some of our community are sufficiently security conscious that
javascript means not accessible.

randy

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 16 Mar 2014 07:48:12 +0000

> javascript means not accessible.

Good thing we operate by rough consensus?

Lars

---

From: <[email-masked]>
Date: Sun, 16 Mar 2014 10:02:21 +0000

...and Javascript IS running code.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Eggert, Lars [[email-masked]]
Sent: 16 March 2014 07:48
To: Randy Bush
Cc: IETF Disgust
Subject: Re: IAOC Seeks Community Input on IETF Website Revamp SOW

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Mar 2014 00:17:02 +1300

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.

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.

>  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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 17 Mar 2014 14:39:41 +0100

* Brian E Carpenter wrote:
>This is long, [...]

+1
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: David Morris <[email-masked]>
Date: Mon, 17 Mar 2014 07:07:39 -0700 (PDT)

Yes, Brian's detailed review is on point.

---

From: Eric Burger <[email-masked]>
Date: Mon, 17 Mar 2014 12:12:02 -0400

Agreed. We don't need flashy(tm) stuff. We need easy to access and find stuff. Mobile sites are really easy if the site itself is simple, compact, and NOT using the proprietary flavor of the month for fancy display.

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/>

> On Mar 17, 2014, at 10:07 AM, David Morris <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Mar 2014 12:58:15 -0400

> Agreed. We don't need flashy(tm) stuff. We need easy to access and find stuff. Mobile sites are really easy if the site itself is simple, compact, and NOT using the proprietary flavor of the month…

While we certainly don't need a web site that doesn't continue to fill the needs of its existing community, it's worth asking if "we" really means what various people who have weighed in on this think it means.   What is the target audience for the web site?   Is it IETF attendees?   The press?   People who use our protocol specifications?   The open source community?   Young geeks learning about networking?   Governments?   Other standards bodies?

Nearly 100% of the time when I go to the IETF web site it's to look up when the next meeting is, or when a previous meeting was.   Everything else I tend to access through the datatracker.   Am I a typical user?   Are you a typical user?

I don't know what the answer to these questions is, but I suspect that if you look at this effort strictly from the perspective of "what would work for me," you probably are narrowing the scope way too much to be useful.

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Mar 2014 10:18:26 -0700

> in avoiding changes of this kind.

<aol>

---

From: Scott Brim <[email-masked]>
Date: Mon, 17 Mar 2014 15:57:38 -0400

On Mon, Mar 17, 2014 at 12:58 PM, Ted Lemon <[email-masked]> wrote:

> While we certainly don't need a web site that doesn't continue to fill the
> needs of its existing community, it's worth asking if "we" really means
> what various people who have weighed in on this think it means.   What is
> the target audience for the web site?   Is it IETF attendees?   The press?
>   People who use our protocol specifications?   The open source community?
>   Young geeks learning about networking?   Governments?   Other standards
> bodies?

GSMA, as an example, has two completely different websites, one for the
public and one with less bling for document tracking and other work. The
public site doesn't even point to the members-only working one.

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 17 Mar 2014 21:03:21 +0000

Hi Ted,

Thanks you pointed to what needs to be discussed or what needs to
be changed. My comments below,

On Monday, March 17, 2014, Ted Lemon wrote:
> the target audience for the web site?

That is the key question for web change to better involvement with
the user community.

> Is it IETF attendees?   The press?   People who use our protocol
> specifications?   The open source community?   Young geeks learning about
> networking?   Governments?   Other standards bodies?

That includes the internet community, but IETF participants (usually number
of active participants in IETF did not change and their preferences may not
change) should not object to change because change will include more
opportunities within the dynamic internet community.

>
> Nearly 100% of the time when I go to the IETF web site it's to look up
> when the next meeting is, or when a previous meeting was.   Everything else
> I tend to access through the datatracker.   Am I a typical user?   Are you
> a typical user?

Usually I think IETF participants are mostly not using IETF web site, they
are more focused on WG activities.

>
> I don't know what the answer to these questions is, but I suspect that if
> you look at this effort strictly from the perspective of "what would work
> for me," you probably are narrowing the scope way too much to be useful.

The subject says IAOC seeks community input so that means from internet
community perspective not only perspective of active participants. I think
that the answer is that the IETF web site needs changes to
be more marketing to total internet community related
announcements, activities or events.

AB

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Mar 2014 17:58:03 -0400

On Mar 17, 2014, at 5:03 PM, Abdussalam Baryun <[email-masked]> wrote:
> That includes the internet community, but IETF participants (usually number of active participants in IETF did not change and their preferences may not change) should not object to change because change will include more opportunities within the dynamic internet community. 

IETF participants can and should object to things they think are mistakes.   However, it's important to have a clear idea of the scope of the problem being solved while discussing approaches to the problem.   Otherwise we wind up with a solution that may be perfect in a narrow scope but doesn't address important requirements.

So please don't take my previous message as an indication that IETF participants shouldn't object to the proposed plan.   I was just trying to remind people to keep scoping in mind while thinking about the problem.

---

From: t.p. <[email-masked]>
Date: Tue, 18 Mar 2014 17:42:13 +0000

----- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "Eric Burger" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 17, 2014 4:58 PM
On Mar 17, 2014, at 12:12 PM, Eric Burger <[email-masked]>
wrote:
> Agreed. We don't need flashy(tm) stuff. We need easy to access and
find stuff. Mobile sites are really easy if the site itself is simple,
compact, and NOT using the proprietary flavor of the month for fancy
display.

While we certainly don't need a web site that doesn't continue to fill
the needs of its existing community, it's worth asking if "we" really
means what various people who have weighed in on this think it means.
What is the target audience for the web site?   Is it IETF attendees?
The press?   People who use our protocol specifications?   The open
source community?   Young geeks learning about networking?
Governments?   Other standards bodies?

Nearly 100% of the time when I go to the IETF web site it's to look up
when the next meeting is, or when a previous meeting was.   Everything
else I tend to access through the datatracker.   Am I a typical user?
Are you a typical user?

I don't know what the answer to these questions is, but I suspect that
if you look at this effort strictly from the perspective of "what would
work for me," you probably are narrowing the scope way too much to be
useful.

<tp>

I was concerned when I first heard of this that it would result in a
website that would call for flashy software on a gee-whiz device to
be able to carry on participating in the work of the IETF.  I note,
however, that while the SOW talks of getting the work done, the SOW is
limited to www.ietf.org.  Checking History, I find I last used that when
planning to attend IETF89 and before that, I cannot recall when.

So if www.ietf.og was made gee-whiz and flashy, it would not affect me;
and perhaps that website, which is what the innocent browser would most
likely stumble across in a search for the IETF, should be gee-whiz and
flashy to advertise better who we are and what we do, to give us more
street cred..

Of course, if graphics, moving images and incredibly clever java
(that always misguesses what I am about to do) were to mission creep in
the direction of the datatracker, then that would be disastrous for me;
but as long as this is only www.ietf.org, then it could be a good thing.

Tom Petch

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Mar 2014 21:13:41 +1300

> planning to attend IETF89 and before that, I cannot recall when.

I think you're overlooking that there is lots of informational
material at www.ietf.org/* for people who may not strictly be
newcomers but are still learning. I'm still learning, and use
much of that material frequently.

Of the ~50 links off http://www.ietf.org/content.html, I counted
only 6 links to the datatracker.

> flashy to advertise better who we are and what we do, to give us more

That's the outreach mission. Different audience.

   Brian

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 19 Mar 2014 10:50:40 -0400

Sent from my iPhone

> On Mar 19, 2014, at 4:13 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> 

It might be useful to get feedback from newcomers to the past few IETF meetings to get their perspective.  Many of is are used to the interface and have adapted, even prefer it's simplicity.  I did get questions from a few newcomers in Berlin about the web site, thinking the IETF was a bit out of touch and behind the times.  This may make it difficult to attract newcomers and younger engineers.  

Best regards,
Kathleen

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 19 Mar 2014 10:08:47 -0400

On Mar 18, 2014, at 1:42 PM, t.p. <[email-masked]> wrote:

> perhaps that website, which is what the innocent browser would most

Street cred that can be purchased with "gee-whiz and flashy" is street cred I don't want. (My own reaction to such is generally to downgrade my opinion of the organization behind the site, though I'm sure you can find as many reactions as you can individuals.)

I agree with Brian's long note of March 17, with the sole exception of not completely accepting that there's nothing to be improved in the site's navigability, as implied by

> I've almost never experienced a website revamp that made navigation *easier*;

i.e. just because I think it *could* be improved doesn't mean I have any confidence it *will* be :-(

Also: hey! you kids! get off my lawn.

--John

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Mar 2014 13:55:21 -0400

On Mar 19, 2014, at 10:08 AM, John G. Scudder <[email-masked]> wrote:
> Street cred that can be purchased with "gee-whiz and flashy" is street cred I don't want.

Is it your impression that the current SOW aims to make the web site "gee whiz and flashy?"

> i.e. just because I think it *could* be improved doesn't mean I have any confidence it *will* be :-(

You _can_ be confident that if there is a usability problem with the web site and nothing is done, the usability problem will not go away.   I think the argument "change isn't always for the better" is a very weak one to raise as an objection to a change that serves to address some need.   It would be better to (1) determine whether the need is sufficiently documented that you can evaluate it, (2) determine whether the proposal addresses that need and (3) if it doesn't, make suggestions for how it can do so.

That is to say, it is by reading the SOW and making concrete suggestions, if you find gaps, that you can do your part in making sure that the outcome is good.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 19 Mar 2014 16:10:31 -0400

> From: "t.p." <[email-masked]>

> So if www.ietf.og was made gee-whiz and flashy, it would not affect me;

I'm not entirely sure what you're saying, but if it means that somehow
the "main" web site and the "datatracker" become even more
disconnected, that's not good at all.  Currently, the distinction
regarding what is on one and the other seems to be nearly arbitrary,
and it's constantly getting in my way when I try to find information.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2014 20:27:48 +1300

Ted,

> Is it your impression that the current SOW aims to make the web site "gee whiz and flashy?"

I think there are three reasons for concern about this.

1. The confusion of two audiences: current and new users of the
IETF site as a working tool, and the "outreach" audience described
by "These individuals include policy makers, managers of current or potential
IETF participants, and C-level executives from the organizations of IETF
participants."

2. Several instances of marketing-speak that I mentioned in my long
message.

3. The absence of a clear requirement to be simple and avoid bells
and whistles.

Knowing what I know of professional web designers, this amounts to
a licence to jazz up the site.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2014 20:37:50 +1300

> It might be useful to get feedback from newcomers to the past few IETF meetings to get their perspective.  Many of is are used to the interface and have adapted, even prefer it's simplicity.  I did…

Maybe I should draft some text on "Why this website looks so boring" for
the newcomers' page? (Seriously.)

   Brian

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 20 Mar 2014 09:40:22 +0100

On Thursday, March 20, 2014, Brian E Carpenter wrote:
> I want to see the answer in simple text. But it is not only boring but may
be more about not useful.

AB

---

From: Avri Doria <[email-masked]>
Date: Thu, 20 Mar 2014 18:08:56 +0800

On 20-Mar-14 15:37, Brian E Carpenter wrote:
>>> It might be useful to get feedback from newcomers to the past few
>>> IETF meetings to get their perspective.  Many of is are used to
>>> the interface and have adapted, even prefer it's simplicity.  I
>>> did get questions from a few newcomers in Berlin about the web
>>> site, thinking the IETF was a bit out of touch and behind the
>>> times.  This may make it difficult to attract newcomers and
>>> younger engineers.
>>>
> Maybe I should draft some text on "Why this website looks so boring"
> for the newcomers' page? (Seriously.)

I like that idea.

My personal experience is that I never saw a redesign of a web site that 
actually made it easier to use.

avri

---

From: t.p. <[email-masked]>
Date: Thu, 20 Mar 2014 09:49:58 +0000

----- Original Message -----
From: "Dale R. Worley" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 19, 2014 8:10 PM
> and it's constantly getting in my way when I try to find information.

I am saying 'Leave the Datatracker Alone'!

It does the job for me and as I said before, the only use I can find I
made of the www.ietf.org website in my browser History was to check the
details of IETF89 before booking.  Mailing Lists, I-Ds, Charters,
Archives, RFC, History, DISCUSS .... etc I access via the Datatracker
(which is my browser's home page - used to be Google).  Sometimes it
lets me down - ever tried to find the tools mailing list via it? - but I
suspect that any change to it would impair my ability to participate in
the IETF, short term and may be long term.

I think that the layout of the main www.ietf.org is poor, scrappy.
(Didn't underlining go out when printers gained support for more than
one font?)

By contrast, I think that the IEEE website looks, well, professional.
We may technically be amateurs in the IETF but we should still appear
professional!

Tom Petch

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Mar 2014 07:42:29 -0400

> a licence to jazz up the site.

To be clear, I'm not objecting to your analysis, which I found to be helpful.   I'm just reacting to several subsequent messages that didn't add anything, but expressed concern about "bells and whistles" without giving any advice for how to avoid trouble.

My personal opinion is that the IETF web site isn't really all that useful to IETF participants.   I use it to find info about meetings, and mailing lists, but otherwise rely on datatracker.   My reason for stating that was to see if anybody disagreed.   You've already said that you don't use the main site, and several other people have said that they rarely use it either.

So there's certainly a case to be made that the front page could change quite a bit without causing inconvenience to regular IETF users.   I am hoping that this assertion will attract loud objections if I am mistaken.

BTW, my wife is a professional web designer, has a horror of Flash, and seems to design pretty nice, spare, usable sites.   And she usually takes advantage of work other web designers have released into the public domain in order to do this.   I think it's important that we be clear about what we want, and any lack of clarity in the SOW should be addressed.   That is, after all, why we were asked to review it.   But I do object to characterizations of web designers as a class being irresponsible children who cannot be trusted to produce a usable site when asked to do so and given a clear spec.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Mar 2014 07:43:23 -0400

> the newcomers' page? (Seriously.)

I am fairly certain that if you do so, you should treat it as a humorous and ironic article, because it will certainly be viewed that way by its intended audience.

---

From: Scott Brim <[email-masked]>
Date: Thu, 20 Mar 2014 08:02:17 -0400

I also like the idea of two faces. I mentioned GSMA as one organization
that does this - one site for the public, one site for the gritty work.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Mar 2014 06:33:50 +1300

Ted,

On 21/03/2014 00:42, Ted Lemon wrote:
...
> BTW, my wife is a professional web designer, has a horror of Flash, and seems to design pretty nice, spare, usable sites.   And she usually takes advantage of work other web designers have released…

Yes, it is the SOW we're supposed to be discussing, and my point is not
that all web designers are bad, but that we must indeed produce
a clear spec that will select the kind of designer we need.

I certainly apologise if I seemed to insult the entirety
of web designers.

> that does this - one site for the public, one site for the gritty work.

Sure. This is quite common. If we want that, let's specify it clearly.

   Brian

---

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Mar 2014 13:29:12 -0500

Trimming to a detail. I don't want this to become a large diversion,
but I found it useful when thinking about what to do:

On 3/19/14, 3:13 AM, Brian E Carpenter wrote:
<snip/>
> Of the ~50 links off http://www.ietf.org/content.html, I counted only 
> 6 links to the datatracker.
I looked at what those were by looking at the href elements at that URL.
There are 42 that point back into www.ietf.org, and 8 that point to the 
datatracker.
The numbers aren't nearly as interesting as what was actually being 
pointed to.
Here's the result, sorted roughly by what kind of href it was.

Again, I don't want this to take away from the main point of the thread, 
but I found
looking at what content we're talking about this way informative, and I 
hope others
will to:

/
/about/
/about/mission.html
/about/note-well.html
/about/standards-process.html
/assignments/
/blog/
/contact-the-ietf.html
/edu/
/edu/tutorials.html
/iana.html
/id-info/
/iesg/
/iesg/members.html
/iesg/minutes.html
/iesg/statement.html
/ipr/
/ipr/file-disclosure.html
/ipr/policy.html
/liaison/
/liaison/managers.html
/list/
/list/announcement.html
/list/discussion.html
/list/nonwg.html
/media.html
/meeting/
/meeting/cutoff-dates.html
/meeting/interim-meetings.html
/meeting/past.html
/meeting/proceedings.html
/meeting/upcoming.html
/newcomers.html
newcomers.html
/nomcom/
/resources/mentoring-program.html
/rfc.html
/secretariat.html
/tools/
/tools/tools.html
/wg/
/wg/chairs-page.html

/css/ietf2.css
/css/ietf3.css
/css/ietf4.css
css/ietf.css
javascript:setStyle('1');
javascript:setStyle('2');
javascript:setStyle('3');
javascript:setStyle('4');

http://datatracker.ietf.org/list/wg/
http://datatracker.ietf.org/wg/
https://datatracker.ietf.org/
https://datatracker.ietf.org/drafts/
https://datatracker.ietf.org/idst/upload.cgi
https://datatracker.ietf.org/iesg/ann/new/
https://datatracker.ietf.org/ipr/search/
https://datatracker.ietf.org/liaison/

http://iaoc.ietf.org/
http://iaoc.ietf.org/subpoenas.html
http://rfc-editor.org/rfcsearch.html
http://www.rfc-editor.org/queue2.html
http://tools.ietf.org/
http://wiki.tools.ietf.org/group/
http://www.amsl.com/
http://www.isoc.org/
http://www.isoc.org/educpillar/fellowship/
http://www.isoc.org/members/
http://www.isoc.org/pubpolpillar/
http://www.isoc.org/standards/

mailto:[email-masked]
mailto:[email-masked]
xmpp:[email-masked]?join

---

From: David Morris <[email-masked]>
Date: Thu, 20 Mar 2014 13:22:08 -0700 (PDT)

I think the applicability of your observation re. website re-design
making it easier to use applies to most re-design efforts I've
observed. Feature creep combined with not having a complete understanding
of original features conspire against success.

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 22 Mar 2014 11:26:34 -0400

> 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

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 22 Mar 2014 16:24:30 +0000

OK, it seems that RFC1436 is the way to go for the redesign.

Lars

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Mar 2014 03:36:26 +0900

> OK, it seems that RFC1436 is the way to go for the redesign.

perhaps instead of repeated sarcasm and put-downs, you could explain
technically what it is you want in the user interface of the ietf web
site and the features needed to support it.  that way, folk actually
trying to wade through the redesign decision actually have something
to consider.

fwiw, i have seen usable and featurful web sites that are done with
pretty simple technology and work in very sparse user environments.

randy

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 23 Mar 2014 09:43:59 +0000

Hi,

> trying to wade through the redesign decision actually have something

fair point.

In terms of look & feel: I'd like the main web site (and the datatracker, but that's not covered by he SOW obviously) to have a clean, modern look and feel, be fully usable by clients with small screens, and follow ARIA accessibility standards.

In terms of management: Whatever the secretariat prefers. Whether the backend is some CMS, or a static page generator, or something else. It would be nice if the backend was future-proof, such that the content could be easily extracted when we do this revamp exercise the next time (5-10 years out, if web technologies keep evolving at their current pace). It would be nice if we could leverage CDNs more aggressively than at the moment (but that's actually more important for the datatracker responsiveness, i.e., not this SOW).

In terms of technology used: I don't actually care much *how* this is implemented, both in terms of the backend and in terms of the content delivered. I'd prefer if we'd follow modern web standards (HTML5 with some modern framework such as bootstrap, jquery-mobile, etc.), mostly so there is a deep enough pool of developers that we can hire from.

> pretty simple technology and work in very sparse user environments.

Yep. This isn't rocket science. (But it is a bikeshed.)

We could simply save ourselves a lot of cycles and adopt whatever one of our friendly peer organizations (ISOC< W3C, etc.) are using...

Lars

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Mar 2014 19:01:46 +0900

thanks.

small screens are a good point, in many cultures phones etc. are the
main mode of internet access.  not sure what a clean, modern look and
feel is, but that may just be my age showing.  what about the trade-off
between density and having to do more clickivation to get where you want
to go?  i am on the dense side, probably because i have become used to
japan's high visual density, and i kinda hate lots of clicking and page
loading.

randy

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 23 Mar 2014 10:22:40 +0000

> japan's high visual density, and i kinda hate lots of clicking and page

It's a tradeoff. Pinch-zooming and flicking around pages that render to a desktop viewport makes mobile use painful. On the other hand, making all UI elements touch-ready wastes a lot of screen real estate.

My suggestion would be that the current web logs are mined in order to identify the elements that are most commonly interacted with by site visitors, and we focus on making them easily usable on small screens.

Lars

PS: For the datatracker, which has much more interaction options, this will both be more difficult and more important.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 23 Mar 2014 13:50:59 +0000

On Sunday, March 23, 2014, Eggert, Lars wrote:

>
> My suggestion would be that the current web logs are mined in order to
> identify the elements that are most commonly interacted with by site
> visitors, and we focus on making them easily usable on small screens.

IMHO, the Most important web element for visitors which IETF MUST choose
carefully is the latest news/events content and its updating method.

> PS: For the datatracker, which has much more interaction options, this
> will both be more difficult and more important.
>
I think that active participants don't want to develop data tracker for
now, because it will need a good plan.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Mar 2014 08:57:30 -0500

> In terms of look & feel: I'd like the main web site (and the datatracker, but that's not covered by he SOW obviously) to have a clean, modern look and feel, be fully usable by clients with small sc…

It may be worth pointing out that there are competing needs here.   What you are asking for is something called "responsive design," and this is generally done with a substantial amount of fancy css and a bit of javascript for flavor.   The alternative is those stupid mobile sites that don't actually work for your particular mobile device because they assume the wrong screen size.

The desire for a clean backend is a valid one, but in fact most of the time CMSs store this stuff in tables in a database, which are easily extracted if you want to migrate later.   There isn't a way to store web pages that doesn't require a bit of data analysis and transmogrification when you are upgrading—even a directory tree will have a layout that's specific to the particular deployment you have chosen.

So while I think the point you are making about that is a good one, it doesn't preclude CMSs that store information in databases—it just argues for the use of a CMS that does so in a way that's not needlessly complex and confusing.

---

From: Rich Kulawiec <[email-masked]>
Date: Sun, 23 Mar 2014 10:24:35 -0400

On Sun, Mar 23, 2014 at 08:57:30AM -0500, Ted Lemon wrote:
> The desire for a clean backend is a valid one, but in fact most of the
> time CMSs store this stuff in tables in a database, which are easily
> extracted if you want to migrate later.   There isn't a way to store web
> pages that doesn't require a bit of data analysis and transmogrification
> when you are upgrading?even a directory tree will have a layout that's
> specific to the particular deployment you have chosen.

As I mentioned in my earlier comments, it's possible that a CMS is
too heavyweight for this application and quite possibly not compatible
with the need to have (a) sane, meaningful URLs and (b) the ability
to migrate at some future date.  The "software tools" approach suggests
using simple tools in combination rather than monolithic ones, and I
strongly recommend investigating that approach here.  As I also mentioned,
it's really not difficult to build a very simple, very scalable, very
future-proof "CMS" out of basic Unix/Linux tools, used in combination
with a little bit of shell or Perl glue to hold them together.  This
approach facilitates testing, incremental updates, global updates,
revision control, timestamping, and backout quite readily.   It also
allows for easy upgrades/changes because the storage formats are simple
and easily migrated to other ones.

It's not fancy, it's not trendy, it's not buzzword-compliant.  But it's
simple and robust.  So I think that an important part of this revamp
process is ascertaining exactly what the content management requirements
are and figuring out what the simplest possible toolset that meets them
looks like, i.e., I think it's important not to commit to the idea
that a full-blown CMS is required before an actual need to do so is
demonstrated.

---rsk

---

From: David Morris <[email-masked]>
Date: Sun, 23 Mar 2014 10:58:47 -0700 (PDT)

> japan's high visual density, and i kinda hate lots of clicking and page

Careful organization can generally achieve a good balance between
density tree depth. Small screens, in particular as found on phone
devices, suffer because click resolution is limited by the size of
a finger tip.

Another enemy of usability is frequent reorganization of commonly
used pages.  If one must always look for commonly used links
because they move around, efficiency suffers. In my observation,
attempting to achieve high density results in more frequent
adjustments.

Backward navigation is critical. If you make the wrong choice,
perhaps because your finger didn't touch the correct place
on the screen, going back must be easy. This can be achieved
by taking care to insure that the browser back button will
always work, OR always having a reverse navigation element
on every page.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Mar 2014 15:23:47 -0500

> attempting to achieve high density results in more frequent

This is true, although only relevant to the extent that we expect the site to get frequent use by IETF regulars.

> always work, OR always having a reverse navigation element

I would second this, however I can't imagine a reason why the IETF web site would need controls that would prevent the back button from working, so I think we should just say "the back button must work" and leave it at that.

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 24 Mar 2014 07:04:19 +0000

> It may be worth pointing out that there are competing needs here.   What you are asking for is something called "responsive design," and this is generally done with a substantial amount of fancy cs…

Yep. But I'd leave the details about CSS and JS out of the SOW, and instead describe the desired behavior of the site.

> So while I think the point you are making about that is a good one, it doesn't preclude CMSs that store information in databases—it just argues for the use of a CMS that does so in a way that's not…

Exactly.

Lars