Forums: Discussions for entrepreneurs and small business.

Hello Everyone. I have a general critique/implementation request for a very large, complex online help database that is implemented with XHMTL/CSS. This is a question for advanced designers ... but everyone is free to chime in!

The table of contents for the help is implemented being implemented in two ways for the purpose of testing. The first method uses the <ul> element to present the table of contents as a set of bullets.

http://www.scenomics.com/documentation/help.stm

The second method uses <table> elements to present the contents in a more standard visual form, as you might find in a book. Table-less layout is a big deal but W3C says that tables are appropriate for tabular data. I think a table of contents qualifies.

http://www.scenomics.com/documentation/commands.stm
http://www.scenomics.com/documentation/interface.stm

Either way, there are going to be a lot of nested tags.

Which approach is better? As far as I can see, neither approach scales better/worse than the other.

[Also, this help is under construction. You will find things that don`t yet work.]

Scaling is important because there are around 500 pages already and 1000 graphics. The page count will increase over time. [The site makes heavy use of server side includes.]

Some technical writers have commented that the <ul> based design doesn`t have the right look/feel for a table of contents and that the <table> based design is better.

I think that yes, this is an appropriate use of a table.

I also like the table design better because the separations are nice.

I would probably use the tables with appropriate labels (we`ll call them "upscale" tables) over bullets or any dt/dl moves.

I would opt to also do some smarter design and not nest tables, but to do your nesting in the backend code (table of contents is in a database, no?) and use css classes to give the appearance of nesting. If that makes sense ... and if it doesn`t, I can write you a snippet.

Thanks for the input; I really respect your opinion. General consensus prefers the table layout. The <ul> layout doesn`t look right ... people seem to expect it to behave like a tree control ... and although that could be done ... avoidance of Javascript is a key design issue here.

The nested appearance is controlled by CSS in this stylesheet. So the table is just a straight table <table>, <tr>, <td>, with nested tags as required by table structure.

http://www.scenomics.com/css/page.css

[ See "Table Of Contents Styles " at the bottom.]

The table contents are not in a database as there would be very little gain since it`s just a list of hyperlinks ... albeit a long list. There are also design issues with database use.

The page source for most of the pages is shown here.

Database and Javascript are avoided because each page needs to be transformed into printed pages and be easily portable to Microsoft`s compressed HTML document format for distribution on end-user machines. So, it`s actually easier to use a database-less design that ports very easily. Basically to ship this documentation as compressed HTML requires a table of contents in the build environment and that`s about it. Should take less than 1 day. Similarly, a printed form should be relatively easy to build with CSS. So those are some of the requirements there.

I also have an additional question.

Some experimentation has been done with providing "Back" links at the top of the pages. However, this doesn`t really scale well, and using the back button is easier as it returns you to the exact place in the previous page, so you don`t have to scroll down through the table of contents to find your place again, for example. What do you think of this?

Feel free to post a snippet of CSS code and Thanks Again!

Hey CookieMonster

You don`t really appear to be using the table to present tabular data. I`d use lists and style them appropriately with CSS.

    Rich


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

Blog - http://www.buggy.id.au/

What I`m saying is (just so everybody else knows for future reference), instead of using nests like

<table><tr><td>
<table><tr><td></td></tr></ table>
</td></tr></table>

you do this

<table>
<tr class="main"><td></td><td></td>&l t;td></td></tr>
<tr class="sub1"><td></td><td></td>&l t;td></td></tr>
<tr class="sub2"><td></td><td></td>&l t;td></td></tr>
<tr class="sub1"><td></td><td></td>&l t;td></td></tr>
<tr class="sub2"><td></td><td></td>&l t;td></td></tr>
<tr class="sub2"><td></td><td></td>&l t;td></td></tr>
</table>

The reason for this is that tables within tables tend to have the same load issues when they get so large ... this is the reason why people moved from the crazy all-table design. To the user, this looks the same as the nested tables without using them. Just apply the CSS to create some hierarchy (usually adding left padding, alternating background colors, font changes, things like that) without nesting.

I think CookieMonster`s site is doing a pretty good job at that, with the fake nesting.

And yes I agree about the database thing. I`ve made manuals for video games, and you use all html/css so they can put it right on the CD. (The TOC is considerably shorter though!)

The thing about javascript and back functions is that they only work if the user goes that way. Some people might click to open in a new window and then close the child window to get back to the TOC.
The questions is this ... if they click on a link from the TOC, do they get an option of subnavigation to choose from? If not, a bit that says "[link] Table of Contents ... or use your brower`s back button" is fine. (OK, something like that, mine sounds bad - I`m going to blame daylight saving`s time!)

The thing about using straight HTML is this ... KISS. Because you don`t know what browser or setup they are using, and you can`t detect with programming. So whatever makes it easier for everyone is best.

Rich, Thanks for the input! Not yet sure what`s going to be done and I`m not the final word on the contents layout.

Nikole, Thanks for the additional information. I`ve debated whether or not to put in backward navigation link buttons, either <a> or javascript. These don`t make sense in all contexts, so probably should be avoided.

The back button, or BACKSPACE key, makes it relatively painless to navigation backwards. I think backwards navigation options in the page are rather superfluous, and have a per-page cost in terms of memory.

The idea of opening the page in a new window from the TOC. Well, to be honest, I don`t like this either. Funny, though I`m not necessarily a standards-freak ... well actually I am ... I really believe in not breaking document flow.

Actually, another question. There is the possibility of deploying a version of this using frames and a javascript tree control. It`s already implemented but it doesn`t really work well in Firefox ... hard to style the frames. The IE frame styling relies on a few dirty hacks, but the help itself looks/works pretty awesome.

I know frames aren`t a favorite technique ...

Rich, Is there any benefit to using lists instead of tables?

A list with sublists seems to be a more natural fit. It just feels like you`re using a table for presentation purposes rather than because you actually have tabular data. With a list anyone using a screen reader may have an easier time skipping sections instead of being forced to read the entire table.


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

Blog - http://www.buggy.id.au/

I didn`t mean you make them open in a new window. I mean, your users might, therefore destroying your navigation.

(For example, being the impatient page loader that I am, I have about 8 SUN tabs open in one window right now.)

Rich - how is a table of contents not tabular data?

In all honesty it doesn`t matter. You can put them all in p tags too, with left side padding. I just don`t like bullets for this unless you`re using some roman numeral outline format.

In fact, I was going to suggest something MORE table-like. I was going to suggest hierarchy in backgrounds on each section heading. Like

BLUE
    light blue
    light blue
    light blue
RED
    light red
    light red
    light red

OK those are hideous colors but it does make it pretty obvious.