# Radicle IDE Plugins | UX Research | Milestone 1 Delivery :mailbox:

* **Application Document:** [radicle.community post](https://radicle.community/t/application-radicle-ide-plugins-ux-design/2728).
* **Milestone Number:** 1

## Context
The scope of the 1st milestone of the grant application covered the UX research and design prototypes for a Radicle plugin for the Jetbrains suite of Integrated Development Environments (IDEs).

## Deliverables

| Number | Deliverable | Link | Notes |
| ------------- | ------------- | ------------- |------------- |
| 1. | "Paper prototypes" - 1st & 2nd Iteration | [Interactive Prototype](https://www.figma.com/proto/9h2suLnyckUXGmMyReMiYP/LF-Wireframe---Milestone-1?node-id=472119%3A11713&scaling=scale-down&page-id=77%3A432&starting-point-node-id=472119%3A11713&show-proto-sidebar=1) and [Figmal source file](https://www.figma.com/file/9h2suLnyckUXGmMyReMiYP/LF-Wireframe---Milestone-1)| Rather than providing separate deliverables for each iteration, we deliver a single figma working copy, complete with all comments and work we have been doing in the open. In addition, rather than delivering non-interactive "paper prototypes" of each page, we are delivering interactive prototypes that we believe will significantly speed up understanding of expected behaviour during further development stages. |
| 2. | Field Studies/User Interviews research results | [See below](https://hackmd.io/@gsaslis/radicle-ide-plugins_milestone1#Usability-Workshops---Detailed-Observer-Notes) | Rather than running 2 group studies, we instead decided to run **individual** moderated usability workshops, so we can better understand each of our users problems / struggles / thought process, etc. Instead of running 2 workshops with 10 participants each, we ran 17 individual workshops, for which we are delivering: a. Notes from observers. b. An overall summary conclusions. |

## Additional Information

### Usability Workshops - Executive Summary

The setup of the moderated study involved a participant and 1-3 observers who were there to **learn** how developers approach the undertaking of 4 simple tasks **(through the IDE)**:

1. **Clone** a Repo from Radicle
2. **Publish** New Repo to Radicle
3. **Contribute** a Patch to an existing Radicle project
4. As a **maintainer**, find a new Patch that a community member has contributed.

The facilitator and observers could not answer any questions about the IDE plugin UX. The facilitator could only answer some questions about Radicle and

At the start of every workshop, the facilitator emphasized to the participant that what was being tested were the designs and **not** the participants.

### Usability Workshops - General Observations / Learnings

1. **IDEs offer more than one ways to get things done**: In Jetbrains' IDE, plugins add functionality by adding new menu items, new buttons, new tool windows, etc. We originally added the Radicle-related functionality in one of the menu items. It quickly became apparent, after the first couple of usability workshops, that our users were looking for the same functionality in different places of the IDE - and all were valid. (e.g. the "create a new git branch" is available as a. a top-level menu option, b. as a context menu option through the Git Tool Window, c. through its own tool window that users can access from the bottom right, d. as a toolbar button, e. as a shortcut - and that's just scratching the surface). It therefore became obvious that rather than us trying to find **where** the right place for this information is, we rather needed to think backwards, starting from the places where "Git functionality" is already offered and work backwards from there, by adding the same Radicle functionality everywhere users would already be looking for it.
1. **"Git" vs. "Radicle" separation:** Even though most of our users completed the necessary steps for their tasks successfully, it was clear they didn't always understand everything that was happening "under the hood". Perhaps this is to be expected, when faced with an entirely new domain that they were operating in. However, we feel this is worth highlighting towards all Radicle core teams: users **successfully** went through the Radicle "clone", "publish", "contribute", "review patches" actions, without necessarily understanding the differences between `rad clone` vs. `git clone`, `rad push` vs. `git push`, etc.
1. **"Finding it the first time" is the hardest:** Around half or more of our users commented that they only struggled to **find** the "Radicle" functionality. After they had found it, it made perfect sense and being able to find it a second time it was **very** straightforward.
1. **"Anchoring effect"**: Continuing on from the above point - and also related to (1) above - we noticed that when our users found "Radicle functionality" in a specific place in the IDE (e.g. top-level menu item), they then started expecting to find **all** Radicle-related options in that same place. When they didn't they felt stuck during the workshop.
1. **"Seed Node"** was the most important Radicle `entity` to come to terms with, in terms of being able to complete the basic set of tasks we asked them to. This ties in nicely with Radicle's Unique Selling Point (decentralization) and we feel that this would make a nice entry point in a learning path.
1. `rad init` combined with `rad push`: Though these are separate actions, doing very different things, we are of the opinion that `rad init` is better presented as part of a 2-step process: "publishing your project to Radicle". It is worth noting that this is an assumption we started with though and this is not a finding of our usability studies. Not one of our users was confused by the information requested by `rad init`, nor did they complain or wonder about its presence as the first step of the particular UX journey, however that also **doesn't** confirm our assumption - it just adds a data point. And it is worth noting that `rad init` probably makes more sense with users that would like to experiment more locally and should **also** be present as a separate action.
1. At least 50% of the users that took part the prototype testing **prefer the Command Line Interface (CLI)**, so the can get a better understanding of what is happening under the hood”.

### Interactive Prototype vs. Paper Prototypes

A big difference with the original proposal was that we decided to try out an interactive prototype, as opposed to the paper prototypes we were originally planning for (we would scan these and the moderator would manually change the screens for users, as would happen in a non-virtual workshop). The interactive prototype has required more hours of work, but we still think it has been a valuable addition: we can maintain more of an observer role and the interaction feels more “natural” for users.

A lot of work went into making the interactive prototype more open for exploration by the users, and not just covering the “happy paths”. This has made the setup on figma MUCH MUCH harder, but has also resulted in learnings already when we found users exploring actions we didn’t expect they would take.

We think the delivery of **interactive** prototypes will dramatically speed up the actual implementation of the IDE plugin (which we plan to propose in a future grant proposal, as it will give the developers a much clearer spec of the required functionality. The paper prototypes do leave room for doubt (a person is still required to answer the “what screen does the user go to when they click this button” kind of questions).

### Continuous Improvement vs. 2 Planned Ιterations

Another difference with the proposal was that rather than just 2 (larger) iterations of improvements, we have instead been making smaller, continuous, improvements to the designs, after every couple of workshops.

The main driver for this decision was that finding suitable candidates was proving rather hard (e.g. we had several VSCode users, but we were looking for folks familiar with the Jetbrains IDE, so that we can focus on the UX of the Radicle IDE plugin, not the IDE itself).

The big learning here was that we probably have to reconsider the incentives for finding future users.

### Usability Workshops - User Sample Demographics

In this section we present some demographics that should help understand better the group of users we observed.

We are explicitly excluding traditional demographics like "age" (opting for years of experience instead) and "gender", so we can focus on


### Usability Workshops - Detailed Observer Notes

#### 1. 2022-04-11 | nikos


---

#### 2. 2022-04-15 | vaggelis


---

#### 3. 2022-04-15 | michalis


**Other Notes:**
* Locker icon at "Settings/Identities" section: secure/insecure the user searching for a red or orange icon. He is not understand 100% what this icon represents.
* Uses CLI to clone and not GUI, he are searching the clone action from the navigation menu.
* The user believes that Radicle sync action make fetch. He would like to have a list/log with the commits of the project.

---

#### 4. 2022-04-29 | alex


---

#### 5. 2022-05-03 | yves


---

#### 6. 2022-05-03 | teo


---

#### 7. 2022-05-04 | iosif


**Other Notes:**
* Task 1:
** He finds usefull the Git menu actions.
** He are searching the terminology and likes to explore the GUI.
** Prototype bug issue while the user are playing around.
** He finds useful to use the Apply button rather than OK button.
** He don't undrestand Radicle Seed Nodes what it is.
** Task 1 completed successfully.
* Task 2: completed successfully
* Task 3:
** He is a bit confused.
** He pressed git pull in order complete the task. (unsuccesfully)
** Completed successfully
* Task 4:
** The users tries to fetch the project by using update project git action. He was looking for a confirmation message.
** The users gets confused with pull and update git actions.
** He is not familiar and don't trust so much the IntelliJ GUI. He is using CLI.

---

#### 8. 2022-05-04 | paul


**Other Notes:**
* Task 1:
** Task 1 completed successfully.
** He was looking for Clone action inside the sub menu of Git-Radicle.
* Task 2: completed successfully.
* Task 3:
** He is not familiar the terminology of Contribute.
* Task 4:
** The users tries both fetch and pull, he don't know what to do.
** Don't understand the icon meaning on Radicle tool window.

---

#### 9. 2022-05-05 | manolis


---

#### 10. 2022-05-06 | themis


**Other Notes:**
* He was not sure if Git Clone action will make the Radicle Clone action.
* Suggestion to include Clone inside the menu of Radicle
* He gets confused with push action for task 3
* He was looking for a confirmation message after the push action or a related preview message

---

#### 11. 2022-05-06 | ioannis


**Other Notes:**
* He was trying to make clone action from the Radicle tool window. (Bug)
* He would like to review the background actions on a CLI window.
* He was not expecting the pop up message "Succesfully Pushed"

---

#### 12. 2022-05-10 | stelios

#### 13. 2022-05-11 | giorgos


---

#### 14. 2022-05-13 | michalis


**Other Notes:**
* Task 1: He is confused.
* Task 2: He don't understand the "Seed".
* Task 3: He was looking for a confirmation message as he completed the task.
* Task 4: Question about Radicle sync and git pull if sync the radicle project.
* He is familiar with an action group of shortcuts on the top right of the IntelliJ window. He was expecting to find this actions.

---

#### 15. 2022-05-16 | andreas


---

#### 16. 2022-05-17 | vaggelis


---

#### 17. 2022-05-17 | manos


---

## Conclusion & Next Steps

We are delighted to have concluded the first Milestone of this research project! 🚀

We are now confident we are in a much better position to **understand** the problem area and proceed with planning the **implementation** of the Radicle IDE plugin for the Jetbrains family of IDEs (IntelliJ / PhpStorm / PyCharm / Rider / GoLand / RubyMine / WebStorm / etc.).

Assuming approval of the deliverables, and successful completion of Milestone 1, we are eager to proceed on two fronts:

* Proceed with **Milestone 2** of this proposal and design a Radicle IDE plugin for VS Code. On the plus side, we already have some interested VS Code users, which will hopefully speed up the process.
* Prepare a separate grant application for the **implementation** of the Jetbrains IDE plugin.