Digital screen for appointments and employees

(1)

Digital screen for

appointments and employees

Anton Berglund

January 31, 2014

Master's Thesis in Interaction Design, 30 credits

Supervisor at TFE-UmU: Kalle Prorok

Examiner: Håkan Gulliksson

Umeå University

Department of Applied Physics and

Electronics

SE-901 87 Umeå

Sweden

(2)

Abstract

With a digital screen a company can provide a simple way to inform its em-ployees and visitors about what is going on at the oce. The company Knowit AB wished to be able to display upcoming events through such a digital screen. This thesis describes how a solution was designed and implemented to suit the needs of the company.

By using the design process a web based solution was built able to display events retrieved from the company's Exchange server on a digital screen. The solution was also built as a web site, making it accessible from outside the oce so that employees can look up information on the go. The resulting solution is going to be installed in Knowit's oce in Umeå, with a future vision of installing it in several other Knowit oces.

(3)

List of Figures

1.1 Knowit Logo . . . 6

1.2 Knowit Color Scheme . . . 7

2.1 Modied waterfall model with iterative steps. . . 10

3.1 Raspberry Pi . . . 13 3.2 Mockup 1 . . . 14 3.3 Mockup 2 . . . 15 3.4 Mockup 3 . . . 15 3.5 Mockup 4 . . . 16 3.6 Mockup 5 . . . 16 3.7 Mockup 6 . . . 17 3.8 Mockup 7 . . . 17 3.9 Mockup 8 . . . 18 3.10 Mockup 9 . . . 18 3.11 Mockup 10 . . . 19 3.12 Mockup 11 . . . 19 3.13 Mockup 12 . . . 20 3.14 Mockup 13 . . . 20 3.15 Mockup 14 . . . 21 3.16 Mockup 15 . . . 21 3.17 Mockup 16 . . . 22 3.18 Mockup 17 . . . 22 3.19 Mockup 18 . . . 23

4.1 Structure of the solution . . . 28

4.2 Tables in the MySQL-database . . . 30

4.3 Site Map of the solution . . . 31

4.4 Layout of the Master Page . . . 31

4.5 Background images . . . 33

4.6 Comparing two fonts . . . 34

5.1 Screenshot: The Login Page . . . 36

5.2 Screenshot: The Create User Page . . . 38

5.3 Screenshot: The Home Page for Umeå . . . 39

5.4 Screenshot: The Home Page for Sundsvall . . . 40

5.5 Screenshot: The Event Page . . . 42

5.6 Screenshot: The People Page . . . 43 3

(6)

LIST OF FIGURES 4

5.7 Screenshot: The Employee Page . . . 44

5.8 Screenshot: The Edit Prole Page . . . 46

5.9 Screenshot: The Administration Page . . . 47

5.10 Screenshot: The Create Event Page . . . 49

5.11 Screenshot: The Super Admin Page . . . 50

5.12 Screenshot: The Calendar view of the Digital Screen in vertical mode . . . 52

5.13 Screenshot: The Employee view of the Digital Screen in vertical mode . . . 53

5.14 Screenshot: The Calendar view of the Digital Screen in horizontal mode . . . 54

5.15 Screenshot: The Employee view of the Digital Screen in horizon-tal mode . . . 54

5.16 Screenshot:Mobile interface menu . . . 55

5.17 Screenshot: Mobile interface oce menu . . . 56

5.18 Screenshot: Mobile interface Home page . . . 56

5.19 Screenshot: Mobile interface Event page . . . 57

5.20 Screenshot: Mobile interface Edit Prole page . . . 58

5.21 Screenshot: Mobile interface Create Event . . . 58

5.22 Screenshot: Date picker on the Create Event page . . . 59

5.23 Screenshot: Mobile interface Administration page . . . 59

5.24 Screenshot: Mobile interface People page . . . 60

5.25 Screenshot: Mobile interface Employee page . . . 61

5.26 Screenshot: Mobile interface Login page . . . 61

(7)

Chapter 1

Introduction

In larger companies informing employees of upcoming meetings, events or visits from customers can be a hazel. While it is common for large companies to use organizing software such as Microsoft's Outlook to keep track of schedules, these types of software are perhaps not the optimal way to highlight current important events, e.g. if some very important customer will be visiting the oce during the day. They are also useless for people visiting the company, since the visitors do not have access to the companies schedule software.

Many companies solves this problem by displaying important information on digital screens in e.g. the oce entrance or the cafeteria, or both. This kind of digital screens are often used to display announcements, or show visitors which employees that work in the oce. A number of software aimed for displaying information of various sorts on digital screens exists on the market[1].

This thesis will address how such software, or rather system, could be im-plemented for a specic company, namely Knowit Norrland AB and its oce in Umeå. It will describe the steps necessary for designing such a product and discuss how the system can be extended to provide further gain for the company.

1.1 Knowit AB

Knowit AB is one of the largest IT-consulting rms in Scandinavia with about 1800 employees in six countries1_{. The company is divided into a number of}

smaller subsidiaries, with Knowit Norrland being one of them. Knowit Norrland have oces in Luleå, Umeå, Örnsköldsvik and Sundsvall. This thesis was made on behalf of Urban Holmgren, chief executive ocer of the Umeå oce.

Since Knowit is such a big company and specializing in IT-consulting, they were in need of an modern solution for displaying upcoming meetings and events for booth their employees and their visitors. In Umeå they have employed an analogue solution for a number of years consisting of a whiteboard where employees can write today's events if they like. Such a solution seems untting for a company involved with developing IT-solutions.

A more modern solution was needed, one that would be up to date automat-ically and without needing the direct involvement from the employees or the employer.

1_{Retrieved on 2013-10-04 from http://www.knowitgroup.com/sv/Om-oss/}

(8)

CHAPTER 1. INTRODUCTION 6 Since the solution should be made for Knowit using their prole colors and forms was a demand made by the client. Figure 1.1 shows the logo used by Knowit in their most used color. Figure 1.2 shows the color palette they use.

1.2 Concepts

This thesis will use concepts such as: • Knowit Infoscreen:

The suggested name of the implemented system. • Digital Screen:

A digital screen can be a lot of things, mostly referring to a TV or computer screen. In this thesis, however, the term digital screen refers to part of the system that will be displayed on a digital screen. In other words, the part of the system that will be visible for employees and visitors in the oce entrance or wherever the digital screen is placed.

• Web Interface:

The web interface refers to the part of the system accessible from a web browser, allowing employees to use the system without having to look at the digital screen. The web interface allows for much more interaction than the digital screen.

(9)

CHAPTER 1. INTRODUCTION 7

(10)

Chapter 2

Background

Knowit Norrland AB have been thinking of developing a digital welcome screen for employees and visitors for a couple of years. This thesis is based on two earlier projects that also tried to create a solution to the problem of developing a digital screen.

2.1 Problem Description

Today Knowit Norrland have no solution at all for displaying important infor-mation to employees and visitors. Earlier a billboard was used to manually put up notes if some important event was happening that the employees needs to know about. There does not exist and have never existed a digital solution, although the idea for a digital solution has been in the works for a couple of years. The idea has been researched and a small implementation based on the idea was made, but not developed into something that would work as a real solution.

A new solution based upon the research and the implementation is needed to create a functioning system for displaying events and information to employees and visitors. The solution should not rely too heavily upon previous done work, only use it as a guide for how the solution could be implemented. The solution should meet the demands of the client, in this case Knowit Norrland AB, but also meet the demands of the users.

Thus this thesis should produce a working solution, implemented in a way that best meets the demands placed by the client and users, as well as a written report describing the solution and the process of developing it.

2.2 Goal

The goal of this thesis was to create a working solution for displaying events and information on both a physical screen and on a web interface. The system should be customized to meet the needs of Knowit Norrland AB, meaning that it should have the look and feel of the company as well as the appropriate functionality. The functionality in this case included being able to display events present in the shared Outlook calendars that the company uses for booking e.g. conference rooms.

(11)

CHAPTER 2. BACKGROUND 9 The second goal is to describe the solution and the process of developing it in a written report, namely this thesis.

2.3 Methods

This thesis and the solution belonging to it was structured as a project using the design process. Using a project plan document the project was structured in three main phases, these phases being:

Before the Project: The project plan document should be created includ-ing a time schedule and a list of thinclud-ings do be done. Research of previous work should be done, as well as research on the environment in which the system will operate. Necessary hardware, such as the Raspberry Pi, should be acquired. During the Project: The project was structured after a model of the de-sign process, as shown in Figure 2.1. It consist of six steps, where step 3 and 4 represents the iterative part of the process. In parallel with the design process a report, this thesis, was written.

1. The rst step was the exploratory, nding out the clients requests, study-ing the previously done work and creatstudy-ing a list of specications and de-mands.

2. The second step was to brainstorm for ideas and suggestions for functions and design.

3. The third step, and the rst iterative step, was making a design for both the functions of the system and the look of the system. The design was then evaluated with user tests and then remade with the results from the evaluation.

4. The fourth step was implementing the design and then evaluating the implementation with user tests, and using the information from the evalu-ation to improve the implementevalu-ation. This step is repeated as many times as needed.

5. The nal product is delivered to the client.

After the Project: After the project a written report, this thesis, should be handed to the university and a nished solution should be handed to the client. A oral presentation of the work that has been done should also be hold at the university.

During all of these phases a log, in the form of a blog, should be kept to docu-ment the work and allow people to follow the work process.

2.4 Previous Work

As mentioned earlier the project has been in progress two times before. First the project idea was given to a group of students from Umeå University, more specically to students from the computer scientist program during the spring

(12)

CHAPTER 2. BACKGROUND 10

(13)

CHAPTER 2. BACKGROUND 11 of 2012. Second, an attempt to implement the idea was done by Peter Viberg, an employee at Knowit's oce in Örnsköldsvik.

The work of the students resulted in a report that included a specication for demands, an analysis of similar solutions, simple suggestions for how the prototype would work and look, and suggestions for future work[1]. It did not include any implementation, although implementation is implied as a natural extension of their project.

Other suggestions made for future work included creating a system to keep track of the employees' comings and goings at the oce (an attendee system) and some kind of presentation of the company that could be visible on the digital screen[1]. More information from the report was used in the exploratory.

The work of Peter Viberg included a more detailed description on how the system structure could be implemented as well as the beginning of an implemen-tation using ASP.NET and C# [2]. Parts of this code was used to get started with this project.

(14)

Chapter 3

Design Process

In developing the digital screen for appointments and visitors the design pro-cess was used, beginning with an exploratory and gathering of information and ending with an implementation and testing of the implementation.

3.1 Exploratory

Information needed for the project was collected, primarily from the client, to know the needs for the nished product. More information on how to do the implementation was collected from Peter Viberg, who previously worked on the project. The previous work done by the students of the computer scientist program was also used in the exploratory.

According to the studies of Selin et al. the digital screen for appointments and visitors should be platform independent to increase availability, simple to use and only accessible for employees at Knowit[1].

Similar solutions to the digital screen for appointments and visitors include DISE (Digital Signage)1_{, a system for distributing information to information}

screens through the Internet. The system is used by Umeå University to provide information to screens around campus. It can be used to display images, videos, web sites etc. on an unlimited number of screens around the world[1].

Another similar solution is Smartsign Manager2_{that can be used to control}

a large number of screens and schedule information that should be displayed on them[1]. While both DISE and Smartsign Manager are non-open source and needs to be bought, Concert3 _{is an open-soruce solution that oers similar}

functionality but is free and since the source code is open, adaptable for the user's needs[1].

For hardware Selin et al. suggests to use Philips BDL 3245E4_{or NEC V321}5

for the display, because they are built for being used twenty-four hours a day and still have a lifespan of 40 000 to 50 000 hours[1]. For the computer that

1_{http://www.dise.com/} 2_{http://www.smartsign.se/} 3_{http://www.concerto-signage.org/} 4_{http://www.p4c.philips.com/cgi-bin/dcbint/cpindex.pl?slg=sv&scy=se&ctn=} BDL3245E/00 5_{http://www.necdisplay.com/p/large--screen-displays/v321-2?type=support} 12

(15)

CHAPTER 3. DESIGN PROCESS 13 would be connected to the display Selin et al. suggest using a Raspberry Pi6_[1].

The Raspberry Pi functions like a miniature computer running a version of Debian/Linux called Rasbian. It is capable of performing simple tasks such as displaying websites. It has become increasingly popular in later time[3], and a schematic of how it looks is displayed in Figure 3.1.

Figure 3.1: Structure of the mini computer Raspberry Pi. It measures only 86 mm x 56 mm x 21 mm.a

a_{http://www.raspberrypi.org/faqs}

3.2 Brainstorming

The brainstorming part of the design process is important for creativity and innovation in the solution, but hard to do by yourself since you do not have anyone to exchange ideas with. Because of that the brainstorming for this project was brief and did not yield any extravagant ideas for how the solution could be implemented. Instead a few ideas was drawn to give a sense of how the solution could work and look.

(16)

CHAPTER 3. DESIGN PROCESS 14

3.3 Mockups

Some of the drawings from the brainstorming was chosen and made into real mockups by using the tool Balsamiq Mockups7_{. Figure 3.2-3.6 shows dierent}

suggestion of the layout and look of the digital screen.

Figure 3.7-3.10 shows how the web interface could look like. These are the only mockups done on the web interface since it was a secondary part of the solution, but it come to include more pages than shown in the mockups. The mockups display only two pages, the startpage and the page for displaying employee information.

Figure 3.11-3.19 are more advanced mockups created with Adobe Illustrator. Since the previous mockups mostly dealt with the placement of elements, these mockups suggest how the elements could look like, what colors could be used and what fonts could be used. No such mockups were done on the web interface, only on the part that will be displayed on the digital screen.

Figure 3.2: Simple layout showing upcoming appointments, including descriptions of the appointments and participants. The appointments are simply listed in order of occurrence.

3.4 First User Tests

The rst user tests were made with the help of the mockups represented by Figure 3.7-3.19 and was done at Knowit's oce in Umeå among the employees who work there. Six employees participated in the tests, enough to get a sense of which mockup should be developed further. Each participant was at rst presented to the more advanced mockups for the digital screen, represented by

(17)

Figure 3.3: Appointments are places in boxes to clarify what information belongs to what appointment.

Figure 3.4: Same as in Figure 3.2 but dedicating a part of the screen to showing a slide of employees.

(18)

Figure 3.5: Same as Figure 3.3 but ordering the boxes vertical instead of horizontal, giving room for more information and clarifying the order of occurrence.

(19)

Figure 3.7: Suggestion for the start page when accessing the solution through a web browser. Divided into one calendar part and another part showing the employees in the current oce. Each employee can be clicked and thus redirecting the user to an information page about the employee, see Figure 3.10.

Figure 3.8: Instead of dividing the calendar and the employees on the same page it is divided into two pages, this one showing only the calendar and a button for navigating to the employees. Note that only the calendar for the currently selected oce is displayed.

(20)

Figure 3.9: Shows the employees of the current oce, and a navigation button for switching to the calendar view. As with Figure 3.7 clicking on an employee brings the user to an information page, see Figure 3.10.

Figure 3.10: A page displaying information about an employee, such as contact information but also the current status of the employee.

(21)

Figure 3.11: A more advanced look to the layout in Figure 3.2 but only showing the events for the one day. Faded background displaying the city of the current oce.

(22)

Figure 3.13: Displaying the events of one day, and using backdrops for the event titles to improve readability.

Figure 3.14: Same as Figure 3.13 but without the backdrops and with larger titles instead.

(23)

Figure 3.15: Same as Figure 3.13 but with all backdrops the same width to give a more unied look.

Figure 3.16: Simplied header with no backdrop, more in line with the company im-age. Showing appointments for the whole week placed in rows with partly transparent backdrops to improve readability. This was the most well received design suggestion during the user tests.

(24)

Figure 3.17: Same header as in Figure 3.16 but dropping the backdrops and using larger titles instead.

Figure 3.18: An alternative page showing the employees of the current oce. Switch-ing between this page and the calendar is possible with a timer function, or if the calendar includes sensitive information this page could be displayed instead when a costumer visits the oce.

(25)

Figure 3.19: A bit like Figure 3.12 but with dierent header and some elements moved.

Figure 3.11-3.19. They were then asked to answer some questions regarding them. The questions were:

1. Would you like the screen to display only the events for today or for the whole week?

2. Which suggestion do you nd most suitable and why?

3. Is there some information you are missing that you think should be in-cluded?

4. Is it important to be able to see the participants of an appointment? 5. Would you like to be able to see what appointments occurs in other oces? Summing up the answers from each test person the most common answers to these questions where:

1. Viewing the whole week is preferable to viewing only one day.

2. Figure 3.16 is the look liked by most users because it is easier to understand than any other without losing its style.

3. The name of the organizer should be visible, the organizer being the person that created the appointment.

4. It is good to be able to see the participants of an appointment, but it is not necessary and should be a secondary function.

(26)

CHAPTER 3. DESIGN PROCESS 24 Dierent questions were asked regarding Figure 3.7-3.10 that represents the web interface. These questions were:

1. Would you like to be able to see what your colleges are working with or where they are working?

2. Would you be willing to update your own status for others to see? The answers to these two questions were similar for all participants. The most common answers were thus:

1. It would be very interesting to be able to view what other employees work with and where they are currently working, or just if they are available or not.

2. Few would be willing to manually update their status, thus rendering the system redundant.

From these results the design in Figure 3.16 was used for the prototype, but with a lot of changes taken from other mockups and also from input from the participants.

3.5 Prototype

A prototype was implemented using Visual Studio 2012 and coded in C# and .Net and also HTML, CSS and JavaScript. The prototype was developed to become a nished product ready to be delivered to the client, but remained only a prototype until all user tests and debugging was done. Implementing the prototype included the actual coding of the website that will be running on Knowit's servers and then displayed on the screen in the oce entrance.

It also included setting up the server and the appropriate database for the website, as well as setting up the actual physical screen and the Raspberry Pi connected to it.

3.6 Second User Tests

The second user test was made with the working prototype. The test subjects could use the prototype by navigating to a certain URL where the prototype was hosted. The test subjects were employees on Knowit in Umeå. Seven people participated in the test, most of them earlier participants in the previous test, meaning that they had prior knowledge of the project and its purpose.

The test was divided into three parts. The rst part was a practical exercise where the test subjects should use the prototype to solve a series of tasks. In the second part the test subjects were asked some questions about the prototype. The nal part of the test included more questions, but about the digital screen instead of the web interface.

In the rst part of the test each test subject were given a short list of tasks to perform using the prototype website. While doing the tasks they were encour-aged to describe how they would execute each task and what (if any) problems they ran into. The tasks were:

(27)

CHAPTER 3. DESIGN PROCESS 25 1. Login to the site.

2. Check the status of a fellow employee. 3. Check the calendar for the user's own oce. 4. Check the calendar of another oce. 5. Update the user's own status. 6. Update the user's password. 7. Create a new event.

8. Remove the event just created. 9. Log out from the site.

The test showed that most test subjects had no trouble logging in on the site and also no trouble nding another employees status, however, some subjects found it unclear what the status was. No one had any trouble checking the calendar for their own oce, although almost all subjects complained about the loading time for the site. Navigating between two oces turned to be a bit troublesome for some subjects, not understanding that the links for the calendar and the employees changes depending on what the current oce is.

A few had trouble nding where to update their own status, believing it would be somewhere around where you checked the status of other employees. Also, about half of the test subjects did not immediately understand how the edit buttons, or the save and cancel buttons on the edit prole page, worked. Updating the password was also confusing for some, since there were two boxes for updating the password. Some believed that entering the existing password was necessary, when in fact the new password should be entered twice to conrm that the user did not spell it wrong.

The most troublesome task was to create a new event. Most test subjects had no problem actually creating the event, the real trouble was nding where to do it. Most started out in the calendar page believing that some button would be found there. It took a while for most to nd the button in the administration page.

The hardest part about creating a new event, besides from nding where to do it, was to add participants to the event. Although explained how it works most test subjects still wanted to only write in the names of the participants, not their e-mail addresses. Suggestions were given that participants should be possible to select from a list of employees, thus improving the user friendliness of the page.

After creating the event many test subjects noticed that the event did not immediately show up in the calendar page. This occurs because the calendar page is saved in the browsers cache and only updating every ten minutes (to speed up the page and not call on the Exchange Web Services with every refresh of the page). Feedback that the event was created is given in the administration page, but most test subjects missed this and wanted the changes to show directly on the calendar page.

Removing the newly created event and logging o from the site was not something any test subject had any problem with.

(28)

CHAPTER 3. DESIGN PROCESS 26 After the exercise the test subjects were asked two questions about the web interface, namely:

1. Is some information missing or unnecessary? 2. How was the functionality of the web site? The most common answers to these questions were:

1. No information is missing, but for some events too much information is displayed. Full information about an event could instead be displayed in a separate page which should be accessible from clicking the events in the calendar. The status is an interesting function, but perhaps not necessary, and it should also be visible directly on the employee page. Titles and locations for the events should be more relevant.

2. The web site is slow but the functionality is otherwise good, not too much features and not too few.

After this the test subjects were shown the digital screen as displayed on an actual screen that later could be used in the oce entrance. The application for the digital screen diers from the web interface since it does not require any interaction from the users. Thus it was only displayed for the test subjects, in the display mode that switches the calendar view and the employee view. Each test subject were then asked for questions, namely:

1. Should the display be vertical or horizontal? 2. How is the readability?

3. Is some information missing? 4. How is the deign experience?

The most common answers to these questions were: 1. The screen should be vertical.

2. The readability is good but could be improved with larger font size and larger images of the employees.

3. Status for the employees could be added, as could the number of the current week and the current weather, but none of this is really necessary. Displaying the name of the oce is unnecessary since the digital screen will hang in the oce itself.

4. Clean and nice looking design, but could be improved with larger images for the participants for the events and perhaps smaller images for employ-ees on the employee page.

The results of these tests were used to improve the prototype before declaring it a nished product.

(29)

Chapter 4

Implementation

4.1 Platform

The solution was implemented as a website to make it accessible for all of Knowit's employees, since a standalone program would only be accessible on the computer running it. The implementation was done using Visual Studio 2012 on a computer running Windows 8. It was coded in ASP.NET optimized for web using C# in the code behind les. The website was made to run on a .NET-server.

4.2 Setup

The physical digital screen is a at TV hooked up to a Raspberry Pi. The Raspberry Pi is a small computer running Linux and congured to run and display a webpage in full screen on startup, following the guide provided by Iglesias et al.[4]. The Raspberry Pi is able to connect to the Internet through either a LAN-cable or, in this case, through a wireless adapter, thus able to connect to the server running the actual website.

The website is placed on a server provided by Knowit. The same server is also running the MySQL-database. The website can then be accessed by anyone with an Internet connection by navigating to http://kit-meetings.vidvinkel.se but for anyone not logged in no information about Knowit will be displayed. Login is required to view the information on the website. The ability to save ones login through a cookie eliminates the need to login multiple times on the same computer.

The website is design for three types of screens. One is for the digital screen that will be seen in the entrance of the oce, another is for desktop computer screens and the third is for mobile devices such as smart phones.

The structure is displayed in Figure 4.1. As shown the web server is con-nected to the MySQL-database and to the Exchange Server through the Ex-change Web Services. The web site stored on the web server can be displayed on a digital screen using e.g. a Raspberry Pi or it can be displayed on a computer or a smartphone with access to the Internet. The users can administer data ei-ther through the web interface or through Microsoft Oce Outlook, which is in turn connected to the Exchange Server.

(30)

CHAPTER 4. IMPLEMENTATION 28

Figure 4.1: Simple map of the solution and how dierent parts connect to each other.

4.3 Exchange Web Services

To limit the eort needed to keep the information on the digital screen up to date and relevant it had to be able to connect to an Exchange server. The employees of Knowit uses Outlook for managing their emails and their calendars, and Outlook in turn uses Exchange servers to store the information and keep it synced between users. By accessing the Exchange server one is able to read and alter information regarding calendars, calendar events, emails, contacts and more.

Getting access to the Exchange server is pretty straight forward using Ex-change Web Services (hereafter abbreviated as EWS)1_{, an extension provided}

by Microsoft that can easily be added to Visual Studio using the Nutget Package Manager. By adding the namespace

using Microsoft.Exchange.WebServices.Data;

to the code behind it is possible to call the methods provided by the EWS. Authentication is necessary for retrieving and manipulation data through the EWS. In the digital screen the EWS is used to retrieve data from calendars, and thus it is necessary to have authentication information for each calendar that should be displayed. Authentication can be done in two dierent ways. If the URL to the Exchange server is known it can be called directly using: ExchangeService service = new ExchangeService(ExchangeVersion.

(31)

CHAPTER 4. IMPLEMENTATION 29 Exchange2010_SP1);

service.Credentials = new WebCredentials("username","password", "domain");

service.Url = new System.Uri("https://yourdomain/EWS/Exchange. asmx");

If the URL is unknown another method is needed:

ExchangeService service = new ExchangeService(ExchangeVersion. Exchange2010_SP1);

service.Credentials = new WebCredentials("username","password"); service.AutodiscoverUrl("username",

RedirectionUrlValidationCallback);

This method is much slower than the rst method, taking as much as ten times longer. Thus the rst method was used. However, it should be noted that none of the methods are fast, the faster of them taking up to ten seconds to load.

The Exchange Server are structured in folders for each user, so to nd ap-pointments the calendar folder needs to be searched, and to nd contacts the contacts folder needs to be searched. The long loading time is caused by the large number of items in these folders[5].

The EWS comes with classes that handles appointments and contacts, and also attendees to an appointment. Getting the appointments for the coming week from a calendar can be done using:

FindItemsResults<Appointment> foundAppointments = service.FindAppointments(WellKnownFolderName.Calendar , new CalendarView(DateTime.Now, DateTime.Now.AddDays(7)));

Getting the attendees of an appointment requires the appointment being bound to the EWS, as shown by:

Appointment temp_appointment = Appointment.Bind(service, appointment.Id);

AttendeeCollection attendeecollection = temp_appointment. RequiredAttendees;

AttendeeCollection attendeecollection_2 = temp_appointment. OptionalAttendees;

Getting contact information is similar to getting appointments from a calendar, but using a dierent folder.

4.4 Database

Since all information necessary to make the digital screen work could not be retrieved or stored on the Exchange server a MySQL-database was used. The MySQL-database was necessary to make it possible to add events that maybe did not belong to any available calendar. A prime example being a planned visit by some customer when no special room is to be used, on what calendar would the event go then? Another example is if some bigger event is planned, like a team building day. Such events would then be stored in the MySQL-database instead of on the Exchange server.

(32)

Figure 4.2: The four tables and their columns in the MySQL-database used for the solution.

The MySQL-database that was used contained four tables, as shown in Fig-ure 4.2. The Calendar table is used to store authentication information for the calendars that will be displayed on both the digital screen and in the web inter-face. The program also uses this table to know which calendars to display for which oce.

The People table is used to store information about employees, since not all of the information needed to display information about an employee (such as status and description) could be retrieved from EWS. This table also stores the users login information, making it much faster to login than if the user would have to authenticate themselves through EWS every time they login to the site. The Event table is used to store manually added events, events that cannot be created through Outlook since it does not belong to any particular calendar. Lastly the Settings table is used to store the settings for each oce's digital screen. It contains the URL to the background image. It also contains the settings for the display mode, if the display should show the calendar only, employees only or switch between them and if so the number of seconds between each switch.

The data in the database can be modied from the web interface, but also directly through a web interface provided by MySQL called phpmyadmin which is accessible from the Internet provided one has the correct database address, username and password.

4.5 Structure

The implementation is divided in two main parts, one part that is visible only on the digital screen and one part that is visible in the web interface. The part visible on the digital screen consists of only one page, since no interaction is possible with this part, while the web interface part is larger, including the pages visible in Figure 4.3.

The web interface part uses a Master Page to provide a unied look and navigation structure along the entire site. The dierent parts of the Master Page is visible in Figure 4.4. The top navigation bar is for switching the current oce. The left navigation menu is for navigating the dierent pages of the site. The part in the content placeholder is the part that changes with dierent pages, while the navigation parts remains the same.

To access any part of the implementation a user have to login using previ-ously acquired credentials. Logging in is done on the Login page. Attempting

(33)

Figure 4.3: Site Map of the solution, displaying the dierent pages of the site. Only the Login page is accessible without being logged in, as marked by the lock symbols.

Figure 4.4: The Master Page of the site, with content from the Home page when the current oce is Umeå. The square marked as Content Placeholder is the part that changes when switching pages, while the squares marked Navigation is visible from all pages.

(34)

CHAPTER 4. IMPLEMENTATION 32 to access any other part of the site without being logged in will result in a redirection to the Login page. If it is the rst time for a user to login a default username and password will be used, in this case the users company e-mail and password. First time users will be redirected to the Create User page, otherwise the users will be redirected to the Home page.

The Create User page is a single page allowing a new user to create an account. When done the user will be redirected to the Home page. It should be noted that only employees at Knowit that have a functioning Knowit e-mail account are able to create accounts on the site.

The Home page is the main part of the site, displaying the calendar of the current oce. It is a dynamic page that changes content depending on which oce is the current oce. The Home page can be considered the start page for each oce, since it is the page the user is navigated to when switching oce.

The People page displays the employees of the current oce, and is thus dynamical and changes depending on which oce is the current one. Each employee is a link to the Employee page, which is also dynamical and displays information about the currently selected employee. If the currently selected employee is the user a link to edit the users prole will appear.

The Edit Prole page is thus accessible from the main navigation menu and from the Employee page. It allows the user to edit their prole information. The Administration page is only accessible from the navigation menu and only if the active user have administration privileges. The Administration page allows changing the settings for the digital screen and adding or removing calendars and events.

The Create Event page is a dynamic page, used both for creating new events and editing existing events. It is accessible from the Administration page as well as from the Home page of each oce. However, only new events can be created from the Home page. It is also accessible from the Event page, if the event was created manually.

The Event page displays additional information about an event that is not displayed directly in the calendar. If the currently selected event was created manually, and not imported from Exchange, it includes a link for editing the current event.

The part of the site that is displayed on the digital screen include only one dynamic page, namely the Screen page. The Screen page uses the settings given by settings stored in the database and can dynamically change to display only the calendar of the current oce, only the employees of the current oce or switch between both views on a xed time interval. No user interaction is possible on the Screen page.

4.6 Design

4.6.1 Background

Having large background images on a website is trendy in modern web design[6] since it helps catch the viewers eyes and makes it more living then what a one coloured background would have. Because large images were chosen as the background for the site, each oce having their own background images, where the image itself displays the city in which the oce is located. To prevent the

(35)

CHAPTER 4. IMPLEMENTATION 33 background images from taking over and obscuring the content of the page, they were made very transparent and also in Grayscale. Four images were used, shown in Figure 4.5. All images were free to use provided that the copyright holder were attributed.

Figure 4.5: The four images used for the background of the dierent oces.

4.6.2 Fonts

Resulting from the rst user tests, the font called "Champagne & Limousines"2

were the favourite font among the test persons. But not only is the font not a free font (at least not for commercial use) it is also not among the web safe fonts3_,

meaning that not all browser supports it. Because of that the font "Century Gothic" was chosen instead, since it was the one among the web safe fonts that was most similar to "Champagne & Limousines". A comparison of the two can be seen in Figure 4.6. The font is used on the entire site, except in text-boxes where simple "Arial" is used instead.

4.6.3 Color

The colors used were chosen primarily from the color palette shown in Figure 1.2. These colors were used since one of the demands on the solution was that it should follow the graphical prole of the company.

Of the primary colors only white was not used, while the black color was used for much of the text and the turquoise color was used for all the elements

2_{http://www.dafont.com/champagne-limousines.font} 3_{http://cssfontstack.com/}

(36)

Figure 4.6: Comparing the fonts "Century Gothic" and "Champagne & Limousines".

that needed to stand out e.g. the headings, event blocks, links etc. For the background as well as some text that did not need to be as readable as the black text, the grey color from the secondary colors was used. The additional red color was used for all the error messages.

The turquoise color was used as the primary color around which the other colors were selected, mainly because it is the primary color used by the company since the color represents wisdom end renewal[7]. The gray color was chosen as a complement to the turquoise color, while the dark blue, the purple and the yellow colors did not pair well with the turquoise color. The red color was used for error messages since it would stand out well, which is important when wanting to catch the users attention.

(37)

Chapter 5

Results

The results of the project that this thesis describes was a working solution for a system to display information on a digital screen as well as provide a means to access this information from a web browser. The solution consists of a web site developed in ASP.NET containing two parts, one that can be displayed on a digital screen and one that can be displayed on a normal computer screen using a web browser.

5.1 Web Interface

The purpose of the web interface was to give employees of the company a quick way of seeing what happens in the oce in the near future, and also to be able to see what happens in the company's other oces. This was solved by displaying a calendar for the bookable resources of the oce, e.g. a conference room. In addition to the calendar the web interface is able to display the employees of each oce, as well as creating and editing events in the calendar, changing the settings of the digital screen and updating the users prole information.

5.1.1 Login Page

Before being able to access any other part of the web interface it is necessary to provide login credentials, thus restricting access to the site from people that are not employed at Knowit. Since the site contains sensitive information about the company authorization is required to prevent outside access. The Login page provides a way for the user to authenticate themselves and is displayed in Figure 5.1.

For users that are already registered on the site logging in is pretty straight forward. The user just have to provide a correct e-mail address and password. If both credentials are correct the user will be redirected to the Home page for the oce that they work in.

For users that are logging in for the rst time the logging process is a bit dierent. Since they have no previous credentials to login with they have to use their company e-mail and password, the e-mail and password they would use to login to their Outlook-account. This requires the user to be an employee of Knowit with an active Outlook-account. The e-mail address and password are

(38)

CHAPTER 5. RESULTS 36

Figure 5.1: The Login Page is the rst page a user navigating to the URL gets to, unless already logged in.

(39)

CHAPTER 5. RESULTS 37 veried by using the EWS, and if veried correctly the user is redirected to the Create User page.

The design of the Login page is simple, with two text boxes for input and a button for submitting the provided information. There is also a text describing the process of logging in for the rst time. Beside the submit button there is also a check box that allows users to stay logged in on the site from the current computer, since checking the box creates a cookie that saves the users credentials and enables automatic login.

5.1.2 Create User Page

The Create User page only appears once for each user, namely the rst time they login to the site. The Create User page allows the user to ll in information about themselves and change their login information. If no changes are made the default login information will be used, the e-mail address and password used for logging in the rst time. Figure 5.2 shows the Create User page.

The Create User page is similar to the Edit Prole page in structure and available editable forms. The user can ll in a name, a telephone number, an address, a job title, a personal description, a current status and select which oce they work in. The user can also upload a prole image, change their e-mail address (and subsequently also their login credentials) as well as their password.

All changes are then submitted through a single button and if all forms are lled in correctly the user is redirected to the Home page for their oce. The user will not be able to return to the Create User page and all new changes to the users prole will be done through the Edit Prole page.

5.1.3 Home Page

The main part of the web interface is the Home page. The Home page changes dynamically depending on which oce that should be displayed. Because of this new oces can be easily added without having to change anything on the Home page. This applies to the entire site, with only some navigational elements in the Master page that needs to be changed or removed if adding or removing oces.

The Home page displays the calendar for the current oce. If Umeå is the current oce the calendars associated with Umeå will be displayed, and if Sundsvall is the current oce the calendars associated with Sundsvall will be displayed. What calendars are associated with the current oce is controlled from the Administration page. Figure 5.3 shows the Home page for Umeå, while the Home page for Sundsvall is shown in Figure 5.4.

The calendar is displayed as a list of events, divided into days. The "Today" and "Tomorrow" labels are always visible, the rest of the dates are visible if any events occur on these dates. Each event is displayed in a box, containing the time of the event, the name of the event, the location of the event and a short description of the event. The location and description is only shown if available, and if the description is too long only a part of it is displayed.

The participants of each event is also displayed in the form of small images showing the participants prole picture. Hovering the picture will display the participant's name and status, or e-mail address if the participant is from outside

(40)

(41)

(42)

Figure 5.4: The Home Page as it looks for the Sundsvall oce. Notice that the background is dierent from when displaying the Umeå oce.

(43)

CHAPTER 5. RESULTS 41 of Knowit and does not exist in the database. Another small image in the upper right corner of each event displays the organizer in the same way. Each small image is clickable and when clicked redirects the user to a page displaying more information about the participant.

Each event is also clickable, redirecting the user to the Event page, which displays additional information about the event. Below the calendar is a button for creating new events, eliminating the need to rst navigate to the Adminis-tration page when the user wants to create a new event.

The design of the Home page is similar to a simple schedule, with the rst event to happen on top, follow in chronological order by the rest of the events that happens in a certain time span. Thus the most immediate event will always be on the top of the page. That each event has its own box helps separate one event from another, even if they occur on the same day. The transparent background of the boxes improves readability while not covering the background image completely.

5.1.4 Event Page

The Event page, displayed in Figure 5.5, is used to display information about an event and accessible only when clicking an event in a calendar. Information that is displayed on the Event page but not in the calendar on the Home page is the name of the participants and the organizer, and the full description of the event. As with the Home page, the participants and the organizer are clickable. If the Event was manually created and stored in the database, and the user is administrator for the oce that the event occurs in, an icon will appear in the upper right corner allowing the user to quickly edit the event.

5.1.5 People Page

Figure 5.6 shows the People page, which displays the employees of the current oce. The People page is dynamical, and the employees that are shown depends on which oce is currently selected (a value that is stored in a session variable). Each employee is displayed with a circular image and the employee's name. If an image is missing a default image is displayed in its stead. Hovering the image or the name reveals the employee's status, if available. Furthermore each employee's image is surrounded by a border, which changes color depending on if the employee is available or not.

Each employee is clickable, leading to the Employee page which displays additional information about the employee. The employees are shown in alpha-betical order and there is no limit to how many employees that can be displayed.

5.1.6 Employee Page

The Employee page is accessible both from the Home page and the People page as well as directly from the navigation menu, but when clicked in the navigation menu only the users own prole is displayed, as it is in Figure 5.7.

The Employee page is a dynamical page and the information displayed changes depending on which the current employee is, a value that is passed through a URL parameter. This prevents the need to have one page for each

(44)

Figure 5.5: The Event Page for the event Åke Eriksson, a meeting occurring from 10:00 to 11:00 in the conference room. The event have four participants along with the organizer.

(45)

(46)

(47)

CHAPTER 5. RESULTS 45 employee, and the employees can be stored in a database instead of in hard coded HTML-pages.

The Employee page displays the name of the employee on top, followed by a larger picture of the employee, which is surrounded by a border indicating their status, as described in 5.1.5. Below the picture is the status of the employee, displayed in a talk bubble to visualize that this is the employees' status. A default status is shown ("I have yet to write a status") if the employee has not added one themselves. Below the status is information about the employee's availability and some more information about the employee such as job title, e-mail address, telephone number, street address and the personal description.

If the user is visiting their own prole on the Employee page an edit icon is visible in the upper right corner that, when clicked, redirects the user to the Edit Prole page.

5.1.7 Edit Prole Page

The Edit Prole page, shown in Figure 5.8, is very similar to the Create User page, but with the dierence that it shows the information that already exist instead of only showing empty forms for the user to ll in. In fact no forms are shown, only labels with information. Each information part can be edited individually. To change the job title, for example, the user have to press the edit icon next to the job title label. The label will then turn into a text box displaying the same information, but allowing the user to edit it and save it, updating the database.

Along with the elds for name, oce, job title, telephone number, address, description and status is also the current prole picture. A new picture can be uploaded by selecting a picture on the computer and pressing the upload but-ton. Alternatively the user can choose to display their Gravatar image instead, Gravatar being a web service that hosts globally recognized avatar images1_.

The Edit Prole page also allows the user to change their e-mail address and password, eectively changing their login credentials. However, the eects of changing the e-mail address or password will not take place until the next login attempt.

The purpose of having individual editing for each eld of information is to allow the user to swiftly change only one part of their information without having to worry about aecting any other part. Note that the background of the Edit Prole page will switch back to that of the oce the user belongs to, no matter what oce the user was currently displaying.

5.1.8 Administration Page

The Administration page, shown in Figure 5.9, is only accessible to users with administration privileges. If the user lacks these privileges the link to the Ad-ministration page will not be visible and attempting to navigate directly to it will result in a redirect back to the Home page. For user that are administrators however, the Administration page is where it is possible to change the settings of the digital screen, add or remove calendars and creating or editing events. Changes made on the Administration page will only eect the oce to which the administrator is a member of.

(48)

(49)

Figure 5.9: The Administration Page with the digital screen only displaying employ-ees on a vertical screen, with a maximum of 7 events and 7 days, showing descriptions for the events. Also only one calendar is used and no manually created events exists.

(50)

CHAPTER 5. RESULTS 48 The Administration page is divided into three parts. The rst part is for set-ting up the digital screen. A list of choices allows the administrator to make the digital screen display only the calendar, only the employees or switch between them both. It also allows to set the time interval for this switch, an option only visible if the switch option has been selected. The administrator can also set if the digital screen should be tted for a vertical or horizontal screen, and set the maximum amount of events and days to be displayed in the calendar. The administrator can also set if the calendar should display descriptions of the events or not.

The second part of the Administration page is where the administrator can add, edit or remove calendars that should be displayed on the Home page and on the digital screen. To add a calendar the e-mail address of the calendar is needed as well as the password. For example, if adding an employees calendar the employees Outlook credentials is used. If adding a resource, e.g. a conference room that has a public calendar, only the e-mail address of the resource is needed.

In the third part of the Administration page the administrator can view a list of manually created events and either edit or remove them. The administrator can also add new events. Clicking the add new events link or editing an existing event brings the administrator to the Create Event page, while removing an event will only update the page and remove the event from the database.

5.1.9 Create Event Page

The Create Event page is a dynamical page that changes depending on if a new event is being created or if an existing event is being edited. Figure 5.10 shows what it looks like when a new event is being created. The dierence when editing an existing event is that the text boxes are already lled in with information and that the heading of the page is named after the event.

The Create Event page is simple, with elds for naming the event, giving the event a start and stop time, a location and a description. Participants can also be added to the event by typing the participants e-mail address in the eld for adding participants. If the e-mail address exists in the database suggestions will appear below the text box while the user is typing, which means that the user does not need to know the entire e-mail address of the participant the user wishes to add. If the e-mail address is not in the database, however, the complete e-mail address needs to be added manually.

Adding a participant creates a list of participants for the event, from which a participant can easily be removed by clicking the remove icon. The event is then created or updated by clicking the submit button.

5.1.10 Super Admin Page

The Super Admin page, shown in Figure 5.11, is only accessible to the main administrator, the person responsible for managing the system. It is accessible from the Login page by using the credentials of the super administrator. How-ever, logging in as the super administrator only gives you access to the Super Admin page, not the rest of the site, this is because logging in as the super ad-ministrator is only due to change settings for the system. Thus this page is only relevant to the super administrator and not to normal users or administrators.

(51)

(52)

Figure 5.11: The Super Admin page with a couple of active administrators and three places with aliases.

(53)

CHAPTER 5. RESULTS 51 On the Super Admin page the super administrator can add administrators, or rather choose which of the current users should have administrator privileges. The super administrator can also remove the administrator privileges of a user that is already an administrator.

The other thing the super administrator can do is to add, edit and remove places and their aliases. Adding an alias to a place allows one to customize the look of the calendar without having to change anything in Outlook. For example, the name of the default place for the Umeå calendar is "res-ume-konfrum", which does not really convey what room is used. On the Super Admin page the super administrator can add an alias to this room, renaming it e.g. "Konferensrum Umeå".

Lastly the Super Admin page can be used to remove employees from the database, e.g. if an employee quits.

The Super Admin page is constructed similar to the add calendar part of the Admin page and the add participant part of the Create Event page.

5.2 Digital Screen

The digital screen is the central part of the solution, although it is based on the web interface and uses the same underlying structure. Basically it is a dynamic web page that is supposed to be displayed in full screen on a physical display somewhere, preferably in the entrance, of the oce. Its part in the solution is visible along with the web interface on the site map in Figure 4.3. It consists of only one page, but the page can either display only the calendar view, only the employee view or switch between them both, depending on its settings.

The calendar view is visible in Figure 5.12 and the employee view in Figure 5.13. They look almost exactly like their web interface counterparts. What has changes is that all navigation has been removed, since the users cannot interact with the digital screen. The digital screen is view only, all interaction has to go through the web interface via the settings on the Administration page.

Since the digital screen can be displayed on both a vertical or horizontal screen it has two dierent layouts depending on its settings. Figure 5.12 and Figure 5.13 showed the digital screen in its vertical mode, and Figure 5.14 and Figure 5.15 shows it in its horizontal mode. There is no big dierences, other than the two columns in the calendar view and the extra column in the employee view.

Since no interaction with the digital screen is possible the number of events to display in the calendar part had to be limited, and the limit is set in the settings in the Administrators page. The number of employees on the other hand cannot be limited, and to prevent them from overowing the page a timer function will be active should the number of employees exceed the number or employees that can be shown on the screen at the same time. The timer function will rst display the number of employees that ts on the screen, and will then switch and show the rest of the employees. If the digital screen is set to switch between the calendar view and the employee view, the switch of which employees that should be visible occurs between the changing of views.

(54)

Figure 5.12: The view of the Digital Screen showing the calendar of the oce, here in vertical mode.

(55)

Figure 5.13: The view of the Digital Screen showing the employees of the oce, here in vertical mode.

(56)

Figure 5.14: The view of the Digital Screen showing the calendar of the oce, here in horizontal mode.

Figure 5.15: The view of the Digital Screen showing the employees of the oce, here in horizontal mode.

(57)

5.3 Mobile Interface

To make the solution accessible, even on the move, the web interface was re-designed to be user friendly even on mobile devices. Adapting the web interface for a smaller screen demanded a dierent type of navigation, and thus the menu elements that was conned to a sidebar in the web interface takes the form of a dropdown menu on mobile devices, as shown in Figure 5.16. The menu for switching between the dierent oces has been changed to a dropdown list that uses the mobile device's built in dropdown list form, which means that it will look dierently depending on which operating system the mobile device is using. Figure 5.17 shows the dropdown list as it looks on an Android device.

Figure 5.16: The menu on the mobile interface as it is displayed when all elements are dropped down.

The Home page is similar to the Home page on the web interface, although the elements have been made smaller, shown in Figure 5.18. The date headers have been made to always oat on top until a new date appears, so that no matter how many events there is a day the date of the day will always be visible.

The only change in the Event page, shown in Figur 5.19, is that all content is in one column instead of two. Similarly changes were made to the Edit Prole page shown in Figure 5.20. The Create Event page is also in one column in the mobile interface, but some more changes were needed to provide mobile friendly user inputs. Following some guidelines given by Gibson[8] all text boxes and buttons were redesigned to make it easier for the user to press them using a touch screen, as shown in Figure 5.21. The date picker was changed to use the mobile devices built in date picker, shown in Figure 5.22, and the image buttons

(58)

Figure 5.17: The dropdown list displayed when switching oce in the mobile inter-face.

Figure 5.18: The Home page on the mobile interface displaying the calendar for Knowit's oce in Umeå.

(59)

CHAPTER 5. RESULTS 57 for editing and removing participants were changed to normal buttons instead.

Figure 5.19: The Event page on the mobile interface displaying detailed information about an event in the calendar belong to Knowit's oce in Umeå.

The Administration page in Figure 5.23 underwent similar changes, with image buttons becoming normal buttons and all the content in one column instead of two. The two pages that needed the least changes were the People page and the Employee page. The People page, shown in Figure 5.24, needed no changes at all since it already adapted to the width of the screen. The Employee page needed to be adapted to the width of the screen, but otherwise no changes were needed, as shown in Figure 5.25.

Lastly, in Figure 5.26, is the Login page, which is a good example on how the text boxes and the buttons have changed in the mobile interface. It should be noted that the mobile interface has yet to be optimized for displays in landscape mode, and that it has not been tested on a wide variety of devices.

(60)

Figure 5.20: The top part of the Edit Prole page on the mobile interface.

(61)

Figure 5.22: The date picker on the Create Event page as it looks on an device running Android, in this case Android 4.1.

(62)

Figure 5.24: The People page on the mobile interface, displaying two columns of employees instead of four.

(63)

Figure 5.25: The Employee page on the mobile interface displaying information about an employee, with no noticeable changed compared to the Employee page on the web interface.

(64)

Chapter 6

Extending The Digital Screen

Many companies welcome visitors with a screen presenting the company and its employees, or to show announcements of some kind. The digital screen described in this thesis does more, displaying upcoming events as well as the employees. It also provides a web interface with additional information, but it has the potential to do much more. The potential functions and benets of extending the digital screen will be described in this section.

6.1 Employee Tracking

The digital screen described in this thesis has the function of displaying an employee's status, if the employee in question have supplied a status. If a status exists it means that other employees easily can check if the person they want to e.g. talk to is busy or not. The usefulness of this function depends, however, on how often the employees update their own status. Automation is needed to improve this system and make sure that the status is always up to date and accurate.

A way to do this could be by allowing the system access to the employees' personal schedule or by having the employees use an access card when leaving or entering the oce (something a lot of oces already have in place). That way the system knows if the employee is in the oce or not, and when the employee is supposed to be on meetings and other appointments. The system could also check for activity on the employee's computer to know if the employee is at his or hers desk, but then the system will become more invasive than most people would accept[9].

The benets of tracking the whereabouts and activities of employees is that it improves productivity[10]. Other employees do not need to spend time looking for them or waiting for them, hoping that they will be available. Instead they can quickly check when and where the employee will be available. This kind of system can be very useful in, for example, university environments. Allowing students to see when their lecturers and professors are available, and also where they are located, will eliminate the need for students to spend hours waiting outside the lecturers or professors oce.

Other benets of employee tracking is that it makes it easier for employers to check what their employees are doing, e.g. how much time they spend away

Digital screen for appointments and employees