Try editing a task on ios mobile. Touch the task and wait for the cursor to appear. Now try to move the cursor. 95% of the time the task starts sliding making editing almost impossible. It is enough to get me to go back to Workflowy. I can’t believe what a poor UX decision this was. Was it zeal to match other apps? Was it obsession with something cool? Compromising basic functionality is no way to add features. It’s terrible. The so called solution is to add a confirmation? I suppose this reduces accidental deletion or completion, but that only tells you there is something wrong with sliding to begin with. It looks like there is no intent to fix this unfortunately. Get rid of it, or make it an option in Settings. I’ll immediately turn it off, or just go use Workflowy.
Hey I understand your frustration but please hold off the hostility!
That’s one way we could fix the issue. An alternative I’d propose is to disable swipe actions when there’s a cursor focus. I think this is a good solution because when a user intend to swipe and complete/delete, they will need to click on the confirmation, which de-focuses and hides the keyboard. So given a de-focus happens regardless, I think it’d be a better experience if swiping only works when there is no focus and the keyboard is hidden.
Of course an option in the settings page can still be useful. We’re open to discussion on that one.
Understandably it doesn’t feel useful at all to you, but this was suggested many times by other users as a way to complete or delete items without having to wait for the keyboard to pop up, press the complete/delete button on the toolbar, and tap away to hide the keyboard.
The implementation could use some improvements for sure, but if you’ve been following our development you should know that we actively fix issues like this when it’s reported.
The confirmation was added because some people accidentally completed/deleted parent level items with lots of children items. All this without knowing it happened, so you can see the frustration when they realize half their stuff was nowhere to be found.
There’s always a trade-off between making things easier to do, and accidentally doing it. I don’t think that means there’s something wrong with sliding. In fact, many other apps does it this way - not saying there’s no downsides but there must be some merit to the design if it’s that popular.
I also don’t understand why you use such a tone. You’re using our product for free, we’re happy you want to voice issues with it. We’d be happy to make our product better with your help, but your threats to use Workflowy is completely uncalled for. Please don’t do this again.
There’s restraint and then there’s Shida. Different class.
Nice one Shida
You are correct about the hostility. I was very frustrated. I’m a UX designer (18 years, award winning) working on applications so my tolerance can be quite low. But seriously, it wasn’t that hostile, I’ve heard much worse. This has been in Dynalist for quite a while and it is very frustrating, which tells me there is no hurry to address it. While you re-iterated what I discussed, you didn’t address the problem, except for my suggestion (make it an option). You did feel the need to discuss my tone, but not a solution. While Dynalist is free, that is also part of the marketing plan, which makes sense.
Of course, the internet is full of dark and scary places. We only strive to keep our discussion forums civil and free of hostility. Think about it this way: by being hostile, you don’t achieve anything here other than venting your frustration. We don’t intentionally want to ruin your day by not fixing this issue, but in return we ask for your respect to not intentionally direct your anger at us.
Maybe I missed it but has it been reported by another user? I personally haven’t ran in to this (admittedly I work on my desktop way more often than use my phone).
I think it may have coincided with iOS 13’s new selection manipulation mechanism that we’re only aware of it now. Previously there were handles you would drag with, which I believe did not trigger the swiping action.
I did address the problem:
An alternative I’d propose is to disable swipe actions when there’s a cursor focus. I think this is a good solution because when a user intend to swipe and complete/delete, they will need to click on the confirmation, which de-focuses and hides the keyboard. So given a de-focus happens regardless, I think it’d be a better experience if swiping only works when there is no focus and the keyboard is hidden.
Actually, you missed the point.
What’s the point that I missed?
Fellow user here (paying user). Welcome to our community, and it IS a community. This forum is great for it’s open, friendly, discourse and for users helping each other. We’re very fortunate in having the active participation of the devs and, beyond that, their active listening and passion to improve the product.
This is your first post and you chose to use it make an unpleasant attack on the Developers for something that was frustrating you. You then compounded this by, explaining, rather than apologizing, for your tone. Can I suggest that, if you’re new to a community, you take the time to gauge the way it works before posting? What’s acceptable and normal in one community may not be so in another. If it helps, here are the forum guidelines. If you find it difficult to present your frustrations in a civil way then maybe a closed channel would be more suitable for you. Feedback can be give here .
Is Dynalist perfect? Absolutely not. Do users get frustrated? Of course. However, more than any other software product or service I’m currently using, or have used in the past, the team care about getting it right and are committed to doing so.
I hope you will persevere with Dynalist and find it as indispensable as I do. Perhaps, you will even post again and give us all the benefit of some of that “award winning” experience.
Take care. Be nice.