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.
I Created a new JPanel, and went to the New Wizard's step 4, Create Fields. I found this panel awkward to use and identified several issues: 1) You must click on the New button to get started. This gives you a skeleton declaration that you can then modify. The New button is location a long distance away from where I need to type. This seems like a poor layout. 2) After hitting New and getting a skeletal entry of "int field0" I then changed the name of the field. At this point I did not know what to do in order to make the change take affect. My visual goal was to get my new name to show up in the large textarea. I instinctively hit Return. That took me to the next pane in the Wizard!! This was quite a surprise. 3) So I then hit Prev to return to Create Fields and my new name had taken affect. Again, surprising. Eventually, I determined that the changes take affect when the focus leaves the textfield. This was counter-intuitive. I think the way that new field is created and edited needs to be changed. Relying on focus lost seems like the wrong interface. I'm not sure the New button is needed. I think it would be better to view the portion of the pane below the Fields list as the Field Editor. Below the Field Editor would be and Add and Change button. Add would take the info and create a new Field and Change would apply the values in the Field Editor to the currently selected Field.
Reassigning to the proper mailing list
Yes, relying on focus is weird. Not only the user cannot control when the changes are applied, there can be several mutually dependent controls which cannot be handled this way (in a general case). However, that is how customizers work -- applying all modifications immediately without any other confirmative (does such a word exist ?) action :-\ I think this is worth investigating by UI/HIE people as the same pattern is used throughout the whole IDE.
BTW changing to an enhancement request - the UI is usable as it is... it "only" isn't user-friendly
I disagree with the sentiment that usability is an enhancement. Usability problems are bugs, especially serious ones. I'm changing it back to a defect. I would also disagree that the current implementation is usable. I went to the next pane in the Wizard several times because I instinctively hit Return to get the change to take affect. This is a serious frustration issue.
OK, I will raise this as generic issue on nbui@ mailing list. I would argue with the idea of Return/Enter confirming a field in a dialog -- such a global key is usually used to confirm the dialog as a whole, that is the whole field list. But that's really for ui discussion. That said, it won't be solved in 3.3. release.
I agree on all counts. - Lets take this to nbui for discussion. The solution is not obvious. - Return should confirm all of the changes not individual fields. Tab will navigate between fields and Return should be a "doit". - This should definitely not be fixed in 3.3.
Feel free to reassign to another UI/HIE developer as needed :)
BTW I suggest to change this issue to an enhancement after all, despite Evan's comments: The dialog UI *was designed* this way, cooperating with HIE. So it is a flaw in usability, right, but not defect; defects are deviations from the indented behaviour. Evan seemed to use rather vague definition what a defect is, IMHO.
An interesting philosophical discussion, Svata. Can a spec have bugs in it? Yes. If the implementation faithfully follows a buggy spec, then the product has bugs. I have a concern when changing an issue from a Defect to an Enhancement. There is often a large focus on bugs and Enhancments are ignored. Making an issue an Enhancement often has the affect of making the issue "disappear", that is, it won't get worked on. The NetBeans IDE has a number of usabilty problems. If we adopt an attitude that "if can be done, no matter how awkwardly, then its not a bug", then our usability will always be poor. I've added Chris LeDantec to the cc list. I suggest that Chris should decide if this is a Defect or Enhancement. I will live with Chris's decision.
sorry Svata, this is a bug. it's a bigger issue than just the wizard panel you are using since it needs to be fixed with a major redesign of the customizer dialog/functionality. aside from the wizard step, where does the user get to this feature? i'd just as soon get away from the very limiting customizer and implement this as a straigh panel so we can do things correctly. i realize that doing it as a customizer allows this to be re-used somewhere else, but it hasn't answered the question if it should and what user problem that solves.
FYI. I believe that problem 2) and 3) from initial description was fixed by issue #20350.
OK, whom should I reassign the bug ? Chris or Dirk ?. We have quite tight bug threshold, so I would like to have fixed at least bugs which may be fixed (some can't be for 3.4) and I don't like exceeding the bug count agreed on. To Chris' question -- go to a Class (method, field) node and invoke Customize fom popup menu. IMHO the presented dialog should NOT behave as a customizer as well, since the object's properties are simply too complex - types for multiple parameters, so updating after each change may yield incovenient UI for the users. If possible the dialog should have "OK" and "Cancel" buttons as well, so it won't be a customizer either. Please could you start a discussion on nbui@ ?
i will add this to the list of bugs that should work on but right now i'm swamped so i'll wait to start this up on nbui. i think it makes sense to look at the whole class wizard and not just one step. so when i get through what i'm working on now i'll take at look at that. cL
For what it's worth, I did the design work on this wizard. And I'm not happy with it either! The problem is that the design effort had to live under several constraints. First, there was pressure to present everything in the wizard, no matter how complex or obscure. Second, we had to be able to re-use the individual wizard panels as customizers. Third, some technical problems prevented us from having a field's entry in the "Fields" list update on a keystroke by keystroke basis. This would have clarified things somewhat. I mention all this because it points out what we need to do to improve things: 1. Decide what the wizard's real function is. Is the wizard something for an expert developer, containing everything she needs? Or is it a quick thing that gives the user most of what she needs (and that therefore expects her to finish editing the class in the Editor or with customizers)? Given how complex and cumbersome the wizard turned out, I vote for the former function. ;-) 2. Assuming we go for a simpler wizard, we need to be willing to create wizard panels that are separate from the equivalent customizers. That way, we are free to do what we need to do in each case. 3. We should decide on a general method for doing "Add/Edit/Delete" of items. Once you start considering both methods of doing "Add/Edit/Delete" (enter some information then click "Add" versus click "New" then enter the information) you usually find that both methods have pros and cons. The first way can be confusing: more than a few users will click "Add" before they've entered any information and will then wonder why nothing is happening. The second way, as we've noticed, can also be confusing: you can enter your information, but then be unsure of whether you have to do something to update your entered information. There's no good solution to this problem except to pick one standard for doing it in the IDE and to then stick to that standard. That way, users will gradually learn what to expect. I (or Chris) will be perfectly happy to redesign the UI with whichever standard is deemed preferable. If we need to get on this right away and Chris is swamped, I could start up the design effort. --Dirk
This wizard was *never* meant for an expert developer. The only panel worth for increased productivity is the "override methods" one, since it saves a lot of typing and helps to avoid mistakes. Now tell me - if a class can contain fields, methods and can derive from something, which pieces will you drop from the wizard to make it less "complex" ? Any functionality which you choose drop will be missed in some use cases - even beginner's ones - when creating a new class. Let's have no wizard at all: you say that it is too complex for beginners and experts won't use it.
The wizard was meant to be helpful for beginners and convenient for experts (or, at least, this was one of the constraints put on its development). I would be delighted to drop the expert user from this set of constraints, as it would result in a wizard that is more usable for beginners. However, before we do so we might want to investigate one further use case: the situation in which a developer (expert or novice) wants to use the wizard to create a class skeleton, and to then fill it out later in the Editor or by using the Add menu items in the Explorer (cf. Eclipse's class creation wizard). I don't want to do that analysis here; we should move that out to nbui to broaden the discussion. Yes, the current wizard is too complex for beginners. But, simplifying the wizard need not involve dropping functionality. A UI (wizard or otherwise) can be simplified by providing easy access to the simplest or most-used functionality, and less easy access to more complex functionality. Again, we need to discuss the specifics of this on nbui. In the meantime, I think it's a bit premature to get rid of the wizard.
i agree with Dirk: simplification is not a matter of the functionality present but of the functionality presentation. and yea, i'm swamped like swamp-thing. i'd be happy to look at this in a couple of weeks when stuff around options get's into a more settled place. and the target is 4.0 so i don't see a huge need for rush here...
*** Issue 20993 has been marked as a duplicate of this issue. ***
The similar problem is described in 20993, when we redesign this wizard we should count on other java-related wizards (interface, etc.).
Similar problem (relying on focus lost) is used in New | Other | Text wizard. Is this general problem of each wizard or do you want me to file separate bug against this one. The problem is that in last page of this wizard ("Choose Extension") there is checkbox "Add to Supported Extensions" which gets enabled only if you press Back&Next or if you know that you have to press Tab, because in this page there is no other component to which you could move the focus. Really tricky! :-)
this is really a problem. it *should* enable the checkbox as soon as the user stops typing (some reasonable delay). i know javacvs does something like this when entering a path that contains a cvs subdir. this is a similar type of bug but it's different enough -and more serious -that it should be it's own bug. the work around is very unintuitive and liable to cause the user to miss it. the new bug should also be related to 12641 which deals with the problem of entering the file extension with the file name (which is far more natural). cL
thanx Chris, filed as issue 21581
The issue is opened for *MORE OVER A YEAR* waiting for a new UI proposal and still no UI designer was willing or capable to work on the issue. To Dirk's comment from 2003-03-05: "there was pressure to present everything in the wizard, no matter how complex or obscure": Well. If the Wizard should guide the user through the class' creation *including* adding fields and methods, then I suggest to read a decent book on Java and check that methods and fields, their modifiers parameters etc are considered *very* basic constructs. Of course, they are not simple things like a single checkbox. The other option is of course to remove all panels but the first and create only the class - c.f. Eclipse and IntelliJ IDEA; I would like to see careful analysis why hand-written code is better (e.g. for beginners), or how to reshape the functionality so it is available at the time the user *knows* how the class should look like. "Second, we had to be able to re-use the individual wizard panels as customizers": This is not correct -- see e.g. Field customizer and the Wizard panel: completely different layout. "Third, some technical problems prevented us from having a field's entry in the "Fields" list update on a keystroke by keystroke basis.": Again this is not correct. The problem is that updating with each keystroke and *checking* for correctness cannot be done in principle: you don't know whether the user has finished typing at all, finished one word or just paused for a moment to catch up his thoughts. The entire concept of "live" updates after each keystroke sucks, however it seems charming to see things moving on the screen - simply because the gesture that confirms and ends the enter operation is missing. No one sane except perhaps NetBeans does that. Please be more specific than just "wizard is too complex" - and *prove* what functionality is overly complex. If the GUI is too complex or cumbersome for simple functionality, then it is your turn to redesign it. If you are not able to design it for whatever reason, or understand the functions and their relative importance, please say it in plain words. Otherwise it is terribly difficult to get any value from such vague feedback.
Svato, I'm sorry you feel frustrated by the lack of progress on this issue. I can assure you that there are a number of UI modifications requested by HIE that have been likewise neglected. In both cases, the neglect casts no aspersions on engineering or on HIE, but simply reflects the realities of workload vs. staffing level. The past year has seen a number of important issues addressed (projects, options, startup, performance); by comparison to those, this issue is relatively minor. All that said, if you feel that this issue is blocking your work or is causing a serious usability problem, then please state your reasons and increase the issue's priority. This will increase its likelihood of being addressed in the next round of NetBeans planning. Thank you, Dirk
Dirk, since I was advised that my comment can be read as being rather hostile to you or Chris, I owe you clarification - and an apology in case you were reading it as such. For better clarity, I would like to restate the sentence with "understaning functions" -- the intention was to ask that if you are not sure about or need to re-evaluate relative importance (weight) f individual Wizard's functions in order to move forward, don't hesitate to say that openly. I actually suspected several reasons for which the issue was not addressed, your comment posted in the meantime confirmed those suspicions, and it perfectly explains why the issue was not solved yet. Still I would like to know whether I can count on your advice for the next release or better try some experimenting on my own in order to progress. To answer your question -- I think the issue is relatively important(that's why it is still P3); the Wizard is used pretty often. If a radical change needs to be made, I do not suppose we will be able to do it in the dev trunk (at least one Forte module uses and plugs into the wizard) - better try something in the Projects branch.
Svato, Thank you for the clarification. I'm reasonably confident that the wizard changes can be designed and implemented in the 4.0 timeframe; I will propose that they be added to the 4.0 plans. (Besides, even if we haven't had time to rework the wizard before now, I still think it's a pretty good idea!) I will also talk to Jirka Mzourek about assigning an HIE to work on the design. Thanks, Dirk
Will not be fixed for NB 3.5
Tentatively, I'd like to do something for 4.0. But looking on the 4.0 plan :-\ I rather set the milestone to future. Feel free to work on the UI spec part of the issue, if it will be ready I will try to fill some unexpected holes with the programming part.
i'd like to see it addressed for 4.0 as well but i'm in the same boat as you -hie's plan is full too. i'll try to put some work into a ui spec but no promises.
FWIW, I actually started prototyping a better UI for this, because it annoys me too. The more I think about it, the more I feel that we need some "UI Design Patterns" and support classes. For example, there are many common patterns in NetBeans UI all implemented separately and differently. Na priklad: -Adding items to a list - Methods - Fields - Constructors - Array editors - Compiler & other service types -Moving some items from one list to another - Overriding inherited methods - Update center - Jar Content It would be much better design, IMHO, to have some panel classes that support this, and the developer simply writes a model which these classes will use. Some caveats have to be taken into account for things like the length of the strings (the Jar wizard's is particularly bad at this), but this can be managed through some small UI Descriptor. I'll try to put together a proposal/prototype of this in my copious free time :-)
Yes, that would be a great help. Actually this was the reason why PropertyPanel use is promoted so much. What puzzles me is that the design you name as "separate and different" was done by person whose specifik task is to maintain consistency.
As years go the issue has become irrelevant. The new Java Wizard UI spec has been already implemented for nb 3.6. The spec can be found at http://ui.netbeans.org/docs/hi/promoB/javaWizard.html
Reorganization of java component