thoughts on MITquest interface

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

patrick et al.,

here's a rough sketch of how the MITquest route-generator
interface might look.  this is to get people thinking and
discussing; it's not iron-clad by any means.

as a few guiding principles, i'd like the interface to:
  * produce correct and (nearly) optimal routes
  * be flexible to needs of different users/times/seasons
  * be easy to use (& produce results easy to understand)
  * be visually appealing at small and large scales
  * be reactive to the user
  * be invokable either interactively or by URL query

we should shoot to make MITquest cool and useful enough
to become one of the most used services at MIT.

from the interface point of view, the main query page
could look like:


           MITquest:  Directions and Maps of MIT

        Starting Point                    Destination

     [Left Graphics Area]            [Right Graphics Area]

                           UI Choices

when initialized, the query page has no info about the user's
choices, so the start and dest could default to central MIT
(say, killian court), or to the location of the user's network
access point, if it can be determined and if it's on campus.

the graphics areas show a perspective or plan view of the
whole campus.

the UI choices, arrayed to the left or below the graphics,
lead the user through stating his/her route plan.  as the
user adds info, the graphics panes "react" by changing their
contents.

so for example after the user specifies via pulldowns a start
building, start floor, and start room (or alternatively after
the user types in an MIT locator from which those three things
can be parsed), the left pane displays one building, then one
floor, then highlights a room of that floor.  reasonable
defaults prevail always:  so if no room is specified, perhaps
the center of the floor is used, or the route originates at
multiple places:  all possible egresses from that floor.

if we have the graphics bandwidth in a typical java renderer
(patrick:  do we?) it would be cool to animate the transitions.
so, from a perspective view of all campus, one building glows
for a second, then we zoom in on it.  then one of its floors
glows, and the others fade from opaque to (nearly) transparent.
last to be highlighted would be the start point or points.

similarly for the destination.  once both are specified,
perhaps a third graphics area could appear (or the two panes
above could merge?  we may not have a lot of screen area.),
showing both start and destination in appropriate scale,
location and orientation.  careful to handle corner cases here!
(start == dest; start floor == dest floor; bldg; etc.)

as for the UI choices:  i envision several orthogonal sets of
radio buttons, with reasonable first-time defaults (shown
with * below), and reasonable subsequent defaults (perhaps
set by cookies -- patrick, how painful is that).

route type:

   *walking route  /  rolling route

route constraints [only if rolling route selected?]:

   *allow ramps for level changes  /  use elevators only

weather considerations (perhaps with different summer/winter default):

   *outdoor-indoor route OK  /  generate indoor route only

route optimization:

   *give shortest route  /  give route with fewest turns

security considerations:

   avoid cardkey doors  /  *traverse cardkey doors as needed



are there other parameters (like, avoiding crowds)?

again, it would be cool if, as the
radio buttons are toggled, the displayed route(s) recompute and
redisplay on the fly.  if recomputation is expensive, perhaps
the server could background computation of the most frequent
alternatives selected (if 2^5 - 1 alts are too much to compute
routinely or on-the-fly), then cache & display them as needed.

a more aggressive caching strategy would be to cache exit door
to exit door routes of all flavors at the server, then select
and patch them together according to actual user queries
(bracketed, of course, with the generated indoor portions).
patrick, perhaps you could explore the tradeoffs of latency,
storage, etc. here as part of your Meng.

connections to others in the group:

  to vitaly:  info about outdoor conditions:  height changes,
    curb cuts, ramps, stairs, etc.

  to michael:  space labels, portal info.  also:  interface to
    route renderer, to show plan view and first-person view of
    route traversal.

  to peter:  mostly through michael; visibility queries for
    route rendering.

a final note:  i've cast everything above in terms of generating
routes from A to B, but many people may just want contextual maps
of specified single locations.  we should support that too.
extending in the other direction, we should also support "tours"
(either open-loop or closed) in which a route is generated through
waypoints A-B-C-D-E (and if closed, back to A).  this would be
useful for self-guided tours of campus, stata center, etc. etc.

comments & discussion to the bmg list please.

seth