How do we represent the Extensions UI?

[austincondiff]

A question we’ve recently run into is how the UI around extensions should be represented and where this functionality should be placed. We have three options:

1. Navigator Sidebar
2. Separate Extensions Manager Window
3. Settings Window

Considerations

• Extensions have settings
• Extensions can be enabled/disabled per project
• Settings can be overridden per project
• Apple may not like creating our own “App Store” within our app

Navigator Sidebar

Apps that do this

VS Code

Pros

Easy Access / Great discoverability

Cons

The sidebar on the left contains navigator sidebars. Navigators help you to navigate the project the containing window represents. Extensions do not really help you navigate any specific project, but rather apply to all projects and are universally scoped. This may disqualify this option for us.

UI Design Concept

Separate Extensions Manager Window

Apps that do this

Nova

Pros

Dedicated window means clear direct and targeted functionality
Out of the way when you don’t need it

Cons

May be seen as a separate App Store within CodeEdit
How do we handle extension settings? Do we place them in the extension manager or the Settings window? If an extensions settings are in the Settings window, does this abstraction of an extensions settings from the installing/disabling/uninstalling functionality in the Extension Manager window make sense? Now we’ve split how the user interacts with settings. If we leave the extension settings in the extension manager, is it clear that these settings are in the Extension Manager window and not in Settings with all the other application Settings?

UI Design Concept

Settings Window

Apps that do this

IntelliJ, Sketch, Raycast

Pros

Easy Access / Good discoverability (if the user ever opens Settings which is very likely)
Does not seem like we have an “App Store” inside our app

Cons

Might clutter Settings

UI Design Concept

This falls right in line with my plan on how we can override settings per project...

Conclusion

The thought is, we might need a separate extensions window because we need the additional space. But I am not so sure we really do. For example...

Less is generally more here. With a block of text like an extension description, a wide area is difficult to read because it results in more eye travel. A narrow space is necessary so in wide windows you constrict the width and center the block of text. This waists space. The key here is is using our space most efficiently.

If we were to use a separate window, it would feel like an App Store within CodeEdit, and I believe that is generally frowned upon by Apple. Putting it in settings doesn't really change functionality, however it looks a lot less like an app store.

If we are going to have extension settings, and we want to override those settings per project in project settings. Having a separate window is great until we want to change it per project. At that point we would have a settings override and extensions override window in addition to settings and extensions which is too much and would causes the users to have to think too much about where things are. If we built it into settings we would only need a Settings window and a Project Settings window which feels much better to me.

These are my findings in my design process. As you might tell I have gravitated to integrating it in settings as I have thought these three scenarios however if I am missing anything please let me know.

[austincondiff]

If we did go the Settings route it shouldn't be terribly difficult to change if we so chose to do so at a later point. We would also have a menu item similar to this one to jump the user right into Extensions within Settings.

[austincondiff]

I also think the inclusion of "Create New Extension..." in the Extensions menu is brilliant here as it encourages developers to write new extensions.

[Wouter01]

Great write up!
After looking at all the concepts again, I still think the separate window would be the best, most intuitive one to use. For project-specific settings, an idea like your concept would work great I think. I'd also think it might become confusing if project-specific settings and the general settings look too much like each other, as it might cause confusion. I've extensively used Jetbrains IDEs, Nova, and also quite a bit of VSCode and in my opinion, Nova's way of handling extensions is the most clear, so that's my preferred way.

I do agree that lots of additional space is definately not the way to go, as you shows in your last concept. However, it also might not look too crammed, which it nearly is in the settings page. The separate window is the sweet spot in this case in my opinion, as you can resize it easily according to your needs.

Curious to see what other people's opinions are!

[austincondiff]

If we are going to have extension settings, and we want to override those settings per project in project settings. Having a separate window is great until we want to change it per project. At that point we would have a settings override and extensions override window in addition to settings and extensions which is too much and would causes the users to have to think too much about where things are. If we built it into settings we would only need a Settings window and a Project Settings window which feels much better to me.

How would you handle this scenario then? Where would the user go to make project overrides to extension settings?

[Wouter01]

If we are going to have extension settings, and we want to override those settings per project in project settings. Having a separate window is great until we want to change it per project. At that point we would have a settings override and extensions override window in addition to settings and extensions which is too much and would causes the users to have to think too much about where things are. If we built it into settings we would only need a Settings window and a Project Settings window which feels much better to me.

How would you handle this scenario then? Where would the user go to make project overrides to extension settings?

I think these could live in a sheet, together with the project-specific settings, like in your concept. The reasoning behind why it could work here, but not for the global settings is:

• You don't have the extension store
• Not all settings tabs will be displayed for a project, e.g. the updates tab
• Extensions that aren't actively used by the project could be hidden in a dropdown

I'm again following the way Nova does it

[fuzenco]

Navigator sidebar would be my preference. At least with VSC, I find myself turning extensions on/off frequently. The sidebar makes this faster. Your UI design concept is actually pretty nice.

[Wouter01]

I think an extension navigator sidebar could be handy for project-specific settings, so e.g. turning off an extension for a specific project. If there would be a sidebar, would you expect it to handle extensions for the project only, or global?

[bombardier200]

My thoughts were to have both! Giving the user the option to have it on sidebar, VSCode way, or the separate window like nova. The reason I say this is because if a user changes extensions a lot they will not really like having to go the separate window because it would be a pain. So having it in sidebar for them would be best. But for someone who never changes their extension or rarely does, they might not want the editor cluttered with yet another tab so they will chose the separate window route. This also gives the users switching over to using our editor the options of using something familiar to them which is a great plus.

[austincondiff]

I know my thinking is somewhat different than what has been done in the past, but I'd like to challenge the status-quo.

My goal is to have more simplicity conceptually by putting both application settings and extension settings together. VS Code has all of their settings together for example. We have moved our settings from an editor tab to an external settings window. While this is more Mac-like, it introduces a problem. The app settings are no longer co-located with the extension settings as with VS Code. Putting Extensions in Settings fixes this problem.

I've been looking at this for weeks. I never intended to go this direction. But the more I look at it the more it makes sense as I look from all angles. Putting Extensions in Settings makes things very consistent with project settings which feels very nice and natural.

No, it isn't what people are used to and yes it's different, but I strongly believe it is a pattern that people will discover they like even though they never had it before.

Sketch and Raycast are the only native Mac apps I can think of that supports extensions and they both have Extensions in Settings. That is enough for me to see that as a pattern and follow suit.

[AngelTheTwin]

As extensions are things we may visit once to install and then almost never need again, I believe using a separate window for the extensions store is the way to go.
As for the project specific extensions, I'm thinking the sidebar menu that's on the mockups for CE could be the place to turn ON/OFF extensions for the project we're currently working on. At last, the sidebar is where we see project specific info. And if the extension has some project specific settings it could be open in the workspace area.

[lukepistrol]

I think the workspace should be exactly that - a work space. Everything else that might disrupt the workflow should live in its own window. I really hate to navigate through VSCode's extensions and settings since it is just repurposing the space that is available from other scopes (like displaying the file tree). Most of the time setting up an extension should be a one-off task (set and forget) and I like the idea of doing that in a visually separate space like an extra window.

So I would go for option 2 since it offers the most flexibility when it comes to laying out things in the UI. Just repurposing for example the navigator sidebar is a bad UX approach.

We could still have an extensions tab in the navigator but just use it for enabling/disabling extensions for this specific project (checkbox, toggle-switch,…). Everything else that usually only gets setup once should live in the designated extensions window.

I understand that this is a tough decision to make and everyone will have slightly different opinions but I see a consensus here that most of the time these things will be "set & forget".

EDIT

And for those who need it regularly it's not a big thing to ask to remember a simple keyboard shortcut like the proposes ⇧⌘2