Explicitly modeling Miller Columns #40

asolove opened this Issue Sep 29, 2011 · 19 comments


None yet
4 participants

asolove commented Sep 29, 2011

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:

  • The client code could save your current Path and let you pick up from the same place when you return later.
  • You could send a link to a friend that captures not just one story, but the current Path of stories you are refactoring.

I would appreciate your thoughts before I begin.


WardCunningham commented Sep 29, 2011

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.



WardCunningham commented Sep 29, 2011

This jQuery will answer an array of page ids (slugs) in the order they appear on the screen:

 $('.page').map(function(i,p){return $(p).attr('id');})

SvenDowideit commented Sep 30, 2011

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'?


asolove commented Sep 30, 2011

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:

  • With a clearly-modeled "Path" we can also talk of a "Path History" similar to the history of a story. The Path History is a record of an interactive session with the wiki. It says: "I started out on this story, then went to this one, then moved a few items from one to the other, then opened another story and added something there."
  • 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.

WardCunningham commented Sep 30, 2011

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.


asolove commented Oct 4, 2011

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/Smallest-Federated-Wiki@833786c More to come!

hellekin commented Oct 4, 2011

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.)


asolove commented Oct 4, 2011

@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.


asolove commented Oct 5, 2011

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.


WardCunningham commented Oct 5, 2011

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.


asolove commented Oct 6, 2011

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.


WardCunningham commented Nov 18, 2011

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:

  • id which is the page name slug.
  • data-site which is the remote domain name when the page comes from a remote site.

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.


asolove commented Nov 18, 2011

See: https://github.com/balupton/History.js/

I can take a shot at fixing it to work with remotes tomorrow.


asolove commented Nov 21, 2011

Ok, I was a bit overambitious and didn't make much progress on this. The plan is simple enough

  • render data-remote="server.com" and data-name="welcome-page" attributes on all the pages
  • combine the remote and the name to create a unique ID for each page on the dom
  • update all code that was using the ID as the page name to be aware of the data-name attribute and use remotes if needed.

WardCunningham commented Nov 21, 2011

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...


WardCunningham commented Nov 30, 2011

Well, again my terminology has been careless. I should have said "origin", the site from which the javascript has been loaded. So if I started at foo.local then I would get my javascript from that site and it would be the origin and its pages would have data-site == null (or no data-site attribute).

Indeed, null is way better then :) +1 for "origin", it's much clearer.


WardCunningham commented Jan 20, 2012

Although not perfect, this capability is very useable now. Further discussion should be part of issue #100 or in a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment