* DONE Designing Flexible Extendable Scales :blog:dev:tech:
:PROPERTIES:
:ID:       designing-scale
:CREATED:  [2024-11-12 Tue 10:26]
:END:
:LOGBOOK:
- State "DONE"       from "DRAFT"      [2024-11-12 Tue 10:26]
- State "DRAFT"      from              [2024-11-10 Sun 11:43]
:END:
In my task manager,
I wanted priorities to be simple and accessible,
but flexible for power use.
So instead of nailing you down to a given set,
I decided on simply using a number in the backend.
The frontend could still display that number in any desired format.

Such scales ideally expand upwards -
not like the EU energy label
which has now been reset because they built a scale of few items
with A being the best,
instead of the other way around where you could at least extend it to the following letters
instead of introducing a confusing reset.

That is why low priorities are given low numbers
(and there is no technical reason not to allow negative numbers either,
to allow expansion in both directions)
so that old low-priority tasks do not pollute the list
in a need to be adjusted downwards.
Because if low number meant high priority,
similar to the energy label,
a new priority in your repertoire
is easier to add to the bottom,
requiring you to adjust.
Adding it to the top
means minimal adjustment needed,
bceause there are typically fewer high-priority tasks.

Additionally,
I introduced a mechanism that allows for interspersing as desired:
A single-digit priority is always multiplied times 10,
allowing one to easily get started incrementally with 10 priorities
without caring about that mechanism,
but if even more granularity is desired,
the transition is seamless to one hundred or even more priority levels
(not that I could envision myself properly using that,
but I want to keep everything open
for all kinds of individual workflows).