June 15, 2009
Auld Lang Syne
Let me zoom out for a minute: I believe strongly in the future of universities as global education brands rather than physical campuses, towns, communities or facilities. Although we like to think we're the vanguard of technology and innovation, in a lot of ways we lag behind even the retail industry. Relying on the "one-to-many" pattern in the lecture hall is going to get us in trouble. Web culture has taught us that openness is more effective, practical, and even monetizable in many cases than old-fashioned models.
There are a couple conclusions here. First, it's our responsibility to be one hundred percent transparent with our research projects, our technological developments, and our culture in order to effectively sell the brand globally. The benefit of this is saturating underserved markets, instilling love - not respect or envy - of the institutional brand into the genius kid with an OLPC in Ghana, who will remember that relationship and then want to become part of the brand in the future.
Second, to bring this back around to something vaguely related to the project at hand - we should take every opportunity to make projects like this revolve around teaching and learning. Today's student isn't served as well in a lecture hall as she is by being part of a team whose product (even if it iterates in a year's time and looks nothing like the interface she worked on) is public and creating actual value; we could accomplish this by approaching our educational mission more like entrepreneurship than like content distribution.
Posted by dchase at 09:48 PM | Comments (0)
March 24, 2009
Now what?
We drafted an agreement with Four Winds that allowed us to install unlimited players (signs) and unlimited "content manager" installations within the pilot units.
This is when the actual hard work started - we had to make decisions about details.
First, we had to talk about the actual stuff that would be displayed on the devices. Who wants an interactive application, and what should it look like? What functionality should be in there? Do we try to prescribe a "look and feel" for the entire network, or let each group develop their own? Some of this was laid out in broad strokes within the project definition, but actually settling on these details is a complicated thing.
We had to begin preparing our individual communities for this deployment, too. For the most part, people are happy to let you do a bunch of work on their behalf, as long as you keep the progress transparent and appear to be on track to provide a high-quality product. Besides all of the tangible functionality, these systems will serve as a public "user interface" to the University as a whole - so it becomes a marketing tool, too. The devices need to say "leaders and best" before you read a word or touch a button. Who's going to create all this content? Who's going to vet the content? How and when do we train these people?
Third, our facilities needed to be prepared. Running conduit and cable is expensive. Hanging 42" touchpanels that weigh 125 pounds isn't trivial. Security, both physical and electronic, needed to be addressed.
I'll explore each of these topics in detail in the next few posts. These are the issues that have occupied us for the past six months or so, as we prepared ourselves to actually deploy this system.
Today, I got word that we actually ordered the first batch of touchpanels and the displays, as well as the mounting hardware, for the departments that don't have to do additional construction in order to deploy the product. Until this point the project's mostly been theoretical. I can't wait to get this stuff in!
Posted by dchase at 05:00 PM | Comments (0)
March 16, 2009
The Art of Thinking Independently Together
After the vendor fair, many departments contacted me, and a few who were especially interested or "shovel-ready" quickly formed a solid group of units that were prepared to seriously participate. In addition to Dentistry, the Graduate School, the School of Education, University Housing, Nursing, and the Health Center became a core group that started planning to conduct a pilot. Many other schools chose to wait in the wings and expressed that they were interested in participating later.
We collaborated on a Request for Proposal for a signage software solution and started to build a cohesive project definition as well as a project plan (see the "extended entry" below for the full text of these documents).
Also around this time, we decided to solicit the formal support of the University. After meeting with the Vice Provost, we felt as though we'd been given institutional blessing to proceed. (See the Project Definition, below the fold and below the RFP requirements, for more about what that means.)
By the end of May, we had narrowed the field to only a very few suppliers. It turned out, as a digital signage consultant told me, that "there are hundreds of solutions out there. About 50 of them are any good. About 3 of them would be good choices for you." The three finalist suppliers were invited to present on campus in June.
During this period, our collaboration with the Department of Public Safety and the Emergency Management working group became solidified. It became more and more clear that their participation would be instrumental in making this project happen.
After the on-site presentations, the choice became reasonably clear - by no means was there unanimity, but we were able to make a decision with minimal irritation. By the end of July, we had awarded the contract to Four Winds Interactive.
-
Thanks for visiting and check back often. (There's a "Syndicate this site" link around here somewhere, too.)
Interested in participating? Need digital signs in your facility? Have specific questions? Post a comment here or contact the author.
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.
Posted by dchase at 09:28 PM | Comments (0)
March 12, 2009
Coalition-building
8/13/2007:
"Lynn, I want to feel around campus to see if any parallel departments are interested in collaborating on the digital signage stuff. It could bring costs way down and make management easier in the future if we expanded this across campus, even just to a couple departments."
Our first step was to get the impressions of the "IT Commons Shared Capabilities Group," a regularly-convened group of campus IT leaders who seed this kind of collaborative action. Between this meeting and a few others, as well as some informal chats with our peers, we found that a lot of groups were at least thinking about these products; many were doing research and a few already had something deployed.
It wouldn't be practical to do this across the entire campus at once, clearly. We decided we'd try to create an agile team of facilities that would work together on a pilot, selecting and deploying a signage solution that could later scale to the rest of the University. If nobody else had to go through requests for information, contract negotiations, server installation, etc., we'd be saving tons of work and lots of money.
Lynn Johnson suggested a way to get the word out, to coalesce the pilot group, and to get an idea of what the best product might look like in the meantime: we'd hold a "trade show"-style event and invite everyone on campus that might even be peripherally interested in working on this.
In early 2008, we asked ten suppliers to visit our campus, and brought together over a hundred IT pros and facilities managers.
-
Comments and conversation are encouraged!
Thanks for visiting and check back often. (There's a "Syndicate this site" link around here somewhere, too.)
Interested in participating? Need digital signs in your facility? Have specific questions? Post a comment here or contact the author.
Posted by dchase at 08:38 PM | Comments (0)
March 10, 2009
Getting Started: Summer 2007
It didn't take much Googling to realize that there was a large and growing group of companies building signage solutions - some with proprietary hardware, some that promised interactivity, some that looked great, some that looked terrible, some that didn't bother spell-checking, and some that didn't even have any images on their websites. In July, we decided to submit a Request for Information to as many suppliers as we could quickly collect addresses for. We wound up sending the following to about 40 companies.
The University of Michigan School of Dentistry seeks a comprehensive, robust, scalable, and state-of-the-art Digital Signage solution for rapid deployment to seven locations within the School, and for possible future deployment to additional locations. This communication is an informal request for information regarding your concern’s solution for such. You were selected via Internet search to participate in this request. The replies will be assessed and a Request for Proposal will be prepared. By replying to this request, you express interest in being considered as a bidder for this contract. Replying or failing to reply to this communication will not affect the final bid process.The timeline for your reply to this request is short. We require that the information requested below be provided by 12:00 noon EST on Thursday, July 12, 2007.
I. Required functionality.
Please provide a detailed description of how your solution will fulfill these requirements:It must be possible to utilize Internet- and Intranet-based RSS content.
The capability to provide different content to different displays is required.
Multimedia content of various formats (please provide a list of available formats) must be available.
The ability to divide the display into “panes” in order to simultaneously display diverse content is required. II. Additionally, please provide the following in your reply:
A detailed end-to-end description of the content delivery system.
Any available diagrams, white papers, case studies, and multimedia demonstrations.
Because of the nature of this deployment, it is impractical to run additional cable to each display. We do, however, have LAN-connected wireless access points at each location. Please provide a detailed description of a method in which to stream your solution’s signage content over the LAN and transmit it to the display locations wirelessly. III. Provide any additional information that may assist the School in selecting a Digital Signage solution, including functionality and advantages not explicitly mentioned in this Request, and suggestions regarding ways in which your solution could be used in research, graduate and postgraduate educational environments.
IV. If possible, provide a proposal for an on-site and/or Web-based demonstration of your solution.
It's pretty naïve, in retrospect. Doesn't even mention interactivity and wayfinding, which would later become centerpieces of the project. And at this point, we were just beginning to consider working with other campus facilities. In August, we started talking within Dental Informatics about presenting our thoughts about the benefits of interoperable, campus-wide digital signage to the campus IT community. We envisioned the two possible paths that signage solutions might take at the University:
1. Every department separately researches and buys a signage solution.
If we assume for the sake of argument that half of the facilities in Ann Arbor want digital signs, and that half of those wind up purchasing different products, that's over 100 installed signage systems on the Ann Arbor campus alone.
100 groups separately installing and configuring servers, separately researching what the best solution might be, separately learning separate software packages, separately deploying player PCs with different configurations. 100 siloed installations, with 100 separate sets of content that can't be shared, and 100 separate interfaces for Public Safety to implement for emergency messaging.
This prospect is pretty terrifying, especially from an IT pro's point of view.
But surely everyone doesn't need the same functionality!
This is probably the most compelling argument against collaborating on this project, so it was our job to find a solution flexible enough to fit as many sets of desires as possible. We had to keep in mind that everyone's needs are different.
2. Get a single (or very small number of) solution(s) for deployment across the entire campus.
This sounds kind of crazy too, at first, especially in a strongly decentralized environment, where every school and college has its own IT staff, and its own editorial board, and its own administration, who all have opinions about what "digital signs" are and should be. But in the interest of providing the greatest benefit to the community in the long run, it was well worth it to at least shoot for this type of outcome.
-
Comments and conversation are encouraged!
Thanks for visiting and check back often. (There's a "syndicate this site" link around here somewhere, too.)
Interested in participating? Need digital signs in your facility? Have specific questions? Post a comment here or contact the author.
Posted by dchase at 03:25 PM | Comments (0)
March 09, 2009
"80% of Success Is Showing Up"
On June 6, 2007, we started out saying, "let's replace these beastly 30-year-old TVs." Now we're busy trying to implement interactive digital signage and wayfinding uniformly across the entire University, including all three campuses.
I think they call it "scope creep."
It was irresistible, though, once we'd developed a sense of what the potential outcomes might be if we resisted working together. In the next few posts, I'll summarize what's been done since that first e-mail was sent. We'll also talk more generally about interdisciplinary collaboration and its benefits. Eventually, I'll catch up to the present day and keep you updated with the project as we roll it out.
-
Comments and conversation are encouraged!
Thanks for visiting and check back often. (There's a "syndicate this site" link around here somewhere, too.)
Interested in participating? Need digital signs in your facility? Have specific questions? Post a comment here or contact the author.
Posted by dchase at 12:38 PM | Comments (0)
March 08, 2009
What's "Digital Signage" and Why Are You Writing About It?
When we started this project, we thought "digital signage" was equivalent to "PowerPoint presentations on TVs in lobbies." It turns out that there are hundreds of commercial solutions out there, from warmed-over PowerPoint to ultra-shiny and sophisticated interactive signage applications.
If you're interested, start by reading the Wikipedia article on Digital Signage. It's pretty good, although it concentrates mostly on retail and commercial applications for the technology, and doesn't answer a lot of the questions that come up when talking about signage for higher education. For example, it doesn't include anything about wayfinding, or about emergency messaging. I guess I should fix it. For now, though, I'm just going to expand on it here.
"Static Signage"
This is what you've seen around, like at the grocery store or at the mall - a monitor, divided into "regions," with different kinds of stuff in each region (announcements, advertisements, the weather, a stock ticker, or event calendars).
Interactive Wayfinding
Some signage solutions allow you or the supplier to design and build interactive applications - much like a simple Web application. These could be built to do just about anything a Web app can do, but most of these are designed to let you look things up in a directory and show you maps.
One of the main problems we encounter in our public spaces is that we have guests, new students, patients, visitors, and conference attendees, and these people have never been here before, and they get lost. "Analog" signs work sometimes. What if we had a network of touch-enabled screens on campus where people could look up what they wanted and be guided there?
Emergency Messaging
Recent tragedies on university campuses make the need for emergency messaging clear, and there's always the potential for natural disasters about which the community needs to be notified. Having multiple vectors to distribute emergency messages is a necessity. We can use e-mail or SMS messages, but the SMS protocol is less than reliable, and people in public spaces aren't all checking their e-mail. Digital signs prove to be a very effective way of disseminating this kind of information in the event of an emergency.
___
It's important to us to be able to share the lessons we've learned in the last year and a half, because there are a lot of them, and we want to help other campus communities make the right decisions. We've been really happy to receive communication from a bunch of other institutions already. Get in touch!
Administrivia: this blog will be displayed in forward-chronological order until I'm done with the history part, and then I'll flip it when it becomes more of a traditional blog kind of a thing.
___
Comments and conversation are encouraged!
Thanks for visiting and check back often. (There's a "syndicate this site" link around here somewhere, too.)
Interested in participating? Need digital signs in your facility? Have specific questions? Post a comment here or contact the author.
Posted by dchase at 08:09 PM | Comments (1)