public inbox for [email protected]  

help / color / mirror / Atom feed

From: Gavin M. Roy <[email protected]>
To: Dave Page <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: Omar Kilani <[email protected]>
Cc: [email protected]
Subject: Re: Alternate PostgreSQL.org Design
Date: Fri, 12 Nov 2004 08:51:08 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <E7F85A1B5FF8D44C8A1AF6885BC9A0E43070FE@ratbert.vale-housing.co.uk>
References: <E7F85A1B5FF8D44C8A1AF6885BC9A0E43070FE@ratbert.vale-housing.co.uk>

Since this design is "drop-in" ready requiring only minor changes, 
perhaps we should resurrect the idea of a vote (maybe on Advocacy).  Any 
thoughts on that?

Gavin

Dave Page wrote:

> 
>
>  
>
>>-----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
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to [email protected])
>  
>

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], [email protected]
  Subject: Re: Alternate PostgreSQL.org Design
  In-Reply-To: <[email protected]>

* 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