-
Notifications
You must be signed in to change notification settings - Fork 0
Exhibit Development Guide
This page explains how to develop software for an exhibit at the Jerusalem Science Museum. It covers everything from getting a repository to testing your code on a fresh kiosk install. It's written for university students and external contractors — no deep software experience required.
Who are you?
- External contractor building an exhibit for the museum? Start with Getting Your Repository below, then read the rest of the page.
- New museum team member? Your team lead will set up the repo for you — skip ahead to Repo Naming Convention and read from there.
All exhibit software at the museum must run from a repository in the museum's GitHub organization: jerusalem-science-museum.
There are two ways to set this up:
The museum creates a dedicated repository in the org and adds you as a collaborator on that specific repo. You'll have push access to your exhibit repo only — not to any other repos in the organization.
- Coordinate with your museum contact to create the repo (see naming convention below)
- You'll receive a collaborator invite via email — accept it
- Clone the repo and start working
- When the project is done, the museum removes your collaborator access
This is the preferred approach because the code lives in the right place from day one.
If you prefer to develop privately first:
- Create a repo in your own GitHub account
- Develop your exhibit there
- When done, use GitHub's Transfer repository feature to move it into the
jerusalem-science-museumorg - The museum will need to accept the transfer on their end
Note: Either way, coordinate with the museum team lead before you start. They'll help you pick the right repo name and set things up.
Repository names follow the pattern: category-descriptive-name (all lowercase, hyphen-separated).
The first word is the exhibit category — it groups the repo with the rest of that exhibition's code. Current categories:
| Prefix | Exhibition |
|---|---|
space |
Eitan Stiva Space Exhibition |
energy |
Energy |
illusions |
Illusions |
leonardo |
Leonardo |
ftc |
Freedom to Create |
ftf |
Freedom to Flow |
edu |
Educational Workshops |
ext |
External Exhibitions |
bear |
Bear Department |
dl |
Discovery Lever |
arad |
Arad |
archive |
Archive |
Examples:
space-what-would-you-take-to-spacespace-rfid-what-to-takeenergy-solar-panel-demo
The full list is maintained here. If you need a new category (e.g. for a new exhibition), ask the museum team lead to add it.
| File | Purpose | Required? |
|---|---|---|
setup.sh |
Installs exhibit-specific dependencies and configures auto-start. Run once after the base kiosk setup. | Yes |
run.sh |
Launches the exhibit. Called automatically on every boot after setup. | Yes |
requirements.txt |
Python package dependencies (if your exhibit uses Python) | Yes (if Python) |
README.md |
Brief description: what the exhibit does, how to set it up, how to test | Yes |
.gitignore |
Exclude .venv/, __pycache__/, logs, data files, etc. |
Recommended |
Your setup.sh handles exhibit-specific setup only. It does not need to set up the entire machine — that's already done by the base kiosk setup scripts:
- Linux Mint: Kiosk Base Setup
- Raspberry Pi: Kiosk Base Setup RPi
Your setup.sh runs after the base setup and should:
- Install any additional system packages your exhibit needs via
apt - Create a Python virtual environment and install
requirements.txt - Set file permissions (
chmod +x run.sh) - Configure the exhibit to auto-start on boot
It should be idempotent — safe to run more than once without breaking anything.
Use these as a starting point for your own setup.sh:
-
Linux Mint — setup.sh: On Mint, the base kiosk setup and the exhibit setup are separate scripts. Your
setup.shhandles only exhibit-specific things: venv, pip packages, desktop autostart entry, Chromium kiosk mode, etc. -
Raspberry Pi — see Kiosk Base Setup RPi: On RPi, the setup script from the wiki page is your repo's
setup.sh— you copy it into your repo and customize it (add your apt packages, configure your app). There's no separate base setup step.
Writing bash scripts can be tricky. Use Claude (the AI assistant) to help you write your setup.sh and run.sh. Give it one of the example scripts above plus your project's requirements, and ask it to generate a first draft. It's great at this.
run.sh is what executes every time the kiosk boots. Keep it simple:
#!/usr/bin/env bash
cd "$(dirname "${BASH_SOURCE[0]}")"
source .venv/bin/activate
python3 main.pyKey points:
- Always
cdto the script's own directory first (so relative paths work regardless of where it's called from) - Activate the virtual environment
- Launch your application
Platform-specific notes:
-
Linux Mint / browser-based exhibits:
run.shalso needs to open Chromium in kiosk mode after the server starts. See the Mint example repo above. -
Raspberry Pi / hardware exhibits:
run.shmight need to launch VLC with hardware decoding flags, or set up serial connections. See the RPi example repo above.
This is the most important step. Your setup.sh must work on a machine that has the base kiosk setup and nothing else. The only way to verify this is to test from scratch.
- Install VirtualBox on your development computer
- Create a VM and install Linux Mint — see Installing Mint
- Run the base kiosk setup script — see Kiosk Base Setup
- Clone your exhibit repo and run
./setup.sh - Reboot the VM
- Your exhibit should start automatically
For faster development iteration, you can use a VM on your computer:
- Install VirtualBox on your development computer
- Download the Raspberry Pi Desktop ISO (the x86 version for PCs/VMs)
- Create a VM and boot from the ISO
- Run the base kiosk setup — see Kiosk Base Setup RPi
- Clone your exhibit repo and run
./setup.sh - Reboot the VM
- Your exhibit should start automatically
Important: The VM is useful for development, but you must also test on an actual Raspberry Pi before submitting. Some things (hardware GPIO, camera, serial devices, GPU acceleration) behave differently on real Pi hardware.
The kiosk computers at the museum start from a fresh OS install. If your setup.sh only works on your development machine — where you manually installed things over weeks — it will fail on a real kiosk. Testing on a fresh install is the only way to catch missing dependencies.
-
requirements.txt— Generate it withpip freeze > requirements.txtafter installing your packages. Commit it to the repo. This is howsetup.shknows what to install. -
.gitignore— At minimum, ignore.venv/and__pycache__/. Use gitignore.io to generate one for your tech stack. -
Don't commit large files — Videos, images, and other large assets shouldn't live in git. Talk to the museum team about where to store them (usually a
data/folder that's downloaded separately). - Commit often — Make small, frequent commits with short descriptive messages. It makes it much easier to find and fix problems.
- Use Claude — Seriously. If you're stuck on bash, dependencies, autostart, or anything else, just ask Claude. It knows these patterns well.
Before submitting your exhibit, verify:
- Repo is in the
jerusalem-science-museumorg (or ready to transfer) - Repo name follows the
category-descriptive-nameconvention -
setup.shexists and works on a fresh machine after base kiosk setup -
run.shexists and launches the exhibit -
requirements.txtlists all Python dependencies -
README.mddescribes the exhibit and setup steps - Tested on a fresh Linux Mint VM or fresh Raspberry Pi OS
- Exhibit starts automatically after reboot
- Kiosk Base Setup — Base setup for Linux Mint kiosks
- Kiosk Base Setup RPi — Base setup for Raspberry Pi kiosks
- Exhibit Setup Template — Template for documenting your exhibit on this wiki
- Contributors and Repositories — Who built what, and where the code lives
Kiosk Setup — Linux Mint
Kiosk Setup — Raspberry Pi
Development
Exhibits
Reference