[SGVLUG] Website features (was testing)

[Emerson, Tom]

> -----Original Message-----
> Behalf Of David Lawyer
[...]
> in the static webpage: http://www.lafn.org/~dave/sgvlug.html.

That makes a very nice resume, but SGVLUG isn't looking for a job the last time I checked :)

> [...] I've eliminated some of the
> links.  We don't need a sitemap if the site is only a couple of
> webpages

ahhh, but that's only the case "right now" -- when we add features (that our members have requested), a sitemap will be much more in demand [though in a way, I tend to agree that a sitemap should be unneccessary, or perhaps redundant -- after all, isn't it the point (of the home page) of a site to BE a sitemap in the first place?]  

> [...] The "Calendar of Events" can be short and on the homepage.

which I believe is the case for the "sample" site on phpwebpage -- in fact, it actually IS a calendar (with the "days" as clickable links if there is an event scheduled)  I don't think we did this on the mambo version, but I'm reasonably sure that this is available as an add-on module.  Regardless, this is something that SCREAMS out "build me as a table!", so you'll have those nasty confusing tags to deal with anyway...

> Do we really need a Tools page?

The intent is that these would be member-produced tutorials, discussions, examples, or what-have-you explaining how to use some "tool" (as it relates to Linux...)  [note to self: add in Hershel's link on adding users, as soon as Michael releases the page for me to edit...]

> One could mention tools used to create the site: "Edited html file
> with vim editor over a ssh connection." To save bandwidth, there are
> no images.

If this is how you are maintining your site, by all means, write this up!  We'll add it as a link in the "tools" hierarchy.
 
> Regarding my last post.  I implied that one could maintain the
> master copy of the sgvlug site on their home PC and [...]
> Well, it would still work if only one of
> these two people maintains the site and the other is just a backup.
> [...and when changed externally] It would be
> nice to also know who modified it and when and I'm assuming that a CMS
> would show that info.

yes, you're beginning to see the big picture behind what CMS's offer over "upload and hope you didn't just screw up the other guy's changes"

> So while a CMS might be nice, in the meantime, what about using vim
> over ssh to edit the simplified html directly?

that is EXACTLY what we are doing with the sgvlug.NET version of our site -- this whole CMS investigation is geared toward what we can and should be doing in the future.

> I'm expecting our old
> site to be back online shortly so if you like my rendition (5kB for
> fast download over slow (or fast-:) modems) of the site

[tom at vorean ~]$ cd /var/www/html
[tom at vorean html]$ l
total 128
drwxrwxr-x  7 root     www  4096 Jul 19 08:00 ./
drwxr-xr-x  8 root     root 4096 Jun  3 16:36 ../
-rwxrwxr-x  1 mproctor www  6318 Jul 16 22:51 index.html*
-rw-rw-r--  1 tom      www  2801 Jun  4 08:33 sgvlugStyles.css
-rw-rw-r--  1 tom      www  3998 Jun  4 08:33 w3.html.css
[tom at vorean html]$

[files not pertinent to "the home page" removed from this listing]

the current index page is 6k, which isn't that big a jump from 5k.  A good part of the "additional" space used by this page is "whitespace" used to indent & set sections apart -- this is purely for the poor sap who has to maintain the page "by hand" [ummmm.... that would be me or Mike] as you know that any additional "whitespace" is ignored by browsers when rendering the page.

Addmittely, we have an obligatory "graphic", but downloading images is a client-controlled activity.  The stylesheets do add a bit to the total "page size", and in fact doubles it, but that is mainly because the home-page-content is fairly small.  (besides, don't most clients cache stylesheets if they see they haven't changed?  stylesheets should be far less likely to change than the content of the actual site...)  Also, have you checked a packet-capture of a discussion between a client & server lately?  Many clients support (g)zip compression of the "page", so the actual number of bits-on-the-wire transferred is quite a bit lower than you might expect.  Even still, the .css files can (and should) be "cleaned up" and slimmed down anyway.

> [...] and linuxdoc is too weak and simple to make a flashy
> looking site. 

wait a minute, I thought you were trying to PROMOTE the use of linuxdoc, not detract from it -- please make up your mind!