RE: [Transit-tools-developers] thinking about choice sets

[Chris S. <ch...@ch...>]

Ali,

I think we're operating under different assumptions (or at least not fully
articulated assumptions).

The first is whether a choice set is the description of a trip (corridor?)
or of a set of origins.

For example, we now have several choice sets for the Lloyd TMA. Each choice
originates in the Lloyd District, but the destinations are very broad, like
NE Portland vs. SW Portland. If you think about choice sets as origins, I'm
not sure you can do automatic naming.

And I think users will want to be able to edit their choice sets.

So I think I'm suggesting a split solution.

A desktop browser environment that requires login to create and edit choice
sets, and a mobile device environment that only requires providing either a
choice set id, or an id for a list of choice sets, with no authentication
requirement.

BTW I propose calling choice sets 'Transit Places'. Any other suggestions?

Chris

-----Original Message-----
From: Ali Corbin [mailto:ali...@gm...] 
Sent: Sunday, March 05, 2006 7:03 PM
To: Chris Smith
Cc: tra...@li...
Subject: Re: [Transit-tools-developers] thinking about choice sets

On 3/5/06, Chris Smith <ch...@ch...> wrote:
> I think there is a lot of advantage to the everybody-can-see-everything
> model.
>
> But there are some drawbacks too. Privacy perhaps being the biggest. If
you
> know your choice sets can be seen by anyone, you need to make sure you
don't
> name them in any way that gives away personal information, e.g., "downtown
> to Chris's house".

If all choice sets are public, then the user shouldn't be able to pick
the name.  We'll need to do it, using some standard nomenclature. 
(Something along the lines of NW23rd&NWThurman-to-SW5th&SWMorrison) 
For privacy reasons, we'd probably want to translate an address to its
nearest intersection.  That ought to be generic enough.

>
> There is also the issue of integrity. If anyone can EDIT anything, what
> keeps someone from hacking up my choice sets to the point where they are
not
> useful to me?

Right.  Which is why, if the choice sets are public, we can't allow
anyone to edit them, only to create them from scratch.  But then
again, if we use something like the above nomenclature, in which the
choice set's ID actually encodes its endpoints, then editing the
endpoints of a choice set will automagically produce a new choice set.
 And if two people happen to create the same choice set, then we can
notice that the IDs are the same and simply reuse the original one.

>
> I'm wondering if we couldn't have a model where you use your web browser
to
> create and edit choice sets, with a password required, but use of a choice
> set it open to everyone? If you wanted to modify someone else's choice set
> for your own use, we could have a 'clone' method for copying another set.
>
> I think it would be great if no one ever had to log on from a mobile
device!
>
> As to finding choice sets, I think there are at least two good ways that
> immediately come to mind:
>
> 1) On a map (e.g., a Google Maps app). Since a choice set is a set of
stops,
> each of which has a know lat/lon coordinate pair, calculating a centroid
and
> putting it on a map is straightforward.

Cool idea!  And I've played a bit with google maps (see
http://www.hevanet.com/acorbin/maps/) so that we'd have a head start
on the learning curve.

One caveat, however.  The last time I checked, google maps only worked
on firefox and MSIE.  That would cover most of the world, but wouldn't
help Mac people, who tend to use safari (but who could always download
firefox).

Note that Google themselves have mobilized google maps to run on cell
phones.  I myself have never tried this out, having a dinky little
screen and paying for downloads by the byte.  Also, I somehow doubt
that the published google maps api will actually work in this case -
they seem to have coded their mobile app up from scratch, using java.

>
> 2) By transit line, as in "show me all the choice sets on the #15 line"
>
> -----Original Message-----
> From: Ali Corbin [mailto:ali.corbin@gmail.com33]
> Sent: Sunday, March 05, 2006 2:32 PM
> To: Chris Smith
> Cc: tra...@li....net34
> Subject: Re: [Transit-tools-developers] thinking about choice sets
>
> I've been giving some thought to the trade-offs.
>
> For the developers, it'd be easier to allow anyone to create and use
> both choice sets and sets of choice sets (we need to figure out better
> ways to name these thingies).  That way we wouldn't have to worry
> about keeping track of users.  The downside is that if people can
> share these thingies, then we can allow them only to be created from
> scratch, and not edited after creation (to prevent someone from
> changing a thingy that someone else is using).  And we might have
> problems keeping things cleaned up - if a thingy doesn't belong to
> anyone, how do we know when it's no longer needed?
>
> On the other hand, even if we did store thingies on a per-user basis,
> would we necessarily know when to clean up after them?  We could give
> them the option to delete their accounts, but I doubt that many people
> would bother, or remember, to do it if they stopped using it.
>
> >From the point of view of the users, the trade-offs are being able to
> use thingies that someone else has already created, versus having so
> many already-created thingies that you can't find the one that you
> want.  If we did make them public, we'd have to come up with a way to
> display them in some coherent sorted, or searchable, fashion.
>
> >From a practical point of view, the choice sets are far more likely to
> be reused than the sets of choice sets are.  In other words, there
> will be more people interested in getting from A to B than there are
> in getting from A to B _and_ C to D _and_ E to F, etc.  So I'd guess
> that the best solution is to give each persion their own set of choice
> sets, but let all of the choice sets be public.
>
> And even then, you could provide the 'private' thingy without having
> to do logins by letting them create it, then assigning a unique id to
> it and giving that to the user.  And if they lose the id, they have to
> start over.  You could even let them edit the set of choice set
> thingy, because no one else would be using it (assuming that they
> didn't give out their id).
>
> As for creating the choice set thingies, it seems to me that this is
> something that we could do automagically.  Starting with an address or
> an intersection, we should be able to find all bus stops within, say,
> 5 blocks.  Or rather, the closest bus stop on each bus line within
> some some distance.
>
> Of course, that would give huge hulking gobs of data for anywhere in
> downtown.  Maybe it would be better to get a list of stops for those
> lines that are also going within some distance of some destination
> location.
>
> We have another choice in how the choice set thingies are displayed.
> Your prototype has them as a list of links, one for each separate
> stop, each one of which leads to the current times for that stop.  I
> had envisioned it as a single url which would give the combined times
> for each of the stops.
>
> The trade-off here is between the time spent in navigating between the
> different links (Well, I see that bus A will be at the stop one block
> north of me in 10 minutes.  Let's see when bus B will be at the stop
> one block south of me.) with maddeningly slow connect times, versus
> scrolling through all of the combined information on a maddeningly
> small screen.
>
> Ali
>
> On 3/3/06, Chris Smith <chris@chrissmith.us35> wrote:
> >
> >
> >
> > Fellow developers,
> >
> >
> >
> > So I think the next key piece of Transit Surfer/Transit Board to work on
> is
> > the creation and management of choice sets. A choice set is currently
the
> > driver behind Transit Boards, and it has great potential for Transit
> Surfer.
> >
> >
> >
> > A choice set is nothing more that a list of transit lines boarding at a
> set
> > of transit stops. As currently modeled, it's an XML structure that looks
> > like this:
> >
> >
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <choice_set>
> >
> >
> >
> >             <stylesheet size="small">
> >
> >                         lloyd
> >
> >             </stylesheet>
> >
> >
> >
> >             <banner>
> >
> >                         Lloyd District to North Portland
> >
> >             </banner>
> >
> >
> >
> >             <message>
> >
> >                         Transit Board&amp;trade; is a trademark and
> service
> > of <a target="_blank" href="http://portlandtransport.com3336">Portland
> > Transport</a> provided in cooperation with the
> >
> >                         Lloyd TMA. We welcome your <a
> > href="mailto:webmaster@portlandtransport.com3437">feedback or
> suggestions</a>.
> >
> >             </message>
> >
> >
> >
> >             <stop id="1097">
> >
> >                         <route id="140"/>
> >
> >                         <route id="4"/>
> >
> >             </stop>
> >
> >             <stop id="11814">
> >
> >                         <route id="1"/>
> >
> >             </stop>
> >
> >             <stop id="10953">
> >
> >                         <route id="6"/>
> >
> >             </stop>
> >
> >             <stop id="11508">
> >
> >                         <route id="190"/>
> >
> >             </stop>
> >
> >
> >
> > </choice_set>
> >
> >
> >
> > The stylesheet, banner and message elements are application-specific to
> > Transit Board. The stop/route elements are the key for the choices. In
> > Transit Board they essentially drive the list of lines in the table.
> >
> >
> >
> > In Transit Surfer, I see the potential for a user to have a set of
choice
> > sets that constitute 'My Favorite Transit Places'. This would be a much
> > better starting point for the interface than entering a stop id, or
> > navigating through a set of lines to a set of stops to a stop.
> >
> >
> >
> > You can see this in action for yourself at a script that I build for
> myself
> > about a year ago:
> > http://chrissmith.us/cgi-bin/transit.pl?user=chris3538
> >
> >
> >
> > So to make this work, we need a number of pieces of functionality:
> >
> >
> >
> > 1)       A user needs to be able to construct a choice set and store it
in
> a
> > retrievable way
> >
> > 2)       A user needs to be able to define a set of choice sets that
> > constitute their favorites
> >
> >
> >
> > So the first question is what is a user? Is it someone who has logged in
> via
> > a traditional authentication scheme (probably cumbersome on a cell
phone).
> > Is there an alternative model?
> >
> >
> >
> > Do we need to have login in order to protect privacy? Should choice sets
> be
> > private or public? Would users potentially want to use another user's
> choice
> > set. Could there be a collaboration system for sharing choice sets?
> >
> >
> >
> > Let the list know what you think.
> >
> >
> >
> > Thanks.
> >
> >
> >
> > Chris
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
> that extends applications into web and mobile media. Attend the live
webcast
> and join the prime developer group breaking into this new coding
territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164239
> _______________________________________________
> Transit-tools-developers mailing list
> Tra...@li....net40
> https://lists.sourceforge.net/lists/listinfo/transit-tools-developers41
>