I did for a while. Mostly fun one-offs for popups and events rather than practical applications. Once I got a taste for it I tried seeking a career in it but there's just very few places doing it and I wasn't able to get my foot in the door. The market exists but it's small.
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.
I've been doing one-offs as a freelancer for 10-15 years, though it has never been my sole focus/career. I think once you start landing some gigs and build a network, similar work will find its way to you. As much as it's a small niche with not very much demand, there isn't much supply or competition. The thing that helps with word of mouth with physical installation work is you can end up with something visually striking to show colleagues or prospective clients.
I have my own product in this area which is basically a web app. Then I ask customers to open it with the most popular Android kiosk app and it works like a charm.
It's how I got my "real" start in the tech industry
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.
I did it for years. Mostly interactive content for museums and marketing events. Last one was in 2014 I think.
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.
I built a wheelstand kiosk that’s still in use. Really just brochure-ware (wheelstand is the stand next to a car or equipment at a trade show or dealership).
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.
I am also a big Elm fan, especially due to the maintainability as you mentioned. But I have never worked with it in a production environment. Just in case you were working with a team on this project, how easy was it to convince the rest of the team to hop on the Elm train? Have you encountered any shortcomings while using Elm in production?
I did for a little while. I thought it was going to be a lucrative untapped market, but really it's just not very in demand. Basically +1 to everything tootie said.
Worked on a kiosk for the Pacific Oil Conference in 1982 for Gasboy, Inc.
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.
I have worked on automotive infotainment systems, set top box and UI for certain kitchen appliances at various jobs before.
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.
Been thinking of getting into it. But, I do not think the tech stack is what matters as it would be the systems knowledge about that particular market and the best way to use the tech stack to leverage that systems knowledge of that market for the kiosk end-users.
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.
Since you mention it McDonalds kiosks specifically, here's my UX observation.
It takes 10 touch screen presses to order and pay for a single item, also having to locate touchpoints (not always buttons?) which move up and down by several ft.
Not sure if it really fits your definition but I make interactive exhibits for museums, trade fairs and events. I am mostly using a visual programming environment called vvvv: https://visualprogramming.net/#Showcase
Well, in both you connect nodes through edges to build a graph :)
Seriously though, vvvv is a lot more low level and lends itself better to "application programming" while TD is rather focused on visuals. But ofc I am biased.
I work on a team building an application that displays real-time predictions/service alerts and other stuff on various types of strictly non-interactive screens posted around the MBTA’s* bus and rapid transit network.
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.
That's basically what I did for some screens around the office (before covid sent us to remote work) - elixir backend with a raspberry pi on the back of each TV, then Drab[0] to update the screen over websockets (liveview wasn't a thing then IIRC)
I worked for an Automaker for a while. When I was doing POC work we did a lot of Ubuntu on NUCs, and occasionally Raspberry Pi’s. We did a lot of QT/QML
When we were doing production work, the stack was QNX/QT. I specifically did work on a web layer
In the industrial control world, they call these "HMIs", or human-machine interfaces. There used to be a lot of Windows CE on small SBCs with PC/104 (basically ISA) bus adapters for custom logic. The software was usually a normal GDI based Win32 application, using Windows CE's real time features either in app or in a separate thread/process to meet timing. QNX photon was also popular in applications that weren't cost sensitive (telecom switches, million dollar HVAC, 10 million dollar elevators, etc). The business model was usually a government contract, where we adapted existing in-house HMI libraries to a vendor's SBC mated to our proprietary control boards.
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.
As a web developer, I certainly agree that doing this sort of stuff using web techs is almost certainly like using a howitzer to swat a fly, especially when security is a concern, and I'm kinda surprised… well, not surprised, but more dismayed by the number of replies to the OP saying they did this with web techs. When all you have is a hammer…
I worked at a company where another team built kiosks for malls and such. Last time I checked, they work remotely for the majority of the work but do have to go to the office to properly test the software at times. Fully remote is a no go for sure.
I work for LinkNYC. We have a few thousand kiosks all around New York City.
I work remotely from a different state without any issues, as does the rest of engineering.
They shipped all the relevant hardware to my home address. It was a bit of a hassle to put it all together and it can take a bit of space but it's definitely doable.
I left NYC a few years ago because I got tired of the city. The rest of engineering mostly moved out during Covid. It wasn’t a company strategy to hire out of city, it just happened
I used to work for an avionics company’s in-flight entertainment (IFE) division for just one year. IIRC the business model primarily involved selling new systems to airlines to be installed into newly-delivered aircraft and secondarily upgrading those systems hardware, software and content.
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.
I’m Product at CHEQ (hiring in Greater Seattle area). Kiosks are part of our product portfolio that are used to order food and drink at stadiums. https://www.cheqplease.com/stadiums
Our kiosks are running Android.
Are you looking at building a kiosk? What is your use case?
Not as a main gig, but I frequent an arcade bar very often. I've started light research into how I might put together an arcade cabinet running a unity app using a raspberry pi. I was looking into how to automagically start the app in full screen using Linux. Something that I think may be accomplished using systemctl? The idea is to have it be plug and play; arcade bar staff should just turn it off and back on for it to restore video game service.
Any tips are welcome and appreciated. If not, I'll do heavier research when I am ready to hack this idea into life.
My fear is if the unity app somehow loses focus, perhaps due to some annoying OS pop up. I'd love to learn more so I can be confident that it could run in production without too much concern.
I have used Android Open Source Project (AOSP) as a basis for kiosk/embedded UI. For most projects it is overkill. In one case the need was to integrate an inventory management app into a commercial kitchen label printer. That made sense. But, unless you are starting from a large existing Android app, I would look for a simpler, more specifically kiosk-oriented platform.
Aside: Our local Taco Bells were a trial for ordering kiosks ~25 years ago. One of my friends worked on it. According to him, a significant contributor to the failure of the project, at the time, was that they didn't want to spend money on industrial PCs, and grease and commercial PCs don't get along very well together.
They were shockingly similar to the kiosks that got deployed at the same location ~3 years ago.
I was visiting a lot of Europe a few months ago and 90% of the fast food restaurants have moved exclusively to kiosk ordering. One thing I noticed is that the kiosks are all set back a good distance from the kitchen.
A McDonald's I stopped at had a row of kiosks against the wall lining the entire length of the restaurant; probably 10 kiosks 3-4 feet apart. I'm curious if they discovered the same thing about grease when installed on/close to the front counter.
I did about ten years back for a client. Android-based tablets, peripherals connected via USB HID, front end built on libGDX (it was a gaming-related product), in-house remote management agent + back end (a WebSocket key/value store + pubsub db managed with a Django app, SSH + adb for fallback device access). Overall I was happy with the approach but if I were building it today hopefully there would be better off the shelf software for the back end. The client's business involved renting the kiosks to customers of their larger gaming business.
I develop perhaps the most affordable family tree and organigram software. "Kiosks" in under-developed countries offer customers the option to create their family tree with it. Since it's collaborative, free, and cross-platform, customers can then share it with their relatives. The kiosk's cost can range from $0 to $12, no subscriptions charged
55 comments
[ 3.1 ms ] story [ 99.1 ms ] threadI 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.
Arm/cpp/linux
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.
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.
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.
Here's the slides from a presentation I did if they're helpful: https://www.slideshare.net/ClaudiuLodromanean/start-developi...
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.
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.
It takes 10 touch screen presses to order and pay for a single item, also having to locate touchpoints (not always buttons?) which move up and down by several ft.
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)
[0] https://tg.pl/drab
When we were doing production work, the stack was QNX/QT. I specifically did work on a web layer
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.
I work remotely from a different state without any issues, as does the rest of engineering.
They shipped all the relevant hardware to my home address. It was a bit of a hassle to put it all together and it can take a bit of space but it's definitely doable.
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.
Our kiosks are running Android.
Are you looking at building a kiosk? What is your use case?
Any tips are welcome and appreciated. If not, I'll do heavier research when I am ready to hack this idea into life.
They were shockingly similar to the kiosks that got deployed at the same location ~3 years ago.
A McDonald's I stopped at had a row of kiosks against the wall lining the entire length of the restaurant; probably 10 kiosks 3-4 feet apart. I'm curious if they discovered the same thing about grease when installed on/close to the front counter.
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