ivan-cukic commented 1 year ago

Report UX Workshop

/ 11. October 2022 KDAB Office Berlin

Participants:

Dr. Ralph Steinhagen (FAIR)
Alexander Krimm (FAIR)
Dr. Ivan Čukić (KDAB)
Giulio Camuffo (KDAB)
Björn Balazs (KDAB)

Scope of the product(s)

The project will foremost provide a digitizer app with a primary focus on FAIR usage.

Additionally the project wants to become a good player in the free software community and build up / start a community around this.

To foster this a good seperation between the framework (openCMW) and frontend implementations is needed. The FAIR digitizer app serves as a frontend implementation / poc for the framework. Again there are two main aspects to the frontend - the flowgraph to configure the output and the actual dashboards to monitor operations.

In order to make it easy for others to build upon our work it makes sense to seperate these aspects of the project as much as possible:

1. Framework

Provides the technical infrastrcture (extends openCMW)
Provides reusable components for post processing
Can be used to trigger (semi) automizations
Should not provide graphical components, but serve as backbone for many different application on top (without any limits)

-> as there should be no UX component to this we did not look at this further.

2. Flowgraph

Example implementation of a configuration UI for the framework
Optimized for FAIR needs, but we expect this component to be rather generic for many purposes. This is why it should not be part of the more generic framework nor the more specific digitizer app.

3. Digitizer

App that allows to monitor the machines at FAIR
Integrates Framework and Flowgraph with a dashboard system
Optimized for -- Monitoring -- Bug tracing

User

We assume a pretty nerdy user group, as users are expected to work on rather complicated graphs from various tech areas.

For FAIR there are four basic user groups: 1 Machine experts (12 ppl per accelerator) They look from top and look at the lateral view, what system is responsible for the problem and refer to system experts ("your magnet is the problem") 2 System experts (similar to ^) (~100 ppa) They are responsible for the vertical stack (power converter stack; dealing with magnets; ...) 3 Operators (25 ppa) They monitor, see machine is running, and report issues at more shallow level, do pre-diagnostics. Available 24/7. They are technicians, not physics experts 4 Others - experimental users 1000s ppa This user group contains the public (as data will be publically available), management and scientists having their experiment run on the accelerator

The main difference in work overall is the degree to which users do

Monitoring or
Bug-tracing

We decided to create two personas on both edges of this spectrum:

Susan

Susan is very experienced in acc revelevant physics and knows basic programming. Her main task is to trace bugs to keep the acc up and running.

Paul

Paul is an early graduate (bsc) and does not have programming experince. He works as an operator and his job is to monitor the acc working correctly. He does first level bug fixing. In case he cannot fix himself, he has to identify the right person to escalate to and provide a report of the problem.

We identified a set of tasks and rated the importance for both users (0 not applicable / 5 most important):

S | P |
5 | 5 | I want to see whether a signal is correct
3 | 0 | I want to create a reusable view of freq. used signals (dashboard)
4+| 5 | I want to view a set of pre-defined signals (dashboard)
4-| 0 | I want to create a signal trafo based on basic trafo blocks
3 | 0 | I want to create a reusable signal trafo chain based on basic trafo blocks
3 | 4 | I want automatically (trigger) to be notified about non-normal states

During discussion a couple of topics arose:

A few of the above include the subtasks:

I want to get an overview of available signals
I want to easily find a (set of) signal(s) I need

I want to see whether a signal is correct

compared to expected (in mind)
compared to a second signal (same time or freq axes)
correlated with a second signal (value 1 versus value 2)
compared to a predefined tolerance band around a reference
compared to a user-defined min max thresholds
is signal even shown
see error log for the signal
usual charting features!!!
usual post processing step (task below)
saving the snapshots of all the shown data sets, maybe even with the reloadable dashboards with the old data
screenshots

I want to create a reusable view of freq. used signals (dashboard)

save/store - define name/tags, saves screenshot (git)
group signals into the same chart (shared or separated axes)

I want to view a set of pre-defined signals (dashboard)

open/recover buttons
finding the right dashboard
from outside: launchable via URL

I want to create a signal transformation based on basic transformation blocks

@see GNU Radio companion
frontend and UI flowgraphs
editable flowgraphs - topology and parameters (parameters editable during runtime of the flow, not of the service)
dataset processing - reactive streams? or GR integration? (impl detail)
load and store - name ...
no GUI items (the globals)

I want to create a reusable signal transformation chain based on basic transformation blocks

@see GNU Radio companion

I want automatically (trigger) to be notified about non-normal states

define thresholds (min max)
trigger envelopes
impl-wise: specialized post-processing
actions:
- notification on the machine
- external notification
- twitter :)
- saving snapshots - pre, actual and post signals - for a defined set of signals (transient recording) - aka post mortem analysis

Vision

Digitzer: Improve the uptime of the acc by enabling everyone to gain the insights to spot and fix problems ASAP

Overall: Create a vivid Free Software community around the topic of signal processing

UX

We briefly discussed the UX flow, but mainly focussed on three central areas:

Workspace (Landing Screen)

Users need to able to easily define and choose dashboards. Each dashboard is the visual representation for a certain monitoring or research question. Dashboards need to be loaded from different sources and possibly shared, e.g. via repository, URL. User will have to work with various dashboards at the same time. The Landing screen orchestrates this.

The main focus for the workspace is:

Finding the right dashboards
Managing a set of dashboards
Creating new dashboards

Dashboard

A dashboard allows the user to arrange and manipulate a certain sets of charts in order to monitor and understand signals.

The main focus of the dashboard is:

Layouting the charts
Manipulating charts (e.g. zoom, dis- enable sources, colors,...)
Arranging charts (e.g. choose layout, arrange charts)
Admin (e.g. save, share, print, ...)
Adding simple signals

Flowgraph

The flowgraph allows the users to define the content (data sinks) of the charts shown on the dashboard.

The main focus of the flowgraph is:

Manage signals (add, remove, disable, ...)
Allow to visually modify / transform the signals (by connecting available blocks)
Dewfine sinks to be used in the charts

In detail we discussed the follwing features:

Filter source / sink to focus flowgraph
Filter / List / Add blocks
Filter / List to add sources
Move and connect elements / blocks
Name / add sinks
View / modify the FEC of a source / modify block parameters
delete blocks
Filter / add hierarchical blocks
Define / save hierarchical blocks
Auto layout blocks
break up hierarchical blocks

Misc.

Signal meta informationen:

Name
Unit
Rate
Origin
Type / Time vs. Freq. Domain

FAIR specific:

Cycles need to be respected (definition per dashboard) -> Breaks the source selection in Flowgraph

RalphSteinhagen commented 1 year ago

Additional whiteboard snapshots for documentation purposes are below. The main info is summarised above but some of the drawings trigger some additional undocumented memories in the participants.

RalphSteinhagen commented 1 year ago

IMG_20221010_122101