Libelektra: QT GUI usability problems

[omnidan]

the usability test for Elektra Web also uncovered some problems with the QT GUI:

• [ ] when keys have subkeys, but none of those subkeys have further subkeys, they are shown with a black arrow instead of the usual green one:

• [ ] in general it is not clear where information appears (e.g. some users didn't see the search results, others clicked on a key and didn't see that something popped up on the right)
• [ ] key values are only shown when hovering over the key or double clicking to get to the edit dialog
• [ ] copy & pasting array keys does not work (creates a key with the same id)
• [ ] it is not possible to edit names of array keys (which makes it impossible to fix the copy & paste issue)
• [x] it is not clear that the box when editing a key contains metakeys (only the button at the bottom "new meta key" hints at it), some users thought it contains subkeys, maybe add a title to this section

[markus2330]

Thank you for reporting the problems! I think some clarifications are needed (what was expected, what the users tried to do,...)

Maybe you can also separate usability problems and the actual bug (copy&pasting array keys).

@0003088 please write if it is not clear to you what the individual problems were.

[0003088]

Thank you for your input. Do I guess correctly that you tested your GUI with an audience and included the qt-gui as well?

The first mentioned issue is no bug but a feature. It should inidicate that there exist further subkeys, without the indicator one would have to click every key in the treeview to see if there are subkeys. Or is the problem that the subkey indicator does not look similar to the expansion icon? Since the icons do have different functions I thought they should be visually different as well.

As far as I remember I experimented with colors to indicate that a search result was successful (green) or unsuccessful (red). It might be useful to implement something like that.

That the key values are only shown by hovering or clicking is true, but I did not have any better idea to solve the problem considering the general design of the viewports.

The copying and pasting issue of the arrays seems to be a bug as is the next array related icon, I will see what can be done.

Thank you for your last suggestion, this should be an easy fix.

[markus2330]

Do I guess correctly that you tested your GUI with an audience and included the qt-gui as well?

Yes, it was an A/B test with Web-UI and qt-gui. You can read about the details in Daniel's bachelor thesis (to be finished soon, preliminary version is in our private repo).

Or is the problem that the subkey indicator does not look similar to the expansion icon?

Yes, I also think it is a good idea to have different icons there. Maybe the usability is better if the "Key Name/Key Value" view is also used if non-leaves are selected (up to all keys of a namespace). For irregular-shaped "trees" (especially if exactly one key has subkeys but no other) the right view is nearly always empty and the hints (hover text) need to be used very often.

That the key values are only shown by hovering or clicking is true, but I did not have any better idea to solve the problem considering the general design of the viewports.

Maybe reducing the time when the hover text is shown might already help.

The copying and pasting issue of the arrays seems to be a bug as is the next array related icon, I will see what can be done.

Thank you!

We decided that arrays should have the metadata "array" containing the last index (see #182). This should make detection of arrays easier. It would be nice to see support for it in the qt-gui.

[markus2330]

@0003088 Maybe we can here also have some improvements (next to #2405)

[0003088]

Maybe reducing the time when the hover text is shown might already help.

The interval is set for 1 second atm, so set it to 0.5s? Or maybe even add an option for the user to select the time for herself?

Maybe the usability is better if the "Key Name/Key Value" view is also used if non-leaves are selected (up to all keys of a namespace). For irregular-shaped "trees" (especially if exactly one key has subkeys but no other) the right view is nearly always empty and the hints (hover text) need to be used very often.

Maybe add a checkbox in the settings as well? Called "always show key name/key value" or something like that?

[markus2330]

The interval is set for 1 second atm, so set it to 0.5s?

Yes, sounds good.

Or maybe even add an option for the user to select the time for herself?

I think we should choose it, as we have the responsibility to provide usable programs.

Maybe add a checkbox in the settings as well? Called "always show key name/key value" or something like that?

If there is no strong reason against it, I would also simply always show (without any setting).

[markus2330]

@0003088 Thank you for working on this!

[0003088]

@markus2330 You are welcome, but I cannot promise any timeframe when this will be done. Sorry for the unintended closing of this issue. I should avoid the term 'fix' I suppose ^^

[markus2330]

No, it is only that you directly pushed into master and because of that the "fixes ..." in comments immediately triggers to close the issues. If you create a PR, this will not happen (only after the PR was merged).

Please do not forget to write release notes. (doc/news/_preparation_next_release.md)

[0003088]

Ugh, you're right, I didn't work out of my fork! Do you want to undo the commits?

[markus2330]

If they are okay, you can leave them. Please only add a note about them in the release notes.

[0003088]

It seems to be fine on my machine. I'm not worried about the timer, but I fixed some layout errors and I do not know how older versions of Qt will react to these, since I've never seen the errors before, so something in Qt seems to have changed (there's no issue for this I just fixed them)

[markus2330]

@darddan ping

[markus2330]

@0003088 I unassigned you, as @darddan will now work on it. We will integrate the qt-gui more nicely into KDE.

[0003088]

Sounds nice, looking forward to see improvements.

[stale[bot]]

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions :sparkling_heart:

[markus2330]

@darddan did you have a look at these issues? Could you reproduce them?

[darddan]

The issues were all there when I last checked. Unfortunately because of my health condition my time in front of the computer is very limited and didn't have any time to work on these issues. My current long-time-open-task is the migration to a newer version of QML and using the "official" TreeView (but I can't tell how close I am at finishing that either) and that one doesn't affect the problems stated in this task.

[markus2330]

Beautiful to read from you again, I wish you to recover soon! :heart:

Good plan, would be amazing to use the official TreeView.

[0003088]

I'm excited to see somebody is planning to use the official tree-view. I myself tried to migrate the qt-gui to the new view a few years ago, when the qml view was released, but failed unfortunately (if anybody is interested, the code is in https://github.com/0003088/libelektra-qt-gui-test/tree/master/src/tools/qt-gui). AFAIR the problem was the proxy model. As long as the nodes where preserved in the structure, e.g. just renamed, it would work fine, but as soon as I started to add and remove nodes I would run into problems I could not solve. I'm courious to see how it can be done.