ideas for developing the app's time capabilities

[sadanyagci]

I have several ideas for developing the app's time capabilities, that I wish to implement (I've set up the system locally and started looking through the code). I'm posting them here for comments before jumping in and changing things. Comments and criticism are appreciated. :-)

I find this app is very useful, but utterly fails in scheduling. Flopping over EVERY task at a time when the majority of people are sleeping is kind of ridiculous. Not allowing people to check off things they forgot to check off yesterday is also a fatal flaw. It feels horrible to have a perfect record and then wake up in the morning finding that you have to cheat the system by changing your streaks manually, just because you forgot to check some things off before you fell asleep. What if you don't remember which ones you didn't do, and which ones you did? What if you just see you lost 4 health and don't know why? Add to this the fact that this app is about building good habits, and one good habit is scheduling rather than making endless overwhelming to do lists. Seriously, this app needs the option of scheduling your day and getting reminders. People need to be able to have this app bug them about doing things. Right now it has the "out of sight, out of mind" problem as long as the person isn't staring at the app. I propose a fix for this.

1. Revamping timing. Remove daystart, and replace it with windows of opportunity to do a task. Default for a daily would be that day, midnight to midnight. Instead of setting daystart, a person can change their default task to have a window of what ever the person wants it to be. Want it to flip at 3am? Set it for 3am to 2:59 am. Want it to not show up until 6am, and flip at 9pm? Default window of 6am to 9pm. Could also set an ideal, and early, and a late range, as well as an expected duration of task. This way A: people are forced to think logically about how much time they have to devote to a task, and B: people get more points for getting done early, less for getting done late, and still lose blood for not getting done at all and the task expiring.
2. Change dailies. Dailies don't really work 100%. Life is more messy than that. Sometimes you make a note to take out the trash every week on Saturday, but then you go on vacation and can't take out the trash. It's dishonest to check it off, but it's wrong to lose health for it and break your streak. Also, what if you need to reschedule it one week, to Monday, because of flooding? My idea for this is to merge dailies and todos, and make them a bit different. Every daily would have a rule about how often it's done. Right now the system in place is you choose what days of the week. Replace that with strings that translate into math rules. Leave the current display of days of the week for now, but add an advanced checkbox for showing a text box for typing in a string of rules for when the event repeats (strings similar to how apps like todoist do it, though that can be made more user-friendly). This way any task can be made to repeat at any time and in any way the person wishes, past tasks can be reused instead of remade into dailies when you realize you need to do them again and again. Make main tasks able to hold child tasks. The child tasks are the same as the parent task unless explicitly stated. This saves space on repeats and allows people to plan ahead for problems they forsee. Example:
   • Tasks:
     • site default: every day from 12:00am to 11:59pm
     • user default: from 7am to 9pm
       • Task 1: every saturday except US holidays
       • Task 2: every sunday by 3pm
       • Task 3: from 9am to 10am lasting 25 minutes
       • Event 23: deleted
       • Event 25: at 4pm
       • Event 58: Note: in conference room B
   • This translates to:
     • site default: every day from 12:00am to 11:59pm
     • user default: every day from 7am to 9pm
       • Task 1: every saturday except US holidays from 7am to 9pm
       • Task 2: every sunday from 7am to 3pm
       • Task 3: every wednesday from 9am to 10am lasting 25 minutes
       • 23rd recurrence: skip 2014/1/7
       • 25th recurrence: 2014/1/14 at 4pm lasting 25 minutes
       • 58th recurrence: 2014/6/21 from 9am to 10am lasting 25 minutes. Note: in conference room B
3. Calendar. Allow people to view by day (showing times), week, or month. This way they can schedule ahead of time. Force people to acknowledge that they did bad by clicking a red X. This way a person can acknowledge what they didn't do without the task vanishing on them, and they get to check things off if they forgot to when they completed the task. Plus they can see their past mistakes. Past failures can drive a person to never do it again. Letting the task vanish eliminates that reminder.
4. Alarms. People need reminders. Email reminders, SMS reminders, or push notifications would be great. This removes part of the "out of sight" issue. This can either be done with an addition to the app or with google calendar integration, which I noticed is on the list to be worked on. Implementing both would probably work out best in the long-run.

[lemoness]

Good news! The following features are in the works/requested:

-Push notifications -Record Yesterday's Activity

The others should be requested on Trello. Unfortunately, we will not be able to combine Dailies and To-Dos, as that would greatly change a component of the app that most of our users find very useful.

If your Daily should not be due on the day it is usually due, you can disable it under the edit screen or switch it to a different day.

Thanks for your feedback!

On Sun, Jan 4, 2015 at 8:47 PM, sadanyagci notifications@github.com wrote:

I have several ideas for developing the app's time capabilities, that I wish to implement (I've set up the system locally and started looking through the code). I'm posting them here for comments before jumping in and changing things. Comments, criticism, and help are all appreciated. :-)

I find this app is very useful, but utterly fails in scheduling. Flopping over EVERY task at a time when the majority of people are sleeping is kind of ridiculous. Not allowing people to check off things they forgot to check off yesterday is also a fatal flaw. It feels horrible to have a perfect record and then wake up in the morning finding that you have to cheat the system by changing your streaks manually, just because you forgot to check some things off before you fell asleep. What if you don't remember which ones you didn't do, and which ones you did? What if you just see you lost 4 health and don't know why? Add to this the fact that this app is about building good habits, and one good habit is scheduling rather than making endless overwhelming to do lists. Seriously, this app needs the option of scheduling your day and getting reminders. People need to be able to have this app bug them about doing things. Right now it has the "out of sight, out of mind" problem as long as the person isn't staring at the app. I propose a fix for this.

1.

Revamping timing. Remove daystart, and replace it with windows of opportunity to do a task. Default for a daily would be that day, midnight to midnight. Or instead of setting daystart, a person can change their default task to have a window of 3am to 2:59 am. Or a default window of 6am to 9pm. Each task can have a window of what ever the person wants it to be. Could also set an ideal, and early, and a late range, as well as an expected duration of task. This way A: people are forced to think logically about how much time they have to devote to a task, and B: people get more points for getting done early, less for getting done late, and still lose blood for not getting done at all and the task expiring. 2.

Change dailies. Dailies don't really work 100%. Life is more messy than that. Sometimes you make a note to take out the trash every week on Saturday, but then you go on vacation and can't take out the trash. It's dishonest to check it off, but it's wrong to lose health for it and break your streak. Also, what if you need to reschedule it one week, to Monday, because of flooding? My idea for this is to merge dailies and todos, and make them a bit different. Every daily would have a rule about how often it's done. Right now the system in place is you choose what days of the week. Replace that with strings that translate into math rules. Leave the current display of days of the week for now, but add an advanced checkbox for showing a text box for typing in a string of rules for when the event repeats (strings similar to how apps like todoist do it, though that can be made more user-friendly). This way any task can be made to repeat at any time and in any way the person wishes, pa st tasks can be reused instead of remade into dailies when you realize you need to do them again and again. Make main tasks able to hold child tasks. The child tasks are the same as the parent task unless explicitly stated. This saves space on repeats and allows people to plan ahead for problems they forsee. Example:

Tasks: ->default: every day from 7am to 9pm ->Task 1: every saturday except US holidays ->Task 2: every sunday by 3pm ->Task 3: from 9am to 10am lasting 25 minutes ---->Event 23: deleted ---->Event 25: at 4pm ---->Event 58: Note: in conference room B

1.

Calendar. Allow people to view by day (showing times), week, or month. This way they can schedule ahead of time. Force people to acknowledge that they did bad by clicking an X rather than a check. This way a person can acknowledge what they didn't do without the task vanishing on them, and they get to check things off if they forgot to when they completed the task. Past failures can drive a person to never do it again. Letting the task vanish eliminates that reminder. 2.

Alarms. People need reminders. Email reminders, SMS reminders, or push notifications would be great. This removes part of the "out of sight" issue. This can either be done with an addition to the app or with google calendar integration, which I noticed is on the list to be worked on. Both would probably work out best in the long-run.

— Reply to this email directly or view it on GitHub https://github.com/HabitRPG/habitrpg/issues/4477.

[sadanyagci]

I wasn't suggesting changing the dailies component of the site in the way you are suggesting. It would still function the same. It would just have additional capabilities. It would also eliminate the need for such extensive usage of cron, which I have read is one of your performance issues.

I wasn't giving feedback. I was asking for feedback on changes I would like to make. I'm not looking to request others make changes for me. I was looking to contribute to the site with code. I was hoping since this site is open source that I could discuss this with other site designers. Your message is basically putting me off bothering, just like this sites limitations are putting me off using it.

[lemoness]

@sadanyagci Ah, I see! I'm sorry about that, I didn't realize that these were changes that you were hoping to make yourself. We frequently get inundated with requests for changes from users who want programmers to implement the changes for them, and the standard practice is to redirect to Trello so that ideas can be discussed there by all users and then brought to Github only when a concrete change is going to be made. While conversations on Trello may seem slow-moving, they are all read and taken into account when a corresponding Github ticket is finally created.

I'm reopening this ticket so that a programmer can look through it and decide whether or not there are any ideas here that can be implemented in their current form, or whether it is best to workshop them in Trello first.

[sadanyagci]

That's alright. I can definitely understand being accosted by people recommending you do what they want rather than offering help. Thank you for reopening the ticket. :)

I'm wanting to offer my help on coding the site in general. These are the things I thought would be best to look into first. I have other ideas as well. The basics of this just seemed to be the most foundational, least amount of change from a user perspective, the most benefit from a user perspective, and the most benefit from a future feature implementation perspective.

[crookedneighbor]

Stuff I'm interested in

Alarms: Particularly the push notifications. I think that could be a great feature. Here's a Github ticket if you want to add something to the conversation/start working on it.

Calendar: A calendar view is intriguing. There could be modes to see everything, just upcoming events, history (of when habits were clicked, dailies completed or left incomplete). I'd want to see some kind of mockup though, and a more thorough explanation of how you'd implement this.

Stuff I'm concerned about

Revamping Timing and Change Dailies: I think your ideas for setting time constraints on a per task basis are intriguing, and worth exploring, but I'm concerned that they don't take things like Quests into account. How will your system fit into that framework?

"My idea for this is to merge dailies and todos": Those words scare me. It would radically change the user experience of the site, in a way that I can see being unhelpful for the majority of users we have. I like having the dailies separate from the todos.

You followed up that post with another that says "I wasn't suggesting changing the dailies component of the site", so it's possible I misunderstood what you meant by that, so would you mind parsing out your meaning? If possible, mockups might helpful too.

[sadanyagci]

Revamping Timing and Change Dailies: I assume you're referring to daystart being used in quests, in which case use the equivalent default task value, either the start or end number. Any dailies would be counted based on the day they expire, based on that default task time that is equivalent to daystart. Would this solve the issue? Are there any other quest issues in this area?

"My idea for this is to merge dailies and todos": The only difference between a daily and a todo is a daily repeats. If an item has no instructions that make the task repeat, it's handled as a todo. If it does have instructions that make it happen repeatedly, it's handled as a daily, and its sub-events appear on the calendar in the way todos are displayed. Sub-events can be customized as if they are individual todos, but have the same task name. Sub-events would be auto-calculated based on the daily's data, for the calendar, and only have information saved in the database for a specific event if the person specifically changes something (other than the name, which is unchangable). This way there is still a difference between todos and dailies, exactly the same as exists now. This would simply expand functionality without interfering with the user experience in this particular area.

Alarms: I would personally go with implementing google cloud messaging for this kind of communication. Now that I think of it, though, rather than push notifications, a service similar to the android alarm clock app's popup alarm would work better. It's a dialog with a ringtone that wakes the phone up from sleeping. You would only need the service to communicate with your server if the server has alarm information to update the phone with. It wouldn't need an always-open connection, so I don't see how there would be additional performance issues on either end.

Calendar: I could do some mockups of the calendar idea. I'm not well versed enough with the site code to explain exactly how I would implement it. From a user perspective, I would have a page that is taken up by a calendar, with the option of viewing yearly, monthly, weekly, and daily. It would also have an expandable list of un-scheduled events that can be dragged and dropped where you want them on the calendar, similar to organizing events in the lists. Filters would work on this page, and other filtering options would also be available. Buttons for tasks would only be visible if there isn't a whole lot of clutter on the page, meaning no buttons on yearly and monthly pages (only allowing you to click on the task itself to view/edit by popup). Day and week viewing would have the normal task buttons. Dailies would be separated from todos with a circling arrow icon.

[sadanyagci]

While I was starting making mockups I had this idea I just had to bring out. What do you think of this calendar page idea?

[crookedneighbor]

Revamping Timing and Changing Dailies

So, would your calculations for quest damage cascade throughout the day depending on when the timeline for the specific task resets? IE, at 9am I damage the boss for completing task "foo". At 11am I damage the boss for completing task "bar". At my specified day start I damage the boss for everything that doesn't have a task specific time?

Or would you calculate the damage together and apply it all at once after dayStart, and just not include the stuff that has a custom due time after dayStart (those would be applied to the following day).

Is that correct? Or do you have another plan/idea?

My idea for this is to merge dailies and todos

The only difference between a daily and a todo is a daily repeats.

Strictly speaking, that's not quite accurate. Todos don't inflict damage on you the next day if you don't do them, even if they have a due date. Likewise, boss damage to the party is calculated by undone dailies, not todos. In addition, completing todos regenerates some mana (although I believe a change is being discussed to allow dailies to regenerate mana too).

Because of those differences, there should be a clear visual separation between the two. You suggested a swirling arrow icon for the calendar view. I think that's a good representation for a daily. In the non-calendar view, let's call it list view for now, the dailies and todos should still be separated.

You might also want to take a look at this ticket for monthlies. I don't think any consensus has been reached. One idea was to convert dailies into regularly repeating events, and allow todos to repeat at irregular intervals. For instance, you might have a task that needs to be completed once a month. That would become a todo. Another task you might need to complete on the third day of each month, that would become a daily (or whatever we'd end up calling it).

Again, nothing has been decided for sure on that, so there's still time to input new ideas.

Alarms

I'm not familiar with that service, but keep in mind that whatever system gets put in place should be cross platform: Web, Android, iOS.

Mockup and filters

Your mockup looks interesting. Do you have plans for how that would degrade for smaller screen sizes like tablets and mobile phones? Or would that view only be available on desktops of a certain size?

I'm very interested in being able to have more complex filters. IE, todos with due dates between January 1st and February 2nd. Show only red todos. Of course, we get enough bug reports of people saying all there tasks have vanished, when the real reason is a tag is enabled. (sometimes out of no fault of the user) So, maybe additional filtering is not a great idea unless we can think of a really good UX way to present what's happening.

Conclusion

I'd post your ideas that radically change the nature of the site as a request on Trello. It'll get voted on by the community there, and if it gets accepted, we can officially sanction that change. You should mention in the feature request comment that you're willing to write it yourself (as a reminder to us).

For your ideas that expand upon already accepted features, I'd comment on those particular tickets or submit PRs if the route to go has already been decided upon.

[crookedneighbor]

One other thing, while your idea is being discussed on Trello, I'd encourage you to take a look at some existing issues and submit PRs for them. That'll be a good, easy way to get acquainted with the code base!

[sadanyagci]

Revamping Timing and Changing Dailies

I'd recommend damage still be based on dailies that fall within the range of a certain daystart. This would be functionally the same as it is now. The only difference is a person could mark it off after-the-fact, and as long as their party is still in the same calculable situation, the damage would be undone (in case they did the task but didn't mark it off in time).

My idea for this is to merge dailies and todos

I can accept that a task's start and end range could be set for an entire month, though a task like that would probably need sub-tasks or at least trigger following tasks (if this task done, show that task, but that's a whole other possible feature).

I agree that in list view dailies and todos should be kept separate. Single events and repeated events are nice to see separately, after all.

I'd say that as long as an event is a single event, it's a todo. If it has multiple events, it's a repeater, which is a better term for dailies. This would make determining what's what easy, as users would have to be able to easily predict whether what they add is a repeater or a todo. Simple and intuitive is best in such a case. If I add a task I should know what it will be without thinking of a bunch of rules. This will also make determining the difference simple from a design standpoint. If subtask, then daily, else todo.

Alarms

That's a huge limitation. Why can't the server determine what it's talking to and respond accordingly?

Mockup and filters

That idea is pretty raw. I'd imagine on the web you could zoom in and out for different time ranges and to view more tasks. I'd also imagine you being able to scroll it back and forth, and it auto-scrolling, just like when you click the gps button on a map and it centers on you and follows you. On phones I'd say it should span the width of a sideways screen. Tasks should vanish if it's too crowded. Filtering done by the menu button bringing up options, and the filters option bringing up a popup. Zooming done the same as on maps.

I'd say when I was trying out todo apps, todoist had the best filtering system, which is similar to gmail's filtering system. Make it so you can change filters by clicking a button (presaved, default, or label filter), or you can use a menu with individual options clearly displayed, or you can type in a text box exactly what you want, in as simple or advanced a way as you want. That way people can learn the advanced by observing the simple, or they can look up tips and tricks. Add all requested search features as long as you can make them work and assign them a type of string that simply and clearly interprets into the calculation.

[crookedneighbor]

FYI, I was just notified that we have a HabitRPG dev working on push notifications/alarms already.

[sadanyagci]

What radically changes the nature of the site? Default functionality would remain exactly as it is now, and the only difference would be people will have more options, which the behavior of those options still wouldn't radically change any feature currently implemented.

[Alys]

@sadanyagci Radical changes can include additions of new features, even if existing features aren't modified. One of the reasons is that new features aren't completely without overhead, even after they've been created; there's code that needs to be maintained if other site changes affect it, user documentation that needs to be written, and support time whenever users have questions about the new features. Hence a new feature would only be desirable if there was sufficient demand for it, otherwise the ongoing effort required to support it might not be balanced by its usefulness. When a new, large feature is discussed on Trello, we can discover how much demand there is for it, and we can learn from people's comments about how it can be implemented to be of the greatest use to the greatest number of users.

For your suggestions that aren't close to existing feature requests, I do recommend that you mention them in Trello. It's the best way to start the process of deciding whether we should go ahead with them.

[sadanyagci]

Windows of opportunity seem covered by accepted suggestion "Due Dates".

Changes to dailies seem to be covered in several parts by accepted suggestion "Dailies v3" (implementing "Does not apply", "mark daily incomplete" and "weekly rollover"), and accepted suggestion "ADD REPEAT EVERY __ DAYS/WEEKLIES/MONTHLIES TO HABITRPG.COM"

Time scheduling falls under accepted feature "Premium: Timer" and currently being implemented Alarms.

I'm not worried about implementing calendars right now. I thought they would be a future feature to discuss, as it would be more difficult to implement, however google calendar integration has already been accepted.

I merely brought up the way to do these things ideally, and offered myself to do them. I don't think voting would be useful about how to implement changes to the underlying mechanics when they already voted that they wanted the surface features that result from those changes.

[Alys]

It sounds like this suggestion from @crookedneighbor in one of his comments above is relevant: "For your ideas that expand upon already accepted features, I'd comment on those particular tickets or submit PRs if the route to go has already been decided upon."