Frame-based layout

[UloDeTero]

Well, I decided to make a mock-up of how Cantr would look with a frame-based interface.

In this example, the left-hand pane deals with data-related pages: Character Info, Project Info, Name Change pages, etc, while the main page deals with the various main sections of the game (Events, Inventory, etc)

There's also an initial "Title" page made up of the Player Info (that's usually at the top of every screen) and the Character and Player menus (that are usually at the bottom of every screen). Maybe a timer could reset the left-hand screen to the"Title" after a minute or so, otherwise the player can just click the character's name at the top of the main screen.

Note, not all of the buttons and links function, but feel free to 'explore'!

[link!]

[Rossato]

Well, ProgD has almost no time, and the true load on the servers aren't the navigation, but the calculus of animal migration, food, sneeze, project increase, etc. So, it would be a lot of work with no real gain.

Of course, it would be faster to us to play, but the efforts may be too big for the benefits.

[Torkess_theCommie]

I can see how this can help make navigation easier and faster...
but I've never been a fan of frames. (-___-")

Just my 2 cents..

Edit:
I don't know much about servers but would frames help a bit since the menu (left frame) would only have to be loaded once when you're on a character?

[joo]

Ah, this is when at last I get to voice the idea which I have been holding back for fear of the very fate that this thread has suffered...

The future of Cantr: Client-Side XSLT Transformations with DHTML...

I'll leave the rest to your imaginations.

[tiddy ogg]

I guess all that means something to techies. The main thing needed for this game is for it to be accessible to almost everyone, preferably to those using Lynx, other text-only browsers, Windows 9X etc.
Although frames have given me no problem, I think some adaptive software don't like 'em.
And I've no idea what that bunch of acronyms above do.

[joo]

The server could still dish out the old HTML pages to those who have old browsers... but maybe in the long run, when the ProgD have more time, they could start to add more dynamic elements for top-end browsers.

To expand on my previous comments, I hold the belief that since most of the data being transferred to the client is presentational in nature, it makes sense to keep that presentation content, like layout, colours, images, etc... in a static XHTML page with CSS styles loaded into the browser. At opportune moments, the page will request XML packets from the server containing the raw data to be updated on the page... I don't know whether this could be done better with Javascript, as in the scripted build menu, or XSLT, which as far as I know reloads the page with the XML.

In any case, this is something for the very long term, maybe even a from-the-ground-up Cantr III years from now...

[w.w.g.d.w]

It is necessary to change more because such a connection new with old looks strange (only manufacturing a helicopter (balloon,zeppelin?) 1% is good).