Digital Signage and Wayfinding

RFP Requirements Section

When this document was prepared, we still didn't completely understand the technology. Or how the project would proceed. Or basically much of anything. If you're planning to crib from this, write me to ask what I would change if I were to do this again. I'll probably blog about that later, but I didn't want anyone to use this without talking to us about lessons learned first. Also, I apologize for the formatting. -Doug

3 Specifications
3.1 General Requirements
Please attach complete product specifications and respond to each of the requirements below:

1. Solution must be able to utilize various display devices for content delivery, including but not limited to: LCD displays of all sizes, LCD/DLP projectors, plasma displays, and touch panels.
2. Solution must provide administrators the ability to instantly override any current programming on all displays for the purpose of disseminating campus-wide emergency or other alerts. The ability to interface with existing emergency alert systems is strongly desired.
3. Solution must include options for interactive kiosk installations in addition to dynamic digital signage/narrowcasting installations. Interactive directory search with integrated wayfinding capability is required. The solution shall interface with the University directory, either with a live connection or a nightly transfer of data. Solutions with common integrated management and control of both elements will be given extra consideration. Demonstrated successful experience in designing wayfinding applications for higher education customers is desired.
4. Solution should allow the Participants the ability to create, manage, and alter every aspect of the design and functionality of the system, including access to all administrative consoles within the system, the ability to change any aspect of the system’s interfaces or functionality without the participation of the Supplier, including but not limited to external database connections, design elements, skins, interfaces, frame and window layouts, and maps. Solutions allowing the University access to all source code and APIs will be given extra consideration. Conversely, Supplier must have the capability to provide professional services including graphic design, interface design, and application development as needed by the Participants.
5. The aesthetic quality of design elements provided by the Supplier must conform to the high standards set by the University of Michigan. The Supplier should provide screenshots, demos, and/or other examples of previous work to demonstrate their ability to provide graphic design of the highest quality.
6. Interface design must conform to modern best practices for usability and accessibility. The Supplier should provide screenshots, demos, and/or other examples of previous work to demonstrate their ability to provide interface design of the highest quality. The Supplier may include in their response a statement regarding the capabilities of their solution regarding the provision of accessible solutions for those of differing levels of physical capability, including the wheelchair-bound, visually impaired, and hearing impaired.
7. Solution must allow for content display natively in several aspect ratios including but not limited to 4:3 and 16:9. Solution must allow multiple options for content to be displayed in a variety of aspect ratios (full frame, letterbox, anamorphic, etc.).
8. Solution must allow for displays to be arranged in multiple configurations including portrait and landscape, multiple displays in sequence, and arrays of multiple displays. Solution must allow for configurations to be made up of different sizes, orientations, and devices.
9. Solution must be able to display low-resolution images and high-resolution images in the same stream, allowing for changes of resolution/size/orientation based on content requirements.
10. Solution must allow for user-managed windowing/segmenting of the display screen into multiple regions for simultaneous display.
11. Solution must allow for user-configurable multi-frame screen layout options; multiple frames must be independently updatable and allow for the display of various content formats simultaneously.
12. Solution must allow for video in multiple formats (Windows Media, mpeg, QuickTime, Flash, live video, CATV input).
13. Solution should allow content in Powerpoint format to be displayed without conversion.
14. Solution must support full remote administration of all components.
15. Solution must support active notification and messaging features to inform administrators of display and stream status, problems, and updates.
16. Solution must provide for multiple levels of administration and control with role-based and group granularity such that administration, approval, publishing, and notification may be assigned to groups/individuals on one display, multiple displays, or all displays. Different levels of administration may be granted to the same user for different displays such that being an administrator on one display does not necessitate administrative rights on other displays.
17. Solution must support XML feeds including RSS. Ideal solutions will accept multiple types of data streams and incorporate their content into the displayed content.
18. Solution must provide for narrowcasting/dynamic digital display functionality including remote scheduling of images, streams, content; time/date based programming for begin and end times of all delivered content; dynamic playlists or other GUI-based content management/scheduling functionality; web-based remote access for viewing content status/stream information/content.
19. Solution must allow for display of content in native resolution and format for the broadest possible content formats to include, but not be limited to: QuickTime, Flash, Windows media, Silverlight/WPF, HD, jpeg, ppt, png, pdf, gif, html, mpeg, tiff, live video feed, cable TV, DVD, VHS, mp3, wav. Support for sound delivery is required.
20. Solution must allow for remote management of audio content at individual display locations.
21. Solution may incorporate any combination of dedicated media devices, central control servers, standalone PCs, or University-provided hardware to provide optimal functionality.
22. Solution must allow for content to be delivered to one or many displays, and for the configuration and composition of display groupings and program schedules to be remotely managed, manipulated, and reconfigured dynamically.
23. Solution must allow for unattended recovery of program stream or content after interruption (i.e. power failure, network interruption). Solution must allow for remote shutdown or startup of any dedicated devices necessary for delivery of content.
24. Solution must allow for content repository management such that content libraries may be shared as desired among multiple user/display groupings; content naming requirements must be clear and concise. Ideal solutions would allow for any content image file naming structure to be implemented without alteration.
25. Solution must allow for content streams to be created from multiple file formats, content schedules and streams must be reconfigurable and interruptible. Content stream creation must be user-friendly and GUI-based. Administrative consoles should not require the installation of a client, but should be available via a Web browser. Web interfaces must be secure (HTTPS).
26. Solution should allow the display of existing Web content, the interaction with which should approximate the standard use of such content from a conventional Web browser.
27. Solution should be capable of changing the content of any frame or the source feed of any frame at a user-configurable time interval; for example, every ten seconds, a frame would display a different Web page from a pre-defined list.
28. Solution must allow for unlimited user/administrative licenses. There should be no restrictions on the number of users/administrators allowed to create content, publish content or administer the system.
29. Solution must provide for secure password protected access for each individual user/administrator of the system. Solution must have a clearly defined groups/role based management structure that allows for user configurable options and flexibility. Solutions which are compatible with LDAP directory structures for user names/passwords/privileges will be given extra consideration.
30. Solution must allow for an unlimited number of content assets to be associated with each display location.
31. Standards-based solutions are preferred, although all product solutions meeting the criteria will be considered.
32. Interactive kiosk installations may include one or more of the following: POS, VoIP, and especially videoconferencing (for example, between the kiosk and a webcam-enabled workstation elsewhere in the University, or between a kiosk and another kiosk). Solutions with unified control and management consoles for these features are preferred.
33. Solution must utilize standard video cable and Ethernet network cable for delivery of content to displays.
34. Solutions may incorporate wireless or other alternate display delivery methods as alternate or additional options, but standard delivery must be available in traditional wired connectivity methods.
35. Solution must be scalable to allow eventual deployment to the entire U-M campus and UMHS campus (100+ buildings).
36. Solutions allowing forward-and-store architectures will be given extra consideration. Ideal solutions will allow content to “trickle” to display endpoints where there is limited bandwidth, and will not require a fast network connection at all displays. The capability to receive data wirelessly is desired.
37. Solution must be modular in approach to solutions such that one area may opt for a single display and limited administrative functionality whereas another may include multiple displays and display groupings with high-resolution video and multiple user/administrative groups. Both approaches must be easily and effectively accommodated.
38. Solution may include differing options for lower resolution standard digital signage and wayfinding applications alongside the higher functionality requirements. User groups should be able to opt into a campus-wide solution with an entry level display and ramp up their signage activities and functionality without any hardware replacement requirements.
39. Solution should be capable of interfacing with Microsoft Exchange calendaring and EMS scheduling software for display of scheduled events. Solution should be able to filter calendar events per display or display group. A flexible database connection interface, preferably one that will allow system administrators and University programmers to create and alter database connections, is strongly preferred. The ability to communicate with other calendaring systems including iCalendar (RFC2445) is desired. Integration of calendaring with wayfinding is strongly desired; for example, user selection of a calendar event should launch the display of a route to that event.
40. Suppliers should supply descriptions of additional significant functional elements of their solutions not explicitly requested in this RFP should they exist.
3.3 Other Considerations
Please respond to the following:
1. The University of Michigan is committed to the sustainable use of energy and other scarce resources. Sustainable practices support ecological, human, and economic health and vitality. Sustainability presumes that resources are finite and should be used conservatively and wisely with a view to long-term priorities and consequences of the ways in which resources are used. Provide information related to your institution’s efforts in environmental stewardship. Provide any positive environmental sustainability information related to the equipment and/or services that you are proposing.
2. Are the prices offered in your proposal response the lowest afforded any other customers?
3. Delivery time shall be a consideration in the evaluation process. What is your standard lead time from receipt of order through complete installation of product?
4. Describe how installation and configuration activities are scheduled and coordinated.
5. Provide information on your customer service program, commitments and dispute resolution procedures.
6. Provide complete warranty information for products involved in proposed solution.
7. Provide information on recommended system training.
8. Explain the process of content creation and management in the following scenarios:
a. Creation of the intitial deployment content set, including maps, database connections, interactive applications, and a limited set of University of Michigan-branded slides.
b. The subsequent ongoing creation of content including departmental announcements and that content which will be displayed at the digital signage installation sites.
c. The addition of map resources, directory elements, and interactive applications after the initial deployment.
d. The addition of live video elements and live television signal to the display sites.
e. The creation and display of emergency messaging content.

Project Definition

I. Overview

The School of Dentistry began to investigate the replacement of its digital signage system during Q3 of 2007. The need for a wayfinding solution was also apparent. After an RFI and research, it was found that a great number of products existed that could solve both of these problems. Successful implementations of these systems were found to exist in other higher education environments, and the decision was made to investigate these possibilities further.
Like any other internetworked system, the benefits of a signage and wayfinding network increase hyperbolically as more endpoints are added. The per-user cost decreases along with the per-unit requirements for maintenance, configuration, and content creation. At the same time, brand visibility and user experience improve.
An investigation of the interest in these devices around the University, including central campus, north campus, and UMHS, revealed that many units were already investigating the purchase of products of this type.

The installation of multiple non-interoperable systems across campus would cause duplication of work and would likely preclude any sort of shared use across facilities (like emergency alerts or shared content). In the interest of avoiding this, a small group of units interested in sharing the work of purchasing and deploying a common system convened to submit an RFP for a distributed pilot.
This document describes our plans for this pilot project. We also attempt to describe the contributions that will be made by the pilot team to the Commons as a whole, through the investigation, purchase, configuration, installation, documentation, evaluation, and maintenance of this pilot system. It is our goal to make a stable and successful Digital Signage and Wayfinding infrastructure available to the whole of the University community.

The Purpose of Digital Signage and Wayfinding Systems

Wayfinding

Visitors to our facilities, whether students, parents, patients, or guests, generally have a specific destination and often need assistance finding it. One primary purpose of this system will be to assist these individuals (users) with this process.
For example, the name of a location, event, or faculty member can be entered at a touch-enabled interface, and the system will return a path to the location by displaying or printing this path on 2- or 3-dimensional maps.

Signage

All University units and departments already produce information that needs to be available to the public and to their individual communities. Digital signs will display research posters, announcements, schedules of events, and any other content which departments wish to share with their guests and their community.
In the event of an emergency, we can effectively and instantly share information about the event with our community, or provide details about action that should be taken.

The system also serves as a public relations and marketing tool, demonstrating the University’s commitment to innovation and our desire to improve the experiences of our visitors. Some portion of the digital signs’ “air time” could be devoted to U-M publicity materials.

Room Scheduling and Event Management

The system interfaces with existing scheduling tools including EMS and Exchange to provide detailed information about events, including directions to the rooms in which they are being held.

In the Future

Still more functionality is available: video and other media can be displayed, custom interactive applications can be designed, and other database interfaces can be implemented. The system can be conceived of as a matrix for any number of custom applications, and as a platform for innovation in public-facing interactive information devices.

II. Scope

Nine University units have collaborated on this project and plan to deploy the system simultaneously during the Fall 2008 semester. These units have different intentions for the functionality of this system, allowing us to assess a variety of implementations.
After policies are written, documentation is complete, and the pilot has been evaluated, we hope that the management of the server infrastructure will be assumed by a central University authority.
The scope of the pilot includes:

 The purchase, installation, and configuration of server infrastructure capable of the following functionality:

 Display of rich digital signage media

 Display of streaming media

 Wayfinding

 Directory search (integrated with wayfinding)

 Room scheduling (integrated with wayfinding)

 The installation and configuration of the content management software

 The purchase and installation of display units (LCD displays and touchscreens paired with PCs) capable of these tasks

 The education of content creators, managers, and system administrators about the use and maintenance of the system

 The development and implementation of content for each unit, including interactive applications; branding, announcement, and map resources; and some content intended to be shared across all participating facilities

 The development of best practices and policies with the intent of ensuring the sustained successful operation of the system

 The integration of the Digital Signage and Wayfinding (DS/W) server(s) with the University Online Directory (UMOD), Exchange servers, and Dean Evans EMS system

 The development of secure, scalable, and reliable internetworking between the U-M campus and UMHS, allowing the potential for further growth to include all U-M campuses

 Assessment of the pilot and the development of metrics related to the usability of the system and our users’ perceptions

 The development of documentation to facilitate further deployment and integration of this system by other units

III. Objectives and Success Criteria of the Project

The objective of this project is to satisfy all of the project requirements listed below before the conclusion of the Fall 2008 semester. For this project to be considered successful, all requirements must be met and the product must “go live” on time. Additionally, communication among the project team and testing group, focus groups, and other participants must be frequent and clear in order to permit dynamic changes to the system and error checking.

Requirements

Functionality

The system must allow:

• The schedule-based display of static high-resolution graphics and text

• The schedule-based display of Flash, Windows Media, AVI, MPEG, H.264, and other media formats

• The ability to segment a given display into multiple sections for the simultaneous display of multiple, disparate content elements and sets of elements as determined by a particular department

• The ability to provide a different set of content to each endpoint display

• The provision of interactive wayfinding, integrated with Exchange, the University of Michigan LDAP directory, and Dean Evans EMS

• That U-M staff have the ability to design and deploy interactive applications that include calls to existing databases

• That U-M may elect to contract all or part of the design of interactive applications with the supplier

Usability (for the End-User)

The system will be available to all members of the University community and to guests of the University, and must therefore be designed with the broadest possible audience in mind.
The user experience (UX) must be designed with attention to modern best practices and to usability concerns for all members of the community.

Design of all graphical resources and UX elements must be of high quality and conform to standards established by the University.
Interfaces and signage elements must attract and engage users.
These displays represent a “front-end” to the University itself and therefore must be designed with attention to the impressions of the University that will be left with the user.

Usability (for University Staff)

Interfaces to be used by those staff members who will create, manage, and deploy content must be intuitive and feature-rich. The system must allow users to create dynamic and static digital signage applications of their own design.

Reliability

While it is always the goal for systems of this kind to approach 100% uptime as closely as possible, we do not anticipate the implementation of a redundant infrastructure until the project transitions from pilot to camus-wide production status and is hosted centrally. A baseline level of availability above 95% will be the goal of the pilot team.

Performance

Content sent to the system should be available on the display computer within ten minutes.
Emergency content pushed to all displays should appear within one minute.

UX elements should be displayed as they were designed, without artifacts of scaling or rendering.
Animations and streaming content should display smoothly. Client PCs should have adequate graphics processing power to handle the content stream being sent by the server.

Supportability

The server will send e-mail and/or text message alerts to administrators if the system malfunctions.

The system should be capable of detecting problems, including nonresponsive display clients.

An external monitoring solution will alert administrators if the DS+W server is not available for more than five minutes.

All content creators, administrators, and moderators will have access to electronic versions of all documentation and manuals.

Implementation

Servers, screens, and computers are simply a mechanism to provide the real deliverable in this effort – content. In order for a system of this type to be a success, its content and applications must be attractive, useful, fresh and “sticky.” The more useful the content becomes to our users, the more effective we can consider the signs to be. Best practices and metrics used to describe and assess Web design may be used alongside signage- and wayfinding-specific criteria.

To quantify this for the purposes of making it a project success goal: content on each display must be updated, at a minimum, weekly. Ideally, the content would change, to some extent, daily.
Representatives from the Human-Computer Interaction specialization of the School of Information will provide guidance regarding the scholarship and literature around content and UX design. Decisions made through this partnership will be synthesized and provided to the supplier. We will expect the supplier’s implementation of the design to be faithful to our design and functionality intentions.
A content repository will be created. Some content will be created that is appropriate for display on all screens; “University” content. Other content will be unit-specific. Each unit will display some content from the University content set. The extent of this usage will be determined by the individual units.

Interface

This subheading describes only those displays that are touch-enabled. Each pilot unit using touch-enabled devices will use a common interface, whose development is described under the “Implementation” subheading. (Following the conclusion of the pilot, additional interfaces may be designed as needed.)

As described in the “Functionality” subheading, the interface will provide access to wayfinding and directory search. Some section of the screen will display content from the signage repository. Examples of existing interfaces which are currently in use at the University of Arkansas appear below.

Scalability

A goal of this pilot is to ease implementation by other units. We will provide a clearly documented procedure for units interested in deploying DS+W displays in their facilities.

Security

Workstations and servers will be configured according to best Windows security practices and will be monitored. To increase the security of the system, the server and clients will be connected via a system-specific VPN.

Server Hardware Considerations

A server must be purchased for the pilot that exceeds the specifications provided by the supplier and can provide content to approximately 60 clients.

Client Hardware Considerations

Client computers must be purchased which can display high-resolution graphics and video. The client computers should have processors with clock speeds of at least 2MHz, 2GB RAM, and a video card with at least 256MB RAM.

Documentation

A document describing the process of adding displays to the system will be provided to any unit interested in doing so.
A document describing the process of creating and deploying content will be prepared.

Documents assessing the success of the project, including metrics and user comments, will be prepared.

A case study for those external to the University will be prepared.

Assessment

A comprehensive evaluation of the pilot project will be conducted with the oversight of the Human-Computer Interaction specialization. Data collected from this evaluation will be submitted for publication.