+- 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)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
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.
(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.
RE: Grand River Transit - danbrotherston - 03-19-2019
(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.
RE: Grand River Transit - Canard - 03-19-2019
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”?!
RE: Grand River Transit - ijmorlan - 03-19-2019
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.
RE: Grand River Transit - trainspotter139 - 03-19-2019
(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.