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

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

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".

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?

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.

2) By transit line, as in "show me all the choice sets on the #15 line"

-----Original Message-----
From: Ali Corbin [mailto:ali...@gm...] 
Sent: Sunday, March 05, 2006 2:32 PM
To: Chris Smith
Cc: tra...@li...
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 <ch...@ch...> 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.com33">Portland
> Transport</a> provided in cooperation with the
>
>                         Lloyd TMA. We welcome your <a
> href="mailto:webmaster@portlandtransport.com34">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=chris35
>
>
>
> 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