Usability analysis: tasks, pains and gains

[jurra]

In this channel we want to focus mainly on identifying issues that users currently faced when it comes to archiving.
We have now a general discussion about tasks, pains and gains. But we can split it up around specific tasks like creating a new archive, or updating metadata from an existing archive, etc.

Could you document a task that you often perform when it comes to archiving or downloading data from archives?
Can you document it in the style below?

Tasks:

• list of focused tasks....

Pains

• List of pains and things you dont like.....

Gains

• List of things that would be nice to see or have

Here is an example of a task, pain, gain story:

Tasks:

• Archiving a new project/data to an Archive.
• Fill in metadata fields via the browser interface of the specific archive (4TU, Zenodo)
• I might need to archive in different systems, more than one.

Pains

• I have to use the browser interface and navigate to an upload page, then manually find in a file browser where the project is.
• I cannot retain a copy of the metadata in my local repository, it stays in the archive. This may include the DOI.

Gains

• What if I could have a copy of the metadata in my workspace?
• Would be nice to archive via the terminal easily without having to go to the browser.

[manuGil]

@jurra Who is this for? From my meeting notes, I think this is for us to first document such tasks/pains/gains. Is that right?

[jurra]

This is for us and for users. Its a first attempt to document specific tasks, pains and gains in a structured way. Then I was thinking we can have different of these as separate discussions, if they are big enough. For now we can keep them all here.

[connieclare2802]

Task: 'I might need to archive in different systems, more than one.'

• When and how often is this the case? I would not say this is good practice to duplicate published datasets?

Pain: 'I cannot retain a copy of the metadata in my local repository, it stays in the archive. This may include the DOI.'

• Does this mean you have to add metadata upon publishing but then you don't have a local version of it?

[jurra]

When and how often is this the case? I would not say this is good practice to duplicate published datasets?

You are right this is not a good practice, but sometimes researchers need to archive data in different systems. Is not a good practice. I am not able to answer how often this happens, this is why these are assumptions to be verified.

Does this mean you have to add metadata upon publishing but then you don't have a local version of it?
Yes it means this. A git clone for instance has the exact same data, it doesnt matter if it is in your computer or in a github repository.

[girgink]

You are right this is not a good practice, but sometimes researchers need to archive data in different systems. Is not a good practice. I am not able to answer how often this happens, this is why these are assumptions to be verified.

It might be more common than we thought for some disciplines, especially if funding is also involved. I think up to 3 different repositories might be the case: 1) the repository required by the funding agency, 2) the repository required by the institution (e.g. university), 3) favorite repository of the researcher (i.e. for more visibility).

[manuGil]

Tasks

• Prepare a version of the dataset/code to comply with data/metadata requirements of a specific archive (e.g. Zenondo, 4TU).
• Prepare a README file describing the content of the dataset/code, including the meaning of headings on data tables, how some data must be interpreted, measuring methods, installation instructions, and any quality considerations of the code/data to be archived.
• If datasets are large, split and compress into chunks
• Publishing two or more independent datasets to a data archive by the same person/user.

Pains

• The need to prepare a 'clean' version of data/code for every data archive, I wish to publish my data. I usually have to prepare different metadata files for each data archive, as they have different requirements. I usually keep versions of the archived data/code in my personal backup, just in case.
• Metadata already described in the README file needs to be typed again in the archive submission form.
• Uploading large datasets to a data archive is time-consuming because uploading often requires regular checks and sometimes it can fail. In such a case, the uploading process might need several retries.
• Manually repeating each step of the archiving process via the archive GUI, when two or more independent datasets need to be archived by the same person/user.

Gains

• What if I could quickly "select" the data (code/data organization) that I want to publish so that I don't spend time preparing clean versions for archiving?
• What if most metadata could be automatically read from the metadata/data files already kept in the work environment (versions that are used to do the actual research), and formatted in a way that is understood by the data archive?
• What if the uploading of datasets to the data archive could continue after closing the browser, and the users can come back later to check the status?
• What if advanced users could automate the process of archiving two more independent datasets by providing a CLI (Command Line Interface?

[connieclare2802]

Pain: 'The need to prepare a 'clean' version of data/code for every archive. I usually keep versions of the archived data/code, just in case.'

• Is this more about the metadata than the 'clean' version of the data/code? Is it possible to create a collection of all the fields that are required for different repositories, and request that these are completed within the JupyterLab environment? Then, there could be transfer of relevant metadata to specific repositories?

Pain: 'Splitting large datasets in chunks is time consuming, and uploading might take a long time or fail. Several retries might be necessary.'

• Sorry if this is a naïve question, but is the solution we are aiming for to upload datasets/chunks once to JupyterFAIR and redistribute to other repositories? Is there a use case whereby researchers may want to upload different parts of datasets to different repositories?

[connieclare2802]

Gain: 'What if I could match my scientific workflow without much hassle (code/data organization) so that I don't have to spend time preparing clean versions of the parts that I want to archive for every data archive?'

• What are the scientific workflows? Are we specifically talking about organisation in terms of file/folder structure, naming convention, etc.?
• Would a possible 'Gain' be the option to download data from a repository into JupyterLab for reuse?

Gain: 'What if data upload for large datasets is handled in the background, and the users can check later for completeness or failure?'

• What do you mean by in the background? If you only have one browser tab, you would have to wait for the data files to upload before you can publish. Is the idea that you submit data files for upload and in the meantime the metadata is extracted from the data and auto-filled before publication? I'm not sure that the metadata could be extracted if the data is not successfully uploaded which could be a problem.

[manuGil]

@connieclare2802 Thanks for your comments. I think most of your questions come from the fact that I framed my sentences using technical language. I will rephrase things to make them clear to a wide audience. This is an important lesson for communicating effectively with the focus group

[girgink]

• Is this more about the metadata than the 'clean' version of the data/code?

I think @manuGil is referring to data sets in this case, not metadata. Eventually data repositories support versioning and different versions might include different files/folders, so keeping track of them might be a challenge in fact. I think allowing wildcard characters in the manifest for selecting files to be uploaded and also allowing to indicate which ones should be excluded will help for this.

[girgink]

• What do you mean by in the background? If you only have one browser tab, you would have to wait for the data files to upload before you can publish.

This is the case if you use UI of a data repository through a web browser. But it you use a computing platform, then this process can be in fact performed in the background even if you are not logged in. We can have a service running in the background for this purpose.

[girgink]

Tasks

1. Cloning a research data set from a repository to use it, e.g. for research or just for exploring.
2. Uploading data sets generated on an interactive computing environment to a repository.
3. Filling data set related information (e.g. available data columns, geographical extent, etc.) in metadata entry forms
4. Entering information on authors/collaborators

Pains

1a. Data set should be downloaded manually, which is difficult if there are many files or the data set is big.
1b. If data set is an archive (or can be downloaded only as an archive. i.e. to have the same file/folder structure), it need to be extracted. Also if archive creations is done by the repository on-demand, then it may take considerable time (i.e. for large datasets).
1c. Metadata is usually not included in the files downloaded, so it should be recorded separately (or repository should be visited whenever necessary)
2. Repository web portal or a CLI (if available) needs to be used.
3. The information, which is available in the data set, needs to be entered again manually.
4. Information of the collaborators (e.g. name, surname, title, institution, email, address, etc.) needs to be entered manually, even if they have complete records available online (e.g. on ORCID)

Gains

1. What if a data set can be cloned locally with a single command, including its metadata?
2. What if a data set can be easily uploaded from an interactive computing environment (e.g. JupyterLab) by using a simple UI?
3. What if metadata stored in the data files can be extracted automatically and put into the metadata form?
4. What if researcher information can be imported from online resources by using only researcher identifiers, e.g. ORCID?