Evaluation or comparison with alternatives (particularly Workrave) could be more efficient

[Chealer]

I was recently informed that an important issue in Workrave could be avoided by using Stretchly instead, which got me to evaluate Stretchly to see if I should replace Workrave with it. As a longtime Workrave user, I was surprised I hadn't heard about Stretchly before it got so mature.

In the end, it took me many minutes to confirm that Stretchly still didn't match Workrave for my needs. As Stretchly and Workrave both address pretty much the same platforms and the same potential users, many more people are likely to "waste" some time in that process. As Stretchly's future is visibly more promising than Workrave's, comparison is likely to only get more difficult unless it is somehow facilitated.

There are 2 possible approaches:

1. Facilitating Stretchly evaluation
2. Providing a comparison with alternatives

I believe the best way to achieve the first approach would be to sort Stretchly issues by importance by default, or at least ensure its ITS allows to order tickets by decreasing importance.

The second approach would be something for Stretchly's website. I suppose it would be best to add a "Compare" page dedicated to that. A basic implementation could be to just link to an issue report which would allow everyone to provide input, like this one. Or a link to a comparison of multiple RSI management utilities, if a fair one can be found. Or, it could be 2 columns, one with each product's advantages.

If Stretchly offers its own comparison with Workrave, it could at least mention the following advantages:

1. Possibility to suspend/pause breaks for a limited time

...as well as the following main disadvantages:

1. Old notifications get stacked
2. The sound when a mini break ends is the same as the one when a long break ends.
3. The end break sound is the same as the sound of any system notification, for example an incoming email (that issue is somewhat treated in ticket #966).
4. There are no usage statistics and there is no history of breaks.

[Chealer]

The README file's Known issues section already takes the first approach, but unfortunately fails to mention several important issues.

[hovancik]

Well, Known issues mention only technical issues (that I am not able to fix) not the usage issues: Each person likes something else so issue for one use is good feature for someone else.

With comparisons, there are many alternatives, not only Workrawe, and to be honest, I am not interested in doing comparisons as I am not checking the competitors at all. For example, AlternativeTo lists over 40 alternatives: https://alternativeto.net/software/stretchly/. Then it becomes: which apps to compare to? All 40? What app should do the comparison? One of them? All of them? What and how to compare?

I guess it's on the user in the end to do the research and figure out what they like, as different people like different things.

[Chealer]

Well, Known issues mention only technical issues (that I am not able to fix) not the usage issues:

If you want to keep a specific list of issues which you are not able to fix, this can be done by having an "Issues in need of technical help" section, which could be a subsection of Known issues.

That being said, as this information is likely not relevant to users, the vast majority of projects rather achieve this using their ITS. A "Help needed" tag can be created and applied to tickets about the issues in question.

Each person likes something else so issue for one use is good feature for someone else.

A list of issues in a program is generally not considered as a list of issues affecting every user, but if you feel that distinction is important, it is perfectly possible to categorize issues, for example in a list of Issues for all users and another list of Issues for specific users.

With comparisons, there are many alternatives, not only Workrawe, and to be honest, I am not interested in doing comparisons as I am not checking the competitors at all.

Just to be clear, unless there is a mention to the contrary, a ticket is not a request for anyone in particular to do a change. It is a report about an issue which can (if we ignore permissions) be tackled by any contributor.

For example, AlternativeTo lists over 40 alternatives: https://alternativeto.net/software/stretchly/. Then it becomes: which apps to compare to? All 40? What app should do the comparison? One of them? All of them? What and how to compare?

I guess it's on the user in the end to do the research and figure out what they like, as different people like different things.

The user will always have to decide what they ultimately want to use. This ticket is about facilitating comparison, and minimizing the research and time users will have to spend in that process. You ask good questions, and I don't have answers as good. If there was a fair comparison between all these alternatives, linking to it would surely be best, but I am not aware of any existing one. However, from all these listed alternatives, RSIBreak is (unless that has changed) specific to GNU/Linux, Time Out is reportedly specific to macOS, and Eyes Relax, Eyeleo, Eye Defender and Iris all have a purpose different from Stretchly (judging by their name). The rest don't even have the tenth of Stretchly's popularity (judging by the "likes" recorded on that site). So Workrave is by far Stretchly's main competitor.

That being said, I shall remind that this ticket is asking to facilitate comparison or evaluation. If you find picking a number of alternatives to compare with too difficult, let's start with facilitating evaluation.

[Chealer]

Is there a reason why this ticket is closed?

[hovancik]

Because I don't plan to maintain any comparison with similar apps section

[Chealer]

@hovancik I see that you may be Stretchly's main contributor, but this does not prevent others from contributing to Stretchly. In fact, someone else may become its main contributor soon. As mentioned previously, this is not a request for you (or whoever would be Stretchly's main developer), nor even any of Stretchly's past developers, to solve the issue.

In fact, this ticket is not even a request at all; it is an issue report. As the issue persists, there is an implicit request to solve it, but the fact that a given developer has no plan to do so unfortunately does not constitute a solution to the issue.

That being said, at the risk of repeating myself, I shall use this opportunity to remind that this issue can be solved by facilitating comparison or evaluation. If you find comparing too difficult, let's start with facilitating evaluation.

[wolftune]

FWIW, I just did some comparison, and I appreciate the value of this, but indeed maintaining comparisons with projects all being moving targets is really cumbersome.

If anyone really works on this, it should IMO prioritize Free/Libre/Open options. That brings down the dozens of programs to just a few: Stretchly, SafeEyes, WorkRave, RSI Break, BreakTimer. And of these, I think really only Stretchly, SafeEyes, and WorkRave are competitive at this time.

[Chealer]

FWIW, I just did some comparison, and I appreciate the value of this, but indeed maintaining comparisons with projects all being moving targets is really cumbersome.

Good point. So if a comparison table is created, instead of having pure boolean values like "No", the values would better be versioned (at the very least in the code, but probably best to display to readers too). For example, "No (2.1)"