(Forwarded from non-list mails)
On Wed, Aug 04, 1999 at 11:24:18AM +0200, Asger Alstrup Nielsen wrote:
> > But I still think we
> > need something better than having everything in the main directory. If we
> > have 30 files in the main directory, it will be confusing for people who
> > want to edit pages.
>
> No, it's not. You find the page you want to edit with your browser, and
> see the filename there. Start your editor and edit the page.
> Come on, the main LyX source directory has hundreds of files, and this
> is not a problem, even if we do not have the luxury of using a browser
> to find the one we need to edit. Why should it be a problem with many
> 50 web-pages?
(1) I think the LyX sources would be easier to look at---especially for
newcomers---if they were in subdirectories. And in fact Lars *did*
reorganize things that way, although apparently just partially.
(2) OK. My original argument was kind of dumb. But IMO maintenance is easier
if things are nicely divided up. Yes, I'm probably too obsessive about it,
but I think it's useful for organizing things.
> I agree that pictures and "logical" units such as the LGT should go into
> a directory by itself. But it's a mistake to demand that all pages
> should go into it's own sub-directory, just because you fear that it
> will be confusing. I find it more confusing to have all these
> sub-directories because that makes maintainance a hell, and it doesn't
> even work, and we have the cookie-hell as well.
It only makes maintenance a hell if you have a badly designed system. If you
have a well designed system, it makes it easier. And I admit you get more
cookies, but once you've accepted 1 cookie, what's so bad about 5?
> The reason that sub-menus make things harder is that you can not see all
> available pages, and therefore you have to try and guess where this and
> that page is: First you click on "About...", well, it's not there, so
> then you try "Download...", but that didn't find it either. Hmm, maybe
> it's "Developers" and so on.
[and from later in the mail:]
> The top nav-bar is a problem because there is not enough space to
> present all the different pages in one go. Therefore, we have to settle
> to present only the groups, and not the entries inside each group,
> because of space considerations.
This problem would persist and be even worse using your suggestion for the
top navbar of only having the main topics. Then you *really* have to guess
where pages are.
> Grouping the pages into groups is a good idea, but all pages should be
> visible in the navigation bar, IMO. It should be visible immediately
> which pages are available in a group -- you should not have to expand it
> to see.
> Them it's much easier to find something, and you get a much more
> immediate impression of what is available on this site.
There are currently about 15 different pages. You want to put them all in
the navbar? What about when we have 20 pages? 25? No, I don't know what
will be on those pages, but we ought to build this system so that it can
expand if necessary.
I suppose a potential option would be to require a side navbar and use an
intelligent scheme to list the main menu & sub menus, e.g. using a bigger
font for the main pages, and/or indenting sub menus. The main start.php3
would be much simpler without all the top vs. side code.
> Sub-folders is a powerful tool, but it should only be used when
> appropriate. It has advantages and disadvantages that should be
> considered before applying, just like any other tool has to be evaluated
> before it's used.
Of course. So far we've had three votes for sub-menus and one against. Plus
a rather large number of "yes by default and laziness" votes.
> I suggest that we only have one start.php3 page which contains all pages
> in the system. Having local start.php3 in each directory is a
> maintainance hell, and we will end up with something which isn't an
> improvement of the old system -- if we want to change the nav-bar, we
> have to go around and change it in many files.
> The entire point of the start.php3 file is to avoid this problem -- all
> pages are registered one place, and one place only.
I admit that it might be better to leave the whole database in one place.
(Although perhaps we should put it into a separate file to be included by
start.php3? Which would also make creating a site-map really easy.)
While I am not entirely opposed to getting rid of the local start.php3's, I
don't think they're as bad as you're making them out to be. My way of
thinking was that if you want to change the main navbar, you should be
editing the main start.php3, while if you want to change a subnavbar you
should be editing the sub start.php3. And it's not like that will be
difficult to find. If you're editing or adding a file in a given directory,
you edit the start.php3 in that directory. That seems like *less* of a
maintenance hell to me. Although the only web site maintenance I've done
before is the lyx web site, so maybe I don't know what I'm talking about.
> I proprose a compromise: All pages are registered in start.php3 in the
> main folder. We have sub-directories for some things, like the LGT and
> a few other relevant items, like maybe the pictures from ILDM.
> We add a new customization option: "All pages visible?" which will
> present all pages in the nav-bar if chosen. If not, only the group
> headings are displayed, and you have to click to expand them.
I'm only slightly opposed to a new customization option. While I realize
people should be able to customize things, a well designed site should be
able to satisfy most people with the defaults. (And we may want to combine
the cookies if we'll be having three per page.)
While I'm all for compromise, there's still the option to try and fix the
sub-directory system---although for reasons that I don't think you've yet
proven, you seem to think that the system is unfixable. Taking the ILDM as an
example (ignoring my previous email), you could put ildm.php3 in the main
directory & have the jpgs in a subdirectory as you say. If there are lots
of pages of pictures, you could create a new subdirectory that would hold
them, and add that directory to the list in start.php3.
Perhaps we need to make clear what sort of maintenance we expect will be
necessary, and how that will work or not work based on different systems.
Editing one file of course works either way. Adding a file requires adding a
line to start.php3. Adding a set of files would require creating a new
subdirectory with its own index.php3 (which can be very sparse, simply
listing links to the other pages), then doing several iterations of
"adding a file" above. Doesn't sound too hellish to me.
Breathlessly awaiting responses from Asger or others.
-Amir
