First I explain the simple concept of an access counter.
After that, I come with the advanced concept for a relevance value.
WHAT DO YOU RECOMMEND?
In principle, a kind of an automatic generated list of favorites.
There are always Objects that are more frequently used then most others.
It would be nice to have a way to sort a View for the counts of accesses.
This way, you would see a list of your most viewed/opened Objects, sorted by accesses, with your most used Objects on top.
We already have the “Favorites” function, to declare certain Objects manually as favorites.
What I suggest does in principle the same thing automatically.
HOW COULD IT BE DONE?
What we need is simply a new Property that counts the accesses for each Object.
Each time the user opens an Object, the counter increments.
REAL WORLD USE CASES
As explained, it would give us a quick way to find our most used Objects.
A sorted Query View would do the job.
All what we need for the simple concept is the Property that counts the accesses.
What I expect is a quicker workflow in daily navigation. The most relevant Objects (because most used) are quickly to find. – But see next section.
NOW THE ADVANCED CONCEPT (about the relevance of an Object):
The described counter is in my opinion needed, but this alone wouldn’t sufficiently serve the purpose to find the most relevant Objects.
Most relevant are Objects that was often used in the younger past.
– Objects that was heavily used two years ago are less relevant then Objects that was often used during the last two weeks.
That means, we need a kind of integral over time.
There are different approaches imaginable. I suggest a very easy approach without the need to store the time stamp of each access:
- Add one more additional Property “Relevance”.
- Each manual access increments the value by one.
- But once per day (or maybe once per week), the value becomes automatically decreased by one.
As a result, the older the accesses are, the less is their weight.
The “Relevance” Property is related to the simple counter that I’ve suggested in the simple concept, but it is not identical with it. Because the simple counter increments only by manual access, while the Relevance value in addition also decrements every day, and that automatically.
If an Object was heavily used long ago, its relevance value loses up to 364 points over the year and becomes less relevant every day.
While an Object that was frequently used in the last few days will have a higher relevance value.
Unfortunately, in this concept, there must be a daily task that modifies the values of each Object’s relevance Property every single day. For thousands of Objects, that needs an own thread that consumes a bit time. And there is also to deal with the syncing …
– I don’t want to make this request “tldr long” by explaining my idea how to deal with that in detail, but if there is interest I can do it in a following post.
RECOMMENDED ALTERNATIVES
–
ADDITIONAL CONTEXT
Two additional thoughts for the simple counter (forget for a moment the relevance value):
- Maybe you could think that it’s a good idea to add even two new counter Properties:
a) A counter for the accesses (in reading mode).
b) A counter for the accesses for modification.
In a sense an analogy to the Properties “Last opened” and “Last modified”. Only difference is, that the suggested new counter Properties don’t store timestamps, but counter values. - How to deal with the History?
If the user restores from the History an older version of a certain Object, what should happen with the counter?
– One could think differently about that, I have no clear preference. I simply put the thought on the table so that the devs don’t forget to take the History into account.