Bugzilla – Full Text Bug Listing
| Summary: | [About] About dialogue should use "name" (i.e. plug-in name) instead of provider name for hover-over popup | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Larry E Williamson <larrywil> | ||||
| Component: | UI | Assignee: | Kim Horne <eclipse> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P5 | CC: | bjorn.freeman-benson, bokowski, bugs.eclipse.org, cross-project.inbox, eclipse-bugs, gdtaylor, Kevin_McGuire, mober.at+eclipse, pascal, phil.kursawe, remy.suen, richard.gronback, Tod_Creasey | ||||
| Version: | 3.0.2 | Keywords: | helpwanted | ||||
| Target Milestone: | 3.5 M4 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Server 2003 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Larry E Williamson
I noticed this same symptoms in IBM's Rational Application Developer. The hover help is derived from the provider_name, which doesn't make this About information very helpful if you have no labels and all the hover over popups (except 1) say "IBM". Wouldn't you think that plugin name (or maybe a hover over indentifier string that the application could set) would be more useful? I'll attach a snapshot of an example of what I'm seeing. Thanks/regards, Larry E Williamson Created attachment 75848 [details]
Example of hover over popup using provider name
These aren't plug-in icons - they're feature icons. And even then, only kind of - they're every unique icon used to describe a feature in our system. If two features share the same icon/vendor then only one icon is shown. Showing the feature name here instead of the vendor could be problematic because you cannot guarantee there is only one feature to show. My initial inclination would be to mark this as "wontfix" but there might be something we can do. Perhaps we could use one of our new fancy tooltips to add a list of included features. This is low priority at any rate. I didn't even realize that the about dialog was attempting to collapse identical icons. In our product, I see icons that are slightly different incarnations of each other (different background color, same icon for example), or are identical to my eye. Perhaps the design should be changed so that collapsing is not done. This would allow you to make the hover helps much more useful. Without that collapsing the number of icons for the average IBM product would span about a dozen lines. The idea for the initial about screen is to give a brief overview of the contents of your installation - the user can then click on the plug-in or feature button to further drill into this information. Putting it on the main page would be counterproductive. As for the (apparently) duplicate icons, this is likely an issue with how the icons are being stored/distributed in the sourcebase to the affected product. Equality for these images is done via a hash of the bytes of the uncompressed image. If the image has been loaded and saved by different programs these hashes could differ. Any indication of this should be logged against the appropriate IBM product team. I appreciate the dialogue - interesting to see the different perspectives. At the heart of the question, I would think, is how the facility is interpreted by the end-user. I pasted in what I see in the Message Broker Toolkit "About Message Brokers Toolkit". Kim, has the facility - particularly the feature / plugin icon approach been reviewed by human factors for the usability aspects? I'm surprised that end-users find this screen helpful. I doubt that end-users will readily relate the icons to any one specific feature or plugin. Having the hover-over identifier of "IBM" (which seems to be extracted from "provider name") for all of them doesn't help at all. You'd think that the interface would use a "feature name" or "plugin name" structure so that something meaninful would appear when you place the cursor above the icon. I'll include Theresa Ramsey with WebSphere Human Factors in this reply - perhaps she has time to comment. Theresa, I've included the bug dialogue below the snapshot. You can see the issue by looking Rational Application Developer or the WebSphere Message Broker Toolkit. Use the "Help / About <product>" to see the page. You'll see a string of unlabeled icons mostly with hover-over identifiers of "IBM". You actually have to click on each icon to figure out what feature or plugin set they're associated with. It seems to be a very unfriendly design. Taken as ONE product, this would be low priority. But when you see that several IBM products suffer from the same issue, I think that makes the issue a little more important. Right, I can see that adding all features would not be a good idea. Could something be done with product definitions instead? Or is there the possibility of finding out the top-level features (features that have no dependencies) and using these as categories? Along the lines of the previous comments, the categorization needs to make sense to the end user. Users have no idea about features. They might be able to grasp products, but even this might be a stretch. For WID, I was thinking that I'd like to see: -WID -RAD -Eclipse Note that there are other layers than what I listed above, but I think users know of those three main layers (I could be wrong). (In reply to comment #7) Agree with Grant's comments. Problem is that we have no description at that macro level such as WID vs. RAD vs. Eclipse SDK. Thus we have this curious "group together by like icon" algorithm which is news to me. With 'features' still being a rather poorly understood item, I am somewhat reluctant to suggest we add another structure. Yet the user scenario Grant describes is quite valid. End users want to know what's in the box at a macro level and product branding and identification of layers is important given how we now build our products. What about a structure that looks like the following? (I used the term "productlet" because all the good words like bundle and feature are already taken <g>) <productlet> <id>com.ibm.wid</id> <name>WebSphere Integration Developer</name> <version>6.1.2.7</version> <iconpath>/icons/wid.gif</iconpath> <buildID>20070806</buildID> <builtOn>com.ibm.rad</builtOn> </productlet> <productlet> <id>com.ibm.rad</id> <name>Ration Application Developer</name> <version>8.3</version> <iconpath>/icons/rad.gif</iconpath> <buildID>20070501</buildID> <builtOn>org.eclipse.sdk</builtOn> </productlet> <productlet> <id>org.eclipse.sdk</id> ...etc... Thinking even more broadly, these seem to match the level at which we want to hook custom error reporting. Hmm... *** Bug 226244 has been marked as a duplicate of this bug. *** Pascal, is there p2 metadata that could help us out here? I just looked at I20080422-0800 and it seems that this enhancement has actually been implemented already: When hovering over an icon in the about dialog, the tooltip now no longer shows the provider only, but it shows the branding plugin name of a feature.
The problem I see with the current implementation is, that in case multiple features (and their branding plugins) have the same provider and the icon, so they are collapsed under one icon, arbitrarily pick any of their branding plugins to contribute the name for display in the tooltip.
In the case of Eclipse installed with RSE and EMF, this results in some oddities: Hovering over the EMF icon displays
"Eclipse.org - Eclipse Modeling Framework (EMF) -
org.eclipse.emf.mapping.ecore.editor"
or hovering over the Eclipse icon displays
"Eclipse.org - RSE DStore Services Source"
which is really confusing.
I see two possibilities for approaching this problem:
(1) Keep the current behavior, but instead of randomly picking a branding
plugin, sort the branding plugins by plugin id and pick the
alphabetically first one.
This will ensure that in case of "a.b.c.d" any prefix like "a.b" will win
over the others, so it's likely a "more geneeral" feature is allowed to
contribute the text.
(2) Get rid of the change and show the provider only, but encourage all
Eclipse project that whenever they have a custom icon, they MUST ALSO
have a custom provider name, e.g. "Eclipse Tools Project" or
"Eclipse Modeling Project" rather than just "Eclipse.org".
This had been suggested for Europa already, but nobody just picked it up.
I think it's a good idea, it's the right solution, and it should be
done now.
See also http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg00376.html
Will look into this in 3.5. Will you revert the current random situation to using the Provider again for 3.4? Boris, what do you think? You checked this in as a fix for bug 219892... (In reply to comment #11) > The problem I see with the current implementation is, that in case multiple > features (and their branding plugins) have the same provider and the icon, so > they are collapsed under one icon, arbitrarily pick any of their branding > plugins to contribute the name for display in the tooltip. I was not aware of this. > (2) Get rid of the change and show the provider only, but encourage all > Eclipse project that whenever they have a custom icon, they MUST ALSO > have a custom provider name, e.g. "Eclipse Tools Project" or > "Eclipse Modeling Project" rather than just "Eclipse.org". > This had been suggested for Europa already, but nobody just picked it up. > I think it's a good idea, it's the right solution, and it should be > done now. I would be in favour of (2). And I had thought I found one thing in Eclipse that was easy to fix... :-/ (In reply to comment #15) > (In reply to comment #11) > > The problem I see with the current implementation is, that in case multiple > > features (and their branding plugins) have the same provider and the icon, so > > they are collapsed under one icon, arbitrarily pick any of their branding > > plugins to contribute the name for display in the tooltip. > > I was not aware of this. > > > (2) Get rid of the change and show the provider only, but encourage all > > Eclipse project that whenever they have a custom icon, they MUST ALSO > > have a custom provider name, e.g. "Eclipse Tools Project" or > > "Eclipse Modeling Project" rather than just "Eclipse.org". > > This had been suggested for Europa already, but nobody just picked it up. > > I think it's a good idea, it's the right solution, and it should be > > done now. > > I would be in favour of (2). > > And I had thought I found one thing in Eclipse that was easy to fix... :-/ > This suggested fix is in HEAD. Bjorn, should this recommendation be brought before the planning council? Thanks Kim. You likely meant target milestone == 3.5M4 ? Ooops, yes - the releases are all blurring together now ;) Ooops, yes - the releases are all blurring together now ;) (In reply to comment #16) > Bjorn, should this recommendation be brought before the planning council? I added this as an item for our next call, thanks. http://wiki.eclipse.org/Planning_Council/Dec_03_2008#Topics Per our discussion on today's Planning Council call, we've decided to make the should-do requirement for branding a must-do, and to augment its description with the advice here that provider names be more descriptive than Eclipse.org (to be determined by each PMC for their projects). *** Bug 282777 has been marked as a duplicate of this bug. *** |