Re: Alternate PostgreSQL.org Design - Mailing list pgsql-www
From | Dave Page |
---|---|
Subject | Re: Alternate PostgreSQL.org Design |
Date | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E43070FE@ratbert.vale-housing.co.uk Whole thread Raw |
In response to | Alternate PostgreSQL.org Design (Omar Kilani <omar@tinysofa.org>) |
Responses |
Re: Alternate PostgreSQL.org Design
Re: Alternate PostgreSQL.org Design |
List | pgsql-www |
> -----Original Message----- > From: pgsql-www-owner@postgresql.org > [mailto:pgsql-www-owner@postgresql.org] On Behalf Of Robert Treat > Sent: 12 November 2004 15:08 > To: Dave Page > Cc: Omar Kilani; pgsql-www@postgresql.org > Subject: Re: [pgsql-www] Alternate PostgreSQL.org Design > > please note I am dropping -advocacy from this discussion > since I need some focus on www work Good call. > > One problem I have with Lukasz design is that some of the > subsection really scream out for second level navigation. > > In Lukasz design, we end up re-propogating the right nav bar > on every page which I think is bad because it uses a lot of > screen real estate while adding little/no substance to the > secondary pages. For example, do we really need a link to > external community sites on every page? > > In something like the "Overview" section, I would like to add > in content like case studies, gui tools, advantages, and > other sections from advocacy and techdocs websites, but this > mean putting all of these subsections on the main "overview" > page, creating a long scrolling lists that have to be gone > through to find content. I think it is easier for people to > scroll short lists of subcategories in a left hand nav like > in the "About" section of the tinysofa design. > > These underlying structural issues need to be addressed > regardless of what design we use. Yes, agreed. > > 2) What happens if xyz web design comes and offers us another great > > design next week. Do we start again? Where/when do we draw > the line? > > If I'm honest, based on our agreement to use Lukasz' design I think > > that line should be drawn already. > > > > If we agree that there are some underlying structural issues, > then either that needs to be addressed in the current design, > or we need to swap. I understand that we don't want to just > toss Lukasz' work out the window, but if we were developing > an application and we found flaws in some piece of it, and > someone else coded up an alternative implementation, I don't > think we would discount the new idea simply on the grounds > that we already have an existing implementation. Hmm, I don't think it's quite the same as a code issue though, as it's a lot more subjective. I see what you mean though. > (In > fairness, the new design also has some structural issues, > like fixed width, that would also have to be addressed before > we could use it) Also agreed. I should add that I do actually quite like this design, at least as much as Lukasz'. Regards, Dave