Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the user-experience with connectors #1012

Closed
laeubi opened this issue Oct 29, 2022 · 23 comments
Closed

Improve the user-experience with connectors #1012

laeubi opened this issue Oct 29, 2022 · 23 comments
Assignees
Labels
sponsored usability Improvements that can give a better usability or user experience

Comments

@laeubi
Copy link
Member

laeubi commented Oct 29, 2022

At EclipseCon 2022 it was complained that the Connector Install Dialog lacks good user-experience.

grafik

I could think about the following improvements:

  1. Make it default that m2e installs connectors with accepted licenses by default (that could be switched off in preferences for concerned users)
  2. Never show dialogs with errors (I can't think of a situation users can fix a missing connector)
  3. If dialog must be shown (e.g. connector without approved license) or opened manually (e.g. quickfix) improve the dialog so it clearly states what is the value of connectors, how to help with missing connectors and if connectors are chosen show what the connector does and what it offers to the user.
@mickaelistria
Copy link
Contributor

Item 2 and 3 seem consensual and could be implemented without much disruption.
Item 1 is indeed more annoying to some users (including me); I believe it should be considered separately, as we don't want to install anything by default without explaining the users why this should be installed.

@laeubi
Copy link
Member Author

laeubi commented Nov 8, 2022

For the first item I just wondering why should I not want to install it if:

  1. no licensing concerns (e.g. I previously have approved EPL 2.0)
  2. no "security concerns", e.g we only allow trusted connectors (do we have any "trust" in place at the moment beside signing? Does someone reviews the code?)
  3. I get degraded functionality otherwise

Another way would be that we add as much connectors (even external ones) we see useful by the default m2e installation (e.g. with a m2e-connectors feature) if we can get IP clearance, for example Visual studio says:

Hard disk space: Minimum of 850 MB up to 210 GB of available space, depending on features installed; typical installations require 20-50 GB of free space.

InteliJ recommends:

2.5 GB hard disk space, SSD recommended

so disk space seems not that much of a concern for users and we would only add a few mega-bytes (as most connectors are really small!)

@mickaelistria
Copy link
Contributor

There is another concern in the quality of connectors: some of them just are not good and do not make the IDE better; some others are good and do what one expects but come with a ton of other UI elements that are not desired because the grain is too coarse... We do not know what user want; I personally wouldn't like to get some connectors automatically installed just to hack some pom.xml quickly. So there should be at least a warning on the 1st attempt to auto-download that would allow user to not automatically install connectors.
Thinking about it, I think it could be a preference and this preference be shown with 1 or several checkboxes on the current "connectors" dialog: "Always install connectors when ..." (which would be like a warning).

@laeubi
Copy link
Member Author

laeubi commented Nov 8, 2022

I think that are all valid points I just wondering how should a user decide on this beforehand?
So probably we need to clean up the connectors and add some kind of measure, e.g does the connector add UI elements? If yes maybe require at least one screenshot what it adds. Probably we can require to add a "last relese" date and a website link (e.g. maven central requires to add a scm link for artifacts) ...
And at the last resort, we should remove connectors that are not stable and produce more harm than help.

@mickaelistria
Copy link
Contributor

how should a user decide on this beforehand?

Good question. Based on my experience with connectors, my strategy is to not install them and start working without them and only install them if I sense my workflow is inefficient because of missing integration of this or that connector.

@laeubi
Copy link
Member Author

laeubi commented Nov 8, 2022

But even then you can trap into one of

  1. this connector is bad and does not help
  2. this connector adds numerous UI items

So probably it would really be the best to require some kind of "quality gate":

  1. There are connectors we decide are useful, working well and are of interest of a larger audience and we iclude them by default (requires a compatible license)
  2. There are some incubation ones and we require to explicitly describe the author what it does, where one can send feedback and so on before we put them on the cataloger
  3. If for some time there are no updates, no response from the developers, we remove those and warn the user about that so one might can step-up to manage that connector

Currently its quite we recommend to install the connector (green checkmark) so user would expect its fine to install them and as there are no other measures could not really "decide". Except for some expert like you that know what connectors are, how they work, and when to use them or not.

@mickaelistria
Copy link
Contributor

some kind of "quality gate":

I don't believe expecting someone to spend time trying connectors to definie universally what's good or not can work as 1. I don't believe it's a motivating task, so I don't think anyone will ever take care of it -after all same is true for most "marketplaces" and 2. I don't believe that "good enough" is an absolute state but more something that depend on each user according to their needs, liking, priorities...

Currently its quite we recommend to install the connector (green checkmark) so user would expect its fine to install them and as there are no other measures could not really "decide".

I think it's OK to recommend the installation; but recommending (ie showing a subset of a catalog) is less intrusive than auto-installing.
Again, I'm not auto-installing. I just think it should just be off by default; but making it posisble and promoting the capability would be fine.

@laeubi
Copy link
Member Author

laeubi commented Nov 8, 2022

The good thing is that the planing council has approved m2e to be added to the funded development efforts:

https://wiki.eclipse.org/Planning_Council/2022-11-02

so hopefully there will be some "motivation" (a german comedian sometimes starts his show with the sentence "Actually I would not like to be here but I was forced - with money!) and thus I think its not entirely hopeless.

At least I more like to gather some points what would be the best, then we can decide if/how to archive and come out with at laest something good :-)

@laeubi
Copy link
Member Author

laeubi commented Nov 8, 2022

One thing for example I think would be useful is, that m2e records statistics about the runtime and probably even errors that occur while execution. If we detect that some mojo is really slow, or a connector often throws errors (instead of reporting them to the BuildContext), we can ask the user:

  1. If he likes to report this to the m2e-catlouge so we probably blacklist this connector / execution
  2. further disable the connector and/or mojo execution

@guw
Copy link
Contributor

guw commented Nov 29, 2022

I think the connector quality discussion is a result of delegating work without educating. The concept of connectors sounds nice from a technical (osgi, extensibility) perspective. However, from my experience it fails because when people write a Maven mojo to integrate their tool into Maven, they are already dealing with the complexity of Maven. It's too much of an ask to also require them to learn Eclipse specific code and processes ((M2E, Tycho, p2, etc.) just for making it work in Eclipse. They would rather say no and use IJ or some other IDE.

I am a big +1 on inner-sourcing all connectors into a M2E connectors git/project with full write access for M2E committers. IMO this way, the whole 2.0 disaster, which broke all connectors for no good reason (osgi/p2 versioning issue), could have been avoided.

@laeubi
Copy link
Member Author

laeubi commented Nov 29, 2022

However, from my experience it fails because when people write a Maven mojo to integrate their tool into Maven, they are already dealing with the complexity of Maven. It's too much of an ask to also require them to learn Eclipse specific code and processes ((M2E, Tycho, p2, etc.) just for making it work in Eclipse. They would rather say no and use IJ or some other IDE.

It is not a requirement that the mojo-author is the connector author. And it is not a requirement to "make it work with eclipse".

I am a big +1 on inner-sourcing all connectors into a M2E connectors git/project with full write access for M2E committers. IMO this way, the whole 2.0 disaster, which broke all connectors for no good reason (osgi/p2 versioning issue), could have been avoided.

Connectors where "broke" because no one maintains them and m2e can't maintain them for others that are to lazy, have lost interest or whatever.... So for most people contribution to m2e/connector this was simply not a problem.

@laeubi
Copy link
Member Author

laeubi commented Dec 8, 2022

One important goal here would be to better support the plexus-build-api, that way most connectors can become obsolete anyways.

For this we would require:

@kwin
Copy link
Member

kwin commented Dec 14, 2022

For the first item I just wondering why should I not want to install it if:

I often deliberately do not install suggested connectors as they conflict with other connectors or cause some regressions. The quality of the connectors listed in https://github.com/eclipse-m2e/m2e-discovery-catalog is not assured by anyone and therefore installing them must be handled with extreme care.

@laeubi
Copy link
Member Author

laeubi commented Dec 14, 2022

We should then remove those from the cataloger... A user has nearly no way to "guess" how good a connector is so offering them something to install where we are not sure if it helps or even causes issues is defiantly bad. Probably we can have some kind of incubator connectors or something then.

@kwin
Copy link
Member

kwin commented Dec 14, 2022

I don't think that there is capacity to do this kind of QA for third party connectors. Also in some cases they just conflict with another connector (so it is totally fine for some users not using the other connector). This is due to the fact that M2E does not really deal well with e.g. multiple Maven Project Configurators for the same packaging/mojo provided by extensions.

@laeubi
Copy link
Member Author

laeubi commented Dec 14, 2022

I don't think that there is capacity to do this kind of QA for third party connectors.

The we should not offer any such connectors by default... having arbitrary content suggested to the user is really not giving good user experience.

This is due to the fact that M2E does not really deal well with e.g. multiple Maven Project Configurators for the same packaging/mojo provided by extensions.

Can you please open specific issues for this and link them here? m2e should have now enough knowledge to decide the version of a packaging type as well.

@kwin
Copy link
Member

kwin commented Dec 14, 2022

Eclipse Marketspace (and in general open source) works quite differently than e.g. Apple App Store. Everything should be listed here anyone submitted (and therefore deemed useful). m2e committers or anyone else should not evaluate the listing, because as I said, it may be useful for some but break stuff for others.

@laeubi
Copy link
Member Author

laeubi commented Dec 14, 2022

Eclipse Marketspace (and in general open source) works quite differently than e.g. Apple App Store. Everything should be listed here anyone submitted (and therefore deemed useful). m2e committers or anyone else should not evaluate the listing, because as I said, it may be useful for some but break stuff for others.

The difference is that the marketplace is only show on user request, you have detailed information and user ratings and so on. The connectors are shown as a prerequisite to work with m2e and users won't be able to distinguish between "offered by m2e" or "offered by random 3rd party project" here.

@laeubi laeubi added usability Improvements that can give a better usability or user experience sponsored labels Dec 16, 2022
@laeubi laeubi self-assigned this Dec 16, 2022
@laeubi
Copy link
Member Author

laeubi commented Dec 16, 2022

I created

to get some feedback how we should design m2e so it fits best into Eclipse.

@laeubi
Copy link
Member Author

laeubi commented Jan 5, 2023

Also related here as if a connector installs additional builds but these do not behave good one gets disturbing error popups:

laeubi added a commit to laeubi/m2e-core that referenced this issue Jan 5, 2023
Currently if not a single connector can be proposed the dialog is still
opened and disturbs the user even though there is nothing much one can
do (and most probably want to do).

This first checks if there is at least one proposal before open the
dialog when importing a project.

This relates to eclipse-m2e#1012
@laeubi
Copy link
Member Author

laeubi commented Jan 5, 2023

One reason for the bad user-experience in the mentioned example is that junit5 is actually a gradle project but buildship currently do not provide integration with smartimport so I trying to revive:

laeubi added a commit that referenced this issue Jan 6, 2023
Currently if not a single connector can be proposed the dialog is still
opened and disturbs the user even though there is nothing much one can
do (and most probably want to do).

This first checks if there is at least one proposal before open the
dialog when importing a project.

This relates to #1012
@laeubi
Copy link
Member Author

laeubi commented Jan 9, 2023

Another disturbing dialog:

@laeubi
Copy link
Member Author

laeubi commented Mar 8, 2023

I assume this done with the recent changes, for further improvements the linked issues should be used.

@laeubi laeubi closed this as completed Mar 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sponsored usability Improvements that can give a better usability or user experience
Projects
None yet
Development

No branches or pull requests

4 participants