Grand River Transit

[danbrotherston]

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.

[trainspotter139]

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

[danbrotherston]

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.

[robdrimmie]

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.

[KevinT]

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.    (Either that or I misinterpreted what I saw.)

[ijmorlan]

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.

[trainspotter139]

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.

[danbrotherston]

[Spokes]

Why wouldn't they get it right before launching?

[trainspotter139]

[Canard]

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

[danbrotherston]

[Canard]

100% with Dan.

Presto is ridiculously confusing as it is. This has like 3X the line items making it even worse.

I tap on a bus - that’s one line. One thing. It should not be multiple things. And what the heck is a “SV”?!

[ijmorlan]

One problem I saw with the transaction listing is that the amounts in the Amount column don’t add up to the balance. In a normal bank account listing, the balance is always the sum of the previous balance with the transaction amount. I would actually be OK with tapping on a bus and getting:

1) fare paid -$2.50
2) transfer issued $0

Not ideal, and would almost certainly be better to list the transfer issued as part of the fare paid line, but at least the money would make sense. Right now, I challenge anybody to explain what is happening with the money balance.

And as somebody else said, on-bus terminals should not be listed as the home garage of the bus. I could understand if they said “GRT Bus 21110 Front” but if GRT is actually in control of its IT plant then adding on “Route 5 Trip 0501” would not be difficult.

Part of the problem of course is that many organizations have given up on maintaining control of their IT systems. They think it’s just peachy to have external vendors controlling their data and how they access it. This should be considered absolutely unacceptable, in the same way that they would consider it unacceptable for unpaid interns to do all their cash handling.

[trainspotter139]

100% with Dan.

Presto is ridiculously confusing as it is. This has like 3X the line items making it even worse.

I tap on a bus - that’s one line. One thing. It should not be multiple things. And what the heck is a “SV”?!

When you pay with Stored Value (SV) it's not a single transaction. It's multi-part transaction composed of individual actions. Another action is added if there's a pending load transaction in the system. Because of the way the system works a load transaction occurs at the time of a card tap and the card is loaded at the farebox not at the time you purchased the fare product and not online.

I don't agree with Dan on this because over simplifying what happens with the card can confuse some users of the system. Good UX shouldn't remove access to information that some users would find helpful.

Presto, for example, has a transfer credit that is credited to the card when you transfer between GO buses and between some other transit agencies that use Presto. That credit is credited to the balance of the card on a card tap and is a separate action from the initial fare subtracted when you tap on the GO bus you may transfer to.