EastYorkTTCFan
Senior Member
I think that has something to do with airflow from the trains going through the tunnel creating a sort of suction effect
I think that has something to do with airflow from the trains going through the tunnel creating a sort of suction effect
mdrejhon
Senior Member
Suction is true, but the resistance is high on certain doors even in situations where it would be assisted by the suction effect. Perhaps they are necessarily high resistance because TTC designs them from popping open due to suction. A good candidate for motorized assist, as resistance can be high until the door is touched by humans...
Student99
Active Member
OH GOD NO.
Coming off a train at 4pm into the Bay Teamway and trying to head north is pure hell. Between people blocking the way looking up at screens, and lines forming to buy tickets, it's just absolutely terrible.
Sorry, but you are "an obstruction" whether you're staring at a screen in the middle of the teamway OR at the entrance of the teamway. Both are equally bad.
They should get rid of ticket vending in the teamway entirely- those who don't have their act together in advance and are looking to buy tickets should have to go into the station proper... there just isn't enough space here. The teamways should be for express boarding/exiting only.
As for people staring at the screens and obstructing, I'm not sure of a good solution, aside from posting the platform numbers much further in advance and putting a massive screen (jumbo-tron style) outside for people to casually glance at as they walk in.
AlvinofDiaspar
Moderator
I have no problem with having screens - I have every problem with the way they positioned them and how it interferes with chokepoints in the worst possible ways. Perhaps information trains/platform might be provided in two stages in the teamway area - indication of platform by teamway entry (perhaps using large format displays), followed by overhead LED displays at the teamway right in front of staircase that indicates line, express and minutes from departure. Don't try to cram everything including the kitchen sink into the display and design the system to handle everyone - those who aren't in the know should be handled by service agents.
And the ticket machines are utterly stupid - sorry, did they ever look at the totem design at say McDonalds? Clear, simple and fast - instead of that space wasting clunker with an utterly unresponsive, unintuitive lag-hell of a UI that felt slower than a first-gen iPad.
AoD
Last edited:
mdrejhon
Senior Member
It's STILL the lesser of evil.
I don't loiter at the entrance of the teamway. I only need to know which platform, as I almost always arrive less than 10 minutes of my GO train, so my platform number is always displayed.
Besides, people will gravitate to timetable screens that are away from people bumping into them. There will be some [bleep]'s that persist, but most commuters will gravitate to a compromise waiting position regardless of where the screens are, as long as they can see the track announcements.
Another solution is to display screens above each platform entrance, which also displays which train they are (e.g. "Lakeshore West"). Like the screens in Platforms 25-27, albiet perhaps landscape orientation rather than portrait orientation. This will provide quicker routes for commuters to get out of the way.
Even us experienced commuters still want to know the Track #. Some of us pre-emptively go on the platform before announcement, knowing the usual platform. But I arrive all over the peak period and so I need to glance the track #, even if I stand beside a bike racks, comfortably completely out of your way.
I use my phone/iPad too (by googling "immediate departures from Union" and clicking the first result -- I'm Feeling Lucky) -- it's faster than trying to visit the gotransit website directly -- when I'm walking on Bay and have reception (rather than subway). Phone reception in the downtown subway should help once it finally arrives in the next while.
Most commuters during peak period arrive less than 10 minutes prior to the train, and the platform number is already displayed in most of these cases.
Those ticket machines were installed there only because the Bay concourse is closed.
I would support their removal afterwards reopening of the Bay Concourse, though!
THAT is an excellent idea.
But not 100% without cons. A jumbotron timetable above the teamway entrance would be great, but there may be too many people loitering in front of the entrance, making things even worse because the jumbotron would encourage an even bigger group of people to loiter waiting to read the track number.
Maybe not, but I'd worry about this unanticipated side effect, especially in the TTC bottleneck and the stairs (accidents running down stairs, when reading jumbotron timetable instead of holding stair rail). So there may also be a liability issue with the jumbotron method.
However, the pros of the jumbotron outweighs the cons, as it would force a lot of people to stop running as they realized their train was delayed, they missed their train, and they could even loiter in the more spacious area near the "UNION STATION" sign, just around the corner, out of the flow of commuters. You could smell the roses of the flower stand, relax for a few minutes to your next train, before walking towards the teamway.
Last edited:
mdrejhon
Senior Member
Agreed on the atrociousness of the GO Ticket vending machines
And designed in almost the same era. Not quite, but almost.
I complain about:
- Lack of caching for searches. Searches should be instant.
- Searches that become slower during peak
- Slow autocomplete of station search, keypress at a time
- Should automatically order stations on most common station
(e.g. typing "U" should display Union first)
- Should have Google-style misspelled station "Did You Mean?" showing in the list
- Should NEVER move the "Cancel" button around. It should never share the same location as the "OK" button of a previous screen. Lag means sometimes you tap Cancel when you meant to tap OK.
I have seen people throw their arms up in frustration at the slow GO ticket machines, even though they arrived 5 minutes before their train, then consequently miss their train. Even a vision-impaired person could see the screen but got very confused by the method of searching for a station (even in assistive mode).
I think the machine hardware could be saved, but the processor needs to be modernized to a cheap GPU-accelerated smartphone processor, with an instant-responding touchscreen. I'm not sure if slowness of the touchscreen is because of the bad software, or also because of the touchscreen hardware. Hopefully it's just the bad software. If so, then all it needs is a processor hardware replacement (embedded computer) and a software rewrite. Redesign the user interface with a faster/cheaper processor, possibly Android-based for lower-cost programming redesign. They probably already spent a fortune designing the machines.
Fortunately not all Metrolinx UIs are a fail. The new machines like the Metrolinx Presto add-value machines, have instant-responding touchscreens. Compared to the older GO ticket vending machines, the Presto AVM machines touchscreen UI is relatively good except for the low height (hard to reach down to the Interac pad/screen). My main nitpick is ergonomic with the Presto AVM machines, but I'm happy enough with their UI. The "insert Presto card" animation should probably be improved with a huge on-screen arrow pointing to the edge of the screen (where the Presto reader is) but other than that, the UI seemed well-designed in comparison.
Last edited:
AlvinofDiaspar
Moderator
I know I have, literally. In any case, I think the text based station entry should be the last ditch option, not the first line of interaction, especially for a touch-based interface - and like you've said, if you going to use text, make it quick and responsive.
AoD
Last edited:
mdrejhon
Senior Member
It's almost bad enough that it could be a viral video. If we had 4 or 5 video clips of people throwing up frustration, that could turn enough heads at Metrolinx to hire a low-budget software rewrite. "Metrolinx made a fast UI for the Presto add-value machines. Why can't it be ported to the older laggy GO ticket machines?" (then cue playback of video)
If we can't replace the hardware, we could at least improve the software a bit (e.g. fixing the Cancel button location) as well as executing instant feedback (as feasibly possible) before doing the processing. Then adding some caching logic.
Then maybe even the processor hardware could be saved -- just a relatively simple software enhancement that could reduce frustrations by ~80-90%. Slight lag (e.g. 1/10th second) before feedback, and searches reduced to 1 second (for a slow processor), making the hardware "usable" without needing a processor replacement (to a modern cheap commodity GPU-accelerated smartphone processor which I heard is now being used in the Presto add-value machines)
-- Adding instant (or as quick as possible) feedback for button taps.
This includes flashing the button before executing any processing tasks. That will at least tell people they tapped the correct button, and their tap worked. The touchscreen might still have slight lag, but it would become the shortest possible lag (~1/10th second) for the given hardware.
-- Do not share screen location for OK and Cancel button
Use blank spaces instead of buttons when disabled. The slow machine lag means a person can end up tapping "Cancel" when they meant to tap "OK".
-- Add caching for searching
Refresh the internal memory once a day (or even a randomized time during every off-peak hour, so not all machines download at the same time) -- rather than everytime a person searches. No server-based searching.
-- Reorder the search results
Display "high-priority" stations higher. (so "Union" would go first when typing "U", and endpoint stations such as "Aldershot" would go higher than "Appleby" if you only typed one letter "A")
This would solve pretty much 80-90% of the complaints. Not all, but you'd save the hardware and even keep the processor.
If we can't replace the hardware, we could at least improve the software a bit (e.g. fixing the Cancel button location) as well as executing instant feedback (as feasibly possible) before doing the processing. Then adding some caching logic.
Then maybe even the processor hardware could be saved -- just a relatively simple software enhancement that could reduce frustrations by ~80-90%. Slight lag (e.g. 1/10th second) before feedback, and searches reduced to 1 second (for a slow processor), making the hardware "usable" without needing a processor replacement (to a modern cheap commodity GPU-accelerated smartphone processor which I heard is now being used in the Presto add-value machines)
-- Adding instant (or as quick as possible) feedback for button taps.
This includes flashing the button before executing any processing tasks. That will at least tell people they tapped the correct button, and their tap worked. The touchscreen might still have slight lag, but it would become the shortest possible lag (~1/10th second) for the given hardware.
-- Do not share screen location for OK and Cancel button
Use blank spaces instead of buttons when disabled. The slow machine lag means a person can end up tapping "Cancel" when they meant to tap "OK".
-- Add caching for searching
Refresh the internal memory once a day (or even a randomized time during every off-peak hour, so not all machines download at the same time) -- rather than everytime a person searches. No server-based searching.
-- Reorder the search results
Display "high-priority" stations higher. (so "Union" would go first when typing "U", and endpoint stations such as "Aldershot" would go higher than "Appleby" if you only typed one letter "A")
This would solve pretty much 80-90% of the complaints. Not all, but you'd save the hardware and even keep the processor.
Last edited:
AlvinofDiaspar
Moderator
It doesn't even need a caching logic - if you are going to use search - just ask the user to type in the first letter of the station nam e- and out pop a list of all the options, in large fonts (and if you want to be make it doubly clear to users who might not have a clue, add the location/municipality name). Select - provide additional details (e.g. which line the station is serving, graphically represent it even) - confirm.
AoD
mdrejhon
Senior Member
The problem is there appears to be some kind of a Metrolinx requirement is that the machines are flexible enough to recognize new GO stations at any minute. So it's always a server-based search.
This means the machines need to update the list of stations at all times, so they just solve that by using server-based searching. The machines seems to connect to the server to do the station search. (Correct me if I am wrong)
They should slack-off this requirement to a daily download to be cached. If they need more often than daily, the station download could be hourly. This is what I meant by caching (pre-downloaded station list). The station search on these machines are server-based, and the server slows down during peak period, which means searches are slower.
What I'm saying is that the server-based search -- now needs to becomes to be a local-based search off a cached/downloaded list of stations. Even with a slow processor (even for 20 Mhz embedded CPUs -- doubt it is that slow -- but...) there's ways of speeding up a local search.
In the unlikely event the machines does not even have enough memory for a station list, that becomes a big problem. I would say even 1 MB of flash ROM would be big enough to hold a daily list of GO stations.
Therefore, some form of caching or downloading is needed whether the terminology is "pre-downloading a list of stations daily", or "caching the list of stations" or whatnot -- it's still semantically a form of caching -- but regardless, the objective is to make searching 100% internal and fast without needing network communications to an overloaded server.
The machines could randomize a station download time during the night and during between the peaks, so not all GO ticket machines start downloading the station list simultaneously. This will avoid overloading the server, while keeping programming simple (no need to program each machine to have a separate scheduled download time), assuming they keep the back-end unmodified or mostly unmodified to keep the budget low.
Would love to know what the specs of these GO ticket machines are, being an IT/programmer guy myself...
Last edited:
AlvinofDiaspar
Moderator
That is insane - couldn't they have pushed that info to the terminal as required instead of sending the query to a server every. single. time?
AoD
mdrejhon
Senior Member
Facepalm is all I can say.
It's why the searches are slower during peak period.
</facepalm>
Alvin, you're a moderator.... want to move these two or three GO Ticket Machines posts into a new thread labelled "GO Ticket Machine Problems" or even a "Fare Vending Machine Design" thread (catchall...), to let everybody vent? Maybe it will someday catch attention at Metrolinx.
Jonny5
Senior Member
Yesterday I waited in a line to use the presto fare load machine in the York Concourse. One of the two machines was not working, so we all waited in line for the other machine.
Then a GO customer service attendant came up and said to everyone "If the machine is not working just press 111 (I think that's what he said) on the keypad and it will reset." Then he did just that and the machine was instantly fine.
Everyone was all dumbfounded, like, if there's a simple way to reset it, and it's not a "secret" for staff only, why not put up a damn sign that says how to do it?
Then a GO customer service attendant came up and said to everyone "If the machine is not working just press 111 (I think that's what he said) on the keypad and it will reset." Then he did just that and the machine was instantly fine.
Everyone was all dumbfounded, like, if there's a simple way to reset it, and it's not a "secret" for staff only, why not put up a damn sign that says how to do it?
Richard White
Senior Member
Probably for the same reason people do not mention "711" on telephones. There is a trick wherein Payphones can be rendered inoperable by dialling 711. It tries to connect to the relay service, senses it cannot do so, assumes a problem and shuts down.
No doubt "111" works on presto machines but imagine what would happen if it is was public knowledge? It would cause more problems than it solves.
Komiksulo
Active Member
And do the machines only sell fares to GO rail stations? ISTR trying to buy a ticket from Union to Peterborough and not having the choice. Maybe a second set of destinations could be bus terminals and ticket agencies.