I am trying to design the user interface of a program that tracks recurrent activities and the daily progress. "Done-not done", like a daily to-do-list.

What's the best experience for the user when they first load the program? The options I thought about are:

  • Make everything grayed out except "today"

  • Allow the user to add tasks in the past and marked it as done, but not allow this in the future

  • Allow them to create a list today and make it visible in the past

I wanted to hear some thoughts on:

What is the best way to give the user freedom and flexibility without making it too complicated (i.e. adding start date, end date, "do you want to copy this list to the past?", etc)

When it's a recurrent task, i.e. go for a run in the mornings, would the user need to have a start date, log past dates? or is it bad ux to say "sorry, you bought this program today, and today your tracking starts".

enter image description here

  • Are you making an assumption that all recurrent activities take place on each day of the week (including weekends)? What if it's the 18th and I want to add a task reminding me to send gas meter readings on the 1st of each month? What if I don't shower on weekends? – Izhaki Aug 27 '13 at 23:08
  • It's supposed to track habits so ideally, you should shower everyday :) but yes perhaps having the setting of "specific days of the week" it's required to give a good experience – Rosie Aug 28 '13 at 15:37
  • What's the focus of the application? A list of tasks that happen everyday, where most user interaction is to check/uncheck tasks. Does the application support a requirement such as "Johnny wants to add a task for Saturday, reminding him to call and say happy birthday to his mum". – Izhaki Aug 28 '13 at 16:47
  • No, it's a habit check to keep the motivation. So it creates a "chain" if you don't stop your routine. – Rosie Aug 28 '13 at 20:27

There are a number of things you need to consider, and a number of them depend largely on the Goal of your application and more importantly the users. It's definitely not a good experience to pop up a message saying, no you cannot add to the past OR future, but the important question here is, how often will your users attempt to do it? And if they do attempt it on a large scale, then there is no reason why you should NOT allow it in the first place.

A little more about your application will help a great deal in answering this question. Are all your tasks recurring? Is the application for keeping track of progress? In which case allowing to add to past dates should be allowed.

Simply put, for recurring tasks, you need a start date and an end date, or n occurances, and frequency. The default could be current start date and never ends. You can restrict marking tasks in the future as done, but is there a reason to not allow adding tasks to future? What if I want to add my classes as recurring which start next week?

This might not be a very helpful answer, but knowing your users, and the ultimate goal of the program will help you better decide on the ux.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.