Re: event display algorithm suggestions

[Seth Teller <teller@csail.mit.edu>]

patrick,

your ranking and weighting scheme seems reasonable.  it's hard
to see how to make it more "scientific," since the choice of
weights must be ad hoc.  but perhaps we can broaden the question
a bit by thinking in terms of the actual interface to the user:
what does s/he see, in what order, at what size, for how long,
etc.

so for example (assuming sufficient display area on the signs),
you could show a pool of imminent events (each selectable by the
user), each rotating, or sliding, or somehow getting promoted
into a prime display area (then getting demoted afterward) in a
continuous process.  in other words, use the information display
not only to give the user the outcome of your ordering algorithm,
but also an idea of the process used to produce it and of the
richness of its event corpus.

there's a tradeoff here in terms of effective complexity, but
you could also consider giving the user button or slider control
over how things are cycled (sliders might control the weights
in your scheme above):

  Cycle:   [Events happening soon]  [Events happening nearby]  [Both]

where as always, the device has reasonable defaults, perhaps to
which it reverts after a few minutes of no user interaction.

i'd also ask you to think about visual "summaries" of multiple
upcoming events, from which users could capture a lot of
information with a glance or quick scan.  examples:

  a daily timeline, with event names sorted by time

  a weekly/monthly calendar with same

  a floormap of the campus section within 1/5/10 minute walk,
    with icons for each event shown in their respective
    locations.

if you think about it, each of those is a proximity query,
one along a time dimension, one along a spatial dimension.

it might be hard to pull off, but it would be even cooler
to correlate these three elements as each event is displayed:

      the text listing
      a highlighted calendar day and time indication
      a highlighted event location and route to that event

again, making each of the three selectable, so whichever
one the user touches looms large while the others are
de-emphasized somehow.

these are just initial reactions; i'd be happy to talk more
about this.

seth.

Patrick Nichols wrote:
> All --
>
> I'm writing a data structure that tries to serve up events in a 
> semi-intelligent way. The basic idea is that we have a set of events, 
> which each have a location and a time. Events have a priority, and higher 
> priority events are more likely to be displayed than low-priority events.
>
> The way I'm thinking about the problem is to sort events along two axes: 
> spatial locality and temporal locality. Events which are happening soon 
> and which are close are more important than events which are far away in a 
> long time.
>
> I'd appreciate feedback on this approach, if anyone has any good ideas for 
> thinking about how much to weight these factors. Here's what I've got, 
> roughly:
>
>   /**
>    *  Method which computes the priority of an event based on its
>    *  time, location, and type, and then dislays it.
>    */ 
>   private void computerPriority(SignEvent se) {
>     // first compute how soon it is, and group into one of four buckets:
>     //  1. immediate   (< 1 hour from now)
>     //  2. short term  (< 12 hours from now)
>     //  3. medium term (< 2 days from now)
>     //  4. long term   (> 2 days from now)
>
>     // second compute how close the event is
>     //  1. this locale (20M)
>     //  2. this building (100M)
>     //  3. this quadrant of campus (500M)
>     //  4. all others (2000M)
>   }
>
> I get reasonable results using some home-grown weighings, but was 
> wondering if there was a more scientific approach i could use.