link

These are features that should go into frassle. Some are high-priority, some far-off dreams, most in between.

Notation like [this] denotes incremental levels of complexity on a feature. {This} denotes estimated time to implement, possibly divided out by phase.

Feature list

  • Pop-up UI tips. In frassle, you might have little tricks to speed things up. For instance:
    • When adding categories, you can type "One; two;three" to create separate categories named One, two, and three.
    • When typing a local: URI, you can leave a space at the end in order to ask the server to disambiguate by appending a number. For example, if you type "local:berkman " and berkman and berkman1 already exist, your URI will be automagically changed to say berkman2.

    Near where these tricks are useful, there should be a little hint gadget.

  • Pull from Google/Feedster. When an item is published to a feed, or maybe when a user asks, frassle should query Google or Feedster to find other relevant information. {4h??}
  • Clickthrough and "return to frassle" frame. When you click on a link to an external site, the link should actually take you to clickthrough?member_id=12345. This page should [phase1] do a redirect and [phase2] return a frameset with the external site in the bottom frame below a thin top frame that takes you back to where you were on frassle. {phase1: 20m, phase2: 40m}
  • local:blahLink URIs on members should denote locally-served content. This content should be reachable at a URL that looks like http://fa.rura.org/blahLink to make things easy to write down. {40m}

Deeper observations

  • frassle is web search with really, really big search terms. It's like if you asked google not only about some words, but also provided it with a sort of personal cultural history so it could find things relevant not just to those words, but to those words as understood by you. This is anxiety-provoking because it seems to demand a high-bandwidth, computation-intensive connection on the low-bandwidth, computationally stupid internet. On the other hand, if the fundamental problems of search can be solved by faster networks and computers, that's pretty nice. Of course, a key distinction may be that search terms are getting larger by orders of magnitude, so perhaps hardware technology may not be able to keep up. On the other hand we in CS are pretty good at coming up with tractable approximations to nondeterministic problems, so if we get to the stage that this is a serious question we will have some idea how to go about solving it.