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