Review Request 127891: Parley: Quickly edit vocabularies during practice

Sun Sep 11 11:01:11 UTC 2016

> On May 11, 2016, 7:09 a.m., Thomas Pfeiffer wrote:
> > Sounds like a feature, but features should never be accessible only using the context menu.
> > How about using inline editing?
> > This is how it would work here: When hovering over the card's text, the cursor changes to the text cursor, and when clicking it, it transforms to an edit box?
> > The funciton would not be immediately obvious, but if users notice that there is something wrong with a card's text, moving their cursor to it is likely an inutitive reaction, and then the feature would become obvious.
> 
> Julian Helfferich wrote:
>     Yes, this is a new feature and your idea to change the mouse cursor is very nice. However, I would like to avoid entering edit mode when a user selects text from the label, e.g. to copy and paste it into google image search. A solution would be to enter edit mode not on the mouse-click, but only when a key is pressed (trying to edit the text).
>     
>     The alternative would be an edit button (see third attached image). This is similar to the suggested solution in bug 170534 where an additional button was suggested, marking the vocabulary as invalid. Here, it enters the line edit mode instead. However, I am not sure if the feature is important enough or will be used enough to justify a new button on the interface.
>     
>     I have realized that this new feature comes with quite a large diff making it hard to review. Would it help the review process to a) submit several, shorter patches or b) add a feature branch to the git repository?
> 
> Hartmut Riesenbeck wrote:
>     Here is another idea to inform the user about this nice feature:
>     
>     When moving the mouse curser over the card text a tool tip shows up with a message like "Press F2 to edit!". When the user hits F2 the card changes into edit mode like you showed in your second screen shot.
>     
>     An additiontional context menu entry would also be helpfull. And I think the user would find it if he recognises that the text label is somehow interactive.
> 
> Julian Helfferich wrote:
>     Thank you very much for this great idea!
>     
>     Unfortunately, it will take me a while to update this patch, as I am currently busy with other things. However, combining the two ideas above, I suggest the following design:
>     
>     Case 1: Regular text
>     ====================
>     
>     The EditableLabel displays a QLineEdit that is designed to look like a QLabel (using Qt Style Sheets). Similar to a QLabel, the user can select and copy text. Once the user starts editing, the design of the QLineEdit is changed back to the regular QLineEdit style and the accept and cancel buttons are shown. On accept/cancel, the QLineEdit is changed back to resemble a QLabel and the buttons are hidden. The tool tip for the QLineEdit reads "Edit vocabulary entry".
>     
>     Pros: I think the usage is very intuitive. The mouse cursor turns to an I-beam indicating that the entry can be edited. On the other hand, the interface does not change for anybody not using this feature.
>     
>     Cons: Using Qt Stylesheets to replicate the default QLineEdit look and feel needs to be kept up to date manually if the global design is changed.
>     
>     Case 2: Latex text
>     ==================
>     
>     The EditableLabel displays a QLabel containing the Latex Pixmap. The mouse cursor turns to an I-beam and the tool tip reads "Click to edit". On clicking the Label, the QLineEdit is displayed. On accept/cancel the QLabel containing the (updated) Latex Pixmap is displayed again.

I have suggested a different approach trying to address the same issue :)

https://git.reviewboard.kde.org/r/128752/

Nevertheless, I am not sure that they are mutually exclusive.

What I like in your approach is that entries are modified ‘on the fly’ and user does not have to return to the editor, find the entry, edit it, toggle it, etc.

At the same time, this is the thing I don’t like. A user may want to just mark it as ‘problematic’, go on, finish studying and, in terms of a distinct workflow, go to the editor and fix the issues.

- Dimitris

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127891/#review95378
-----------------------------------------------------------

On May 11, 2016, 4:14 a.m., Julian Helfferich wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127891/
> -----------------------------------------------------------
> 
> (Updated May 11, 2016, 4:14 a.m.)
> 
> 
> Review request for KDE Edu and KDE Usability.
> 
> 
> Bugs: 170534
>     http://bugs.kde.org/show_bug.cgi?id=170534
> 
> 
> Repository: parley
> 
> 
> Description
> -------
> 
> I have implemented a wish request (bug 170534) I would very much see in Parley: Add an option to edit the vocabulary during practice. To keep the review request small, I have implemented the quick edit option only for Flashcard practice. However, the approach is easy to extend.
> 
> I took the following approach:
> 
> * The QLabel displaying the question/solution is replaced by a custom widget.
> * The widget is designed to behave similar to a QLabel, but it adds an additional action to the right-click context menu: "Edit vocabulary entry" (see screenshot 1).
> * When this option is selected, the QLabel is swapped with a QLineEdit and two ToolButtons for "Accept" and "Cancel" (see screenshot 2).
> * Clicking the "Cancel" button brings back the Label displaying the question/solution.
> * Clicking the "Accept" button or pressing enter brings back the question/solution label and emits the entryEdited() signal.
> * This signal is passed on to Practice State Machine as questionEdited() or solutionEdited() which modifies the vocabulary entry.
> 
> The approach does not make the quick edit option very obvious. Instead, I have opted for not changing the look and feel of the application. Another option would be to add an "edit" ToolButton (see screenshot 3).
> 
> 
> Diffs
> -----
> 
>   src/CMakeLists.txt fd352de 
>   src/practice/abstractfrontend.h f5f9552 
>   src/practice/editable_label.ui PRE-CREATION 
>   src/practice/editablelabel.h PRE-CREATION 
>   src/practice/editablelabel.cpp PRE-CREATION 
>   src/practice/flashcardmodewidget.cpp ced6ca6 
>   src/practice/practice_widget_flashcard.ui e1aa099 
>   src/practice/practicestatemachine.h b67ba32 
>   src/practice/practicestatemachine.cpp 8756592 
>   src/practice/rightclickeditlabel.h PRE-CREATION 
>   src/practice/rightclickeditlabel.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127891/diff/
> 
> 
> Testing
> -------
> 
> Flashcard practice.
> 
> Started editing -> Canceled edit
> Started editing -> Accepted edit -> Confirmed that vocabulary was modified
> Started editing -> Pressed continue/Answer later/Hint
> 
> 
> File Attachments
> ----------------
> 
> Additional context menu entry
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/05/11/f2db895e-c290-4548-9547-fd978c368893__context_menu.png
> Edit vocabulary entry
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/05/11/6b602f41-fb17-43ec-a98e-7155f6721489__edit_entry.png
> Edit tool button
>   https://git.reviewboard.kde.org/media/uploaded/files/2016/05/11/8098a66e-eb34-430a-951a-1da21529b4ba__toolbutton.png
> 
> 
> Thanks,
> 
> Julian Helfferich
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20160911/50c94670/attachment.html>