ArchitectingAndRefactoringWebSites

Most consultants today are known first by their web site, then, if somebody finds them potentially valuable, by various "warmer" communications such as e-mail, phone, interview...

Like the AYE Wiki, web sites are subject to entropy, scaling "stretch marks" and aging / obsolescence of material.

Further, clients and friends may develop"deep links" directly into content pages of interest: [on Jerry's SHAPE forum, my Favorites link leads direct to "Inside SHAPE"]

Consider the pain and nuisance of large [slow loading] graphics on entry pages. Consider the user experience. What things have you discovered that make a difference [good or bad] to the effectiveness of your web site?

I think that a discussion of "design by contract" and refactoring as well as general architectural principles applied to personal web sites would benefit many of our consulting members.

The material could also be of interest to people contracting or assigned in [re-]design of client web sites and/or Wikis.

What do you think folks?

BobLee 03/14/02

from RequestsAboutTheProgram

WIKI reality organization:

Pages named "New ...." and "Last Year's ..." need to be rotated, and the term "LastYear" should become 2000, 2001, 2002... to avoid search & frustrate.
I'd like to see 1 page named CurrentYearIndex that points to pages named Year_2000_Sessions as appropriate. Then, one cut'n'paste to Former_2002_index... would make "NewBlahBlah" with future tense last edited in 1999 less of a time trap.

I noticed the AYE Web site clean-up by BobKing, [see AppreciationPage] and suggested to him that a session on ArchitectingAndRefactoringWebSites would be of interest to many if not most of the consultants here. He suggested that we move the idea into the Wiki for discussion. Sounds good to me!
BobLee 03/14/02

I find that I rearchitect my web site every two years. (I've had a web site up since 1995, and I've had 3 major rearchitectures, and I'm starting to think about the 4th. I find that the more I talk to the people who use my web site, the better I can make the architecture. Duh :-)

For this year, I'd like suggestions on what to call the sessions. I number the session in my program database, but just because I number them there, doesn't mean I need to number them here. What would you like to see for a design for the current year's sessions? How is that the same or different from previous year's sessions? -- JohannaRothman 03/14/02

I've been calling the A, B, and C(2002) in my database, and appending a 3-digit session number. I know this is limited to 26 years or so, but so am I. (I'd be happy with 2 alpha and 2 numeric, which should last us forever or so.) I would like the scheme to show that a session is the same (roughly) as one offered earlier. We plan to bring some popular sessions from 2000 and 2001 back this year, for those who missed them.

Besides, websites do need to be rearchitected every two years or so, in my experience, so renaming the sessions shouldn't be too bad, either, if we have a consistent scheme. - JerryWeinberg 3/14/02

"Let's see if we can have fun in 2026" Y2K + 26. I feel a 2-digit date weakness all over again! Are we striving for anything more than just a unique key in the session identifiers? The Wiki page names need to be unique with at least 2 upper-case letters? Currently I see:

SessIdnnn - Sessions from year 2000.
SessionOnennn - Sessions from year 2001.

The prefix of Sess or Session keep these pages distinct from arbitrary collision.

The only purpose of Id or One is to make it a WikiWord for either 2000 or 2001. Jerry's "A, B, C, ..." would be cleaner, but SessionC002 doesn't make a WikiWord, SessionCyr002 does.

The nnn is the unique but [mostly?] meaningless portion. The leading zero is kind of silly, but orders them in the search List All facility.

So Jerry proposal implies SessionCYr002 as the name for 2nd session year 2002. Presumably, we could rename SessId002 to SessionAyr002 and SessionOne002 to SessionByr002 for consistency.

Note: The above shows the problem with WikiWords - things with numerics tend to get ignored by the WIKI Parser. See WordLikeThis
Here are some words that do and don't work:

SessionA001 SessionAa001 SesAa001 SesBb001 SesIdA001 SesAi001 SesBi001

This would really be a LOT simpler with all alpha session ids:

SessAaa SessAab SessBaa SessCaz

BobLee 03/16/02

See KeithRay's piece in ClimbOutOfTechDebt on costs of examining poorly refactored code. This applies to customers of web sites, too. The more clear the organization, the less "hide and seek" is needed by customers coming with "I think it's in there somewhere..."

Our Wiki is still fairly easy to encompass - I can scroll through "list all pages" output in about 8 scrolls. [your mileage may vary] But, as any site ages, it accretes new glitches in its layout, needles get hidden deeper in the haystack, etc.

In coding terms, NameSpaceManagement gets hard. It becomes harder and harder to make up new, sensible names without colliding with existing names - applies to both pages and to links.

Object Oriented languages attack namespace by qualification. Names only need to be unique within class, within file, etc.

Web pages can afford some heirarchical qualification, but it isn't visible or obvious to customers who see a "link" as a "goto". They don't process web sites in heirarchical sequence.

How have you practitioners coped with accretion?

BobLee 03/19/02

Updated: Tuesday, March 19, 2002