public inbox for [email protected]  

help / color / mirror / Atom feed

From: Dave Page <[email protected]>
To: Robert Treat <[email protected]>
Cc: Omar Kilani <[email protected]>
Cc: [email protected]
Subject: Re: Alternate PostgreSQL.org Design
Date: Fri, 12 Nov 2004 15:38:47 -0000
Message-ID: <E7F85A1B5FF8D44C8A1AF6885BC9A0E43070FE@ratbert.vale-housing.co.uk> (raw)

 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Robert Treat
> Sent: 12 November 2004 15:08
> To: Dave Page
> Cc: Omar Kilani; [email protected]
> 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

view thread (59+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Alternate PostgreSQL.org Design
  In-Reply-To: <E7F85A1B5FF8D44C8A1AF6885BC9A0E43070FE@ratbert.vale-housing.co.uk>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox