Technology that changed air travel(retool.com)
retool.com
Technology that changed air travel
https://retool.com/blog/air-travel-software/
65 comments
Just the level of airplane nerdery one needs right now.
Also probably the best explanation of EDIFACT artifacts I've seen.
I just have one remark - how on earth does a 737 fly from SFO to LHR without stopping as in the example?
I just have one remark - how on earth does a 737 fly from SFO to LHR without stopping as in the example?
Ha, great question. We didn't have access a SABRE system so the lookups are fake. I was just about to go in and change it in to a 388 (my favorite plane!), which I think flies daily between LHR and SFO as BA286.
~Unfortunately, the output is in png format which was generated by carbon.now.sh, so I'll have to type everything out. I'll change it once I have a few minutes...~
Edit: just changed it into BA286, which is an 388. (For fun, I also added in first class fare buckets, which United no longer offers.) For additional accuracy, I also updated the UA equipment to 772s, which IIRC is what they actually fly (as opposed to 77Ws).
(If we did this more often, we'd probably actually design it in HTML instead of using Carbon, but an image was much faster, haha.)
~Unfortunately, the output is in png format which was generated by carbon.now.sh, so I'll have to type everything out. I'll change it once I have a few minutes...~
Edit: just changed it into BA286, which is an 388. (For fun, I also added in first class fare buckets, which United no longer offers.) For additional accuracy, I also updated the UA equipment to 772s, which IIRC is what they actually fly (as opposed to 77Ws).
(If we did this more often, we'd probably actually design it in HTML instead of using Carbon, but an image was much faster, haha.)
It doesn't. Or it has a technical stop.
The MAX has a range of 3850 nm, LHR-SFO is 4664 nm
So unless it's an empty ferry flight and you've got very favorable winds, you're not doing that without stopping.
Hawaiian needed extra tanks to ferry their 717 (or was it MD something) over there (there's a picture around IIRC)
The MAX has a range of 3850 nm, LHR-SFO is 4664 nm
So unless it's an empty ferry flight and you've got very favorable winds, you're not doing that without stopping.
Hawaiian needed extra tanks to ferry their 717 (or was it MD something) over there (there's a picture around IIRC)
See https://www.avgeekery.com/boeing-717-fly-way-mainland/
and https://joepriesaviation.net/photoalbum/displayimage.php?alb...
Seems obvious once you've seen it...
and https://joepriesaviation.net/photoalbum/displayimage.php?alb...
Seems obvious once you've seen it...
That was around the time of the merger with McDonnell-Douglas. The 717 was actually the MD-95, so, you're basically correct either way. :)
If you are going to write more about the pricing of airline tickets I would include a graph of the actual demand and supply curves, plot the corresponding business segments in it. Many people did not study economics and graphs like these are a great visualization of the problem at hand.
http://4.bp.blogspot.com/-PDoN9F9YpJo/VjDZxPztmkI/AAAAAAAABn...
http://4.bp.blogspot.com/-PDoN9F9YpJo/VjDZxPztmkI/AAAAAAAABn...
The article mentions that there is little evidence for prices changing based on cookies.
I've seen that happen, reproducibly and in a plausible way: The (third party) site was adding an "agency discount" (name may not be precise, this is from memory, IIRC it was ~$10-30) that turned into a significant (IIRC $50+) "agency surcharge" on your second visit. Clear cookies, discount is back, revisit, surcharge is back, 100% reproducible.
I've seen that happen, reproducibly and in a plausible way: The (third party) site was adding an "agency discount" (name may not be precise, this is from memory, IIRC it was ~$10-30) that turned into a significant (IIRC $50+) "agency surcharge" on your second visit. Clear cookies, discount is back, revisit, surcharge is back, 100% reproducible.
Along these lines, I've noticed airlines seem to jack up a ticket price in the subsequent days if you search for a ticket, visit their website, and don't buy the ticket. Though maybe if you wait a couple weeks they might get disappointed and lower it again. Anybody had a similar experience? (From what I can tell, it doesn't tend to happen if you don't actually visit their website.)
I always buy using the airline’s website and no middleman website, and sometimes it goes up, sometimes it goes down. I use google flight tracker sometimes to track the price, and I can’t find anything to indicate it is targeting me specifically.
I presume the price goes up and down based on aggregate searches or reservations for the flight, i.e. supply and demand. I know for hotels, there are programs crawling and searching for competing hotel’s prices and changing pricing based on that as well as changes in inventory and prior year’s data.
I presume the price goes up and down based on aggregate searches or reservations for the flight, i.e. supply and demand. I know for hotels, there are programs crawling and searching for competing hotel’s prices and changing pricing based on that as well as changes in inventory and prior year’s data.
I've seen this happen fairly consistently on very low-demand off-peak flights. I don't think it's a supply/demand thing. The coincidence of the timing a day or two after I search and the consistency of the experience is what makes me think they do it deliberately. The normal price variations I do see too (including with Google flight tracker), but they don't seem to correlate nearly as strongly with my searches. Hard to prove it though...
If your search causes the price to go to for anyone who searches, them I would still say it isn’t targeting a specific buyer, but just that it’s triggered by a lower level of demand.
I can imagine that a route with 500 available seats won’t be programmed to be sensitive to one search, but a route with 10 seats could be.
I can imagine that a route with 500 available seats won’t be programmed to be sensitive to one search, but a route with 10 seats could be.
[deleted]
I was wondering about the time zones mentioned in the article?
If SFO/T-7 is 7 hours behind Greenwich Mean Time and LHR is in the (same) GMT time zone, how is that 8 hours ahead of the origin airport?
If SFO/T-7 is 7 hours behind Greenwich Mean Time and LHR is in the (same) GMT time zone, how is that 8 hours ahead of the origin airport?
It's really poorly phrased in the article but I assume what they meant is that LHR is in a time zone that sometimes observes GMT, and otherwise observes BST (British Summer Time) in the summer which is 8 hours ahead.
It's not exactly correct that SFO is 7 hours behind GMT because this isn't true for around half the year. It also isn't exactly true that LHR is in GMT.
Most of the year, SFO is actually 8 hours behind LHR. A few weeks are off due to different DST dates.
It's not exactly correct that SFO is 7 hours behind GMT because this isn't true for around half the year. It also isn't exactly true that LHR is in GMT.
Most of the year, SFO is actually 8 hours behind LHR. A few weeks are off due to different DST dates.
The author/editor has mentioned elsewhere in this thread that he was using dummy data (which contains mistakes). For this dummy December flight LHR would be in GMT (UTC+0) and not BST (UTC+1).
GMT doesn't observe summertime, but LHR does. So LHR (and the rest of Britain) is only in the GMT time zone for half the year.
GMT is very nearly the same thing as UTC. Think of it as a reference rather than timezone, but one that happens to be used by a few places half the time.
It's just easier to think of yourself in UTC/GMT all the time (known as Zulu time or /Z in the aviation world) and deal with the relative offsets later. Don't forget that US Daylight Saving has different start/end dates to the UK while you're at it too...
It's just easier to think of yourself in UTC/GMT all the time (known as Zulu time or /Z in the aviation world) and deal with the relative offsets later. Don't forget that US Daylight Saving has different start/end dates to the UK while you're at it too...
Hi I was wondering - a meta question of sorts - how this topic (which was really interesting) was chosen for the retool blog since it doesn’t seem to be connected in any way.
Speaking of XML, don't be shy and advertise your RSS feed!
Great story and pictures, thanks for the information.
Great story and pictures, thanks for the information.
Thats was a good read, I wonder where did you get all the information. content and stories from?
This is an awesome post - nice work! It does a fantastic job of laying out clearly the incredible complexity that underpins travel (which totally shocked me when I started in the industry).
I'm Tim, and I lead airline partnerships at [Duffel][1] (YC S18) - although I'm an engineer by trade ;) We're building a new API platform to make it easy for anyone to sell flights (think "Stripe for travel").
We make integration simple with our beautiful REST API (no XML or EDIFACT) and allow anyone to sign up in 30 seconds, with no need to become an accredited IATA agent.
We're rebuilding the industry's infrastructure from scratch, with direct connections to 20+ airlines' systems using the new technology mentioned in the article, NDC, rather than going through the traditional GDSs like Sabre and Amadeus.
If you want to give our API a try for yourself, you can sign up on our website and book your first flight in our sandbox in less than 2 minutes.
Equally, if this sounds like an interesting problem space to you - we're hiring, so do reach out. My email is in my bio.
[1]: https://duffel.com
I'm Tim, and I lead airline partnerships at [Duffel][1] (YC S18) - although I'm an engineer by trade ;) We're building a new API platform to make it easy for anyone to sell flights (think "Stripe for travel").
We make integration simple with our beautiful REST API (no XML or EDIFACT) and allow anyone to sign up in 30 seconds, with no need to become an accredited IATA agent.
We're rebuilding the industry's infrastructure from scratch, with direct connections to 20+ airlines' systems using the new technology mentioned in the article, NDC, rather than going through the traditional GDSs like Sabre and Amadeus.
If you want to give our API a try for yourself, you can sign up on our website and book your first flight in our sandbox in less than 2 minutes.
Equally, if this sounds like an interesting problem space to you - we're hiring, so do reach out. My email is in my bio.
[1]: https://duffel.com
I was going to ask if such a thing existed and you beat me to it. I will definitely check it out!
That looks amazing. Just curious, what is your target customer base?
In the short term, our goal is to build the best flight API for new travel businesses by making it way easier to get started and build a great customer experience.
We're also in a good position today to help existing travel sellers who want to access exclusive NDC content (mentioned in the article) that they can't get through a traditional GDS.
From there, the sky's the limit really. We'll be in a great position to help anyone who wants to sell flights - new entrant or existing seller.
We're also in a good position today to help existing travel sellers who want to access exclusive NDC content (mentioned in the article) that they can't get through a traditional GDS.
From there, the sky's the limit really. We'll be in a great position to help anyone who wants to sell flights - new entrant or existing seller.
Video here of a training session on GDS:
https://www.youtube.com/watch?v=1PHJkm_nNL8
Typing commands starts at 2:05 in. Watching this left me feeling like I was being taught how to use the "rm" UNIX command while logged in as root on a production machine that wasn't backed up and this was my final chance to keep my job.
https://www.youtube.com/watch?v=1PHJkm_nNL8
Typing commands starts at 2:05 in. Watching this left me feeling like I was being taught how to use the "rm" UNIX command while logged in as root on a production machine that wasn't backed up and this was my final chance to keep my job.
I went through training for Amadeus system in 2010, to get a better idea of the problem domain I'm going to automate for our startup. "oh", I've thought, "it's a terminal, and a text interface, I'll be fine". After two weeks of training we had an exam. With manuals on hand and a 3 hours time limit. My fellow students were pretty fast, and I spent 2 hours issuing a single ticket.
The security of these systems is also lacking, not to mention privacy.
see this talk "Where in the World Is Carmen Sandiego?" from 33C3 conference (2016). https://media.ccc.de/v/33c3-7964-where_in_the_world_is_carme...
see this talk "Where in the World Is Carmen Sandiego?" from 33C3 conference (2016). https://media.ccc.de/v/33c3-7964-where_in_the_world_is_carme...
Of all the ways to book an airline ticket... this has got to be near the worst. Imagine if car mechanics or hair stylists had to learn an extremely esoteric quasi scripting language to do their job. If you swap in travel agent, that’s basically this.
[deleted]
Well, just to discuss a separate point for a moment:
Although the story describes in a technical way that the EDIFACT, XML, etc standards are cumbersome, inert, and resistant to change, I think the real story is somewhat external to the "code" level reasons. And it will also be a lesson (for the proponents of some change to any kind of standard) about why just a technically better solution doesn't always win.
Because, if you look at almost any standard, there's generally nothing stopping someone from proposing an alternative or better version. It's the adoption that's the tough part.
The more fundamental root cause of why this particular "bad" or outdated standard persists so long is that airlines are a very risk averse and capital intensive business. Any change -- especially one so fundamental as could interfere with their minute-by-minute booking engine (companies can lose billions if that system goes down) -- is highly risky. And it wasn't really built with incremental changeability or "hot swappability" in mind. Changing it involves retraining thousands of people, changing computer terminals, keyboards (with special character keys coded in plastic), practices, interfaces to yet other vendors. And when your company is burning dozens of millions of $ per day, that's something that you don't risk unless it's a strategic decision.
So that dynamic flows down into what your software vendors are incentivized (or become attuned) to produce or charge you for. Until there's some ground-level shift -- for example suddenly everyone needs to charge baggage fees -- no airline was actively asking for that capability to add on ancillary fees. And no GDS provider was seeking to innovate on it. Airlines simply wouldn't pay the extra for that unnecessary functionality... until they did.
Old, expensive, risky industry -- and that's why sometimes the change has to come from new entrants who aren't tied to these legacy systems. Although, and this is an even more involved topic, sometimes those new entrants find they have to tie into the legacy system to survive and get customers.
Although the story describes in a technical way that the EDIFACT, XML, etc standards are cumbersome, inert, and resistant to change, I think the real story is somewhat external to the "code" level reasons. And it will also be a lesson (for the proponents of some change to any kind of standard) about why just a technically better solution doesn't always win.
Because, if you look at almost any standard, there's generally nothing stopping someone from proposing an alternative or better version. It's the adoption that's the tough part.
The more fundamental root cause of why this particular "bad" or outdated standard persists so long is that airlines are a very risk averse and capital intensive business. Any change -- especially one so fundamental as could interfere with their minute-by-minute booking engine (companies can lose billions if that system goes down) -- is highly risky. And it wasn't really built with incremental changeability or "hot swappability" in mind. Changing it involves retraining thousands of people, changing computer terminals, keyboards (with special character keys coded in plastic), practices, interfaces to yet other vendors. And when your company is burning dozens of millions of $ per day, that's something that you don't risk unless it's a strategic decision.
So that dynamic flows down into what your software vendors are incentivized (or become attuned) to produce or charge you for. Until there's some ground-level shift -- for example suddenly everyone needs to charge baggage fees -- no airline was actively asking for that capability to add on ancillary fees. And no GDS provider was seeking to innovate on it. Airlines simply wouldn't pay the extra for that unnecessary functionality... until they did.
Old, expensive, risky industry -- and that's why sometimes the change has to come from new entrants who aren't tied to these legacy systems. Although, and this is an even more involved topic, sometimes those new entrants find they have to tie into the legacy system to survive and get customers.
Travel distribution is a problem which becomes computationally complex surprisingly quickly and easily (in addition to doing transactions with limited inventory and highly variable pricing in real time at scale with no errors, you keep running into NP-hard problems. This essay from ITA software founder is a good primer: http://www.ai.mit.edu/courses/6.034f/psets/ps1/airtravel.pdf
And at the time ITA found getting airlines to adopt their tech even more challenging (though a big exit to Google validated their tech stack). The complexity and legacy code behind existing integrations is also part of the GDS suppliers moat when it comes to renewing contracts and whilst airlines want the ability to upsell 'packages' with hotels/transport etc (one of the rationales for NDC, because now baggage fees and travel partnerships are really important to airlines), the GDS companies' travel agent partners whose bookings represent a sizeable part of client airlines' revenue base (and therefore their other moat) want to sell their own hotel/transport bundles.
And at the time ITA found getting airlines to adopt their tech even more challenging (though a big exit to Google validated their tech stack). The complexity and legacy code behind existing integrations is also part of the GDS suppliers moat when it comes to renewing contracts and whilst airlines want the ability to upsell 'packages' with hotels/transport etc (one of the rationales for NDC, because now baggage fees and travel partnerships are really important to airlines), the GDS companies' travel agent partners whose bookings represent a sizeable part of client airlines' revenue base (and therefore their other moat) want to sell their own hotel/transport bundles.
One huge issue with GDS/EDIFACT is that it has no security built in. It was designed in a time when every actor was considered trustworthy.
Banks also relied (rely) for years on "antiquated" systems but they took the "they just work" and built some security around them. Airlines did not. This [0] presentation from 33C3 was really interesting (more readable form [1]).
[0] https://media.ccc.de/v/33c3-7964-where_in_the_world_is_carme...
[1] https://ourdataourselves.tacticaltech.org/posts/50-booking-f...
Banks also relied (rely) for years on "antiquated" systems but they took the "they just work" and built some security around them. Airlines did not. This [0] presentation from 33C3 was really interesting (more readable form [1]).
[0] https://media.ccc.de/v/33c3-7964-where_in_the_world_is_carme...
[1] https://ourdataourselves.tacticaltech.org/posts/50-booking-f...
> To book a seat, the operator would have to find the flight’s index card, mark it to indicate the booked seat, and write the flight ticket out by hand. The process would take 90 minutes for each reservation.
While it sounds horribly inefficient, I can't understand what sort of archaic process can make reserving a ticket a 1.5 hours task. Any ideas?
While it sounds horribly inefficient, I can't understand what sort of archaic process can make reserving a ticket a 1.5 hours task. Any ideas?
I don't really understand either. Sounds like it should take no more than 10 minutes for a somewhat experienced operator.
Find the flight's index card: 1 minute Indicate the booked seat: 0.5 minutes Return the flight's index card: 1 minute Write flight ticket out by hand: 2.5 minutes
That seems a very conservative estimate to me. What happens during the other 85 minutes?
Find the flight's index card: 1 minute Indicate the booked seat: 0.5 minutes Return the flight's index card: 1 minute Write flight ticket out by hand: 2.5 minutes
That seems a very conservative estimate to me. What happens during the other 85 minutes?
I think it is more to it than that. The index card only tells them that a seat is available. They also need to read other documents to find out which fares are available and match that to the seat. There are probably specific conditions for that fare that need to be applied and may require calling the agent or or someone else to confirm. If the seat is too expensive or the fare is unavailable, they need to reset the index card, pick a new one and repeat the process.
I imagine arranging payments was also part of the 90-min average.
I have to assume that's a typo, and the author meant 90 seconds.
Either that, or there's a big queue in the middle of the day where an operator would take down the reservation request, put it in an already-tall stack, and only call the travel agent back 90 minutes later on average.
But since a queue would be highly variable, 90 seconds seems much more likely.
Either that, or there's a big queue in the middle of the day where an operator would take down the reservation request, put it in an already-tall stack, and only call the travel agent back 90 minutes later on average.
But since a queue would be highly variable, 90 seconds seems much more likely.
They mention a table has 8 operators only. I'm guessing the 90 minutes includes the client waiting time on the phone.
The post has annoying little errors that make it harder to read. The figure says BA286, and the text says "BA287 means British Airways flight 287". So does that mean you always add 1 to the flight number shown on the screen, to get the actual flight number? "388 equipment type: 389 refers to Airbus A380-800". Again, you add 1 to the number shown on the screen? Why does "389" mean "A380-800" and not "A380-900"?
I realize it's possible to figure out that these are just typos and you don't really mean "take the number shown on the screen and add 1 to it to get the actual flight number", but why would you make your readers deal with that kind of confusion?
I'm sorry. I made the change quickly at around 11pm my time (when I was a bit tired) because somebody in another thread here [1] noticed that a 767 wouldn't make it from SFO to LHR. I made two typos in this edit (typo-ing "286" to "287" and "388" to "399"), and have just corrected both. If there are any more issues you notice, please let me know (I'm david AT retool, or commenting publicly here works), and I'd be happy to fix them when I wake up again (in around 8 hours' time).
(The former error is indeed because I confused the outbound / inbound flights. I've taken BA286 quite a few times, but I forgot which direction was which. When I was initially fixing the article I thought it was "BA286" but then looked it up and found it was "287". I then fixed the error in the screenshot but forgot to fix the error in the text itself. Apologies the edit introduced annoying little errors — this is entirely on me trying to do fix something quickly.)
1. https://news.ycombinator.com/item?id=23231453
(The former error is indeed because I confused the outbound / inbound flights. I've taken BA286 quite a few times, but I forgot which direction was which. When I was initially fixing the article I thought it was "BA286" but then looked it up and found it was "287". I then fixed the error in the screenshot but forgot to fix the error in the text itself. Apologies the edit introduced annoying little errors — this is entirely on me trying to do fix something quickly.)
1. https://news.ycombinator.com/item?id=23231453
I found this perplexing:
>"LHR/GMT¥8: the arrival airport, LHR, which is in the GMT time zone, which is 8 hours ahead of the origin airport"
Why exactly is the Yen sign used at the destination? Why would this not warrant an explanation?
>"LHR/GMT¥8: the arrival airport, LHR, which is in the GMT time zone, which is 8 hours ahead of the origin airport"
Why exactly is the Yen sign used at the destination? Why would this not warrant an explanation?
This doesn't completely explain the flight number labelling issue in the article, but may be related:
By convention, large airlines typically number their flights so that even-and-odd numbered pairs operate between the same two cities.
For example, QF49 flies MEL-SFO and QF50 flies SFO-MEL.
By convention, large airlines typically number their flights so that even-and-odd numbered pairs operate between the same two cities.
For example, QF49 flies MEL-SFO and QF50 flies SFO-MEL.
I hoped this would be about GDS.
My first job was in that sector.
I learned a lot during that time. It was an enormous c++ codebase (as I remember it, millions of lines) and as much as I profoundly disliked some aspects of it, there were also a lot of interesting things. IIRC they had a pretty large platform team maintaining their own compiler and eclipse plugin.
One aspect of pricing (and availability, just because there are free seats on a plane does not mean they are available to you) that is not touched in that article is not multi legged flights are almost all the time deeply favored by the algorithm.
So if you absolutely NEED to go somewhere but the website shows zero availability, try to search for a multi leg trip including your intended destination.
My first job was in that sector.
I learned a lot during that time. It was an enormous c++ codebase (as I remember it, millions of lines) and as much as I profoundly disliked some aspects of it, there were also a lot of interesting things. IIRC they had a pretty large platform team maintaining their own compiler and eclipse plugin.
One aspect of pricing (and availability, just because there are free seats on a plane does not mean they are available to you) that is not touched in that article is not multi legged flights are almost all the time deeply favored by the algorithm.
So if you absolutely NEED to go somewhere but the website shows zero availability, try to search for a multi leg trip including your intended destination.
https://www.kiwi.com is good for finding these multi leg tickets as single tickets.
First job was in the travel industry.
fscking GDS was like staring into the abyss
fscking GDS was like staring into the abyss
One interesting artefact of the old GDS interface is that the commands are position based. The field for the amount of people in a group booking is only length 1, so virtually no airline supports group booking of more than 9 people in their standard online flow.
Another place where this leaks through is if your initials are similar to "Mr", you'll get very strange tickets once in a while because the system doesn't actually have the components of your name in separate fields. It parses them from a text command.
The NDS change should solve all of these things, but it's a costly exercise so expect it to be delayed by the current downturn in the travel sector.
Another place where this leaks through is if your initials are similar to "Mr", you'll get very strange tickets once in a while because the system doesn't actually have the components of your name in separate fields. It parses them from a text command.
The NDS change should solve all of these things, but it's a costly exercise so expect it to be delayed by the current downturn in the travel sector.
The airline industry is a rich source of interesting IT projects: I once worked on a scheduling system for BA, which boiled down to a big ol' constraints-based optimisation problem, viz: lots of aircraft constantly moving about < * > mandated max hours they can fly before maintenance < * > restricted set of locations where said maintenance can be performed. I remember that the brief dalliance with individually decorated tailfins - which doubtless seemed like a great idea in a marketing meeting - caused carnage for the maintenance folks because the fins suddenly stopped being interchangeable.
> But the future is looking bright — air travel is growing at twice the rate of GDP. Low-cost airlines are making it ever more accessible, and the industry is already seeing an impressive amount of innovation. With NDS, things are sure to get even better. “This is your captain speaking. Please fasten your seatbelts for take-off.”
Timely :/
Side note, I can get faint hints of how this topic relates to Retool (eg, the GDS CLI is not a good internal tool), but it's pretty rare in my experience for a corporate blog to not try to shoehorn its own solution into the picture, and there's literally no mention of Retool in here. Kinda novel to just have a vaguely related exploration on a company blog.
Timely :/
Side note, I can get faint hints of how this topic relates to Retool (eg, the GDS CLI is not a good internal tool), but it's pretty rare in my experience for a corporate blog to not try to shoehorn its own solution into the picture, and there's literally no mention of Retool in here. Kinda novel to just have a vaguely related exploration on a company blog.
Booking air travel today isn’t the most pleasant experience
Unfortunately, the booking part is almost the most pleasant aspect of it all.
Unfortunately, the booking part is almost the most pleasant aspect of it all.
For anyone old enough to remember the old way with visiting travel agents to book a flight and then getting paper tickets in the mail the booking experience is actually quite good at the moment.
The actual travel experience itself though has totally gone in the other direction!
The actual travel experience itself though has totally gone in the other direction!
I’m pretty happy with buying flights these days. Go to an airline’s website, make a frequent flyer account and fill in the details, and then search for and buy the flight.
https://retool.com/blog/content/images/2020/01/s_07FFC171A6B...
Almost looks like Uber and Lyft!
While Uber and Lyft might not be as crazy-profitable as people had hoped, establishing a marketplace by connecting a large number of suppliers with a large number of buyers is a valid business. The other big commonality is that both air travel and taxis are low-margin.
Almost looks like Uber and Lyft!
While Uber and Lyft might not be as crazy-profitable as people had hoped, establishing a marketplace by connecting a large number of suppliers with a large number of buyers is a valid business. The other big commonality is that both air travel and taxis are low-margin.
This needs an "(2018)" at the end.
Fascinating article, but the wild optimism about air travel at the end was almost creepy. Then I looked at the publish date, 18 November 2018.
Fascinating article, but the wild optimism about air travel at the end was almost creepy. Then I looked at the publish date, 18 November 2018.
I watched an agent being educated in these systems. It seems impossible to make the heads or tails out of it at first, since al commands are terse and cryptic, but then the productivity gains are unparalleled in any other software.
When you see a person entering something like "flight from Istanbul to Moscow with a mandatory 24-hour layover in Frankfurt for a family of three" in under 5 seconds, your worldview is shattered :)
When you see a person entering something like "flight from Istanbul to Moscow with a mandatory 24-hour layover in Frankfurt for a family of three" in under 5 seconds, your worldview is shattered :)
Relevant StackExchange q&a about agents mistyping data into Amadeus terminal emulator command line:
https://travel.stackexchange.com/questions/149323/my-name-ca...
https://travel.stackexchange.com/questions/149323/my-name-ca...
A couple of other resistant-to-change legacy data interchange formats:
HL7 for health information. https://www.hl7.org/
MARC for bibliographic information. https://www.loc.gov/marc/ https://www.loc.gov/marc/
XML has been the vehicle for attempted rework of these formats. I wonder, though, whether the time might be ripe for less cumbersome reworks, maybe using JSON with validated schemata?
HL7 for health information. https://www.hl7.org/
MARC for bibliographic information. https://www.loc.gov/marc/ https://www.loc.gov/marc/
XML has been the vehicle for attempted rework of these formats. I wonder, though, whether the time might be ripe for less cumbersome reworks, maybe using JSON with validated schemata?
Systems we love talk
Life of an Airline Flight: What Systems Get You From Here to There via the Air by Adam Fletcher
https://www.youtube.com/watch?v=8_t41xvPp1w
"But the future is looking terrible — air travel is growing at twice the rate of GDP."
I appreciate how hard it is to get buy-in from all parties involved, and NDC was initially launched in 2012, but is XML still a good fit for this solution? Are there better alternatives now?
oh, so many memories. 4 years debugging barely documented xml output of Amadeus SOAP services (SOAP in name only), (re)inventing rules engines for tax calculations, fearing to receive a bunch of Debit Memos to come 2 months after deploying another poorly understood rule.
Metasearches more or less killed OTA's since. Nobody cares about user experience anymore, if tickets are 1 dollar cheaper on some other OTA, traffic will go there.
Metasearches more or less killed OTA's since. Nobody cares about user experience anymore, if tickets are 1 dollar cheaper on some other OTA, traffic will go there.
I look forward to the air fare article. I worked at 1G for a few years and am interested in seeing your take.
[computer] technology, so not like the turbine engine or carbon fiber that led to real advancements.
Are autopilots, ILS, etc not “real advancements”? How about the airbus fly by wire system? How about the computer systems that control the turbines on modern aircraft?
I's kinda with starpilot on this one. The article was about booking systems, not aircraft systems.
Also, ILS itself is fairly primitive, as is anything prior to GPS. It was all more radio technology than computer technology.
Also, ILS itself is fairly primitive, as is anything prior to GPS. It was all more radio technology than computer technology.
In the future, we're hoping to write a piece about how air fare pricing works too. There's a lot of interesting stuff re. fare buckets, forecasting supply + demand, etc. It's also very topical with COVID: https://www.flyertalk.com/forum/united-airlines-mileageplus/...
(If HN has any ideas about what else we should write about, let me know! I'm david AT retool.com)