This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Please remove the help IDs from all Sun App Server nodes in the Runtime window and all the property sheets coming from those nodes.
the prop sheets are critical to manage the server. Invalid bug. RFE could be to move away from prop sheet, but beyond 4.1
Two questions: 1. Do you think that people are managing the server through the IDE prop sheets, or going to the Admin console and managing it there? 2. Do you think the one-line descriptions that are presently there actually tell you anything very useful, or would they just make you upset because you clicked a Help button and got worthless help? We don't have the resources to update the appserver prop sheet help or even check that it's correct. I think "something is better than nothing" doesn't apply in this case. If the user clicks a help button and gets help that isn't helpful, they will stop going to the help system altogether.
A1. people do use the run-time window. The plugin was designed to go into the studio products. I have to assume they requested the functionality for real reasons/use-cases. I can check to see if there are user filed issues (bugs) in the studio that would indicate that folks are using the run-time server management capabilities. A2. Worthless help is always frustrating. DUH! If the user hits F1, they wil get "help that isn't helpful". So removing the HelpID's isn't going to solve this issue at all. I think there is a very critical RESOURCE problem here. You are attempting to solve a resource issue by making a CODE change. Have you approached the team and management with a request for help with the REAL problem? From the sounds of it, you need: 1. more time to complete the help. 2. more people to correct the help. 3. all of the above. Maybe we should change the ID to content mapping file, to direct pages that haven't been corrected to some place that says... "Hey, we haven't gotten the help completely right, yet. We are working on it and will have it available from the update center when it IS READY" Would that help solve the resource issue????
Well, you could say you're trying to resolve a bad design issue with a docs change :-) The fact is these property sheets are good for people who know the appserver, but awful for people who don't. There is a resource issue, management knows about it, and the reality is that it's not going to go away in the next releases, so I don't see us having time to update the help later and put it on Auto Update. Just like management knows one person's not enough to spec out the entire J2EE project, management knows that there aren't enough docs resources to provide task-based online help, F1 help, tutorials, quick start guides, and plug-in development docs. So we've got to prioritize. Like I said in today's meeting, we can pick out the essential tasks that users need to perform with the runtime property sheets/nodes and document them in their own task pages. AFAICT, complete J2EE in NetBeans Tutorials posted on java.sun.com are much more important than detailed property sheet help.
You are absolutely correct. We need to prioritize. Your initial proposal (Remove the Help ID's) is a step backwards. I am asking you to consider a step sideways. Removing help ids makes your statement in paragraph two: "I don't see us having time to update the help later and put it on Auto Update." self-fulfilling, since it will INCREASE the cost even more. You are removing the possibility that a minor miracle could happen and forcing us into a situation where we have to hope for a major miracle.
We are increasingly moving towards a procedural (also known as 'task based') help set. As discussed at today's i-team meeting, this is the direction we are also taking for the Sun App Server. For this reason, help-ids on property sheets are increasingly being discontinued. This is not a step backwards, but forward.
Purposefully having a bunch of help buttons that lead to a page that says "We might document this in the future." just doesn't work. The user doesn't care about our resources issues - they care about getting meaningful help when they press a Help button. If the resources turn around, it's not a huge problem to put the help IDs back in.
BTW - If the help IDs are removed, F1 on these nodes will get help for the Runtime window. F1 in the property sheet will get help on the Properties window.
Response to: gwielenga 2005-02-15 10:15 PST... A help ID can ALWAYS take the user to a page that is task-oriented.... If there isn't a help id, the user cannot be taken anywhere. That is why there is a help id to content map. We can easily change the map to direct folks to any page that gets written to replace the "less than helpful help" that currently exists. [step forward] For example: If someone has the JVM node selected, there is a limited number of tasks that they CAN use the properties associated with this node to complete. The JVM node help ID could point to a page that gives them a "nudge" toward those tasks... response to John Jullion-Ceccarelli 2005-02-15 10:20 PST... You are absolutely correct. That proposal was not well thought out. I was just trying to trigger more thought. I also do not see how getting additional development time and writing time is EASIER than gettinng additional writing time.... response to John Jullion-Ceccarelli 2005-02-15 10:23 PST Getting help on the Runtime window or the properties window could be considered less helpful by some. WOW! I just had a radical out-of-the-box thought... Why not point the existing help ids at the run-time window or property window help page using the help map until we have better content available...
I'll take this one on.
Vince, thank for your ideas. Let's think about them. Please realize that we also have style guidelines to consider -- for example, the styleguidelines dictate that task-based topics should not be linked to property sheets. In the meantime, while we think on these questions, please be as enthusiastic in reviewing the context sensitive help in the New Project wizard for Enterprise Applications as you have been in triggering thought.
Obviously we don't see this from the same perspective. I am sorry that I have been unable to communicate my perspective effectively.
I think we are seeing this from the same perspectives, but there are a bunch of docs requirements that we have not communicated very well. One is that, as Geertjan said, we can't just map help buttons to existing task pages. The problem is that the connection between a task and a particular piece of UI aren't always clear. For something like a Server Manager the connection to a Registering a New Server page is obvious. For a property sheet, a task page for setting one or two of the properties may not be what the user is looking for. That's why we designed a special style for dealing with CSH. As for mapping existing help IDs to the Runtime page, that works for node (and for a long time we did it that way). But it doesn't work for property sheets, because when there's a help ID the help button is enabled, suggesting that there is specific property sheet help. Also, having lots of specific help IDs mapped to general help topics caused problems for downstream groups who were picking up our help. They had a hard time making sense of all the help IDs, and one of the specific requirements they had for us was to cut back the amount of senseless help IDs in our map file. Like I said in the meeting - we really want to hear from all of our engineers about the real developer tasks that our customers use these properties in and document them in task pages (a much better format for the user).
I agree that it is impossible to to link a property sheet to a particular task. I guess I was suggesting mapping the help for a property sheet to a page that says something like: "The properties on this page control the FOO of BAR. Changing these property values helps you perform the following tasks: T1 <link to task one's help page> T2 <link to task two's help page>" Where can I find out about this "style for dealing with CSH"? Is there another way to solve the expectation issue WITHOUT removing the helpid's? Regarding downstream groups: You are describing a communication issue between the groups. I would bet real cash money that soon after the node and property sheet help id's are removed, somebody will file a bug about not being able to get help. It is a game that cannot be won. Mapping provides greater flexibility than removal. If another group wants to have a DIFFERENT CSH strategy, mapping enables them to make that decision. Removal places the burden back on netbeans.org (us).
test dashboard
This is not a p3 issue.
okay. changing
changed the code. spending time verifying the change
Set the help ids to null for the property sheets and nodes.
v.