Gameification (motivational) features and virtual assistant

[nekohayo]

I haven't got a completely clear idea of what I'd want here, but this is a ticket so that people can help brainstorm (and more importantly, implement) a potential "gameification" (aka "motivational" or "achievements") plugin. It would also depend on #424. It could also be somewhat related to the "Untouched tasks" plugin and "Hamster" plugin, too.

The idea is simple: GTG could encourage/reward the user for accomplishing tasks, by congratulating them and unlocking badges of honor (a.k.a. "achievements" or "ranks" or "titles") or something, like you find in many games today. Maybe with standard (but low-priority/ephemeral) freedesktop notifications (and if we want to be extra obnoxious/funny, an optional sound to accompany it), and maybe with a dashboard UI where you can see your achievements/titles/trophies. Heck, it could even use humor in the notifications for some particular corner cases, for example "Double-kill", "Multi-kill", "M-M-M-MONSTER KILL" (for oldschool Unreal Tournament fans, when accomplishing a bunch of tasks at once or in rapid succession within seconds/minutes) or "C-C-C-C-C-COMBO BREAKER" (for oldschool K.I. fans, when dismissing or deleting a bunch of tasks at once).

Of course that would totally be plugin territory, because it's not a critical feature to have, and maybe even some/many users (boring adults) would find that ridiculous :)

I guess the plugin could be looking at:

• Certain numbers of closed tasks "of all time"
• Numbers of closed tasks in particular time periods (in a day, in a week, in a month), aka velocity. Normally, most people can only accomplish 1-3 things per day, unless they're really small things (see this and that for example)
• Accomplishing a very long-standing task or project (creation vs closed date)
• Accomplishing a task or project that you've procrastinated too much on (i.e. that you used the "Do it tomorrow" button too often on!); but that would require saving/storing new data in the data format, a counter of how many times a task has been deferred...
• Maintaining or increasing velocity compared to the last week or month or something
• Accomplishing a big project (i.e. a task with lots of subtasks); see also #245
• Depending on the time of the day (i.e. time remaining before the end of the work day, or before the end of the night, depending on user preference) encourage people to accomplish "one more (easy) thing", to trick your mind into productivity the same way it tricks itself into procrastination
• Mass-closing many tasks at once (whether because they've all been solved in a fell swoop, or because they don't need to be done anymore, or because the user has the fortitude to reevaluate their priorities and say "no" to things).
• What else can you think about?

The gameification plugin could also serve as a basis for a complementary "A.I. assistant" feature that reminds you of important tasks to do due today that are not currently visible in the current view (because you're in a different tag view or something), or that a particular important task has been sitting around for too long (is it because you don't have time, don't have energy, are procrastinating, or simply because it hasn't been clearly fleshed out into actionable steps?), etc. Someone on IRC also mentioned that someone should study a bit how the "Momentum" app does things, though I guess we'd need to handle this in a much more traditional UI.

Anyhow. This is a big project, but also a fun project... but I'm not going to do implement it myself, and it's not a core feature, so simply filing this idea as a "patch-or-wont-happen" ticket to inspire potentially new plugin writers to work on this.

[diegogangl]

Habitica could also serve as inspiration: https://habitica.com/static/home I would also love this, it's another way to look at productivity and help you score small wins to keep momentum.

[johnnybubonic]

(was asked by @nekohayo for review on IRC)

While I certainly love the concept of this as it definitely appeals to me self-competitive nature, I don't have much in terms of ideas of implementation. I think some of the features should probably be split off to separate plugins as they aren't dependent on #424 and would simply complement this concept while providing serious value to other users without needing the lighthearted approach:

• "Accomplishing a very long-standing task or project (creation vs closed date)"
  • This "pat-on-the-back" sort of thing wouldn't need an archive, just check the creation date upon closing event and comparing it to n days/whatever.
• "Accomplishing a task or project that you've procrastinated too much on (i.e. that you used the "Do it tomorrow" button too often on!); but that would require saving/storing new data in the data format, a counter of how many times a task has been deferred..."
  • With #279 in discussion, now would be the time for it though. :) It's just a simple addition of an optional attribute with type xs:positiveInteger as far as the schema goes, but the schema's the easy part. It's the code that would see some (relatively) hefty addition.
  • Though remember that the data format can store data that the code doesn't know about yet. No pressure to implement both at the same time as long as it makes it into the data format before/at the same time as the code's parsing.
• "Accomplishing a big project (i.e. a task with lots of subtasks); see also #245"
  • This should also be an easy enough check; you can do a len() on the number of subtask children (subtasks/sub) a task has at closing time with the changes #279 brings.
• "Depending on the time of the day..."
  • This provides way too much value to NOT be split off to a separate plugin, I think. This one's a powerful one.
• "Mass-closing many tasks at once..."
  • I think bulk operations (not just close/delete.. maybe bulk changing the due date, for instance, as well etc.) would be super useful as a core feature, honestly.

That's just my $0.02.

[nekohayo]

I think bulk operations [...] would be super useful as a core feature, honestly.

You can already do stuff in bulk, in theory, simply by selecting multiple tasks in the main window (combined maybe with the search feature) and using the contextual menus for that. It works pretty well for me at least!

[johnnybubonic]

oh! thanks! i had no idea!

[digitalethics]

The best realization of gamification features I have seen in any app are in Productivity Challenge Timer. There is a quick review on YouTube.

[zeddo123]

Hi, Should the plugin have everything related to gamification?

We should discuss the look and the placement of the plugin. My inspiration is todoist which has a special menu for the 'stats' and I would like to make it more gnomish. What do you think?

My main focus are these features (leave any other feature that is more important):

• Streak counter (counts the number of day the user has achieved his target number of tasks)
• Ranking system (amateur...master)
  • the user gets points when he/she marks a task as done (depending on the task, the number of points could change)

I have chosen the generic name of gamify for the plugin so if you have a better name, please leave your suggestion.

[diegogangl]

Should the plugin have everything related to gamification?

TBH I don't have a very clear answer yet. I think at least this plugin should handle everything related to "game-like" features. For instance:

• Scores
• Notifications / feel good messages when you do all the tasks
• Streak counters

I think the biggest issue you would run into is that we still don't save any kind of stats. If you want to work on this now, we'd have to come up with some MVP that we can do now. For instance, we can figure out how many tasks were done today and how many are left right now by looping through both open and closed tasks. It's slow and tedious, but it can be done.

Alternatively, you could create a separate XML for this plugin to store custom data. Then when a task is closed the plugin gets notified, and it writes closed + 1 to its own file. Updating the streak, etc.

[zeddo123]

Alternatively, you could create a separate XML for this plugin to store custom data. Then when a task is closed the plugin gets notified, and it writes closed + 1 to its own file. Updating the streak, etc.

Yeah, I think that this solution is better.

One more thing, should I make the hamburger menu (in the Main-window) a stack? so that it could hold all the plugin's functionalities in a separate page

[digitalethics]

A secondary separate XML for data storage has also been proposed in the related #424 task.

[digitalethics]

I also like the simplicity of the task counter in GNOME To Do as a more minimalist motivational feature. What do you think? @zeddo123

[zeddo123]

Hi @digitalethics , I have been trying different designs this week and I not sure I like any of the one that I came up with.

Anyway, I really like the minimalistic design might create something like it. However, the issue is that I am doing the other features like the levels which makes the menu not simple.

[EDIT] Here is a screenshot, any recommendation is welcome!

[nekohayo]

This looks pretty cool! I'll have to try it out when I get back to my testing machine. Some random questions & ideas for @zeddo123 in the meantime:

• Any reason why the text in your button seems to be in bold type, vs regular?
• Have you considered an alternative where daily progression is represented by a GTK LevelBar widget in "discrete" mode (instead of continuous; see screenshot below), squeezed somewhere either between the headerbar and the rest, or maybe above or below the quick-add bar? It might be more minimalistic, this might look great or it might look terrible in practice in the GTG UI, I have no idea, just throwing the idea out there :) of course that also potentially makes the interaction a bit less obvious than a Gtk Button, i.e. it might rely on a GtkTooltip and showing the popover when clicking the levelbar or something...

The levelbar, in addition to allowing discrete chunks, allows having different colors depending on fill levels. And apparently that weird widget still exists in GTK4.

Here's an excerpt of some old code I had in some file I experimented with 7 years ago (I could email you my files if you're interested):

self.levelbar = Gtk.LevelBar()
self.levelbar.set_min_value(0.0)
self.levelbar.set_max_value(10.0)
self.levelbar.set_orientation(Gtk.Orientation.HORIZONTAL)
self.levelbar.set_mode(Gtk.LevelBarMode.DISCRETE)
#self.levelbar.set_inverted(True)
self.levelbar.add_offset_value(Gtk.LEVEL_BAR_OFFSET_FULL, 8)
self.levelbar.add_offset_value(Gtk.LEVEL_BAR_OFFSET_HIGH, 6)
self.levelbar.add_offset_value(Gtk.LEVEL_BAR_OFFSET_LOW, 3)
some_box_object.add(self.levelbar)
self.levelbar.show()

The thing with the levelbar is that in theory you're supposed to be able to have as many custom colors as you want, with CSS, but I never managed to get this stuff to work, I never could quite figure out how it actually works:

.level-bar.fill-block.level-green{ background-color: green; }
.level-bar.fill-block.level-yellow{ background-color: yellow; }
.level-bar.fill-block.level-orange{ background-color: orange; }
.level-bar.fill-block.level-red{ background-color: red; }
.level-bar.fill-block.empty-fill-block{ background-color: pink; }

self.levelbar2.add_offset_value("green", 7)
self.levelbar2.add_offset_value("yellow", 8)
self.levelbar2.add_offset_value("orange", 9)
self.levelbar2.add_offset_value("red", 9.5)

Just my 2¢ in case that helps somehow.

[zeddo123]

Any reason why the text in your button seems to be in bold type, vs regular?

I was trying to differentiate the text. However, there is no bold text anymore. You should take a look at the screenshots of the PR. here's one

Have you considered an alternative where daily progression is represented by a GTK LevelBar widget in "discrete" mode (instead of continuous; see screenshot below), squeezed somewhere either between the headerbar and the rest, or maybe above or below the quick-add bar? It might be more minimalistic, this might look great or it might look terrible in practice in the GTG UI, I have no idea, just throwing the idea out there :) of course that also potentially makes the interaction a bit less obvious than a Gtk Button, i.e. it might rely on a GtkTooltip and showing the popover when clicking the levelbar or something...

I actually started designing a UI with the GtkLevelBar in mind from one issue you've opened (can't remember which) but as I'm not that good with UIs, in general, my use of the widget wasn't good. So I ended up doing it the simple way. Nonetheless, the idea of it being underneath the Quickadd entry is interesting. I will try to implement it to see it how it looks.

We could also have a setting in the plugin to enable/disable one or the other (GtkLevelBar or the button on the top) for people who want the discreteness of the LevelBar.

[nekohayo]

True, if you are OK with the slightly higher code complexity, having an option in the plugin's settings to choose between the two approaches could make people happy :)

[zeddo123]

Here's who it turned out. I like it, it's discrete and elegant.

[noahfrederick]

@zeddo123 Looking good.

Have you tried positioning the LevelBar above the quick-add bar so as not to displace it vertically? It might be better to keep the interactive element (the quick-add bar) at the edge of the window, which makes it easier to target with the mouse.

Also the lack of padding around the LevelBar strikes me as odd looking.

[zeddo123]

Have you tried positioning the LevelBar above the quick-add bar so as not to displace it vertically? It might be better to keep the interactive element (the quick-add bar) at the edge of the window, which makes it easier to target with the mouse.

I've try your suggestion for putting it on top. Although I share your concern about the quick-add, I feel that the buttom area becomes a bit too bolky when putting it on top.

Also the lack of padding around the LevelBar strikes me as odd looking.

Thanks for pointing that out. I added some padding (could use some help on the amount). Your opinion is much appreciated.

[noahfrederick]

I feel that the buttom becomes a bit too bolky when putting it on top.

Yeah, I see what you mean. I might suggest one more option, which is placing the LevelBar on top on a white background so that it matches the background of the task list. I think this might reduce the bulky effect, but it might also look confusing. Not sure.

I added some padding (could use some help on the amount).

Matching the left/right padding of the quick-add bar as you've done feels right to me. The spacing between the quick-add bar and the LevelBar also feels good. I would try adding just a few more pixels of padding below the LevelBar so that the distance between the bottom of the LevelBar and bottom of window is exactly 1/2 the distance between the quick-add and LevelBar, the reason being that there is a bit of visual muddiness caused by so many horizontal borders stacked so closely. Providing a bit more spacing could add some visual clarity, but we don't want to waste too much valuable vertical real estate.

I'm not very familiar with GTK, but another thing I would try, if it's even possible, is to remove the LevelBar widget's border and place it at the bottom of the window with no left, right, bottom padding at all, so that the window's border effectively acts as the widget's border.

[nekohayo]

Since this was implemented in 0.6 and it worked well overall, let's close this for now, new issues can be opened if we find specific remaining actionable enhancements for it :)