Give users the ability to, at least, globally turn off tooltips

Feature Discussion
1

I suggest that users be able to turn off tooltips, at least globally, if not granularly (one at a time). Novices generally need all of the tooltips; pros none, and somewhat experienced users, probably need some tooltips, yet not all of them.

See what Mark Suster has to say about this…

Design for the Novice, Configure for the Pro

I’ve had a long-standing rule of thumb in product design, which I call “design for the novice, configure for the pro.” I started saying this back in 2001/02, long before the era of Web 2.0, lean startups or even the advent of AJAX.

2

I like that concept. Can’t promise anything about implementing this soon but will keep it in mind.

3

I like that concept.

Thanks for letting me know.

Can’t promise anything about implementing this soon but will keep it in mind.

Considering how much I am paying you, I’m not in a position to make any demands on you.

When you architect new features you intend to code, perhaps it might be helpful, if, generally, you were to include the ability for users to turn such a feature on or off (toggle a feature).

For example, instead of implementing feature X while implicitly thinking, “Feature X is a bright shiny new feature every user will LOVE!”, it might behoove you to implement feature X while explicitly considering something like, “I wonder if any of my users will like feature X. Well, even if some users like feature X, others probably won’t. Therefore, I should give users the ability to toggle feature X (on and off).”

It’s a cognitive shift based on an very important concept… h-u-m-i-l-i-t-y.

In other words, instead of implicitly seeing yourself as Vikunja’s Benevolent dictator for life (BDFL), I am suggesting that you explicitly think of yourself as a humble servant of the users of Vikunja, some of whom are currently your paying customers, and others who will eventually become your paying customers.

4

Yes, we’ve been doing that in the past. Given the current scale of Vikunja, it’s not something I would consider doing for every feature. Each knob adds complexity which has to be maintained, and from a user perspective it gets overwhelming once you have too many options.

5

TL;DR

If your implicit attitude is It’s my way or the highway, then I’ll be on my way.

Criticism

it’s not something I would consider doing for every feature.

I am neither rebuking you, nor being pedantic, yet, if you choose to communicate with me in the future, I would appreciate it if you would keep an open mind. Absolute assertions, such as the one I quoted immediately above, make my blood run cold.

If you choose to communicate with me in the future, I hope you will assert things like , “it’s probably not something I would consider doing for every feature.” The word “probably” might seem like, “no big deal” to you; but it’s a big deal to me.

The overwhelming majority of FOSS engineers with whom I worked, have been arrogant and angry men who craved being a Benevolent dictator for life (BDFL). If you are one of them, then it’s unlikely I will be willing to work with you to improve Vikunja.

Please understand, in such a case I wouldn’t be upset. After all, you didn’t ask for my help. Nonetheless, I don’t intend to squander my time proffering suggestions to you, if indicate you dislike them, yet fail to properly refute their value.

If it had a vastly improved UI/UX, then Vikunja would likely become a much more popular application. Currently the UI/UX Vikunja is too clunky and difficult. It also lacks many features. The UI/UX you have designed for Vikunja thus far is not terrible, but it’s not good. The problem isn’t merely that you haven’t had time; no, the problem is that like most engineers, you are bad at designing UI/UX.

If you were to properly argue against my UI/UX suggestions, and, gasp… actually occasionally defer to my expertise in UI/UX, I could help you to vastly improve the UI/UX of Vikunja.

My argument for “more knobs”

I essentially reiterate Mark Suster’s point: give novices very few knobs; give experts many knobs. That is good advice, which you have essentially ignored in the design of Vikunja and which you have failed to explicitly acknowledge.

Essentially I am talking about feature flags. For a novice, most features would be hidden behind a feature flag; for experts all features would be exposed (no features would be hidden behind a feature flag).

Imagine a user was assigned a scale of expertise for each feature. Imagine the scale began at 1 (novice level) and ended at 10 (expert).

Let’s imagine User 1 has an Expertise of 3 for Feature 6. Tersely we could express that as U1E3F6. In that case, User 1 would see the Level 3 knobs for Feature 6.

Then U2E7F1 would describe User 2 who has an Expertise of 7 for Feature 6; U3E9F5 would describe User 3 who has an Expertise of 9 for Feature 5.

Therefore, U83391E4F9629, would describe User 83391 who has an Expertise of 4 for Feature 9629. In such a case, User 83391 would see the Level 4 knobs for Feature 9629.

Who decides the level of expertises for a particular user, for a particular feature? To make it easier for you, I suppose initially the application would allow the user to manually choose his own level of sophistication for a particular feature.

At some point something like ChatGPT could be used to help automatically determine the levels. Nonetheless, the user should probably always have an option to manually choose his level of expertise for a particular feature.

6

Sorry if that came across wrong, I didn’t mean any harm.

I have to balance and prioritize feature requests, though. If I would simply implement every feature request, Vikunja would look like this:

image
image700×700 87 KB

(maybe less technical, but you get the general idea)

Not every feature fits into something like Vikunja. Broadly speaking, I usually need to figure out the problem users have when they come with a feature request and then find the optimal solution for that. A feature is usually a solution, but from my own experience, users don’t always understand the problem they have and jump on the first solution they get in their head. Which usually is not the best solution to a problem.

Well I could have said “it depends” instead, but that’s not any better I guess.

I know I’m the BDFL here, but not really by choice. The community isn’t big enough and so far, I’m the only one who has been doing this since the beginning.

I hope I didn’t come across as arrogant or mean. If that was the case, I’m sorry - I assume the cultural difference plays a role here as well.

That, on the other hand, is something I would consider arrogant or mean.

Not trying to offend you, but that sounds like what you wrote in the beginning:

7

Sorry if that came across wrong, I didn’t mean any harm.

No problem.

I have to balance and prioritize feature requests, though.

At the risk of seeming like a pompous windbag: I believe that you are not qualified to make such decisions; I am. Generally, capable UI/UX designers are qualified to act as translators or intermediaries between engineers and users who are non-engineers.

If I would simply implement every feature request…

I will be harsh: do not proffer strawman arguments to me. I generally refuse to work with engineers who succumb to that despicable approach of arguing with me.

Not every feature fits into something like Vikunja.

Stop prattling on foolishly. Believe it or not, I am not a complete idiot.

I repeat…

I will be harsh: do not proffer strawman arguments to me. I generally refuse to work with engineers who succumb to that despicable approach of arguing with me.

A feature is usually a solution, but from my own experience, users don’t always understand the problem they have and jump on the first solution they get in their head. Which usually is not the best solution to a problem.

Your inane assertions are dripping with irony. Here, let me rephrase that for you, Mr. Genius Engineer…

> Engineers don’t always understand the problem users have and jump on the first solution they get in their head. Which usually is not the best solution to a problem.

Ummmm, errrrr, wellll… Mr. Genius Engineer… stop blaming users because you are unqualified to make functional architectural solutions. To be sure we are clear, functional architectural solutions subsume UI/UX solutions.

Non-technical users and engineers need someone to act as translator (an intermediary). In this case, that “someone” might be me.

I know I’m the BDFL here, but not really by choice. The community isn’t big enough and so far, I’m the only one who has been doing this since the beginning.

That makes sense to me.

I hope I didn’t come across as arrogant or mean. If that was the case, I’m sorry - I assume the cultural difference plays a role here as well.

Frankly, you came across as arrogant. You are obviously arrogant; however, apparently you don’t realize that you are arrogant. Don’t worry. It’s a common failing, not just for engineers, but for men generally.

That, on the other hand, is something I would consider arrogant or mean.

Don’t be a thin-skinned, arrogant narcissist. My criticism was (and is) valid. In my experience, arrogant narcissists are invariably “allergic” to criticism. In this case, I am not the problem; you are the problem. My criticism is valid; your ignorance is invalid.

Not trying to offend you, but that sounds like what you wrote in the beginning:

I have found that redundancy is often valuable, particularly when arguing with recalcitrant engineers like you.

8

Well I never said I am some kind of genius. I wouldn’t say that about me in any area really. Right now, you come out of nowhere, without any trackrecord, blast me with comments, insulting me and telling me how to do everything better. Sounds pretty arrogant to me.

Given the medium we are using to communicate, I’ll blame this on the tool and maybe cultural difference and not on any of us personally.

I feel like this discussion is now getting out of hand. Please keep this about topics that are related to Vikunja.

1 Like
9

I have read your assertions.

Farewell.