Navigation & pages

[alexyork]

How should we handle navigation and pages?

From the mockups, we have 4 main pages, and each page has at least one "click-through" sub page. Bear in mind that one of the features is that it should have the ability to run in offline mode (I am not sure if that shapes our thinking or not).

Thoughts?

[hegerokenes]

Regarding the offline mode it doesn't matter if we go with single or multiple pages. We make a manifest file that lists all the offline resources, so the moment you access one of the page the browser reads the offline manifest and downloads all the files listed in the manifest.

Here is a good article on offline mode: http://diveintohtml5.info/offline.html

[yornaath]

We could use hashchange or pushstate where it is supported. Preferably using a library that exposes a abstracted routing api, uses pushstate and degrades gracefully to hashchange.

For example page.js http://visionmedia.github.com/page.js/

That way we don't break the back button.

[alexyork]

Yeah, that looks sweet. Have you used that before?

[yornaath]

I haven't used page.js but the api seems very similar to the one express.js for node uses. And that I have used several times.

Though at first code glance it doesn't seem like it supports hash change. Is that a deal breaker? As stated before, our users will likely be using modern browsers, supporting pushState.

[yornaath]

I have implemented router navigation into the src code now. Using the backbone router in favor of page.js. I have also included a lightweight nodejs server to run the app so the routing works correctly.

You can easily use apache if thats your cup of tea using src/frontend as root dir.

[alexyork]

Awesome! Seems like it works great. I think using the Backbone router was a good choice. Node is also my preferred server :-D

The next big challenge is to have each page drill down into a details-view. i.e. click on a session and drill down to the session details. Not breaking the back button is essential here, because the typical user workflow will be top click into a details view, then click back, etc.

I'm not sure what to use as the #id for the session, since they don't have ID's. Thoughts?

[yornaath]

Cool! I love node :)

Hmm, im not sure if I understand what you mean about ids? Do you mean what we should use as the unique identifier for a session "row"? If so why not just use the title concatenated with date and time?

For not breaking the back button we can make the route parameterized /sessions/:id and programmatically open the correct row if id is supplied. When the user then hits back to /sessions it will render the same sessions but not open any row.

[alexyork]

Yes, I meant a unique ID for a session row, so that when a user clicks on a session and navigates to the detailed info about that session, they have a URL that they are able to copy/paste and still have it work.

Session title + time would work. The solution you describe above sounds like a plan. I will assign this task to you :-)

[yornaath]

Il take a look at it soon :)

[yornaath]

On second thought, maybe the easiest way is to just assign the sessions a unique int? As with speakers? After all we have full control over the data :)

[alexyork]

You are right, this would make the Sessions easier (especially in the URLs). Maybe we don't need it with Speakers though, since we know they have unique names? Or should we just do it for consistency?

[yornaath]

Lets do it out of consistency. Would make the transition to using a database easier too if we need to at a later stage.

[alexyork]

Agree. It is now done :-)