Bugzilla – Full Text Bug Listing
| Summary: | [Intro] Allow perspectives to contribute help | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> | ||||
| Component: | User Assistance | Assignee: | platform-ua-inbox <platform-ua-inbox> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | amj87.iitr, ankur_sharma, bokowski, cgold, deepakazad, khalsted, markus.kell.r, raposok, remy.suen | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Dani Megert
I like the idea, but we have to make sure there's an easy way to remove this information if you don't want to see "commercials" in the empty editor area. We should really discuss about the usefuleness of this. IMO, users dont see the blank editor area when they start eclipse because they always have one or more open files(The last time i saw the empty editor area was ages ago!). Isn't there someplace where we could show the tips and tricks without relying on the welcome page to be opened? (Or maybe always start with welcome page even when there are files open). (In reply to comment #2) > IMO, users dont see the > blank editor area when they start eclipse because they always have one or more > open files(The last time i saw the empty editor area was ages ago!). I see it when I end up with 30-40 editors and close all to start over again :) There is an existing product option to always open the workbench to the Intro/Welcome, with the user's option to stop that behavior: https://bugs.eclipse.org/bugs/show_bug.cgi?id=241885 But I think there's still validity to the idea of doing something with empty editor space, to improve the out-of-the box experience for new users. Some of our (IBM Rational) products have been doing something like this, and I'll try to dig up more information about how, and comment further here. (In reply to comment #2) > We should really discuss about the usefuleness of this. IMO, users dont see the > blank editor area when they start eclipse because they always have one or more > open files The whole point of this is to give *new* users initial tips and tricks. In that case the editor area is for sure empty ;-). In contrast to the Welcome page where you might get lost he will see tips directly targeted to the perspective he opened. IBM Rational Application Developer populates the empty editor area with contextual getting started information via a web page after project creation. It opens automatically on project creation and it can be accessed through the Help menu. The auto-opening capability has a built-in disablement function for more advanced users. This solution was designed to provide a soft landing from initial project creation and bridge the development environment to the documentation. We’ve integrated user assistance capabilities with product UI in a way that is relevant to the project a user has just created. The getting started information is presented as a series of links to help topics on the next possible tasks that a user can perform. We’ve also added links to samples and tutorials as well as links to actions or wizards. This solution reduces the amount of time a user has to spend looking for getting started information and makes access to documentation quicker and easier. It is implemented with extension points, so anyone familiar with the Eclipse plug-in development environment can easily implement this solution. If you're interested in learning more about this solution please feel free to contact me. I also share the opinion that Intro is not as useful as it could be because it is designed to work in full page mode most of the time and hides the workspace. I've also heard the suggestion that a mode where intro opened in an editor would be useful although that is somewhat different from this suggestion. If information on how to use features of Eclipse was presented in an editor that would have the advantage that you could work in a view and see information in the editor on how to use that view. Information in an editor would be less useful if you wanted to learn how to use an editor. I agree that showing such a page when no editors are open is not particularly useful because usually an editor is open. Maybe a better trigger would be to open the page the first time you switched to a new perspective, and it should also be possible to open the page from the help menu. I think that we would need to consider how this page would fit in with the rest of the help system - we already have intro, cheat sheets, the help view and the help browser as vehicles for providing user assistance. Kelly, are you opening the help in an (web browser) editor? Chris, it might be a good idea to look at what RAD does. Maybe it's something that could be pushed into the platform. Created attachment 183544 [details]
RAD solution for getting started
The solution opens in the editor area on project creation. It lists links to help topics that will open in the information center.
>A good place for this would be the empty editor area. > >==> Allow perspectives to specify help contents that gets displayed in the >empty editor area. After the discussions I agree that it's better to show the help in a new editor instead of putting it directly into the empty editor area. (In reply to comment #10) > >A good place for this would be the empty editor area. > > > >==> Allow perspectives to specify help contents that gets displayed in the > >empty editor area. > After the discussions I agree that it's better to show the help in a new editor > instead of putting it directly into the empty editor area. I assume this new 'help' editor will open as soon as the editor area is empty? And this editor will auto-close as soon as another editor (or view in 4.x) is opened in the editor area ? > I assume this new 'help' editor will open as soon as the editor area is empty? No. The trigger would probably be the opening of a perspective but one could also imagine to tie it to project creation (like we suggest to switch perspective). > And this editor will auto-close as soon as another editor (or view in 4.x) is > opened in the editor area ? No. The benefit of showing it in an editor instead of using the editor area is that it's still there when you open a new editor. Only when the user closes it it will go away. (In reply to comment #11) > [..] > I assume this new 'help' editor will open as soon as the editor area is empty? > And this editor will auto-close as soon as another editor (or view in 4.x) is > opened in the editor area ? It'll be more elegant to do it the 4.x way. Why not just make the help editor (view) part of all the other ones where help could be needed? So when the editor area is empty we have only the help editor, and as soon as a new editor is opened, let the help editor (view) be still present as part of a combo of the new editor and help editor. (Perhaps we can also refresh the contents of the help editor and remove "Creating a new project" from the top of the help page, and bring up the next relevant help topic instead - in a way RAD Kelly has pointed out). > be still present as part of a combo of the new editor and help editor
I don't want to have a combo in my (e.g. Java) editor.
(In reply to comment #12) > > I assume this new 'help' editor will open as soon as the editor area is empty? > No. The trigger would probably be the opening of a perspective but one could > also imagine to tie it to project creation (like we suggest to switch > perspective). hmm.. the *first* time a perspective is opened? surely you do not want this to open on switching from Debug perspective to Java perspective. Project creation sounds an ok option... but it does not happen too often. Plus will the help shown include only static content i.e. links to help documents? >hmm.. the *first* time a perspective is opened? surely you do not want this to
>open on switching from Debug perspective to Java perspective.
I guess it would be there unless the user closed the editor. We might also ask the user whether to display the next time the same perspective is created.
(In reply to comment #16) > We might also ask > the user whether to display the next time the same perspective is created. With the number of times you end up switching between Java and Debug perspective, I think almost everyone will disable this for Java perspective. I thought the idea was to utilize was to utilize the editor area while it is empty to serve as a reminder to the user about the nice help documents that exist (a user can always open these explicitly). Or you could even show some dynamic content - e.g. tips based on the usage behavior (something like Bug 330357), or even the usage data - e.g. the data collected by Usage data collector project http://www.eclipse.org/epp/usagedata/ I feel like every word I say gets twisted here.(In reply to comment #17) > (In reply to comment #16) > > We might also ask > > the user whether to display the next time the same perspective is created. > With the number of times you end up switching between Java and Debug > perspective, I think almost everyone will disable this for Java perspective. Of course one would not ask on each perspective switch. > I thought the idea was to utilize was to utilize the editor area while it is > empty to serve as a reminder to the user about the nice help documents that > exist (a user can always open these explicitly). Yes, initially that was my idea. The problem with the empty area is that it gets hidden almost immediately (e.g. creating a demo project might open a Web Browser editor and hence the help is already gone). Another benefit of just opening the help in the Web Browser editor is that not many new concepts have to be introduced, e.g. we don't have to think about how the user can get rid of the help. (In reply to comment #18) > > I thought the idea was to utilize was to utilize the editor area while it is > > empty to serve as a reminder to the user about the nice help documents that > > exist (a user can always open these explicitly). > Yes, initially that was my idea. The problem with the empty area is that it > gets hidden almost immediately (e.g. creating a demo project might open a Web > Browser editor and hence the help is already gone). Maybe we can do both ? 1) Show help in a Web Browser when a perspective is 'created' (or a new project is created). I agree that on perspective creation it would be better if the help does not go away too quickly. 2) Show help in the empty editor area at other times. Perspective creation and new project creation are not that common occurrences, it could be useful to show help/tips and tricks at other instances as well. Are we considering this for 3.7 or is it more a discussion of something that might happen in a future release. It seems that some of the design issues we would need to deal with are similar to issues which intro has had to deal with, including: 1. Do we assume that a browser widget is available on the target platform, if not what do we do? 2. Is the content served locally using the file: protocol or do we start the help server to load content? Do we support content in jarred bundles? 3. Assuming that we don't use the help server to load content we would probably end up defining a protocol such as help: for opening help pages and add listeners to the browser widget to handle that protocol (which is what intro does). Would we want to define other protocols also to handle different kinds of links? >Are we considering this for 3.7 or is it more a discussion of something that
>might happen in a future release.
Probably depends on the size of the changes.
Since intro is already present/loaded at the time we'd want to show some perspective-centric help I guess we could simply use the same mechanism/logic.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |