Re: Stata DXFs, MITquest Interface

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

patrick et al.,

re: stata plans.  they won't/can't give us a firm date.  i think
they're shooting for november, but these things always take longer
than planned.  try to work with what you have, and keep in touch
with the DOF for updates.

re: your question about application vs. active sign.  here's my
thinking:  in the past, i've had a number of MEng students write a
piece of deep infrastructure code.  but because it was deep down
in a pipeline, with a code-only interface in and out, it was hard
to tell how the work was going.  moreover, once the student left,
and the workings of the code were more exposed, problems appeared.

so this time i want to do something different:  i want your code
to serve a primary app -- the active sign, or an equivalent web
interface, as we've discussed from the start -- in a highly visible
way.  this will allow us to assess progress and make course
corrections much more easily.  in fact, the additional effort
involved (over a pure active sign project) is small, since we're
really just talking about an additional query & results interface.
i would argue that making this multi-client will sharpen your
design, too, since you won't fall into any single-interface traps.
making max yet another client of your stuff makes this even stronger.

ok?  now:  on the issue of portable signs.  it would be great if
you can get some crude cricket connectivity going and demonstrate
a sign that auto-reconfigures as it is moved about.  once you get
that working even for a small beacon deployment (say, three
beacons over tens of meters of hallway) there is a huge incentive
for the rest of the cricket team to do a full-floor or even full-
building deployment.  so see if you can work that in.

next:  on the issue of route queries.  my wife thought the route-
planning concept was exciting, and she came up with two additional
constraints for the route server.  first, what if a portal has a
revolving door on it (we can't get the stroller to go through
those; wheelchairs won't either i think).  second, what if you
want to stop for coffee on the way, either anywhere suitable or
at a favorite spot?  the route planner should incorporate these.

a more general observation/challenge for the route planner.  can
you design it so that a single, suitably constrained search
handles all the constraints we've come up with so far?  as a core
you're probably going to want a dijkstra path generator on the
graph.  saying indoor-only disables portals to outside.  specifying
shortest route vs. fewest turns changes the edge weighting
function.  saying you want to stop at bldg 4 for coffee forces
the path to contain a specified node.  etc.  my challenge is:  can
*all* of the constraints we've enumerated be expressed as dynamic
constraints before a single, universal search is launched?

regarding the mockup search interface.  it looks good.  a couple
of comments.  perhaps headlining it with "Maps and Directions to
Places at MIT" above the graphics pane would clarify its function.
also, for start points the list of buildings may become unwieldy
once it contains every MIT building number.  i'm not sure what to
do about that.

on starting points:  we should consider the needs of people
coming from outside MIT, i.e., arriving at 77 mass ave or the
kendall square T, or the stata center entrance (probably a big
tourist draw in future) and entering MIT that way.  perhaps we can
have a branch point for arrivals from outside MIT?  not sure how
best to handle that either.

seth

Patrick Nichols wrote:
> Hi Professor Teller,
>
> Its good to hear you've safely arrived in Italy! I hope you're having a 
> great time and enjoying Florence.
>
> ** BMG News **
>
> On the BMG front, we've managed to get DXFs from Greg Knight and are 
> inspecting them in the lab right now. It looks like they have a somewhat 
> peculiar format, with ~100 layers and all kinds of stuff in them. Luka and 
> Mike are currently assessing the odds of passing the DXFs (or some 
> modified version of them) through the pipeline. We'll tell you more when 
> we know.  Do you know when facilities belives they'll have a properly 
> formatted version of this data?
>
> ** MITquest **
>
> On MITquest: I designed a simple web interface for the application you 
> described in your most recent email to the list -- take a look at 
> http://graphics.csail.mit.edu/~pnichols/research/mitquest to get an idea 
> of what my current thinking is.
>
> I have a broader question about MITquest: what role should this 
> application play relative to the active signs I'm working on? When we 
> spoke at the start of the term, I was under the impression that my main 
> area of focus for my thesis was the active signage project. The 
> route-finding software I'm writing will be highly portable and I should be 
> able to deploy it as an applet (or some version of it), so getting 
> *something* working isn't my main concern. I'm just wondering how this 
> fits in context with the rest of my stuff.
>
> ** Other news **
>
> I've touched based with Max Van Kleek (the interactive kiosk guy) and 
> we're going to be working together in the term ahead. He will be a client 
> of my route-finding and display software, which should stress-test the 
> reliability and portability of my code.  He has done a lot of work on 
> agent-based architectures for intelligently displaying events (in his 
> case, news items pulled from sources like BBC) and will help me my 
> event-display logic.
>
> If you google "active signage", my research page and thesis proposal are 
> the top listed links. 
>
> Thats about it for now. TA'ing 6.837 is quite a bit of fun, and I feel 
> like I'm learning more about the subject a 2nd time around. Thanks once 
> again for securing the TAship for me.
>
> --Patrick