03-19-2019, 08:36 AM
(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.