Reworking the ActionPropertyEditor dialog to incorporate feedback from xDesign.

Proposed changes:

  • redo the layout to look like the mockup below
  • put the selected, enabled, and blocking properties on the second tab
  • all the second tab 'advanced' (call the first tab, basic?)
  • make the 'new action' button pop up a small dialog that asks for the method name, scope, and return value
  • when returning from the 'new action' popup, switch to the new action and disable the scope/action combos
  • make the method name and return type be labels showing the signature rather than disabled components. (possibly move up to be under the action list?)
  • put the jump to code button on the same line as the method

misc notes

Ann: For the demo - I think eliminating the indentation under "Available Actions" is ok, and notice the indentation of the blocking-related textfields under the Blocking Type combo (as well as the disabled labels to emphasize the non-applicability). As for post-demo, I still find the save/new/persist model of the editor being unclear, which hopefully some more redesign could help out.

Coleen: I'm coming in late to this conversation without having carefully read the thread (I'm running around between Solaris and Java SE work like mad) so not sure if I have the big picture, but on a whim and purely from an aesthetic & information-organization POV I modified the screen (see attached). I think there is too much info in the current screen and more info segregation/grouping needs to happen to make the visual flow of the dialog more intuitive depending on task-context. (see screenshot)

Josh: I'm imagining that new action will pop up a dialog asking for the method name and it's return type. These values are immutable after you create the action, so it makes sense to separate them. After you hit okay the new action is created and selected in the dialog. Then you can edit the properties as normal. Question: after you hit okay to create the action should it really be created at that point, or will hitting the cancel button on the main dialog cancel creating the action?

Coleen: It seems like that's the only difference between the properties in the two tabs: one set is general, another is advanced. I wonder what other people do in such a situation? If we can follow a standard, that'd be great. I can try to do some research on this before the week is out. (on the new action stuff:) When something like this is done (e.g., when you create a new location in Apple's Network prefs), usually you're creating something more meta. I think what the "New Action" button should probably do is have a sheet pop up (if Apple hasn't patented it) or a small dialog asking for an action name. Then the user is returned to the action editor dialog and he edits the properties there. Properties shouldn't be edited in two places/two levels of the dialogs; it dilutes the information grouping and task flow logic.

Josh: Then you are returned to the previous dialog (Action Property Editor) to edit the rest of the properties. It would feel the same as if the new action had already existed and you simple selected it. I'll do this with a small dialog, but in Java 6 on Mac we can include a special property on the dialog to make it be rendered as a sheet, which will be pretty sweet!  :)

Josh: It might be good to put the 'jump to code' button next to the readonly method name since they are both code oriented. Essentially saying: "here's the method the action works with. go to this method by clicking this button'.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo