Bug 481072 - Simplify the marketplace experience
Summary: Simplify the marketplace experience
Status: CLOSED FIXED
Alias: None
Product: MPC
Classification: Technology
Component: Install (show other bugs)
Version: 1.4.0   Edit
Hardware: PC Linux
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-29 22:42 EDT by Pascal Rapicault CLA
Modified: 2019-02-11 09:59 EST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pascal Rapicault CLA 2015-10-29 22:42:54 EDT
This is a general bug stemming from various discussions around the simplification of installation workflows (http://dev.eclipse.org/mhonarc/lists/ide-dev/msg00906.html)

Basically, people are observing that the marketplace is great but it still requires too many clicks to install something, and it is not easy to browse entries by categories such as "SCM", "Bugtracking", "Build tools", "App server", ... Another thing is that if a C/C++ user is connecting, there are probably many java related tools that are not that interesting for him/her.

So here are some ideas / interrogations:
- Near the search field, what is the purpose of the drop down that says "All Markets"? I honestly never noticed it, and I'm not sure which purpose it serves. I've tried clicking a the different entries and every time I had Yatta profile and the Optimizer...
- Could there be a place where the common categories mentioned above could be shown more prominently?
- Could it be possible to *not* force the user through a license page? For example, when the user press the "install" button there could be an implicit agreement of the license. Note that this is what intellij does, it never prompts you for a license. Instead it shows it to you when you look at the solution.
- When the user hits "install", can't the install just happens? No need to prompt for more, have the complex flow of back and forth. If we wanted to allow for cancellation, there could be a tab showing all the things that are being installed.
- Better filtering of the solutions based on the tool we are installing from. For example if I'm installing from a C++ package or Java I should likely not see the same thing.
- Allow the user to jump to the uninstall page from the marketplace?
Comment 1 Ian Skerrett CLA 2015-10-30 09:23:51 EDT
Thank you for the suggestions. We are looking at improvements for Neon so this is timely.

(In reply to Pascal Rapicault from comment #0)

> 
> So here are some ideas / interrogations:
> - Near the search field, what is the purpose of the drop down that says "All
> Markets"? I honestly never noticed it, and I'm not sure which purpose it
> serves. I've tried clicking a the different entries and every time I had
> Yatta profile and the Optimizer...

Markets are a type of categorization in Marketplace. The Markets I see are Tool, RCP, Eclipse Project and LTS.  I am not sure why you are seeing Yatta profile? Can you attach a screen shot.

> - Could there be a place where the common categories mentioned above could
> be shown more prominently?

The challenge will be to define the 'common' categories. I can guarantee you that your list will be different than someone else.

> - Could it be possible to *not* force the user through a license page? For
> example, when the user press the "install" button there could be an implicit
> agreement of the license. Note that this is what intellij does, it never
> prompts you for a license. Instead it shows it to you when you look at the
> solution.

Interesting suggestions, let me look at the implications.

> - When the user hits "install", can't the install just happens? No need to
> prompt for more, have the complex flow of back and forth. If we wanted to
> allow for cancellation, there could be a tab showing all the things that are
> being installed.

At one point this was how MPC worked but we got feedback that people wanted to be able to queue up a number of plugins to install before starting the installation process. 
> - Better filtering of the solutions based on the tool we are installing
> from. For example if I'm installing from a C++ package or Java I should
> likely not see the same thing.

I guess this would be another type of categorization. Is it language dependent or something else?

> - Allow the user to jump to the uninstall page from the marketplace?

Not sure I understand what you mean.
Comment 2 Pascal Rapicault CLA 2015-10-30 18:13:41 EDT
(In reply to Ian Skerrett from comment #1)
> Thank you for the suggestions. We are looking at improvements for Neon so
> this is timely.
> 
> (In reply to Pascal Rapicault from comment #0)
> 
> > 
> > So here are some ideas / interrogations:
> > - Near the search field, what is the purpose of the drop down that says "All
> > Markets"? I honestly never noticed it, and I'm not sure which purpose it
> > serves. I've tried clicking a the different entries and every time I had
> > Yatta profile and the Optimizer...
> 
> Markets are a type of categorization in Marketplace. The Markets I see are
> Tool, RCP, Eclipse Project and LTS.  I am not sure why you are seeing Yatta
> profile? Can you attach a screen shot.
    At this point I kinda doubt about the relevance of those for a couple reasons:
- The first is that the name and intent of each market is only understandable by Eclipse insiders.
- The second being that if I switch between all these entries, I keep on seeing as first entry the "optimizer for Eclipse" and most of the time the vaadin one. So as I user I don't really attach any trust to what I'm being presented with.
- The third is that the categories don't necessarily make sense in the context I'm in:
   - RCP Application - why would I want to see those when in my IDE. Especially when I can't install them?
   - Long term support - this market is empty (ok there are two entries but they are unrelated to LTS). What would I go find there?
   - Eclipse projects - it shows projects that are not Eclipse and in only includes 9 entries in total which is obviously wrong.
So all in all the only thing that I can trust is the search.
 
> > - Could there be a place where the common categories mentioned above could
> > be shown more prominently?
> 
> The challenge will be to define the 'common' categories. I can guarantee you
> that your list will be different than someone else.
   You and I decide. That's it.


> > - Could it be possible to *not* force the user through a license page? For
> > example, when the user press the "install" button there could be an implicit
> > agreement of the license. Note that this is what intellij does, it never
> > prompts you for a license. Instead it shows it to you when you look at the
> > solution.
> 
> Interesting suggestions, let me look at the implications.
> 
> > - When the user hits "install", can't the install just happens? No need to
> > prompt for more, have the complex flow of back and forth. If we wanted to
> > allow for cancellation, there could be a tab showing all the things that are
> > being installed.
> 
> At one point this was how MPC worked but we got feedback that people wanted
> to be able to queue up a number of plugins to install before starting the
> installation process. 
   This may have been a consequence of how the tool worked. For example it may have been before we had the p2 remediation. I think it worth re-exploring what can be done.

> > - Better filtering of the solutions based on the tool we are installing
> > from. For example if I'm installing from a C++ package or Java I should
> > likely not see the same thing.
> 
> I guess this would be another type of categorization. Is it language
> dependent or something else?
    I think we can do this automatically by using the product id, or the plugins that are installed (for example if jdt.ui plugin is installed then it means that the user uses Java, if cdt.ui is installed...).
    
> > - Allow the user to jump to the uninstall page from the marketplace?
> 
> Not sure I understand what you mean.
   In a situation where the only place I go to install a plug-in is the Eclipse MarketPlace, then it would be great to provide a link to the uninstall page (the equivalent of Help > About> Installation details) or provide users a way to directly uninstall solutions.
Comment 3 Ian Skerrett CLA 2015-10-31 20:25:11 EDT
(In reply to Pascal Rapicault from comment #2)
> (In reply to Ian Skerrett from comment #1)
> > Thank you for the suggestions. We are looking at improvements for Neon so
> > this is timely.
> > 
> > (In reply to Pascal Rapicault from comment #0)
> > 
> > > 
> > > So here are some ideas / interrogations:
> > > - Near the search field, what is the purpose of the drop down that says "All
> > > Markets"? I honestly never noticed it, and I'm not sure which purpose it
> > > serves. I've tried clicking a the different entries and every time I had
> > > Yatta profile and the Optimizer...
> > 
> > Markets are a type of categorization in Marketplace. The Markets I see are
> > Tool, RCP, Eclipse Project and LTS.  I am not sure why you are seeing Yatta
> > profile? Can you attach a screen shot.
>     At this point I kinda doubt about the relevance of those for a couple
> reasons:

I tend to agree with your analysis. The only exception is in the Eclipse projects and that is because the Eclipse Projects market was not completely implemented. If we could list all the Eclipse projects I think it would be useful to have it listed.


  
> > > - Could there be a place where the common categories mentioned above could
> > > be shown more prominently?
> > 
> > The challenge will be to define the 'common' categories. I can guarantee you
> > that your list will be different than someone else.
>    You and I decide. That's it.

This made me smile. If I only had to convince you of things, my job would be so easy. :-) In reality, Eclipse is blessed with have many different communities that want to be represented. 


> > > - Could it be possible to *not* force the user through a license page? For
> > > example, when the user press the "install" button there could be an implicit
> > > agreement of the license. Note that this is what intellij does, it never
> > > prompts you for a license. Instead it shows it to you when you look at the
> > > solution.
> > 
> > Interesting suggestions, let me look at the implications.
> > 
> > > - When the user hits "install", can't the install just happens? No need to
> > > prompt for more, have the complex flow of back and forth. If we wanted to
> > > allow for cancellation, there could be a tab showing all the things that are
> > > being installed.
> > 
> > At one point this was how MPC worked but we got feedback that people wanted
> > to be able to queue up a number of plugins to install before starting the
> > installation process. 
>    This may have been a consequence of how the tool worked. For example it
> may have been before we had the p2 remediation. I think it worth
> re-exploring what can be done.

OK, we can take a look. I don't know much about p2 remediation.

 
> > > - Better filtering of the solutions based on the tool we are installing
> > > from. For example if I'm installing from a C++ package or Java I should
> > > likely not see the same thing.
> > 
> > I guess this would be another type of categorization. Is it language
> > dependent or something else?
>     I think we can do this automatically by using the product id, or the
> plugins that are installed (for example if jdt.ui plugin is installed then
> it means that the user uses Java, if cdt.ui is installed...).

What about on the server side? Don't we need to ask each listing to specify what language they support?

  
> > > - Allow the user to jump to the uninstall page from the marketplace?
> > 
> > Not sure I understand what you mean.
>    In a situation where the only place I go to install a plug-in is the
> Eclipse MarketPlace, then it would be great to provide a link to the
> uninstall page (the equivalent of Help > About> Installation details) or
> provide users a way to directly uninstall solutions.

I am on a really slow internet connection right now so I can't check but I was sure from the Installed tab of MPC you could uninstall plugins.  I will check again later.
Comment 4 Pascal Rapicault CLA 2015-11-01 00:14:24 EDT
(In reply to Ian Skerrett from comment #3)
> (In reply to Pascal Rapicault from comment #2)
> > (In reply to Ian Skerrett from comment #1)
> > > Thank you for the suggestions. We are looking at improvements for Neon so
> > > this is timely.
> > > 
> > > (In reply to Pascal Rapicault from comment #0)
> > > 
> > > > 
> > > > So here are some ideas / interrogations:
> > > > - Near the search field, what is the purpose of the drop down that says "All
> > > > Markets"? I honestly never noticed it, and I'm not sure which purpose it
> > > > serves. I've tried clicking a the different entries and every time I had
> > > > Yatta profile and the Optimizer...
> > > 
> > > Markets are a type of categorization in Marketplace. The Markets I see are
> > > Tool, RCP, Eclipse Project and LTS.  I am not sure why you are seeing Yatta
> > > profile? Can you attach a screen shot.
> >     At this point I kinda doubt about the relevance of those for a couple
> > reasons:
> 
> I tend to agree with your analysis. The only exception is in the Eclipse
> projects and that is because the Eclipse Projects market was not completely
> implemented. If we could list all the Eclipse projects I think it would be
> useful to have it listed.
   Agreed -  bug #480546

> >    This may have been a consequence of how the tool worked. For example it
> > may have been before we had the p2 remediation. I think it worth
> > re-exploring what can be done.
> 
> OK, we can take a look. I don't know much about p2 remediation.
    You can find information about the remediation at http://prapicault.blogspot.ca/2013/05/remediation-support-goodbye-cryptic-p2.html

> What about on the server side? Don't we need to ask each listing to specify
> what language they support?
  Yes, each listing would have to say which language they support in order to be able to perform some filtering. The filtering could either be done on the server or on the client.
As for getting the data, we could ask the owners of entries to fill it, and/or compute a good approximation by analysing the dependencies.


>   
> > > > - Allow the user to jump to the uninstall page from the marketplace?
> > > 
> > > Not sure I understand what you mean.
> >    In a situation where the only place I go to install a plug-in is the
> > Eclipse MarketPlace, then it would be great to provide a link to the
> > uninstall page (the equivalent of Help > About> Installation details) or
> > provide users a way to directly uninstall solutions.
> 
> I am on a really slow internet connection right now so I can't check but I
> was sure from the Installed tab of MPC you could uninstall plugins.  I will
> check again later.
   Well, that's embarassing. There is indeed an "installed" tab :) However, now that I look at it, I can see that not all the entries that I have installed are showing there (I'll open another bug).
Comment 5 Carsten Reckord CLA 2015-11-02 10:30:49 EST
(In reply to Pascal Rapicault from comment #0)
> categories such as "SCM", "Bugtracking", "Build tools", "App server"
> [...]
> - Near the search field, what is the purpose of the drop down that says "All
> Markets"? I honestly never noticed it, and I'm not sure which purpose it serves.
> [...]
> - Could there be a place where the common categories mentioned above could be
> shown more prominently?

Those categories sound more like something that should show up in the Categories drop down. Maybe we should instead look at reorganizing that one (and making it more prominent)? Or come up with new UI for both of those?

> I've tried clicking a the different entries and every time I had Yatta profile
> and the Optimizer...

That's because they were promoted solutions at the time.

> - Could it be possible to *not* force the user through a license page? For
> example, when the user press the "install" button there could be an implicit
> agreement of the license. Note that this is what intellij does, it never prompts
> you for a license. Instead it shows it to you when you look at the solution.

MPC is currently following the standard P2 installation flow here. I agree that less clicks (ideally just one) would be great. I see at least two issues that we would need to look at, though:

1) Technically, we currently only know the full list of licenses on the client side once P2 has resolved all the bits to be installed, which can be a lengthy process 
- This might be more than just one license in case the entry pulls in additional dependencies
- Theoretically, this is complicated by the fact that licenses from external dependencies could change independently of the entry itself, making the full license list dependent on the actual result of the dependency resolution.

We could let the owner of the Marketplace entry maintain the full license text explicitly on the server. Then the question would be whether that matches the actual license(s) of the installation bits - and what the consequences would be if it doesn't match (for the Marketplace provider, i.e. the Foundation, for the entry's owner, and for the user installing the software). 

> - When the user hits "install", can't the install just happens? No need to
> prompt for more, have the complex flow of back and forth. If we wanted to allow
> for cancellation, there could be a tab showing all the things that are being
> installed.

That's certainly interesting. I see two issues here:

1) What about optional parts of the item to install? Those are currently configured on the second page and there are quite a few entries that make extensive use of them. I suppose we could split the Install action in two, one default "Install" action that just installs the default feature set, and one "Advanced Install" action that opens the configuration page.

2) The reason we let people select multiple entries before starting the installation is that it's AFAIK currently not possible to start multiple P2 install actions independently from one another (you'll get an error that an install is already in progress). We could manage our own queue to manage install requests and run them one after another, but we'd need a way to a) get notified when the running install is finished and b) suppress the restart dialog until our install queue is empty. 

We'd also need to think about the UX of having multiple pending installs in the background when the Marketplace dialog is closed, e.g. how to present the queue or when/how to give feedback and query the user if there is a resolution or installation error.

(In reply to comment #4)
> > >    This may have been a consequence of how the tool worked. For example it
> > > may have been before we had the p2 remediation. I think it worth
> > > re-exploring what can be done.
> >
> > OK, we can take a look. I don't know much about p2 remediation.
> You can find information about the remediation at
> http://prapicault.blogspot.ca/2013/05/remediation-support-goodbye-cryptic-p2.html

I don't think that remediation was the issue here, but triggering parallel/sequential installation without waiting for the last one to finish...

> - Better filtering of the solutions based on the tool we are installing from.
> For example if I'm installing from a C++ package or Java I should likely not see
> the same thing.

That would be cool :) MPC already transmits its current product id to the server, but to really do this, we would need more info on the server side. I suppose we could implement client-side rules to detect supported languages and transmit the set of detected languages together with the server request (I think instead transmitting a full list of installed features to implement the logic server-side would be too much data, albeit more flexible...)

(In reply to comment #4)
> > I am on a really slow internet connection right now so I can't check but I
> > was sure from the Installed tab of MPC you could uninstall plugins.  I will
> > check again later.
> Well, that's embarassing. There is indeed an "installed" tab :) However, now
> that I look at it, I can see that not all the entries that I have installed are
> showing there (I'll open another bug).

Since there is no obvious backward mapping from installed IUs to marketplace entries, MPC "cheats" a bit here and remembers its own backward mapping. It persists that in a file in the configuration area or in the user home, depending on access. Taking a quick look, I think I see an error in determining the write location if the config area is read-only. I've opened bug 481244.
Comment 6 Carsten Reckord CLA 2015-11-02 10:44:43 EST
(In reply to comment #5)
> > - Could it be possible to *not* force the user through a license page? For
> > example, when the user press the "install" button there could be an implicit
> > agreement of the license. Note that this is what intellij does, it never
> prompts
> > you for a license. Instead it shows it to you when you look at the solution.
> 
> MPC is currently following the standard P2 installation flow here. I agree that
> less clicks (ideally just one) would be great. I see at least two issues that we
> would need to look at, though:

Oops, I missed adding my second point here... 

I'm not sure what the situation is in the US and Canada, but at least for Europe, the problem is also that the user has to explicitly acknowledge the license. I.e. just showing the license as part of the item's presentation and implying agreement when the user installs the software would not be sufficient. There would need to be at least a checkbox "I agree with the license terms" or similar. I guess that something similar drove the implementation of the current installation wizard's license page. But maybe Ian can get more info from the Eclipse legal team?
Comment 7 Carsten Reckord CLA 2015-11-02 10:56:07 EST
Also, since we're discussing simplifications of the install story here: What would be really awesome and help make the install process much more lightweight would be the ability to install plug-ins without having to restart Eclipse all the time. But that's neither an issue specific to Marketplace nor, I guess, a very realistic goal for the time being...
Comment 8 Pascal Rapicault CLA 2015-11-02 11:01:08 EST
(In reply to Carsten Reckord from comment #5)
> (In reply to Pascal Rapicault from comment #0)
> > categories such as "SCM", "Bugtracking", "Build tools", "App server"
> > [...]
> > - Near the search field, what is the purpose of the drop down that says "All
> > Markets"? I honestly never noticed it, and I'm not sure which purpose it serves.
> > [...]
> > - Could there be a place where the common categories mentioned above could be
> > shown more prominently?
> 
> Those categories sound more like something that should show up in the
> Categories drop down. Maybe we should instead look at reorganizing that one
> (and making it more prominent)? Or come up with new UI for both of those?
> 
> > I've tried clicking a the different entries and every time I had Yatta profile
> > and the Optimizer...
> 
> That's because they were promoted solutions at the time.
   I understand that. But the fact that promoted solution take most of the real estate and on all categories is problematic to me. We'd better get some serious money from this to make it worth the pain for the users.


> MPC is currently following the standard P2 installation flow here. I agree
> that less clicks (ideally just one) would be great. I see at least two
> issues that we would need to look at, though:
   There is a flag to skip the license page.

> [...]
   I know all that. The questions we have to answer are:
    - how often do the worst case happen? 
    - Does it actually matter in the context of tooling installed by the end user?
    - How come competitor products can get away with just showing a license name and we can't?


> That's certainly interesting. I see two issues here:
> 
> 1) What about optional parts of the item to install? Those are currently
> configured on the second page and there are quite a few entries that make
> extensive use of them. I suppose we could split the Install action in two,
> one default "Install" action that just installs the default feature set, and
> one "Advanced Install" action that opens the configuration page.
    Adding two buttons will confuse users more. We know how many entries there are for a solution, let's just automatically do the right thing.


> 2) The reason we let people select multiple entries before starting the
> installation is that it's AFAIK currently not possible to start multiple P2
> install actions independently from one another (you'll get an error that an
> install is already in progress). We could manage our own queue to manage
> install requests and run them one after another, but we'd need a way to a)
> get notified when the running install is finished and b) suppress the
> restart dialog until our install queue is empty. 
     Let's focus on the user experience, not on the code limitations. Today the installation is performed by a job so you could be notified when it completes, and iirc there is an option to silence the restart dialog.
Comment 9 Carsten Reckord CLA 2015-11-02 11:22:30 EST
(In reply to comment #8)
> Adding two buttons will confuse users more.

Sorry, I didn't actually have two buttons in mind, more something along the line of what we do now on the "Installed Software" page, where you get one button with a dropdown in case there is more than one possible action. So in this case, there would just be an "Install" button and if there are optional bits, it'd have a dropdown with an "Advanced..." or "Customize..." entry.

> We know how many entries there
> are for a solution, let's just automatically do the right thing.

I don't understand. How does knowing the number of entries help determine which optional bits should be installed? And how can we automatically do the right thing if we don't know what the right thing is? 

Could it be that we are talking about different things here? Try e.g. installing the Mylyn 3.17 entry. You'll see on the "Confirm Selected Features" page that it has one required and 3 optional parts. In this case, all the optional parts are preselected by default, but entries can also decide to offer optional parts that are "off" by default to indicate additional stuff that isn't typically needed but might be of interest.

I suppose we could always install everything and let users remove optional bits afterwards, but I don't think that's nice UX...
Comment 10 Pascal Rapicault CLA 2015-11-02 11:34:02 EST
> > We know how many entries there
> > are for a solution, let's just automatically do the right thing.
> 
> I don't understand. How does knowing the number of entries help determine
> which optional bits should be installed? And how can we automatically do the
> right thing if we don't know what the right thing is? 

   We are talking about the same thing. My point is if (numberOfEntry == 1), then don't show the "Confirm selected feature" page, else show it.
And similarly, in the listing of solutions, let's not propose the "customize" button when there is only one entry.
Comment 11 Carsten Reckord CLA 2015-11-02 11:45:22 EST
Ah, okay. Fully agreed.
Comment 12 Ian Skerrett CLA 2015-11-11 13:37:01 EST
I'd like to summarize the discussion so we can capture work items for the Neon release

1. Change the 'All Markets' field to only include Tools and Eclipse Projects.
2. If a listing has only one entry to install then don't ask for confirmation, just install it.


Other items:
- License page - still need to investigate. 
- Common categories - I don't see an easy solution for defining common categories. The solution that Pascal and Ian decides doesn't seem like a winning solution.
- Better filtering - we need to investigate adding a language filter.
Comment 13 Carsten Reckord CLA 2015-11-24 13:04:18 EST
(In reply to comment #12)
> 1. Change the 'All Markets' field to only include Tools and Eclipse Projects.

This is a server-side change. I've opened bug 482934 against Community / Marketplace

> 2. If a listing has only one entry to install then don't ask for confirmation,
> just install it.

This is tracked in bug 481071

> Other items:
> - Better filtering - we need to investigate adding a language filter.

This has already been requested a long time ago in bug 317191. I'd suggest continuing this part of the discussion there.
Comment 14 Carsten Reckord CLA 2019-02-11 09:59:19 EST
I'm closing this since all the identified work items have been implemented way back.