Date: Mon, 5 May 1997 09:40:25 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Stefan Bethke <stefan@promo.de> Cc: www@FreeBSD.ORG, "Jordan K. Hubbard" <jkh@time.cdrom.com> Subject: Re: New Web design Message-ID: <Pine.BSF.3.96.970505085456.29300N-100000@fallout.campusview.indiana.edu> In-Reply-To: <l03010d00af929de10182@[194.45.188.81]>
next in thread | previous in thread | raw e-mail | index | archive | help
Ah, I should have read this message first! On Sun, 4 May 1997, Stefan Bethke wrote: > So, after a busy weekend (drum roll): > http://www.promo.de/people/stefan/freebsd/home1/ > > A new home page for FreeBSD (2nd try). [snip] > Points for further discussion: > - What topics should the navbar contain? I've already given a fair amount of thought to this, and spent some time analyzing the log file to determin the most frequenly used sections of the website. The categories I selected, which you have duplicated represent the most to least used resources (left to right). > - Do we want to use a map, or individual images on the navbar? To what extent do clients support client-side image maps? A server side map is out of the question unless we provide different pages for lynx users. Separate images take longer to download, but that problem will diminish as http 1.1 comes into more common usage (and the apache server gets upgraded...) > - Further reorganization for different audiences (first time user, experienced > user, developer)? > - Where to put: the Source Tree, cvsweb, and alike; I think this is neither > "documentation" nor "support"; maybe we want to add a section on "Developer > Info"? We have support resources aimed at non-developer users and sources aimed at developer-users, where `developer' refers to *FreeBSD* development. These two categories are curretly mixed together under documentation and support. To some extent this is necessary because there is no clean line between the two and some of the resources serve both, but we could probably group things a little better. Ultimately what you have to do is try out different arrangements on unsuspecting individuals. This is pretty easy to do: you just make a little flip-book (paper!) where each page represents one of the web pages--just headings, no content--the home page being the top. Find some people and ask them "Where would you go to find..." They point at an item, you turn to the corresponding page, they point again, etc. Just record the trails. It is relatively easy to spot basic organizational problems in this way. It is a lot quicker than an electronic mock-up too since it can be done at a moments notice just about anywhere--in a cafeteria, hallway, bus... The real problem is finding representative people to quiz. Another project I was involved in that used this method was a public library so just about any random person on the street was a good subject. Unix users are few and far between by comparison! > While providing both additional languages (read: translation of the english > pages) and local information is definitly worthwhile, it could easly grow > into a maintainance nightmare. Relative to the handbook, which has been most valiantly translated into Japanese, the rest of the pages represent trivial content by comparison. Compared to the handbook, the content is remarkably static as well. I would like to see a clean architecture that would accomodate a wholesale translation of the site from the home page on down. This: > I would suggest the following structure. A typical FreeBSD WWW server > (including www.freebsd.org) provides one or more of: > - http://www.XX.freebsd.org/en/ the English pages (what is now /) > - http://www.XX.freebsd.org/YY/ other languages such as JP, DE, PO, or FR; > verbose translation of English version > - http://www.XX.freebsd.org/ a link/redirect to the "preferred" language home > page on that server) > - http://www.XX.freebsd.org/local/YY/ information local to country XX, in > language YY looks good as an outside view of things but does not address how the pages are built and maintained. For example if not all pages have been translated, links to those pages need to fall back on the english versions. You can do this sort of thing either at the build stage, and have fully populated language trees, or with server tricks. Another dimension is automatic language negotiation. Apache supports it, but how many browsers do? > The non-english pages are maintained by a group of native speakers, on a > server local to them. The documents are distributed through CVSup, so that > any FreeBSD Web server can provide any language version it wants. Local information should certainly be provided by local mirrors, but for translations of the core stuff, I would tend to favor a unified repository and universal distribution. Excluding the handbook, the web pages don't really take up much space and I doubt we will get more than a handful of translations. It would make partial site translations cleaner to implement and eleminate the current mirror/language dependency. The downside, of course, is the telecommute to the CVS repository in California. Heck, I'm just in Indiana and I sometimes can't even get a usable connection to freefall! Anyway, I'm in finals week now. I need to tune out of this issue until the end of the week.... -john
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970505085456.29300N-100000>