transit-tools-developers — Transit Tools Developers

[Transit-tools-developers] another topic: multiple transit systems

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

Good news! I just got word we have been granted an exception from the
NextBus web site's terms of use to allow us to scrape for Streetcar next
arrival information.

 

So this legalizes the use of code I have already prototyped.

 

But it raises a UI issue. How do we treat multiple transit systems? Right
now the UI is all about TriMet.

 

There are two options I see at the moment:

 

1)       Model Streetcar as a TriMet route. This is actually pretty easy
because TriMet already tracks Streetcar schedules (but not real time data)
and has a route number and stops assigned. The downside of course is that
somewhere the code needs to know to use a different method to get the real
time data.

 

2)       Rearchitect the UI to allow for multiple transit systems. This
would allow us to bring in CTRAN or other systems at some point in the
future. There are some challenges however:

 

-          Need to revamp UI

-          Need to add a layer to the route/stop modeling to deal with stops
that are common to multiple systems

 

What do people think?

 

Chris

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
>

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

[Ali C. <ali...@gm...>]

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 y=
ou
> know your choice sets can be seen by anyone, you need to make sure you do=
n't
> name them in any way that gives away personal information, e.g., "downtow=
n
> 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.=20
(Something along the lines of NW23rd&NWThurman-to-SW5th&SWMorrison)=20
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 choic=
e
> set it open to everyone? If you wanted to modify someone else's choice se=
t
> 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 devi=
ce!
>
> 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 sto=
ps,
> 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 o=
n
> is
> > the creation and management of choice sets. A choice set is currently t=
he
> > 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 look=
s
> > like this:
> >
> >
> >
> > <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> >
> > <choice_set>
> >
> >
> >
> >             <stylesheet size=3D"small">
> >
> >                         lloyd
> >
> >             </stylesheet>
> >
> >
> >
> >             <banner>
> >
> >                         Lloyd District to North Portland
> >
> >             </banner>
> >
> >
> >
> >             <message>
> >
> >                         Transit Board&amp;trade; is a trademark and
> service
> > of <a target=3D"_blank" href=3D"http://portlandtransport.com3336">Portl=
and
> > Transport</a> provided in cooperation with the
> >
> >                         Lloyd TMA. We welcome your <a
> > href=3D"mailto:webmaster@portlandtransport.com3437">feedback or
> suggestions</a>.
> >
> >             </message>
> >
> >
> >
> >             <stop id=3D"1097">
> >
> >                         <route id=3D"140"/>
> >
> >                         <route id=3D"4"/>
> >
> >             </stop>
> >
> >             <stop id=3D"11814">
> >
> >                         <route id=3D"1"/>
> >
> >             </stop>
> >
> >             <stop id=3D"10953">
> >
> >                         <route id=3D"6"/>
> >
> >             </stop>
> >
> >             <stop id=3D"11508">
> >
> >                         <route id=3D"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 choi=
ce
> > 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=3Dchris3538
> >
> >
> >
> > 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 i=
n
> via
> > a traditional authentication scheme (probably cumbersome on a cell phon=
e).
> > Is there an alternative model?
> >
> >
> >
> > Do we need to have login in order to protect privacy? Should choice set=
s
> 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 langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D12164239
> _______________________________________________
> Transit-tools-developers mailing list
> Tra...@li....net40
> https://lists.sourceforge.net/lists/listinfo/transit-tools-developers41
>

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

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

[Ali C. <ali...@gm...>]

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.=20
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 Surf=
er.
>
>
>
> A choice set is nothing more that a list of transit lines boarding at a s=
et
> of transit stops. As currently modeled, it's an XML structure that looks
> like this:
>
>
>
> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
>
> <choice_set>
>
>
>
>             <stylesheet size=3D"small">
>
>                         lloyd
>
>             </stylesheet>
>
>
>
>             <banner>
>
>                         Lloyd District to North Portland
>
>             </banner>
>
>
>
>             <message>
>
>                         Transit Board&amp;trade; is a trademark and servi=
ce
> of <a target=3D"_blank" href=3D"http://portlandtransport.com33">Portland
> Transport</a> provided in cooperation with the
>
>                         Lloyd TMA. We welcome your <a
> href=3D"mailto:webmaster@portlandtransport.com34">feedback or suggestions=
</a>.
>
>             </message>
>
>
>
>             <stop id=3D"1097">
>
>                         <route id=3D"140"/>
>
>                         <route id=3D"4"/>
>
>             </stop>
>
>             <stop id=3D"11814">
>
>                         <route id=3D"1"/>
>
>             </stop>
>
>             <stop id=3D"10953">
>
>                         <route id=3D"6"/>
>
>             </stop>
>
>             <stop id=3D"11508">
>
>                         <route id=3D"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 myse=
lf
> about a year ago:
> http://chrissmith.us/cgi-bin/transit.pl?user=3Dchris35
>
>
>
> 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 i=
n 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 cho=
ice
> set. Could there be a collaboration system for sharing choice sets?
>
>
>
> Let the list know what you think.
>
>
>
> Thanks.
>
>
>
> Chris

[Transit-tools-developers] thinking about choice sets

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

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.com">Portland
Transport</a> provided in cooperation with the 

                        Lloyd TMA. We welcome your <a
href="mailto:web...@po...">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=chris

 

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

[Transit-tools-developers] first message

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

OK, here is the first official message for our transit-tools-developers
list.

 

Now, if I can just figure out the subversion interface to upload some code
:-)

 

Chris