IDEA 13.1 Plugins UI losing features and functionality. Wrong direction?

I hava already filed 2 tickets for the lack of sorting and wasted space, but I think your observations deserve a few tickets on their own :-)

http://youtrack.jetbrains.com/issue/IDEA-120957
http://youtrack.jetbrains.com/issue/IDEA-120956

I've added another issue as well:
Plugin manager: show indicator for auto-disabled (jetbrains) plugin

Agree.

The big green install button is fine, but the table should be just reverted. It is seriously bad.

100% agree. I don't understand what problem the new UI is trying to solve, so this drastic change for the worse is baffling. The 13.0 UI was just fine and had all the information that I needed to make decisions about downloading and installing plugins. The fact that the date, rating, and # downloads columns are gone is inexplicable (putting them underneath breaks a fundamental UI rule of being able to scan the list easily). I used that information to decide whether I want to even give a plugin a chance. I sorted by those columns all the time and now I can't even sort by date?!? Also, showing the date as in "one month ago" or "2 years ago" is a LOT less useful than an actual date.

Please, please, please bring back the old table, this is a HUGE step backwards.

;ted
--
http://about.me/tedmyoung

Thanks Dimitar. I planned to submit feature requests but thought I would see if anyone else agreed first and perhaps give JetBrains developers a chance to explain the design direction in case they have plans to improve the UI in a different direction I am not imagining. Thanks for submitting them in youtrack.

I submitted http://youtrack.jetbrains.com/issue/IDEA-121073 if you'd like to vote on the "Shopping Cart" plugin installation model. Thanks.

Thanks for pointing this out. I agree with many of your points. Especially: I don't really see what kind of problem the UI tries to solve with using larger list cells for each plugin. It just means more scrolling. More scrolling is never good for developers.

Basically, there's only two things bugging me with the old plugin UI:

• there are plenty of old plugins that I probably shouldn't install because they wouldn't run on my current versionon IDEA. Should I be really able to choose "Refactor-X for IDEA 6.0" when my current version is IDEA 13? Will it run? Is it even still relevant? I believe that there should be at least some way of tracking how many exceptions occur in a plugin with each IDEA build and that should be displayed as a quality measure. Sometimes the exceptions occur because IDEA was updated but the plugin wasn't (e.g. Atlassian connector didn't run properly with some IDEA 13 releases for me).
• there is no way to sort the list of plugins by "has update available". If there where a column separate for that, I could sort by that column.

Of course, it would always be nice if plugins handled dependencies better (e.g. you would be able to see dependencies when you select the plugin or if the installation process were aware when dependent plugins are installed together), but that wouldn't be mission critical for me.

The most important pain point for me is the lack of coordination between IDEA releases and plugin releases. I definitely would like to know before updating if the update breaks a JetBrains plugin (e.g. Python plugin or the Ruby plugin) and when an update is expected to be available. This is a problem that I don't see being adressed by the plugin rewrite so far.

A nice touch would be to add an exception reporter for plugins that dumps deduplicated exceptions to a YouTrack instance. It would be a generous move to give every plugin it's own free YouTrack project (of course linked/integrated with IDEA UI). Would you rather like to see issues for plugin XY being tracked at GitHub or with YouTrack? To make it really fancy, every plugin could even get a free TeamCity cloud instance that creates snapshot builds.

Was

Now:


Was:

Now:

The description panel is nice, but what improvement was supposed to be done in the table? Because I do not see any.

I see the difference. Unfortunately I still see it as being less usable than before. There is not much usability loss on the bundled plugins view. There is more usability loss on the 3rd party plugin repositories view with the new layout. I also don't like a lot of extra whitespace in my code because I can see more all at once. I guess I'm just wired that way.

Is there information on the feature request or design direction given to the engineering team? Did UX Designers ask for the change? Just curious.

I never minded the columns in the old layout. However, I did wish from time to time that the autosizing was smarter but I have a wide enough screen resolution that I would resize the window to expand the columns anyway. But it didn't bother me often enough to submit a youtrack issue for it.

Was the plugin view ever organized as a tree view by category? Maybe it's the web view I'm thinking of. A tree view doesn't solve the sorting problem but it might help discoverability by collapsing/hiding the volume of available plugins. Maybe just like the VCS Change Repository view allows Filter by None, structure, or user  and group by date or user. The plugins could be flat as they are now or in a tree view by category or filtered by age, version, updated, etc.

If the screen images are meant to convey "This is the way it is. Accept it." I'll stop discussing but if you'd like more feedback and brainstorming I'm happy to continue.

Konstantin,

thanks for sharing. It certainly does look prettier than before. I'm just not sure what the main objectives of this refactoring are (i.e. which use cases you're trying to improve).

Regarding the plugin repository browser: There seems to be no more way to sort by age. This is something I'm actually doing quite frequently (to group the old stuff at one end and to see what changed recently). I'm doing this even more frequently than sorting the available plugins by name (again because of older plugins)

Regarding the install plugin button: This is too much web style for me. If it is within the viewport of the scrollpane, it might scroll out of the visible area which isn't good (can't really tell from screenshots).

Regarding the "Install JetBrains plugin" and "Browse Repositories" (why is actually plural here?) buttons: maybe those two should be unified. Productivity Support is installed through the former, the wonderful Copy on steroids from the latter. Both plugins have a JetBrains background. I frequently pick the wrong button when I'm searching for stuff. Also, I just don't fancy having two lists when I can use speed typing in the list anyway.

The way I use these screens, I don't really bother with the plugin category at all; this doesn't offer any extra information if it's prominently shown in the list. I'm mainly using search to find plugins (i.e. by parts of the name).

Also, it's good that the plugin type is not shown as prominently anymore. Bundled is clear to me but for example, I wouldn't know the difference between "From Repository" and "Custom". Maybe bundled plugins could have a small IDEA icon? But that's just thinking out loud.

Could you add to the Show dropdown an entry "Plugins ready to update" that shows all plugins that can be updated? That would be applicable for the repository browser as well as the installed plugins. Maybe also: incompatible plugins.

Hope that helps.

Thanks all for the feedback! Our most sincere intention is to make IDEA more usable, but with the sheer number of usage scenarios, user needs and especially point of views, the changes we make sometimes can be a bit off track. That’s why we really appreciate your feedback as it gives us more understanding on what is important.

I’m a UX consultant for the IDEA and would like to give reasoning behind some of the recent changes.

The list of installed plugins


The primary usage scenario for installed plugins is the following: search for a plugin (visually or with the search box) -> see plugin status ->  make changes (activate/deactivate, update, uninstall).
The “after” version attempts to streamline this process by making search more accessible  (e.g., by placement of the search box and a more clean layout of the list) and by making the primary action more clear and visible (e.g., the update/uninstall button with clear label saves time learning what are these icons in the toolbar are, especially for new users and for those who install plugins not often).

The list of repository plugins


Here we saw the primary scenario as follows: search for a plugin by keywords (as there are too many plugins in the repository to search visually) -> based on plugin name, number of downloads, update date and rating, and with the help of category name, select the most suitable plugin -> read description -> install. Given that we focused on this scenario, without knowing of a need to just browse for all new plugins, we removed sorting and tried to focus on scannable representation of the list.

With the feedback you provided us, we see that our priorities were in a way misguided and are going to correct accordingly.

Thank you for sharing the reasons behind the changes. My typical usage is looking for new plugins, to see what might be useful or interesting, which is why I was unhappy about the removal of date-related features, both in terms of how it's displayed and ability to sort. Also, sorting by rating is something I do on occasion. A secondary scenario for me is to look for a specific plugin.

For me, the ability to filter would be just as useful as sorting, e.g., show me plugins that are new or have been updated in the last 2 weeks and have ratings of 4 stars or more.

;ted

Few more use-cases:

• I often want to know whether a plugin is being developed/endorsed by JetBrains and whether it is bundled in IDEA.
• • I would think that a natural indicator for this is the icon which currently serves only decorative purposes.
• I rarely use the categories because I find them ambiguous
  • For example: 'Code Editing' vs. 'Custom Languages' vs. 'Code Tools'
  • Some other system of classification may be better - i.e. crowdsourced tags? In this case the whole experience needs to be rethought - i.e. browsing by tags assumes discovery features like tag clouds, top 10, movers and shakers, etc.
• Occasionally I want to disable all non-bundled plugins when I am investigating a problem with IDEA
• A lot of time I wished to review and use an older version of plugin
• • Sometimes I just want to revert to a previous version I used of certain plugin.
  • Sometimes I need to find what is the latest version of plugin that supports a specific version of IDEA (and install that)
  • Some plugins maintain a release history in the plugin description, some don't.
  • It would be good to add history as standard feature of the repository and clearly show what is new and what changed when. If we get fancy, the plugin repo would run a minimum TCK (i.e. that a plugin starts up and executes specified actions on a sample project without exception)
• Displaying the number of exceptions reported against the combination of the specific plug in version and the currently running version of IDEA would be an awesome touch.