Behavior of checkboxes

[munen]

The original reporter is @neildavidforrest (#945 (comment)). He noticed that there's a regression from the new 'list manipulating functions pr' (#945 from @kjmatsuda).

He argues that the UX of checkboxes have been altered:

Problems:

1. The appearance of an unchecked item has changed. Instead of an empty box it is a partly filled box.
2. Tapping the text of an item no longer checks/unchecks the item, but instead opens the edit menu. This leaves only the very tiny target of the box itself which is quite hard to hit.
3. If I do manage to check or uncheck the item it still opens the menu which alters the position of the subsequent or previous items on the screen making it hard to quickly run through the items to check or uncheck them.

Solutions?
For 1 I assume the solution is trivial. For 2/3 I'm not so sure. One option could be a way to enable/disable edit mode for a list. Or require a long press rather than a tap to reveal the context menu.

First, let me say thank you for the thorough report! I agree about your statement of "But what is good software development but a series of trivia that add up to something great?" - thank you for taking the time to offer suggestions about UX. They are always very welcome 🙏

Thank you also for your kind words in regards to my current situation 🙏

Ok, back to the issue. I confirm the issue you have addressed. Let's see if and how we can address them. Since the points apart from 1 are not a trivial bug, but a change in UX, I have created a new discussion. In here, we can add ideas, pros/cons and potentially come up with a solution. Then, let's create a PR(;

For 1, I have a PR ready: #949
@neildavidforrest Can you test if this changes the color back to what you would expect, please?

Issues 2 and 3 are a bit more complex. For 2, I don't think I even knew that I could tap the text to be honest. So, I was probably always just hitting the checkboxes directly. But I can totally see (now) that the way you describe it is how standard checkboxes behave and that it's a regression(;

3. I've seen this argument before. Some people do not like the way organice shows functionality when the user clicks a header. I can absolutely agree that the headers (or in this case list items) shift position. It's a bit of a weird UX, and some people argue it's not optimal. It's definitively not a common UX pattern, so we did have several discussions with several people about how to improve UX. One of the maintainers (@tarnung) even did an experimental overhaul of the whole UI to get rid of inline editing. He consequently adopted the action buttons of material design. Here's the PR including screenshots: Experimental ui overhaul without inline editing #559

In the screenshots, you can see how great this option is on the one hand (the headers are way cleaner). However, you can also see how it falls short:

• Every needs multiple action button clicks/taps
• The screen quickly fills up with action buttons for actions against a header

Hence, it was agreed that while this was an amazing spike, it's good to see that going the 'standard' material design way is not necessarily better. It cleans up one thing, but clutters another. I feel that the issue with list items is the same. There's different tasks you do on a list item. At least:

a. Create them
b. Move them around
c. If they are a checkbox, check or uncheck them

I'd argue that a and b have been improved by close to an order of magnitude in speed by @kjmatsuda's PR. c definitively has a regression, because all list items move when one is clicked/tapped. However, they always move the same distance, so with a bit of learning, this movement could probably be learned and expected by the user.

You had a good suggestion regarding putting the list item functionality behind a 'long press'. It sounded good when I read your comment. However, while reasoning this out, I would say that it would:

I. Mitigate some of the speed gained in a and b.
II. Hide this functionality from a common user

For me, this trade-off would be worse as a default. However, it could totally be a setting! For a regular user, the new list functionality is easily accessible and might even be optimal. For a pro user with a lot of checkmarks, it would be beneficial to toggle the setting.

@neildavidforrest What do you think?
@kjmatsuda Please free to chime in if you have any thoughts!

[neildavidforrest]

@munen thanks for starting this thread.

For 1, I have a PR ready: #949
@neildavidforrest Can you test if this changes the color back to what you would expect, please?

I tried it out. The fix works great.

I agree with all the points you make about 2 and 3.

How about a compromise?: Clicking on the checkbox itself should only check or uncheck the box, nothing else (currently it modifies the state of the checkbox as well as opening the menu). Instead, the menu would only be accessible when tapping on the text. This would allow one to check/uncheck items in a list without being bothered by the menu appearing, while at the same time keeping the menu available and discoverable for editing the list items. You would still need precise aim to hit the boxes, but I can imagine getting used to it.

A global settings toggle to disable it would be a last resort in my opinion.

[munen]

I have created a PR which changes the UX as proposed: #951

@neildavidforrest and @kjmatsuda: Can you please test this PR and see if it is to both of your liking?

[kjmatsuda]

Thank you @munen ! Yes, I agree with proposal of @neildavidforrest .
Hopefully,I will test this PR in 2 or 3 days!

[neildavidforrest]

Thanks both. I've tested and approve!

One last thought I had: If one does still accidentally bring up the menu with a stray tap, is there a way to hide it again? I know that for the header menus you can click the document title and that will hide the menu again. Maybe this could be extended to also hide the list editor menu too?

I'd be happy to try and make that change myself as you've already put in time and effort on this.

[kjmatsuda]

Hi, @neildavidforrest, Thank you for your suggestion!
Sorry for the late reply.
Below is my opinion to your suggestion.

First, let me break down the different parts as shown below.

You mentioned,

I know that for the header menus you can click the document title and that will hide the menu again.

By "document title," are you referring to the header title? If so, clicking on the header title toggles the visibility of the header contents, but it does not toggle the header menu.
I think consistency is important, so I think clicking on the list title toggles visibility of list contents is straightforward as extention of header behavior.

[neildavidforrest]

Hi @kjmatsuda, actually the "document title" I'm referring to is in the header bar. Let me share a video to show you what I mean. Here I created a file named test.org, and so the document title is "test". Clicking on it will hide the open header menu. My suggestion was to also hide the list header menus too.

screen-20230418-091838.2.mp4

[munen]

The feature @neildavidforrest is referring to is one of the hidden “pro user” features of organice(; I’ve built it once upon a time, because some users like to drill down to a header and then read the content without wanting the edit any content. They gave the feedback that the header menu is in the way of such a read-only workflow. Hence, I’ve added the hidden “tap the title bar” feature.

In my opinion, this would work just as well for the new list items menu. @neildavidforrest If you want to give it a shot, I’d be happy to pull your changes in!

[neildavidforrest]

Ah, OK. I didn't realize / forgot that document title wasn't visible by default. At some point I enabled this in the settings. Sorry for the confusion.

I'll have a go at the implementation when I get some time.