Welcome Guest!
In order to take advantage of all the great features that Waterloo Region Connected has to offer, including participating in the lively discussions below, you're going to have to register. The good news is that it'll take less than a minute and you can get started enjoying Waterloo Region's best online community right away.
or Create an Account




Thread Rating:
  • 3 Vote(s) - 4.67 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Grand River Transit
(03-19-2019, 07:56 AM)trainspotter139 Wrote:
(03-18-2019, 09:08 PM)danbrotherston Wrote: 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"

It's absolutely clear from context that I mean one user operation that equals multiple end operations should not be multiple operations, not that all a users operations should be condensed into one line.

Obviously, add 20 dollars, and then get on a bus, I've done two things, and I should see those two thing in the record, and thus there should be two records.

That being said, I also disagree with your records here, adding funds should not show as a result of the bus terminal, it should show at the time I did it, because that's when my experience suggests it happened.

Since we do have an unfortunately leaky abstraction, there could be a "card update" when I get on the bus, but from a user perspective, I spent that money the day before online, not on a bus.

This point is not what the operations are, it's what the user experience demands.  Listing "issuing transfer" is an implementation detail, that users no longer need to worry about.  It will probably only serve to confuse, what if I don't want to transfer, why do I always get a transfer.  It should only show when you board a bus with a transfer, because that's a record of the transaction that a user cares about.

Now, I'm not saying all users are created equal, a fare inspector is a different user, who needs to see that record, as does the payment terminal, but an experience should be customized to the particular user in question.
Reply


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”?!
For daily ion construction updates, photos and general urban rail news, follow me on twitter! @Canardiain
Reply
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.
Reply
(03-19-2019, 09:21 AM)Canard Wrote: 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.
Reply
(03-19-2019, 10:19 AM)trainspotter139 Wrote:
(03-19-2019, 09:21 AM)Canard Wrote: 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.

It does not matter that the system is implemented that way.  What matters is how the users model of the system. Forcing your users to understand implementation details (including things like knowing what 'SV' stand for) is a guarantee that your users will not understand your system, and will make mistakes when using it. Good UX absolutely should remove access to information which doesn't enhance the user experience.

Presto is another example of an unnecessary and overly complex system.  To this day, myself, a relative expert in how Presto works, still cannot figure out what every line in the presto record means, and generally I need a calculator to figure out how much I paid for one trip. That is a complete failure.

You really should go read the book "The design of Everyday Things" by Don Norman. It is eye opening.
Reply
(03-19-2019, 10:25 AM)danbrotherston Wrote:
(03-19-2019, 10:19 AM)trainspotter139 Wrote: 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.

It does not matter that the system is implemented that way.  What matters is how the users model of the system. Forcing your users to understand implementation details (including things like knowing what 'SV' stand for) is a guarantee that your users will not understand your system, and will make mistakes when using it. Good UX absolutely should remove access to information which doesn't enhance the user experience.

Presto is another example of an unnecessary and overly complex system.  To this day, myself, a relative expert in how Presto works, still cannot figure out what every line in the presto record means, and generally I need a calculator to figure out how much I paid for one trip. That is a complete failure.

You really should go read the book "The design of Everyday Things" by Don Norman. It is eye opening.

The problem is, there is money involved. You simply can't remove access to the minute details of what goes on because it is relevant to users. Users who are money savvy are going to want to know those details. 

You can have the best of both worlds here. You can have easy to read and easy to follow information about changes in card balance in the card history view AND access to minute details of a specific card tap without compromising UX.
Reply
(03-19-2019, 09:54 AM)ijmorlan Wrote: 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.

Yes, I meant to call this sentiment out and emphatically agree with it in your earlier post. I'm more and more inclined to think that the easygofarecard site has to be on a separate domain because they're using tooling provided by the vendor of the system with a very thin layer of colour and logo customization on top of it, built by an outsourced organization.

I think there's a fair argument to be made for outsourcing IT and development for some organizations and systems, but do heartily agree about this specific case. Managing fares and the relationship with riders should be considered a core competency for the GRT. The knowledge and understanding and that comes from building and maintaining the system should be owned (both financially and in the responsibility sense) internally.
Reply
(03-19-2019, 12:50 PM)trainspotter139 Wrote:
(03-19-2019, 10:25 AM)danbrotherston Wrote: It does not matter that the system is implemented that way.  What matters is how the users model of the system. Forcing your users to understand implementation details (including things like knowing what 'SV' stand for) is a guarantee that your users will not understand your system, and will make mistakes when using it. Good UX absolutely should remove access to information which doesn't enhance the user experience.

Presto is another example of an unnecessary and overly complex system.  To this day, myself, a relative expert in how Presto works, still cannot figure out what every line in the presto record means, and generally I need a calculator to figure out how much I paid for one trip. That is a complete failure.

You really should go read the book "The design of Everyday Things" by Don Norman. It is eye opening.

The problem is, there is money involved. You simply can't remove access to the minute details of what goes on because it is relevant to users. Users who are money savvy are going to want to know those details. 

You can have the best of both worlds here. You can have easy to read and easy to follow information about changes in card balance in the card history view AND access to minute details of a specific card tap without compromising UX.

Yes, you can remove those details, the designer is in fact in control of the user interface. When you see your bank transactions, you don't see every minutia of the transaction, but you see an impression of it consistent with your understanding of what a transaction is, and because it matches your mental model, you don't even object.

I'm sure some people have been curious as to what actually happens under the hood, but so what, it still works fine for them. Just because I'm a savvy user who want's to know those details (I don't actually), doesn't mean I should be allowed to know them.  It's wrong to degrade the user experience for everyone, in order to satisfy the curiosity of a few users.

Yes, you can enhance the interface to provide access to this underlying data in some way, but that's not what was done here, just because you can provide access to this data doesn't mean this is a good interface.  This is a terrible interface.
Reply
“It's wrong to degrade the user experience for everyone, in order to satisfy the curiosity of a few users.”

I may not often agree with Dan but this is so true! Simplify, simplify, simplify.
Reply
(03-19-2019, 01:11 PM)danbrotherston Wrote:
(03-19-2019, 12:50 PM)trainspotter139 Wrote: The problem is, there is money involved. You simply can't remove access to the minute details of what goes on because it is relevant to users. Users who are money savvy are going to want to know those details. 

You can have the best of both worlds here. You can have easy to read and easy to follow information about changes in card balance in the card history view AND access to minute details of a specific card tap without compromising UX.

Yes, you can remove those details, the designer is in fact in control of the user interface. When you see your bank transactions, you don't see every minutia of the transaction, but you see an impression of it consistent with your understanding of what a transaction is, and because it matches your mental model, you don't even object.

I'm sure some people have been curious as to what actually happens under the hood, but so what, it still works fine for them.  Just because I'm a savvy user who want's to know those details (I don't actually), doesn't mean I should be allowed to know them.  It's wrong to degrade the user experience for everyone, in order to satisfy the curiosity of a few users.

Yes, you can enhance the interface to provide access to this underlying data in some way, but that's not what was done here, just because you can provide access to this data doesn't mean this is a good interface.  This is a terrible interface.

You are missing the point. You cannot simply not have a way to show all the details of what each card tap does and how it affects the balance of the card. If you were to design it the way you are suggesting, more users would complain about not being able to see more detailed information than if they just stuck with the existing design.
Reply
(03-19-2019, 01:27 PM)creative Wrote: “It's wrong to degrade the user experience for everyone, in order to satisfy the curiosity of a few users.”

I may not often agree with Dan but this is so true! Simplify, simplify, simplify.

This isn't about the curiosity of a few users. This is about financial transparency. Users always want to know what happens to their money.
Reply
When is the last time you complained about not seeing all the minutia behind your banking transactions, or felt that there was no transparency on where your money was going? Trust me, you're not seeing all the details.

I'm not suggesting doing the things you claim I'm suggesting--and this is the second time I have explained that. In fact, the current design does the things you say would be bad, it hides that relevant information through obscurity and broken design. The presto interface is the best example, I can never see how much money something cost me. But on the GRT design, I still cannot see how the amount column affects my balance.

I'm suggesting designing the interface so that it shows information relevant to the model the user has. That means by definition, if the information is important to the user, it is shown, if it isn't it's hidden, and the information is presented in a way that is consistent with how the user understands the system. That is *NOT* the case that is happening now.
Reply
I think there is value in exposing all the details to users, but I don't think it's a hard requirement.

Also, I work on a bank application. There's a lot of details about their money that is impossible for users to see. Dan's example is a good one.
Reply
(03-19-2019, 02:00 PM)robdrimmie Wrote: Also, I work on a bank application. There's a lot of details about their money that is impossible for users to see. Dan's example is a good one.

Ha! Worked on (the back end of) a home banking application for one of the big Canadian banks. Then Internet happened and a whole lot of work had to be thrown out and done again. Smile
Reply
« Next Oldest | Next Newest »



Possibly Related Threads...
  Grand River Transit Fantasy westwardloo 35 20,719 07-17-2017, 04:22 PM
Last Post: Coke6pk

Forum Jump:


Users browsing this thread: 1 Guest(s)

About Waterloo Region Connected

Launched in August 2014, Waterloo Region Connected is an online community that brings together all the things that make Waterloo Region great. Waterloo Region Connected provides user-driven content fueled by a lively discussion forum covering topics like urban development, transportation projects, heritage issues, businesses and other issues of interest to those in Kitchener, Waterloo, Cambridge and the four Townships - North Dumfries, Wellesley, Wilmot, and Woolwich.

              User Links