Keywords

1 Introduction

Trouble tickets is a well-known phenomenon in service oriented industries whether commercial or non-commercial [1]. Trouble tickets are created once a user or a customer has a trouble interacting with an information system. To counter customer troubles, companies provide help known as help-desk or service desk. This paper explores the interaction of employees of an organisation who provide support, known as user-support-staffs (also known as help-desk staffs) with the User Interface (UI) of a trouble tracking system. The trouble tracking system observed in this paper was Best Practical Request Tracking (RT), version 4.0 at the German Climate Computing Centre (DKRZ)Footnote 1. The study was conducted by observing the technicians engaged in user support (help-desk) activities using an ethnographic field research in real settings [2]. DKRZ is a High Performance Computing (HPC) as well as a data centre. It is one of the governmental organisations participating in the ongoing international project of Earth System Grid Federation (ESGF) [3, 4]. ESGF is a global climate e-Science infrastructure that offers climate data projects, computing and visualization facilities to climate scientists. ESGF is currently also being extended to serve other domains such Biology, Chemistry and Astronomy.

The User Interface (UI) of trouble ticketing systems, also known as request tracking systems in general have not been adequately researched [1] and particularly not in the field of e-Science. These request tracking systems, however, play a central role for the success of e-Science as e-Science is considered a new paradigm in doing research and helps to fulfill the Science 2.0 vision. Science 2.0 is a term under which more collaboration amongst scientists using technology especially Web 2.0 is expected as opposed to traditional laboratory science which is termed as Science 1.0. The end-users of ESGF experience problems in getting the data needed and send requests in a hope to get their problems solved. Therefore, establishing an efficient support in a wider scope is one of the major exercises that lies ahead to make e-Science a central scientific method in the highly digitalized and linked up world-wide society of the 21st Century.

This paper supported by this observation study evaluates the usability of UI of User Request Tracking System: Best Practical RT and attempts to provide recommendations to enhance the UI of RT. This paper is structured as follows: In the Sect. 2 the background of the context and terminologies of e-Science, UI and User Support is provided. Also in this section an overview of related work to the research question is given. Subsequently the research steps taken to generate recommendation are explained in Sect. 3. The results of this research study are then shown and explained in Sect. 4. Future work and conclusion are elaborated in Sects. 5 and 6, respectively.

2 Background and Related Work

e-Research is conducted via e-Science infrastructures that are deployed to access and share the data, high performance computing (HPC) facilities and human resources to facilitate interdisciplinary and inter-disciplinary research to harvest knowledge [3–6]. Users need an interface to access its resources usually data. The interface includes command line tools, web portals and Graphical User Interface (GUI) to access data assets which are the main resources hosted [7, 8]. However, during an interaction of a user with an e-Science infrastructure, a user may require help due to outages of some resources e.g. servers or any other anomaly. In other case: a user requires particular scientific or technical information [9]. In order to meet these user support challenges, CI offers user support in the form of a help-desk, which even being a core activity has not received adequate attention since inception of cyber-infrastructures [10–12].

Nevertheless, the aspect of interaction with UI of an e-Science infrastructure is not limited to the end-users. Indeed, it has been observed that also other stakeholders, especially the support worker’s, need better UI of a request tracking system to properly support the users of an e-Science infrastructure [4, 13–15]. This is also due to a reason that there is often no or just a single real working position for a user support worker in e-Science organization [4, 13]. Moreover, e-Science infrastructure is mostly a decentralized structure of multiple organizations worldwide and there are many participants (user support workers) interested in supporting users at multiple sites world-wide rather than a single site [5, 16]. These employees are generally scientists and they contribute to user support on a voluntary basis [5, 13]. All these facts lead to study the current UI of RTS in place in ESGF.

Earth System Grid Federation (ESGF) is an important practical use-case in the field of climate science cyber-infrastructure project. ESGF facilitates to study climate change and impact of climate change on human society and Earth’s eco-system [21, 27]. In a case study of ESGF, user support concept covers “helpdesk” or “service-desk” of a distributed, multi-organizational research-oriented, non-commercial, collaborative environment. The current user support in ESGF is being performed by human support agents i.e. employees, that include top scientists [1]. Better the user experience of GUI of the tracking system is, quicker it is to handle user requests.

There are many books as well as articles that provide guidelines to design an effective Graphical User Interface (GUI) in order to enhance the user experience and the usability e.g. [17–19]. Xie et al. evaluated many trouble ticketing systems in 2004, however, all had design problems. Unluckily, the UI guidelines have not been applied in the current request tracking systems [1], including Best Practical RT System. Jiri Janak investigated UI of five request tracking systems [20]. Moreover, apart from better usability, User eXperience (UX), the possibilities of UI customization, UI as well as software extension, and collaboration features amongst user support staffs are very important in choosing the right help desk system. Another factor that should not be undermined is the distribution politics as well as community support.

In the last decade, the user-support in ESGF has been evolving mainly due to the changes in ESGF CI. For instance, looking at the history of ESGF development, due to the technological plus organizational changes and especially the introduction of new data projects served by the ESGF data archive system, the number of users and their needs have been on constant rise [6, 19–21, 24–27]. Consequently, up until now the employees of ESGF are performing the user support by handling incidents, on a free will basis, on top of their core infrastructure development activities/tasks. A recent survey questionnaire and mailing list analysis conducted revealed that up to 15 % of the incidents were ignored by the employees. Therefore a need to enhance ESGF user support was felt and as a part of result USWAM is suggested amongst other changes in the organisation and governance of ESGF.

3 Research Methods

The field studies were conducted at the German Climate Computing Centre (DKRZ) by eight groups of participants i.e. Masters students of Human Computer Interface (HCI) from the department of Computer Science of the University of Hamburg who agreed to conduct it. Field study is a systematic investigation of groups in their natural research area. In this case, it is the working environment of the support staffs at DKRZ. The field researcher must be integrated in the natural environment of the subjects to be observed. It is important that the researcher disrupt or interfere the workflow of the subjects (in our case: DKRZ support employees) as little as possible. Fieldwork is primarily descriptive. Fieldwork is a holistic view of the research object by discovering the overall context and existing relationships in it.

Each group comprising of four students, observed the support staffs (also known as user support workers) involved in processing user requests. The groups noted the advantages and disadvantages of GUI of the user request tracking software that the user support staffs interacted with in order to support users. The duration of observation was two hours. Based on their observations they criticized the current User Interface (UI) in practice and suggested enhancements in the UI of the requesting tracking system (RTS) in the form of a paper prototype (see Fig. 1 and Table 1). The groups had to follow the following research steps indicated in Fig. 1.

Fig. 1.
figure 1

The figure shows the four steps that the groups went through during this research.

Full size image
Table 1. The table shows the steps of research process, the input and output to each research step.
Full size table

In Table 1 the input to each step is shown in the second column under input and the research outcomes of each step is also shown. Each step is further described in Subsects. 3.1 to 3.5, respectively:

3.1 Observation

Researchers had to find out the advantages and disadvantages of the actual User Request Tracking Interface. The student researchers observed the working environment and the atmosphere of the user support unit at the German Climate Computing Centre (DKRZ), in which the user support staffs performed their work using the actual UI used in a particular Request Tracking System. The researchers observed the support staffs completing their tasks by especially paying attention to their individual behavior as they supported end-users by following a noted protocol of actions performed by user support staffs. The students noted their observations that became the basis for the prototypes. During the observation, important points were noted down in the form of notes.

3.2 Analysis

Right after the observation, notes were analyzed again to re-construct the advantages and disadvantages of the current RTS interface in use. The possible problems were described based on the information. Moreover, motivation to change the current interfaces in use was also noted.

3.3 Prototyping

Based on the experiences and knowledge which were gained in the first step a paper prototype was drafted. It focused on:

  • Handling the main problems of the current UI of RTS

  • Enhancing the actual functionalities of RTS based on, and

  • Proposing new functions

3.4 Evaluation

After prototyping, each group presented their prototype. The HCI student groups evaluated the prototypes of other groups by observing the proposed prototype carefully in guidance with Nielsen’s 10 heuristics for UI design [21] while the group presented the prototype to other groups. The groups then provided recommendations to improve the suggested UI prototype presented by each group.

The student groups went through the process of evaluating their own and each other’s prototype as well. Consequently, they had to enumerate advantages and especially the disadvantages of the presented prototypes in the form of a critique.

3.5 Recommended Changes

Based on the evaluation results, the participating research groups provided recommendations to improve their own as well as other’s paper prototype. This provided them an opportunity to share their ideas with other groups and integrate these ideas and perspectives they learned from other groups’ results.

Eventually, these recommendations were derived from each prototype to improve the interface of RTS. These recommendations are described in detail in the next section.

4 Results and Discussion

The authors observed the whole process of the groups and summarized the ideas of groups in the form of recommendations, grouped into the five sections shown in the Fig. 2.

Fig. 2.
figure 2

The figure shows the five areas. These areas depict the motivation of groups behind proposed UI prototypes, the unique as well as similar ideas that the groups had. “Prototype Evaluation” lists the problems with the UI prototypes that were made evident after the evaluation of each prototype belonging to a group. And finally the changes recommended by each group.

Full size image

4.1 Motivation

After looking at the results, the authors were able to find the basis of a motivation to change the current UI that was observed by the groups during the field study. The proposed prototype UI design by groups were based on the problems categorized as “no knowledge sharing”, “complex software UI design”, “problems with request delegation” and “prioritization of tasks.”

Group number 3, 4, 7 and 8’s prototype was based on knowledge sharing concepts. These groups were of the opinion that the user support staffs that use Request Tracking Systems (RTS) in a federated organization need to share more knowledge with other staff members and the RTS must provide such facilities. For example, a knowledge base can be made available about problems and incidents of users that can be shared with other staff members.

Similarly, group 5 based their UI porotype on priority of requests. They were of the opinion that the support staffs should be able to order the priorities of the user requests in an easy manner while interacting with the UI of an RTS. Alternatively, prioritization mechanism can be provided automatically in RTS. Group 1 and 8’s prototype was mainly based on the features of re-directing or delegating user requests to other federated partner institutions of ESGF.

Finally, groups 1, 2 and 6 were of the opinion that the UI design of RTS was very complex as right from the beginning it exposes its user to plethora of functions. Moreover, they suggested that simple UI design with lesser functions may be replaced e.g. like Google search engine.

4.2 Unique Ideas

Each group had their unique idea in their proposed prototype; these ideas are listed in the Fig. 2 under “Unique Ideas.”

  • Group number 1 had an idea of putting back requests that can be marked solved or unsolved by the direct intervention of users via a proposed interface to the RT system

  • Group number 2 introduced a drag and drop functionality in their paper prototype. The rationale for a drag and drop function was that it saves clicks and eliminates the complexity of interlaced or nested drop down menus

  • Group number 3 suggested a search engine where one can input the keywords defined by user support staffs or the keywords suggested by the users to find the solutions, workarounds in the database. These keywords can be symptoms that may be mentioned in a user request, based on which the matching solutions can be proposed or shown as search results. The examples are shown in Fig. 2. In Fig. 2, the mockup shows that a keyword was given and a solution was proposed by the system that had a relevance probability of around 99 %.

  • Group number 4 proposed that all requests and respective responses should be automatically saved into a wiki article, which can be used for learning or lookup purposes. This feature is however partially provided by the RT version 4.0.

  • Group number 5 came up with the proposal to introduce an inbuilt priority mechanism based on possible priority algorithms to prioritize tickets automatically and show those tickets in the form of visualization. The priority of tickets must be done according to relevant importance.

  • Group number 6 introduced various Web 2.0 elements in their prototype. The tickets are shown under each other which gave the UI a blog-like interface. Also support workers are able to give quick replies to a selected ticket (see Fig. 3)

    Fig. 3.
    figure 3

    A sample of the prototype made by a group of participants.

    Full size image

  • Group number 7 had the idea that tickets should be assigned and delegated to a respective expert of a federated partner within ESGF

  • Group number 8 suggested a traffic light principle. Green in a traffic light visualization stands for the workers with less requests, yellow for the ones with a lot of unanswered tickets and red for workers who are currently not able to handle user requests. Moreover, using this mechanism tickets are automatically delegated to the user support staff.

4.3 Similar Ideas

It was also noted that the groups had similar ideas that the system should automatically recommend a solution; a request priority algorithm can be introduced or embedded in RTS and finally an archive system or knowledge base that contains work arounds or solutions may also be introduced.

4.4 Prototype Evaluation

However, the prototypes designed by each group had some deficiencies in them which were pointed out by other groups in the evaluation phase. They are listed in the Figs. 1 and 2 under “evaluation” and “prototype evaluation” respectively. The changes recommended in the design of the UI prototype of each group are provided in the Fig. 2. It is expected that the changes in the UI and the back-end functionality of an RTS can help the user support staffs to perform better.

  • Group 2 was criticized for “too much steps” to complete a user interaction. This means that the user needed too many clicks until he performed a desired function.

  • The prototypes of group 3, 5 and 7 were both criticized for their lack of task categories, in a way that no classification of the tickets into categories was possible.

  • Group 4 was criticized for a lack of a flexible task handling

  • The UIs of the prototypes of group 6 and 8 were seen as too complicated, because of appearance of too many functions at once.

  • In the prototypes of group 1 and 7 confirmation notifications or other types of feedback when an action was performed, were absent. Consequently, the user would never know 100 %, whether his action has actually been successful.

  • On the other hand, group 8 attracted attention by his high number of confirmation notifications (even after simple and often repeated actions), which has effects the work flow of supporting a user. A reduction of the number of notifications shall be improving the user experience and UI.

4.5 Recommended Changes

The last phase the recommended changes about their own prototypes were collected from the student groups. It is necessary to add that these recommendations were mostly, but not always, based on the critique of phase 4 (prototype evaluation). In this way the student groups sometimes also adopted ideas of other groups which they got to know during the presentations in phase 4.

  • Group 1 suggested to build a clearer description so that functions are immediately comprehendible for a user

  • Group 1 and group 2 were of the opinion to enhance the UI of their prototype by simplifying it. Moreover, they reiterated that only the most important functions shall be immediately visible in a particular UI

  • Group 5 and 6 suggested breadcrumb navigation. This shall provide the support staff the ability to see the history of invoked functions and to possibly return to a previous step

  • Group 6 suggested a dashboard with interesting facts and figures about the summary status of current user support situation (e.g. average response time) on the initial screen. This could for example include the number of requests answered today, a ranking of the user with the most solved tickets and other pertinent facts that may increase the motivation of the user support staffs.

  • Groups 3, 7 and 8 recommended adding a searchable database to their prototype. This is an idea that was possibly borrowed from other groups after the presentation of each prototype

  • Also group 7 suggested implementing embedded confirmation notifications after the user completes an action. They are clearly shown within the RT web UI, but do not appear as a separate window.

  • Group 4 suggested a more flexible task handling.

5 Future Work

In future a complete prototype that integrates all the interesting and important features of other prototypes as recommended by the groups shall be built as a mock-up and finally implemented in the form of a software prototype. Furthermore, this software prototype shall be tested with the user support staffs of ESGF before putting into production.

6 Conclusion

In this paper the field study method was applied to observe the user support staffs using UI of the best practical RT trouble ticketing system in a federated e-Science environment. The study was conducted by eight groups of students of HCI. After conducting field observations, each group had their unique idea in their proposed prototype. Examples include: Drag and drop, search engine, wiki articles and others. These ideas are listed in Fig. 2 under “Unique Ideas.” It was also noted that the groups had similar ideas e.g. the RT system should automatically recommend a solution, see Fig. 3. Moreover, a request priority algorithm can be introduced or embedded in RTS and finally an archive system that contains solutions or work arounds may also be introduced. Yet, the prototypes designed by each group had some deficiencies in them which were pointed out by other groups. The changes recommended in the design of the UI prototype of each group are summarized at the bottom of the Fig. 2. In a nutshell, the changes in the UI and the back-end functionality of an RTS can help the user support staffs to perform better.