This was a student intern project that I took over to turn into a useful application for use within the company. Even though this wasn't a research project, we thought it would be a good way to make Barco Labs better known throughout the company, as many employees viewed us as an "ivory tower" doing esoteric research of little practical value. The Smart Meeting Room App (SMRA) had the very practical benefit of finding and scheduling meeting rooms on the Barco campus.
What the student interns had developed was an Ionic mobile app for smart phones that was built on top of Cordova (a.k.a. PhoneGap). Since it was a native app, that meant that the app had go through the usual Apple and Google Play app store review and approval processes to make it available for public download by users. Barco IT did not buy into the public download aspect of this app because the app might expose company confidential data. And, we needed Barco IT to approve internal use of the app along with setting firewall rules that allowed BYODs (Bring Your Own Devices) to access to the SMRA app server.
We considered going with an enterprise-only distribution license but I realized that this app could be made into a Progressive Web App (PWA) that could be installed on Apple and Android smart phones without the need for public download from the Apple and Google Play app stores. The PWA could also be installed on corporate Windows and Mac PCs without the need for admin privileges. In general, Progressive Web Apps can be user installed and run just like native applications with their own home-screen launch icons.
I had never done a Progressive Web App before (or worked with Ionic), so it took a bit of a learning curve to get up to speed on this new technology promoted by Google. Fortunately, the Ionic/Angular framework provided some support for PWAs meaning that most of the code could be reused with a bit of reworking to eliminate the Cordova dependency and add PWA required code such as service workers that cache the server pages for offline use. I also removed the unapproved password encryption code and replaced it with approved secure-session cookies. In addition, the original student app had several stability issues and missing features which I addressed. I also put the NodeJS/ExpressJS server behind an Nginx TLS termination/proxy server. This reverse-proxy setup allowed the NodeJS/ExpressJS server to run without root privileges allowing IT to manage the Nginx server and keep Barco's TLS server certificate hidden from us developers.
In the end, I managed to create a PWA that could be user installed on iPhones, Android phones, Windows PC and Macs with several GUI enhancements, solid stability and Barco IT approved security. The SMRA was then successfully deployed for company-wide use.
Here is the SMRA login screen on a PC with the Barco NV headquarters building (in Belgium), called the "The Circle", shown in the background. I did the screen graphics and responsive layout. The SMRA is integrated into the Microsoft Office calendar, hence the sign in.
Once logged in, the user is presented with a campus map.
The screen shot on the right shows how the campus map appears on an Android Galaxy S5 smartphone.
The user can then do any of the following:
- Use the search box to find any meeting room by name within any of the campus buildings.
- Zoom the campus map in and out using the [+]/[-] buttons or with the pinch gesture.
- Pan the campus map by dragging with a mouse or swiping with a finger.
- Click/tap on one of the buildings in the map to show the ground floor plan for that building.
All the building floor plans are company confidential except the ground floor plan for "The Circle" which contains the main lobby, the lounge, the cafeteria and the theater. That floor is the only area where visitors can roam without an escort. All other areas are employee only which limits what I am allowed to show here.
By the way, the campus map was drawn by your's truly using Adobe Illustrator and Adobe Photoshop.
Back to some of the app's features. If one enters "Sp" in the search bar, the app will display a drop-down list of meeting room names dynamically matching the string entered as one types. In this case, two room names containing "Sp" show in the drop-down menu.
If one clicks or taps on the "Spotlight" selection in the drop down menu above, the SMRA will then show the ground floor plan (0) for "The Circle" with the "Spotlight" meeting room highlighted with a red fill, as shown in the screen shot below.
On a PC or Mac, mousing over any meeting room momentarily pops up a tool tip displaying the meeting room name, as shown above. This is one of the enhancements I added. Unavailable meeting rooms are otherwise shown with a yellow fill while available meeting rooms are shown with a green fill (based on information provided by the Microsoft Office calendar). In this case, none of the meeting rooms on the ground floor (0) are available.
The bottom quarter of the screen allows one to set filters for room availability based on a set of criteria including:
- Equipment requirements such as a projector, phone and/or whiteboard. (Video conferencing equipment is indicated directly on the floor plans.)
- Seating needed; and,
- Estimated meeting duration.
When specified, only those meeting rooms that satisfy those requirements are highlighted as available (with green fills)
By clicking or touching the "Spotlight" meeting room on the floor plan, a dialog pops up showing what kind of meeting room it is, how many seats there are, and what equipment is available. This is shown in the screen shot below. One can also report problems with the room or request a change (such as decreasing the number of seats for COVID-19 social distancing). Because the room is currently not available, some of these options are currently greyed out. Because the "Spotlight" meeting room is next to the cafeteria, it is often used for catered meetings with guests.
The three tabs at the bottom allow the user to:
- Show the floor plans and book rooms.
- Show the user's meeting calendar for the day with room location links, or
- Show a set of preferences (which are remembered between log ins).
The user can either click/touch those tab buttons or swipe between screens.
On the Preferences screen (the last tab), one can switch various facility indicators on and off such as rest rooms, coffee nooks, elevators and stairs. Here is a screen shot of the preferences screen with four of the facility indicators switched on.
(Bubbles are small meeting cubes for one-on-one meetings or for making private phone calls that are available first come, first serve.). When swiping back to the floor plan screen, these facility indicators are now visible. The [Home] button on the upper right returns to the campus map which was another one of my enhancements.
The last five items on the Preferences screen are all enhancements I added to the app.
- The About item provides info about the app along with technical details and release notes.
- The Usage Tips item explains how best to use the app's features and what finger gestures are possible.
- The Install SMRA... item, (the wording varies with the platform), allows the app to be installed and run like a native app. (This is the PWA enhancement.)
- The Usage gathering & consent item allows the app to gather usage stats if the user consents. These stats are dumped to the SMRA server daily without revealing any user privacy info. We use these stats to see how the app is being used and where we might make improvements.
- The Debugging Info item dumps debug traces that can be e-mailed to a SMRA developer. (Even though the item shows in light grey text, the item is active.) Clicking on that item displays the screen below.
The debug tracing can be filtered by type. Users tapped the [Send] button on the upper right to e-mail these debug traces to me without giving me their phone. This enhancement has proven instrumental in stabilizing the app on a wide variety of mobile devices. While simulators and emulators do part of the job when connected to an IDEs like XCode or Android Studio, there are still stability issues that can only be tracked down when run on the actual hardware. Since I had very limited access to the large variety of smartphones in the field, I needed a way to debug issues on the user's hardware without a connection to an IDE. This debug tracing enhancement really did the trick in finding some of the more esoteric issues only seen on certain smartphones running legacy O/Ses. I had a lot of problems getting iPhones to work properly because Safari (at that time) only supported part of the PWA spec, so several work-a-rounds where needed to handle Safari's limitations. And then, there was a problem that only occurred on Android hardware devices but not on any of the Android emulators. Both issues were solved with the help of this debug trace enhancement.