Subject: Re: Alternate PostgreSQL.org Design

From: "Dave Page" <[email-masked]>
Date: Fri, 12 Nov 2004 15:38:47 -0000

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

---

From: "Gavin M. Roy" <[email-masked]>
Date: Fri, 12 Nov 2004 08:51:08 -0800

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:

>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to [email-masked])
>  
>

---

From: "Marc G. Fournier" <[email-masked]>
Date: Fri, 12 Nov 2004 13:14:16 -0400 (AST)

On Fri, 12 Nov 2004, Gavin M. Roy wrote:

> 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?

Once change to the new design has to be made before it can be drop'd in, 
and the banner has to be added to the right menu like it is on the new 
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.
>> 
>> 
>>>> 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. 
>> 
>>> (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. 
> TIP 6: Have you searched our list archives?
>
>              http://archives.postgresql.org
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: [email-masked]           Yahoo!: yscrappy              ICQ: 7615664

---

From: Robert Treat <[email-masked]>
Date: 12 Nov 2004 14:53:20 -0500

> > subsection really scream out for second level navigation. 
<snip>
> > regardless of what design we use. 

here is a more concrete example of a structural issue. One of the items
on the TODO list is getting some initial integration of
developer.postgresql.org into the main site.  I came up with the
following structure that I think would work fairly well for integrating
the two sites:

Developer/
	Roadmap/
				TODO
				unapplied patches
	Coding/
				bios
				cvs retrieve
				dev lists
				translating
				info/
					flowchart
					db internals
					implementation
				(howto build for linux/win32)
				(db projects ie. odbc,jdbc,dbd,etc...)
				(howto on writing docs)			
	Testing/
				beta
				dev docs
				dev docs 5 min
				(autobuildproject)
				(nightly builds)
				(report a bug)
	Tools/
				cvs - web 
				cvs interfaces - web
				(lxr)
	FAQ/
				faq

Basically we start with a main nav "developer" link, which takes us into
the developer content. This content cant be broken down into a number of
subcategories (RoadMap, Coding, Testing, Tools, FAQ), which would have
further content underneath them. I've added some items in () to show
where future content might grow into. 

In the lukasz design, I would basically be forced to have the main
developer page be a list of links that scroll down the page. In the
tinysofa design, we could put the subcatagories into a right hand nav
bar with content or further links into the main section, and it would
not be cramped in like we are with the main nav bar. 

Now, we could probably accomplish this with the luckasz design, though
all we have seen are repeated right hand nav bar style pages. The
tinysofa design has the advantage of already seeing how these types of
subpages would look. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL