A Web-based Visualization Tool for Marine Vessel Scheduling

Transcription

1 A Web-based Visualization Tool for Marine Vessel Scheduling by Di Lu B.Eng., Beijing University of Posts and Telecommunications, 2011 A Project Report Submitted in Partial Fulfillment of the Requirements for the Degree of MASTER OF SCIENCE in the Department of Computer Science Di Lu, 2014 University of Victoria All rights reserved. This thesis may not be reproduced in whole or in part, by photocopy or other means, without the permission of the author.

2 ii Supervisory Committee A Web-based Visualization Tool for Marine Vessel Scheduling by Di Lu B.Eng., Beijing University of Posts and Telecommunications, 2011 Supervisory Committee Dr. Melanie Tory, (Department of Computer Science) Supervisor Dr. Stephen W. Neville, (Department of Electrical and Computer Engineering) Departmental Member

3 iii Abstract Supervisory Committee Dr. Melanie Tory, (Department of Computer Science) Supervisor Dr. Stephen W. Neville, (Department of Electrical and Computer Engineering) Departmental Member In this project report, we present an interactive web-based visualization tool that aims to provide an effective representation of vessel schedules for Seaspan Ferries unique needs. The tool delivers a set of clear schedule charts while addressing the shortcomings of traditional schedule tables and charts such as traditional Gantt charts. It supports different views of schedules to make them more comprehensible. It also utilizes overview + detail techniques to help users inspect details while maintaining awareness of the context. These representations allow users to actively interact with data within a particular time frame. As a detailed introduction to the tool, we also describe each step of the entire design and development process, and the trade-offs of design decisions that we made. In the end, we summarize the strengths and limitations of our tool as well as the future work.

4 iv Table of Contents Supervisory Committee... ii Abstract... iii Table of Contents... iv List of Tables... v List of Figures... vi Acknowledgments... vii Dedication... viii Chapter 1 Introduction... 1 Chapter 2 Related Work... 4 Chapter 3 Design Process Problem Identification Mock-up and Requirements Refinement Implementation and Evaluation... 7 Chapter 4 Requirements Analysis Basic Elements Core Requirements Additional Requirements Chapter 5 General Design Visualization Design Vessel View Berth View Overall UI Design Chapter 6 System Workflow Overall architecture Case Illustration Chapter 7 Discussion and Lessons Learned Chapter 8 Conclusion and Future Work Bibliography Appendix: List of paper mock-ups... 33

5 List of Tables v

6 vi List of Figures Figure 4.1: Traditional schedule table... 9 Figure 4.2 Mock-up # Figure 4.3 Mock-up # Figure 4.4 Mock-up # Figure 4.5 Mock-up # Figure 5.1: Visualizing sailings as rectangles Figure 5.2: The detail chart in Vessel View Figure 5.3: The complete interface of the Vessel View Figure 5.4: The Berth View Figure 5.5: An initial interface Figure 5.6: Three results of processing a demanding file Figure 6.1: Overall System architecture... 25

7 vii Acknowledgments I would like to express my immeasurable thanks to those people who had been of great help during this unusual period of time. This project would not be successful without their guidance and support. I have the deepest gratitude to my supervisor, Dr. Melanie Tory, for offering her meticulous help all the way, from accepting me as her student to finishing my degree. She is nice and supportive with my graduate studies and is providing valuable comments and suggestions to this project and report all the time. Being her student is always a pleasurable experience. Also, I would like to thank the members of this project team, Dr. Yağız Onat Yazır and Dr. Stephen W. Neville for their kind guidance and support throughout this project. In addition, I am heartily grateful to my fellow labmates for being nice and helpful to my research. Especially Dandan Huang is such a great advisor in every aspect of my graduate study and I owe her a lot. The one-year time with this project has been a bittersweet and unforgettable experience to me both in school and out of school. I give my sincere gratitude to my parents and all my friends for helping me out via real life contact and long distance connection.

8 viii Dedication Dedicated to: My mother, Binghua Jiang My father, Zhibing Lu

9 Chapter 1 Introduction Seaspan Ferries Corporation is a commercial ferry service providing regularly scheduled transportation services connecting Vancouver Island and British Columbia s lower mainland. Seaspan Ferries operates over 1.25 million trailers and 35,000 trips annually. With the growth of customer demand, Seaspan was seeking to replace its current manually computed scheduling approach with an automated solution that satisfies the following conditions: (i) it can be easily understood and maintained, (ii) it is capable of providing an optimal or near-optimal solution, (iii) it allows flexible changes when the schedule is influenced by various conditions, and (iv) it should be a reasonably mature product for industrial usage. Seaspan Ferries approached UVic to develop a working prototype solution to meet the above goals. Seaspan requested to generate schedules for seven vessels transporting goods among five terminals. Among the five terminals, two are located on the mainland and three are on Vancouver Island. Each vessel/tug varies in capacity and speed and sails between those terminals. The challenge we were facing can be divided into two sub-problems: How to generate theoretically optimal schedules with given conditions, and how to best represent the schedule data by applying state of the art visualization techniques. We envisioned the solution to be a web application that can be deployed inside Seaspan s server. In particular, the web application should consist of a back-end server that optimizes vessel scheduling and a front-end interface that shows visualizations of schedule data. Within our research project team, our collaborators Dr. Yağız Onat Yazır and Dr. Stephen W. Neville were in charge of generating optimized schedules in the back-end, while we built the front-end visualization. This project report addresses the

10 schedule representation challenge, and we will mainly focus on the design of 2 visualizations of the optimized schedule. Managing vessel schedules with respect to customer demand can be a challenging task, especially when it is further complicated by unpredictable conditions like weather. The problem can be categorized as a job shop scheduling problem in the operations research field and is proven to be NP-complete for m>2, that is, no optimal solution can be computed in polynomial time for three or more machines (m) (in our case equivalent to three or more vessels) [1]. Previously, Seaspan s personnel generated schedules manually, based on conventions and experts experience; however, Seaspan recognized the opportunity to optimize their operations with a computer-generated optimal schedule. Most schedule activity representations are created within two axes: a permutation of activities and a timeline. One of the most common approaches to represent time-oriented data is Gantt chart [2]. Despite being created a century ago, variants of Gantt charts are still widely applied in many applications. Adaptations exist to circumvent the original s limitations, such as Marey s train schedule [3] and VisRuption [4]. Accordingly, the basic visual design of Gantt charts gave us inspiration for our initial sketches, as we will describe in chapter 3. Meanwhile, Gantt charts do have a few downsides as people discussed in [5]: poor utilization of space, a lack of substantive detail, and difficulty of showing dependencies that don t appear on the same screen. Since Seaspan s schedules involve only a small number of vessels, the ideal solution should be a one-screen web application that shows all essential details that users can interact with. Thus one visualization challenge we had was to deal with screen space limitation. With a compact and clear schedule overview,

11 the users can get immediate visual feedback and keep good awareness and even 3 manipulate visual elements at a glance. Overview plus detail [6] and focus plus context [7] techniques help to make interfaces quite space-efficient; therefore our design incorporates some of these ideas. However, none of the existing visualization techniques directly solved the vessel scheduling visualization problem at hand. Therefore, in this report we propose our own case-specific design that effectively represents the schedule data, by applying and adapting a combination of existing approaches. Our goal was to design and develop a standard web interface that can effectively visualize the data, and finally deliver a software tool that works in conjunction with the back-end server. In this project report, we begin by reviewing the overall process of designing and developing the visualization interface. First we discuss the limitations of Seaspan s existing schedule representation and describe the requirements that were refined in the end, including essential elements that comprised the visualization design. Then we introduce the general design and interactive mechanism that supports overview plus detail awareness. Afterwards, we briefly demonstrate how the system works to help users generate schedules. Finally the discussion and conclusion section summarizes our accomplishments and points out some future work that would further enhance the flexibility and functionality of our tool.

12 4 Chapter 2 Related Work Gantt charts have been extensively employed to support project management, and mainstream project management tools such as MS Project and GanttProject [8] include Gantt charts as a central component. In research, Aigner et al. proposed a technique called PlanningLines [9], which addressed the flexibility of activity timing in Gantt charts. Furthermore, Huang et al. presented follow-up techniques to support the comparison of Gantt charts [10]. Those improvements to Gantt charts, however, cannot cover their innate shortcomings, including a lack of representation of detail and sparse use of screen real-estate. To resolve some of those drawbacks and utilize space more efficiently, Luz et al. devised Chronos [11], a visualization tool that employed a temporal mosaic display as a basic user interface element. The mosaic display was more space efficient than a traditional Gantt chart display and supports viewing different levels of detail while maintaining awareness of context. Gantt charts are well suited to displaying schedule information in project management. But there are many other types of time-oriented data, for which other dedicated visualizations are required. A systematic survey of state of the art visualizations for timeoriented data was given by Aigner et al [12]. There have been several applications in visualizing temporal data in a variety of domains. The LifeLines project [13] was a milestone work. It not only proved to be intuitive for visualizing personal histories in medical applications, but also was able to help users detect patterns by summarizing a large dataset. For calendar applications, Faulring and Myers [14] introduced the availability bar to help users schedule meetings with complex calendar scheduling constraints. In particular, one visualization tool that

13 drew our attention was proposed by Rosenthal et al. [4]. The data it visualized were 5 airline operation problems which could occur every day. The time-oriented data in that paper (related to airlines) had similar attributes to our own schedule data (sailings), such as time and priority. Finally they used a graphical fisheye view to address the screen real-estate problem. To date, little research has been done on job shop scheduling visualization. An early study by Baek et al. [15] used a scheduling system (similar to today s MS project) to help schedulers do job shop scheduling. The research found that if a computer-generated schedule was incoherent to human problem-solving strategies, the result turned out to be less effective than expected. A graphic interface was effective and promising provided that the design was well matched to human strategies. This paper highlighted that both the optimization strategy running in the back-end and the visualization design on the front-end should be case-specific and user-centered.

14 6 Chapter 3 Design Process Our project was developed through a user-centered process over six months. Our target users were employees from Seaspan Ferries, especially the schedule manipulators from the Vessel Operation team. The visualization tool was designed in close collaboration with those domain experts. A general manager and a project manager were actively involved throughout the project; they provided schedule expertise and evaluated the proposed visualization prototypes. The design process was organized in three phases: problem identification, mock-up and requirement refinement, and implementation and evaluation. 3.1 Problem Identification In the first stage we had a face-to-face meeting with experts from Seaspan Ferries at the Vancouver office to understand the problem space and extract basic requirements. We ran several activities to facilitate our initial understanding of the problem space. We held a research team meeting prior to meeting the company. During this internal meeting, we outlined our challenge and defined the task breakdown. For the visualization design part we collected a list of questions to ask for the upcoming meeting. For the first meeting, our target users introduced us the current overview of scheduling considerations. Aside from talking about technical specifications and vessel sailing constraints, they seemed not to have a fixed concept of the desired visualization. Given such a situation we decided not to ask them their ideal visualization model. Instead, we asked for current schedule representations to discuss their strengths and weaknesses. That helped us extract basic visual elements from the existing schedule

15 7 table. By the end of the meeting our team set up milestones for the next meeting, where we would present a couple visualization mock-ups to find out their preferences. After the meeting they ed us paper documents that helped us better understand the problem background and requirements. was often the most common communication approache that helped us bridge the gap between two domains. By the end of this phase, our team developed abstractions of the data and tasks. On the visualization side, we derived a basic requirement set for the upcoming mock-ups. 3.2 Mock-up and Requirements Refinement After we collected all the information from the previous stage, we designed and presented seven paper mock-ups to the experts at Seaspan Ferries. Among the seven mock-ups, they preferred two of them and gave us feedback on how some elements should be improved to better express the information they held. We then repeated this process of mock-up design and review several times. The iterative mock-up discussion and refinement lasted one month. It seemed interesting that most requirements were extracted halfway through the process, compared to only a few at the beginning. Integration of the two best candidate mock-ups resulted in the blueprint for the working prototype. 3.3 Implementation and Evaluation Before we started with implementation, we investigated current state-of-the-art visualization libraries such as Flare, Raphael and D3.js. Eventually D3.js became the toolkit that we decided to use for its flexibility and large user base. A first prototype was implemented and evaluated informally by users at Seaspan Ferries. We revised the

16 prototype based on their feedback for several rounds. For now the working model is 8 being plugged into the server side and made available for internal test by the staff from Seaspan Ferries. Regardless of some minor deployment problems, the feedback come from our users for the visualization tool are mostly positive. The server side of the system, which is the schedule generator, was developed by our project partner Dr. Yağız Onat Yazır.

17 9 Chapter 4 Requirements Analysis In the previous chapter we mentioned that the requirements were extracted during three stages of the design process. In the first stage, we studied the existing schedule representation and derived basic visual elements. Then we refined some core features during the iterations with our paper mock-ups. The last stage was the prototype review with Seaspan s domain experts. 4.1 Basic Elements The goal of designing our visualization tool was to amplify user s (in this case Seaspan staff) understanding of the optimized schedule by giving an explicit visual representation of the schedule data. Figure 4.1 shows a general schedule layout that Seaspan previously adopted. From a user experience perspective, there are several downsides to this layout: 1. The schedule is organized by day. However this is a confusing division since night shift is quite common because of their customer requests. For instance, the return trip on Monday for vessel FL is actually on Tuesday. This may lead to possible confusion if the user does not look at the schedule from a weekly perspective. Figure 4.1: Traditional schedule table

18 10 2. There is no direct information on the length of the sailing or the waiting duration. The transit time is relevant to cost estimations. The waiting duration between the outbound and inbound sailing is crucial to the crew members, as the Masters on the 24 hour vessels are required to have a minimum 6-hour rest period. 3. The flexibility is seriously restricted with a purely textual layout. Although this layout reduces redundancy by compressing the weekdays that have the same schedule, it will be cumbersome for the manager to generate schedules that encompass changing demands. Overall, the fundamental problem of the traditional schedule is: the sailing information contained in the table is not clearly apparent to its audience. We attribute it to multiple reasons: 1. Due to limited space on paper, the schedule is represented in a way that is incoherent with humans mental model. The traditional schedule arranges each day in vertical order, which might contradict people s impression that in a calendar, days are arranged in horizontal order. 2. It may take extra effort to understand the schedule as a big picture. In Figure 4.1, as the schedules from Tuesday to Thursday are the same, a schedule of three days is compressed into a schedule of one day. However, this inconsistency may require a user s extra attention to notice that schedules are actually compressed. Given the fact that the new automatically derived schedules will be inconsistent from day to day, a visualization for each individual day becomes necessary.

19 11 3. Certain information is not represented (or at least not explicitly represented) in the table-based schedule. Missing information includes vessel wait times, occupation of berths, and vessel capacity utilization. According to the above analysis, there are three essential elements for a vessel schedule: time, vessels, and terminals. Time is a numerical element and vessels and terminals are ordinal. Combining these elements in different ways could provide useful information from different perspectives. For instance, a combination of time and terminal could be the vacant/occupied period of one terminal, or the timestamp when one terminal starts to load trailers. Those help the people working at the terminals maintain up-to-date awareness of the situations on the coastal area. 4.2 Core Requirements Although the goal of our visualization tool was to provide a clear and intuitive representation of schedules, our target users were only a few members from Seaspan s personnel. With those basic elements confirmed, initial paper mock-ups were created based on time, vessels, and terminals. We will shortly discuss mock-up #1, #3 and #4 and how we made changes to these mock-ups. All the mock-ups can be found in the appendix. Figure 4.2 shows the first paper mock-up that we designed. It was using a time vessels paradigm. The vessel names were aligned at the top time proceeded from top to bottom. The bar in the middle zoomed in / zoomed out nearby

20 12 Figure 4.2 Mock-up #1 sailing schedules so that area above the bar revealed details of every single sailing while the area below the bar gave an overview of the rest of the sailing schedule. The layout of mock-up #1 was approved by Seaspan, as the zooming technique helped save space, but they preferred a horizontal orientation, as designed in mock-up #4. Mock-up #3 is shown in Figure 4.3. The idea behind this mock-up was that every sailing was part of a round-trip, and we built a round-trip view for all the sailings. Terminals were represented in circles and sailings were visualized as arrows. The length Figure 4.3 Mock-up #3

21 13 Figure 4.4 Mock-up #4 of the arrows told the duration of a sailing and users could select a date range by clicking the weekday grid at the bottom. One feature of this mock-up was it provided comparisons both between round-trips and different routes. A potential problem with the view was that there were many sailings, whose durations extended across two days, e.g.: from 22:00 to 1:30am on the next day. It was not easy to specify a time range to look up. In the end, this mock-up was discarded in favour of mock-up #4 and #1 because our users were less familiar with this one. Mock-up 4 (Figure 4.4) was a highly experimental design. We tried to adapt a source and sink paradigm to visualize the schedules. The arrival terminals were regarded as sinks and the departure terminals were sources. The dark stripes represented the sailings between departure / arrival terminals. We expected this design would serve as a sideline view to the other mainstream designs since it put more emphasis on routes. But based on feedback from Seaspan, this design was not implemented because it did not provide a useful abstraction from the target users perspective.

22 14 Figure 4.5 Mock-up #5 Mock-up #5 (Figure 4.5) was a version 1.0 of the final design. We used triangles to represent sailings and the direction indicated whether it was an outgoing trip or return trip. What made mock-up #5 different from the previous mock-ups was that it added auxiliary panels. The grid chart at the bottom explained the utilization of the warehouse for each terminal, and the Transit Details showed the information from a particular sailing (on which the mouse was hovered). It avoided a strict delimitation of one full day and so users could see sailings that ran across midnight more easily. This mock-up was accepted by Seaspan. But while we implemented the design, we made several tweaks to make it more practical. The final design is elaborated in chapter 5. After paper prototyping, we started off the several rounds of evaluation by the experts and redesign. The following were the requirements we derived from their feedback: 1. It must provide an effective overview of the schedule over a reasonable timeframe. The timeframe could be a schedule service cycle (e.g., one week) or a particular period (e.g., holiday).

23 2. The visualization should be easy to understand for Seaspan scheduling 15 personnel. 3. From a finance perspective, it would be useful to reveal cost information, including but not limited to actual cost estimate, vessel space utilization and minimum acceptable vessel utilization. That information should be incorporated into visual elements as well. 4. From an operation perspective, inter-sailing information was necessary to the operators. Inter-sailing data referred to information between two consecutive sailings. The duration from when a vessel arrived until it departed again, and the time gap between two vessels arriving in a row, were useful information but somehow hidden in the traditional schedules. 5. Hierarchical views were preferred. Aside from overview requirements in #1, Seaspan also wanted to be able to request details about a single sailing. 6. Besides hierarchical views, different perspective views could make the schedule more comprehensible. The traditional schedule was vessel-centered, but a combination of vessel centered and berth centered views seemed to provide more comprehensive information. 7. We expected that data would be viewed in an interactive way, given that there were multiple views. 4.3 Additional Requirements One additional requirement Seaspan requested was to make the visualization charts and schedule data printable. This would enable personnel to use the schedules offline and away from their desks.

24 Another requirement they requested was to have an interaction with the server to 16 customize the visualized schedule directly through the web page. Once implemented, this would allow users to play with schedule data to change existing schedules to better fit into their practical needs. Although this initially seemed to be trivial to implement, it indeed required a lot of effort to be done both on the client side and server side. We had to put this feature into future development. In retrospect, our tool satisfied all the basic and core requirements, and partial additional requirements.

25 17 Chapter 5 General Design In this chapter we first describe the details of how we designed each component in our visualization tool strictly respecting the requirements from chapter 4. Afterwards, we give a brief introduction to our tool s user interface design as a preview to the system workflow for the upcoming chapter. 5.1 Visualization Design Initially we decided to make 2-element combinations out of the three main data components, namely we had time vessel, time terminal and vessel terminal views. However, by the time we started to create paper mock-ups we realized the combination vessel terminal would not make much sense because it focused on route information that was not critical to understanding the schedule. Therefore, we created two views, Vessel View and Berth View, which were based on time vessel and time terminal respectively. The Vessel View was displayed as default and the Berth View was accessible via a tab Vessel View The Vessel View was designed with the idea of time vessel. In general, for timeoriented data it is almost inevitable to distribute data along with a timeline. Household time-oriented charts, such as Gantt charts or calendars, are very straightforward and easy to use. Among the paper mock-ups we proposed to Seaspan, visualizations without timeline were considered too complicated and not used to it from experts verbal feedback.

26 We presented two similar time-oriented mock-ups (see Appendix: mock-up 2 and 18 mock-up 3) that differed in direction. One was race view : vessels were aligned side by side along a horizontal axis, and the time axis was vertical so that the sailings were scattered from top to bottom. One advantage of this layout was it could display a wide range of time as user scrolled down the page. The other one was a rotated version of previous one: vessels were aligned along the vertical axis and the timeline was the horizontal axis, and within these two axes sailings were distributed. The timeline was bounded by a fixed time range (e.g., one week) and overall it looked similar to a calendar so we named it calendar view. Discussion with usability experts revealed that the calendar view would be a more appropriate choice given that (i) the design was more consistent with the previous layout that Seaspan staff were familiar with, and (ii) The race view would cause space shortage issue if the number of vessels increased. After the framework had been specified, visual encoding choices were being considered. Ideally, each sailing element should convey the following information within Vessel View: the vessel name (already provided on the vertical axis), the departure time/terminal and arriving time/terminal, the transit time, and the utilization of the vessel (Core Requirement #3). Eventually we decided to incorporate all the above information into a labelled rectangle. The annotations for a labelled rectangle are described in Figure 5.1. The location of text inferred the direction of a sailing (a sailing travelled from the location named at the upper left corner to the one at the lower right corner). The relative transit time of each sailing was indicated by the width of the rectangle through comparison with other rectangles.

27 19 Figure 5.1: Visualizing sailings as rectangles. (a) A labelled rectangle box contained the following information: The departure terminal N and departure time 00:45am, the arriving terminal T and expected arriving time 4:00am. The green color indicates it is on the Tilbury Nanaimo route and it has a utilization ratio up to 75%. (b) The legend of color encoding Another feature of the rectangle was the color encoding we applied. We borrowed three color schemes from ColorBrewer [16]. Hue and saturation were deployed for routes and utilization ratio respectively. Utilization ratio was an important factor for senior staff in decision-making and hence it was important to make this information very salient within the display. The layout of Vessel View is analogous to a Gantt chart organized by vessel (y axis) and time (x axis) (see Figure 5.2).

28 20 Figure 5.2: The detail chart in Vessel View: It shows a schedule of one full 24 hour day (starting just before midnight) with 7 vessels (represented by abbreviations on the y axis). The grey bars delimit every 6 hours. However, while we were implementing the prototype we found it was impossible to view all the sailing details in one screen. To tackle this problem we employed an overview + detail technique for the view of a single sailing (Core Requirement #5). As illustrated in Figure 5.3, we used two coordinated charts (Overview chart and Detail chart) instead of one. The chart on the right was Overview chart. It gave an overview of all the sailings with textual details omitted in a fixed time frame. The overview chart still kept the color encoding of sailings, and meanwhile we highlighted the intervals between each sailing to indicate the time duration from the previous arrival until the next departure (Core Requirement #4).

29 21 Figure 5.3: The complete interface of the Vessel View. The Overview Chart shows schedule data in a weekly perspective (middle). A grey focus region can be selected in the Overview Chart and shown in greater detail within the Detail Chart (left). The time was revealed in a tool tip upon hovering the mouse cursor over an interval. An overview + detail interaction mechanism was also applied here. A grey box was added on top of a certain time period and it supported navigation through panning and zooming. Dragging and dropping this grey box to a specific point in the overview timeline would show this portion of the timeframe in detail within the Detail chart at the left. The detail view had already been described in Figure 5.2. This overview + detail mechanism enabled a detailed inspection while maintaining an overview over a wider period of time. Even with this rich exploration of schedule data, some concrete data still remained to be displayed. We set up an information panel to the right of the Overview chart to print out the cost and utilization ratio with respect to each of the vessels. In the end, a legend of color encoding was fit into the top right corner of the entire interface.

30 22 Figure 5.4: The Berth View. It shows the berth occupancy status over a certain period. E.g.: The berth at the Swartz Bay terminal is occupied by vessel CS from 02:30 to 04:30 on Day Berth View The Berth View was a corresponding solution to Core Requirement #6, and it conveyed some missing information from the Vessel View. The goal of presenting the Berth View was to show the real-time status of all the operating berths. As illustrated in Figure 5.4, there were three waiting berths and two loading/offloading berths in Tilbury terminal, namely from Tilbury W1 to Tilbury L2, and the other five berths were listed sequentially. The Berth View followed the same design pattern as the Vessel View, using the same overview + detail technique. It had less information to visualize than the Vessel View: only the time and vessel name. The green texts on the center of each rectangle were the vessels that were staying at this berth. Each grey box represented the stay-over time within a berth for a particular vessel.

31 5.2 Overall UI Design 23 We incorporated both the Vessel View and Berth View into one interface as they complemented each other. Meanwhile, we developed important interface controls and options to guide the user to use the system. Figure 5.5 is the main interface of our system. The workflow of our system is described in chapter 6. Figure 5.5: An initial interface before the user uploads a demanding worksheet. A typical workflow is (a) upload worksheet to generate schedules. (b) Select corresponding schedule files from archive to view. (c) Switch between Berth View and Vessel View to see the schedules With valid user input, all the information is displayed on a one-screen web page. However, if the user demands exceed the capacity of vessel operations, we prompt the user to change the input. As a result, we added three error-handling pages that prompted the user to proceed if the generator was unable to create schedules. Figure 5.6 shows these three web pages: successes (Figure 5.6 a.), warnings (Figure 5.6 b.) and errors (Figure 5.6 c.).

32 24 Figure 5.6: Three results of processing a demanding file: (a) successful, (b) warnings given and (c) errors given.

33 25 Chapter 6 System Workflow In this chapter we describe the workflow of our system (schedule generator combined with visualization interface). 6.1 Overall architecture Our system consists of two modules (see Figure 6.1): client side and server side. The client side works as an interface with a visualization engine. It takes the user s input and directly passes it to the server side. Meanwhile, the schedule generator on the server side analyzes the input and run algorithms to generate the optimized schedules. Then the schedules in JSON format will be fetched by the client side and later represented by the visualization tool. The schedule generator is written in Python. The client side web interface is written in JavaScript that utilizes the visualization engine, D3.js [17]. The whole system is a stand-alone web solution that can be deployed on any web server. Client Side Server Side Web Browser Ask data to display JavaScript Engine D3.js Document Object Model (DOM) SVG Schedule generator Schedule data JSON data sent back to be displayed in Demand Worksheet Export schedules User Parsing data Figure 6.1: Overall System architecture

34 6.2 Case Illustration 26 Suppose our user (a Seaspan employee) is requesting a new schedule and the demands are given, the workflow to generate the schedule visualization is described as follows: 1) The user fills out the standard input worksheet we specify. The worksheet contains a set of specifications about vessels and terminals as well as transportation requests from Seaspan customers. 2) The user visits the server URL and the interface will be shown as in Figure 5.5. Following the instructions the user uploads the worksheet and awaits the system s response. 3) Once the file is uploaded successfully, an error checker will pre-process the file to examine whether any improper demands or errors exist. If the file passes the preprocess step, the schedule generator will be executed and generate schedules. The whole process lasts for a few seconds until it succeeds or reports errors (and it will redirect the browser to the error-handling page). 4) When schedules generate successfully, they are stored in an archive directory and can be accessed using the drop-down menu on the right. In the end, the user can see the schedule by selecting the archive file that shares the same name with the demanding worksheet, and then picking a schedule in a secondary drop-down menu. A visualization of the schedule is finally presented to the user. 5) If the file fails to pass the error checker, there could be two reasons: (1) there are some syntax errors which make it impossible to run the file. In this case, the user will be notified about which cell(s) caused the error, and has an option to download

35 27 the original file with error cells marked out. (2) The demanding worksheet has no syntax error except for some impractical data (e.g., overload capacity on one vessel) that could possibly result in no feasible schedules. In this situation, the user will receive similar instructions plus an extra option to still run the generator. If a set of schedule data is generated successfully, there is also an option to download it as a human readable worksheet (the download button is located in the top right corner of Figure 5.5). Ideally, a user can view the schedule data in two ways: visualization charts and human-readable worksheet.

36 28 Chapter 7 Discussion and Lessons Learned As a schedule visualization solution that was designed specifically to meet Seaspan s scheduling needs, initial feedback indicates that our system (both the generator and visualization tool) generally provides a handy and intuitive way to make and manage sailing schedules for Seaspan s personnel. Compared to manually creating schedules with pen and paper or spreadsheets, our new approach automates the process and is expected to reduce costs. In general, our domain experts from Seaspan were satisfied with the visualization tool. According to their remarks, the overview interface was straightforward and the overview + detail interaction was self-explanatory. By viewing an overview chart of a periodic (weekly) schedule, users can gain a concrete idea about the schedule presented. Moreover, further analysis of the overview chart can help users to infer in-depth information. For example, through the number of rectangles we can tell if the schedule is tight or loose, and that can reflect the sales in some sense. Also, the colors identify which route is more popular, which could help with market research planning. The distribution of rectangles might indicate the types of customers: Do the customers belong to daily grocery stores that request shipping every day? Or if their requests only happen on weekdays that could imply that they are institutions that close on weekends. The statistics in the information panel give a direct report on cost and utilization; thus, the visualization tool can work not merely as a representation of schedules, but also as an analysis tool that can be referenced by the financial department and even senior staff.

37 The schedule visualization tool was a successful example of applying existing 29 visualization techniques to a new problem. We borrowed the basic framework from Gantt charts, and made some adaptations to fit Seaspan s problem. Regarding the old schedule table from Seaspan, our new visualization makes it easier to understand more complex schedules (e.g. irregular ones) and can encompass additional information including utilization and wait times. Combined with the back-end generator, we expect Seaspan users will have a brand new way to formulate and comprehend their schedules with the help of this application. To our knowledge, we are the first to present an application for visualizing marine transportation schedule data; the visualization diagram we built will provide an example for future work in this field. Also, a formal feedback is expected from Seaspan s experts. By now our system has been delivered to Seaspan but it is still in an internal testing stage. As we mentioned in chapter 3, many of the design requirements were finalized during the iterative discussions, after the initial designs were proposed. In a survey paper proposed by Maguire and Bevan [18], they report that user requirements will evolve as the system develops and more formal user evaluation takes place. As a matter of fact, it was not until the testing stage that some new required features were identified.

38 30 Chapter 8 Conclusion and Future Work The design of our visualization tool has addressed several limitations of Seaspan Ferries previous schedule representation. The visualization design was proposed corresponding to requirements that were tailored in an iterative process. We implemented this design by building a web application using the D3 JavaScript library. It supports viewing shortperiod schedule information while maintaining awareness of context, and it displayed a schedule from vessel-centered and berth-centered views. In all, the visualization tool sufficiently satisfies the requirements that we identified. In terms of future work, there are plenty of new features that could be added to this visualization tool. For instance, in addition to presenting users with existing schedules, schedule manipulations could be activated directly within the visualization interface to allow users to play with the schedule. Ideally, the user might want to be able to adjust a specific sailing time based on business needs and the system should then be able to validate whether it would still be a near-optimal schedule. This idea would truly achieve computer-assisted scheduling (with a human scheduler involved) as described in [15]. Up to this point, our system provides a base initial schedule that requires human schedulers to do further optimization after considering their practical needs and adjustments.

39 31 Bibliography 1. The complexity of flowshop and jobshop scheduling. Garey, Michael R., David S. Johnson, and Ravi Sethi. 1976, Mathematics of operations research, pp Gantt, Henry Laurence. Organizing for work. s.l. : Harcourt, Brace and Howe, Chakravarti, Aravinda. A graphical representation of genetic and physical maps: the Marey map. Genomics. 11 1, 1991, pp VisRuption: Intuitive and Efficient Visualization of Temporal Airline Disruption Data. Rosenthal, Paul, et al. s.l. : Blackwell Publishing Ltd, Computer Graphics Forum. 5. Tufte, E.R. Project management graphics (bulletin board). [Online] [Cited: 03 01, 2014.] e.com/bboard/q-and-a-fetch-msg?msg_id= The perspective wall: Detail and context smoothly integrated. Mackinlay, Jock D., George G. Robertson, and Stuart K. Card. s.l. : ACM, Proceedings of the SIGCHI conference on Human factors in computing systems. 7. A focus+ context technique based on hyperbolic geometry for visualizing large hierarchies. Lamping, John, Ramana Rao, and Peter Pirolli. s.l. : ACM, Proceedings of the SIGCHI conference on Human factors in computing systems. 8. Barashev, Dmitry, and A. Thomas. The gantt project. [Online] [Cited: 03 01, 2014.] 9. PlanningLines: novel glyphs for representing temporal uncertainties and their evaluation. Aigner, Wolfgang, et al Ninth International Conference on. IEEE. 10. Visualization techniques for schedule comparison. Huang, Dandan, et al. s.l. : Blackwell Publishing Ltd, Computer Graphics Forum. 11. Chronos: A tool for interactive scheduling and visualisation of task hierarchies. Luz, Saturnino, et al. s.l. : IEEE, Information Visualisation. 12. Visualizing time-oriented data a systematic view. Aigner, Wolfgang, et al Computers & Graphics pp

40 13. LifeLines: visualizing personal histories. Plaisant, Catherine, et al. s.l. : ACM, Proceedings of the SIGCHI conference on Human factors in computing systems Availability bars for calendar scheduling. Faulring, Andrew, and Brad A. Myers. s.l. : ACM, CHI'06 Extended Abstracts on Human Factors in Computing Systems. 15. A visualized human-computer interactive approach to job shop scheduling. Baek, Dong H International Journal of Computer Integrated Manufacturing pp Harrower, Mark, and Cynthia A. Brewer. Colorbrewer.org: An online tool for selecting colour schemes for maps. The Cartographic Journal. 2003, pp D³data-driven documents. Bostock, Michael, Vadim Ogievetsky, and Jeffrey Heer. 2011, Visualization and Computer Graphics, IEEE Transactions on 17.12, pp Maguire, Martin, and Nigel Bevan. User requirements analysis. Usability. s.l. : Springer US, 2002, pp

41 33 Mock-up 1: Appendix: List of paper mock-ups Mock-up 2:

42 Mock-up 3: 34 Mock-up 4: Mock-up 5:

43 35 Mock-up 6: Mock-up 7: