Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 492020

Summary: [Smart project import] Inconsistent naming
Product: [Eclipse Project] Platform Reporter: Rüdiger Herrmann <ruediger.herrmann>
Component: IDEAssignee: Mickael Istria <mistria>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, Lars.Vogel, mistria, psuzzi, ruediger.herrmann, sewe
Version: 4.6Flags: mistria: review+
Lars.Vogel: review+
psuzzi: review+
Target Milestone: 4.6 RC3   
Hardware: PC   
OS: All   
See Also: https://git.eclipse.org/r/73394
https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d172f0dd961d7b4638c911b6a46f27033f077c3a
Whiteboard:
Bug Depends on:    
Bug Blocks: 492821, 495009    

Description Rüdiger Herrmann CLA 2016-04-19 11:53:45 EDT
In most places, the smart project import is labeled as 'Import' or 'Import projects'. The File menu, however, lists the command as 'Open Projects...' - and then opens a dialog title as 'Import projects'.

I suggest to decide on either 'import' or 'open' and align the labels accordingly.
Comment 1 Lars Vogel CLA 2016-04-19 11:55:29 EDT
(In reply to Rüdiger Herrmann from comment #0)
> In most places, the smart project import is labeled as 'Import' or 'Import
> projects'. The File menu, however, lists the command as 'Open Projects...' -
> and then opens a dialog title as 'Import projects'.
> 
> I suggest to decide on either 'import' or 'open' and align the labels
> accordingly.

I think Mickael prefers "Open Projects...". Gerrit patches welcome.
Comment 2 Mickael Istria CLA 2016-04-19 12:02:37 EDT
+1 for aligning.

I do prefer "Open Projects..." and some other prefer "Import...". It's been a couple of time I/we move from Open to Import and back.
"importing" is a confusing word as it can imply importing in the workspace model and/or importing in the workspace location. This wizard only supports importing in the workspace model, which actually isn't much more than "opening" a project from user perspective.

So +1 for aligning on "Open" then.
Comment 3 Lars Vogel CLA 2016-04-19 12:38:37 EDT
(In reply to Mickael Istria from comment #2)
> So +1 for aligning on "Open" then.

I assume this was supposed to be: +1 for aligning on "Open Projects..."

+1 for this.
Comment 4 Lars Vogel CLA 2016-04-20 07:36:47 EDT
Fixed via https://git.eclipse.org/r/#/c/71020/ Thanks Rüdiger.
Comment 5 Rüdiger Herrmann CLA 2016-04-20 07:59:28 EDT
(In reply to Lars Vogel from comment #4)
> Fixed via https://git.eclipse.org/r/#/c/71020/ Thanks Rüdiger.

The above-linked change is unrelated to this bug. The open vs. import inconsistency is still there.
Comment 6 Lars Vogel CLA 2016-04-20 10:28:17 EDT
(In reply to Rüdiger Herrmann from comment #5)
> (In reply to Lars Vogel from comment #4)
> > Fixed via https://git.eclipse.org/r/#/c/71020/ Thanks Rüdiger.
> 
> The above-linked change is unrelated to this bug. The open vs. import
> inconsistency is still there.

Please use the correct commit message header in Gerrits to avoid such errors. If you follow platform bug message format, the Gerrits are auto-linked.
Comment 7 Rüdiger Herrmann CLA 2016-04-21 10:45:14 EDT
From what I understand, the wizard does two things:
1. for plain folders, creates project descriptions and imports them into the workspace
2. if folders have existing project descriptions, just imports them into the workspace (this is redundant to the 'Import existing projects' wizard)

If this summary is right, then shouldn't the name rather be 'Open Folder (as Project)' or 'Import Folder (as Project)'?
Comment 8 Lars Vogel CLA 2016-04-21 10:51:58 EDT
Lets stay with "Open Projects...", this has been agreed upon and "open folder" does IMHO not bring the correct message across.
Comment 9 Dani Megert CLA 2016-05-02 10:34:50 EDT
Calling it Open Projects is misleading since we already have Project > Open Project.
Comment 10 Dani Megert CLA 2016-05-18 13:16:36 EDT
This should be fixed for Neon.
Comment 11 Mickael Istria CLA 2016-05-18 14:23:07 EDT
Do you have any suggestion Daniel?
I really like the word open for that action so I'm failing at finding something that is pretty explicit and look simple for all users and that doesn't use Open like most application do. 
Actually, the more I think about it, the more I question the current naming of "open". I'd rather see open/closed projects in the workspace called enabled/disabled ones. However, it's not something that's out of the scope of Neon.
Comment 12 Dani Megert CLA 2016-05-23 05:56:45 EDT
(In reply to Mickael Istria from comment #11)
> Actually, the more I think about it, the more I question the current naming
> of "open". I'd rather see open/closed projects in the workspace called
> enabled/disabled ones. However, it's not something that's out of the scope
> of Neon.

I assume you wanted to say that this *is* out of scope for Neon ;-)


The 'Open Projects...' needs to go away for Neon. It looks odd and collides with existing terminology.

I see two possibilities:
1) Just remove it. Reason: Many users use other imports much more often, than from the file system (e.g. from Git).
2) Rename to 'Import Projects...' ('Import Projects from Folder or Archive' like in the Import wizard, would be best, but that's too long), and move it below the 'Import...' menu. Use 'j' as mnemonic since chances for a collision are small with this one.


NOTE: The tool tip currently shows the label string, which means the '&' is visible.
Comment 13 Mickael Istria CLA 2016-05-23 06:34:40 EDT
(In reply to Dani Megert from comment #12)
> I assume you wanted to say that this *is* out of scope for Neon ;-)\

Of course.

> 1) Just remove it. Reason: Many users use other imports much more often,
> than from the file system (e.g. from Git).

I believe this is a matter of POV or habit. At the moment, there is nothing that tells how much users are going to rely on this wizard more or less than some other ones.
People do not use solely Eclipse IDE. Some clone a Git repository with CLI or some other tool (even sometimes a concurrent IDE) and then will consider opening the content of the Git repo sometime later when it's useful for them to have it into Eclipse IDE. In such case, an "Open projects..." action well visible in the File menu is most likely what they're expecting.
So overall, -1 for removal as this operation makes total sense in the File menu. Users are very used to it because most other software work like that, and I don't see why Eclipse IDE has to keep on being so different on that topic.


> 2) Rename to 'Import Projects...' ('Import Projects from Folder or Archive'
> like in the Import wizard, would be best, but that's too long), and move it
> below the 'Import...' menu. Use 'j' as mnemonic since chances for a
> collision are small with this one.

And what about calling it "Import local projects...", and having it above the "Import..." menu?

And would a "Open local projects..." label be ok to remove ambiguity in your opinion?
Comment 14 Dani Megert CLA 2016-05-23 06:50:15 EDT
(In reply to Mickael Istria from comment #13)
> I believe this is a matter of POV or habit.

I fully agree! But if every plug-in takes your position, then we will have 10 additional menus. One for local import, one for Git, one for CVS, etc.


> And what about calling it "Import local projects...", and having it above
> the "Import..." menu?

I could live with that. But
- needs to be 'Import Local Projects...'
- the name in (and of) the Import wizard should be adjusted to that


> And would a "Open local projects..." label be ok to remove ambiguity in your
> opinion?

No, it starts an importer, and that's the first thing that's brought to the user's face when invoking the command.
Comment 15 Eclipse Genie CLA 2016-05-23 07:39:11 EDT
New Gerrit change created: https://git.eclipse.org/r/73394
Comment 16 Lars Vogel CLA 2016-05-23 08:03:45 EDT
I personally preferred the "Open Projects..." term but I follow Danis explanation about consistency. +1 for the change.
Comment 18 Dani Megert CLA 2016-05-24 04:27:54 EDT
Verified in eclipse-SDK-I20160523-2000-win32-x86_64.
Comment 19 Lars Vogel CLA 2016-05-26 16:31:25 EDT
*** Bug 494685 has been marked as a duplicate of this bug. ***