Capture plaintext (Brain Dump)

[nelsonic]

The basic "workflow" of the @dwyl app will be:

1. Capture the idea/thought
2. Categorise the information
3. Create / Complete the task

The first step in our app is to help the person capture everything on their mind.
We call this step/feature the "brain dump". The purpose is to empty your working memory so that you're not thinking about too many things and can focus on the one most important thing. "Free your mind" ...

If you haven't seen The Matrix this reference will be lost ... Seriously, watch it!

• https://hustletostartup.com/brain-dumping (post needs some editing)
• https://anniemueller.com/brain-dump-noun-1/ (definition and intro image)

Todo / Acceptance Criteria

Figma wireframe: https://www.figma.com/proto/WrpkKGJNYZbeCzMRDVtvQLbC/dwyl-app

• A textarea for free text input
  • Informative / action-inducing placeholder text
    (tbd ... for now "write down everything that is on your mind" ... we will A/B test this later!)
  • Automatically expands to use the available space on mobile device
• Text is saved to Phoenix backend and stored in text field in Postgres

For now this is "enough" to get started.
We don't need anything fancy it just needs to work.
Once we get the Capture stage nailed we can move on to the rest of the workflow:

Note: we are working on inputting text first.
Once text is working, we will add Image support. see: dwyl/imgup#46

[iteles]

My prediction is that people will want to add tags as they brain dump for some form of categorisation but that's definitely a next step 👍

[nelsonic]

@iteles agreed. We cannot expect to impose a strict separation of the steps.
in many cases people will capture, complete and then categorise their tasks.

Our job as UX designers / developers is to make the process seamless in any order.

[SimonLab]

I like the idea to keep the capture simple. For example I dont't think when "brain dumping" you want to have to click on "add item" as it makes the capture less quick and can also distract from your thoughts. so a textarea seems appropriate for this first step.

However the text captured still need to be converted to items. For a first iteration we could split the text on new lines to create the items (should this be added as acceptance criteria?)

In the case where the items needs to be more complex, for example can item contains multiple paragraph, images, sound... we will need to find another way to differentiate the items.

[nelsonic]

I've been racking my brain to figure out how we are going to store the plaintext
and I've reached the conclusion that we can store the plaintext in item.text.

Let's consider the following "brain dump" which would create a single item:

Develop morning routine.
Trigger morning routine automatically on waking each day.
Track progress in a repeatable checklist
Share list with relevant people so they are aware.

This plaintext is one item until the person splits it out into separate items using tags.

When the person inputting this plaintext decides to Categorise the data,
the original item would e.g: item.id 1 would continue to exist,
but 3 new items would be created:

1. Develop morning routine. [task]
2. Trigger morning routine automatically on waking each day. [reminder daily]
3. Track progress in a repeatable checklist [task]
4. Share checklist with relevant people so they are aware. [task]

@iteles / @SimonLab thoughts?

[SimonLab]

To clarify, on brain dump a new item is created, eg:

id: 1
text: 
Develop morning routine.
Trigger morning routine automatically on waking each day.
Track progress in a repeatable checklist
Share list with relevant people so they are aware.

Then when the categorisation process is triggered 4 new items will be created:

id: 1 (original item is preserved so history can easily be viewed)
text: Develop morning routine. [task]

id: 2
text: Trigger morning routine automatically on waking each day. [reminder daily]

id: 3
text: Track progress in a repeatable checklist [task]

id: 4
text: Share checklist with relevant people so they are aware. [task]

and the item id 1 still exists, is that right?

In this case do we want the new 4 3 created items to be linked to the "source" item?

id: 1
text: Develop morning routine. [task]
source_id: 1

Allow what actions do we want to do when the source text is edited:

• delete and recreated the items?
• keep the current items and create new ones linked to the edited source?
• user can't edit the source text only the generated items?

[nelsonic]

@SimonLab hope you don't mind that I edited your comment to clarify it, it was faster.
The original item (id=1) is preserved and only 3 new items are created.
The concept of a source_id is definitely worth exploring to have traceability of items through the stack. (separate issue/story) 👍

[iteles]

It will be very interesting to see whether people want to capture a run-on list of to-dos in this way. Possibly by capturing a main task with various sub-tasks all at once...

The one thing I believe is missing from the acceptance criteria is submitting the text (i.e. I've written what I want to write and I want to either move onto the next item or I want to exit the app but know my text has been saved).

I propose this be a little icon for submit for now from icon8:

I'll open a separate issue on which icon to use!

[nelsonic]

@iteles submission is implied by saving the data to the server. But you’re right we need to be 100% explicit with the UX. initially we will have a submit button. But as soon as we start with the PWA, saving will be automatic and transparent.

[nelsonic]

@SimonLab given that we are going to be AFK for much of Thursday,
would you mind taking a look at this issue to attempt to estimate it?
For now we just need to capture plaintext in a textarea
and save it to item.text on the server with a "submit" button.
(please/thanks!)

[SimonLab]

Current interface, home page, capture page and list of captures:

• Make the header/menu more obvious (eg background colour different to the main section) to make it easier to navigate to the home page

• Make sure the textarea on the capture page takes all available space to make it easier to type text
• Change the "Categorise" button to "Save" button save icon (see Capture plaintext (Brain Dump) #234 (comment))

• Change title of the page to "list of captures"

I'll also make sure the display of the pages are good on desktop. Other styles can later be applied to make the pages a bit more user friendly (eg: font size and colour, spacing, button size and colour)

[iteles]

@SimonLab Thanks for this! This is the comment with the icon for the save: #234 (comment)

[SimonLab]

Home page:

The navbar is a bit more obvious now. Of course the colour, text can be improved. I'll see later also if I can center the group of buttons vertically. Let me know also if you have any other ideas on what needs to be changed on the home page or any elements you would like to be displayed (or removed)

[SimonLab]

Capture screen:

Removing the syles for the submit button to only display the arrow image:

[SimonLab]

I've spotted an error with Ecto when the capture is a long text:

We can fix that by adding a new migration file to update the field from :string to :text for the items

[nelsonic]

@SimonLab good catch.
Indeed item.text is currently :string https://github.com/dwyl/app-mvp-phoenix/blob/663ea3a8744fe5972e649ce4ac560a79db0fe20a/lib/app/ctx/item.ex#L6
but it should be :text. 🙄
Please create the migration when you can. 👍

[SimonLab]

Captures page:

[nelsonic]

@SimonLab capture is looking functional. 🎉

[nelsonic]

@SimonLab great work on PR: dwyl/mvp#22 🚀 Thanks!
I consider this issue "done" for MVP purposes. (we will refine it in subsequent iterations) 👍

[nelsonic]

[nelsonic]

@SimonLab is https://dwylapp.herokuapp.com/capture supposed to show the capture form?

[SimonLab]

At the moment all the capture are in the categorise page: https://dwylapp.herokuapp.com/categorise which is the "next" step when processing your captured thought

But I agree it would make more sense to displayed all the captures on this endpoint as I'm not sure there /categorise endpoint will be needed later on