[conspire] not mentioning years (was Re: July schedule posted)

[Rick Moen]

Quoting Tony Godshall (tony at of.net):

> I went to a BayLISA event at Yahoo a month or two back.
> 
> It happened the year before.
> 
> Egg on my face.

I can well imagine.  But it wasn't my calendar that sent you there.

> Not mentioning years in web pages is one of my pet peeves.  What,
> people who write articles think the web is transitory?  Almost makes
> me want to do all my websurfing through archive.org's wayback machine
> where at least the infrastructure tells you when the page was editted.

There's definitely some strong merit to what you're saying, here.

A public calendar that goes unmaintained for more than a year, _and_
omits mention of the year from included events, definitely becomes a
menace to users.  I try to never let that happen.  ("So, don't do that,
then.")

It happened briefly on BALE when Deirdre and I were both stumped by
sudden, mysterious silent breakage of the newmonth.py monthly cronjob
script that populates new months' events rows in MySQL from the
eventtemplate table.  (Root cause turned out to be a MySQL upgrade to a
version that suddenly required COMMIT statements before INSERTs would
work.  This was tough to spot because everything used to work and it
wasn't obvious what if anything had changed.)

While the PHP/MySQL-based version of BALE was broken, I dealt with the
situation by renaming index.php to index-save.php, and reverted to
maintaining a flat-HTML index.html file manually in vi -- until we
figured out the SQL problem.

Additionally, both the BALE and CABAL pages _do_ mention the year, at
the bottom -- the BALE page in a copyright line, the CABAL page in both
that and a "Last modified" timestamp line.  That's definitely not
prominent, but it _is_ there.

I've put a lot of thought into information presentation on BALE, over
the years, and tried out a number of experiments.  One of my resulting
rules is that the top and especially top-left of a page needs to house
_only_ the most-vital information.  Less-vital data needs to be banished
to down below or on subpages, if present at all.  So, you'll see each
BALE line is maximally terse, with key details bolded, and a hyperlink
goes to either a tag further down the page ("#svlug") or to an offsite
page ("http://www.communityleadershipsummit.com/").

The "Last modified" line on the CABAL page is pursuant to one of my
other rules, that you need to reassure the user that the page is still 
maintained, because so many pages on the Web aren't, and are misleading
the way BayLISA's calendar was with you.  

BALE used to have such a line, but lost it when it got automated using
PHP and MySQL.  This has always bothered me, but at least the copyright
line serves much of that purpose.

Quoting my advice to new LUGs on
http://linuxmafia.com/faq/Linux_PR/newlug.html :

   18. Make sure every page has a revision date and maintainer link.

   It's traditional to put some variation on "Send feedback to [link]" or
   "Copyright (C) 2000 by [link]", or "Webmaster: [link]" where "[link]" is
   the maintainer's name with a "mailto" hyperlink. And there's a good
   reason for this tradition: It ensures that "feedback" comments -- from
   sharp-eyed readers who catch errors, omissions, and ambiguities in your
   public information -- will reach the right person. Make it easy for the
   public to help you, and some of them will.

   Putting a date stamp at the bottom of each page, whenever you update it,
   reassures visitors that the site really is current. You may know that
   it's a living site with current data, but newcomers won't. Dead sites
   with obsolete data are far too common on the Web, and the date stamp
   marks your page as freshly edited. (Equally, it reminds you of when you
   last overhauled the site.)

   Need I mention that the worst-maintained LUG sites in my area lack
   revision dates and maintainer links? It's true.

Including "2009" ot "2010" (etc.) in each date would compromise -- at
least to a small degree -- my rule about maximum terseness for lines in
the top section.  Again, quoting my advice to LUG leaders:

   13. Place time-sensitive and key information prominently near the top
   of your main Web page.

   Don't banish all meeting information to your events page, or tuck it
   into an unobtrusive text box for aesthetic reasons: Ensure that the most
   prominent items on your site are the ones viewers need most. Consider
   using "STRONG" or "EM" HTML tags on particularly important items, such
   as your date formula (e.g., "second Tuesdays at 7 PM").

   Displaying time-sensitive information prominently is useful not only
   because that tends to be what viewers seek most often, but also because
   such text calls your attention to itself, when it needs updating. Think
   of this as comparable to putting perishables near the front of your
   refrigerator, date-stamp outwards.

So, basically, I am reluctant to widen the date column to include year
data because that is not time-sensitive, key information.  I _will_
consider it, though -- as it's only about five additional characters per
event.

I'm trying not to get pigheaded just because my calendar's (BALE) been 
around for twelve years and clearly meets a lot of people's needs well
-- but I do have considered reasons for many of its inclusions and
omissions.