How HistoryShowcase works, from first setup to the kiosk
Everything behind a HistoryShowcase display: setup and editing, photo processing, layouts and motion, phones, kiosks and offline use, hosting and releases, people and permissions, low-power mode, browser support and testing.
A full-screen web display, built for all-day kiosks
A HistoryShowcase display is a web page that runs full screen in a Chromium-based browser. It loads your school’s saved content, shows photos as soon as they are ready and scales its visual effects to the screen it runs on. Saved offline, it keeps working when the network drops.
Updated
- Browser engine
- Chromium 116 or newer: Chrome, Edge, ChromeOS and Android System WebView kiosk apps
- Tested on
- Current stable Chromium (149) for every change; Chromium 116 checked on the live site
- Screens tested
- 1920 × 1080 landscape, 1080 × 1920 portrait, tablets and phones down to 320 px wide
- Slower hardware
- Low-power mode, chosen automatically or turned on for every display
- No network
- Save display offline keeps a verified copy on the device
- Check your screen
- Add
?motion=hudto the display address
From first idea to a live kiosk
Start without an account
Open /start and the real setup wizard and editor run in your browser. Your work stays on that device until you create an account. It is then copied into the account and compared before the browser copy is removed.
Set up in four steps
Enter your school’s details, add a logo (its colors are suggested for you), choose up to 10 starting collections and pick one of three designs. The preview beside the wizard is the real touchscreen, scaled to fit.
Begin with examples
Each collection starts with three example stories to edit or replace, and a Layouts collection shows every look. A story that still holds its sample text never appears to visitors.
Edit with autosave
Text saves after a short pause and choices save immediately. Visible content goes live once the server confirms the save. Private stories and hidden collections are saved but stay off the live site.
Bring in your team
Add colleagues by email as owners, publishers, editors or viewers. They get access by signing in with that address.
Launch a display
Pair a kiosk with a single-use code, open it full screen and save it for offline use. Saved changes go live without a separate publishing step.
Editing tools
Editor beside the real screen
A side drawer with four tabs edits the live touchscreen next to it, shown at landscape, portrait (1080 × 1920) or phone (430 × 932) size.
Undo and history
Undo and Redo, a filterable change history with Revert, and Recently deleted, which keeps removed items for 30 days.
Spreadsheet import
XLSX, XLS, CSV or TSV files up to 5 MB, 2,000 rows and 40 columns. Formulas aren’t evaluated and macros never run. Imported stories arrive as proposals to review.
Smart Add
Turns pasted notes, documents and photos into proposed stories tied to their source. Nothing changes on the site until you apply them.
Find and replace
Searches the fields you choose and shows every change before and after, so you can review it before it is applied.
Rich stories
Headings, tables, captions, colors and language tags in the story text, with up to 100 photos and videos in each story.
Photos, video and yearbooks
Prepared before upload
Photos are resized to at most 2560 px on the longest side, turned upright and saved as WebP in the browser. Camera details, including GPS location, are removed before the file leaves the device.
Five sizes of every photo
Each photo is stored as WebP at 160, 320, 640, 1280 and 1920 px wide, never enlarged beyond the original.
The right size for each spot
Search results, cards, portraits and full-screen backgrounds each load the smallest size that stays sharp on that screen. Zoom opens the original.
Color while loading
Every photo’s main color is recorded, so its frame is tinted to match while the photo loads.
Other photo formats
HEIC, AVIF and TIFF photos are converted to WebP on upload.
Video
Videos up to 350 MiB upload straight to storage, can carry a custom thumbnail and stream in pieces, so playback starts without downloading the whole file.
Yearbooks and books
PDF yearbooks open as page-turning books. Their text is extracted, with character recognition for scanned pages, so visitors can search inside a book and see matches highlighted.
Layouts, design and motion
Prebuilt layouts
33 home screen layouts and dozens more for collection lists, profile grids and stories, all chosen from visual previews in the editor.
Complete designs
9 complete designs, 13 font pairings and your own uploaded fonts (WOFF2, WOFF, TTF or OTF). Gallery lighting can be Evening, Daylight or the original look.
Atmospheres
28 animated atmospheres and 14 film backdrops, from starlight to snow, plus confetti and sparkle celebrations you can turn on for each page.
Arrival motion
Headings, cards and photos rise gently into place in about a third of a second, in turn, so each page feels composed rather than switched.
Resting and waking
Decorative loops rest after a minute without visitors and wake as soon as someone touches the screen.
Ready for the next visitor
After 6 minutes without a touch (you can change this), the display asks “Still exploring?” and then returns home, resetting text size and other accessibility settings. It never interrupts a video playing with sound.
Filters and search
Two filters of your own choosing, such as sport and decade, each with up to 20 values that can be suggested from your stories, alongside full search.
Live athletics
Athletics pages can show approved schedule and video feeds, refreshed every 5 minutes and available as a calendar subscription.
Phones, tablets and accessibility
Automatic phone layout
On a phone-sized screen, the same site switches to a phone layout with a compact bar for Back, Home and Search and touch targets of at least 44 px.
Lighter on phones
Phones skip decorative effects and celebrations, so they spend their effort on your stories and photos.
Tablets
Portrait tablets use the compact story layout, sized for a narrower screen.
Visitor accessibility
Every display has an Accessibility panel: text size from 16 to 28 px, Reduced motion, Invert colors, Full screen and Reset.
Take it with you
A QR code on the display opens the same page on a visitor’s phone.
Largest text on the smallest screen
Tests check the largest text size on a 320 px-wide phone, so text reflows instead of being cut off.
Kiosk launch and offline displays
Pairing codes
A pairing code is two words and four digits. It works once, within 10 minutes, and is exchanged for the display’s own link.
Display codes
A reusable 12-character display code can sit in a kiosk’s start address, so the screen comes back by itself after a restart.
Any kiosk browser
Open the display in Chrome and choose Full screen, or put it in the Start URL of a kiosk app such as Fully Kiosk Browser.
Save display offline
The display stores a complete copy of your content, photos and the touchscreen itself, and checks every file against its SHA-256 fingerprint. It leaves room on the device rather than filling it.
Updates without gaps
A new copy is prepared alongside the last complete one, so an interrupted update leaves the previous version working.
Status reports
Each registered display reports its content version and offline readiness once a minute.
What happens when a display starts
The display opens
The kiosk browser opens your display’s address full screen. It loads one compiled set of scripts and styles. Every file name carries a fingerprint of its contents, so a display never mixes old and new files.
It chooses a power mode
Before drawing any effects, the display checks the visitor’s settings, your school’s Performance mode and what the device reports about itself. It then starts in the full experience or in low-power mode.
It loads your content
The display reads your school’s current saved content. Stories you keep private never reach it.
Photos arrive in order of need
Photos on screen load first. Downloading and decoding run in separate lanes, so one large photo can’t hold up the next. The previous photo stays visible until its replacement is decoded, so visitors don’t see blank frames.
Visitors explore
A tap lights the pressed button at once, before the next page renders. Back returns to the same filtered results and scroll position.
It keeps measuring itself
On Automatic, the display times scrolling and taps while visitors use it. If it is clearly too slow, it switches to low-power mode once and stays there for a week.
Low-power mode
Many kiosks pair a large panel with a small processor and graphics chip. A full-screen glow, blur or film-grain layer costs real work on that hardware, even when it holds still: the browser still has to paint it and combine it with everything above it, and that work competes with the visitor’s next tap.
So low-power mode leaves decorative layers out entirely rather than freezing them. The device spends its time on your content and on responding to touch.
Hardware reports alone miss many slow kiosks. Chromium reports at most 8 GB of memory and only a processor-thread count, however weak the graphics or large the screen. That is why a display on Automatic also measures itself. Once it has switched, it never switches back during a visit, so the experience can’t flicker between modes.
When a display uses low-power mode
Visitor settings, your school’s setting and a 2G connection come first. This device’s choice comes next, then hardware reports and measurement.
| Reason | What the display checks | How long it lasts |
|---|---|---|
| Reduced motion | The device’s reduce-motion setting, or the display’s own Reduce motion choice in Accessibility | While it is on |
| Data saving | The browser’s data saver is on | While it is on |
| Your school’s setting | Performance mode is On in the editor, under Motion & atmosphere. It applies to every display and to the editor preview. | Until you change it |
| Slow network | The browser reports a 2G connection | While the connection is that slow |
| This device’s choice | The display address was opened once with ?performance=lite or ?performance=full | Until ?performance=auto clears it |
| Smaller hardware | The device reports 4 GB of memory or less, or 4 processor cores or fewer | Each time the display starts |
| Measured slowness | After 90 frames of scrolling, a quarter of them took longer than 34 ms (under about 30 frames per second), or the middle value of the latest taps (at least 6) took longer than 200 ms from touch to the next paint | One week, then the display measures again |
What changes in low-power mode
| Part of the display | Full experience | Low-power mode |
|---|---|---|
| Atmospheres and particles | Animated, with a video or still version where needed | Not drawn |
| Celebrations | Shown on cue | Not drawn |
| Scene grain, vignettes and background ghost photos | Layered over the background | A solid surface in your theme colors |
| Hall light pools and the blurred copy of a portrait | Drawn behind the story | Not drawn |
| Welcome-screen photo | Drifts slowly | Holds still, with its contrast shade kept |
| Photos held in memory | Up to 18 decoded photos or 80 MB | Up to 6 decoded photos or 24 MB, with fewer loading at once |
| Content photos, logos, colors, fonts, focus outlines, filters, search and accessibility settings | Shown | Shown, unchanged |
Hosting, delivery and releases
Content delivery network
Pages, the touchscreen and photos are served through Amazon CloudFront. Files named by their contents are cached for a year; the touchscreen’s entry files are rechecked on every load, so displays pick up a new release straight away.
Serverless platform
The API runs on AWS Lambda (Node.js 22 on ARM processors) behind API Gateway, with DynamoDB for content and private, versioned, encrypted S3 storage for media. Photo sizes, video conversion and text extraction run as background jobs.
Releases built once
Every release is built once into an unchangeable package with a SHA-256 fingerprint of every file. After upload, every live byte is checked against that list and health checks run.
Automatic rollback
If a deployment, health check or byte check fails, the previous release is restored automatically.
Recovery
The content database can be restored to any point in the last 35 days, and stored media keeps earlier versions of replaced files.
People, roles and protection
Each person gets one role for each school site.
| Role | Edit content | Approve changes and manage displays | Manage people |
|---|---|---|---|
| Owner | Yes | Yes | Yes |
| Publisher | Yes | Yes | No |
| Editor | Yes | No | No |
| Viewer | No, view only | No | No |
How content and accounts are protected
School sign-in
School accounts confirm their email address and can use passkeys. Staff sign in separately, and staff addresses can’t use the school sign-in.
Each school’s own space
Every request is checked against the signed-in person’s school memberships, and each school’s files are stored and checked under that school alone.
Private stays private
Private stories, hidden collections and unapplied proposals never reach public displays. Private photos open through links that expire after 60 seconds.
Display credentials
Display links and codes are shown once and kept on the server only as one-way hashes. A display’s link stays in the kiosk’s start address, never in shared links or QR codes.
Agent and API access
Connections for AI agents and integrations have their own scopes (read, content, design, publish), expire after 1 to 90 days and can never manage people or displays.
Lean records
API logs record each request’s route, status and timing, not its content. Change history and audit records are kept for a year.
Crawlers and AI tools
School sites tell crawlers and AI tools not to collect their content, and the workspace asks search engines and AI tools not to index it or train on it.
Supported browsers and devices
Displays and the editor need a Chromium-based browser, version 116 (released in August 2023) or newer. Every change is tested in the current stable Chromium, version 149 today. On November 8, 2026, Chromium 116 also opened the live display and went from the home screen to a collection, a story with its photo, and back, in both power modes, with no errors.
For the full experience, choose a kiosk with more than 4 GB of memory and more than 4 processor cores. Smaller devices start in low-power mode. The tests cover landscape 1920 × 1080 and portrait 1080 × 1920 kiosks, 768 × 1024 tablets, 390 × 844 phones and 320 px-wide phones at the largest text size.
| Browser | Where it runs | Status | How we test it |
|---|---|---|---|
| Chrome and Chromium 116 or newer | Windows, macOS, Linux and ChromeOS | Supported | Every change runs in current Chromium. Chromium 116 was checked on the live site in both power modes. |
| Microsoft Edge 116 or newer | Windows | Supported | Same Chromium engine. Not tested separately. |
| Android System WebView 116 or newer | Android kiosk apps such as Fully Kiosk Browser | Supported | Same Chromium engine. Kiosk apps that send their own browser name are part of the tests. Keep WebView updated from Google Play. |
| Chromium 115 and older | Any | Not supported | The display uses browser features first available in Chromium 116. |
| Safari and Firefox | iPhone, iPad, Mac, Windows and Linux | Not tested | Visitors may open shared links on their phones. Phone layouts are tested at phone sizes in Chromium only. |
How we test speed and quality
Automated checks run on every change; deeper measurements run whenever a change affects motion or rendering.
Browser tests for every change
Every change to the touchscreen or the editor runs the full browser test suite in current Chromium, split across four parallel runners, alongside unit tests, type checks and a production build. A change can’t merge until all of them pass. The tests tap through real journeys: kiosk navigation, filters, search, Back to the same results and scroll position, keyboard focus, the largest text size on a 320 px phone, portrait screens, offline saving and kiosk apps with their own browser names.
Both power modes
The main browsing journey runs twice, once in the full experience and once in low-power mode, so neither mode can quietly break filters, story returns or keyboard focus. Separate checks confirm that reduced motion stops animation and that decorative effects come to rest.
Chromium trace profiling
For any change to motion or rendering, we record Chromium performance traces before and after it. They show whether each animation runs on the graphics compositor or the main thread, which layers repaint, how long painting and image rasterizing take, and how each tap divides into input delay, event handling and rendering. A performance budget fails the run when a tap, layout shift, forced layout or number of animations goes over its limit.
Constrained-device comparisons
For changes aimed at slower hardware, the old and new builds run side by side in fresh browsers on cloud machines limited to 1 GB of memory and a quarter of one processor core. Each run uses a synthetic school with no real content. It taps through Explore, a collection, a filter, a story and Back, and a step only counts as ready when the expected photo is decoded and visible.
Long-running soak tests
A display repeats the same visits for days, so anything a visit leaves behind adds up. Soak runs repeat a visitor’s tour many times, collecting garbage between rounds. They flag pages, elements, event listeners or memory that keep growing, and name what is holding on to them.
Release verification
After every release, automated checks run against the live addresses. They confirm that the public pages, the display and the editor load, that a reference school’s live content matches its recorded checksums, and that the API and private photos refuse anonymous requests.
Check your own screen
The same performance monitor we use runs on any HistoryShowcase display or editor. Open it on your kiosk to see how your hardware handles your content.
Test browsers use software graphics. They show whether a change makes the display faster or slower, not your panel’s exact frame rate, so your own screen is the final check.
- Turn it on
- Add
?motion=hudto the display or editor address.?motion=offturns it off. - Frame rate
- Frames per second, the screen’s refresh rate, the slowest 1 in 20 frame times and dropped frames
- Taps
- The slowest interaction on the current page, amber from 100 ms and red from 200 ms
- Stability
- Layout shifts, memory and the number of page elements, refreshed every 5 seconds
- Share it
- Copy report copies a detailed report you can send to support
- Try a mode
?performance=lite,?performance=fullor?performance=autosets this device’s choice
Technical questions
Which browser should our kiosk use?
Chrome or another Chromium-based kiosk browser, version 116 or newer, with automatic updates turned on. On Android kiosks, keep Android System WebView updated from Google Play; kiosk apps such as Fully Kiosk Browser use it to show the display.
Will low-power mode hide our photos or logo?
No. Low-power mode removes only decorative effects. Your photos, logo, colors, fonts and stories stay the same, and visitors can still filter, search and use the accessibility settings.
Can we always use the full experience on a capable screen?
Yes. Open the display address once with ?performance=full, and that device remembers it. A visitor’s reduced-motion or data-saving setting, a 2G connection or your school’s Performance mode set to On still take priority.
Does the display keep working without internet?
Yes, once you save it offline. In the display’s Accessibility panel, choose Save display offline and wait until it’s ready. The device keeps a complete, checked copy of your current content, photos and the touchscreen itself. Updates are prepared alongside the last complete copy, so an interrupted update leaves that copy in place.
How can we see how our screen performs?
Add ?motion=hud to the display address. An overlay shows the frame rate, dropped frames and the slowest tap while you use the display. Copy report gives you a detailed report to send us.
Do these tests prove how our screen will perform?
No. Test browsers run on servers with software graphics, so they show whether a change makes things faster or slower, not your panel’s exact frame rate. Check your own hardware with the overlay; the display also measures itself while visitors use it.
