Community
Participate
Working Groups
Created attachment 195524 [details] screenshots (zipped) Here are the screenshots for the upcoming R4E team UI review. It contains all possible dialogs, property views etc. that can appear while using R4E
Thanks for taking the time to post the screenshots! If possible it would be nice to do a quick demo of the work-flow as part of the next call. We can provide an Adobe Connect session for screen sharing. No worries if that's not possible. We'll just do it based on the screenshots then.
Thanks for taking us through the R4E today Sebastien! I have some high-level suggestion some of which we already discussed after the demo: * Consider replacing (modal) dialog based work-flows with editor based work-flows. It's generally more user friendly if a lot of input is required and use of the forms UI in dialogs is discouraged and not used in Eclipse. * The R4E Properties view should be merged with the general Properties view. * Settings for accounts (LDAP, Email...) should be managed in the Team Repositories view. * For dialogs with several input fields it's nice to use a wizard which provides feedback for input field validation and progress if needed. * Consider integrating more tightly with Mylyn views and editors such as Team Repositories, Task List, Task Editor Here are some minor nits that I noticed while following the demo: Review Navigator * A lot of icons in toolbar. Could some be removed that are used less frequently (e.g. sorting)? * It looks like the deeply nested hierarchy for review content could be potentially difficult to navigate * Consider rename "Focus" to "Go Into"? Focus is terminology used by the TFI whereas Eclipse uses "Go Into" for scoping the visible hierarchy in structural viewers. * Consider removing the global preferences for filters and rely on the view specific menu instead. * What is the meaning of Close in a nodes context menu? Is that similar to closing projects? * Should Add Review be renamed to New Review to follow standard Eclipse terminology? Anomaly Dialog * Add a search filter to the rule set section? Comment Dialog * Dialog is fairly small * Is spell check and rich editing (WikiText) supported? Enter Participant Details * Is content assist supported for Id? Review Group Details * Add/Remove buttons should be top aligned
Thanks for your comments Steffen. See my answers below. (In reply to comment #2) > Thanks for taking us through the R4E today Sebastien! > > I have some high-level suggestion some of which we already discussed after the > demo: > > * Consider replacing (modal) dialog based work-flows with editor based > work-flows. It's generally more user friendly if a lot of input is required and While I agree about this, there are some cases where we do not want editor-based work-flows. For instance the anomaly dialog should not be in an editor, since it involves entering data where one would want to see the file on which the data is entered in the editor window while entering it. For some other taks (e.g. new review group, participant, review...) it does make sense. For these this is already on out task list to do it > use of the forms UI in dialogs is discouraged and not used in Eclipse. > * The R4E Properties view should be merged with the general Properties view. I'm not sure I understand where you want to put the view actually? > * Settings for accounts (LDAP, Email...) should be managed in the Team > Repositories view. I agree, this will be put on our task list > * For dialogs with several input fields it's nice to use a wizard which > provides feedback for input field validation and progress if needed. I agree on principle, but which dialogs are you referring to in particular? > * Consider integrating more tightly with Mylyn views and editors such as Team > Repositories, Task List, Task Editor > Yes I know that not a lot have been done in that area (due to other commitments) but this is definitively on our task list. I am thinking that then end result will look similar, for some parts, to the Gerritt Connector UI you implemented > Here are some minor nits that I noticed while following the demo: > > Review Navigator > * A lot of icons in toolbar. Could some be removed that are used less > frequently (e.g. sorting)? I agree, will look into this > * It looks like the deeply nested hierarchy for review content could be > potentially difficult to navigate Yes this is a concern. This is why we added some filters e.g. to filter out selections and deltas > * Consider rename "Focus" to "Go Into"? Focus is terminology used by the TFI > whereas Eclipse uses "Go Into" for scoping the visible hierarchy in structural > viewers. Ok I will do that' > * Consider removing the global preferences for filters and rely on the view > specific menu instead. THe reason to have default filters is to tailor the contents displayed by the review navigator to what the user wants. To reduce "information overfolw" I don't know of a better way to do it. > * What is the meaning of Close in a nodes context menu? Is that similar to > closing projects? Yes this is similar. Specifically, the "closed" reviews/review group information is not loaded in the UI model, which reduces memory consumption and speeds up response time > * Should Add Review be renamed to New Review to follow standard Eclipse > terminology? Yes it makes sense. I will add this to our task list > > Anomaly Dialog > * Add a search filter to the rule set section? Yes this is a good idea. Put into our task list > > Comment Dialog > * Dialog is fairly small Yes I have an item on our list to have a minimum size for all dialogs > * Is spell check and rich editing (WikiText) supported? Not for the moment, but it sure could be a nice improvement for all "description" text boxes > > Enter Participant Details > * Is content assist supported for Id? Not at the moment, could be done later as an improvment > > Review Group Details > * Add/Remove buttons should be top aligned ok I will change this
(In reply to comment #3) One more thing regarding the following comment: > > * The R4E Properties view should be merged with the general Properties view. > > I'm not sure I understand where you want to put the view actually? > We had a discussion about this at some point in the past, on bug 336004. Basically if there is a way to restrict the input of the properties view to the R4E UI Model then it is fine, otherwise we'll have to use our own properties view, for the reasons mentionned in bug 336004
(In reply to comment #3) > While I agree about this, there are some cases where we do not want editor-based > work-flows. For instance the anomaly dialog should not be in an editor, since > it involves entering data where one would want to see the file on which the data > is entered in the editor window while entering it. For some other taks (e.g. > new review group, participant, review...) it does make sense. For these this is > already on out task list to do it Good point. In that case it's just a matter of making controls in dialogs use the standard platform look and feel. I would still recommend to either collapse details by default and only show frequently used controls or move more detailed editing options into an editor. This would be similar to how Google Calendar allows creating events by typing a summary into a dialog with an option to proceed with the defaults or open the event details to make additional changes. > > use of the forms UI in dialogs is discouraged and not used in Eclipse. > > * The R4E Properties view should be merged with the general Properties view. > > I'm not sure I understand where you want to put the view actually? Yes, that is essentially the same suggestion I made on bug 336004. I would recommend reopening the bug and revisiting this. If the API (or internals) in the Properties view are indeed not sufficient I would recommend filing a request against platform to provide the required extensibility. > > * For dialogs with several input fields it's nice to use a wizard which > > provides feedback for input field validation and progress if needed. > > I agree on principle, but which dialogs are you referring to in particular? I would use the wizard style for all dialogs that have more than one input field, e.g. for creating anamolies. > > * Consider removing the global preferences for filters and rely on the view > > specific menu instead. > > THe reason to have default filters is to tailor the contents displayed by the > review navigator to what the user wants. To reduce "information overfolw" I > don't know of a better way to do it. The filters are fine. I am just suggesting not making them available in the global Eclipse preferences as that is inconsistent with the Eclipse platform.
The following comments were addressed and the code changed in the current R4E version: > Review Navigator > * A lot of icons in toolbar. Could some be removed that are used less > frequently (e.g. sorting)? > * Consider rename "Focus" to "Go Into"? Focus is terminology used by the TFI > whereas Eclipse uses "Go Into" for scoping the visible hierarchy in structural > viewers. > * Should Add Review be renamed to New Review to follow standard Eclipse > terminology? > * Consider rename "Focus" to "Go Into"? Focus is terminology used by the TFI > whereas Eclipse uses "Go Into" for scoping the visible hierarchy in structural > viewers. > Comment Dialog > * Dialog is fairly small > Yes I have an item on our list to have a minimum size for all dialogs > Review Group Details > * Add/Remove buttons should be top aligned For the other ones, this is still in progress, so I will update the bug to 0.8.1 target milestone
This bug will now be closed. A new one 372434 is open to keep track of all comments received in UI reviews and other reviews
