Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Re: Alternate PostgreSQL.org Design
Date: Fri, 12 Nov 2004 15:38:47 -0000
Message-ID: 
 <E7F85A1B5FF8D44C8A1AF6885BC9A0E43070FE@ratbert.vale-housing.co.uk>
Thread-Topic: [pgsql-www] Alternate PostgreSQL.org Design
Thread-Index: AcTIyXv2dYfCkLQFQA2rpyq4w8ra2QAArxNA
From: "Dave Page" <dpage@vale-housing.co.uk>
To: "Robert Treat" <xzilla@users.sourceforge.net>
Cc: "Omar Kilani" <omar@tinysofa.org>, <pgsql-www@postgresql.org>

=20

> -----Original Message-----
> From: pgsql-www-owner@postgresql.org=20
> [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
>=20
> please note I am dropping -advocacy from this discussion=20
> since I need some focus on www work

Good call.

>=20
> One problem I have with Lukasz design is that some of the=20
> subsection really scream out for second level navigation.=20
>=20
> In Lukasz design, we end up re-propogating the right nav bar=20
> on every page which I think is bad because it uses a lot of=20
> screen real estate while adding little/no substance to the=20
> secondary pages. For example, do we really need a link to=20
> external community sites on every page? =20
>=20
> In something like the "Overview" section, I would like to add=20
> in content like case studies, gui tools, advantages, and=20
> other sections from advocacy and techdocs websites, but this=20
> mean putting all of these subsections on the main "overview"=20
> page, creating a long scrolling lists that have to be gone=20
> through to find content. I think it is easier for people to=20
> scroll short lists of subcategories in a left hand nav like=20
> in the "About" section of the tinysofa design.=20
>=20
> These underlying structural issues need to be addressed=20
> regardless of what design we use.=20

Yes, agreed.

> > 2) What happens if xyz web design comes and offers us another great=20
> > design next week. Do we start again? Where/when do we draw=20
> the line?=20
> > If I'm honest, based on our agreement to use Lukasz' design I think=20
> > that line should be drawn already.
> >=20
>=20
> If we agree that there are some underlying structural issues,=20
> then either that needs to be addressed in the current design,=20
> or we need to swap. I understand that we don't want to just=20
> toss Lukasz' work out the window, but if we were developing=20
> an application and we found flaws in some piece of it, and=20
> someone else coded up an alternative implementation, I don't=20
> think we would discount the new idea simply on the grounds=20
> that we already have an existing implementation.=20

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=20
> fairness, the new design also has some structural issues,=20
> like fixed width, that would also have to be addressed before=20
> we could use it)=20

Also agreed.=20

I should add that I do actually quite like this design, at least as much
as Lukasz'.=20

Regards, Dave