Project Testing

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 7

Enable interactive data visualization for MBARI AUV data

CST489-Capstone Project Planning

Jake Horne, Kevin Yoshimoto, Luis Navarro, Michael Watson & Myles Lopez

Professor Cassandra Eccles & Professor Brian Robertson

Summer 2023
1

Table of Contents

Project status update.................................................................................................................. 2


Changes to initial objectives/approach/solution/deliverables...................................................2
The current state of the project................................................................................................2
Individual contributions (past and future).................................................................................3
Project Testing............................................................................................................................. 3
What is your target audience?................................................................................................. 3
Who will be testing your project?............................................................................................. 4
What are the main tasks you would like your client/users to complete?..................................4
For client-based testing........................................................................................................... 5
Observing usability testing and tester feedback...................................................................... 5
2

Project status update

Changes to initial objectives/approach/solution/deliverables

The deliverable as well as the objective for our project has not changed, where we are

still expected to have a Jupyter notebook with demonstrations of widgets as a pull request. The

initial solution has changed, where at first we had all extrapolation based on our given dataset

and slowly, we felt the need to integrate on a larger scale where any dataset implemented would

be treated the same. Similarly, our visualization wasn't just scatter based but we chose to include

other data visualization options to give more flexibility to end users. In terms of work completed,

Michael and Jake worked together for implementation of the widget dropdown, separation of

platforms (also through dropdown), and contribution for writeup for video presentation as well as

this project outline, at a future date.

The current state of the project

Our specific goal for this capstone was to quicken interactive exploration of large data

sets, using widgets within a Jupyter notebook. If a user inputs a dataset, we want to be able to

provide the necessary widgets relevant to the dataset as well as be able to look at the data in

different views, whether that be at different points of time or changing the scale of the graph to

remark on key differences and trends. Currently, we are able to visualize the data as well as take

in a dataframe of arbitrary length. From there, by looking at the first element of each column, we

are able to title the widgets based on the specified attribute and, given the type of data in each

column, provide a slider that is applicable (string to dropdown, slider to time etc.). Finally, with

the widgets applied, we are able to show different types of graphs of the same data, that is
3

additionally split by the two platforms (tethys and daphne) that are used to collect the data.

Initially, we were to work with a poetry shell but due to compatibility issues across the groups'

computers, we opted to work with anaconda in order to have seamless development between all

users. Sliders for contiguous data are not currently integrated with visualizations, we have a

situation where moving the slider does not affect the view of the graph, but this is currently being

diagnosed and worked on.

Individual contributions (past and future)

In terms of work completed, Michael and Jake worked together for implementation of the

widget dropdown, separation of platforms (also through dropdown), and contribution for writeup

for video presentation as well as this project outline, at a future date. Myles incorporated the

findings of Michael and Jake into more complex widgets by bringing all features into one single

large widget. Myles researched all different approaches to coding the widgets to achieve desired

outcomes while cutting down processing costs of the code. Kevin helped by figuring out the base

code for the incorporation of the rangeslider and dropdown menu onto an hvplot. Kevin shared

the base code and other resources that were useful in implementing the rangeslider, as well as

turning the generic hvplot scatter plot into a datashader scatterplot.

Project Testing

What is your target audience?

Our target audience for our project is our client user, known as Professor McCann. Our

final deliverable of a Jupyter notebook (demonstrating the widgets created) will be conclusively

tested and ultimately accepted by Professor McCann. He is our direct target audience and end
4

user, but should he see fit, the widgets we have created could be implemented in other teams

associated with MBARI.

Who will be testing your project?

Likewise, our tester for our project will also be Professor McCann and, if he sees fit,

could overflow into other teams of software developers, but this timeline would extend beyond

the scope of our course. Overall, this user base is adept technologically since they work directly

with the source material as software engineers and data scientists, as well as they develop

regularly and make pull requests to this repo, so all pertinent information is regurgitated

constantly.

What are the main tasks you would like your client/users to complete?

For our test, we would like to offer no initial input, all relevant information should be

present in the cells of the Juypter notebook, from the resources that need to be downloaded prior

to running, as well as the order for the cells to be run in. Within the Jupyter notebook, cells are

labeled on their intended purpose and documented to completion, to increase the

comprehensibility of the code. We want the following main tasks to be completed by Professor

McCann during his walkthrough. Professor McCann should be able to run all dependencies, and

create the initial dataframe that is to be manipulated. From there, all attributes within the sample

dataframe (timevalue, depth, platform etc) will be labeled as pertinent keys that can be called

upon. Next, the dataframe should be split into their respective daphne and tethys auv vehicles

and all “NaN” will be dropped from the dataframes. From there, multiple plots will be created,

all with chlorophyll as the y-axis (since this is the variable we are most interested in seeing the

relationship between other variables), and with the option to look at either the “tethys” or

“daphne” version of the graph. Professor McCann will be able to choose which x-variable to
5

relate to chlorophyll, as well as dictate the type of graph to view the graph, whether it be scatter

plot, bivariate etc. For certain variables on the x-axis, for example “timevalue”, which are not

discrete values, if the slider is manipulated, the graph will change in real-time to reflect the new

set of ranges that have been implemented.

For client-based testing

We met up with Professor McCann to go over the formal walkthrough of what we had

been working on through a Zoom call where we shared our screen to him. From there, he went

through downloading the necessary dependencies that our Jupyter notebook relied on as well as

running the initial cell of the dataframe in question that had previously been provided. Since

Jupyter notebook is straightforward in that every cell has to be run from the top down, there was

no need to explain methodology of how to achieve the final outputs from the user perspective,

rather we focused more on questions he had about why certain cells were structured the way they

were, what each cell did. This was more from an insight perspective than an actual critical view

in the overall design of our final deliverable. Overall, Professor McCann was able to complete all

required tasks and we were able to to finalize all aspects of the deliverable that were required:

● Provide a drop down selector for activity__name,

● Provide a range selector for depth

● Provide a range selector for time

● Have these selectors operate on figures created by Notebook biplot() function

Observing usability testing and tester feedback

We still have to submit a new Notebook as a pull request to his repository in order to

fulfill all criteria, but that will be completed before the festival begins. He had no issues with the
6

overall flow of the Notebook, stating that it was very clear and showed the progression of the

work we had put in during the course of the Capstone project, from inception all the way to its

final completion. There was no knowledge barrier to understanding the Notebook, and he said it

was fully complete in its understanding of the task. From his perspective, there was no issues

with what we provided, so there is no notable observation or description to provide for tester

feedback. We asked if there were any additional features or functionalities that he could think of

that he wanted us to add further, but given that we are a week out from final presentations, he

was satisfied with the overall results that we had provided at that point. So in the short term,

there were no pressing issues or adjustments that needed to be met before the festival, and there

were no explicit talks about long term, save that the pull request would be merged and would

become a permanent member of the mbari repository.

You might also like