[SGVLUG] Website Testing

[David Lawyer]

[regarding a note on the Internet saying the the sgvlug site was
boring] 
> On Wed, 20 Jul 2005, David Lawyer wrote:
> > I saw this too when I was checking out some links to sgvlug.org.  I
> > think the person who wrote this is wrong.  Our site quickly, simply
> > and rapidly provides info on sgvlug.
> 
On Wed, Jul 20, 2005 at 08:39:37PM -0700, Dustin wrote:
> Two things: first, "boring" is an aesthetic judgement.  Second, while you
> say "Our site quickly, simply and rapidly provides info on sgvlug" in a
> context that suggests that you are offering it as a counter-argument to
> the assertion that the site is boring, in fact it has no relevance to
> boring.  Both can easily be true, and in fact I think they both are true.

Quick simple and rapid tend to imply the opposite of boring so my
assertion does have some relevance to boring.  I suppose it's possible
for both to be true but I don't think it's so.  Since boring is a
subjective judgement, there's no way to prove either point of view.
I would think that "cool" and "flashy" etc. would clearly be aesthetic
judgements but "boring"?  I'm not so sure.  Do you want the aesthetics
of a site to try to favorably bias your evaluation of the content?
Shouldn't the surfer want neutral aesthetics.  So a cool site may be a
negative aspect in the social welfare sense.
> 
[snip]
> > There's also the universal markup method which is something like an
> > html editor.  You create a page in say docbook or linuxdoc using vim
> > and then run it thru a filter to get hmtl, plain text, pdf, etc., etc.
> > Docbook is a very powerful markup language but why use it to create
> > html pages when Docbook is equally as complex as html.
> 
> This doesn't actually solve any of the problems of writing plain html in 
> vi--it's brittle, higher maintenance, and doesn't allow delegation.  In 
> fact, it's worse in that it has a higher learning curve.

If writing in linuxdoc is a lot easier to learn that writing in html,
then it does solve the problem of writing in html.  You don't write in
html but write in linuxdoc.  The downside is that you both need to
learn linuxdoc and also don't have the ability to use many of the
features of html which linuxdoc doesn't support.

> Universal markup is a solution to an entirely different problem than we 
> have, unless you frequently find yourself thinking "if only I could sit 
> down with a hot cuppa in front of the fire and read the SGVLUG website on 
> my laptop in PDF form."

You're right in that one wouldn't be using the features of "universal
markup" to convert to various markups other than html.

Note that in my previous post I coined the phrase "universal markup"
as I've never seen that term.  Well, I found it on an internet search
but it was used with another meaning: a full featured markup which
would tag by both content and presentation.  Html is like this but not
"full featured".   It doesn't have tags for dividing a page into
chapters, sections, subsections, etc. all with a machine-created table
of contents.  I don't think xhtml fixed this either.

> I don't find myself wanting to do that all that often.
> 
> > > The problem with using "just a plain text editor" is that once you
> > > get to "more than one person doing the work" [or even "one person
> > > using more than one computer"], you need to invest in a
> > > revision-control mechanism of some sort anyway -- otherwise you'll
> > > get changes overwritten by "the other guy with the older version of
> > > the page..."  
> > 
> > Not if you use the copy on the server as the master copy and update
> > it by editing with vim via ssh.  One could log their changes inside
> > an html comment and keep a history of changes there, to be removed
> > every couple of years when it becomes too large.
> 
> Yeah, vim does a kind of primitive file locking by creating a hidden
> "dot" file while the editing takes place.  Now what happens when I
> decide to use emacs while Tom is using vi?

You could always type "who" to see if Tom (or whomever) is logged in.
Or both use vi.

> 
> > There are other ways too.  Suppose we have two co-maintainers, each one
> > of which agrees to maintain the site for a 3-month period and then
> > take 3 months off.  Or they can negotiate between themselves for
> > variations: one fills in while the other is on vacation, too busy,
> > etc.
> 
> This kind of thing is not very workable for volunteer organizations, 
> because things change.  People legitimately have things that take 
> priority, and it is unrealistic to expect such a system to work for long 
> periods of time.

It would work if the two people agree to look for a replacement when
one of them no longer has time for it.  Also, the organization has to
have publicity to bring in new people to replace the ongoing loss of
people.

> It *is* better than unloading it all on a single victim like Charlie, but 
> introduces problems of its own (I thought you were doing this meeting).
> 
> > Also there can be two or more ssh login accounts on the server.
> 
> AFAIK, that is precisely what Michael wants to avoid for security reasons.
> Sure, we could just give everyone in the LUG a shell account and delegate 
> as much as we want.  It isn't a real solution.
> 
> > So there are simple ways to do this for sgvlug without any revision
> > control system.
> 
> We can all invent many, many schemes for doing things manually.  What you 
> don't seem to understand is that the people who are maintaining the site 
> seem to be very clear that they do NOT want to do things manually if they 
> don't have to.

Connecting to the site by ssh and editing with vi is about the same
effort as going to the site with a browser, logging in, and then
editing.  In any case one has to type in the changes.  And the vi-ssh
allows the use of a powerful editor that one already knows.

In both cases there is the problem of who to give access to and how
they will coordinate their work.  For the CMS case, there's the
problem of who will administer the CMS, including a backup person to
take over should the administrator leave.  Plus there's the time of
investigation various CMS's (partly done) but this may be of interest
for other uses of CMS systems.

> > But as I explain above and Tom explains below, sharing the work
> > doesn't require a dynamic site.
> 
> Are you saying you personally would like to maintain the site indefinitely
> on your own?  I don't hear anyone else with much interest in doing it the
> hard way.

The "hard way"?  I've never used ssh but it seems to have automatic
login like ftp, wvdial, or minicom (to login to bulletin board sites
before the Internet took over).  Since when did I say I would like to
maintain the site?  Well, I'm willing to give it a try for a few
months, provided someone else works on the task of listing sgvlug on
various lists on the Internet.

> > ...For the Linux Documentation Project
> > (LDP), the hosting site would not allow the use of Plone, partly due
> > to alleged excessive bandwidth needed by Plone.
> 
> That was almost certainly excessive server load, not bandwidth.
I think you're right.
> 
> In any case, this is what testing is for.
> 
[snip]
> 
> AFAICT if we implemented your solution we would have a similar problem--so
> far only you find it in the remotest attractive.  In fact your solution is
> more or less identical to what we've already been doing and are doing
> right this minute, and Tom (at least) has told you so.  The fact that the
> people who are using it at this minute don't much like it says something.
> 
> Dustin

OK, fine.  But I'm saying that many of the problems we have at present
will still exist with the CMS.  I don't think it will be a great deal
of help unless we want to have a much larger site.  But I'll talk
about the tools issue in another post.

			David Lawyer