Drupal 8 can power experiences beyond the traditional web. As more data rich APIs become available, Drupal can be used to accumulate data, identify a variety of devices in an Internet of Things network and then route data to the appropriate places. Given Drupal’s own rich content management capabilities, the CMS can still be utilized to enhance this datastream - making it that much more relevant based on location, language or any other metadata stored in it. In this presentation we will demonstrate how to use Drupal 8 to power a real-time signage system and discuss the techniques to build your own! What’s Covered: Responsive Techniques to support different display sizes. ADA rules around public signage. We’re not just talking WCAG/508 anymore! How to rebroadcast data from other sources. Data Delivery Methods: Push and Pull models. Sizing and Scaling your network of Signs. Fault tolerance on your Kiosk. Why even use Drupal to power a sign?

1. BEYOND WEBSITES: USING DRUPAL FOR DIGITAL
SIGNS

2. About Us

3. Adam Weingarten
Technical Architect, Acquia
D.O:
github:
linkedin:
adam.weingarten
aweingarten
adam.weingarten

4. Mike Madison
Technical Architect, Acquia
D.O:
github:
linkedin:
mikemadison
mikemadison13
mikemadison

5. WHY ARE WE HERE?
Next-generation digital experiences
Beyond conventional browser

6. WHAT COULD THOSE LOOK LIKE?

7. TOUCH SCREEN ON A CAR/PLANE

8. MALL KIOSK

9. PUBLIC TRANSIT

10. WHY ARE WE REALLY HERE? SIGNS!

11. WHAT ARE YOU GOING TO HEAR ABOUT?
Content Management
Working with external data
Data Transmission
Device Management
Security
Support
Case Study

12. WHY EVEN USE DRUPAL TO POWER A SIGN?
SKEPTICS SAY: THERE ARE BETTER OPTIONS!
Caution: Gratuitous opportunity to cram in buzzwords and
technologies!
Great DX. Horrible UX.

13. DRUPAL PROVIDES UX FOR MANAGING CONTENT!
Even in a headless world Drupal has a place
Makes it easy to author and edit
Has views to find the right content
Services to spit it out

14. WHY DO WE USE DRUPAL TO MANAGE CONTENT
AGAIN?
Content Modeling
Access Controls & Permissions
Revisioning
Translations
Reproducing this elsewhere is expensive

15. DRUPAL LETS NON DEV MORTALS EDIT THE WEB

16. CONTENT MODEL EXAMPLE: DC METRO!
Lines: Red, Blue, Yellow, Green
Line Direction: Shady Grove or
Glenmont
Stations: Metro Center,
Smithsonian, Farragut North
Platforms: Single platform can
service Multiple lines.

17. D8 MAKES IT EASY TO SYNDICATE THIS DATA
USING WEBSERVICES
Build your own API

18. WORKING WITH EXTERNAL DATA AND FEEDS
Drupal isn't the source of all things.
It can still help process outside data.

19. WHAT KIND OF "EXTERNAL DATA" FROM OUTSIDE
APIS:
Pinterest, Facebook, Twitter

20. TRAIN ARRIVALS

21. WEATHER

22. STOCK QUOTES

23. TOP NEWS

24. CONTEXT IS EVERYTHING
Remember that Drupal content model?
We can use it to to process that data!

25. BACK TO OUR TRAIN EXAMPLE...
Say we have an arrival feed.
Can process updates for specific signs
Let the signs know that something has changed

26. HOW DOES THIS ACTUALLY WORK?
Start with a Drush command
Store the credentials in Drupal
Sprinkle in some caching to enforce rate limits
Parse and normalize data

27. DATA TRANSMISSION
Getting information from Drupal to your device

28. APPROACHES

29. PULL SUKS
High Traffic
Load on devices
Load on servers
Can mimic DDOS

30. THE DREAM
Send data to devices from multiple APIs in "real" time

31. PROBLEM: DATA IN REAL TIME
!@$!%@# Caching
Must stay "current" over time
Limited or no user interactivity
(can't constantly reload)

32. OUR SOLUTION?

33. USE A WEBSOCKET!
Long connection time
Nearly instantaneous communication
Can be shared between devices
Bi-directional

34. ...AND MOST IMPORTANTLY

35. HIGHLY SCALABLE
(pretty critical for a lot of devices getting a lot of data)

36. CASE STUDY: AWS IOT SERVICE
N number of Devices each subscribe to 1 or more "topics"
Drupal subscribes to one or more data sources
Drupal pushes appropriate data to appropriate topic(s)
IOT pushes data to connected device(s)

39. PRETTY COOL BUT...
...now we have a new problem

40. DEVICE MANAGEMENT

41. SO FAR, DRUPAL KNOWS ABOUT:
Data
Content

42. BUT!
That case study only works if Drupal knows about the Devices too

43. WHAT DO WE NEED TO TELL DRUPAL?
Which device cares about what data?
What format should the data be provided in?
How do you make sure that only your devices are accessing the
data?

44. WHICH DEVICE CARES ABOUT WHAT DATA?
Device Location: DC Metro
What direction do trains travel?
What tracks does this screen cover?
What platform is the device on?
What station is the platform in?
What routes run through that platform and station?

46. CREATE "CONTENT" TYPES
Entity references provide context
Metadata can be used in reports
UX bonus: re-use this structure for message / data placement

47. CAUTION:
Fully boostrapping Drupal during parsing == slow
Cache!

48. WHAT FORMAT SHOULD THE DATA BE PROVIDED
IN?
What size screen?
What IP address?
What direction is the screen facing?
What language should the device display?

49. HOW DO YOU MAKE SURE THAT ONLY YOUR
DEVICES ARE ACCESSING THE DATA
Whitelist your system
Make sure your service requires authentication from devices
Require TFA for user access
(let's talk more about this)

50. SECURITY
You just created a real device in the real world!
And everyone wants to hack it

51. GIVE YOUR HARDWARE SOME LOVE
Embedded devices have poor security track-records
O en ship with default passwords.
Restrict physical access

52. YOU HARDWARE ISN'T JUST HARDWARE.
IT'S ALSO RUNNING SOFTWARE.
Make sure that the vendor releases patches in a timely manner
Stay on top of firmware updates
Plan for upgrades when any installed so ware has a published
vulnerability

53. IF IT CAN CONNECT TO THE INTERWEBS YOU CAN
HACK IT
Even a TV can be hacked

54. SOURCE DATA
Guard the back door!!!!
MUST be as secure (or more so) than the rest of the stack
Validate your data
Audit your data

55. IT'S 2017 USE SSL EVERYWHERE
No one wants a man in the middle attack
Great way to vandalize your sign
It's a go live blocker

56. IT'S NOT PARANOIA IF THEY ARE REALLY OUT TO
GET YOU
In case you were wondering: they are.

57. FAULT TOLERANCE
Something goes wrong on a webpage you reload
Don't give it a second thought
When a sign shows a blue screen of death people notice

58. WHAT DOES FAILURE LOOK LIKE?

62. EXCEPTION HANDLING
Graceful Degradation

63. AT SOME POINT YOU WILL HAVE A PROBLEM THAT
YOU CAN'T HANDLE

64. CUSTOM EXTENSIONS TO AUTO RELOAD FAILED
TABS
Oh no you didn't Extension
Good starting point for a custom extension

65. SUPPORT
Troubleshooting a complex stack with API integrations is hard

66. LET'S PRETEND YOU DIDN'T SEE THIS
PRESENTATION
Devices use Angular to poll various APIs in real time (directly)
You didn't load test any of your web servers before launch
You add 20 more screens in production

67. ALL OF YOUR SCREENS LOSE DATA
SIMULTANEOUSLY
How do you troubleshoot?
Did a server powering one of the APIs crash?
Did the web server crash?

68. UNDERSTANDING THE ARCHITECTURE
Make sure support knows what those APIs are.
Make sure support knows the warnings signs and symptoms of
problems.

69. NEED ESCALATION PLANS FOR OUTAGES
Who owns which API
Who you gonna call

70. KNOW WHAT YOU CAN AND CAN'T FIX
Figure this out before something bad happens
(that includes testing before hand)

71. LOAD TEST BEFORE SCALING UP
Mirror the production hardware
Including any dependent APIs

72. AND REMEMBER!
Your source APIs may not have as robust of a workflow as your
main site
Make sure the owners of those systems know not to make
changes without notifying your dev team

73. CASE STUDY
< 5k devices, real-time data

74. CASE STUDY 2: MASS TRANSIT DISPLAYS
Devices: Digital Screens
Content: Arrival data, messaging / emergency communication

75. CHALLENGES
Real-time data across thousands of devices
Internet & websocket connectivity
Error handling & recovery
On-demand messaging
Performance

76. APPROACH
Arrivals (and other) data parsed by Drupal
Drupal content for messaging
Amazon IOT Websocket Push Model
React front end
Inventory of Drupal assets to speed parsing

77. ADVANTAGES
Right sized targeted messaging
Arrival data changes on screen within 5-8 seconds
System is massively scalable
UX for content managers

78. WRAP UP
Why Drupal is a good idea for signs!
A few techniques to use
A couple of case studies on how we used them

79. QUESTIONS?
Leave us some feedback!

80. Thanks!

81. Adam Weingarten and Mike Madison: Beyond Websites: Using Drupal For Digital Signs
00:47
RESOURCES
Places for Websockets as a Service
AWS IOT
Pubnub
Pusher