I finally got around to testing out the Deck JS slideshow software on a presentation, and it works great. I love how the display can be easily coded with HTML in the backend and perfectly styled with CSS. The presentation adjusts wonderfully to different screen sizes, and it degrades nicely across older browsers. This is definitely a designer’s alterative to PowerPoint!
Which got me thinking. Deck JS may be the solution for the long-running problem I’ve tried to solve of finding an accessible digital signage platform. (Digital signage software allows you to remotely control the content of presentation monitors, such as you’d find in a store, school, or reception area.)
Here’s my idea for a DS solution using Deck JS and WordPress.
Deck JS Implementation
Deck JS would be merged into a bare-bones WordPress theme. The JavaScript would remain mostly untouched, while the theme itself could potentially have as little as a single index.php file. The document would call the Deck core, and a WordPress loop would query the slide contents and wrap them inside a .slide class.
Backend
Posts and pages would not be necessary. Instead, there would be a “Slide” custom post type, with a “Slideshow” hierarchical taxonomy. Each taxonomy item in slideshows would be a separate slideshow. Users would create a slide using the WYSIWYG editor, styling it with most of the options a normal post has. They would then categorize the slide according to what slideshows it should appear in. Creating a new slideshow would be as simple as adding a new item in the taxonomy.
Frontend
To view the slideshow, the user would go to the taxonomy archive URL for that slideshow. Use a modern browser, set it to toolbar-less full screen, and you have a display monitor.
Advancing Slides
This could be done with a JS function, at interval X.
Updating Content
A simple meta reload in the would refresh the slideshow with new content every X seconds, restarting it from the beginning. However, Deck JS supports jumping to individual slides via anchor tags, so some inline JS could be executed every X seconds to either refresh the page or go to the current URL (two ways to do the same thing).
Slide Order
Slides could with the orderby attribute: randomly, by date, by name, or by ID – ascending or descending.
“Theme” Options
Theme options for this implementation might include: a choice of transition (changing the JS transition file which loads via PHP), slide delay time, slide reload time, different Deck JS modules, CSS theme, and slide ordering rule.
Possible Shortcomings
Variation – Since WordPress’s taxonomy field options are currently very limited, there isn’t any clean way to allow per-slideshow options. These options would either have to be universal, across the entire installation, or would have to be localized in a non-user-friendly way (i.e. custom fields in the slides or appropriating the taxonomy description field).
Accessibility – Deck JS is a coder’s tools, but WordPress is very user-friendly. By using theme functions to strip irrelevant items out of the WYSIWYG editor, non-technical users could create and style most content. Even indicating transitions within slides could be done without code via a menu item to apply the relevant div class.
Previewing – Content could not be previewed before being published, due to the slideshow relying on the full taxonomy loop. However, the user could make a “test” taxonomy, and preview the slide in context.
Final Thought: Enterprise Advantage
This method of digital signage would give enterprises an advantage when coupled with a Multi-Site installation. Each user group could have its own WP instance, sandboxing them against harming each other. WordPress’s native user roles would also allow all content to be verified by a manager (or technical user) before being published. WordPress also can be configured to work with LDAP, allowing current enterprise authentication schemes to be preserved.
Comments are closed.