In the course of building Ooradee, a todo app side project, one of the most important things I’ve learnt is that interface and experience design is very difficult to do well. A big reason for this is that it’s very difficult to anticipate how a change affects behavior and perception. So, it’s necessary to iterate, a lot.

The main component of a todo app is simply a text input. To make it intuitive to use, even just for myself, I had to iterate through it quite a few times.

Here are the questions I had to answer about how it should look and function:

1. How to display it? Should it be an input, contenteditable, a textarea or using Trix?

   a: I ended up trying all of them eventually settling on contenteditable.

2. How to indicate that it’s editable? Should there be a button that edits it? Should it be just be a textarea?

   a: Tried with and without a button. The appearance ended up intuitive enough that I didn’t need an edit button.

3. How to save it? Should there be a button or just enter?

   a: Enter was intuitive enough.

4. How to show it when it’s not being edited?

   a: Tried having an indicator, an edit button but ended up removing them.

5. Since enter is used for being saved how to enter new lines?

   a: Shift+Enter seemed to be used by other software so I copied that. It still causes confusion sometimes because some software uses Alt+Enter. Considering making it both.

6. What if the user enters multiple lines? How to display multiple lines? Should there be a more/less link?

   a: Long content was very unwieldy so More/Less link was very useful. Ended up having to implement it manually so as to be able to keep track of the state for when the field is blurred or another field is focused.

7. What if the user enters multiple lines and then presses enter? Should there be a way to create multiple items from a single input?

   a: I decided to make Ctrl+Enter split the input into individual lines and create individual items for each line. This still is not discoverable and likely needs a hint to show that it’s possible.

8. Since I decided on using content editable, how to handle formatting? Should there be a toolbar?

   a: Tried with a toolbar but ended up not wanting detailed formatting so instead added a hint for keyboard shortcuts. Still missing a shortcut for strike-through.

9. What buttons should the toolbar include?

   a: Tried quite a few taking cues from the Trix editor. Ended up removing all of them.

10. What to do about pasting formatting?

    a: Pasted formatting seemed to be mostly a bad thing, especially when copied from Google Docs for instance. The amount of HTML generated was breaking too often. Decided to strip it.

11. What tags to allow?

    a: Tried being as permissive as possible but in the end decided that it’s not a text editor so ended up with div, p, b, i and br.

12. Since the toolbar only includes the most common functions of bold, underline and italics, should I remove the toolbar?

    a: Yes.

13. Since I removed the toolbar, how to handle formatting on mobile?

    a: I decided to (eventually) implement a floating formatting toolbar on mobile.

14. How to add a new line on mobile? Should there be a save button so enter can be new line?

    a: I decided add a save button on mobile so enter can be used for new lines.

15. Since I added a save button, how should I place it?

    a: Below the field, to the left to the right, fade in, fade out, show only when there is content, show if there isn’t content but disabled. Still trying this out.

16. What if the content fills the screen? What happens when the user saves a new item that has a lot of text?

    a: First, add the More/Less link. Then when the user saves, by default collapse it but scroll it into view. In the beginning, it was quite confusing after entering a bunch of text and clicking save, the screen changes quite a lot and there is little way of indication that anything has been done.

17. What happens after editing a item with a lot of text?

    a: Leave it open, but scroll to the top.

18. How about on mobile?

    a: On top? What if the content is long? OK, on bottom? What if the user is editing the beginning. OK, so floating. Added a floating bar on the bottom for saving on mobile.

19. How to cancel editing?

    a: I added a cancel button that reverts the content.

20. How to cancel editing on mobile?

    a: Added the cancel button to the floating bar.

21. How to handle links?

    a: Well, links can just be copy pasted but that’s not really friendly. OK, so add a library that parses links in divs and makes them actual anchor tags. Add anchor tags to allowed tags.

22. How about hashtags?

    a: They should obviously link to a search with the tag as the content. In the backlog at the moment.

23. Should I support emojis?

    a: I found myself using them for indicators, so yes. Change the encoding for the database connection to support UTF8.

24. How to sort items?

    a: Automatically. Sort them by starred, category priority then time added.

25. Does @ do anything?

    a: At first I imagined it’d tag people for assignment. But since the focus is individual rather than team work, I decided to make it used for sorting. So, anything following @ would be considered that items priority.

    Still figuring out how to properly educate the user that this is what it does.

26. How to sort items with time?

    a: Tried below and above the starred items. Below seemed to make more sense.

27. What if the user has two items with same priority?

    a: Well, that’s not good. Instead on save, increment any clashing priorities.

28. What if the user enters a time after @?

    a: I found myself doing this quite often. Entering @11am do something. OK, so add a parser that takes anything after the @ and the first space and parses it as time if it has a colon or am|pm and then group items that have time together and sort them.

29. What is the user moves an item that has a time set?

    a: Obviously the time has to be changed to the new date.

30. How to show hints?

    a: Just dump them below the box. Need to find a better way for this.

31. What if the user starts editing but then the input loses focus?

    a: I decided to keep the content in the box but not save it. However, if the user navigates away the content is lost. Not sure if this is right, or if I should keep the draft content saved more permanently and add an indicator that it’s a draft.

32. Since I’m using content editable what if the user presses enter while they’re at the start of the line?

    a: This was causing an issue since the handler would trigger after the content has been updated resulting in items that have a new line at the start. OK, so have to intercept it and check if it’s at the beginning, and if it is, remove the new line from the start and then only save.

33. What tag to use for paragraphs?

    a: This is still up for debate. At the moment it’s div but it might be changed to p.

34. What if the user presses ESC?

    a: I found myself instinctively pressing ESC to cancel editing, so have had to add that.

35. What if the user edits it in another window?

    a: I implemented live updates using ActionCable but then realized I’d have to roll another server and set up Redis. But I didn’t want to have another server just for redis. Instead, I implemented a basic solution that gets most of the way there without ActionCable and Redis. More details about how to reload the content without cables are here.

And after all this the input is still not done. There are quite a few answers that I’m still not certain about that might have better implementations. Or I’m aware of what the correct implementation is, but I haven’t had the time to do them. Good design is hard.

Another interesting conclusion is that while there is only a single input that the user interacts with, several inputs generate data for different fields.