Like others in the comments, we use a pretty straightforward architecture—our backend is written in Elixir and the frontend is rendered as a webpage with HTML/TypeScript/SCSS. We also use AWS Polly for on-demand readouts of the same content. The client periodically requests new data from the server—no web sockets involved for now.
The kiosk part is pretty basic; most of the interesting problems we face are related to the fact that we support a large variety of screen types/formats and need to strictly adhere to ADA guidelines (for both type size and audio equivalence). Screen types include solar-powered e-ink, portrait mode 1080p LCD, twin side-by-side portrait LCDs, and a set of screens owned by an ad vendor, on which our content appears in a rotation alongside ads.
The codebase is open-source! https://github.com/mbta/screens
* (Massachusetts Bay Transportation Authority)
Using Radio Shack Model ][ (with 8” floppy drive). and BASIC/Z80-assembly, a snazzy interactive presentator for those different kinds of folks (tech, CxO, finance, sales).
alongside the hands-on demonstrator and specification of the first credit card payment pad on the gasoline pump.
Instant sell out. Rich, too ($10,000/month back then or about $30,707/mon. today’s value.). Once bought out, royalty dried up. Fun while it lasted.
so, BASIC did my kiosk/infotainment and the key was making it robust enough as well as deep menu scoping with quick timed-out home menu for a large breadth of an audience. Took about 5 people busy writig content while I was programming onto a floppy.
Some companies were taking contracts for big name companies, while some produced their own dashboards/hardware. The tasks start becoming repetitive after a while though.
Tech stack in almost all those places has been:
* Embedded Linux (Buildroot/Yocto) / rarely QNX.
* C++11 + Qt/QML/QtQuick for UI ( case study: https://www.slideshare.net/BurkhardStubert/qt-dd2014-casestu... ). We did prototype an application using Qt Webkit, but the performance was meh and we moved back to QML. This was in 2013 iirc. Things might have gotten better these days. It has almost always been 1 main UI application - so we didn't even need a window manager. We booted straight to the main application in 2-3 seconds and then used Qt's eglfs to render to full screen directly.
* Developers were free to implement other services (Notifications demon, Recovery/OTA system, logging etc...) needed by the main application in tech of their choice. We mostly ended up using C++ because that's what most of us were experienced in, and also meant less bloat/messy integration. Sometimes shell scripts.
Hardware has always been some NXP iMX6 variant.
None of those devices had any internet connectivity and Software updates meant using a usb stick etc... So never got to try out something like balena for OTA updates.
I can also tell you it's really not rocket science. We built UIs the same way we build anything else. A lot were just web pages with a machine locked in Chrome kiosk mode. Some were Electron or Unity if we needed razzle dazzle. You can get all kinds of off-the-shelf devices control lighting or read input from all kinds of sensors that just go in a USB port. You can rig stuff with microcontrollers but for a commerical project, you can buy bulk devices purpose-built for whatever task.
Currently work at a self-driving car company working on interfaces for passengers to interact with a driverless vehicle
In the past I worked at an agency that specialized in kiosks for clients who didn't necessarily have the skillset or experience to deploy hardware to stores (Google Nest was one of our customers, and iirc they had some internal grumbling about owning Android but paying us to deploy Android-based kiosks)
One place I worked at had a very meteoric rise and fall. Their business model was selling a premium spin bike with an Android tablet attached (you can guess which company this is)
The common thread is "Android for HMI", and it's the niche I've based my career on.
They were shockingly similar to the kiosks that got deployed at the same location ~3 years ago.
Web app using Elm on the client side with a simple iOS webview wrapper and provisioning via remote MDM + apple’s enterprise store.
The sole purpose of the wrapper is to lock it down, and launch on start. I’d just use a kiosk app instead though if I had to do it again and try to avoid the whole MDM and Apple enterprise stuff… major pita.
Elm for the client side has been absolutely bulletproof and maintenance free. Adding random feature requests has been enjoyable. Highly recommend.
Front-end stack: Android and iOS: CN1, HTML5, java, obj-c Web: HTML5, js, wasm
Backend: nodejs, datastore (no-sql db), GCP buckets
6groups.com
This is all public information that was previously shared, so it may be out of date: the devices are Linux (Ubuntu) [1], running an advertising player (Broadsign) [2], which has Chromium Embedded (CEF) for web content [3]. The kiosk app was written in React [4]. It does things like load most data ahead of time to provide that "instant" feeling [5].
[1] https://ubuntu.com/blog/digital-signage-the-face-of-the-smar...
[2] https://broadsign.com/blog/intersection-selects-broadsign-na...
[3] https://docs.broadsign.com/broadsign-ayuda/configuring-splas...
[4] https://mattj.io/posts/2019-02-12-building-smart-city-kiosks...
[5] https://mattj.io/posts/2019-07-09-improving-perceived-interf...
The terminal had a receptical for paper money, which was a crazy expensive thing back then, a massive touch screen (late 90s mind you!) and was hooked up to the internet through an X.29 modem. The pumps were controlled via a serial cable using a protocol that was documented just with a phone number of a guy who knew the details. Duck-taped the whole thing together, showed it off to the guy, he paid the balance in cash and then it was passed to the deployment guys, where it remained for a couple of years, because the client was assasinated (but lived) and had a subsequent change in life priorities.
Fun times. The stack was Windows NT.
I built out a Lua based server that lived on each of our units and communicated back to home base for updates using svnlib to grab changes. It was a pretty neat system, lots of hardware integrations and so on. Super fun. Lua was nice because its FFI is so pleasant to use. Flash was absolutely amazing for handling the UI. Our kiosks looked _so_ much better than all of the other hideous Motif-style UIs out there. Hell they looked better than most kiosks still look these days.
If you lived in Australia in the 00s and ever stepped foot in a Westfield or Stockland mall you'd have seen some of our kiosks.
The hardware stack involved PPC-based servers connected to what was essentially switches that serve groupings of 4-6 seats that distribute power and connectivity to what was essentially embedded low power x86 PCs with touchscreens attached (for the prior generation of hardware) or modified android tablets (for the current generation of hardware) all connected via Ethernet.
As for the software stack, everything ran a modified version of fedora Linux and sshd. For the seat-back units, they either ran an X11 server on the prior generation units or the android runtime for the current generation of units. Atop that the QML runtime ran 80% of interfaces on both generations that users interacted with. The other 20% were games and other 3rd party android apps we distributed typically not written in QML. There were also a few parts of the interface (diagnostic screens, etc) written using android widgets or IIRC qt (or perhaps even Xt?) and then maybe one or two legacy systems we supported which were written in the pre-QML era using android widgets , or Qt.
Often airlines would request content updates, which would include new movie releases (many of which were still in theaters. IIRC this was a selling point of buying a traditional IFE system over iPads since our company had a close relationship with several studios, acquiring the rights for films much quicker than other distribution channels). Content updates also included new or patched games and often updates to the UI with new commercial advertisements, new theming for a holiday or new language translation options. Most of this data needed to be loaded to the flash memory of each seat back unit (gui, games, commercials and a few movies) with the rest needing to be loaded to the head end units which there could be 2-8 all over 10/100 or 10-BASE-T Ethernet networks. This was cleverly done via libtorrent, installed on every unit. I was always blown away by the speed of these BitTorrent-powered content upgrades even on aging early- and late- 2000s embedded hardware and Cat3 Ethernet.
Any tips are welcome and appreciated. If not, I'll do heavier research when I am ready to hack this idea into life.
An example, Fast food kiosks. What systems knowledge can I gain about all about McDonalds can I gain to them partner with my tech stack to deliver a McDonalds kiosk that amps up the McDonalds Experience.
Here's the slides from a presentation I did if they're helpful: https://www.slideshare.net/ClaudiuLodromanean/start-developi...
We didn't stick with making games for kiosks. Managing both the software and the hardware was too much overhead, and at the time I didn't think it was a tenable line of business compared to other opportunities.
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...
I have a few prototype kiosks that I use a android TV inside (cheap Chinese 1080p ones, The first version where just Rapsberries PIs inside but the dollar is expensive as hell in my country now, and I had to import them, so now they cost 5X more).
My original front / Back where in PHP brecasse I had to code it in 1 month and php is cheap as hell to host. Now I'm changing for a control panel in React / backend in C#.
And the application is a native android application that I will probably port to React Native. Just because I'm learning react native.
The displays I've worked on generally run on standard touch-enabled TVs on something like an Intel NUC running Windows.
Unused pi presents for a project a whole ago, it has very robust functionality including toggling io pins, etc. I've found it hard to justify using anything else, it's super simple and very versatile.
>Easy-to-use Raspberry Pi image for booting directly into full-screen Chrome, with built-in convenience features for unattended operation. Perfect for dashboards and build monitors.
Our kiosks are running Android.
Are you looking at building a kiosk? What is your use case?
My main stack was Adobe Air. Sometimes I used Cinder, a C++ framework when I needed more performance. The last projects were done using NWJS which was like Electron using whatever JS stuff was needed like Rivets, Pixi, even jQuery.
In between the reliability of consumer kiosks and a HMI, there are proprietary systems like Labview and GE Fanuc, which have the ability to create drag-and-drop GUIs for custom applications. I've built or modified a few of these for specialized factory lines, water/wastewater plants, or experiments under contract.
I've also built kiosks using Windows Embedded and Chrome on Raspberry Pi, for conventions as a volunteer, and for mass transit systems under government contract. The Miami International Airport monorail and portions of the BART airport extension both use these kiosks.
I want to emphasize that although web technology allows for extremely fast app prototyping, web browsers were by far the largest risk for all of these projects. Industrial control systems are expected to have 100% uptime, forever, period end of story, and in many cases are disconnected from the Internet and never patched. This is a very realistic expectation when the target system does not include a TCP/IP stack or even networking hardware (controls are done via RS-422 or a similarly deterministic bus), the total image size peaks at a few megabytes, there is no BIOS, and the bootloader is a jump instruction to a XIP image in memory mapped NOR flash.
On the other hand, in situations where a service contract is being pushed on the customer for business reasons, the Chrome+Raspberry Pi option is great because it breaks all the time. SD cards, even high endurance ones (I'm looking at a dead 32G Samsung HE card from a Helium miner right now) break for no reason, Chrome or Raspbian's WM throw up dialogs for irrelevant issues, uboot will sometimes not, and the HDMI transceivers between the Pi and the display will sometimes just refuse to talk. Don't even get me started on the USB touchscreen bits.
Despite what you might think, you don't need a web browser for infotainment or movie playing. All the major embedded frameworks include video, and if you really want to use web technologies there's node bindings for Qt and that kind of thing. Kiosks are fixed DPI, fixed resolution, fixed font systems, and there's no need to involve HTML, CSS, or any other dynamic layout technology.
When we were doing production work, the stack was QNX/QT. I specifically did work on a web layer
Arm/cpp/linux
The basic idea is that we have ~2000 kiosks deployed across all 5 boroughs. Each screen has 2 displays so that's ~4000 displays playing various ads. Kiosks also provide free Wi-Fi for the public, free phone service since they replaced the payphones, and there is an Android tablet that can be used for various online services such as applying for food stamps.
We have some kind of partnership setup with the city, and we also get money from ad plays. The business structure is a lot more complicated than that but I don't want to go into details because it's highly likely I'll say something wrong.
Like most things, it's a mixed bag. Working with hardware that's deployed in public changes the game in interesting ways. Things can break for so many different reasons since they interact with the physical world all the time.
There was a funny moment when we noticed one of the kiosks being down. It wasn't responding, we couldn't reach it over the network at all so we decided to take a look at it in the street and....it wasn't there. A 7-8 ft kiosk just disappeared off the street. We later found out that a truck smashed into it in the early morning and it was all cleaned up by the time we realized something was wrong.
Hot weather, cold weather, car traffic, people smashing kiosks with a baseball bat because they think wifi spreads covid, there are a lot of things that can break physical devices on the street and it's been fairly interesting dealing with it.
Bad stuff: Ad tech. I hate the whole advertising industry with a passion of a thousand suns. I have moral issues with it and every ad tech thing I touched is horrible from a technological standpoint.
Good stuff: It's interesting. I work on a ton of different stuff. I could be doing a lot of operations work for a while, then go develop a new service next week, then design a bunch of analytics so we can get more insight the following week. Engineering team is not huge and we all have to do everything. We are all remote and the company made sure to ship us all the hardware we need, which is nice.
Nice stuff: Free wifi covering most of the city is a useful thing for people. I'm happy we provide it and it's what makes me feel good about this. Kiosk tablets are also used by the poor and homeless to apply for various programs such as food stamps.
Tech: Nothing very surprising. Various single board computers, Linux, Python, Go, js, SQL, Ansible.