---
# System prepended metadata

title: 'Project title: Integrating SCope visualisation for SCC'
tags: [requirements interview, ' software']

---

---
tags: requirements interview, software
description: requirements interview for integrating SCope for the SCC
---

# Project title: Integrating SCope visualisation for SCC

Date: 3-Feb-2022

## Participants

* James Collier
* Kevin Verstaen

## Purpose
The purpose of this document/interview is to understand the requirements that SCC has for integrating SCope. Provide as much information as you can, details, overview, context, questions, priorities, anything. This document will eventually become a formal list of prioritised requirements. For now it is very informal. There are already some guiding questions but please don't be limited by them.

## Glossary
* **MVP** - Minimum Viable Product. The minimal set of features that a working system can exhibit while being acceptable.
* **SCC** - VIB Single-Cell Core Facility.

## Priority levels
* ***Highest priority*** = Feature is required for us to be able to integrate SCope in the SCC workflow
* **Priority** - Somewhat important, but we can live without them
* **Nice to have** - Would be cool to have in the future, but should not be focussed on

## Outline

The single-cell.be portal provides single cell analysis services (including visualisations) to the VIB community. Users may click on a link on this portal to view their data in SCope (logged in using their VIB account).
There is a very elaborate data management and experimental project tracker tool for all involved cores and staff from initial sample prep until data delivery. 

## User info

> Who are your users? How technically literate are they?

There are 2 types of users:
- biologists/researchers with no bioinformatics background. They would mostly use the tool to annotate data based on their biological knowledge.
- researchers with a basic bioinformatics background. They know enough R/python to make some (basic) visualisations of the data. These people are the minority.
- embeddeded bioinformaticians might also want to use the tool to rapidly interact with their users (in their own lab) for the data specficially inside the portal. The portal should be a point where all parties involved in the entire single cell workflow can converge.

> What do the users want from SCope?

It's mostly just plotting of gene/antibody expression on a dimensionality reduction + annotating the data collaboratively. Having an easy way to annotate data makes the communication between researcher and bioinformatician way easier.

Downloading /exporting the annotation (cell barcode + label) as a CSV would be a minimal requirement as well.


> What might users not want? Or what might they want to avoid?


## Features

> What minimal set of data formats should SCope be able to display?

Loom files are sufficient. Conversion from any other data format (e.g. seurat RDS objects) to loom should at the moment not be a priority for SCope and will be handled in the processing pipeline itself.

The only problem I see, is that our data often is multi-modal. Next to the gene-expression data we can also have antibody (AB) information (from CITESeq and/or hashing). It would be nice of SCope could support multi-modal data or alternatively advice a general way on how to handle this type of data.
A 'hack' I currently do if I have to convert a multi-modal Seurat object to loom is concatenating the gene expression matrix and AB matrix into 1 larger matrix. SCope will just see this the antibodies as genes and work properly. ***Highest priority***


> What minimal set of data formats should users be able to extract from SCope?

* Seurat object: most of our users will probably use R to work with the data. 
**Priority**
* SCE object (optional): could be useful, but not really a priority for us **Nice to have**
* loom & h5ad: in case there is something you want to run in python (already available?)

> What data editing features (if any) do you need from SCope? e.g. is collaborative editing useful in an MVP?

* editing of cluster information: giving the user the ability to define custom clusters by either merging existing clusters or drawing on the plot to select a custom set of cells will allow for a better annotation of the data **Priority**
* Creating a subset of the data: sometimes you don't need the whole dataset and you only interested in a smaller number of cells. This feature is only useful if it would be possible to recluster and recalculate PCA/tSNE/UMAP in SCope itself, but this might go a bit too far for now... **Nice to have**

> Programmatic access to deposit data over HTTP is ok? Also for data requests from SCope?

An HTTP API is perfect! It should primarily only support upload/download/deleting of the data, but gradually adding more features (e.g adding additional metadata/annotations to a dataset, downloading specific metadata...). ***Highest priority***

> Please describe the features you want in as much detail as possible (include priority where possible)

* User management: we need to be able to protect data from the public. A dataset should be linked to a person (or group of people) so only they can have access to the data. It should also be possible for the researcher add more collaborators to the datset via the interface (or the API itself) ***Highest priority***
* Improve the way people can see available metadata in their data. This might already be possible in SCope, but I don't really see how (mind you, I only have very limited experience with SCope). From what I see, you can type in the searchbox to look for a metadata variable you want to plot. This works if you know what it is called, but maybe it would make more sense if it was just a dropdown with the available options? **Priority**

* A version history of the annotation (annotation label, user, date) to recall/export.
For each cell/cluster/... **Nice to have**