User interface development of HELIO
Citation for published version (APA):van Gelderen, T. (1994). User interface development of HELIO: a lighting control system. (IPO-Rapport; Vol. 981). Instituut voor Perceptie Onderzoek (IPO).
Document status and date: Published: 18/05/1994
Document Version:
Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)
Please check the document version of this publication:
• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.
• The final author version and the galley proof are versions of the publication after peer review.
• The final published version features the final layout of the paper including the volume, issue and page numbers.
Link to publication
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
• You may freely distribute the URL identifying the publication in the public portal.
If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:
www.tue.nl/taverne
Take down policy
If you believe that this document breaches copyright please contact us at: openaccess@tue.nl
Institute for Perception Research
P.O
.
Box 513 - 5600 MB Eindhoven
TvG/tvg 94/02
18.05
.
1994
Rapport no. 981
User interface development of
HELIO; a lighting control system
T. van Gelderen
a lighting control system
JAS project at Philips Lighting
May 1994
User interface development of HELIO; a lighting control system
Executive Summary
This report describes a three month' JAS (Jonge Academen Stage) period, february lst - april 30th 1994, in the LCS Group of the Business Group Luminaires, Philips Lighting, Eindhoven. During this period I worked in the LEGO/HELIO project. The aim of this project is development of a lighting control system for large commercial offices and buildings. The lighting control system will be the successor of the current IFS 800 lighting control system. The system consists of a network of lighting controls, a 486 PC, MS-Windows 3.1 installed and the HELIO Graphical User Interface software running on this platform. Main users are designers of lighting systems, installers of these lighting systems and facility managers of buildings.
Current lighting control systems go beyond simple on and off switching of a lamp or other lighting device. Actually, on and off switching is their starting point. Such lighting control systems are e.g. capable of centrally switching lamps on and off, doing the same at regular hours (say after working hours), control movement detectors in offices, measurement of daylight in order to adjust the amount of light on a desktop, monitor energy consumption of offices and buildings, keep an eye on maintenance matters such as replacement of lighting devices, etc. This functionality seems not very complicated at first sight but when two or three
"features" are combined; non trivial user interface issues arise. These issues need close attention, careful design and should be tailored to the user needs. My contribution to this project was to give this close attention and provide input for the UI design of HELIO.
Several methods were applied to support the UI design process (Chapter 3 and 4). These methods included a continuous expert appraisal during the whole period, two interaction walkthrough sessions with several team members, several interviews with potential users and a small user test. The application of these methods had three reasons; firstly to get some feedback on the usefulness of these methods in a business environment, secondly to become more experienced in providing user interface solutions in a short period of time and thirdly to show the importance of user interface work as part of the design process.
In this relatively short period it was not possible to address all UI issues and come up with satisfying solutions. So there is still work to be done. Therefore a list of foreseeable follow up activities is presented here. These activities are split up in a Research questions section and a PCD AE section.
Research questions (more elaborate described in Chapter 5)
1. Research on new User Interface concepts for Lighting Products. One can think of switches, remote controlled lights, control light by human gestures, speech, integrated in Personal Digital Assistants etc., but also incorporate results of the Highlights project to result in new user interface concepts for lighting controls.
2. What are the effects of controlling light in domestic environments on a user? What are the attributes of light that are important when controlling light, e.g. color, lux level, light at one spot. What consequences could this have for the UI? Or a somewhat related issue: a good light show adds to a pop concert, a lot of knowledge in this field could be applied in offices, homes etc. How is this knowledge gathered, transferred and integrated in Ul's for future home lighting systems?
3. How can a lighting management system be integrated in and support large office systems. What UI issues are important here ?
PCD activities (more elaborate described in Chapter 5)
I. Interaction redesign of the UI in a iterative manner. 2. Graphical design of icons and other screen elements.
3. Specify Usability requirements to serve as a benchmark for the software.
Table of Contents
1. INTRODUCTION ... 6
2. THE HELIO SYSTEM ... 7
2. I INTRODUCTION ... 7
2.2 FUNCTIONALITY HELIO. ··· ... 7
2.2. I Intelligent Luminaire (IL) ...... 7
2.2.2 Light Measurement Cell (LMC) ...... 8
2.2.3 Movement Detector(MD) ......................................... 8
2.2.4 Timer/Clock (RTC) ......... 8
2.2.5 Digital Switch and Dimmer .......................... 8
2.2.6 Infra Red Receiver (JR), Remote Control, Wall transmitter ................. 8
2.3 USER INTERFACE··· 8
2.3.J Users and their Tasks ... 8
3. INTERVIEWS ... 11
3. I INTRODUCTION ... I I 3.2 RESULTS AND CONCLUSIONS ... I I 4. USER STUDIES ... 12
4.I EXPERT APPRAISAL ... 12
4.1.1 Introduction ................................. 12
4.1.2 Method ......................................... 12
4.1.3 Results and Conclusions ... 12
4.2 WALKTHROUGH ... 12
4.2.1 lntroduction ................................................ 12
4.2.2 Method ...................................................................... 12
4.2.3 Results and Conclusions ...... 14
4.3 USER TEST ... I4 4.3. I Introduction ................................ I 4 4.3.2 Users ..... 14
4.3.3 Experimental setup and Materials .................. 15
4.3.4 Results ............................. 15
4.3.5 Conclusions ..... 16
S. FOLLOW-UP RESEARCH ... 17
5.I PHILIPS CORPORATE DESIGN (PCD) ... 17
5.1.1 Interaction Design .................................................... 17
5.1.2 Usability requirements ..................................................................... 17
5.1.3 Consultancy during Software development ............................ 17
5.1.4 Graphical Design ... 17
5.2 RESEARCH ... 18
5.3 ACKNOWLEDGMENTS ... 18
6. REFERENCES ... 19
7. APPENDIX A EXPERT APPRAISAL ... 20
7 .1 PROPOSED CHANGES TO HELIO ... 20
7.2 GENERAL ... 20 7.3 TOOLBAR ... 2I 7.4 MENU ... 2I 7.4.1 File ... 21 7.4.2 Edit ... 22 7.4.3 Window ...... 22 7.4.4 Tools ...... 23
User interface development of HELIO; a lighting control system 7.4.5 Set Clock ...... 23 7.5 MESSAGE BOXES ... 24 7.5.1 File Open ....... 24 7.5.2 /nstall ... 24 7.5.3 RTC ... 25 7.5.4 Intelligent Luminaire ...... 25 7.5.5 RC5R ... 25 7.5.6MD ... 26 7.5.7 LMC ... 26 8. APPENDIX B WALKTHROUGH ..•••...••••••••...•.•...•...•••••..•••.... 27
8.1 ISSUES DISCUSSED ON W ALKTHROUGH HELIO SYSTEM ... 27
9. APPENDIX C USER SCENARIOS ••••••••••••...•...••••... 30
9 .1 PERSON ONE ... 30
9.1.1 Bedenkfase (system designer) ............................................ 30
9.1.2 lnstallatiefase (installer) ............................................... 30
9.1.3 Opleverfase (commissioning) ................... ...... 30
9.1.4 Beheer \service\ nazorg . ...... 30
9.2 PERSON TWO ... 31 9.2.1 System designer ........................................................... 31 9.2.2 Installation engineer ................................................ 31 9.2.3 Facilities manager ..................................................................... 31 9.3 PERSON THREE ... .32 9.3. 1 System designer ...... 32 9.3.2 Dozen installateur ...................................................... 32 9.3.3 Software-installateur ....................................................................... 32 9.3.4 Facilities manager ........................................................................... 32 9.4 PERSON FOUR ... 33 9.4.1 Typical Usage ....................................................... 33 9.4.2 Layout Designers ...................................................................... 33 9.4.3 Installation Engineers ......................................................................... 33 9.4.4 Installation of PC Software ....... 34
9.4.5 Physical Installation of HELIO network ................................................................... 34
9.4.6 Logical lnstallation ................................................................ 34
9.4. 7 Facilities Managers ... 35
9.4.8 Initial Configuration ............................................. 35
9.4.9 Day to Day Usage .............................................. 36
9.4.10 Delegated Representatives ..................................... ..... 36 9.5 PERSON FIVE ... .37 9.5.1 Initielefase .............................................. 37 9.5.2 Tenderfase ...... 37 9.5.3 lnstallatiefase: ...... 37 9.5.4 Opleverfase ... 38 9.5.5 Gebruiksfase ................................................................ 39 9.5.6 Service ... 39 9.5.7 Opleidingen ....................................................................... 40 10. APPENDIX D INTERVIEWS ...•....•...•.••.•.••.••.••....•... 41
10.1 INSTALLER; IFS I00 ... 41
10.2 PHILIPS SYSTEM DESIGNER ... 41
10.3 FACILITIES MANAGER: IFS 800 ... 42
11. APPENDIX E USER STUDY: INSTRUCTIONS & TASKS ... 44
13. APPENDIX G ISO 9241PART11: GUIDANCE ON SPECIFYING AND MEASURING USABILITY ...••••••••.••••••...••.••...•••...•••...•••...••••.•...•••••.•..••••...••••. 59 13. l USERS ... 59 13.2 EQUIPMENT ... 59 13.3 ORGANISATIONAL ENVIRONMENT ... 59 13 .4 TECHNICAL ENVIRONMENT ... 60 13.5 TASK ... 60 13.6 GEBRUIKERS ... 60 13.7 OMGEVING ... 60 13.8 TAKEN EN APPARATUUR ... 61 13.9 EIGEN VRAGEN ... 61 14. MAILING LIST •••••••••....•••••••...••••••••.••••••...••••••...•...•.••...•.••••..•...••••....••••...••••...•...•... 62
14.1 NAT. LAB. I IP0 ... 62
14.2 LIGHTING ... 62
User interface development of HELIO; a lighting control system
1. Introduction
This report describes my work during a three months Jonge Academen stage (JAS) period, february lst until April 30th 1994, in the Lighting Controls & Systems Group of the Business Group Luminaires, Philips Lighting BV, Eindhoven. During this period I worked in the LEGO/HELIO project. This project had and at this moment still has the goal of developing a lighting control system for large offices and buildings. This lighting control system will be the successor of the older IFS 800 light control system that is sold today.
Current lighting control systems go beyond simple on and off switching of a lamp or other lighting device. Actually, on and off switching is their starting point. Such lighting control systems are capable of for example centrally switching lamps on and off, doing the same at regular hours (say after working hours), control movement detectors in offices, measurement of daylight in order to adjust the amount of light on a desktop, monitor energy consumption of offices and buildings, keep an eye on maintenance matters such as replacement of lighting devices, etc.
This functionality seems not very complicated at first sight but when two or three "features" are combined; new non trivial user interface issues arise. These issues need close attention, careful design and should be tailored to end user needs.
My contribution to this project was to give input into the design of the User Interface of the HELIO lighting control system. As this was a development group, extended academic studies were not needed. It was a challenge to apply as much of my knowledge in the field of human factors and user interfaces in a form that was directly applicable to the UI design.
Several evaluation methods were used during this period for two reasons. Firstly, to assess their usefulness in a development environment and secondly, by using them, show their importance during the design process. In the next chapters I will give an overview of the HELIO system, its users and tasks and an overview of the applied evaluation methods, the results and my experience with these methods. The report is concluded with my view of the follow-up research that is needed.
2. The HELIO system
2. 1 Introduction
The HELIO system is intended as a successor of the IFS 800 Lighting Control System. The HELIO system will manage and control the lighting system in large buildings, offices etc. One could think of offices ranging from 200 to 2000 rooms or areas. Once installed, the HELIO system can switch lamps, react to presence, monitor energy consumption, facilitate maintenance, support billing for tenants of offices etc. These features are controlled and accessible from one central point with a PC and MS-Windows 3.1 software. The HELIO system can be linked to and interact with other systems like security- and air conditioning systems.
The current IFS 800 system used a central VME computer to control the lighting system, HELIO however makes use of "distributed" intelligence in a network. Each lighting device has some intelligence build within to control its part of the system (see figure l ). The PC connects to the network via a so called "SLTA". The PC is used to configure the network, but is not needed during operation.
The PC software is used by different users, i.e. system designers, installers and facilities managers. These users are described in more detail in another part of this report. The end users who use the system for their own lighting needs will not be confronted with the software, but will have a control device at their disposal. The control enables the end users to switch particular lights on and off and to switch to a light preset. A preset is usually a combination of several lights where each light has its own light level, up to four presets are available on the current control.
Power Supply
Intelligent Luminaire
Figure I Overview HELJO system
2.2 Functionality HELIO
SLTA
PL
In order to give a clear insight of the functionality of the system the main devices and features are described here in more detail.
2.2.1 Intelligent Luminaire (IL)
This is the control device for a luminaire (e.g. a lamp; PL and HF-Gear) and receives the commands from other devices described below.
User interface development of HELIO; a lighting control system
2.2.2 Light Measurement Cell (LMC)
This device can switch another device on or off depending the amount of lux it measures. For example, the LMC can be configured to switch off the lights at a certain daylight level, if one wants to save energy. In the same way, the LMC can switch the lights back on if the daylight level is too low. An interesting human factors issue is the sensitivity to changing daylight levels. During a cloudy day the light conditions can change rapidly and very often. If the LMC is configured to switch a lighting device on or off at a daylight level that occurs often that day, could this lead to a very nervous reaction of the system. So the question is how fast should the system react to these changing daylight circumstances. One solution is the continuous regulating of the luminaires by the light measurement cell. So the luminiare is dimmed when needed.
2.2.3 Movement Detector (MD)
The Movement Detector is a fairly simple device. If someone enters a room with a MD, the lights will be switched on at a certain level and switched off if no movement is detected for a specified period of time. If one wants to save energy, the MD can be configured to switch the lights off if no movement is detected, but will not switch the lights on again if movement is detected. The user has to do that by himself. This could make the user more conscience of the fact that light consumes energy.
2.2.4 Timer/Clock (RTC)
The Timer/Clock is an important device in the system. This device enables the user to switch devices on and off at specified times or periods of time. One can think of periods like weekends, non working hours, lunch breaks, hours when the cleaning people need light, vacation periods, etc. Setting this clock gives roughly the same UI problems as setting a VCR to record a specific program.
2.2.5 Digital Switch and Dimmer
A mechanical switch or infrared wall transmitter can be a digital switch for HELIO. It is no more than an on/off switch but can control any device in the network that can be controlled by an on/off switch. The Digital dimmer can control a device by rotating a knob or pressing a "down" button on a remote control.
2.2.6 Infra Red Receiver (IR), Remote Control, Wall transmitter
These devices are closely linked from a user view but technically speaking quite different. The only real device for the network is the Infra Red Receiver, the other two are "initiators" for the receiver. In end user terms the Remote Control and Wall Transmitter are often seen as the "real" devices. The Wall transmitter was described earlier (digital switch, dimmer). The Remote Control has four Presets: switch on one or more devices with a specified light level. Furthermore, the RC can separately switch and dim five (groups ot) devices and store their switch-on light level. Where these light setting parameters should be set in the interface is an interesting and complicated UI issue. Both the RC message box and Device message box are suited in some situations to set these parameters.
2.3
User Interface
2.3.1 Users and their Tasks
Four users groups are identified for the HELIO system. They all have a different use of the system in different instances of installing and configuring the system. The intended users are:
• System designer • Installer
• Facility manager • End User
Appendix C contains a description of the work flow for each user group. These user groups are not the only intended users of the system. One can think of sales persons, architects, consultants, service engineers and
trainers as other user groups. But the four user groups mentioned above form the main user population. The
work flow descriptions or scenario's give an insight of how five members of the HELIO development team see
the use of HELIO by its most significant users. The scenario's will be discussed in more detail later on in the
chapter on Walkthrough.
Partly as a result of the exercise to write a scenario, a more general work flow of HELIO was drawn by one of
the HELIO team members (see figure 2). This figure shows the work flow of a project in time:
1. A system designer draws all components of a lighting system on the architectural layout of a building or
floor. Such a lighting Design will be constrained by some requirements. The result will be a parts list of all
devices used. This is needed to calculate costs. The second result is an installation drawing that is needed
by the installer.
2. The installation drawing and hardware devices are used to install all devices in the appropriate places in
the building and the bar-code sticker of each device is placed on the installation drawing. This is done by
an installer.
3. The installation drawing
+
bar-code stickers are used to logically install all devices. The logicalinstallation is done behind the PC with a bar-code reader by either the installer or the facility manager.
4. The hardware and software are synchronized (checked) in such a way that what is represented on screen is
also actually there in each room. A lighting control application is needed for the facility manager to configure the lighting devices and other devices (heating, sun blinds, security etc.). One can think of configuring the Remote Control to control a specific number of luminaires in a room or configuring the
timer to switch of all the luminaires in a building after 5 PM except weekends.
5. After configuration, the devices are "used" in end user terms, i.e. turning the light on and off, using the
remote control etc. End users will have changing lighting needs and this will lead to reconfiguration of the
devices every now and then. Also a changing infrastructure like breaking down walls or rearranging floor
layouts will lead to reconfiguration. The operational phase gives system management data such as
User interface development of HELIO; a lighting control system
Layout (Syetemlliigner )
~
Partslist
Installation drawing
~-/
\_
Lghting Control Application Prepired Datakse ----Configured/~
)
Installation drawing of Building+
Barcode stickers\
Hardware
+
Software Synchronizedr-:_
~nfigure
~~rati~
---...
System • Management3. Interviews
3. 1 Introduction
In order to become acquainted with user behavior and problems I interviewed members of three user groups (installer, facilities manager and system designer). These interviews should give the information to set up the tasks for the user study later on. The ISO 9241 issues on usability requirements were used as a general guidance for the questions. Besides this list of questions, each user answered questions about specific issues, their common day to day tasks and their general opinion concerning IFS 800 and IFS 100. The questions were open ended and recorded on audiotape.
3.2
Results and Conclusions
It turned out that the interviews were mainly used by the interviewees to express problems they had with the current system. Appendix D gives a summary of each interview. The interview often started of with a number of technical questions. These questions could not be answered at that moment as one can expect. These technical remarks gave valuable information for the development department but not for UI design. It took some time and effort to get the focus right for the interview.
The results of the interviews were encouraging. Not because of the many technical remarks or the deeper insight of the UI of the IFS 800 or IFS l 00 systems, but mainly because of the organizational remarks and remarks concerning their day to day usage of the system. It provided enough information to properly set up a number of tasks for a user study; the main goal of the interviews.
Furthermore, the interviews provided some feeling of the user environment. The knowledge of the users' environment was a significant contribution to deepen my view on use of lighting control systems.
The use of ISO 9241 Chapter 11 "Guidance on specifying and measuring usability" as a guide for the questions asked was not very positive. The issues that are described in this chapter are very relevant and to the point. However, it turned out that it was difficult to shift the relevant issues from the irrelevant ones. The users did not always view their work in terms of tasks, environment etc. (see Appendix G). Some questions seemed therefore somewhat silly to the users.
Chapter 11 is very useful to serve as a backbone for a usability requirement specification (its intended use), but not as a framework for a questionnaire to get a more profound insight in the context of use of a user interface. If
the focus is primarily on specifying measures and benchmarks for usability then this chapter can prove its value. The HELIO system could benefit from such a specification as is outlined in a chapter on follow up design and research.
User interface development of HELIO; a lighting control system
4. User studies
4.1 Expert Appraisal
4.1.1 Introduction
The so called "expert appraisals", heuristic evaluations (Nielsen, 1992), are terms for a type of evaluation that is often used in User Interface design and development. The basic idea is to let a User Interface Expert have a look at a user interface, work with it if possible and comment on everything that seems relevant in respect to the User Interface and its users. This type of evaluation is cheap, takes little time and the results cover most of the usability problems that will become apparent in the final product. A disadvantage of the method is that the remarks, recommendations and comments can suffer from to be too detailed and scattered. It is sometimes not easy to filter out the real important remarks. This kind of evaluation should therefore be combined with a user study.
4.1.2 Method
Several expert appraisals were done on the user interface of HELIO. These appraisals resulted in "proposed
changes" of the interface. Four versions of the document containing a proportion of the proposed changes can be found in Appendix A. The general format of the document was as follows: Under development, Completed
and New Issues. Under each header appears a list of items that describe the UI issue. These issues could be
discussed and implemented in the proposed or altered form. They were moved to the Completed part of the document. If an issue raised new problems or questions then these issues were place under the New issues header.
4.1.3 Results and Conclusions
The document in appendix A is probably the most important result of this JAS period. It is not only a document to keep track of the changes in the interface but also a report of the communication between development and a UI expert. Furthermore, it illustrates the impact of user interface design on the whole interaction with the system. The appendix contains only the last version of the document. It doesn't contain all issues discussed and subsequently altered. The appendix gives only an indication of the issues we dealt with. My estimation is that this document covers about 40 % of all issues. So it illustrates that it's seems hard to keep a record of all changes. Working with developers, the proposed changes are sometimes easily made and also easily forgotten!
4.2 Walkthrough
4.2.1 Introduction
Walkthroughs have many different forms. In software engineering for example a system walkthrough is used to review (parts of) software under development. In cognitive psychology the cognitive walkthrough (Polson &
Lewis) is a technique to do roughly the same as a system walkthrough but from a different viewpoint. A cognitive walkthrough (CW) assumes that a user is trying to achieve a goal and every action is taken to
minimize the distance between the current situation and the desired goal. The CW method sees the user as
someone who has the general strategy of learning by exploration or "label following". A CW evaluates the ease with which users can perform a task with little or no formal instruction or informal coaching. Through this approach a CW can assess the usability of a system. The aim of doing a CW in this JAS period was to receive some feedback on the usefulness of a CW in development.
4.2.2 Method
A CW requires some preparation. The tasks that are discussed during a session (1.5 to 2 hours) should be prepared. These task descriptions should contain the following elements.
2. Provide a task description 3. Description of the Context of Use.
4. Task scenario. (Place the tasks description in the context of use, describe relations with related tasks,
contexts)
5. Determine correct sequence of actions 6. Identify anticipated user population 7. Describe the user's initial goals
Some participants were asked to write down element 4: a task scenario. This was requested up front in order to
get the right focus of the actual session. The aim of making these scenario's was also to come more quickly to the essence of some anticipated problems. If participants had already thought of the user point of view, then
perhaps during the session this would result in better solutions for some problems.
The general set up of a CW session is outlined in figure 3. Usually five to seven evaluators participate in a CW. These evaluators can be members of the development team, ergonomists, product managers, sales persons, trainers, etc. These evaluators usually evaluate and walk through the interaction with a prototype of a system. The main responsible for this prototype (i.e. the presenter) gives an introduction of the system and shows and explains to the evaluators why the prototype is designed this way.
Moderator
i
I
Evaluators
Figure 3 Walkthrough Setup
Presenter
lvcR I
Video
Camera
During this process a Cognitive Walkthrough Evaluation Sheet is used to keep the focus right, i.e. looking at the system from a user point of view. So by evaluating if the system supports the user in coming closer to - and
achieving his/her goal. The whole process is monitored by a moderator; usually an ergonomist. Also a video
camera is used to record the walkthrough. The use of a camera eliminates the need to write things down and
thereby slowing down the walk through process. During the actual sessions there was no system displayed due to the ongoing development at that time. The technical background knowledge of the HELIO system did not
User interface development of HELIO; a lighting control system
Cognitive Walkthrough Evaluation Sheet Actions/Choices should be ranked according to:
• What percentage of potential users are expected to have problems: 0
=
none, 1=
some, 2=
more than half, 3=
most.• How much estimated time will the user need to complete action/choice ?
... minutes, hours, days
1. Description of user's immediate goal.
2. (First I Next) Atomic action the user should take. 2a. Obvious that action is available? Why ?
2b. Obvious that action is appropriate to goal? Why ? 3. All other available actions less appropriate? For each: why? 4. How will the user execute the action ?
4a. Problems? Why?
S. Execute the action. Describe system response: Sa. Obvious progress has been made toward goal ?
Sb. User can access needed information in system response? Why ? 6. Describe appropriate modified goal. If any:
6a. Obvious that goal should change? 6b. If task completed, is this obvious? Why?
4.2.3 Results and Conclusions
The results of two Cognitive Walkthroughs with HELIO team members can be found in Appendix B. The appendix contains solely issues that where discussed in some length. The appeared that the issues discussed were of another nature than intended by the CW method. Eventually the evaluation sheet was not used at all! At that time this did not seem a problem. The first session was successful and followed by another one because the participants found it a useful way to discuss the issues that came up. The fact that one could discuss from a user standpoint elements of the system that potentially could cause problems seemed useful enough to the participants. Also the absence of the system itself seemed no problem. The participants were very involved in the development and needed no system to picture themselves the flow of events. Perhaps a system would give more elaborate discussions if it were there. This remains a research issue to be solved. The main conclusion is that the CW procedure itself was not used. However, organizing these kind of sessions with a general aim of choosing some common tasks and walk through a system from a user point of view will give valuable information for development in this stage. At a later stage in development a more formal and exhaustive walkthrough of the most common tasks of a user (interface) would need the actual CW method itself.
4.3 User test
4.3.1 Introduction
A user study was part my planning in this JAS period. However, due to various problems and delays there was no time left to do a (in my view) proper and useful user study. So this part of the report is merely a description of the user study I intended to do rather than the results of such a study.
4.3.2 Users
In the specification of HELIO are four user groups distinguished: system designer, installer, facility manager and end user. As a starting point three out of these four user groups were interviewed. Appendix D gives a summary of those interviews. The purpose of those interviews was twofold. Firstly, to get an overview of
common and most frequent tasks during their work. These tasks should be used, if possible, in the user study. Secondly, in order to get as much information as possible during the user test, a good personal relation with the subjects could improve this. The (potential) users were selected on basis of their previous experience with IFS 800 or IFS 100. The system designer had experience with IFS 800, facility manager with IFS 800 and the installer with IFS 100.
4.3.3 Experimental setup and Materials
The general setup was rather straightforward. The subject was sitting behind a PC with MS-Windows 3.1 and HELIO running (see figure 4). The units were attached to a wooden board and via a so called SLTA to the PC. The subject had to perform a number of tasks (see Appendix E). All was videotaped with a S-VHS Camcorder from a corner of the room. The subject needed about one and a half hours to complete most tasks.
IA small Office
DIN rail
BUS
!Room 1
I
!Room 2
I
Figure 4 Experimental Set up
4.3.4 Results
Subjecti
PC Windows HELIO Video Camera SLTAThe results are based on one small pilot study with a naive subject (in both the domain of lighting controls as in knowledge of the HELIO system) and one study of a system designer with no knowledge of the HELIO system and PC Windows software. Therefore these results are very preliminary and certainly not conclusive. They only point out a vague direction for further development and interaction design. Observed issues:
Installation
1. A general impression is that the logical installation of units caused not much problems.
2. Features for large numbers; channel connections during installation could take place after executing a command. So not immediate after dragging a line on the screen.
3. Favors use of service pen with notebook or cordless communication instead of bar-codes on a paper floor plan. The impression is that installer will not like the paperwork.
User interface development of HELIO; a lighting control system
4. Advantage that only bus connection is needed and no mains power to install units to the PC software. However, the bus needs -65 VA so a portable generator of electric power could be needed.
5. The right mouse button for dragging lines was not easily discovered. 6. Toolbar icons don't seem "draggable".
7. The terminology could be confusing. The subject was not familiar with "channels" (used "bus").
8. A problem is stealing units during the building of offices etc. The units should be small or should not look as if they were valuable in some way.
9. System response too slow; subject made several remarks on the time between actions.
IO. Light Measurement Cell icon not clear; looks like a "shower".
I I. Infrared Receiver not clear, expected a unit with a transparent element on top, not an icon of a RC. I 2. What happens if the wrong service pen is pushed?
13. Sees no difference between install and configure mode.
Configuration
I. A general issue was the confusion caused by where should a parameter be set; e.g. in the message box of the RC or the IL. So what is the relation between units and their parameters? Generally the subject tried the IL dialogue box first.
2. Strong mental connection between imported bitmap and placed icons. The subjects thought that what is in a room (graphically) automatically is connected (logically binded).
3. Copy command for units and their parameters.
4. Drag a line over another icon, subjects thinks that this icon is also connected.
5. Why only switch OFF and no switch ON? (the dragged line between icons indicates that one can switch a IL on but OFF is a checkbox in a message box!
6. No indication of channels in the IL dialogue box.
4.3.5 Conclusions
It was not feasible to perform a proper user study given the availability of (correctly working) hardware and remaining time. The number of subjects and subsequent results were insufficient to identify definite trends for future directions in the interaction design or desired functionality of HELIO. The study did provide some hints for improvement and area's in the user interface that need extra attention.
Several user tests remain a crucial activity in the interaction design process of the HELIO system. Results of such tests will be the main input not only for design but also to guide usability, acceptability and bench marking tests of the actual product.
5. Follow-up Research
This chapter gives a brief overview of, in my view, necessary follow-up research and development concerning
the User Interface of the HELIO system. A distinction is made between applied ergonomics and interaction
design work (PCD) and long term research (Nat.Lab./IPO). The current status of the HELIO User Interface is
taken as a starting point for the follow up activities.
5.1 Philips Corporate Design (PCD)
5.1.1 Interaction Design
During this stage period a lot of changes have been discussed regarding reasonable improvements. Some of them have been implemented in the prototype. Even more suggestions for change did not make it to
implementation because of various reasons. Some suggestions were rejected "simply" because of technical
reasons. Other suggestions were sometimes thoroughly discussed before they were rejected because one did not know if the so called improvement would really be an improvement. One way to judge if a suggested
improvement is really an improvement is to test the User Interface with real users. Because of technical
problems and delays it was not possible to do such a test in the stage period. The first activity in a follow-up
would be to conduct a user test. Later on in the development of the software, another user test is needed to evaluate the UI and assess if the UI meets the usability requirements. This second user test requires another 20
days. So the estimated resources are one ergonomist, 40 days. The current prototype would be sufficient for a
first user test. Number of subjects: between 5 and 7, each user group at least one with an emphasis on installers
and facility managers.
The entire Interaction Design requires an estimated 40 days by one ergonomist.
5.1.2 Usability requirements
The usability requirements are part of the specification of HELIO. The requirements are not finished at this moment. They need to be completed in order to test the software from a user point of view. One can think of
system crashes, response time, quality of help texts, time to learn a function, efficiency etc. These requirements
should be met when the software is ready to market. Estimated resources: 2 to 3 days.
5.1.3 Consultancy during Software development.
During the development many tiny changes of the User Interface have to be decided upon. In order to have the highest possible usability an ergonornist should monitor these changes in my opinion. Estimated resources: 5 days.
5.1.4 Graphical Design
One aspect of this User Interface is not discussed so far. The feel aspect of the interface is to some extent
covered in this report, the looks of a User Interface however needs also special attention. The graphical design
of a product plays especially in the buying process an important role. As this is a product that will be used in a professional environment it is my guess that the buyers will not always be the users of HELIO. These buyers will be attracted to a User Interface with nice icons and a great logo.
Another issue is the use of icons in the User Interface. As it is becoming common in Graphical User Interfaces
to use toolbars, floating palettes and panels, one needs to have icons for all commands and even for some
shortcuts. These icons should have a clear visualization of their meaning. The current icons fit their purpose in
the prototype but would not be acceptable in the actual product. Redesign of the current icons and design of icons for menu items and other lighting devices is needed here. Estimated is about 50 icons for menu items etc., and 10-15 icons for luminaires and other lighting devices and a HELIO logo. Time needed; 55 days.
User interface development of HELIO; a lighting control system
5.2
Research
The User Interface research component of follow-up research would have a different and more general approach. Interacting with light would be the main theme. Possible projects would be:
1. User Interface concepts for Lighting Products. One can think of switches, remote controlled lights, control light by human gestures, speech, integrated in PDA's etc., but also incorporate results of the Highlights project to result in new user interface concepts for lighting control.
2. What are the effects of controlling light in domestic environments on a user? What are the attributes of light that are important when controlling light, e.g. color, lux level, light at one spot. What consequences has this on the UI?
3. Research on integrating CE products with light controlling, e.g. use TV as User Interface for lighting control.
4. A good light show adds to a pop concert, a lot of the knowledge in this field could be applied in offices, homes etc. How is this knowledge gathered, transferred and integrated in user interfaces of lighting systems?
Support for sales persons in selling light has many UI issues. How does one show lighting solutions to customers? What support is adequate? One can think of knowledge based systems with many UI issues to be solved.
These subjects give a mere impression of possible user interface research within lighting. As systems become more complex, the user interface will become more important. And as long as there are people operating devices, there is some form of user interface. So the need of giving user interface design and - research its place in the development process of new products becomes more and more apparent in today's products.
Acknowledgment of that need is acknowledging the need to primarily focus on the user instead of the technology of a product.
5.3
Acknowledgments
First of all I would like to thank H. Bouma, G. Frederix, J. v/d Akker, N. Bonne and F. van Nes for giving me time and opportunity to do a JAS period within Philips Lighting. It has been a very useful period for me in which time constraints, on the spot design solutions and becoming a UI expert on lighting control systems were the main challenges. I would also like to thank the whole group for their support and especially H. Verstegen, E. van Dordt and J. Renckens for their support and good cooperation.
6. References
Polson, P.G. & Lewis, C.H., Rieman, J., & Wharton, C. (1992). Cognitive walkthroughs: a method for theory
-based evaluation of user interfaces. International Journal of Man-Machine Studies, 36, 741-773.
User interface development of HELIO; a lighting control system
7. Appendix A Expert Appraisal
7.1
Proposed changes to HELIO
IntroductionThe purpose of this document is a discussion document in order to improve the UI of the HELIO system to be. Issues that are Under development are not implemented, issues that are Completed are implemented but not fixed at this moment, New issues are issues brought up by implemented elements of the UL For now the completed issues are dealt with but these issues remain in this document to document the process of change of the HELIO UL
7.2
General
Under development1.5. Show a busy cursor whenever the application is performing a task.
1.6. Add key short-cuts to menu items.
1.11. Add HELP. The Help button should be between OK and Cancel
Completed
1.1. Add maximize to the control menu box
1.2. Add maximize button to the right of the title bar. (and a restore button also) 1.3. Enable double-click of title bar to maximize application
1.4. Add a window border to the application to enable resizing of the application.
1.7. Add a Help menu name in the menu bar
1.8. Have a consistent position of OK and Cancel (Yes and No). Message boxes with vertically placed buttons: top OK and bottom Cancel closely placed together, message boxes with horizontally placed buttons: Left OK (Yes) and right Cancel (No) closely placed together. The Help button should be between OK and
Cancel.
1.9. Remove "debug" window in upper right corner.
1.10. The Minimize button that appears now and then in message boxes should be removed.
New issues
7.3
Too/bar
Under development2.3. Change appearance of toolbar buttons so that the meaning is clearer: Add labels to the buttons.
Binding button
When the binding button is clicked three additional buttons appear: show, add and de!. These buttons reflect a more fundamental issue of this UI: the approach here is that the user first selects a command and then selects an object to apply this command to (edit uses the same approach). In graphical Ul's this is not very often the case, usually a user selects first an object (e.g. a sentence in a word processor) and selects then the command (e.g. delete, cut). The latter philosophy should be followed in this UI to my opinion.
Proposed changes:
step I. Show: is merely a default command when in "bindings mode". So when a user clicks an object, this
object turns inverse video and shows its bindings to other objects.
step 2. Add: click and drag (with right mouse button pressed) from an object to another object, dragging a "wire" to this other object, on release of the mouse, the wire is replaced with a binding.
step 3. Del.: select binding (selection blocks on wire), select cut or del. in the Edit menu or press del. on
the keyboard.
These proposed changes make these buttons in the button bar obsolete. Completed
2.1. Remove "Current Building" from toolbar.
2.2. Move current file (eea, eec) to title bar: example: Microsoft Word - JAS.DOC becomes: HELIO
-eea. l st
2.4. Change organization of toolbar buttons. Two distinct phases can be distinguished: installation and
configuration, this should be reflected in the UL
2.5. Interaction with toolbar buttons differs: the channel, install, binding and parameter buttons are modes (view modes and working modes) and the "Toolbar" (in menu option Windows) is a drag & drop
toolbar. Change interaction: t.b.s.
New issues
2.6. Remove buttons altogether.
2. 7. The install and configure mode can have the same interaction for binding logically and
connecting physically). Observation of two presentations (demos) of the HELIO prototype resulted in both cases a question whether a user could make the distinction between the logical bindings and the physical connections conceptually. The current HELIO prototype shows both types in a similar way. Prop: present a clear distinction to the user that he/she is in Install or in Configure mode. (further
t.b.s.)
7.4
Menu
7.4.1 File
Current menu items:
New, Open, Save, Save as, Exit Completed
User interface development of HELIO; a lighting control system
3.1.1. Remove New; as long as HELIO cannot make its own light switching plans this options is not necessary.
3.1.2. Remove Save and Save as; the database is automatically updated, and the plans are imported so an explicit "save" or "save as" is not necessary.
3 .1.3. Add Close; if a user wants to close the current floor map, this should be possible. Although the Open menu item would do the trick, an explicit "Close" gives the user more confidence. This issue is related to the "Save and Save as" issue; the user should get informative feedback that the data in the database is saved and that no information is lost as the floor plan is closed. So after an Open or Close the user could get a message box stating: Data is saved, Database is being closed, please wait... (supposing that the closing of the database takes a few seconds).
3.1.4. Add a line between Open and Exit; this groups menu options that have some relation to each other (or not in this case)
3.1.5. Add three dots to Open; this indicates that another box will follow. (Windows convention)
New issues
3.1.6. The general issue here is how the files of floor plans (or buildings) are related to the database and managed.
7.4.2 Edit
Current menu items:
Select Item, Unselect All, Select All, Delete Items.
Edit uses the philosophy of command first, object selection next. Under development
3.2.1. Remove Select Item; is not necessary in this GUI, clicking an object is sufficient.
3.2.2. Remove Unselect All; is not necessary in this GUI, clicking besides objects deselects them.
3.2.3. Remove Delete Items; is not necessary in this GUI, clicking an object and press Del. or select Cut in the Edit menu.
3.2.4. Add Cut, Copy, Paste to the Edit menu. These menu options have an effect on the object andits properties, so not the channel and bindings are copied or pasted.
3.2.5. Add Undo; users make mistakes.
Completed none.
New issues none.
7.4.3 Window
Current menu items:
Tool bar
Proposal here is to have a separate place mode (Add objects) in which the "toolbar" (floating?) is displayed.
Completed
3.3.1. Remove Window altogether; the window menu name is usually used in case of multiple documents. Here only one document can be opened at a time. If multiple floors and buildings can be viewed and configured in one session, then a Window menu name is necessary. The Too/bar is only necessary if the user installs the objects.
New issues none.
7.4.4 Tools
Current menu items:Connect objects to channel, Install Objects, Make Binding to Objects, Show all Bindings, Set object parameters. A button bar with the same functionality as a menu name and menu items gives a more flexible interaction. Users can choose between menu and buttons. The current situation is therefore preferred.
3.4. l. Two suggestions for change however, as the interaction is mainly graphically once a mode is entered (i.e. for example Install Objects) the menu name Tools is proposed to be altered in View.
Note: these suggestions are based on the current situation of the UL A future version could well have a different approach that is more task supporting. A change to this different approach must be further discussed. A possible approach could be that each view is represented by tabs. Another could be that separate menu names are assigned to installation and configuration. A distinction between user groups is needed possibly, certain users may not have access to configuration or installation. This has effects for the password management. Completed
3.4.2. Second change could be the removal of "Set object parameters". By double-clicking the icons of objects a pop-up box should appear for all the necessary settings. The "Pencil" button in the button bar is removed also then.
New issues
3.4.3. Add a new menu name Network (so not View) with three menu items: Install, Configure,
Synchronize All. Rationale is to make a distinction between the Installation and the Configuration part of the network.
7 .4.5 Set Clock
Current menu items: noneIssue: This menu name is also a command.
3.5.3. The way the date and time are set could resemble the way it is done in the Control Panel - Dateffime in MS-Windows 3.1. This interaction leaves little room for wrong formats of time and date.
Completed
User interface development of HELIO; a lighting control system
3.5.2. Change proposal here is to remove the Set Clock menu name and replace it with a more general
menu name Options where Set Clock will be a menu item.
New issues none.
7.5
Message boxes
7.5.1 File Open
Under development4.1.2. As already mentioned, the file structure is not clear yet. The system specifications specify only that it should be possible to import an AutoCAD file. But is this always and DXF or other AutoCAD file format? Is the relation between the vbx database and different floor plan files clear? For example: will there be one file per floor or one file per building and how is the filename related to the database?
Should a user be able to change the name of its floormap file? This issue should be further discussed.
4.1.3. The use of bitmap files for floor plans is presumably done because of time pressure, currently one file takes up approx. 600 KB RAM. This slows done the system. A discussion which file formats to support is needed.
Completed
4.1.1. Visual Basic 3.0 uses a different presentation of the file list and directory list box than Windows 3.1. At this moment it seems not possible to adjust this box to let it resemble the Windows 3.1 looks. It would be preferable to have the 3.1 looks.
New issues
4.1.4. Support different file types (*.BMP, *.DXF etc.) in dialogue box.
7 .5.2 Install
The install mode has no dialogue specified for the use of the bar-code reader. This aspect has importance because the user has to switch (attention and hands) very often from bar-code reader to HELIO and vice versa. Completed
4.2.1. Change boxtitle Install in Bar-code Install (?).
4.2.2. Change Module type in Type.
4.2.3. Change Module Name in Name, is this label needed?
4.2.4. Change Neuron Id in Id number.
4.2.9 Proposal:
1. In Install mode.
2. Double-click e.g. a luminaire, pop-up box with Type is given (no Abbreviation!) and a message:
"Place bar-code reader on bar-code and pull the trigger" If a bar-code is received by the system the pop-up box disappears and the "normal" message box appears with the information. What will happen when a bar-code is already in the database or the user has to use the fall back system has to be specified.
New issues
4.2.5. Install is only possible after the connection of objects to a channel. Prop: message if a user attempts to install an object without connecting it first.
4.2.6. What happens if a user tries to read a bar-code that is already in the database? 4.2.7. What happens if a user reads the wrong bar-code given a selected object? 4.2.8. Are Type and Name necessary? When?
7.5.3 RTC
Under development4.3.2. This box needs considerable redesign, one approach could be a planning-program like appearance of time frames giving a clearer overview of a larger timeperiod.
Completed
4.3.1. Change RTC in Timer
New issues
4.3.3. OK and Cancel buttons.
7 .5.4 Intelligent Luminaire
Under development4.4.4. Add Min. (what is Min. in lighting anyway? Off or very dimmed?) to the horizontal sliders. 4.4.5. Add Light level to the horizontal sliders.
4.4.6. Remove Clock/Calendar presets and move it to RTC box (redesign of RTC box).
4.4.9. General: if these settings have to be done in a separate room and not in the room the settings are for then there could be much irritation and communication problems between facilitation managers and the real end users.
Completed
4.4.1. Change Intelligent Luminaire in Luminaire
4.4.2. Place Wall transmitter switch-ON level in upper part of message box.
4.4.3. Change Wall transmitter switch-ON level in Switch-on light level of Lamp switch. 4.4.7. Change Switch-On by Movement Detector in Movement Detector Active.
4.4.8. Change Switch-On by Light Measurement Cell in Light Measurement Cell Active.
New issues none.
7.5.5 RC5R
Under development
4.5.2. The use of the term Channel here and during the installation mode seems confusing. Needs further discussion.
User interface development of HELIO; a lighting control system
Completed
4.5.1. Change RC5R in Remote Control. 4.5.3. Change Timer in Switch-off after:
4.5.5. Change Dimming Speed in Light Dimming Speed.
New issues none.
7.5.6 MD
Completed4.6.1. Change Switch-off timer in Switch-off after: 4.6.2. Change MD in Movement Detector.
New issues none.
7.5.7 LMC
Under development
4.7.4. Move Calibrate button to right of box, different function. After clicking the button, pop-up box with: "Enter lux level measured with lux meter", enter value, click Calibrate, message box with:
"Sensor calibrated" , click OK and return to first box.
Completed
4. 7 .1. Change LMC in Light Measurement Cell (Sensor?).
4.7.2. Change Switch-off level in Switch-off Light at:
4.7.3. Change Reaction Speed in Reaction Speed to changing daylight intensity.
New issues
4.7.5. Change Calibrate in Change. Show tux level measure on toplevel of messagebox. Interaction: see above.
8. Appendix B Walkthrough
8.1 Issues discussed on Walkthrough HELIO system
I = ISSUE discussed
P =POSITION towards that issue (negative or positive (-or+)
ProP: proposal to deal with issue (by T.v. Gelderen)
/: Use of bar-code and bar-code reader.
Who:
P+: some superior of the installers P+: facility manager
P-: Philips people P-: not Philips people Where:
P+: Person uses Bar-code reader behind desk.
P-: Laptop PC with bar-code reader during installation No, because ordinary installers are not capable of doing this. How:
P+: Printout of floor map that is made on PC-HELIO software with enlarged spaces for bar-code stickers. I: Normally, installers do not have latest version of floor plan.
ProP:
Interview users of IFS 800 for more feedback on this issue.
Set up of training I courses program for HELIO so that a division of needed skills and required educational
level has to be set.
I: Could terminology cause problems? P: mapping tenninology Echelon to HELIO P: Lighting history
P: Conflict with other systems
ProP: make glossary of terms by making an inventory of used tenninology in lighting systems. review by users, installers, etc. Choose fixed set of terms, labels for all lighting systems
I: ls it clear that place and orientation of icons/bar-code on a printed floor plan is related to real physical
position in an office under construction?
P: use units that already have some information attached considering spatial arrangement in a room. (e.g.
"lichtlijnen" in industrie).
P: this approach is not suited for of the shelf products. ProP: t.b.s.
I: Use offallback mechanism P: has to be done with two persons ProP: walkie-talkie (interview, user test)
/: How to copy properties from one device to other devices ? P: change as default global parameters.
User interface development of HELIO; a lighting control system
P+: Select multiple devices in a similar way as draw packages do (e.g. Designer, Coreldraw).
ProP: P+
I: If the users wants to see parameters of these selected devices, which one(s) is (are) shown? P-: First selected (top left).
P+: Click on desired device.
P-: Table of parameters of all selected devices P-: no table in a GUI
P+: like Word 6.0 Word processor: display parameters if a user places the mouse cursor on top of a device icon.
I: How long does it take to retrieve the information and display this info? P: "quite" some time. Depends if local or distant.
ProP: Does the user want to check the devices before or after the selection ?
If before: click on desired device (P+)
If after: Word 6.0 like (P+)
P: problem is when the user want to edit the parameters of an individual device while it is selected. I: Would a user want to know all parameter values of the selected devices?
P: Yes, if a user is not sure if all devices have to be altered: check, stay in control. P: In case some parameter values shouldn't be altered.
P+: "Tag" a device.
P: Yes, but only the relevant parameter values.
P: Relevant are these values that are altered by the user.
P: Relevant are the global values. (I: what are global values ?) P+: Show only these values.
ProP: P+
I: If a user has selected a large number of devices and has change some values, how will the user see that the action is completed successfully ?
P: Appearance of device icon changes if some parameter is altered.
P: No confirmation needed, the system is reliable.
P: A pop-up window appears with the changed value and the user is asked to acknowledge the change (except the tagged devices) with "Yes -Yes to All - Cancel".
I: If a large number of devices is selected and altered, the number of pop-up windows will be large also. ProP: t.b.s.
I: ls changing the values an irreversible action ? P: yes
ProP: undo possible ?
I: If more than one type of device is selected, how can one select (e.g.) only MD devices from the larger selection?
P: Menu item with device types P: Click Toolbar icon
P: currently not visible in installation mode
P: Sequence: select, if multiple device types then pop-up window containing a question of buttons to select the required device type.
ProP: t.b.s
I: How to show a subset of the parameters of a device ? P: use query techniques (time, date, type, AND, OR etc.) P+: this should be an add-on.
ProP: P+.
I: How to name a selection of devices e.g. "Room 333" ? P: use current name field
P: used for billing, tenant etc.
P: difference between device names and "other" level names.
ProP: t.b.s.
I: Management of Names; Textual VI vs. Graphical representation of e.g. Tenants ? Prop: t.b.s
/: Does a user want to change for example the tenant of a room or the select devices for billing ?
P: each month for billing ProP: interview
/: How to select all devices on a single floor ? P: depends on CAD file
I: What is in a CAD file ? P: One floor ?
P: Buildings ? P: Rooms?
ProP: interview users
I: How does a facility manager perceive afloorplan ? P: per floor
P: per building P: otherwise ? ProP: interview
/: Zooming a floorplan necessary considering previous issue ?
P: zoom out until icons are not readable anymore. Prop: t.b.s.
User interface development of HELIO; a lighting control system
9. Appendix C USER Scenarios
9. 1 Person one
Aanname: projektmatige aanpak, d.w.z.: geen "toonbankartikel" De gebruikersgroepen vallen uiteen in twee groepen:
1) Niet reele gebruikers, demo's, kursus.
2) Reele gebruikers, installateurs, service, beheerders, etc.
De eerste groep is niet zo interessant, maar bij demo's worden wel vaak beslissingen genomen!
De tweede groep. Hierbij heb even als leidraad genomen het installeren, opleveren en beheren van een projekt.
9.1.1 Bedenkfase (system designer)
Hierin wordt het systeem uitgewerkt en op papier gezet. Werken met de diverse onderdelen is hier nog niet aan de orde. Echter het valt te bedenken dat de designer de configuratie al invoert in een configuratieprogramma. Dit kan dan later tijdens de opbouw in gedeeltes in het gebouw ingevoerd worden.
9.1.2 Installatiefase (installer)
Hierin wordt het systeem geinstalleerd en onder spanning gezet. Hierbij zijn twee dingen interessant:
I. Testen van de diverse komponenten (reageren ze op de bus, staan de adressen goed, reageren sensoren, reageren de units op direkte schakel kommando's, etc)
2. Het configuren van een situatie waarbij alle verlichting van een bepaald gedeelte van een gebouw (bv een verdieping van een vleugel van het gebouw) op een simpele manier aan en uit geschakeld kan worden ("een knops bediening", de units schakelen automatisch in zodra ze onder spanning komen, etc.) Deze situatie blijft totdat de lokale bedienings elementen aanwezig zijn. Dan wordt de originele configuratie geladen, vaak met toevoeging van extra tijdklok in- en uitschakeltijden voor het gemak tijdens het inrichten
van de ruimten.
9.1.3 Opleverfase (commissioning)
Hierbij wordt de originele configuratie geladen, getest en ev. aangepast. Ev. regelparameters worden ingevoerd.
Problemen worden oplost, waarbij allerlei testen vaak noodzakelijk zijn (zie boven). Uiteindelijk wordt de installatie over gedragen aan de beheerder. Vaak wordt hierbij ook de konfiguratie "vastgelegd" (floppy, papier) voor de service en of nazorg. Sensoren (bv lichtmeetcellen) worden regelmatig uigelezen voor het kontroleren van de goede werking.
9.1.4 Beheer \service\ nazorg.
Het systeem is in bedrijf. Wijzigingen moeten vastgelegd worden, fouten moeten opgespoord kunnen worden (testen, zie boven).
9.2
Person two
9.2.1 System designer
1. Draw/generate/recall building layout.
2. Introduce demanded functionality in rooms/areas by introducing required items. (possibly including routers).
3. Make lists of required parameters settings per item.
4. Make list of required binding per item.
5. If possible simulate behavior system to test functionality. 6. Generate list of required IR. addresses per room/area.
9.2.2 Installation engineer
1. Draw/Generate/Recall building layout.
2. Introduce installed items in correct places using bar-codes. 3. Make wiring diagram for routers/repeaters/bridges.
4. Possibly layout items in correct places. 5. Generate bindings.
6. Set item parameters.
7. Test bindings and parameters and electrical connections.
8. Debug problems (facilities for this).
9. Generate actual installed functionality per room/area on paper for actual office users.
Note: some activities may have been done or prepared by the system designer.
9.2.3 Facilities manager
1. Draw/generate/recall building layout to adapt to new state.
2. Zoom in on relevant part of building (also system designer/installer). 3. Adapt bindings.
4. Adapt unit parameter settings.
5. Introduce simple new items (e.g. transmitter).
6. Generate functionality and IR. addresses per room/area.
7. If possible simulate behavior of the system or part of the system. 8. Read/view status of units.
