Reducing inadvertent "spam" by creating renewable subscriptions (instead of, what are currently, continuous subscriptions)

Feature Discussion
1

For example, in case a user makes many changes in a short period of time to a task (say 6 changes in 28 minutes), to avoid overwhelming other users who have subscribed to that task with notifications, how about implementing the following feature…

Enable each user to choose to only receive one notification for a task which has been modified (changed). That is what I am calling “A renewable subscription.”

A user with a renewable subscription to a task will never receive any additional notifications for that particular task, unless the user indicates he would like to receive more notifications for that task in one of two ways: by renewing his subscription to that task or by continuously subscribing to that task.

I suppose that a user visiting Vikunja will get a prominent notification indicating one or more of his continuous subscriptions have “lapsed” (terminated) with a message such as,

“Unless you click on the ‘Renew my renewable subscription [radio] button, next to the task, or ‘Create a continuous subscription [radio] button’ and then click on the ‘Submit’ button,you will no longer receive any more notifications for the task(s) listed below.

If the user hovers over any part of, ‘Renew my renewable subscription’ or ‘Create a continuous subscription’ he will see a tooltip explaining the difference between renewable subscriptions and continuous subscriptions.

Philosophically, this a compromise of sorts between Pull technology and Push technology. The latter includes this…

The use of unnecessary push notifications for promotional purposes has been criticized as an example of attention theft.

I am not suggesting that users of Vikunja are intentionally spamming other users; however, for subscribers receiving too many notifications, the experience might be tantamount to receiving conventional spam via email.

2

I think it’s a good idea to limit the amount of notifications users get from Vikunja. I fear the system you’re describing is too complicated though, especially for new users (as well as the implementation of it). What do you think about having a “snooze” functionality instead, where users could turn off notifications for some period of time?

3

Call me crazy, but I actually like using things like paragraphs containing actual sentences comprised of things like, I dunno, subjects, verbs, and objects. /s (sarcasm).

In other words, I eschew the software engineering norm of using inane terse commands such as “Snooze” which probably came about due to tiny displays that were difficult to read back in, say, the 1950s and 1960s.

No, I’m not going off on a bizarre tangent.

Here’s how you could make this easy for both Mark Suster’s novice and pro.

Give users a message, which engineers would probably consider, ridiculously long and better placed in the documentation (which, nobody reads, yet devs adore bikeshedding about in, absurd discussions like this Technical Writing Courses https… //news.ycombinator.com/item?id=22652241).

SOMETHING LIKE THE FOLLOWING BELONGS IN THE ACTUAL VIKUNJA APPLICATION, NOT MERELY IN THE DOCUMENTATION

I AM NOT SHOUTING… I AM SCREAMING AT THE TOP OF MY LUNGS!!!

Dear Mr./Miss/Mrs. User,

Notifications can be helpful; yet, notifications can also be overwhelming. Striking a proper balance is often deceptively difficult.

Of course you don’t want to miss an important notification, yet you almost certainly aren’t going to want wake up to 47 emails because Ben or Naomi changed a task, 47 times over the course of, say 5 hours last night.

Therefore, we here at Vikunja World Headquarters (my living room), have decided to follow the sage advice in the quotation generally attributed to Albert Einstein, “Everything should be made as simple as possible, but not simpler.”

Put simply, this is a complicated matter. Therefore, we are going to provide you with many different choices. However, please don’t worry, you can configure all of your choices in, say, 10 seconds right now, or in, perhaps a few hours over the course of, say, a couple of months or even years. It’s up to you. And, yes,of course, you can change your mind.

You can configure notifications for a particular task, a particular user, or globally (for all tasks and all users). Regardless of how you configure them generally, you will be able to customize the notification settings for each particular task

Here’s a 10 second choice…

Always receive an email notification every time, anyone makes a change to a Task

Simply choose that option and will be all done configuring notifications… but, if you actually use Vikunja, we think you will quickly want to change that option because you will tend to get overwhelmed with notifications.

Here’s a 20 second choice… Receive an email notification every time, anyone makes a change to a Task, but not more frequently than every A days, B hours, C minutes, and D seconds [For this I eschew unnecessary pull down menus in favor of allowing users will enter number in manually].

For example, you might choose to Receive an email notification every time, anyone makes a change to a Task, but not more frequently than every 15 minutes.

That way, if Susan were to make 4 changes in 12 minutes, you would only receive one notification.

Here’s a 30 second choice… Receive an email notification every time, anyone makes a change to a Task, but not more frequently than every A days, B hours, C minutes, and D seconds [For this I eschew unnecessary pull down menus in favor of allowing users will enter number in manually], but only send notifications between hour X and hour Y.

For example, you might choose to Receive an email notification every time, anyone makes a change to a Task, but not more frequently than every 45 minutes, only between 7AM and 5pm.

That way, if Mike were to make 6 changes in 1 hour and 20 minutes between 7am and 5pm you would only receive two notifications, but you wouldn’t receive any notifications between 5pm and 7AM.

As you have probably surmised, this follows Mark Suster’s advice Design for the Novice, Configure for the Pro

https… //bothsidesofthetable.com/design-for-the-novice-configure-for-the-pro-b259c6b4662a)

They key thing is having a proper user interface. I envision something that would be a bunch of sentences would could be dragged around to form a series of paragraphs.

It probably sounds incredibly difficult based on the complexity, but I assure you it’s merely a bunch of boolean logic presented in a very user friendly manner.

For example, please take a look at these Trello cards…

https… ://archive.is/wip/f7M8X. (The link is on Medium .com; I used Archive.is to get you past their soft paywall).

The inherent problem with most settings in software applications is this: they normally fail to use parts of speech subjects, verbs, objects, articles, prepositions, etc. They also rarely use complete sentences; and almost never use one or more paragraphs.

I am not talking about documentation; I am talking about linking huge amounts of text as part of the UI/UX (user interface/user experience). Think of Wikipedia. Sure it can be overwhelming, but it doesn’t have to be.

In 20 seconds, an ordinary reader could learn this about bicycles…

https… ://en.wikipedia.org/wiki/Bicycle

A bicycle, also called a pedal cycle, bike, push-bike or cycle, is a human-powered or motor-assisted, pedal-driven, single-track vehicle, with two wheels attached to a frame, one behind the other. A bicycle rider is called a cyclist, or bicyclist.

An expert could go down a “bicycle rabbit hole” for hundreds of hours.

4

I like that idea.

This is actually already planned. Along with some kind of summary at the start of that period summarizing “here’s what you missed” (to be decided whether that should happen via mail or inside Vikunja only).

I like how you’re thinking about UX and how things could be better from a user’s perspective - building user-oriented software is always the end-goal. In your first post of this thread the concept of “renewable” subscriptions sounds a bit unknown and I wouldn’t think that’s something that’s easy to understand for the novices. Framing it the way you did in the second post makes for a much better UX.

Thank you very much for the explanation.

5

This is actually already planned. Along with some kind of summary at the start of that period summarizing “here’s what you missed”

Thanks for letting me know.

(to be decided whether that should happen via mail or inside Vikunja only).

That is a blatant false dichotomy. If you want to become a great engineer, you must not fall into such lazy ways of thinking.

Obviously, instead of “A or B” it should be “A, or B, or (A and B).”

In other words, users should be able to choose to receive notifications by email, in Vikunja, or both via email and Vikunja. As a further refinement, email notifications should not need to be identical to “in Vikunja notifications.”

In other words, users should be able to choose preferences for email notifications that are different from “in Vikunja notifications.”

I like how you’re thinking about UX and how things could be better from a user’s perspective - building user-oriented software is always the end-goal.

Good.

In your first post of this thread the concept of “renewable” subscriptions sounds a bit unknown and I wouldn’t think that’s something that’s easy to understand for the novices.

The man who famously opined, “Imagination is more important than knowledge” was not a fool.

Framing it the way you did in the second post makes for a much better UX.

Frankly, I didn’t want to bother fleshing out how to implement my idea, unless I gleaned you were open to implementing my idea.

Thank you very much for the explanation.

You are welcome.

Fundamentally, engineers tend to implicitly believe users who are non-engineers are fools; I do not. Rather, I explicitly believe that users who are non-engineers tend to have brains that work very differently than engineers.

As a result, when engineers use methods of communicating with users which are tantamount to engineering jargon (for example, using buttons labeled with a single word, instead of an entire sentence) because in general, engineers have become convinced that they must normally create simplistic UI/UX, because users, who are non-engineers, are fools.

If someone were to start speaking to you in Korean or Arabic would you understand what they were saying? From the perspective of non-engineers, many UI/UX they see look similar to a language which is foreign to them.

In other words, engineers tend to mistakenly conclude that users are fools, in cases when users are merely confused. It is easy, and dare I opine tempting, for engineers to conflate “user confusion” with “user foolishness”. You must not do that.

Vis-à-vis most UI/UX problems, instead of education, what is needed is merely translation. The former is often an arduous task; the later is typically trivial. In other words, to solve UI/UX problems, we don’t need to help users surmount Mount Everest, rather we simply need to help them walk up a small hill with a gentle incline.

Below is some food for thought. I hope you will read it carefully. Specifically, I hope you will try to apply Einstein’s “imagination approach” to solving a problem which engineers tend to improperly, unfairly, and, yes, arrogantly and angrily, characterize as, “The vexing UI/UX conundrum” (“How are we supposed to build software for non-engineering users, most of who who are fools?”

“in Vikunja notifications.”

The full famous quote, in context

Although Einstein would go on to write many more influential papers, the discovery of General Relativity would always loom as his most colossal scientific achievement. In 1929, while being interviewed for the Saturday Evening Post by George Sylvester Viereck, the following exchange occurred:

Einstein: “I believe in intuitions and inspirations. I sometimes feel that I am right. I do not know that I am. When two expeditions of scientists, financed by the Royal Academy, went forth to test my theory of relativity, I was convinced that their conclusions would tally with my hypothesis. I was not surprised when the eclipse of May 29, 1919, confirmed my intuitions. I would have been surprised if I had been wrong.”

Viereck: “Then you trust more to your imagination than to your knowledge?”

Einstein: “I am enough of the artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.”

In other words, the first time this quote appeared, it was in the context of Einstein believing that he knew how an experimental/observational result would turn out before it was conducted, on the basis of the previously-established success of his theory. It wasn’t a foregone conclusion, but he chalked up his physical intuition about a yet-to-be-determined measurement to “imagination,” rather than “knowledge,” in response to a leading question from a reporter.