[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEUL: WWW site issues
> First, what minimum browser spec are we designing to? For instance, we
> could have a rule of "everything must be readable by XXX". XXX being,
> for instance, Lynx or Netscape 2. This is not to say that there can be
> no tags not recognised by the minimum browser (eg font sizes), just that
> someone using this minimum must not loose any content.
That is an issue we have to deal with. There are several ways to do it,
with increasing reliance on proc power and software on the server side.
The current site has been designed to look as good as possible in Lynx,
while retaining its presentation under Netscape. If you look at the code,
you'll find that the ALT tags for the sections are tied to dummy images,
not the actual graphics. This allows Lynx to show the section titles
before the text, rather than after.
If we want to be truly browser independent, we'll have to make sure that
all the docs that have some kind of specific presentation are served by
some kind of cgi-bin program. The parser arma wrote, combined with a good
set of handlers based on what I've written, could be optimized and used to
server/cache pages for appropriate browsers, possibly running as a Fast-CGI
program or other setup. However, the more we rely on these things, the
less likely it is we'll find sites willing to mirror for us.
> In the longer term: This is not very relevant at present, but eventually
> I can envisage two almost separate sites being required: one for
> development and one for potential users investigating SEUL.
> At some point I think the two sites will have to separate, with the
> users' one being www.seul.org and containing a link to the dev site
> (maybe seul.org/dev) for anyone interested.
We've thought about how to keep them separate enough, and I think we have a
1) all files in specific public_html parts of the CVS repo will be checked
out into a given place, tagged for en masse revision control, and will be
designed to provide the end-user site.
2) files placed into html/ subdirectories *anywhere* in the repo will be
checked out sans the 'html/' part, and should be designed for the end-user
3) files placed into doc/ subdirectories, again *anywhere* will be checked
out into the website, and can contain whatever you like. This is so that
docs for various packages (ours or someone elses) will always be available
on the web.
(see http://www.omegacs.net/~omega/seul/dirhier for examples)
This doesn't address the issue of separation between church and state, er,
developers and end-users, though. I don't know if there's a good way to
enforce that, but I think as long as we define what is end-user and what's
developer, we'll be OK.
One way to do it is to assume that html/ stuff is *always* for the
end-users, and anything in doc/ is for developers. There's nothing keeping
html and sdoc files out of doc/, so it can be used for anything. For
instance, dev/ui/doc/index.html might be the developer homepage for the
user interface group, even though dev/help/xhelp/doc/README is part of the
xhelp distribution and is raw text. (I hope that made sense... :)
This does need to be discussed, however.
Erik Walthinsen <email@example.com> - SEUL Project system architect
/ \ SEUL: Simple End-User Linux -
| | M E G A Creating a Linux distribution
_\ /_ for the home or office user