We sent a copy of the recent discussion about WWW based bus schedules to
the developer of the software which generated the html and received the
following reply.  To keep list traffic down, please write directly to
[log in to unmask] with your comments and suggestions concerning the
presentation at http://trfn.clpgh.org/patransit/

-- forwarded message ---
From: R.H. Jannini <[log in to unmask]>

I had received a copy regarding your discussion of On-line Bus Schedules. As
the developer of data2schedule, I believe I am somewhat qualified to discuss
some of the "rational" that is currently in use, as well as hurdles that
confront us in this goal of dual access data.  I offer this information so
that I might be able receive some additional feedback which will aid in the
continued development of dual access information.

First of all, as some of you may be aware, the Port Authority site has gone
(and will continue to go) through improvements.  The very first and ongoing
hurdle is to generate the bus schedules quickly and accurately from the
original "mainframe" data.  For the last few years, the Port Authority had
struggled with the timely conversion and accuracy of generating schedules
from this data.  With over 250K bus stops, the word "tedious" is probably
the best publicly usable word.

The underlying idea is that once the raw data was converted to a suitable PC
database to a could manipulated into formatted HTML as well as reusable PC
data for aiding in the layout of the "printed" schedules. Once the initial
conversion was out of the way, we took the time to focus on the display and
formatting of the tables for all types of users.

As for the existing "format" - currently there are a couple visual clues.
As was pointed out there was an abundance of color added to the schedules to
suggest AM/PM stops.  We used lighter and darker shades of "gold" to signify
the differences, but more importantly used normal and BOLD fonts for support
those same AM/PM times.  It was our hope that those with limited browser
capability and/or visually impaired would still be able to deduce the
differences in time.  However, designing output for a Braille printer, I
don't believe BOLD is a suitable approach.

For this reason, tables would need to be "reformatted" to support AM/PM
notations (simple). Still, more importantly, changing the data orientation
and layout to not only be scanned and/or printed.  Once the orientation and
layout is changed from a strict tabular format its ability for use in
cross-referencing diminishes.  (Ed: this is something I would like to have
more input on as I am interested in meaningful mental representations of
data in Braille.)

Therefore, work is being done to support departure/destination routing with
this data.  The idea that riders could use an on-line system and be provided
a "rider itinerary" of only the information needed to go from point A to B
and back again with any appropriate bus changes, is one of the underlying
goals of this data conversion.

Here again, we have a couple of issues in supporting dual access to this
information.  Since the thrust of this list is to discuss the visually
impaired, I will focus there although the problems are very similar in
nature.

First, is the initial input of the request - all bus stops are identifiable
with the appropriate or nearest street intersection, and simple routing can
be achieved with time, route number, direction.  This is not a problem -
initial development already is in place for this.

However, the real snafu is how the departure/destination bus stop is
identified to users not familiar with the system, the geography as well as
spatially or visually impaired.

The use of lists or listboxes still requires both types of users to FIND the
starting/ending bus stop - the shear quantity (~9000) of this alone is a
problem.  Both types of users would have to pour over seemingly
disassociated names to find a street intersection familiar to them.  Sorting
alphabetically is possibly the best one could do - and even then it would be
a searching nightmare.

The cleanest approach provides the user a short list of bus stops to choose
from - ideally, this is generated by allowing the user to enter their
beginning and ending address (I won't even discuss local street naming
conventions or typographical error correction support and the like).  These
addresses would then be used to find the closest bus stops ordered by their
shortest distance - this requires geographical attributes such as lat/lon
which currently does not exist in the database but are being entered now.
Being a GIS designer for over 10 years, I am very aware that these are
important aspects of the system - but without the source data little can be
done.

A second approach would be to display a local street map which is properly
gridded and indexed to the bus stops within each cell.  This approach is
highly recommended for those who are spatially challenged but this makes the
information accessible only in a visual based environment and clearly not
the best choice for Browser or Visually Impaired users. (Ed: again, I would
be interested in hearing or seeing how maps are used by the visually
impaired, in particular how (or if)general street cartography can be reduced
to allow for both local landmarks while retaining g its meaningfulness.)

So you see, the real issues revolve around user interface and not simply
data technology.  As I (constantly) mentioned earlier, I would be very
interested in hearing or seeing examples of how this type of information can
be imparted.

Regards

R.H. Jannini IV  -  [log in to unmask]
412.351.1627 Voice
412.351.1625 FAX


VICUG-L is the Visually Impaired Computer User Group List.
To join or leave the list, send a message to
[log in to unmask]  In the body of the message, simply type
"subscribe vicug-l" or "unsubscribe vicug-l" without the quotations.
 VICUG-L is archived on the World Wide Web at
http://maelstrom.stjohns.edu/archives/vicug-l.html