Rockbox

Tasklist

FS#7809 - Gather statistics about menu usage (and, possibly, reorder menu items)

Attached to Project: Rockbox
Opened by Alexander Levin (fml2) - Friday, 21 September 2007, 22:13 GMT
Last edited by Alex Parker (BigBambi) - Sunday, 06 June 2010, 08:23 GMT
Task Type Patches
Category User Interface
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Here is my shot at what has been discussed on IRC a couple of days ago. Since I already provided a patch for reordering of items in the main menu (but it was rejected), I liked the idea because:

1. It's more general (applies to all menus, not only the main one)
2. Menus are adjusted automatically to each user's usage pattern
3. Even if not used for automatic reordering, it can be used for gathering statistics about the GUI usage and thus provide information for optimizing the menu structure

This is just the first quick try, but I hope the idea is clear: each menu item gets a unique ID. IDs are generated by macros, so no need to edit many source files; hopefully, there won't be any name conflicts. If there will the line number (as in PP macro __LINE__) could somehow be incorporated into the ID. I just couldn't figure how to do it. With lines incorporated, names become more unique but also more fragile.

Also, each item gets a counter for how many times the item was selected.

Then, before a menu is displayed, its items are reordered so that more frequently used items go to the top.

At shut down, the stats can be dumped to a file, and loaded again at startup.

There could/should also be settings telling:
- whether the stats should be gathered (maybe you've achieved your dream configuration want to freeze it?)
- whether the reordering should be made (useful e.g. for blind users)

TODOs:

1. Find a better place for the definition of GATHER_CALL_STATS so that this feature can be cut at compile time
2. Add something to the macros that would register each item's stats struct in a global array. This array would then be used for dumping/loading
3. Implement dumping/loading the stats (now everything is initialized with zero)
4. Add the appropriate settings

Please don't put this down immediately after you see "menu reordering." Just live with the idea some time, and maybe you'll like it. And I'd be glad if someone would help me with all this.

I'd definitely use it to reorder some items and would then freeze my stats once the desired and frequently used items are on the places where I'd like to find them.
This task depends upon

Closed by  Alex Parker (BigBambi)
Sunday, 06 June 2010, 08:23 GMT
Reason for closing:  Rejected
Comment by Dominik Riebeling (bluebrother) - Friday, 21 September 2007, 22:22 GMT
I guess you're aware that especially automated menu reordering is evil, not only because a lot of people dislike it but also because of blind users. That being said I simply don't like the idea of reordering at all. And I can't see a real use for gathering data as usage patterns will pretty much be usage dependent, thus depending entirely on the user. Which makes this bloat in my eyes. Others might disagree of course. I don't want to put you down, but ... ;-)
Comment by Alexander Levin (fml2) - Saturday, 22 September 2007, 21:17 GMT
> I guess you're aware that especially automated menu reordering is evil

Could you please explain why? I can see some benefits (and even more when there is an option to freeze the order). And no drawbacks provided there is the option to disable it. (OK, binary size increases, yes.)

> not only because a lot of people dislike it

This is your assumption. How can they dislike it if they haven't even tried it?

> but also because of blind users.

Yes, I'm aware of them. That's why there should be an option to disable reordering (which would be the default).

> That being said I simply don't like the idea of reordering at all.

You don't but I do to some extent as it would allow me (and others) to non-intrusively (i.e. without having to change the code) put some items to where I want them.

> And I can't see a real use for gathering data as usage patterns will
> pretty much be usage dependent, thus depending entirely on the user.

Agreed. Usage patters are probably quite dfferent. But I imply the opposite: this will allow each user (should she want it) to adjust the menus to her *personal* preferences.
Comment by Paul Louden (Llorean) - Sunday, 23 September 2007, 15:48 GMT
It's "evil" for multiple reasons:
1) Binary size increase, as you mentioned. As we do not want reordering menus a binary size increase is very unwanted. The reordering menus will then affect people negatively even if they choose not to use them.
2) We've stated we do not want custom menus, as they will make support more difficult, and use more confusing. For example people often just want instructions to fix their language, and not want to clear settings, and it's impossible to talk someone through a non-static menu structure as you can't know how theirs has changed (worse if automated.)

As for people disliking it: The developers dislike the idea. These are the people who've talked about it. I know that I dislike stuffing potato chips up my nose, and I've not tried it. I know I dislike shifting menus and I've not tried it. It's pretty clear I can know I dislike things without trying them based on an aggregate of other interactions and events that have similar feature's and the human brain's wonderful ability to extrapolate an event from similar related events. This is partially about the purpose and goals of the project, which is not "be everything for all users" but rather "meet the needs of the people creating it" and in general they feel that static menus are best.
Comment by Alexander Levin (fml2) - Sunday, 23 September 2007, 18:43 GMT
> The reordering menus will then affect people negatively even if they choose not to use them.

As with any other setting not used by a user.

> For example people often just want instructions to fix their language, and not want to clear settings

I think it's a rather artificial case. But I clearly understand that RB doesn't have to accept every proposal. I respect this mode and hence will probably stop working on this.

Or I'd first start a discussion in the forums to see what others think about it. If many would be interested, the dev's attitude might change. So diplomatical work must be carried out first!
Comment by Dominik Riebeling (bluebrother) - Sunday, 23 September 2007, 20:20 GMT
> As with any other setting not used by a user.

Yep. But this is bloat, while a lot other features are not. Specifically, it has nothing to do with Rockbox' main purpose (playing music).

> If many would be interested, the dev's attitude might change.

I don't think this will happen ...

And about me disliking auto-reordering menus: I'm pretty sure that almost everyone who is used to computers already "tried" that auto-hiding of "unused" elements windows comes with per default. And almost everyone I talked about this feature disliked it. The only reason for not disabling it is usually laziness or lack of knowledge how to do. The number of people who really liked that feature is neglectible -- at least from my experience.

IMHO this task should get rejected.
Comment by Jonas Häggqvist (rasher) - Sunday, 23 September 2007, 22:13 GMT
As perhaps a statistical anomaly, I happen to rather like reordering menus. I especially like Windows' hiding of unused elements, since it actually does adapt to my needs, and does only show the ones I frequently use. I don't need to see the full list of 800 items to chose from, when 95% of the time, I simply want to pick one of the same 5 items. I see this as one of Windows' few redeeming features.

As for reordering of Rockbox menus, I'd probably personally like it. A lot of options could be said to not be about Rockbox' main purpose or just plain bloat (alarm clock, cuesheet - just split the files on your computer, overly complicated sound settings (who honestly *needs* that much control?), fading display backlight, backdrop support etc.)

I'd personally love to see Rockbox giving me the menus I want, need and use, rather than some rather arbitrarily ordered list of settings that I may or may not be interested in.

How many features do you honestly blindly navigate to anyway?

In the end though, I can understand not including it, but the best reason I can see is the Archoses and their ever-present RAM issues (how much does this add to binsize by the way?).

I think it'd still be interesting to keep this around, for use in case we wanted to re-order the menus to better suit more users. In that case, usage statistics like these would be invaluable.
Comment by Jonas Häggqvist (rasher) - Sunday, 23 September 2007, 22:16 GMT
A side-note: Perhaps with a few hooks added to the menu code, the statistics-gathering part could be rewritten as a TSR plugin purely for usage analysis? That should be a far less intrusive patch that would add fairly little to the core.
Comment by Alexander Levin (fml2) - Monday, 24 September 2007, 07:45 GMT
> ...A lot of options could be said to not be about Rockbox' main purpose or just plain bloat
> [...]
> I'd personally love to see Rockbox giving me the menus I want, need and use, rather than
> some rather arbitrarily ordered list of settings that I may or may not be interested in.

Exactly the reason I thought it would be useful.
Comment by Shiloh Hawley (gree665) - Friday, 28 September 2007, 00:07 GMT
I wouldn't like to have my menus reordering themselves but I would love to be able to control the order myself. This is especially true because with the ipod, without looking, you can only scroll to the top or bottom of a menu. I think manual reordering could be done without adding much to the binary size, using a user-editable configuration text file to change the order of the menu items. Since the only thing it would change is the order, I dont think user support would be more complicated. Any instructions like "go to main menu -> settings -> general settings -> playback -> play selected first -> no" would still be just the same.

I would work on implementing this feature, but I have seen all the forum discussion about it and similar ideas, and it seems the devs are against it. Since it is their project, they get to decide. I end up reordering menu items (and taking out menu items I dont use) and building the code, whenever I update my firmware. It is worth the effort.
Comment by Alexander Levin (fml2) - Friday, 28 September 2007, 20:03 GMT
You will be able to to what you describe here provided that there will be an option to freeze the order (and there will be one). The statistics will be saved to and read from a text file (this can be accomplished by a plugin, no need to put this in the core). You can edit it manually thus setting the order of items in the menus. The possibility of the *auto*-reordering is a side effect and would come and nearly no cost once the reordering is implemented.

The tricky part is IMHO to automate the creation of the item list and to ensure that this list matches what's really in the code. I think I've come up with a solution to this. Build process will be slightly modified, and some rules will be imposed to the usage of the macros for producing menu items.

As to hiding menu items: this should also easily be possible once everything has been implemented, but even I would not go that far. Since THEN you might get real problems with the support. But I agree that just reordering items should not call for a mess.
Comment by harry tu (bookshare) - Saturday, 29 September 2007, 14:58 GMT
I don't get why this is bad for us blind users! Just as long as the voice features update with the menus, I am not seeing what is wrong.
Comment by Shiloh Hawley (gree665) - Saturday, 29 September 2007, 16:18 GMT
I think it would be better to just configure the menus manually through a config file. I don't see an advantage to auto-reordering, and it adds complication. For one thing, the menu items you want most accessible correspond to the tasks you want to do without looking, but might not be the tasks you do most often. For another, having the menu items in the order most used would not be so helpful, at least on the ipod, because the first and LAST items on the list are the easiest to get to, since it is hard to scroll one by one without looking at the display. (I do not advocate being able to remove menu items, but since I'm rebuilding the code for myself I take em out).
Comment by Alexander Levin (fml2) - Saturday, 29 September 2007, 23:19 GMT
Here is what I've come up with so far.

Menu items can be reordered. Auto reordering seems to work. NOTE TO ALL: I consider auto reordering just as a side effect of the possibility to reorder items. I just haven't yet created settings for activating/deactivating that.

Also, there is a plugin for dumping the current statistics to a file and loading them.

Just consider the values as "item priorities": the higher the priority, the higher the item will be in the menu. You can edit the file manually of course.

TODOs:

1. Modify Makefiles so that all the necessary things are generated and compiled automatically. For now, I just executed the script (also attached but not part of the patch) manually.

2.Create setting for ignoring/respecting the file with priorities (and probably other settings, e.g. auto save at shut down, auto load at startup etc.)

3. Implement "Restore factory settings" for the order of menu entries. I.e.set all counters to 0.

4. Introduce a symbol for this feature. If the symbol is not defined, the call stats & co won't be known in RB (and the binary size should not increase of course). I.e. sort of make it a build option.


Maybe TODO (but very unlikely):

1. Implement hiding menu items. For example, if the call counter is negative, the item is hidden

Since the voicing will work, I also don't see any troubles for blind users.
Comment by Alexander Levin (fml2) - Saturday, 29 September 2007, 23:20 GMT
PS. I desperately need help in adjusting Makefiles.
Comment by Alexander Levin (fml2) - Sunday, 30 September 2007, 10:50 GMT
For the interested, here is the generated .c file for H120 sim. I added it to apps/FILES in order to get it compiled.

The build process should work as follows:

1. Compile RB core (i.e. not codecs and not plugins) files with '-save-temps' option. The symbol GATHER_MENU_CALL_STATS should be defined. codecs and plugins are compiled as before, i.e. without the option and with the symbol undefined.

2. Run the script to generate the array with addresses of all the stats structs. The script is attached.

3. Compile the generated file

4. Link everything together (same as before)

I need help in modifying Makefiles so that the steps 2 und 3 are executed.
Comment by Alexander Levin (fml2) - Sunday, 30 September 2007, 14:48 GMT
Cleaned up the patch (many changes got in because my editor stripped off the trailing spaces). Also fixed some errors in the new plugin.
Comment by Alexander Levin (fml2) - Sunday, 30 September 2007, 19:57 GMT
Open file for writing with 'creat' instead of 'open' with flags
Comment by Alexander Levin (fml2) - Tuesday, 02 October 2007, 20:14 GMT
In this 'release':

- introduced the option for automatical menu reordering. It is set to false by default. No entry in the settings menu for it yet (or ever).

- Partial configurations are now possible. If you just want to change e.g. the order of items in the main menu, you can specify priorities just for them. But you have to tell the plugin that not the full item coverage is intended. It is done by placing '# full coverage: no' to the file. This is somewhat similar to the 'Option Explicit' in Visual Basic :-)


An example of the file for arranging main menu like this (on H120):

Files, FM Radio, Resume Playback, Settings, Database, Recording, Playlists, Plugins, System

# full coverage: no
file_browser: 100
fm: 90
wps_item: 80
menu_: 70


The four items are explicitly pulled to the top, the order of the rest is unchanged.
Comment by Alexander Levin (fml2) - Tuesday, 02 October 2007, 23:02 GMT
Now also adjusted the Makefile. Someone with knowledge of Makefiles in general and RB build system in particular: please check if it's ok.

One warning though: the makefile produces .i files (result of preprocessing). These are generated in the source dir (apps). So it's dangerous to build two targets simultaneously since the results of preprocessing might conflict. Ideally, I'd specify an option where .i file should be generated, but I couldn't find one.
Comment by Alexander Levin (fml2) - Sunday, 07 October 2007, 10:46 GMT
Synchronized the patch.

One more feature in the plugin. It'snow possible to specify a default priority which will be assigned to all items not explicitly mentioned in the file. Thus it's possible to specify only the items that should go to the top and to the bottom. The rest will be assigned the default.
Comment by Alexander Levin (fml2) - Wednesday, 10 October 2007, 19:47 GMT
Synchronized again. This will probably be the last synchronization since the interest in this feature is rather low.
Comment by alex wallis (alexwallis646) - Sunday, 02 March 2008, 23:52 GMT
Hi. I am blind and personally I like the idea of this patch. However i'd like to see this patch adapted or built on, so that it was possible to hide menus, or options within menus that a person could some how specify in a config file. For example I never use options like the data base, or any of the recording functions or a hundred other tiny options that add a few extra button pushes to get past them.
Comment by Alexander Levin (fml2) - Monday, 03 March 2008, 20:20 GMT
Hi Alex.

Hiding menu items would be easy to implement with the approach used in the patch. However, I'm afraid this will never get accepted by the developers. Even just reordering of the menu items is frown upon. And hiding them is then a crime!

Loading...