Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Categorise -> How to Transform Plaintext into Actionable Items? #235

Open
nelsonic opened this issue Nov 8, 2019 · 5 comments
Open

Categorise -> How to Transform Plaintext into Actionable Items? #235

nelsonic opened this issue Nov 8, 2019 · 5 comments
Assignees
Labels
epic A feature idea that is large enough to require a sprint (5 days) or more and has smaller sub-issues. help wanted If you can help make progress with this issue, please comment! needs-criteria needs-ui A feature idea that needs UI in order to be discussed/built. priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished T1h Time Estimate 1 Hour

Comments

@nelsonic
Copy link
Member

nelsonic commented Nov 8, 2019

As part of clarifying the "What?" in our Product Roadmap dwyl/product-roadmap#9, 🤷‍♀
we need to create a UX/UI that allows people to Categorise their plaintext
into something more useful and actionable. 📝 > ✅

My initial sketch/idea was to simply transform the plaintext into a set of Todo items:

image

However this is not a very compelling UX. It offers almost no benefit over existing Todo List apps and does nothing to offer a "workflow". This is a classic case of attempting to solve the problem, before the problem has been clearly defined. 🤦‍♂ So let's first focus on defining what we want to achieve. 💭

What Problem Challenge Are We Solving?

The challenge we are solving is: how to categorise, organise and prioritise unstructured information.

Story

As a person wanting to be more effective with my time,
I want to organise my thoughts (plaintext) into clear categories and kinds of actionable item
(e.g: "note", "task", "reminder", "appointment", "meeting", "reading", "exercise", "shopping", etc.)
So that I have system for everything in my life and nothing falls through the cracks.

@iteles can you please read through this and see if it makes sense, if not, please edit/improve. Thanks!

@nelsonic nelsonic transferred this issue from dwyl/product-roadmap Nov 11, 2019
@iteles iteles added epic A feature idea that is large enough to require a sprint (5 days) or more and has smaller sub-issues. T1h Time Estimate 1 Hour labels Nov 20, 2019
@iteles
Copy link
Member

iteles commented Nov 20, 2019

There are a couple of different scenarios here:

  • A capture that is a single item
  • A capture that has multiple to-dos contained within it (as per the screenshot examples in the OP) - this is made additionally complex because say a person is creating a shopping list, are they going to have to create everything in plain text and then go to each line individually and 'turn it into a checkbox item'?

In addition to this, there is a question around WHEN the categorisation happens - is there an action vs non-action switch when you first enter the plain text? Or are you only 'allowed' to categorise once you've finished your capture?

@iteles iteles added the in-progress An issue or pull request that is being worked on by the assigned person label Nov 20, 2019
@nelsonic
Copy link
Member Author

nelsonic commented Nov 20, 2019

@iteles let's consider a single use-case for now (that isn't shopping lists which should really be linked to recipe lists which are in turn linked to meal plans and managing inventory/pantry items ...)
For now let's focus on capturing a bunch of plaintext a typical list of "things on your mind" for work/life
and converting it into actionable items which can mean that a line of plaintext can be a single "task" or it can have multiple sub-task. We're trying to keep the app simple i.e. not introducing the concept of "Projects" until we need them and not complicating the UI with "shopping lists" until we have a legitimate use-case.

@iteles
Copy link
Member

iteles commented Nov 20, 2019

@nelsonic Naturally. My expectation of an epic like this is that it 'generates' multiple issues - a very small number will be relevant for MVP and a much larger number will be for discussion or 'further down the roadmap' features. That's why this issue is still assigned to me and in-progress ☺️

@iteles iteles added priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished needs-criteria needs-ui A feature idea that needs UI in order to be discussed/built. and removed in-progress An issue or pull request that is being worked on by the assigned person labels Nov 20, 2019
@nelsonic
Copy link
Member Author

nelsonic commented Nov 20, 2019

Suggested UI/UX for transforming an item of plaintext into a task:
image

This is definitely not the "final" UX, it's just a visualisation of how to Categorise text into something actionable. If you want to edit or add to this design please do so in Figma: https://www.figma.com/file/WrpkKGJNYZbeCzMRDVtvQLbC/dwyl-app?node-id=0%3A1

I've annotated the design to attempt to explain the flow:
image

@iteles / @SimonLab LMK your thoughts/suggestions.
I'm aware that completely changing the contextual menu when a categorisation action is performed (in this case the creation of a "Task" item) so this is something we will need to discuss & test with people.
I just figure that the Mobile screen is so small that we cannot display all the buttons all the time
and in the case of "Undo", there's no point showing "Undo" before a categorisation action has been made. But equally there's no point continuing to show the "Task" or "Reminder" buttons once an item of text has been transformed into a Task. However I feel that the "▼ More" button could allow us to show lots more options including the full tagging #245 interface.

@nelsonic nelsonic added the help wanted If you can help make progress with this issue, please comment! label Nov 21, 2019
@iteles
Copy link
Member

iteles commented Jan 7, 2020

My computer is having a moment and was refusing to charge so I will add my UI sketches later, but I wanted these thoughts to be captured ASAP. I will add further thoughts once my computer is working again.


I have been going around in circles with #245 but actually the reason it's taking so long is that I'm reviewing this proposed UI with totally different eyes/perspective.

I love the idea of being able to braindump and then convert this to tasks (although as with everything, we are not married to it, but we think it's a great thing to set the app apart). HOWEVER, this makes the UI uncomfortably more complicated so we need to rethink and re-simplify. Although we will have progressive learning of the application #197, there is still a need to make features as intuitive as possible.

The aim here is to go from entering any flow of text to having a categorised item (action, prose or capture).

Possible flow-jarring actions with the current proposed UI

This is not critical. In order to figure out what needs to change to feel intuitive, we need to start with places where people might find an action required to interrupt their flow (and therefore overall warm and fuzzy feelings) or using the app.

  • On a screen with no options, it's not intuitive to know that the next step is to highlight a sentence, so we would need to provide some kind of button to help people not get 'stuck' (although they could still highlight the sentence)
    +
  • Tapping a sentence is usually done to edit it, so we would need to provide both the cursor and the highlight once a sentence is tapped
  • Creating a single focus to-do list item (which is the most familiar user pattern to people coming to our app from any other apps) is a bit more time consuming than it needs to be as we've added the step of highlighting the task before making it into a task or not

I considered having the menu always display but the issue is that we wouldn't know which of the many sentences the person was trying to categorise in some way if they just start using the menu without highlighting.

Alternatives

a) Contextual menu per line

This is where having created a multi-line item, you would have a contextual menu appearing on each line (defines as anything before a line break rather than a physical line) as a button to click in order to take action.
This makes everything look more complex than it is and takes up valuable screen real estate. Not a good solution

b) Presumption that if this is a task, every other line is a sub-task of that task

Here, clicking the ‘Task’ button on a multi-line item would create a task from the top line and then make any further lines into sub-tasks of this main task.

This is also not a great solution because it makes far too many assumptions. It could be that the top line is a task with the remaining lines being comments/notes for that task.

It could also be that they are all individual tasks and totally unrelated.

c) The original solution in the OP but if there is only one line (ie no line breaks), no highlighting of the line is required for the menu to appear

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic A feature idea that is large enough to require a sprint (5 days) or more and has smaller sub-issues. help wanted If you can help make progress with this issue, please comment! needs-criteria needs-ui A feature idea that needs UI in order to be discussed/built. priority-2 Second highest priority, should be worked on as soon as the Priority-1 issues are finished T1h Time Estimate 1 Hour
Projects
None yet
Development

No branches or pull requests

2 participants