Turning an Old Laptop into a Video Kiosk

My father-in-law came to me with an interesting idea. He wanted to create video kiosk for our church which would play videos on different mission organizations we're involved with. The wall - previously - had photos and text about each missionary or organization, but he wanted to revamp.

We initially tried to use PowerPoint and a custom keyboard to jump to different slides, but maintaining and updating that system wasn't going to be very elegant or user friendly. So, about a year later, I had an "oh, duh" moment and realized we could do it as a static, locally-hosted website. It would be easy to build and even easier to maintain, so that's what we did.

In this post, I'll talk about the hardware and software we used to get it finished. There are still some things to hammer out, but the bones of the project are done and tested successfully, so it seems like a good time to document it.

The Hardware

Our initial idea was to use a Raspberry Pi 3 to do everything because of it's low price point and small size. Unfortunately, the RPi, in general, doesn't handle web video too well. I looked into using the kweb minimal web browser, which hooks into the native OMX Video Player on the Pi, but you can't customize the look and playing full screen video had lots of menus. In the end, it was turning into a huge job to make it look polished, so we moved away from the Pi.

My brother-in-law had an old HP laptop that had died when he tried to update it to Windows 8 (insert snarky Microsoft joke here). So, he donated it to the cause.

I wiped the hard drive and installed Ubuntu Linux 16.04 LTS. It's pretty lightweight and gets consistent updates. It's also really user-friendly in case there is a problem with the laptop, so one of the office assistants can troubleshoot if I can't make it. I also chose to stick with Linux because I can use SSH to log in via my Chromebook on Sunday mornings and run updates remotely if I need to.

flickr photo shared by bennettscience under a Creative Commons ( BY ) license

You could definitely argue that running a full desktop environment for a simple web kiosk slows the machine and introduces a bunch of variables that could cause things to go wrong, which is 100% accurate. OMG! Ubuntu! has a good article on how to either convert a full machine to a dedicated kiosk or how to build one from scratch, but since I didn't find the article until we were almost done, I decided not to go back and rework everything.

For user interaction, we grabbed an Intuos Art Small tablet from Wacom for $100. It's seated in a wall mount to lock it in place and hide the wires. Essentially, it's a giant touchpad.

flickr photo shared by bennettscience under a Creative Commons ( BY ) license

Finally, we bought a 55" wall mounted TV. The laptop had an HDMI port, so that took care of high-definition video and audio.

The Software

I built the page with plain HTML and JavaScript. It's currently being hosted locally on the machine to ensure smooth video with no buffering. I'm planning on testing the broadband rates via ethernet next time in church because over wifi we ran into issues. If I can get a good download rate, I'll switch the site over to GitHub Pages so I can update remotely.


The HTML and CSS is pretty standard. I didn't want a ton of bloat, so I coded everything from scratch. You can take a look at the markup on GitHub. There's also a live example so you can see how it's rendered.

First, this is a hallway display. There will probably be times where people aren't watching videos, in which case I want to avoid burning an image into the screen of the TV. I added a small jQuery function to bring up a prompt if no one touches the trackpad for 30 seconds. This also turned out to be handy because a lot of people walked up to the tv and tried touching it directly rather than using the trackpad input.

To play the videos, I wanted each container to reference a hidden video div. I use jQuery to handle the element selection and JavaScript to pay attention to the play state. When a user clicks the tile, a fullscreen video starts playing. There is no keyboard for them to quit out of the video, so I don't worry about keypress events. If they jump out of fullscreen using the playback controls, it saves the video location.

Ubuntu tweaks

There were also some software tweaks I needed to make on the machine itself.

I wanted a standard user to log in automatically. So, I created a generic user on the system and dropped the source files onto the desktop (more on that in a minute). Theoretically, the user will never get out of Chrome because there's no keyboard available. When the computer boots, it logs into the generic user right away.

Then, I edited the Startup Applications option. You can launch Chrome from the Terminal and you can specify which command to use in the settings. Using:

chromium-browser --kiosk [URL]

launches Chrome in the full screen kiosk mode and displays the website immediately after login.

The laptop is mounted on the wall behind the TV. Ubuntu wasn't recognizing the monitor when the lid was closed. There is a flag in etc/systemd/logind.conf that handles a dock, but we weren't using one. So, I had to change the HandleLidSwitch flag to ignore to ignore the lid being closed (thanks to this answer)

Finally, because the laptop is mounted behind the TV on tracks with a padlock, it's a pain to take it out to turn it on and off. I was able to automate the daily shutdown pretty easily by specifying a time using crontab -e (you have to be root to shut down). Startup was harder.

After some research, I found that most computers have something called a Real Time Clock (RTC) synced with UTC. It can be used to set an alarm to wake the computer. You can test this by setting the clock to zero with:

sudo echo 0 > /sys/class/rtc/rtc0/wakealarm

and then resetting it with:

sudo echo date '+%s' -d '+ 10 minutes' > /sys/class/rtc/rtc0/wakealarm

Now that I knew the computer would turn itself back on, I could create a simple bash script to run with cron that would handle startup and shutdown daily:

I stored the file in /usr/bin and made it executable with chmod +x.

Then, I edited crontab -e to run the script daily. Note that this specifies the shutdown time. At 8 PM every day, the computer will shut down. The shutwake script resets the RTC alarm:

0 8 * * * * /usr/bin/shutwake

cron can be picky, so if you need more help, this article helped a lot.

The last thing we needed to work out was muting the audio during sermons so someone didn't crank out a video in the middle of church. The video will still play with captions (accessibility FTW) and muting the audio turned out to be not too bad. I can toggle the pulse audio driver in Ubuntu with a simple cron job that runs on Sundays at 9:00 and 12:00 to turn the audio on and off:

0 9 * * * 0 amixer -q -D pulse sset Master toggle

flickr photo shared by bennettscience under a Creative Commons ( BY ) license

In the end, I'm really happy with how it turned out. Remote management and simple setup led to a really effective display for the wall.

If you want more specifics about software or construction, leave a comment.

Defining the Problem

Consider the train problem:

A train is barreling down the tracks. At a fork, you have the option of flipping the train to the left branch or the right branch. On the left side is someone you know, tied to the rails. On the right, there are five strangers.

Which way do you throw the switch?

A philosophy professor posed the question to his two-year old.

The great thing about this is that he was still solving a problem...it just wasn't the expected problem.

I think a lot of frustration can come up in a classroom comes from ambiguity. I may have a problem and anticipated solution, but if that isn't clear to students, conflict can pop up when they take a different path. Even more, defining specific solutions to problems worth discussion is a poor teaching method.

Next time you're given an unexpected solution, consider the validity of a different point of view.

More on Licensing Culture and Owning What You Pay For

I was talking with our school librarian today about why we don't offer ebooks for students to check out. It came up because I grabbed a real, hardcover library book six weeks ago and had just finished it this week. It's only 400ish pages, and taking that long to read a short/medium length book was a little embarrassing.

Compared to reading on my phone or my Kindle, it was an eternity. I like the portability of ebooks. I like being able to pull it up on my phone and read a little when I'm sitting, waiting for something. Especially this year, as I move all over the district day to day, carrying another book in my bag is precious space that's often wasted due to time.

Ebooks sound great, but I got thinking about Maha Bali's post on "owning" a domain and Audrey Watters' fantastic take (rebuttal?) on the topic. I even weighed in a little bit on how teachers can start to build that identity.

I don't want to encourage a culture where ownership is a burden. Moving school libraries to epubs sounds great: access! they're on their phones anyways! Kindle!...

...but in practice, it's a school, paying a company to licence titles. Each borrow by a student turns into dollars paid to an outside entity for the privilege of licensing the book. Libraries cannot give the books away or even recoup shrinking budgets by having used book sales. It's a expenditure, through and through.

All of that, of course, is ignoring the DRM hurdles put on certain publications, which are only accessible through certain platforms. Ebooks aren't "just like" books, only in bits. It's a completely new market geared for one thing: making a profit.

At whose expense?

Flipped Learning as a Way to Build an Online Presence

Hybrid Pedagogy is a publication you should be reading. It's completely open access, written, edited, and published by educators. The article authors and editors are laser focused on the deeper questions within technology use in education like innate power structures, programmed bias, and the fact that technology is not agnostic by nature.

This week I read Beyond Surface-Level Digital Pedagogy and was introduced to HybridPod, a companion podcast to Hybrid Pedagogy. The article linked and Martha Burtis' keynote at the 2016 Digital Pedagogy Institute really push hard on the idea that all instructors and all students should really be doing stuff on the web. Learning stuff. Breaking stuff. Just stuff.

Tying the two together is this idea (posited in the first article):

"...if our institutions of higher learning ignore the calls for critical digital pedagogy a vast number of K-12 educators will continue to look for shiny tools to cover up education’s most difficult problems."

Granted, higher education has been involved in the making (and breaking) of the web since the beginning while K-12 has really started using it in earnest with students in the last ten years. There's history there, in higher ed, that isn't present in K-12. But, are we learning lessons from that history?

In particular, have K-12 teachers really recognized the enormous value in making and sharing things online? I'm not convinced that lesson is one that's been learned, nor is it one people want to learn. Martha's discussion of the LMS is describing the current state of K-12 education:

I think the Web hit us at a critical moment in higher education where we were already struggling with doing our work less like schools and more like businesses, and the tech industry and its vendors had already begun to infiltrate us with promises of how technology could help us achieve this goal. We had already bought into student information systems (which eventually became everything information systems), and with the promise of those systems came the promise of lots of data which would allow us to become more efficient and streamlined.

As the web becomes more sterilized for our students, we have important pedagogical decisions to make.

Flipped Learning, given its popularity, is often the first place teachers are confronted with working heavily in the online space. Many are already constrained to the LMS and find the shortcomings frustrating to work within. So, they work around.

That process of working around limitations exposes teachers (and by extension, students) to the potential of working in an open web space rather than a closed web space. Flexibility and customizability become the expectation rather than the "nice-to-have." And it's not just about the look of the space: flexibility in functionality - the experience students have - can strongly influence their experience in learning (it's a hybrid experience, remember?)

I agree that Flipped Learning, at first does not necessarily push a shift in instructional methods. But, when you're used to teaching in a very straightforward manner, whether in person or online (in an LMS, perhaps) making an instructional shift is very difficult because of the mindset change involved. I'd like to propose that the first shift be to look outside the provided methods of organization and begin to explore the messiness of digital learning through open spaces.

Martha's suggestion is simple: set up, and run, a domain. The easiest thing to do is purchase a domain name and start a blog. Start sharing. Start reading. Reflecting on practice in an open environment invites comment and outside input to your pedagogy. Being transparent and vulnerable in what we do with instruction will begin to inform those instructional decisions and help bring about a shift.

As you get more comfortable with your space, you'll feel more comfortable pushing your students to do the same. Our students are creating digital footprints in spaces where there is no control. In schools, it's in the LMS. Outside of school, it's through social media (no, they do not own their tweets, snaps, or likes).

Improving in the use of technology is more than just being able to whip out the right app at the right time. It's being able to critically pick apart the explicit and implicit nuance in function while at the same time enhancing the learning experience. Use the challenge of flipping to really push your thinking about how technology can truly change the teaching and learning experience in schools.

flickr photo shared by AstridWestvang under a Creative Commons ( BY-NC-ND ) license

Push Announcements With a Chrome Extension

Patrick Donovan put out a tweet the other day with a screenshot to a Chrome extension he had just put together. It caught my attention and led to this post because it's a really, really good idea.

I tracked down Curt Schleibaum whose website included a demo to his Chrome extension idea. In short, he provided a template which included all of the necessary files to have a simple popup Chrome browser extension. It was quite clever - instead of having the user change code for the extension to push information, it had an embedded Google Doc that you use updated with new information. It also included links back to the district website, tech support, etc.

It got me thinking about how the extension could be improved, so that's what I put together last night. The source is on GitHub so you can see the nitty gritty. My extension builds on Curt's original idea - allowing a teacher or admin to use a Google service to push announcements out to extension users. Instead of a document, mine uses a spreadsheet and watches for an update to publish and then badges the extension when new information is available.

If you want to play with this yourself, follow the steps below (mostly proof-of-concept at this point, lots of refining to do).

Get the spreadsheet

Google spreadsheets are your friend. The best thing, in my opinion, is that they publish in multiple formats when you publish one to the web (this is different than sharing). One of those formats is JSON, which is a great way to take a lot of data, organize it, and then display that information nicely in another application.

Grab this template spreadsheet and save a copy to your Drive. Then, go to File > Publish to the web and publish it with all the default settings.

The Extension

The extension is a collection of JavaScript files and a popup.html file. The JS does all the magic with the spreadsheet JSON data and the HTML displays it nicely in the Chrome browser. The JS will also ping the spreadsheet every few minutes to see if there have been updates. If there was an update made, a badge notification will appear on the extension icon. Sweet.

The easiest way to do this is to download the extension and load it locally on your machine. To do that, open the project on GitHub and click on "Clone or download" on the right side of the screen. Unzip the file that downloads.

Next, go to chrome:extensions and make sure "Developer Mode" is checked. Once it's checked, you can click on, "Load unpacked extension" and select the folder you just unzipped.

The extension needs one more thing: the spreadsheet key. Go back to the template spreadsheet and grab the jumble of letters and numbers that come after


and before edit in the URL. An example URL would be,


. When you click on the extension icon the first time, you'll be prompted to copy and paste that spreadsheet key into the box. Now, you're good to go!


To test the extension, go back to your spreadsheet template and add some data. Give it a minute or two and, hey presto! Your extension will update with the information you just entered.

Most schools are using some kind of learning management system which includes a messaging app. If you're not, this would be a good way to talk with your students (maybe). In our case, we're looking at using this as a rapid-push service to notify teachers and other staff about upcoming professional learning, system outages, or other announcements that need to be sent, but don't need an email. It's definitely an experimental project, but one I'm curious to play with some more.