{"id":794,"date":"2024-02-12T18:19:10","date_gmt":"2024-02-13T00:19:10","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=794"},"modified":"2024-02-18T11:17:36","modified_gmt":"2024-02-18T17:17:36","slug":"building-a-todo-app-from-scratch-step-1-planning-design","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/building-a-todo-app-from-scratch-step-1-planning-design\/","title":{"rendered":"Building a TODO App from Scratch \u2014 Step 1 \u2014 Planning & Design"},"content":{"rendered":"\n

I find it fascinating how websites come to be. Especially websites with user interactivity and functionality, there are so many things to plan, build, and maintain, that it’s no wonder it easily makes for a whole career.<\/p>\n\n\n\n

Perhaps one of the most clich\u00e9 introductory things to build on the web (or otherwise), is a to-do app<\/strong>. But we’re going to do it again, as a website, and for good reason: it’s the perfect scope. A to-do app is fairly simple, adding and removing short bits of text forming a list. But it’s not too<\/em> simple. It requires us to think about all sorts of things. While we’re ultimately going to care about coxre web development technologies like HTML & CSS, we’re going to choose to layer in JavaScript to help with user experience and data handling, and then see what other technology we might find helpful along the way, if any. <\/p>\n\n\n\n

We’ll call our project TODO. Don’t sue me. It’s just for learning.<\/p>\n\n\n\n

\"\"
We’re not going to get fancy right off the bat. <\/figcaption><\/figure>\n\n\n\n

And we’re going to do this thing as a series, so this list of posts will be updated as they are completed.<\/p>\n\n\n

\n
\n

Article Series<\/h3>\n <\/header>\n
\n
    \n
  1. \n Building a TODO App from Scratch \u2014 Step 1 \u2014 Planning & Design<\/a>\n <\/li>\n
  2. \n Building a TODO App from Scratch \u2014 Step 2 \u2014 HTML<\/a>\n <\/li>\n
  3. \n Building a TODO App from Scratch \u2014 Step 3 \u2014 Basic JavaScript Functionality<\/a>\n <\/li>\n
  4. \n Building a TODO App from Scratch \u2014 Step 4 \u2014 Styling & Interactive Choices<\/a>\n <\/li>\n
  5. \n Building a TODO App from Scratch \u2014 Step 5 \u2014 Extra Functionality<\/a>\n <\/li>\n <\/ol>\n <\/div>\n<\/div>\n\n\n\n

    Prior Art<\/h2>\n\n\n\n

    Marc has already broached this subject on this very blog.<\/a> Go check out the GitHub repo<\/a>, where there is a lot of code to explore. Marc went deeper on the JavaScript aspect than we likely will. He tells me:<\/p>\n\n\n\n

    \n

    I added branches for TypeScript support, used lit-html<\/a> for performant rendering, and an app-architecture branch for how to architect larger apps<\/p>\n<\/blockquote>\n\n\n\n

    There is also an extremely cool project called TodoMVC<\/a> that was hot’n’heavy around 2012-2016. The purpose of it was comparing<\/em> different approaches of a to-do app created using different JavaScript frameworks and vanilla approaches. <\/p>\n\n\n\n

    \n

    TodoMVC is useful for comparing syntax and solutions, is officially used in cross-browser benchmarks.<\/p>\n<\/blockquote>\n\n\n\n

    It was\/is useful in helping people decide things like “Do I like the Angular approach or the React approach?”, for example. People could decide by looking at the actual code as well as seeing\/feeling the output. We might fiddle with those ideas a little, but we’ll be focusing more on the thinking and experience of building and leaning toward vanilla code.<\/p>\n\n\n\n

    There are no wrong answers<\/h2>\n\n\n\n

    We’re going to take an intentionally wordy trip through this project. We’re going to think about lots of different aspects of product development and web design and development. We’re going to do it in a certain order and land on certain choices. <\/p>\n\n\n\n

    If you were going to build a to-do app of your own, you might think about things differently. You might make different choices. You might do these things in a different order than I’m doing them. I think there is a rhyme and reason to the path I’ll write about, but that doesn’t make yours wrong. In fact, I think finding your own way is a great way to learn, and probably what you’d do anyway regardless of anything you read.<\/p>\n\n\n\n

    So unless what you build is broken or inaccessible, there is no wrong way.<\/p>\n\n\n\n

    Design: Thinking First<\/h2>\n\n\n\n

    I like putting design first, design-driven development<\/em> as it were, and here’s why. Design forces you to think about your app more holistically than you might otherwise. <\/p>\n\n\n\n

    When I started thinking about this idea, admittedly, I started poking around at JavaScript right away, putting some basic HTML together the JavaScript could work with. I was having fun reminding myself how powerful native web tech has become and how much we can do without reaching for anything else at all. But then things started to feel sloppy as I realized I was just randomly poking at things rather than have any actual plan. Sure, I could add new to-do items to a list, then remove them. But oh yeah I need to display the list from saved data. And then what else? Can you re-order them? Can you edit them? Can you delete multiple at once? That’s just scratching the surface. Design allows you to take a beat, stop thinking about implementations, and think of a plan first.<\/p>\n\n\n\n

    A Look Around<\/h2>\n\n\n\n

    There is no shortage of to-do apps. It’s not like we wouldn’t be able to piece it together with our own thoughts of what should be in an app like this, but don’t let that confidence fool you! It’s always worth a look around to see how other apps are doing things, particularly successful ones because those in particular help establish the genre and set user expectations. <\/p>\n\n\n\n

    Here’s a quick walk through some to-do apps I happen to know about. Seriously, quick. These are very surface-level observations, nothing deep. <\/p>\n\n\n\n

    Things<\/h3>\n\n\n\n

    Things<\/a> is the to-do app that I’m most familiar with. It’s a native app, as opposed to the web like we’re doing, but that doesn’t stop us from looking at the UI and UX. <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Notice they don’t go very heavy at all on UI for adding new items. A tiny + on the desktop app and a blue (+) on the mobile apps. The emphasis is more on knowing that Command-N will do the trick. I do enjoy the little feature that you can drag<\/em> the mobile (+) where you want it before adding a new item. Notably, you add a new item before<\/em> you add any text or information to the item. Metadata is pretty limited, preferring that you group<\/em> things in various ways (areas, projects, headings), although there is things like tags<\/em> if you want them. If any metadata is emphasized, it is due dates. <\/p>\n\n\n\n

    Todoist<\/h3>\n\n\n\n

    Todoist<\/a> actually is web-based, so that’s nice to see (hey, you get multi-platform for free!). <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    More metadata is exposed here. Tasks have a description which you automatically some of is interesting. Plus <\/em>tags, plus<\/em> due dates, plus<\/em> collapsible groups. <\/p>\n\n\n\n

    Notice that adding a new task is also relatively chill. Unlike Things, pressing the + Add task <\/strong>button doesn’t automatically create a new task, but instead expands into a fleshed out task adder:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The task name is the only required thing, which makes sense. It would be obnoxious if anything else was. It feels like a reasonable choice to allow you to add all this metadata immediately, but certainly not the only path. They could<\/em> do it such that you add the task first, then optionally add more to it if desired as an optional next step if you wanted.<\/p>\n\n\n\n

    TeuxDeux<\/h3>\n\n\n\n

    TeuxDeux<\/a> is big on having you put to-do items on individual days, although you can customize it if you want to. Having this kind of initially opinionated structure will have a huge influence on how people think about your app. <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Notice there is almost no <\/em>UI for adding new items. The way it works is that the next item in each column is automatically a live input, waiting for you get into it and add text. The extremely narrow item widths will also encourage you to get to the point darn quickly. You can see the markdown come through with the editing toolbar (Things also does Markdown, but only in the body of the description, which is hidden until opening an individual item.)<\/p>\n\n\n\n

    TodoMVC<\/h3>\n\n\n\n

    This is the standard design as part of that TodoMVC project I mentioned (example<\/a>). This is fun, as it’s quite intentionally minimal. <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Note there is no submit\/add button for new items, which weirds me out a little bit on the web. I’d say this then entirely relies on the submit even from the <form><\/code>, but in this case there is no <form><\/code> (?!), which then not only requires JavaScript but more<\/em> JavaScript as they can’t just use that native event. It’s likely our app will require JavaScript as well, at least at first, as adding a backend language might be a trip too far for this series (but we’ll see, if y’all love it, lemme know). <\/p>\n\n\n\n

    Here we’re seeing implied categories based on completion (and a way to delete the cleared items as well). Plus a count. Plus the ability to double-click to edit. That editablity feels like a significant thing to think about. Does that double-click feel right or should you just be able to click in there? Native operating systems have a click-and-linger approach to name editing sometimes. You could certainly offer an “Edit” button (Pencil icon?) as well, but anything you add to every<\/em> item is going is a risk of visual clutter. Reveal it on focus? Maybe there will be enough items to warrant a sub-menu? We’ll have to see.<\/p>\n\n\n\n

    Initial Features<\/h2>\n\n\n\n

    There is no way we’re going to be as robust as some of these apps who have been working on their feature set for years and years. Let’s call it like this:<\/p>\n\n\n\n

      \n
    1. Let’s emphasize the simple text input. Let’s see how easy we can make it to add a new item to one big single list. <\/li>\n\n\n\n
    2. Let’s also emphasize the Add\/+ button. Not only does it lean into HTML and accessibility correctness, but we can also make it part of our branding. Maybe we can borrow the Things approach of draggability someday. <\/li>\n\n\n\n
    3. Just one big list for now, but let’s think extensibility when we store our data. It shouldn’t be a stretch to add multiple lists, tags, descriptions, or anything else.<\/li>\n\n\n\n
    4. Add and Complete are the primary actions. For now, let’s borrow TodoMVC’s approach of double-click to edit unless we find something we like better while building.<\/li>\n\n\n\n
    5. Let’s try and make drag-to-reorder happen.<\/li>\n<\/ol>\n\n\n\n

      Very basic. <\/p>\n\n\n\n

      Of course, we’d love to add user accounts, Markdown support, due dates, tagging, an API, bulk actions, recurring items, and who knows?? AI helpers? Integrations? If you absolutely knew<\/em> that these features needed to be there for day one, then they should be part of the design process from day one. For us, not so much, so we’ll keep things simple and trim and build that first. <\/p>\n\n\n\n

      It’s fun to think about though! Heck, a to-do app, as simple as it seems at first, might be just as complicated or more than an app in just about any other genre.<\/p>\n\n\n\n

      Design<\/h2>\n\n\n\n

      Knowing what a trim feature set we have, I’ll Figma something up real quick. Half an hour later, here we are.<\/p>\n\n\n\n

      \"\"
      I’d say we should also build a small screen version at this point, but I think it’s fairly obvious this simple design will shrink horizontally just fine. <\/figcaption><\/figure>\n\n\n\n

      This artifact is a little<\/em> useful. We can reference colors. We can be relatively sure we’ve represented what we wanted there for day one. But mostly, this forced us to actually think about all that before our greedy little fingers started coding. <\/p>\n\n\n\n

      We’ll code better if we more clearly know where we’re going.<\/p>\n\n\n\n

      Working design-first also frees up your mind, I find, to think more creatively. Personally, I’m happy to drag things around weird places. Pick weird colors. Make things humungous or tiny. Explore totally different icons. All sorts of stuff like that that I just know I’m much less apt to do once I’m actually coding. For lack of a better metaphore, a left brain \/ right brain thing. As you get to know how you work best and most creatively, you’ll have your own tricks. <\/p>\n\n\n\n

      See ya next time! <\/p>\n\n\n

      \n
      \n

      Article Series<\/h3>\n <\/header>\n
      \n
        \n
      1. \n Building a TODO App from Scratch \u2014 Step 1 \u2014 Planning & Design<\/a>\n <\/li>\n
      2. \n Building a TODO App from Scratch \u2014 Step 2 \u2014 HTML<\/a>\n <\/li>\n
      3. \n Building a TODO App from Scratch \u2014 Step 3 \u2014 Basic JavaScript Functionality<\/a>\n <\/li>\n
      4. \n Building a TODO App from Scratch \u2014 Step 4 \u2014 Styling & Interactive Choices<\/a>\n <\/li>\n
      5. \n Building a TODO App from Scratch \u2014 Step 5 \u2014 Extra Functionality<\/a>\n <\/li>\n <\/ol>\n <\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

        I find it fascinating how websites come to be. Especially websites with user interactivity and functionality, there are so many things to plan, build, and maintain, that it’s no wonder it easily makes for a whole career. Perhaps one of the most clich\u00e9 introductory things to build on the web (or otherwise), is a to-do […]<\/p>\n","protected":false},"author":1,"featured_media":808,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[24,6],"class_list":["post-794","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","tag-design","tag-todo"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2024\/02\/TODO-thumb.jpg?fit=1000%2C500&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/794","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/comments?post=794"}],"version-history":[{"count":16,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/794\/revisions"}],"predecessor-version":[{"id":913,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/794\/revisions\/913"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media\/808"}],"wp:attachment":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media?parent=794"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/categories?post=794"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/tags?post=794"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}