PathsInHypermedia

MeatballWiki | RecentChanges | Random Page | Indices | Categories

What are PathsInHypermedia?

ElementsOfLocality mentions that Meatball doesn't have "paths" as such. The various IndexingSchemes are more like maps than paths - a path is more than just a link from node A to node B. Imagine the freedom of movements within a public park, and the distinction of paths therein. A path is a navigational structure, not just a navigational potentiality.

Some interesting path rhetorics are described at [Eastgate's] [Patterns of Hypertext] and demonstrated at [Eastgate's Hypertext Garden]

: ''These are wonderful essays, and they suggest that before one goes too far in implementing Paths in Wiki, we should do some empirical research to evaluate the candidate RepresentationsOfPaths . The various hypertext webs referred to in the essays ought to be good empirical testbeds of the utility of the various visualization approaches (e.g., GraphViz?, TouchGraph, or botanical renderings):

which approaches differentiates the various webs best?
which approaches leads to most informative expectations (seems truer to the web being represented)?

: --JonSchull ''

CategoriesAndTopics partially serve this role, as well as any of the OutOfLineLinks IndexingSchemes, like VisitingLink which is implemented in PhpWiki. But neither approach the level suggested here.

See also VisitedLink for a deeper discussion of socially but implicitly constructed paths (Hebbian learning).

Some examples

Within Meatball, and other wiki based hypermedia, it's quite possible for paths to be laid down by the community, just by writing the links into the pages. Consider for example Wiki:OneMinuteWiki, which at some time had links to the next in sequence (ie. Wiki:OneHourWiki), and that page then had a link to the next in sequence (Wiki:OneDayWiki) and so on. Another example would be the TourBus which travelled InterWiki, stopping at each with a minor commentary. These are WebRings, a simple path structure.

Creating paths like this is laborious and fragile though, especially with the more interesting path rhetorics.

: My favourite mirrorworld/counterpoint hypertext example is [Doug Menuez' Digital Moments] It's a gallery of images, arranged sequentially with commentary, with a delightful non-obvious feature of containing a mirror world. To see what I mean, take a stroll thru the gallery, then start again but this time click directly onto one of the images instead of the next/prev links.

A suggested interface/structure model

I imagine it would be possible to build functionality into a wiki engine designed to support paths as an overlaid structure .. a page elsewhere could list the nodes, with optional commentary, and then facilitate travelling that path with the commentary and path navigation visible on the page itself, perhaps as an extra header inserted at the top. A form of TransClusion perhaps? Visiting the individual nodes, without traversing the path (eg. by following some random link) would present the page in it's normal form, perhaps with an attached appendix listing the paths visible from that node.

Hmmm ... maybe the commentary wouldn't live on the specific path's home page, but instead is exists within the nodes themselves. Would SectionedPages help here? I still think the list of nodes should be maintained in a centralised space (the path home page), to facilitate easy construction and maintenance of the path.

Given that any one node may in fact exist on multiple paths, and the path commentary for each could be different, this also touches on the MultipleViews and ViewPoint concepts.

It's also possible that any given node may exist more than once on a path, quite possibly with a different commentary each time. For example, the path may journey a number of nodes, building in the traveller an awareness of a space, and then loop back on itself back to an earlier node to reflect again upon that node given the enhanced awareness and understanding of the traveller.

: This stateful recurrence may prove troublesome in implementation though. Lets not get ahead of ourselves.

Implementation Ideas

Cookies

Clicking on path links will set a "path" cookie indicating what path you are on. You are always on one path only.
When visiting a page, the WikiEngine script checks wether it is part of the path your cookie is indicating.
If yes, the WikiEngine will add "Next," "Previous," and "List" links to the navigation bar.
If no, nothing happens. Thus, you can take detours from your current path and come back later.
When a page is displayed, a path-cookie-setting link for every path this page is on will be displayed. Thus, you can switch paths when looking at a page that is on several paths.

URL args

Instead of the usual URL http://www.usemod.com/cgi-bin/mb.pl?PathsInHypermedia, the path navigation links would be http://www.usemod.com/cgi-bin/mb.pl?path=TechnologyTour&next=PathsInHypermedia&from=WikiTechnology

The next and from args affords bi-directional travel along the path, and even allows for different commentaries depending on which direction you are travelling.

None

Similar to categories, make it something distributed. At the bottom, add path name, as well as previous, next and list links for each path the page is on. The "list" link leads to an overview of the path generated by a search for the path name.

Advantages
- can be done now

Disadvantages
- requires tedious editing of each page on the path
- fragile: a normal page editor could break the path
- path commentary is visible to all visitors, not just those on the tour bus. The natives might get restless.

Frames

Using either the cookie or url args method of navigation, the nodes could be displayed in a frame seperate from the commentary/navigation.

Advantages:
- doesn't require the direct cooperation of the site being travelled
- the path navigator could run on a completely different server/site
- the path could traverse many different sites, not just meatball, not just wikis

Disadvantages
- some people are allergic to frames
- some sites are allergic to frames

Open Questions

What would we build if path technology were built into the WikiEngine?

Better yet: What would we build that cannot be built by adding plain links to pages in the path?

meta commentary, like SunirShah's powerpoint presentation for OReillyPeerToPeer. [1]

If the paths are implemented in the same WikiEngine which provides the nodes, should a page not visited via a path show those paths? Perhaps a path could be designated as private, where the only way to get onto the path is the path starting page. Think camoflaged Safari Tours. Further refinement - a given path may have the entire path hidden, or just specified nodes. (but lets not get carried away here ;-)

and now for something completely different ...

Slides from Mark Bernstein's Hypertext '01 talk, [Card Shark And Thespis: exotic tools for hypertext narrative], are now available. Highly recommended!

: "Rather than create complex actors, let's create simple automata that say interesting things about important matters. That's theater." -- MarkBernstein

He starts with a simple premise -- instead of constructing a hypertext by taking a bunch of nodes and creating links, start with everything interlinked and then take away the links until you have something interesting. He builds a model where every node has two extra elements: constraints, and assertions. Constraints are things that must be true for this node to be available to visit, and assertions are ways this node changes the environment. Imagine a state machine.

This reminds me of a ancient project I gave up on - a hypermedia community space, where each node was either a person or a place in the space, and knowledge is available only in exchange of other knowledge. If you knew Bob, then when you visit Jim's page it would reveal more information, such as the best place to get coffee on Sunday. Knowing that unlocks further mysteries. Knowledge would be represented as both questions and answers, and even the questions would not be open, but dependent on your contextual knowledge. Think of it as a collaborative text adventure, a cryptocracy. The casual visitor doesn't have much power, but persistence of participation pays off.

Hebbian Learning

What if visitors to the wiki were to create paths not consciously, but simply by doing what they do now: follow links from page to page?

Now would be an excellent time to read VisitedLink which builds weights through a process called Hebbian learning onto the LocalSiteMap idea just mentioned.

References

http://www.enteract.com/~marc/portfolio/toursintro.htm
Wiki:WikiWithTrails
ZWiki:WikiPaths
StrikiWiki:PageTrail an implementation of this idea

Contributors: EricScheid, SunirShah, AlexSchroeder

CategoryWikiTechnology CategoryUncommonWikiTechnology CategoryUnimplementedWikiTechnology CategoryLink CategoryNavigation