[Application] Radicle IDE Plugins - UX Design

Hello again @bordumb ! :wave:

We were just wondering if we can begin working on Milestone 2 while Milestone 1 is under review ? Or should we rather wait until the review is finished ?

Don’t mean to put any pressure on the reviewing team - just looking for some input to help us understand if/when we should plan to work on this.

Thanks in advance!
Yorgos

Hi @yorgos

As we chatted on Discord:
Thanks for the patience as we got the site back up

I have no outstanding questions on this and really liked
So I’ll start gathering votes

One non-urgent note:
When you do get around to applying for a separate grant to fund actually building the JetBrains IDE plug-ins, I think it’d be worth coming up with a framework to keep up with ever-growing features of Radicle. It might be worth experimenting with Drips (Communities?) if you can grow a community of users with this :slight_smile:

Fantastic, thanks so much @bordumb !

Re: drips, I absolutely think they would make perfect sense once the plugin enters a maintenance phase, once a certain set of core functionality has been achieved. In fact, I am already aware of a Jetbrains IDE plugin maintainer who is considering onboarding their existing plugin on Radicle Drips (he will hopefully be working with me on the implementation of the Radicle plugin).

I was also thinking that Radicle Workstreams might also be an interesting way to fund future development stages of Radicle IDE plugins. (In fact, it almost sounds like a good fit for a Grants program as well ? :thinking: )

To sum up, it seems to me that:

  • Drips could take care of maintenance (bug fixes, new IDE version compatibility, offering support, etc.)
  • Work Streams could perhaps be more tailored to development of new bits of functionality that we would like to see added to the plugin.

Disclaimer: I am not entirely familiar with how other communities are currently using drips / workstreams and not sure whether they are currently “production ready”, but we are also not there yet… I do see them playing an important role in the future though…

1 Like

@yorgos — just reviewed the Milestone 1 deliverable and I’m super impressed! Even though I’m not a dev, the interactive prototype was super fun to click through and it was awesome seeing Radicle integrated into a developer experience like that. I’m very intrigued to see the same for VSCode so am very excited for Milestone 2 :heart_eyes:

I’m also excited to see this built! Do you plan on putting together the implementation proposal now? Do you plan on implementing it yourselves?

EDIT: Oops, just saw the implementation proposal. Will read now!

Finally, I’d love to get some of our devs feedback on the milestone/prototype so just CCing them here @cloudhead @fintohaps @alexgood @geigerzaehler for visibility.

Keep up the great work! Excited to see this continue to grow :seedling:

1 Like

Hi @abbey !

Thank you for taking the time to review this ! Yes, I’ve also submitted the proposal for implementation of the Jetbrains IDE plugin with a different team setup. Luckily Radicle is a cool project and that helps with trying to bring a team together (a major challenge in this day and age), as I don’t want this all to be a solo effort on my part - that’s not sustainable, given my other commitments, etc. I really like the idea of this turning into a team that takes on IDE development and I would even like to explore how that could perhaps function as a sub-DAO down the line?

I would love your thoughts on that when you have some time!

Thanks again for reviewing this,
Yorgos

P.S: I’m glad to hear the interactive prototype helped! In our original proposal, we only intended to deliver a non-interactive prototype, but everyone on the team was really excited with the project and decided to take on this extra scope regardless. And same goes for milestone 2. :wink:

Hello folks!!

I am writing this update to confirm we are ready to deliver Milestone 2 - the final milestone for this grant!!

This 2nd milestone has been a long time coming… Focus on the Jetbrains IDE plugin, but primarily contributor availability have been the main reasons for this delay. As the latter was not something we could control, we decided to focus on the things we could control in the meantime and make as much progress as possible on the Jetbrains IDE plugin (an alpha version has already been published and we are steadily moving towards delivering the version 0.2.0, which we are also planning to promote from alpha to beta).

The deliverable for the VS Code UX studies is available here. :heavy_check_mark:

We look forward to your feedback, comments and questions. :pray:

In the meantime, we are planning a new grant proposal for the first implementation phase for the Radicle VS Code Extension. :memo:

Thanks in advance for your time reviewing this work!

@bordumb a kind request please:

if this deliverable is approved, please use the below new wallet address:

0x445717316388f1d1fb1730D3f6f9Bf59e0b03f4f

Thanks in advance!
(I will confirm this by DM on discord as well)

Thanks for the update on the wallet @yorgos

On the latest milestone for VS Code research:

Feedback

  • Really cool how the UI is creating a GUI for the initialisation of projects!
  • Great feature parity with what you guys came up with for JetBrains. So looks good go to me.

One thought on maintenance / growth:

  • Imagine at some point we have 49 different IDE plugin features for IDE A and 50 different IDE plugin features for IDE B. How can we easily find which feature is missing from IDE A to make sure they have feature parity?
  • As the CLI team adds new features, is there some way to streamline/automate the plug-in to pick these changes up easily? In any case, please consider these sort of maintenance or update work for future grants! :smiley:
1 Like

Thanks for taking the time to review @bordumb !

I have been thinking about this as well, not just in terms of the IDE plugins / extensions, but also in terms of the other alternatives people have to access the same functionality - e.g. deploying their own radicle frontend, or running the Terminal UI.

Just like we are talking about creating personas that would be more or less the same for the “code collaboration” problem area - regardless of the UI they choose to interact with the protocol - I have been thinking that the high-level User Journeys could also be another cross-component artefact we maintain across component teams. I expect there will be small differences due to the different nature of the components, but it should hopefully be possible to track journeys like: “creating issues”, “editing issues”, “attachments on issues”, etc. etc. Different teams might want to place different emphasis on different UX areas, however I think it would be beneficial for all of us to have some common input towards our prioritization decisions.

As the person on the IDE plugins team wearing more the “product” hat, I’d be happy to contribute further in any cross-team initiative in this area. (we’ve done some early work on personas already, and each grant proposal for Jetbrains / VS Code did included some early description of the User Journeys we identified, so this is something we’ve been thinking about already…)

I think this is more tricky. The User eXperience on the command-line is somewhat different to the one inside an IDE and also different to what is possible with a self-hosted web interface. Each of these Graphical User Interfaces (GUIs) offers unique advantages / limitations, and those need to be taken into account when designing the UX on each one. In addition, with the additional UX complexities in GUIs - as opposed to CLI - I expect that, rather than this becoming easier, the more features the CLI brings out, the more challenging the incorporation of those features into a Graphical UI will become…

Having said that, I only see those problems hitting us mid-term to long-term. in the meantime, we can always instruct users to perform certain actions not yet available through the IDE with a different tool available, so that they can successfully onboard to Radicle some way rather than not at all.