Design

With the new information provided by Miroslav, we redesigned the detail view part of the GUI, where we previously had the visualizations that we initially decided on. Miroslav provided us with five examples on different visualization that could be applied to the classifications introduced in Chapter 2 section 2.1.2 that the experi-mentalists at WACQT deemed useful. In addition, we also got a table of keys and what classification type the keys belonged to.

3. Design of web interface

The visualizations could now be applied to the 5 different classifications:

• Type 1: A visual representation of the qubits and couplers.

• Type 2: A Histogram.

• Type 3: A box plot.

• Type 4: A Line graph.

• Type 5: A City plot.

The new mock-up for the type 1 visualization is displayed in 3.7. It is similar to the one we had in version 1 of the design. However, instead of combining both the qubits and the couplers into one bit map, we separated them into two different visualizations. When the qubit map and coupler map are separated, it is more intuitive to choose what to display on the different bit maps. Thus creating clear visual separation for the user. In addition, we choose to use radio buttons selecting between qubits, resonators, or one qubit gates for the qubit map visualization. For the coupler map, we choose to use radio buttons for selecting either couplers or two qubit gates. Lastly, we choose to use a drop-down menu for each map to choose what parameter to visualize. Radio buttons and dropdown menus are common UI control elements that the majority of user should be familiar with.

Figure 3.7: Version 2 mock-up of the detailed view, with the qubit and coupler maps.

3. Design of web interface

The new mock-up for the type 2 visualization is displayed in 3.8. The type 2 visualization is a histogram for this version. Previously we had a bar graph that was supposed to do the same thing, but on the advice of the experimentalists at WACQT, we changed the bar graph into a histogram. This visualization also uses radio buttons for choosing one of the following dynamic properties and qubit-specific keys T1, T2, or Tϕ to visualize. T1 is the time of how long it takes for a qubit to degrade from a state to another. T2 is the phase lost time. Tϕ is combination of T1 and T2 times and acts as an overall qubit longevity measure. The mock-up also includes a date picker for choosing the time interval for the data to be displayed.

Figure 3.8: Version 2 mockup of the detailed view, with the histogram graph.

The type 3 visualization is a plot to display each qubits deviation/distribution of gate errors. Miroslav provided an example of how the visualization could look, which is displayed in figure 3.9. The type 3 visualization displays the qubit-specific key gate error on the y-axis and the qubit index on the x-axis. The user will also be able to use the date picker component presented in the type 2 visualization to pick a time span for displaying the data. The date picker is also a common UI element that the users should be familiar with. Due to the more simplistic design of the type 3 visualization and the minimal user input, we decided not to create a mockup for this visualization. We instead used the figure Miroslav provided as inspiration for the implementation of the type 3 visualization shown in figure H.6.

3. Design of web interface

Figure 3.9: Example of type 3 visualization from Miroslavs presentation.

Figure 3.10 displays the new mockup for the type 4 visualization. The type 4 visualization is a line chart which we had already designed in version 1 but at that time we thought the most useful and most common use case of a line chart would be to see values over time. Instead we got feedback from experimentalists and Miroslav that the most important use case is to see correlations between keys. Therefore the new line chart displays values for the majority of the keys as domains and co-domains. So for the updated visualization the needed inputs are domain, co-domain, and what key to use for each. To choose all these inputs, we used radio buttons for the domain and co-domain, where you can choose either qubit, resonator, coupler, or gates. Two drop-down menus are used to select the key to be visualized for the domain and the co-domain. These inputs are displayed in rows with all the inputs in one row for the domain and one for the co-domain making it easy for the user to see the chosen inputs.

3. Design of web interface

-Figure 3.10: Version 2 mockup of the detailed view, with the line graph.

The Type 5 visualization is a city plot. During the design phase, we decided to focus on the first four types of visualizations due to the complexity of creating a 3D-based visualization. If there would be time over at the end of the implementation phase, we would implement the city plot. In the end, we did implement a city plot, which is further elaborated upon in Chapter 4 and Chapter 5. Miroslav also provided us with an example of what the visualization could look like, shown in figure 3.11. The idea for the city plot is to visualize the static property and coupler specific key, xtalk{i, j}, which is a value that represents unintended consequences or influence between coupleri and couplerj. At the design phase, we were unsure if a city plot would be the best way to represent this. During the user test described in Chapter 5 and discussed in Chapter 6 a physics researcher from WACQT explained both advantages and disadvantages of using a city plot instead of something like a heat map.

3. Design of web interface

Figure 3.11: Example of type 5 visualization from Miroslavs presentation.

There will also be a table view available in this version of the GUI that will be the same as in the previous version, which will display all kinds of data. During the design process for version 2, we also came up with the navigational view that can be seen on the left-hand side of all mock-ups above. This navigational view allows the user to navigate between different qubits and couplers for a specific backend without going back to the qubit map and choosing one every time, making the navigation much smoother.

We also decided on displaying skeletons when rendering in components. Skeletons provide the user with clear visual feedback that something is loading. The primary reason for using skeletons in this project is for when large amounts of data is re-quested from the API. It could take several seconds before the frontend receives a response. The implemented skeleton is presented in figure H.9 in Chapter 5.

4

Implementation and development of web interface

This chapter is similar to the previous one, but instead of the design stage, this chapter will first introduce all the development tools and technologies used for im-plementing the design and then present the two iterations, versions 1 and 2.

4.1 The REST API

In this section, the importance of server state and the endpoints used for fetching data is discussed in detail.