spotter usage - a rough analysis of categories
Hi, Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members. Of these 34 used the dive-in feature. That is, these users used at least one contextual search. We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it: 'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1 Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods). As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages. We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE. This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Value is always contextual."
Impressive analysis! This is worth to discuss these findings in an academic venue. Alexandre
On Jun 9, 2016, at 6:56 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Doru, I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process). Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu <http://ws.stfx.eu/>'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com
"Value is always contextual."
I need to enable data collect ;) in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point: - I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc) I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :) cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu <http://ws.stfx.eu/>'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Value is always contextual."
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :) Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu <http://ws.stfx.eu/>'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Value is always contextual."
and just another thing :) I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc I think it is a super functionality (and it was fast), that should be included by default. Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu <http://ws.stfx.eu/>'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Value is always contextual."
I use spotter a lot as well. It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace. The things I look most by name are tools (Menu entries), classes and packages. History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else. Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process" you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category. Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session? Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them. Guille -------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu <http://ws.stfx.eu/>'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Value is always contextual."
On 10 Jun 2016, at 09:47, Guille Polito <guillermopolito@gmail.com> wrote:
I use spotter a lot as well.
Me too !
It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace.
Indeed, same here.
The things I look most by name are tools (Menu entries), classes and packages.
History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else.
Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process"
you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category.
Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session?
Some simple learning would be super cool.
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Yes, that is indeed something that I miss as well: browsing them all. Sven
Guille
-------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
2016-06-10 10:11 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 10 Jun 2016, at 09:47, Guille Polito <guillermopolito@gmail.com> wrote:
I use spotter a lot as well.
Me too !
It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace.
Indeed, same here.
The things I look most by name are tools (Menu entries), classes and packages.
History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else.
Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process"
you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category.
Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session?
Some simple learning would be super cool.
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Yes, that is indeed something that I miss as well: browsing them all.
I don't use Spotter much, because I do that often: code in the result of a search for senders / implementors. Another thing that doesn't work too well with Spotter: I like to restrict the scope to a single package / group of package, either before the search, or after (making it easy to turn off large subsets of the search results). Thierry
Sven
Guille
-------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Hi,
On Jun 10, 2016, at 10:24 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-06-10 10:11 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 10 Jun 2016, at 09:47, Guille Polito <guillermopolito@gmail.com> wrote:
I use spotter a lot as well.
Me too !
It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace.
Indeed, same here.
The things I look most by name are tools (Menu entries), classes and packages.
History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else.
Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process"
you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category.
Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session?
Some simple learning would be super cool.
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Yes, that is indeed something that I miss as well: browsing them all.
I don't use Spotter much, because I do that often: code in the result of a search for senders / implementors.
Another thing that doesn't work too well with Spotter: I like to restrict the scope to a single package / group of package, either before the search, or after (making it easy to turn off large subsets of the search results).
Some scoping can be easily added. For example, if we would add a Senders processor for a Package we could scope it for that package. To scope this for a group of packages is where things become more interesting. The current idea is to allow each processor to provide a typed group and provide processors in that class. For example, diving-in-category of a package category, could provide us not a plain collection, but a PackageCollection (or PackageGroup), and there we could again have processors like Senders. This is something we need to play with some more. Any related ideas? Cheers, Doru
Thierry
Sven
Guille
-------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
-- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."
Hi, Le 10/06/2016 15:34, Tudor Girba a écrit :
Hi,
On Jun 10, 2016, at 10:24 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote: ...
Another thing that doesn't work too well with Spotter: I like to restrict the scope to a single package / group of package, either before the search, or after (making it easy to turn off large subsets of the search results).
Some scoping can be easily added. For example, if we would add a Senders processor for a Package we could scope it for that package.
This is effectively what I use, but linked with scoping in the browser: scope, then search. It's like taking your conversation metaphor around: start sustained, increment or create new threads by search. My interface uses the finder; I wondered at one point if I could reuse Spotter instead (i.e. have a spotter bar instead of the finder bar I have at the moment in the browser).
To scope this for a group of packages is where things become more interesting. The current idea is to allow each processor to provide a typed group and provide processors in that class. For example, diving-in-category of a package category, could provide us not a plain collection, but a PackageCollection (or PackageGroup), and there we could again have processors like Senders. This is something we need to play with some more.
Any related ideas?
I'm not sure creating groups per processor is a good idea. I know that I rely a lot on the fact that the groups are constant to be able to use them. If they were changing based on the processor, then I would find that very messy: imagine a classification where the group GUI contains different packages depending on whether you're searching for a sender, a pragma or an implementor? At the same time, I'm the only one using a complete and constant set of groups of packages for years already among you, so I know my results can't be generalized. Thierry
Cheers, Doru
On 10 Jun 2016, at 10:11, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 10 Jun 2016, at 09:47, Guille Polito <guillermopolito@gmail.com> wrote:
I use spotter a lot as well.
Me too !
It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace.
Indeed, same here.
The things I look most by name are tools (Menu entries), classes and packages.
History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else.
Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process"
you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category.
Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session?
Some simple learning would be super cool.
problem for learning is that it consumes space⦠old algernon was cool on learning, but it was taking always like 10m memory extra. probably not something that you would care⦠and maybe some simple learning would not take as much, but well, I wanted to point it :) cheers, Esteban
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Yes, that is indeed something that I miss as well: browsing them all.
Sven
Guille
-------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
On Fri, Jun 10, 2016 at 4:11 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 10 Jun 2016, at 09:47, Guille Polito <guillermopolito@gmail.com> wrote:
I use spotter a lot as well.
Me too !
It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace.
Indeed, same here.
The things I look most by name are tools (Menu entries), classes and packages.
History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else.
Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process"
you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category.
Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session?
Some simple learning would be super cool.
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Yes, that is indeed something that I miss as well: browsing them all.
I often worry one day someone will remove the Senders <meta-n> and Implementors <meta-m> windows since Spotter *mostly* supersedes them, but actually they fill different needs. Spotter is transient. It opens quickly from anywhere, helps you go to what you want and then it hides itself away. But often I have several different Senders / Implementers windows open for hours at a time, and its nice to flip back and forth between implementations and make edits there. For example, I want to add a halt in every implementer. In the past I asked editing capability in the Spotter code window, but with Spotters transitive nature maybe is not the best place to make edits. cheers -ben
Sven
Guille
-------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
Hi,
On Jun 10, 2016, at 10:55 AM, Ben Coman <btc@openInWorld.com> wrote:
On Fri, Jun 10, 2016 at 4:11 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 10 Jun 2016, at 09:47, Guille Polito <guillermopolito@gmail.com> wrote:
I use spotter a lot as well.
Me too !
It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace.
Indeed, same here.
The things I look most by name are tools (Menu entries), classes and packages.
History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else.
Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process"
you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category.
Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session?
Some simple learning would be super cool.
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Yes, that is indeed something that I miss as well: browsing them all.
I often worry one day someone will remove the Senders <meta-n> and Implementors <meta-m> windows since Spotter *mostly* supersedes them, but actually they fill different needs. Spotter is transient. It opens quickly from anywhere, helps you go to what you want and then it hides itself away. But often I have several different Senders / Implementers windows open for hours at a time, and its nice to flip back and forth between implementations and make edits there. For example, I want to add a halt in every implementer.
In the past I asked editing capability in the Spotter code window, but with Spotters transitive nature maybe is not the best place to make edits.
Exactly :). In the current form, Spotter serves the role of opening a conversation with objects (or code). It is not yet enough for sustaining that conversation. So, we still need a solution for working with a subset of elements for longer periods of time. Cheers, Doru
cheers -ben
Sven
Guille
-------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
-- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Le 10 juin 2016 à 09:47, Guille Polito <guillermopolito@gmail.com> a écrit :
I use spotter a lot as well. It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace.
The same for me. Spotter is the fastest path to open a tool, browse a class, etc. My top searches are: classes, implementors, packages I sometime use tools and use more history. (by the way, I often hit history entries by accident) Christophe
The things I look most by name are tools (Menu entries), classes and packages.
History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else.
Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process"
you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category.
Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session?
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Guille
-------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano < <mailto:estebanlm@gmail.com>estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske < <mailto:maxleske@gmail.com>maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba < <mailto:tudor@tudorgirba.com>tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu <http://ws.stfx.eu/>'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- <http://www.tudorgirba.com/>www.tudorgirba.com <http://www.tudorgirba.com/> <http://www.feenk.com/>www.feenk.com <http://www.feenk.com/>
"Value is always contextual."
Hi, Thanks for the feedback. More inline.
On Jun 10, 2016, at 9:47 AM, Guille Polito <guillermopolito@gmail.com> wrote:
I use spotter a lot as well. It is actually my default entry point to the system. It superseeded the searches in Nautilus, and most of the searches that I used to start in the workspace.
The things I look most by name are tools (Menu entries), classes and packages.
History is of great help and I use it a lot. But it poses a problem sometimes because it alters the order of the results, and you have to wait for the complete search to finish. If you do not do that, it happens what Max explained: you type, hit <down>,<enter> and suddenly the UI refreshed and you finished doing something else.
Also, regarding the ordering of results, sometimes It bothers me that they are sorted by category and not by relevance of the item. I'll explain myself with a concrete case: - open spotter - type "Process"
you get first two #menu items and then the #classes, containing the class Process. I would have expected here to show first the element that matched the most or with more relevance, regardless it's category.
This is indeed an interesting direction, but we are not ready for it yet because Spotter does not have a scoring mechanism that would work between distinct categories. Ideas in this space would be welcome.
Question: Does spotter adapt to it's usage? Besides history, does it learn what are the items with more relevance from previous usages in the same session?
It has no learning mechanism built in.
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Indeed. There is an open issue for allowing editing in the preview. However, even if you can edit, we will still have the problem of the feedback to the list. For example, suppose you are looking for senders of #x, and you modify the code to no longer use #x. In this case you would want the list to update. We do not have that feedback loop. This is an area where again we would benefit from ideas of how to implement such a thing in a generic way. In any case, in the current form, Spotter is not appropriate for longer interaction because of its floating/transient nature. We need something else. It is already possible to transform a Spotter in a regular window, but we still need to play with this idea more until we get to an improved solution. Cheers, Doru
Guille
-------- Original Message --------
and just another thing :)
I think search patterns are a bit naive now (just matching begin of line). We could benefit from regex searchs and/or that search stuff made by Damien⦠I do not remember the name, but it has a name) that thing that you type âabcâ and it will find - abc - absoluteBinaryCapability - AbstractBlooperContext - etc
I think it is a super functionality (and it was fast), that should be included by default.
Esteban
On 10 Jun 2016, at 08:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Ah, and I forget one very important: the menu! I almost do not use the older menu anymore :)
Esteban
On 10 Jun 2016, at 08:54, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I need to enable data collect ;)
in my case, Iâm a happy Spotter user⦠I even have a plugin I made for my own that fits my way of work with repositories⦠anyway, I wanted to point:
- I use a lot Classes/Methods/Packages... and catalog - never used Senders/References/Pragmas because I do not find them easily (then is easier to search the class, then hit references) - some categories seems confusing - some other are not âfor extensive useâ but they are very useful: files, monticello package, playground - this is more for the playground: I never understood why we need a difference between cached pages and named ones (a cached can just be named cached-1⦠etc)
I would be even happier is Yuriy extends his GitHub baseline plugin to scan subdirectories (most github projects keep mc data into a subdirectory) :)
cheers! Esteban
On 10 Jun 2016, at 08:42, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
-- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."
On Fri, Jun 10, 2016 at 09:47:40AM +0200, Guille Polito wrote:
Also, from the top of my head there is at least one use case that I cannot yet replace with spotter, and I have to use a normal workspace/playground to do it => browse senders or implementors. While i use senders/implementors search in spotter, sometimes I want to *browse* them to be able to look at them, and interact with the code. However, from spotter I can only observe results but not edit them.
Indeed, if there was a way to open the MessageFlowBrowser from spotter, that would completely replace Senders and Implementers for me. Cheers, Alistair
Hi, Indeed, this was a question I asked myself as well. And I think I figured out a way to filter most of the false positives out. The analysis goes like this: If you have a misstep, you likely want to restart Spotter and search again. In this situation it is likely that the distance between the end of the misstepped session and the starting of a new session is less than 5 seconds. For safety, letâs consider 20 seconds. To put it in perspective, 90% of Spotter sessions have less than 20 seconds. So, if we filter out all sessions that have another session coming after less than 20 seconds we get this: 'Classes'->40 'Implementors'->38 'History'->33 'Packages'->20 'Menu'->18 'Messages'->18 'Catalog Projects'->12 'Instance methods'->10 'Senders'->7 'References'->5 'Playground named pages'->5 'Pragmas'->4 'Playground cached pages'->3 'Selectors'->3 'Super instance methods'->3 'Help topics'->3 'ws.stfx.eu'->2 'Examples'->2 'GitHub Baselines'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Help contents'->1 'Productions'->1 'Dirty Monticello packages'->1 There are very little changes. History is still number 3, and Menu is in top 5. Cheers, Doru
On Jun 10, 2016, at 8:42 AM, Max Leske <maxleske@gmail.com> wrote:
Hi Doru,
I just want to point out that history may possibly be a bit of a false positive. When I open spotter, type and hit enter quickly I sometimes hit an entry from history that I didnât intend to (one annoying example of this is ProcessBrowser which I regularly hit accidentally when searching for Process).
Cheers, Max
On 10 Jun 2016, at 00:56, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the past 7 months. Of these, only 42 recorded more than 9 sessions so we only focused on these. It can be because the rest switched off the data collection in the meantime. We also excluded the computers of the GT team members.
Of these 34 used the dive-in feature. That is, these users used at least one contextual search.
We looked at the event of acting on an element (pressing Enter), and we collected the parent category. Acting on an item indicates that intent of search. There are 35 categories used in total, with 8 being used by 10 people (25% of the studied population) or more. Below you can see also the amount of computers using it:
<spotter-categories-distribution.png>
'Classes'->40 'Implementors'->38 'History'->34 'Menu'->24 'Packages'->23 'Messages'->19 'Catalog Projects'->12 'Instance methods'->10 'Senders'->9 'Pragmas'->6 'References'->5 'Playground named pages'->5 'Playground cached pages'->4 'Help topics'->4 'Examples'->3 'Super instance methods'->3 'Selectors'->3 'ws.stfx.eu'->2 'GitHub Baselines'->2 'Dirty Monticello packages'->2 'Class methods'->2 'Global variables'->1 'All subclasses'->1 'Example Subjects'->1 'Files'->1 'Monticello Repositories'->1 'Metacello Configurations'->1 'Class instance variables'->1 'Items'->1 'Tags'->1 'Help contents'->1 'Monticello Package'->1 'Instance variables'->1 'Productions'->1 'Methods'->1
Also, in this analysis, some of the categories appear also at deeper levels (Senders, Implementors, References, Instance methods).
As expected, Classes and Implementors are on top. Yet, the third is History, and it is also interesting to see that there is a high usage of a search through the World menu elements, but also of the Packages.
We also note that there is quite a long tail, and this seems to confirm the hypothesis that different people have different needs and that these differences should be supported by the IDE.
This analysis was carried out using the code that Juraj and Andrei put together for analyzing the data from the event recorder.
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Value is always contextual."
-- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."
participants (10)
-
Alexandre Bergel -
Alistair Grant -
Ben Coman -
Christophe Demarey -
Esteban Lorenzano -
Guille Polito -
Max Leske -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba