Waterloo Region Connected
Grand River Transit - Printable Version

+- Waterloo Region Connected (https://www.waterlooregionconnected.com)
+-- Forum: Waterloo Region Works (https://www.waterlooregionconnected.com/forumdisplay.php?fid=14)
+--- Forum: Transportation and Infrastructure (https://www.waterlooregionconnected.com/forumdisplay.php?fid=25)
+--- Thread: Grand River Transit (/showthread.php?tid=13)



RE: Grand River Transit - trainspotter139 - 03-18-2019

(03-18-2019, 11:13 AM)danbrotherston Wrote:
(03-18-2019, 11:01 AM)trainspotter139 Wrote: Changes coming to Route 76 for September Service Changes which will see the route split into two routes. The new route 36 will use larger conventional buses every 30 minutes as opposed to the smaller busPLUS buses currently in use. Route 76 will also get midday service

Does this mean the routes ridership has grown to exceed that of the smaller vans?

That would be great news.

The driver I talked to said they were standing room only (possibly exceeding registered vehicle capacity) for most trips to Conestoga during morning peak and from Conestoga during afternoon peak. From the P&W Committee Agenda:


Quote:Route 76 Doon South – BusPLUS service – Continued growth in demand on Route 76 BusPLUS from Conestoga College students living in the Doon South area has strained the capacity of the current Route 76 Bus Plus service. Staff have evaluated service improvement options that would better accommodate anticipated ridership growth in September 2019 when the Conestoga College U-Pass program will take effect.

The preferred option for Doon South is shown in Appendix C. Route 76 would be realigned to connect Pioneer Park Plaza to Conestoga College via Doon Mills and Doon South Drive. A new Route 36 using a conventional bus would serve the south part of the subdivision, connecting to the college using Robert Ferrie Drive, Doon South Drive, Thomas Slee Drive and New Dundee Road. This would provide the additional capacity required for the growing ridership demand in this area.  Route 36 would ultimately travel along the future extension of Strasburg Road as identified in the GRT Business Plan.

As noted in the table above, a PIC outlining potential service improvements to Route 76 is planned for April 9th.



RE: Grand River Transit - trainspotter139 - 03-18-2019

(03-18-2019, 10:56 AM)danbrotherston Wrote: Anyone have any theories as to what "Actionlist Entry performed ACT. FUNCTION" means?

Definitely a contender for worst UX award.

Did you register your card recently? That could have been attaching the account ID, etc. to the card so that if/when you lose it and block it the fareboxes will react to that properly.


RE: Grand River Transit - danbrotherston - 03-18-2019

(03-18-2019, 11:41 AM)trainspotter139 Wrote:
(03-18-2019, 10:56 AM)danbrotherston Wrote: Anyone have any theories as to what "Actionlist Entry performed ACT. FUNCTION" means?

Definitely a contender for worst UX award.

Did you register your card recently? That could have been attaching the account ID, etc. to the card so that if/when you lose it and block it the fareboxes will react to that properly.

That is possible, the date does align with when I registered the card.

Interestingly, it gives the location as GRT Strasbourg (which is already a stupid thing to do), instead of a more meaningful value like "Web Portal" as is seen on other lines.


RE: Grand River Transit - trainspotter139 - 03-18-2019

(03-18-2019, 12:53 PM)danbrotherston Wrote:
(03-18-2019, 11:41 AM)trainspotter139 Wrote: Did you register your card recently? That could have been attaching the account ID, etc. to the card so that if/when you lose it and block it the fareboxes will react to that properly.

That is possible, the date does align with when I registered the card.

Interestingly, it gives the location as GRT Strasbourg (which is already a stupid thing to do), instead of a more meaningful value like "Web Portal" as is seen on other lines.

GRT Strasburg and GRT Conestoga are used whenever a bus performs an update to a card. I think it shows the garage of the bus or the location of the machine that updated the card vs where the transaction was processed.


RE: Grand River Transit - danbrotherston - 03-18-2019

(03-18-2019, 01:30 PM)trainspotter139 Wrote:
(03-18-2019, 12:53 PM)danbrotherston Wrote: That is possible, the date does align with when I registered the card.

Interestingly, it gives the location as GRT Strasbourg (which is already a stupid thing to do), instead of a more meaningful value like "Web Portal" as is seen on other lines.

GRT Strasburg and GRT Conestoga are used whenever a bus performs an update to a card. I think it shows the garage of the bus or the location of the machine that updated the card vs where the transaction was processed.

I did gather that, but it doesn't mean it isn't stupid. GRT's customers don't care that buses are parked on Strasbourg Rd. and such things should under no circumstances appear in the UI.

The average user is going to be very confused why GRT thinks they are getting on/off the bus on Strasbourg Rd.


RE: Grand River Transit - trainspotter139 - 03-18-2019

(03-18-2019, 01:48 PM)danbrotherston Wrote:
(03-18-2019, 01:30 PM)trainspotter139 Wrote: GRT Strasburg and GRT Conestoga are used whenever a bus performs an update to a card. I think it shows the garage of the bus or the location of the machine that updated the card vs where the transaction was processed.

I did gather that, but it doesn't mean it isn't stupid. GRT's customers don't care that buses are parked on Strasbourg Rd. and such things should under no circumstances appear in the UI.

The average user is going to be very confused why GRT thinks they are getting on/off the bus on Strasbourg Rd.

The farebox isn't tied in to the INIT CAD/AVL (Computer-Aided Dispatch/Automatic Vehicle Location) system and so they wouldn't necessarily know that information


RE: Grand River Transit - danbrotherston - 03-18-2019

(03-18-2019, 02:04 PM)trainspotter139 Wrote:
(03-18-2019, 01:48 PM)danbrotherston Wrote: I did gather that, but it doesn't mean it isn't stupid. GRT's customers don't care that buses are parked on Strasbourg Rd. and such things should under no circumstances appear in the UI.

The average user is going to be very confused why GRT thinks they are getting on/off the bus on Strasbourg Rd.

The farebox isn't tied in to the INIT CAD/AVL (Computer-Aided Dispatch/Automatic Vehicle Location) system and so they wouldn't necessarily know that information

I'm sure they could be connected together, although I am sure that would be expensive. Probably cheaper is simply to include a GPS unit in the farebox. But even cheaper than that is to simply use the route number as the location (and for bonus points, cross reference the schedule, or even the actual GPS track for location at a later time).

But failing all those other reasonable options, don't show the location. Right now that field is garbage data which serves no purpose for the end user, and only serves to diminish the user experience.


RE: Grand River Transit - robdrimmie - 03-18-2019

(03-18-2019, 02:04 PM)trainspotter139 Wrote: The farebox isn't tied in to the INIT CAD/AVL (Computer-Aided Dispatch/Automatic Vehicle Location) system and so they wouldn't necessarily know that information

There are all kinds of systematic reasons presenting the information in a manner that is useful to the end user is hard, and it all makes sense. That doesn't mean that it's a good solution, just that it's the least amount of effort possible to solve a problem, which is a reasonable way to describe my complaint with every piece of software developed by eSolutions. They are incentivized to do the bare minimum (because they are an agency, and because the Region only has so much money to put into these products).

It's easy to understand why an implementation is poor, but that doesn't invalidate criticisms of that implementation, nor does it really justify the poor implementation. The follow-on costs of supporting this tool's bad interface are going to exceed the cost of improving the experience by even a moderate amount, but the latter costs more today and therefore the latter will be someone else's headache.


RE: Grand River Transit - KevinT - 03-18-2019

(03-18-2019, 11:13 AM)danbrotherston Wrote:
(03-18-2019, 11:01 AM)trainspotter139 Wrote: Changes coming to Route 76 for September Service Changes which will see the route split into two routes. The new route 36 will use larger conventional buses every 30 minutes as opposed to the smaller busPLUS buses currently in use. Route 76 will also get midday service

Does this mean the routes ridership has grown to exceed that of the smaller vans?

That would be great news.

On my drive to work this morning I saw the 76 busPLUS bypass the eastbound stop on Thomas Slee just past Doon South Dr where there was 10 or so people waiting for it.  It stopped at the next two stops that had 1 person each, so I guess the policy is if they don't have room for all then pick up none.  Sad  (Either that or I misinterpreted what I saw.)


RE: Grand River Transit - ijmorlan - 03-18-2019

(03-18-2019, 04:19 PM)robdrimmie Wrote:
(03-18-2019, 02:04 PM)trainspotter139 Wrote: The farebox isn't tied in to the INIT CAD/AVL (Computer-Aided Dispatch/Automatic Vehicle Location) system and so they wouldn't necessarily know that information

There are all kinds of systematic reasons presenting the information in a manner that is useful to the end user is hard, and it all makes sense. That doesn't mean that it's a good solution, just that it's the least amount of effort possible to solve a problem, which is a reasonable way to describe my complaint with every piece of software developed by eSolutions. They are incentivized to do the bare minimum (because they are an agency, and because the Region only has so much money to put into these products).

It's easy to understand why an implementation is poor, but that doesn't invalidate criticisms of that implementation, nor does it really justify the poor implementation. The follow-on costs of supporting this tool's bad interface are going to exceed the cost of improving the experience by even a moderate amount, but the latter costs more today and therefore the latter will be someone else's headache.

Well said. Based on the sample account statement posted to an earlier posting in this thread, I am not impressed. In addition to the issues mentioned by people, it appears that many transactions (as understood by anybody using the system) are listed twice in the transaction listing.

One of the challenges that often arises in computer systems is displaying information in a meaningful way. Just because a direct dump of the database contents is not meaningful to users does not mean they are wrong. In this case the transaction listing gets a big fail from me.

And that is my (partial) professional opinion.

With more information and time, I could give a more complete opinion which would include suggested fixes and perhaps hints as to how the poor interface came about. But there is no new information other than “the transaction listing was faked” which could reverse my judgement that the interface is bad. I don’t have to know why it is that way or what challenges may exist to know it’s bad.

And by the way, the Region, and every organization of any significant size, should have its own programming staff. Not for absolutely everything, obviously, but to create small and medium scale systems that connect together everything else and cover gaps in other systems. Every organization is an IT organization now. Suggesting that they shouldn’t have programmers is like, and really almost the same thing as, suggesting that they shouldn’t have managers but instead contract out all management activity. In short, utterly insane.


RE: Grand River Transit - trainspotter139 - 03-18-2019

(03-18-2019, 07:10 PM)ijmorlan Wrote:
(03-18-2019, 04:19 PM)robdrimmie Wrote: There are all kinds of systematic reasons presenting the information in a manner that is useful to the end user is hard, and it all makes sense. That doesn't mean that it's a good solution, just that it's the least amount of effort possible to solve a problem, which is a reasonable way to describe my complaint with every piece of software developed by eSolutions. They are incentivized to do the bare minimum (because they are an agency, and because the Region only has so much money to put into these products).

It's easy to understand why an implementation is poor, but that doesn't invalidate criticisms of that implementation, nor does it really justify the poor implementation. The follow-on costs of supporting this tool's bad interface are going to exceed the cost of improving the experience by even a moderate amount, but the latter costs more today and therefore the latter will be someone else's headache.

Well said. Based on the sample account statement posted to an earlier posting in this thread, I am not impressed. In addition to the issues mentioned by people, it appears that many transactions (as understood by anybody using the system) are listed twice in the transaction listing.

One of the challenges that often arises in computer systems is displaying information in a meaningful way. Just because a direct dump of the database contents is not meaningful to users does not mean they are wrong. In this case the transaction listing gets a big fail from me.

And that is my (partial) professional opinion.

With more information and time, I could give a more complete opinion which would include suggested fixes and perhaps hints as to how the poor interface came about. But there is no new information other than “the transaction listing was faked” which could reverse my judgement that the interface is bad. I don’t have to know why it is that way or what challenges may exist to know it’s bad.

And by the way, the Region, and every organization of any significant size, should have its own programming staff. Not for absolutely everything, obviously, but to create small and medium scale systems that connect together everything else and cover gaps in other systems. Every organization is an IT organization now. Suggesting that they shouldn’t have programmers is like, and really almost the same thing as, suggesting that they shouldn’t have managers but instead contract out all management activity. In short, utterly insane.

the system often processes multiple actions on the card during a card tap. I personally think they should do a summary of those actions with an expander to see more details like the individual actions that occurred at that specific timestamp.


RE: Grand River Transit - danbrotherston - 03-18-2019

(03-18-2019, 08:57 PM)trainspotter139 Wrote:
(03-18-2019, 07:10 PM)ijmorlan Wrote: Well said. Based on the sample account statement posted to an earlier posting in this thread, I am not impressed. In addition to the issues mentioned by people, it appears that many transactions (as understood by anybody using the system) are listed twice in the transaction listing.

One of the challenges that often arises in computer systems is displaying information in a meaningful way. Just because a direct dump of the database contents is not meaningful to users does not mean they are wrong. In this case the transaction listing gets a big fail from me.

And that is my (partial) professional opinion.

With more information and time, I could give a more complete opinion which would include suggested fixes and perhaps hints as to how the poor interface came about. But there is no new information other than “the transaction listing was faked” which could reverse my judgement that the interface is bad. I don’t have to know why it is that way or what challenges may exist to know it’s bad.

And by the way, the Region, and every organization of any significant size, should have its own programming staff. Not for absolutely everything, obviously, but to create small and medium scale systems that connect together everything else and cover gaps in other systems. Every organization is an IT organization now. Suggesting that they shouldn’t have programmers is like, and really almost the same thing as, suggesting that they shouldn’t have managers but instead contract out all management activity. In short, utterly insane.

the system often processes multiple actions on the card during a card tap. I personally think they should do a summary of those actions with an expander to see more details like the individual actions that occurred at that specific timestamp.

The fact that multiple entries are made in a database is irrelevant to a user. From their perspective only one thing happened, they paid to get on the bus.

The back end implementation should not drive the front end.  The user needs should drive the front end experience.

Too their credit however, GRT knows about the issue, and this is at least not final:




RE: Grand River Transit - Spokes - 03-18-2019

Why wouldn't they get it right before launching?


RE: Grand River Transit - trainspotter139 - 03-19-2019

(03-18-2019, 09:08 PM)danbrotherston Wrote:
(03-18-2019, 08:57 PM)trainspotter139 Wrote: the system often processes multiple actions on the card during a card tap. I personally think they should do a summary of those actions with an expander to see more details like the individual actions that occurred at that specific timestamp.

The fact that multiple entries are made in a database is irrelevant to a user. From their perspective only one thing happened, they paid to get on the bus.

The back end implementation should not drive the front end.  The user needs should drive the front end experience.

Too their credit however, GRT knows about the issue, and this is at least not final:


I would argue that multiple actions being performed on a user's card is very much relevant to many users, even if it's not relevant to you.

Imagine for a moment that you loaded $20 onto your card through the online portal. 24-48 hours later, you tap your card on a GRT bus for your regular commute. You look at your card activity 24-48 hours later to see a row that says: 


Code:
"03/19/2019 7:10 AM | Card Tap | GRT Bus #21101 (Route 7 - to Conestoga Stn) | +$17.24 | $21.72"


Knowing a bit about how the system works you arrive at the conclusion that this card tap loaded the $20 you loaded online.

Not every user will arrive at the same conclusion on their own however. That's why it's important to design User Experiences that accommodate users of all skill levels. It may not be relevant to you that multiple transactions occurred on the card at the time of tap, but it is to another user. A summary row in the table that can expand to show the individual transactions is absolutely a good user experience. Not all users will need to expand the row to understand what is going on with the card, but those that do should be allowed to see the list of transactions that occurred: 

Code:
"03/19/2019 7:10 AM | Card Load              | GRT Bus #21101 (Route 7 - to Conestoga Stn) | +$20.00 | $24.48"
"03/19/2019 7:10 AM | Fare Paid - SV Adult   | GRT Bus #21101 (Route 7 - to Conestoga Stn) | -$ 2.76 | $21.72"
"03/19/2019 7:10 AM | Issue Transfer - Adult | GRT Bus #21101 (Route 7 - to Conestoga Stn) |  $ 0.00 | $21.72"



RE: Grand River Transit - Canard - 03-19-2019

It’s amazing: we managed to make a system even worse and more confusing than Presto.