[sword-devel] CrossWire website

[Peter von Kaehne]

Chris Little wrote:
> 
> 
> Peter von Kaehne wrote:
>> With regard to browser inconsistencies I am trying to keep the two
>> stylesheets in sync, but if I missed something, please tell me.
>>
>> I also do think there should be ways of making it work with a single
>> sheet, making IE fail gracefully rather than badly. Any suggestions are
>> welcome. I presume the key will be around exploiting a non implemented
>> child/relation pseudo class type CSS thing which will work everywhere
>> but for IE6
> 
> The CSS non-application issues I've seen (which result in the unordered
> list being displayed as a bulleted, unordered list instead of a menu
> bar) have been on FF3 & Safari, on different systems, at different
> times. If there are bugs on those browsers, then there's code that
> should not have been rolled out to the public site yet.

The only reason I can see for that is that the style sheet was not
loaded. This is not likely a browser or code problem but a problem with
the network connection at any given time. When this kind of thing
happens a refresh sorts it usually and that is well understood by most.

It is maybe the one single downside with using a separate CSS sheet
instead of of inline styling, but it is more than outweighed by the
increased flexibility CSS offers (including the option of viewing a page
unstyled).

>> I have chosen a different coloring to highlight the fact that you moved
>> to a sub section with a different navigation. I am happy to use any
>> other color there apart from the original, which is taken.
> 
> Your desire to color pages differently should be subsidiary to the basic
> issue of usability and legibility. If you couldn't come up with a good
> color other than red, you should not have changed it. Again, purple is
> not good on those live sites.

As I said, increased usability is the reason for the choice. Prettyness
of the colors is/was secondary. Suggested color schemes which do the
same job while being prettier will be gratefully accepted and applied.

>>>>> 3) I still believe the "Read the Bible" link should be in the menu
>>>>> bar,
>>>>> highlighted by virtue of being offset far on the right.
>>>> Off site links should not be in the top menu.
>>> According to whom?
>>
>> Navigation menus are by general convention intrasite menus. Please show
>> me a well designed site which does do this differently.

List based top menus are frequently used on pure CSS tabbed designs, but
often break badly on zooming/narrow screens with a single tab vanishing
down sideways.

Swordweb is an example. For this reason I have chosen a menu bar which
simply wraps. It does the same as e.g. SwordWeb, but it does it in a
better way.

> Here are some quick examples from 2 minutes of browsing:
> www.ebay.com (Their menu links at top-right go all over the place.)

That very same menu stays put all the time while the overall design is
clearly the same site too. It is easy to move around different sections
and you always can get back to where you where.

> freshmeat.net (Last, "scoop" link goes offsite.)

Uses incidentally  the same wrapping list design as you highlighted
below.  I agree that scoop is there and it is bad. It makes very little
sense

> www.logos.com (Last, "view/checkout" link, with appropriate
> highlighting, goes to a site with significantly different design.)

Appears clearly all the same site, including the checkout link. I do
like the separate highlighting and I can see that that works for a
proposed Bible link. But even then the shop application sticks to the
same overall style. So, my suggestion to create a SwordWeb incarnation
which fits into the site remains standing.

> www.google.com (not a great example, but the final, dropdown menu item
> includes a link to YouTube)
> eff.org (The donate to EFF link is raised and offset, similar to how we
> had the Bible link.)
> gnu.org (Highlighted "Join the FSF" link goes offsite)

The day anything associated with Richard Stallman is promoted as
fashionable and stylish is surely a day Richard Stallman will mark red
in his calendar. But again, I like the highlight.

> fsf.org ("Shop" link goes offsite)

You are right and it is not good.

> The gnu.org link is almost identical to what I've proposed: Bible link
> far to the right with additional highlighting.
> 
> (I'm still waiting for that list of sites where wrapping menu bars can
> be found, but I'll point one out of the above that does it:
> freshmeat.net. But they've probably got the worst design of the lot.)

They do. Both. But the list as such is not the main problem.

All the others start horizontal scrolling at very little restriction.

And the sole reason to introduce the list based menu istead of a table
based one was/is the from multiple sides here on the list expressed
desire to avoid horizontal scrolling at all costs. The original
suggestion was a single line table with some flexibility in table cell
width. This worked well down to 400 px or so, but multiword links
started to wrap within the cell. We have too many multiword top links
and that is a separate but relevant problem.

My suggestion is to revert to my original design of a single line table
  based menu and live with the fact that multiword links wrap internally
on side way push. Somewhere you have to make a compromise. This would be
mine.

In the end I have come to the conclusion that life is far too short and
my working relationship with you to important to fight further about this.

Given that our views are pretty much irreconcilable my suggestion is
that we seek consensus here on the list or, failing that ask Troy to
make a final decision.

The options as I see them are

1) unordered list based menu
	- advantage - no horizontal scrolling on narrow devices/screens.
	- disadvantage - the wrapping is possibly non standard (well 			
Freshmeat...)

2) single file table
	- advantage - well established standard design.
	- disadvantage - breaks on narrow devices in two ways - first 			
wrapping inside cells, eventually sideway scrolling.

3) two file table as previously used.
	- advantage - works well on mid range narrow devices
	- disadvantage leads to horizontaql scrolling pretty soon
   		non standard, not nice on wide screens.

My personal order of preference is 1), 2) and then 3).

Yours appears 3) and nothing else, though maybe you would also agree
with 2), at least you appeared to be less upset about 2).



>> They should at least anticipate that something is not
>> standard about the link.
> 
> I wasn't surprised by any of these, but I do think additional
> highlighting will clarify the specialness of the link.
> 

Surprise is a part of the problem. Impaired navigation a bigger. the
lack of unity in our design and (more importantly) linking policies
impairs navigation.

With this I suggest we close the discussion about the top menu.

If I missed any (dis)advantages of the any of the options listed above,
please add them.

Leave it to the others to hash out, we are only getting upset with each
other for no good reason. I respect you too much for going down this
path, though I was very upset with the tone you employed in the last few
days. I do not want this.

-------------

Leaving the menu aside, the immediate problems left according to you are
the coloring of links and subsiduary sites.

My suggestion is that you propose colors which work. RGB codes, hex
codes instead of vague suggestions. I think it is not up to me to come
up with colors you might like. I changed what was there because of a
very specific problem with usability/accessibility. I dealt with all
specific problems you highlighted in this area.

I made progress. It works. It is up to you to make explicit suggestions
to make it work better.

Peter