(FR) Show the last findings with all details, not just their number

[Daniel Kulesz]

Currently, the findings displayed in the scribe view are only represented with the findings' numbers. Only when using a large screen resolution, more than one finding can be seen with its details, as we have two or more edit views then. I suggesting using only one editing view, but offering a list of findings similar to PearReview: http://pearreview.com/images/screen5.jpg

[Holger Röder (roederhr)]

I think this is important. One of the main reasons for using laptop+beamer combos in review sessions is to have the review protocol visible all the time and for all participants. I propose we start prototyping and target an updated protocol view for v1.3. What's your opinion?

[Johannes Wettinger (jojow)]

Let's start! :-)

[Daniel Kulesz (kuleszdl)]

I agree. This feature-request should be one of the most important ones, and definitely a candidate for 1.3.

[Johannes Wettinger (jojow)]

Please find attached the first user interface prototype for the "Findings" tab of the protocol window. I'm waiting for your feedback. ;-)

[Daniel Kulesz (kuleszdl)]

Good work, Johannes. It' s nice to see some progress here! Actually the GUI layout should be okay for "normal" usage, but please remember the beamer mode (https://blueprints.launchpad.net/revager/+spec/spec-separate-beamermode). Using such large fonts is excellent for reading data (by the reviewers) but not very handy for entering data (by the scribe).

One more thought: How can you see the details of the previous findings? There is no button on them to make this visible. The arrow-up and arrow-down buttons are for sorting them, right?

[Johannes Wettinger (jojow)]

Regarding your second thought: I think a simple click on the finding's panel will "open" it for editing. The arrow-up and arrow-down buttons are for sorting, correct.

You're right regarding the usability issue of these large fonts. But then we need to specify and implement another feature for 1.3. I propose to leave the large font size until we've a separate beamer mode implemented (maybe in 1.4). After that, we can "normalize" the font size inside the protocol window. What do you think?

[Daniel Kulesz (kuleszdl)]

I agree. Delaying the changed font size for 1.4 should be a good trade-off.

[Davide Casciato (casciade)]

nice work, Jojo...what do you think about this prototype?

[Davide Casciato (casciade)]

the component on the right side shall represent an accordion...i don't think Swing is offering this component type :-(

[Daniel Kulesz (kuleszdl)]

Personally I think the data entry elements are too hidden. It's a bit annoying to open up i.e. References in order to enter one there. Also the description field seems a bit too narrow for its purpose. Maybe we can hide "files" and "aspects" from the table view also?

[Johannes Wettinger (jojow)]

Thanks Davide for your prototype. IMHO the user interface is too intricate and it decreases the usability because you cannot see and edit the current finding as a whole. But that's only my personal view! We should go on with our discussion here and find the best solution. :-) Therefore I've created 3 more prototypes (2a, 2b, 2c) in order to have more findings visible at once like in Davide's prototype. Personally I prefer 2c (tooltip solution) because for 2b I think there is too much information inserted into the "compact view" of the findings.

@Davide: Don't worry about some implementation details like the "accordion". We'll find a way to implement this if required; the PearReview developers are using this concept, too. ;-)

[Johannes Wettinger (jojow)]

Please find attached the prototype 3, based on 2c. ;-) I tried to improve the clarity by introducing a context menu (which will be enabled after clicking on the finding's icon). Normally the user won't need the "move up" and "move down" functionality that often, so it would be better to move this functionalities into the context menu. There we can also add some more functionalities.

But now I want to give you the chance to write some feedback! :-)

[Davide Casciato (casciade)]

I prefer Prototype_FindingsTabOfProtWin_3 but i would remove the sort options and enable drag-and-drop...also the cursor should became a hand-cursor while hovering the finding-objects. It would be an option to edit the finding by double-clicking the concerning object.

[Davide Casciato (casciade)]

...maybe the sort to top/bottom options in the context menu are meaningful after all.

[Johannes Wettinger (jojow)]

Ok, 'drag&drop' is a good idea! I suggest to leave the context menu and to add the 'drag&drop' functionality optionally for 1.3 (keyword 'nice to have'). ;-) So, the user has the choice how to do it.
Of course you will get a 'hand cursor' while hovering the findings. I just didn't have a proper cursor icon while creating the prototype. ;-)
A single click should open the focused finding for editing as described above.

[Daniel Kulesz (kuleszdl)]

My current favourite is prototype3.now. But I don't support the idea of hiding the sort buttons, they should be visible without the hidden context menu. Of course it would be nice to have this context menu and the drag&drop feature, but I don't like it as a substitute.

The basic question is just: Where should we put them. Placing them *inside* the finding boxes seems not logical to me. They should be rather placed outside, beside the findings. Are there other suggestions regarding the sorting? I tried to put up a new protoype for this. I also wanted to "gray out" the delete/edit buttons, but somehow it's not as easy to accomplish as it should be in OOo draw. Therefore it's not covered by the prototype

Regarding the "accordion": Since PearReview is open source, why not re-use their implementation?

[Johannes Wettinger (jojow)]

Yet another prototype! ;-) I think so many "up" and "down" buttons like you have it in p3b (and the earlier prototypes) are decreasing the overall clarity of the screen. I suggest an alternative with prototype 4.

PS: I've created p4 with OOo Draw again. ;-)

[Davide Casciato (casciade)]

another idea: we could also make the finding objects selectable (without checkbox, only a colored border) and sort them over central sort buttons. (SEE: Attachment)

[Davide Casciato (casciade)]

Sorry, I accidentally swap the images. This is the correct one for the comment above. Some details to 3b : multiselection is enabled for removing, the other buttons are only enabled while selection only one finding object. To select one finding click on it once. To edit a finding, use the concerning button or double-click the it.

[Davide Casciato (casciade)]

...i'm really confused today ;) Please do not pay attention to my spelling. Also i meant 4b instead of 3b.

[Johannes Wettinger (jojow)]

This is a really good idea, I like it! :-) I suggest to move the buttons to the bottom, like we have it inside the aspects manager. For this approach I would remove the "hover effect" for the compact view of the findings again because we don't have to integrate the buttons into the panels. So, we can just show the additional information inside the tooltip. I think this should be more user-friendly.

Just have a look at prototype 5.

[Davide Casciato (casciade)]

Unless there are no more suggestions from your side, we start from next week on with the blueprint for this feature.

[Daniel Kulesz (kuleszdl)]

Regarding prototype 5: I am still not very convinced. This are my concerns:

- I hate the concept of a "double click", except for editing a "non moving" target. In our case the finding would expand its details and therefore change size/position.
- I think the shown situation with the editing window open in mid of the findings is rather an exception, than the normal case.
- I don't like this bar at the bottom, it is too far away from the manipulated object.
- Same goes for the editing buttons.
- the central "add new finding" button is proportionally underrepresented and hidden in the button bar.

I made a new prototype 5-2b. I still don't like it too much, but wanted to share some ideas with it.

Come on guys, there must be a good working solution for a stupid "list, sort and add items" dialog?

[Johannes Wettinger (jojow)]

Thanks, Daniel, for the new prototype. Of course we can still improve the usability. ;-) I've just created prototype 5-3, based on 5-2b. Feel free to give some feedback, so we can start creating the blueprint soon.

[Johannes Wettinger (jojow)]

Please find an improved version of prototype 5-3 attached to this comment.

[Daniel Kulesz (kuleszdl)]

Without question, prototype 5-4 is now my favorite. Any comments or further suggestions for improvements?

[Johannes Wettinger (jojow)]

From my side, I can start creating the blueprint now, so I'll be the drafter for this feature request. Who wants to be the approver for this FR?

[Johannes Wettinger (jojow)]

I finished the blueprint creation finally. Davide, can you check the blueprint please and give some feedback here? Thanks a lot! :-)

[Davide Casciato (casciade)]

As expected, I was able to identify that no changes are necessary in your blueprint. Sorry, for reviewing that late...kind regards

[Johannes Wettinger (jojow)]

Thanks a lot for the approval, Davide! I'm going to start with the implementation after creating a new branch for this blueprint.