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:
  • 4 Vote(s) - 4.75 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Grand River Transit
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”?!
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
Can't find if this was posted previously but it looks like the bid for the UW transit station has been cancelled. There were only 2 bidders and it must have been over their approved budget.

https://regionofwaterloo.bidsandtenders....aba71859e3
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Invisible User(s), 9 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