ideas for developing the app's time capabilities #4477
Comments
|
Good news! The following features are in the works/requested: -Push notifications The others should be requested on Trello. Unfortunately, we will not be If your Daily should not be due on the day it is usually due, you can Thanks for your feedback! On Sun, Jan 4, 2015 at 8:47 PM, sadanyagci notifications@github.com wrote:
|
|
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. |
|
@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. |
|
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. |
Stuff I'm interested inAlarms: 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 aboutRevamping 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. |
|
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. |
|
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? |
Revamping Timing and Changing DailiesSo, 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
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. AlarmsI'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 filtersYour 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. ConclusionI'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. |
|
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! |
Revamping Timing and Changing DailiesI'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 todosI 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. AlarmsThat's a huge limitation. Why can't the server determine what it's talking to and respond accordingly? Mockup and filtersThat 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. |
|
FYI, I was just notified that we have a HabitRPG dev working on push notifications/alarms already. |
|
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. |
|
@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. |
|
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. |
|
It sounds like this suggestion from @crookedneighbor in one of his comments above is relevant: |
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.
The text was updated successfully, but these errors were encountered: