SUBWAY - Random Thoughts Topic

[RailRunRob]

44 minutes ago, Around the Horn said:

I'd like to see that manual @RailRunRob

LOL it was just a extremely random thought I had while I was on an R44. Figured I'd ask it even if the answer was kinda obvious...

Yep, no worries Ill try to get that when I get a chance.

[CenSin]

10 hours ago, RailRunRob said:

Speaking of programs I have the Koito software manual for the program that creates the FIND and route programs. My guys at Kawasaki sent me a copy a few years back.  Can try to upload if anyone's interested.

These guys definitely did not hire a UX designer. The interface is horrible! The program itself seems to be created using Microsoft Visual Studio—perhaps a C# of VB.NET program.

[RailRunRob]

9 minutes ago, CenSin said:

These guys definitely did not hire a UX designer. The interface is horrible! The program itself seems to be created using Microsoft Visual Studio—perhaps a C# of VB.NET program.

Welp as a person that handles UX and UX research on a daily basis they definitely put function over form. Before I'd immerse myself within User pains and gains this is such a small userbase of select folks in the MTA user experience is an afterthought. These route programs aren't updated very often speed isn't a super important metric as long as the user can complete the tasks and objective. But to your point it's bare bones haha.. And you're correct it is based on Visual C++/.NET there's also integration with Adobe premiere for videos on the FIND LCD's. 

[CenSin]

9 hours ago, RailRunRob said:

Welp as a person that handles UX and UX research on a daily basis they definitely put function over form. Before I'd immerse myself within User pains and gains this is such a small userbase of select folks in the MTA user experience is an afterthought. These route programs aren't updated very often speed isn't a super important metric as long as the user can complete the tasks and objective. But to your point it's bare bones haha.. And you're correct it is based on Visual C++/.NET there's also integration with Adobe premiere for videos on the FIND LCD's. 

I’ve dabbled in C++/CLI before. That language doesn’t get much attention from Microsoft anymore and programming front-end applications in it is a pain. It is good for two things though: acting as a layer between non .NET code and .NET code; and accessing “the metal.”

[RailRunRob]

6 minutes ago, CenSin said:

I’ve dabbled in C++/CLI before. That language doesn’t get much attention from Microsoft anymore and programming front-end applications in it is a pain. It is good for two things though: acting as a layer between non .NET code and .NET code; and accessing “the metal.”

I have a .net guy on staff we have a few enterprise platforms under our belt and our dealing with Azure abysmal so I agree with your Microsoft statement. Most of our current projects are Angular and Node JS based.We still push Python quite abit as well. I really only get hands-on with iOS projects on the coding side im an Objective C and Swift guy. Everything else I main head up UX and QA so Sketch, Photoshop and Invision on the pallet and the rest I leave to my team smart guys/gals than me. 

[RailRunRob]

27 minutes ago, CenSin said:

I’ve dabbled in C++/CLI before. That language doesn’t get much attention from Microsoft anymore and programming front-end applications in it is a pain. It is good for two things though: acting as a layer between non .NET code and .NET code; and accessing “the metal.”

I have a .net guy on staff we have a few enterprise platforms under our belt and our dealing with Azure abysmal so I agree with your Microsoft statement. Most of our current projects are Angular and Node JS based.We still push Python quite a bit as well. I really only get hands-on with iOS projects on the coding side im an Objective C and Swift guy. Everything else I mainly head up UX and QA so Sketch, Photoshop, and Invision on the pallet and the rest I leave to my team smarter guys/gals than me. 

Edited October 3, 2017 by RailRunRob

[itmaybeokay]

On 9/27/2017 at 6:15 PM, RES2773 said:

https://twitter.com/TransitCenter/status/912839216333279232 shows something very interesting:

 

I don't see any news on this anywhere. Does anyone know what is going on with this?

That looks like what's described in this article from last summer

https://www.theverge.com/2016/8/24/12614986/mta-subway-new-york-mobile-ticket-masabi-mastercard

 

Quote

Masabi is working with a number of other companies to develop a prototype casing with a multi-format reader to be mounted on the turnstiles at New York City subway stations, Zanghi said. “So anyone coming in from commuter rail can use their joint ticket they purchased to scan in and easily jump on the subway.

This looks like it would read NFC as well - which I hope is what they go with for primary fare-payment, as I'd imagine the glass getting dirty on these things would present a hindrance to their quickly and accurately reading the code. I know QR has some redundancy, but - idk man, optical recognition seems like the worst thing in the world in the subway - just an instinct. 

Also relevant, MTA Press release from July 2016

http://www.mta.info/press-release/mta-headquarters/governor-cuomo-announces-accelerated-rollout-mta-etix-mobile

Quote

Next year, the MTA expects to make the MTA eTix app even more user-friendly by allowing LIRR and Metro-North customers who transfer to or from the New York City Subway or New York City Buses to pay their fares using a single app and a single transit account. This announcement comes in concert with the MTA’s issuance of request for proposals to create a new fare payment system for MTA New York City Transit subway and buses, MTA Bus, and the Staten Island Railway. The system will be fully interoperable with the MTA eTix app, and will offer a variety of convenient ways to pay for fares, including smartphones, contactless bank cards, and pre-paid cards.

 

Takeaway #2: Given the way people fumble with metrocards, this is gonna make people drop their phones, and then the QR won't scan from a broken screen. 

[RailRunRob]

18 minutes ago, itmaybeokay said:

That looks like what's described in this article from last summer

https://www.theverge.com/2016/8/24/12614986/mta-subway-new-york-mobile-ticket-masabi-mastercard

 

This looks like it would read NFC as well - which I hope is what they go with for primary fare-payment, as I'd imagine the glass getting dirty on these things would present a hindrance to their quickly and accurately reading the code. I know QR has some redundancy, but - idk man, optical recognition seems like the worst thing in the world in the subway - just an instinct. 

Also relevant, MTA Press release from July 2016

http://www.mta.info/press-release/mta-headquarters/governor-cuomo-announces-accelerated-rollout-mta-etix-mobile

 

Takeaway #2: Given the way people fumble with metrocards, this is gonna make people drop their phones, and then the QR won't scan from a broken screen. 

2

Anything QR nowaday's is counterproductive it's essentially an extra step in the process. The MTA is such a lumbering giant by the time they figured out there move forward technology has moved on. 3 years ago maybe QR might have made sense for compatibility after all NFC wasn't as widespread. The second thing is upkeep and maintenance having to clean glass, check mirrors and the cost associated with that and your point of the riders screen and that variable.  Just a bad move IMO. QR will be phased out in 4 years or less. Anyone from the MTA here listening go all in on TTP(Tap To Pay) Faceplam       

[itmaybeokay]

5 hours ago, RailRunRob said:

Anything QR nowaday's is counterproductive it's essentially an extra step in the process. The MTA is such a lumbering giant by the time they figured out there move forward technology has moved on. 3 years ago maybe QR might have made sense for compatibility after all NFC wasn't as widespread. The second thing is upkeep and maintenance having to clean glass, check mirrors and the cost associated with that and your point of the riders screen and that variable.  Just a bad move IMO. QR will be phased out in 4 years or less. Anyone from the MTA here listening go all in on TTP(Tap To Pay) Faceplam       

In fairness, I don't think they are going to be using QR for standard farecards, just for fare payment from within the MTA eTix app. That reader seems to also contain NFC  - at least, it has an NFC logo on it. 

On the one hand, I agree - QR - or really, any form of optical recognition is both backwards and failure-prone. 

On the other hand, without dramatically upending the nature of - and requirements for - their LIRR mobile ticketing solution - I'm not sure what else you could do. The options are either:

1) Disallow combination monthly LIRR/Metrocard purchases via the app

2) Require NFC compatible device for use of the app, and revamp the app to use NFC - which would basically require switching partners, or Masabi changing JustRide to support something beyond optical recognition. 

The thing is - QR actually does make sense for many applications -

Rail: scanners needed only by conductors/ticket collectors, so you've got maybe, 200 in a system.

Air: scanners needed at gates and security checkpoints - not that many. In both these scenarios they are operated basically by employee. 

Venue: You get the point. 

NYC Subway: Over 4,800 optical scanners to be operated by any one of like 3 million people, none of whom care about the disposition of the scanner. 

Masabi is trying to shoehorn the solution they have into the system, and yes thankfully they are including other modes such as NFC in their READERS - but - yeah. I don't see an alternative where they keep the LIRR eTix platform, and allow monthly metrocard purchase in the app, but don't have to support QR

 

EDIT: It's also worth noting that Masabi's SLA is for 3 9's - or 99.9% uptime. Which sounds great... 

Except that means there can be 8 hours a year when you just can't get through a turnstile - and somehow I doubt they'll just open the gates if the system goes down. 

Edited October 3, 2017 by itmaybeokay
Adding SLA detail.

[Calvin]

9133-9137, 9158-9162 C.I to Jamaica

Edited October 3, 2017 by Calvin

[RailRunRob]

32 minutes ago, itmaybeokay said:

In fairness, I don't think they are going to be using QR for standard farecards, just for fare payment from within the MTA eTix app. That reader seems to also contain NFC  - at least, it has an NFC logo on it. 

On the one hand, I agree - QR - or really, any form of optical recognition is both backwards and failure-prone. 

On the other hand, without dramatically upending the nature of - and requirements for - their LIRR mobile ticketing solution - I'm not sure what else you could do. The options are either:

1) Disallow combination monthly LIRR/Metrocard purchases via the app

2) Require NFC compatible device for use of the app, and revamp the app to use NFC - which would basically require switching partners, or Masabi changing JustRide to support something beyond optical recognition. 

The thing is - QR actually does make sense for many applications -

Rail: scanners needed only by conductors/ticket collectors, so you've got maybe, 200 in a system.

Air: scanners needed at gates and security checkpoints - not that many. In both these scenarios they are operated basically by employee. 

Venue: You get the point. 

NYC Subway: Over 4,800 optical scanners to be operated by any one of like 3 million people, none of whom care about the disposition of the scanner. 

Masabi is trying to shoehorn the solution they have into the system, and yes thankfully they are including other modes such as NFC in their READERS - but - yeah. I don't see an alternative where they keep the LIRR eTix platform, and allow monthly metrocard purchase in the app, but don't have to support QR

 

EDIT: It's also worth noting that Masabi's SLA is for 3 9's - or 99.9% uptime. Which sounds great... 

Except that means there can be 8 hours a year when you just can't get through a turnstile - and somehow I doubt they'll just open the gates if the system goes down. 

5

Valid points and perspectives. Note 4-5 years had a conversion with some about this a few months. NFC as been open for afew years on Andorid now with Apple opening there standard with a NFC kit this go around in iOS11and 12 within 4-5 years 75%+ US smartphone NFC penetration you're going to start to see RF/NFC start to take the place of many QR/UPC applications. On milk and food scannable with IoT refrigerators and other devices. At Venues  MLB is already doing trials with Apple Pay. Metro systems have already been integrated for the better part of 10-15 years. Rail and Air may one of the last strongholds especially with printed tickets but digitally there's no reason you couldn't just generate a digital card on phone that would just use your NFC chipset both Android and iOS are opening up their backend. Conductor scanners should have an issue I mean can buy a square reader for $150 with Tap to Pay capabilities again the MTA is always a few years back after using the Ventra and Oyster cards. But commuter rail element didn't think about the tie in with the Subway QR would still work in that application. 

[Calvin]

9468-9472, 9478-9482: Jamaica to C.I

9558-9562: Cuomo wrapped

[Calvin]

Another post: 1921-25 are split from being a 5-car set. 

[Harry]

A decent week on the line so far. Not as bad as last week.

[darkstar8983]

The 9133-9137/9158-9162 and 9468-9472/9482-9478 R160 swap was probably just a one-time swap since the entire B division is still in the midst of a car shortage. So cars in Coney Island Yard can perform stints on the  routes and Jamaica Yard assigned R160s parked in Coney Island Yard can fill in for the  /   at a moments notice.

 

i caught the Jamaica yard set (the 94XX cars) running the Astoria bound  during yesterday's PM rush hour 

[MassTransitHonchkrow]

16 hours ago, Calvin said:

 

9558-9562: Cuomo wrapped

You mean Excelsior'd?

[S78 via Hylan]

I must say, I actually like riding the  when it’s local in Manhattan. It moves pretty fast.

[Bosco]

On 10/3/2017 at 10:36 PM, Calvin said:

Another post: 1921-25 are split from being a 5-car set. 

What's the point of splitting the single cars up?  Wasn't the goal to link as many as possible so they could be used elsewhere?

[BreeddekalbL]

I saw a photo of the new rollsign to 96/2 was it added or did they replace anyone that was not in use?

[jon2305]

On 10/5/2017 at 11:38 AM, Bosco said:

What's the point of splitting the single cars up?  Wasn't the goal to link as many as possible so they could be used elsewhere?

When are the rest of the R62A's suppose to leave the (7)?

[Bosco]

On 10/6/2017 at 2:56 PM, jon2305 said:

When are the rest of the R62A's suppose to leave the (7)?

Whenever CBTC goes online, which has been delayed a little (and they're SMSing some of the R188s in the meantime).  It was supposed to be a month ago, but of course here we are.

[R42N]

On September 21, 2017 at 4:40 PM, darkstar8983 said:

 

 

I can see that everyone on this forum just wants to rip me to shreds on everything ????

 

1. First of all, the Astoria line has suffered from poor service when compared to the rest of the subway system because it is serviced by two unreliable routes. Even now in 2017 where every line is crapping out and giving off ~60% on time performance (being optimistic here) hence why service cannot be made even worse by having a mixed fleet. The trains are NOT leaving and arriving on time to give them ample time to send the next R160 train out and swap that trains letter/destination: sometimes you have a situation where you have both Ditmars tracks occupied with R68 trains. What do you do then? The MTA saw this problem when the R160s were first coming onto the and the reliability of that line had hit its lowest point because FIVE different car classes were assigned to this route.

 

2. In general (I also have eyewitnesses in addition to myself) the Astoria GOs were every other week. And just you wait until they update the website to show the rest of the month of October and the being the only Astoria service.

 

3. Those hipsters don't give a damn about anyone and would sooner sell your soul for a sip of beer. I for see them moving to Astoria and turning it into another hellhole like Williamsburg.

 

4. Anyways getting back on topic: if everyone seems to be satisfied with this reduction in service, why don't they just make the run a bit more often to not have people left on the platforms because they don't fit on the train.

I agree with most of your points Darkstar8963. Last week, they said  trains were going to run express from Astoria Blvd to Q-Boro, but the work was cancelled, so the  ’s ran local, but the ’s remained up the upper east side. 

I don’t think the R68’s are the problem, truthfully. Even if it’s a  that must come back as an  they will sometimes just switch the front rollsign and that’s it. Heck, 1 of the 3 sets of R68’s they have has a jammed rollsign that shows the upside down  . 

The big issue is the fact that the  is a completely un-reliable route. Even during peak rush, Ditmars will be behind, so to keep up with demands in Brooklyn, they will dispatch 2 to maybe 3  ’s in a row to make sure there isn’t a 20 minute gap in Sea Beach. 

Additionally, when the Astoria work isn’t completed on-time, then you might not see a  in Queens until 4pm. 

On your point about the millennial hipsters, while it’s wrong of me and totally opinionated, I completely agree. I remember when I immigrated from the Balkan mountains in the 1970s, and everyone in Ditmars Steinway spoke Greek. There was a great, safe, feeling that made Astoria my favorite neighborhood. 

To me, that 14th Street/Greenwich/Williamsburg culture makes me sick, and I would move out of Astoria if that culture came here. 

[RR503]

On 10/6/2017 at 2:56 PM, jon2305 said:

When are the rest of the R62A's suppose to leave the (7)?

December, if nothing else goes wrong. 

[Calvin]

Set 3 of the Cuomo wrapped train: 9563-9567 with 9688-9692

[Ntrainfave]

Could R46s ever be displaced on the  and  lines? It would actually make sense and be much easier to switch from one to the other at Ditmars since they are half-digital.