Can't easily update fields other than description, during the task creation

[Brady Trainor]

I think the following describes the issue well,

Also, the task creation, while simple, lacks the ability to set tags, project or anything else. I first have to remove any filter and sort the task by 'entry'. This adds more effort for someone to create any tasks.

Originally posted by @Akendo in #3 (comment)

This user experience was even worse before the sort feature was added. This issue was a significant proportion of the motivation to implement the sort headers feature as soon as I did. Originally all views were sorted by descending urgency.

Similarly, I may first approach this issue with workarounds via other features. If #4 is implemented, then it would be somewhat easier to get to the recently created task and edit its fields. In the steps described in the above quote, you could quickly switch to the sort:entry- view, and when you're done updating the task, switch back to the sort and filters you were previously considering.

But this issue, while a good place to track the progress on workarounds, is also opened to discuss and track the more specific feature request of actually changing the task creation UI.

I have been considering improving the task creation UI for some time, but I have preferred to consider/prioritize other issues in the app, and as well I'm not sure which direction to go in with the task creation UI.

Among other less-related priorities, I may want to postpone this till I've looked more into adaptive layouts.

Thoughts on which direction to go for changing the task creation UI

I noticed in the Microsoft To Do app ("developed by the Wunderlist team"), their task creation UI is at the bottom of the list, almost blending in with the list, and they manage to fit something like a +next tag toggle, a due date button, and some sort of reminder button, all in that small task creation UI that leaves the task list in view.

I've also considered how simple and uniform it could be, if task creation took you directly to the full task editing details page. Or even if the simpler task creation UI offered a third button to take user to the new task's detail editing page. Or maybe a long press on the first add button, like the quirk where long press removes due dates. Long pressing add might take user to the full editing page. Generally I don't want to be wrestling too much with what design elements are offered most easily by the Flutter framework and their Material app widgets. I try to leverage the features as they are offered, without too much custom UI writing. I try to avoid too many third party dependencies as well, to simplify maintenance.

Similarly, the Microsoft To Do style task creation, seems to be done with something like a bottom sheet, which is a Flutter widget that I've had more difficulty with in previous attempts to add to apps (an older iteration on this app, I had tag filters in a sort of bottom sheet). The developer experience with bottom sheets in Flutter may improve in the future, the project seems to be moving fast.

But once I start to move from the current simple task creation UI, towards either the style in Microsoft To Do, or just taking user to the full detail editing page, or make that an option during the task creation process, I not only am complicating the project, making other higher priority issues harder to get started on, but I will be sort of stuck between the various approaches, not wanting to mess with user muscle memory, or not sure how to justify significant changes in that UI, once I've headed in one of those directions.

If anyone has ideas on why one of the approaches seems more obvious, or how I can resolve this point of indecision, that would be very helpful.

[codingTornado]

Hello and thank you for the hard work. This is probably the best TW app I've used; it's super clean and easy to use considering the little things like this issue.

My grain of sand on this topic: I've tried multiple to-do list aplications on Android over the years, and what I see on most of them is that the new button redirects you to the full editing page to create the new task. That being said, having a fast way to add tasks on the go without much detail is a very useful thing to have.
I believe, from my personal experience, the middle ground is having the add button take you to the detailed task view and having the save button close enough to the description field so you can just type and go save.

Other options I can think that might work:

• Add some parsing to the current task creation dialog to process things like "+tag1 +tag2" as tags, or even giving the possibility of a full parsing like if being added through the terminal. This can be obviously complex, but maybe a subset (like only tags) could be easy enough and not cumbersome to use if needed.
• Add a second add button for quick-add. Can make the screen bloated, but can be pulled off somewhat ok? Maybe? DGT SODA does this and it kind of sort of works fine.
• Add a multi selection input, or whatever is available to Flutter, for the tags in the dialog. It's again a subset of attributes, but I think this might be the most used or at least the one that can be used to make a list for later processing (you can add a tag +in or something and get a nice "inbox" functionality).
• Add tasks with the current filter as base project and tags.

Hope this ideas help!

[Brady Trainor]

Thank you for the kind words, and the discussion above.

• Add some parsing to the current task creation dialog to process things like "+tag1 +tag2" as tags, or even giving the possibility of a full parsing like if being added through the terminal. This can be obviously complex, but maybe a subset (like only tags) could be easy enough and not cumbersome to use if needed.

Your suggestion of parsing felt like the best place to start. It's something like a simple function that can be relatively easy to write unit tests for.

Version 0.2.1 should be on Android in a few days, and on App Store in a day or so. At version 0.2.1, you can add with foo +bar +baz pri:H pro:quux. A little more description of parsing behavior might be understood by browsing the task parsing unit tests, at https://github.com/bradyt/taskw-dart/blob/v0.2.1/taskw/test/task_parser_test.dart.

I also added a button below text field to set due date with GUI dialog. I started to pursue parsing named dates, durations and expressions combining such, but wasn't sure if it was strictly better than a GUI dialog, and decided to simply add the due dialog button, at least for now.

It shouldn't be too hard to find ways to break the new task creation features, but hopefully the current changes bring more benefits than drawbacks.

I expect the parsing and due date button to be a small anticlimactic change, I will be as curious as others how much this improves the app for me, but hopefully gets us closer to the next priority.

Regarding the proposals I have not yet addressed:

My grain of sand on this topic: I've tried multiple to-do list aplications on Android over the years, and what I see on most of them is that the new button redirects you to the full editing page to create the new task. That being said, having a fast way to add tasks on the go without much detail is a very useful thing to have.
I believe, from my personal experience, the middle ground is having the add button take you to the detailed task view and having the save button close enough to the description field so you can just type and go save.

I'm still hesitant to have primary add button open a detailed edit page. Especially since I expect muscle memory would make removing such behavior a bit annoying. I try to avoid adding conveniences that could potentially be removed later, or therefore discourage other improvements. For example, making it easier to mark a task done could block or discourage some other ideas I have, so I'd rather wait to improve the UX for marking task done. For example, batch editing, or swiping between list views (whether this is queries, reports, or contexts, I'm not sure). TaskwarriorC2 had this swiping feature between task commands, more or less.

• Add a second add button for quick-add. Can make the screen bloated, but can be pulled off somewhat ok? Maybe? DGT SODA does this and it kind of sort of works fine.

Rather than have two buttons for something like "quick add" versus "slow add", the idioms I think I find in larger app projects like Todoist or Microsoft To-Do, is either the task is scrolled into view, if not filtered out, or a link is temporarily bannered or snackbar'd near top of list, in either case it is easy to go to a task editing view for a recently added task. This seems like a good feature to try to prioritize, but I'm not sure yet how challenging it will be to design and implement.

• Add a multi selection input, or whatever is available to Flutter, for the tags in the dialog. It's again a subset of attributes, but I think this might be the most used or at least the one that can be used to make a list for later processing (you can add a tag +in or something and get a nice "inbox" functionality).

By multiselection input, do you mean something like a dropdown menu (if I recall correctly, they can go up or down, depending on location, etc.), with checkboxes in the case of tags? I do like this idea, I think Todoist has a nice feature like this. So in our context, typing something like + or pri: or pro: could potentially bring up something like a dropdown menu. Todoist seems to be a great example for this. And they even have buttons underneath the text field, like pressing tags button could insert + in the text field, and the dropdown menu opens with completions filtered by matching if you type.

Hopefully lexical sort of completion candidates would suffice. Potentially they could be sorted by frequency count, an aspect of tags that has precedent in CLI Taskwarrior, or the most recent modified timestamp of any task with that attribute, which does not have precedent in CLI Taskwarrior.

• Add tasks with the current filter as base project and tags.

Microsoft To-Do seems to have something like this constraint. So it seems you cannot add a task without it appearing in the current filter, and thus the new task always can be scrolled into view.

Such a feature, I may want to postpone and de-prioritize, until I've possibly considered features like CLI Taskwarrior's contexts and reports. A slight issue is that I haven't had time to try Taskwarrior's contexts feature, but I may find the feature more intriguing in a mobile app. Not sure.

Hope this ideas help!

They did! Thank you!

[Brady Trainor]

At version 0.2.1 described above, the Add task dialog is starting to get a little cluttered for my tastes, so I managed to switch implementations from an AlertDialog to showModalBottomSheet. I'm not sure when I'll have a chance to release next version, so here's a preview screenshot:

In the process of doing that, I'm experimenting with that keyboard_enter icon to add a task and keep the dialog open to quickly add multiple tasks, as I've seen in some other todo apps. Also experimenting with a design where done key will submit a task if text field is non-empty, then close the dialog. Or you can just cancel the dialog by tapping the shaded scrim. Not really sure if those are good discoverable behaviors, so may need to change that.

[Brady Trainor]

I'm a little peeved with the changes I made, I emulated some of the quoted string parsing of Taskwarrior, and I think a contraction like "isn't" contributed to my app silently dropping parts of a task I added. This app does not benefit from something like GNU readline command history, like we'd see on Taskwarrior, and undo, features which would make it easy to recover from a mistake like this.

Also I think anything like a:b will be silently dropped.

I'm tempted to revert these changes until I can do a better job of experimenting with UIs and implementations. I'm also tempted to block further development on #16, but as I say there, that issue may be a soft block, just serving as a little potential motivation for myself.

I find the new consecutive entries and missing cancel button a little less obvious than the previous simpler dialog. I might have preferred to test that a bit on a beta release before releasing it as stable to all users. I simply don't add that many tasks via mobile to gain a sense quickly enough.

Just wanted to let users know that this feature has led to a bit of difficulty, and there could be some further delay, and possible reversions of some aspects of the new feature, to reduce the disorienting issues I think I introduced in 0.2.1 and 0.2.2.