I am looking for suggestions and advice about an idea I had for adjusting the client-side code.
My goal is to refactor the current client coffeescript code, which uses the dom to implicitly create the Miller Column metaphor, and explicitly model the columns and their state with a new idea: a Path. A Path is simply the current set of stories you are reading and their order.
I think this is a natural direction for the software to grow, and allows a number of easy developments:
I would appreciate your thoughts before I begin.
There is some leftover code server side for bringing up multiple pages before internal links simply did this:
Try view-source for this to see how simple it is.
There is some convention for manipulating "history" when building ajax views. I haven't looked into it but you are welcome to give it a try.
I've looked into bfcache that preserves ajax constructions while back-forward navigating in mozilla. Safari does it too, but chrome doesn't. This doesn't give you a url you can email. That's worth some effort. Give it a try.
This jQuery will answer an array of page ids (slugs) in the order they appear on the screen:
a path - being a journal of clicks? - interesting (though I can't quite see where i would use it)
I'm about to write a node.js server (ok, probably next week, when the girls goto playgroup for the day), and I'm going to write it so the server does no html rendering of pages - leaving it all up to the client (cos the code duplication and massive size of the server irritates me :) )
does that mean you'll be adding a toolbar like thing to the client? or where do you view, save and send the 'path item list'?
Sven: I would prefer not to add a toolbar, it should simply work. When you open a story, the browser's url should change to an emailable url for the current state of your page.
A few more uses for a path:
The Path History is a natural way to model an undo/redo system for allowing people to experiment with changes and then revert them.
You could also use it to record and play back an interactive session, either for use in a public presentation, for demonstrating a particular feature of the wiki, or reviewing a colleague's changes before pulling them back into your wiki.
Any version of a page could be reconstructed by playing-forward the list of journal actions up to that version.
Replay won't work for many of the sample pages because I haven't been meticulous about making the journal match the story. The way to fix that would be to make an empty page, say new-default-welcome-visitors and drag each item from welcome-visitors to the new page.
Just committed a minor change that supports setting the browser url to a representation of the currently-viewed pages. This provides copy-and-pasting links, and returning to the same place if you press "back" after clicking on an external link: asolove@833786c More to come!
I love that functionality, asolove! As I see it, the URL should not grow when recording history: each session should be assigned an id, like any other wiki bit, and each visited id could then be recorded there, under, say, /path/abcdef. When you want to share it, you can review it to edit the history (you might want to skip some pages, e.g. to provide a linear reading of a hypertext for printing, etc.) and save that selection to a special page (maybe a "child" of the original, unedited history.) You could also maintain a session record, to resume a session at any point (e.g. in the context of a federated classroom.)
@hellekin: I think there are two separate modes. When just browsing the wiki, the url should encode the current state of your view, so you can bookmark it, share it with others, or return to the right place when using the back button. Now, if you decide to record a session, then yes, the url should change to some url where you or other users can view and follow that session. But there's a long way to go before we can do that.
I am going to start work tonight on improving the Miller Column UI. Based on the notes in the Wiki, I see that we want to use side-scrolling when displaying more columns than fit horizontally on the page. That should be pretty easy to change. I also suppose that, like the Miller Columns in the Mac Finder, we will want vertical scrolling to be limited to each story, rather than vertically scrolling the page as a whole? I'll build it that way and make a publicly-accessible version so everyone can try it out.
Awesome. The Twitter app on iPad does the side scrolling with clever use of overlap. It works similarly, but not the same, on the phone. A good strategy here is more important that perfection at the moment. I appreciate your help.
I have some rough code at a3e41ed. It demonstrates that side-scrolling is pretty useful, but also hard to get right. Tomorrow I will try adding keyboard shortcuts for scrolling left and right, and perhaps automatically scrolling the page if you hover over a half-shown page near one of the edges.
I'd like to incorporate remote server addresses into the Miller Column logic and History url formation.
My work on Issue #42 makes this possible on the server side. Right now each wiki page in the web page has:
The Miller Columns act up when there are multiple welcome-visitor pages. This happens often when retrieving remote pages. It would seem that the correct solution would be to factor the site name into the page id logic somehow.
Ok, I was a bit overambitious and didn't make much progress on this. The plan is simple enough
This sounds like right approach. data-site="server.com" is already there (null if local). Using null for local makes some code simpler, other code more tedious.
Just an idea popping up from the top of my head. Maybe $hostname.local would be better than null, when using zeroconf e.g., in hackathons where people share the same room and can also share their git repositories over the bonjour protocol. Or on VPNs...
Indeed, null is way better then :) +1 for "origin", it's much clearer.
Although not perfect, this capability is very useable now. Further discussion should be part of issue #100 or in a new issue.