Hi,

> On Jun 10, 2016, at 10:55 AM, Ben Coman <b...@openinworld.com> wrote:
> 
> On Fri, Jun 10, 2016 at 4:11 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>> 
>>> On 10 Jun 2016, at 09:47, Guille Polito <guillermopol...@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 <esteba...@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 <esteba...@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 <maxle...@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 <tu...@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."





Reply via email to