[SGVLUG] Test site update -- mambo stuff

[Tom Emerson]

On Sunday 07 August 2005 8:57 pm, Dustin wrote:
> On Sun, 7 Aug 2005, Tom Emerson wrote:
> > I'm really liking the Mambo site manger -- I think it will work well for
> > the types of things we want to do with the site:
>
> Is that your way of saying that we have a winner? :-)

Unless someone willing to take up the plone, twiki, phpweb, or >gasp< 
edit-by-hand banner and put forth a rallying cry for that as the new site, 
well, then yes.  [of course, I'm still waiting for input from those that are 
volunteering to actually manage the site -- I'm willing to give volunteers 
extra votes, but they have to vote for something in the first place...]

To be honest (fair?) there are some things I DON'T like about the way Mambo 
"does things now" [as well as many things I think could be done better].  The 
big winner, though, is the fact that Mambo is a bit more structured(*) than 
the others.  For the purposes of a user-group website, "structure is 
good"  (as David has pointed out, users tend to want to find certain things 
and find them fast -- having important items show up "wherever" detracts from 
the usability of the site...)


> > ...]  I think I can also enable "ratings" to get an idea of how
> > well liked a given meeting will be (was?)  
>
> There is a big danger in things like that.  [they become self-fullfilling]
> I'm not predicting the bias--only that there will probably be one, and it
> might be a bad idea to place too much emphasis on beauty contests.

Well, I DID say "...it looks like it may be of limited use".  Of course, since 
"ratings" will apply to all "articles", (even if they aren't about a 
particular meeting), it will provide *some* feedback to the authors of other 
content, who can then revise as needed [here is where "comments about..." 
make more sense than a random 1-to-5 star rating -- if everyone things your 
article is "bad", but doesn't take the time to tell you what's wrong with it, 
you'd be hard pressed to fix it...]

Tom

(*) The way I see it, the spectrum from imposes-the-most-structure to least is 
probably mambo, phpweb, plone, twiki [edit-by-hand can fit anywhere, 
depending on the skill and perserverance of the author...]

  -- Mambo is like a magazine or newspaper, and in fact the terminology 
reflects that -- you have sections & categories, "the front page", and so on.  
Just like you can expect to find the comics at the same place in your 
newspaper each day, you'll find the meeting announcement(s) in the same place 
each month.

  -- phpweb can be structured like mambo, but it takes some work on the part 
of the author(s) to maintain it.  I'd say it is more like a community or 
high-school newsletter in that while the editors may strive to have similar 
content from month to month, there is no guarantee it will look the same as 
last month

  -- Dustin observed the following about plone: plone is for people who 
eventually want to learn zope.  (roughly paraphrased)  Maybe it's a mindset 
sort of thing, but it doesn't appear intuitive as to how end users will 
"view" the site -- if I write it up this month, it appears under "my" page; 
if someone else does next month's it'll be under his -- end users won't know 
where to "go" to get the latest meeting update.  [I could be wrong -- 
dedicated plone users are invited to help "educate" me in the nuances of how 
it's better than mambo -- of course, you'll have to buy plenty of beer and/or 
coffee before I'll listen...]

  -- twiki is just simply a way to edit pages "by hand" without the benefit of 
shell access (and with some amenities so far as actual entry of text and 
other elements)  "Structure" only comes about if the moderators impose it 
[and collaborators follow the guidelines]

-- 
blogref temporarily disabled for the Rabbi's benefit ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://vorean.sgvlug.org/pipermail/sgvlug/attachments/20050807/46648690/attachment.bin