here are my comments from the latest discussions.
Stas Bekman wrote:
> :: * The TOP^ link is not obvious that it's link. I think it'd be nice to
> :: have it of the same style as [prev - up - next] widget, so it'll be
> :: clear what are navigation widgets.
> ::
> :: * The [prev - up - next] widget is neat but should be centered and
> :: appear on the top as well. Before the table of contents I guess.
Jonathan M. Hollin wrote:
> I strongly agree with both of Stas' points here. From a useability point of
> view, I'd also recommend that you don't deviate from standard link colours
> (blue - unvisited, purple - visited) - navigational cues are critical to any
> sites success. Bruce Tognazzini, Vincent Flanders, David Siegel and the
> irrepressible Nielson have all lectured widely as to why, so I don't think I
> need to reiterate here.
i dont agree 100% on this.
but i think we should agree on how we seprate navigation-styles.
i see 4 major element-types:
menu-navigation ("boxed" or plain link style)
breadcrumb (some unique style or possibly in a "long-row"-style)
prev-up-next-navigation (widget-style)
top/toc-navigation (maybe this should just be good image? or
a unique font)
i dont really see a great need for the
"toc"-inline-reference, so i think we should throw that away.
and the "top"-reference really should not be like any other
navigation style as it will always point to the current page
page.
about link colors. no matter what any experts i think
designers should choose any link-color they want as long as
they are cinsistent through the site. i might be we loose a
little on userbility on link colors but we also have to look
at our potential "customers". i reckon anyone visiting the
mod perl site will be able to navigate it even if the link
colors differs from the standard and even though they are
not underlined. also i guess, they will apear standard on
non-stylesheet complaint or off-stylesheet browers.
> * Finally the font looks quite bad on mozilla/linux. There is not enough
> vertical spacing and I guess there are better standard fonts, to make it
> easier to read. I think Thomas' font selection was very good
well in my own opnion microsoft have done _one_ good job in
creating the best screenfont currently in existence.
this is probably a matter of personal taste and i certainly
dont mind helvetica.
by the way both letter-spacing and line-height is easly fixable.
> which also means that the original Thomas' design problem wasn't solved
> yet. If the page has a little or no content the content box will shrink
> and look bad when you browse pages. And it'll move the left part of the
> page closer to the center. Somehow we must make it fixed, so when you
> flip between pages, the main parts of the page don't move.
either i dont understand this problem or it doesnt happen on
any of my browsers.
the left navigation is has a fixed width (200px).
the content is relatively fixed so as when you decrease the
window-size tonly the content area scales down (*var_b*).
Thomas Klausner wrote:
> I don't (want to) work to gurantee cross-browser capability, but standards
> complienance. If the browsers are not standard compatible, it's the
> browser manufactureres problem, not mine. You only have to inform the
> users politly that, if they are seeing crap, it's their browsers fault.
i agree 100% with this
> I don't like the idea of using HTML tables to structure a site. Tables are
> good to present tabular data, but (IMO) shouldn't be used for page layout.
while i agree on this point i have never found it pracically
possible to avoid tables.
> Some new comments:
> I think that the background color of the breadcrumb trail (never knew it
> was called that, BTW) and the Table of Contents can be done better using
> CSS.
well i must disagree, those are ASF-colors and i honestly
think they are quite great. in fact i was quite surprised to
see such a great color-scheme from the ASF when i revisited
the site. (they are quite new arent they?)
> Allan, do you think you could do a "proper" release of your new design, so
> we can work on that?
i really would love to but
1) shouldnt we first all pin-point down a more narrow design guideline
2) i am simply too busy during the next couple of weeks (im
moving to vietnam)
Thomas Eibner wrote:
> What ever you guys decide on in the end I hope you will come up with
> something that enhances the documentation and doesn't distract from the
> actual content.
very good point which is often forgotten ...
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
