Pave The Path

Let's say you have a bunch of new buildings and you're not sure how to make paths between them. You could guess, but if you were wrong you'd end up jackhammering a bunch of concrete. Instead, you plant the whole central area to grass. Then you pave wherever the grass gets worn away.

A study some years ago claimed evidence that people wore paths that were consistently the lowest-energy path in that terrain, so actually you should be able to predict the paths ahead of time with a Hamiltonian. -- dm

This is also a metaphor for user interface design. You start with something really simple, then watch the typical usage patterns. If 80% of the people go from page 1 to page 2, promote the information on page 2 to page 1.

But not continually/dynamically; people also need to have consistent navigational paths. -- dm

This process could be assisted by UserInterfaceRefactoring?s.

You could also pave the whole plaza, that way people can make their own path wihout getting muddy feet and then you won't have the added expense of mowing and getting rid of dandelions!

You're obviously a city boy. Those of us who grew up in the country think that 100% concrete environments are the very embodiment of hell. -- DougMerritt

"My god, they have to put the trees on top of the buildings." My southern-fried fiancee upon her first visit to New York City. -- JoeWeaver

Well, you can have different spaces for different purposes. A central business section should be mostly paved since it's for a lot of people moving around quickly. You still need parks in any city, though, since those workers are people who might like to take time off to go on picnics. Both parks and downtowns could probably be described as DesignPatterns. -- francis

Pretty code is like grass. Highly optimized code is like pavement. Make all your code like grass first, but if code gets a lot of traffic, consider making it into pavement. -- SteveHowell

If you fail to do so, the grass gets turned into a mud rut that is neither pretty nor efficient?

PaulGraham describes something like this in http://lib1.store.vip.sc5.yahoo.com/lib/paulgraham/bbnexcerpts.txt. The relevant quote:

: By looking at the way these users modified our built-in templates, we knew what we needed to add to them. Eventually we made it our goal that no one should ever have to use Rtml. Our built-in templates should do everything people wanted. In this new approach, Rtml served us as a warning sign that something was missing in our software.

Yeah, that was interesting. So, should there be some kind of language support for that process?

The ArcLanguage spec requires a profiler. As for the UI sense, it's just a matter of taking the code users have written and making it the default. Having an extensible language like Lisp helps a lot.

Mmm...sure it does, but I'm thinking more along the lines of, not just stuffing every little piece of cruft into the system as a default, but somehow providing support for refactoring along the way, so that the result isn't a kitchen-sink language/application, it's something clean and elegant that doesn't require the user extensions previously required. Brainstorm required, I think. I'm reminded of the difference between purely generating HTML from perl versus using an actual template that non-programmers can edit (most of).

That's interesting about Arc. -- dm

Paving the path can find a local maximum, but not necessarily the global max. For example, a friend of mine actually used Paul Graham's RTML when he joined Yahoo! Stores. He soon switched to uploading his own HTML due not to RTML's deficiences, but because editing RTML over a dialup line was painful (e.g., thirty-second refreshes after a button click). Unless they were monitoring the HTML/RTML ratio among their users, the folks behind RTML might have missed evidence that their system had a problem. PaveThePath, but keep an eye on how many people are taking the bus.