SEUL: Re: Test WWW site [long]

[Erik Walthinsen <omega@omegacs.net>]

(If you're confused about the path references [i.e. pub/public_html], 
there's an explanation about 2/3 of the way down)

> I'm not quite sure about how the development and public sites are
> separated : am I right that they currently share a front page and then
> diverge? My suggestion would be making the two almost entirely
> independent sites. The public one must, of course, start at
> www.seul.org, but the dev one could be behind that at an address that
> everyone would know (seul.org/dev), with a link from the public
> homepage. I realise that there is already a 'development homepage', but
> this seems to be geared to explaining the various groups to the public;
> I'm thinking of something giving direct access to news, decisions, etc.
The split is a tricky one.  I do want to have a distinction, though.  
dev/html/ (..org/dev/) will be the development homepage, with something 
else existing in pub/public_html/ (maybe development/) to provide the 
public face.

Almost everything in dev/*/html/ will be designed as a homepage, and should
be targeted mostly towards developers.  Some teams might be more 
public-oriented, which is a good thing for some groups.  dev/*/doc/ will be 
used for hard-core documentation and technical stuff, like changelogs and 
so on, but html/ will always be 'softer'.  More further down in this mail.

> 1. I like the design of the front page. However,  this quickly goes
> downhill in the rest of the site. I realise that while using sdoc it is
> not possible to have graphic section headings (which look really nice)
> rendered for each one. Might it be possible, however, to have all the
> letters available and have sdoc put them together?
Aldo is trying to get a couple people at his college to work on graphics, 
and I think we can have sdoc create the right images on-the-fly (at parse 
time).  Using separate letters won't have the desired effect, and isn't 
exactly efficient.

The look of the webpage doctype does need some work though.  The advantage 
of sdoc, of course, is that we only need to change the doctype handlers, 
rather than all 50 or so pages we have so far.

> 2. The 'about this site' link at the bottom: once the reader has got
> used to the blue text higher up simply being blue text, there is nothing
> to indicate that this one is a link. It took me a long time before I
> realised. I can't offer any obvious suggestions on how to improve this,
> but it needs addressing.
True.

> 3. Personally, I find it annoying to have *every* instance of the word
> 'SEUL' a link to www.seul.org. Particularly those that are already on
> the front page. ;-) Again I suspect this is an sdoc thing, I guess it's
> a case of doc authors not using the special tag for every instance of
> the word SEUL if there are lots in a paragraph. Call me fussy if you
> like!
To create the link you just put <> around SEUL.  I do that out of habit, 
but it is indeed in the hands of the doc writers.  I like the convention, 
though I agree it might be dropped on the front page.  It's up for 
discussion, and really should be decided before we get too much further.

> Another minor annoyance is that there is no way to tell whether a
> hyperlink that says, for example, 'Erik Walthinsen' is going to go to a
> WWW page about you, or email you. Can I suggest adopting the convention
> of putting mailto: links in italic?
Makes sense.  Though I want to point out that I'd like everyone to have a 
homepage on cvs.seul.org, even if it's just a "Hi!" page.  A default could 
be created and adduser modified to hack that up too.  I dunno, something to 
think about.

> 4. What's new : I have the following suggestion to make: Keep the
> various 'what's new' pages, with their sections according to topic, but
> in addition when they are very new duplicate them on the front page.
> They are then removed from the front page after a couple of days, so
> that there is never more than one or two screenfuls there. This idea is
> taken from www.annihilated.com - although that has too much on the
> front page. I check that site every day, and all I have to do is glance
> at the front page to know whether anything has changed that interests
> me. This is a great time-saver.
Yeah, this is a good idea.  The main reason the existing whatsnew stuff is 
where it is is that we had no better place to put it when they were added.  
Two of those (announce and website) do belong in the pub/public_html/ tree, 
but the third (newdevlists) belongs in the dev/ tree.

Some method for keeping the news list both populated and expired is 
needed, though.

> Uh... whoops... I just realised the mailing lists really perform this
> function. In which case we need to ensure that whenever a significant
> update is made to the site, first of all -pub is informed, and also
> whichever group(s) the update concerns - for a general update that would
> be -project.
I don't think we'll want to be sending news announcements to lists all the 
time.  The bigger news items will be sent to seul-announce, and seul-pub 
will be intimately involved in any major site updates, but other than that, 
the lists will be pretty much left alone.  It's up to the leaders to 
announce things if they feel it's necessary.

> 5. Suggestion : Turn the left-hand blue strip on the homepage into a
> separate frame, and put a full(ish) site map on it. This then remains
> wherever you go on the site. Makes it much easier to find your way
> around. However, care would have to be taken not to exclude people who
> couldn't see this frame, eg because they're using Lynx or something.
> Does anybody still use no-frames browsers nowadays? I can't see our
> target audience using them, it's probably just developers who might be,
> if they prefer text mode or something.
We can use the no-frames tag to provide a merged version of the homepage.  
A navigation frame would be cool though, especially if it were dynamic, say 
a different nav bar loaded for the dev site.


> Who has the responsibility for writing content here? Is this -pub's job,
> or that of the group? Either way, material needs to come from the groups
> concerned (either sdoc stuff, or details of what needs to go on the
> page, what their current tasks are, etc.)
The group in question is in charge of the content, as you say, but how the 
content is managed is up to the leader of the group, or whoever is 
appointed.  If that person is comfortable doing the work themselves, good, 
though there should be some cross-checking by -pub.  If the person doesn't 
want to do it, someone from -pub will have to step in and help them out.

> I have noticed the glaring absence of a page for the -pub group... (as
> opposed to /pub/doc, which should really be docs and nothing else, IMO)
Yup.  Right now, though, -pub doesn't have much definition.  It handles the 
website and not a lot more.  Once it has more to do, then the webpage will 
be more necessary.  There should be one right now anyway, though.

> This page seems to have an identity crisis at present. Is it supposed to
> be for the public to see what the various dev- groups are about, or is
> it supposed to be a regular stopping-point for members of the groups? If
> the former, then it's probably got most of the info it needs,
This page should be for the developers.  What is there now should be moved 
to a developers/ directory in pub/public_html/, as the public face.

> I see no reason why the public and dev sites should not be completely
> separate from each other, as I have said above.
Agreed.

> In fact, a different design for the two might be a good idea to make the
> distinction.
Also possible.  All it takes is changing the doc-type line in the sdoc 
source for all the affected documents, then writing the handlers for that 
doc-type.

> Perhaps keep the blue bar down the left of the whole public one, and make
> it a different colour for the dev site.
Nice idea.  Combined with the frame-based constant nav-bar, that might work 
quite nicely.

> : CVS, if it has any kind of web-based interface,
There is one, but it's a little lame, and it needs help.  It should be 
accessible as http://cvs.seul.org/cgi-bin/cgiweb.cgi.

> mailing list archives,
They're handled in pub/public_html/archives/.

> the project management system that I read about somewhere on the site,
I don't like the one I have listed, and it has the disadvantage of 
requiring an sql and php/fi, neither of which are running on cran, nor will 
be for a while, as they are difficult to build just right.

We need a decent project management system tied closely to CVS that's 
web-based.  I have ideas, but they're ill-formed.  I'll think about them 
some more and write them up, so someone can look into writing something.  
But for now, I'm the project management system ;-}

> While decisions will be made in individual groups, they may (and probably
> will) affect the other groups in many cases. So how about a centralised
> 'decisions index'.
Once we have the decisions process down, I do intend to create a 
centralized database.  How to do that depends on how the decisions stuff is 
implemented.  That's another thing I'm going to have to coredump on..

> Err... am I being thick? Where is this? If I type
> http://www.seul.org/test/pub/public_html/, I get a file not found. Have
> I got the wrong idea here?
OK, sorry about that.  I've developed a naming convention that arma and 
luka and a few others know about and understand, but I haven't explained it 
otherwise:

Anything with a trailing slash is a directory.  Anything without is a file.
Anything with a preceding slash is a partial URL, anything without is the 
CVS repository location.

Any directory with html/ in its path will be checked out into the website 
without the html/.

i.e. pub/public_html/ is the repo directory, which gets checked out into /
dev/html/ will become /dev/, dev/help/xhelp/html/ will be /dev/help/xhelp/

> What's the procedure for doing updates? I'll presumably need to know how
> to use CVS, how to transfer files from my machine to/from server, etc..
> Heck, I don't even know which machine is actually hosting the site!
For CVS, look at www.cyclic.com.  To find out about the machines, go to
the About page on the main site.  I should have the ssh/cvs information you 
need ready rsn.

TTYL,
    Omega


     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user