Naming

One peer was confused as to what the secret field suggested, whether this was some kind of extra cipher input to doubly secure your SSB key. Once it was explained that the secret could be any string, they they attempted to paste and entire document in and came up against the byte limitation.

The difference between the name and the label fields is not clear at all, with one peer aliking them to title and description as typical fields in a form. name and label are overlapping concepts. label could also imply tags.

There is nothing to suggest that the name is only something you see and remains outside of the secret, while the label is packaged up within the secret. Once it was explained to the peer who raised this, and it's what its intention was there as, the peer in question expressed that they felt this was an unclear and possibly one-to-many mapping of 'purpose' and 'concept', that the packaging of the label into the secret when sharded actually revealed that there were two concepts attempting to fulfil the same purpose, and that label was they felt a redundant concept, since there is nothing to stop you from putting the information from the label into the secret. This deserves further thought and discussion.

Many peers trialing the application were unsure what the 'request' button would do. It was explained that this would send a message asking for the return of the shard, and that this (rather than an automated response) was a necessary hurdle to prevent someone from using a lost or stolen device to steal all the secrets, thereby rendering the application useless. After this explanation, it made sense, though the prominence of the button alongside little to no context seemed unintuitive and unclear. The modal that flashes up with a warning asking 'Are you sure' as a part of that process was off putting enough to prevent peers from pressing the request button without being sure. But since there was no clear explanation of what the request would actually do, it rendered the functionality somewhat pointless. Several peers would only press the button after being reassured what it would do. Others were more gung-ho and pressed it to see what happened.

Other peers raised whether naming a secret would actually work for some people. Whether this can be directly addressed or whether this is simply 'peer error' is up to debate. While Dark Crystal should aspire to make things as intuitive as possible, there is only so much you can hold someone's hand. This is worth testing over a long period. Its possible the UI should suggest a naming convention to people as a guideline to work with, then people can apply with what makes sense for them.

Onboarding

The onboarding issues for Scuttlebutt itself are well known but need restating in the context of Dark Crystal's usability. Due to it currently being embedded within Patchbay, and sharing Patchbay indexes that aren't currently required by Dark Crystal, this causes a significant delay when starting the application for the first time, and when listening for the arrival of new data. At times this meant a peer signing up to try out Dark Crystal had to wait 20 minutes for data to sync and Dark Crystal to be usable. While encouraging people to be patient why trying out prototype technolgy is awkward but relatively acceptable, in order to achieve wide peer-base, the waiting times are simply unacceptable and are a sure fire way to lose new peers.

In some instances, it took several hours for shards to render in the application between certain peers (or they never did), despite being local peers on the same network. It is not clear whether they have 'arrived' in the local database and just haven't indexed, or whether there was a network transmission failure. While Scuttlebutt is 99 times out of 100 reliable (if not more so), if we cannot guarantee delivery of shards, this remains a significant and possibly killer issue. More research needs to be done on the lower level implementation of Scuttlebot to ensure messages are gossiped and / or indexed correctly.

Privacy Transparency

There are currently no clear indicators or assurances in the client that the data is actually encrypted and private, and the interface makes the assumption that peers using the application already possess that knowledge.

Many peers expressed a desire for reassurance, at least when initially becoming familiar with the application, that the information contained in the application is either encrypted to yourself only, or in the case of the shards of the secret, encrypted and sent to the destination peers.

Due to the social nature of scuttlebutt, and the secure nature of Dark Crystal, its incredibly important to strike a clear distinction between what is public and what is private.

Behaviour and Navigation

Some peers found both the interface and the protocol puzzling and expressed this confusion in the form of questions such as:

How did I get here?
Where am I currently?
Where am I going next?
What is going to happen next?
What happens if I click this?
Will I be able to go backwards?
Will I be able to change my mind?
How many steps will there be in this process?
Have I done this right?

Such questions reveal an inability to easily intuit what the consequences of a specific action might be. This has serious ramifications for Dark Crystal which is fundamentally about handling sensitive information.

Some peers observered they felt the UI was actively encouraging them to share their secrets. This could be problematic.

Several peers expected different behaviour when hitting the ESC button when selecting a custodian, expecting it to simply close the dropdown rather than exit the form modal.

Multiple peers reported unintuitive use of anchor elements throughout the application, here is one such example:

On the main page of DC, I clicked on the image of the person who had sent me a shard.
I expected to it to take me to the details of the shard.
Instead it took me to their profile.

A bug that persisted in the custodian suggester has been fixed. This was an early behavioural issue that has been resolved.

There is no importance hierarchy in New Crystal form. Peers reinforced our belief that a flat form with no additional information (such as tooltips) meant it was not visually clear what was of importance.