If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

First, would be the 'accessible' way, which would mean multiple page-loads and most of what you are doing being handled server-side, not client side. Frankly, I'd never build a single page that size in the first place; waste of bandwidth if the end user doesn't visit all the options. NORMALLY this would be what I'd advocate as a page SHOULD be made to work -- without scripting -- LONG before you EVER think about adding JS to a page.

Sort of like a search engine where the person selects search terms instead of types them in?

Originally Posted by deathshadow

That said, you've built an application, not a website -- and there is a difference.

That difference leads to my second approach; since none of your elements on the page are the least bit useful when scripting is disabled, I'd have generated 99%+ of your markup... from the script. Quite literally between your <body> and </body> If I was writing that page, the content would probably have looked like this:

EVERYTHING else on that page generated from the script. It would be far, FAR less code, and properly gracefully degrade. It would also mean you could store hooks to the generated elements (preferably built with DOM methods) in objects and arrays so you don't need any of those classes. That would speed up the page's responsiveness since you wouldn't have any getElementByxxx in there either.

The reason I didn't was I was really leary about building such a large page through JavaScript (especially with the colours table, which was hand-coded)--though I agree that DOM methods would be the way to go.

Originally Posted by deathshadow

Oh, and that 'view' popup has to be the most annoying thing ever. I'd try to find some alternative to that. Maybe at least modernize/center it with a lightbox type effect since it's current behavior results in buggy/broken/hard to use scrolling.

How do you use a lightbox?

Originally Posted by deathshadow

Really though a LOT of the data in there I'd be loading via AJAX; there's no point in sending client-side data they aren't actually viewing.

AJAX? Would you believe I've never used it?

Hmmm... *Thinks.* Lessee... I got it! PHP and Framesets!

But aside from annoying popup, does it function okay as an application?

Sorry for the delay, got your PM... (I'm horrible about "notifications" on forums)

Originally Posted by Mr Initial Man

Sort of like a search engine where the person selects search terms instead of types them in?

That's the idea. It's probably not all that practical though given the nature of the data.

Originally Posted by Mr Initial Man

The reason I didn't was I was really leary about building such a large page through JavaScript (especially with the colours table, which was hand-coded)--though I agree that DOM methods would be the way to go.

Thing is with the nature of your data, it would be less work to update and maintain as you wouldn't have markup getting in the way, you could just have arrays of arrays for all the data, or objects filled with objects, or a mix.

Originally Posted by Mr Initial Man

How do you use a lightbox?

I'm not a fan of the usual lightbox scripts per-se, but in this case it would make sense to use the effect which is pretty simple. You make a position:fixed div with a black transparency to 'darken' the page making it clear the stuff on the page is no longer active, then you position:fixed another div offset from the edges of the display set to overflow:auto so it has it's own scroll. Because it would be fixed in place, it wouldn't be as confusing or have the scrolling issues I encountered with what you have now.

Originally Posted by Mr Initial Man

AJAX? Would you believe I've never used it?

It's complex, it's tricky, not surprised. I know HOW to do it, but other than on forums or CMS for things like post submits I generally consider it to be overused -- see the people who use it to replicate frameset behavior.

BUT, since you've basically got a web application, not a website, it operates under different rules. Though the more I think on it, the more I'd consider keeping the data in the scripting, not the markup.

Originally Posted by Mr Initial Man

But aside from annoying popup, does it function okay as an application?

It seems to, though it's hard for me to say since I'm completely unfamiliar with the data or what it does. It feels a little... busy -- what is sometimes called "link overload" from presenting too much information and too many unfamiliar choices to the user all at once, but again that could just be my ignorance of the data, what it's for, and how it's used in "Furcadia"

You'd probably have the same reaction to my little reference sheet I made for myself in making ships for the game "Freelancer".

I used XSLT many years ago. It worked. The adoption was low but implementing it was fun. XML however, is a very memory intensive structure as the entire structure has to load to process data. It was a good idea, it worked, but doesn't scale.