- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] another spotter question

by Aliaksei Syrel

I was talking about clickable arrow to open preview ;) On Jan 22, 2016 10:47 AM, "stepharo" <stepharo(a)free.fr> wrote: > Hi aliaksei > > Hi Stef > > I saw an early version of Spotter with arrows near each item and it was > IMHO awful. But still, pencils taste differently for each of us ;) > > > I do not know. May be the arrow should not be on every element but just on > the group/category > may be the colors should be deemed. > > I can agree with you that people "do not get how to use spotter". However > it depends on how we define "use spotter". From my prospective almost all > do understand how to use main feature: searching. > I think the whole discussion is about more advanced features. > > No it is about frustration. > I get a list in front of my nose and I have no clue how to access it. I > click on it and it does not work. > I have to read blog to see something and I have no clue how to obtain the > same result. > This kind of thing. > > Let's talk about how to open preview(pane to the right) in context of > learnability which consists of multiple design principles. During our > analysis we will try to determinate violated ones and see how they can be > fixed. > > a) Familiarity. It consists of guessability which is surely violated - I > can not imagine anyone who could guess that in order to open preview she > should click on arrow to the right of the item (I talk about intentional > click, not random one to see what will happen). > > ok > > Second part describes how prior knowledge applies to new system. If we > would take Pharo as new system, then principle is finally busted because I > never saw such behaviour anywhere else - it was invented in spotter. If new > system would be spotter in context of Pharo, then still violated as > clicking on arrow is not used anywhere else in Pharo. > > If you put a little triangular icons on top of the arrow then people will > certainly undertsand that they can click on it. > > My point is ask yourself why many people do not know how to open the pane. > I could not find it. Once I got it I asked around and really few people > know it. > > Possible way to fix familiarity principle is to spread usage of arrow to > the whole Pharo (or world) or to modify its design to improve guessability > by adding preview icon/label/whatever on the arrow. > > b) Generalizability. Meaning that user can extend specific interaction > knowledge to new situations. Clicking on arrow is only used in one place in > spotter - so there is no chance for user to extend not existing knowledge. > Violated. > > Fix is similar to familiarity - clicking on arrow to expand/open new pane > should be used in more places. > > I do not think. > > c) Predictability. Consists of determinism and operation visibility. > Determinism is not violated because effect of clicking on arrow can be > immediately observed by user. However, operation visibility is violated - > arrow does not change depending whether preview is available or not. > > To fix operation visibility we need to change arrow color/icon depending > on availability of preview. > > > You do not reply to the point that to see that I can interact with a group > of element I have to select the first one. > Currently it only work because some people use arrows. I never because > there are at the bottom of my keyboard. > > d) Synthesisability. Not violated - user can easily observe effect of past > operations. Preview has only two states: on and off. > > e) Consistency. We can not say anything, because there are no similar > situations in the system. > > To conclude, an action to open preview should be improved. The most > easiest fix would be to add something on top of arrow to make it obvious > (improve guessability) what clicking does. > > yes to improve the fact that we may click on something. > > More preferred one IMHO is to expose arrow usecases and teach users so > that generalizability would start playing a role. > > I do not get it. > You should understand that Pharo can be used with a mouse. > > Sorry for long email > Alex > > > Le 20/1/16 14:30, Aliaksei Syrel a Ã©crit : > > On Wed, Jan 20, 2016 at 12:59 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> +1. Its annoying that it takes two clicks to dive into categories like >> "Implementors" (one to click an item under the category to make the arrow >> appear, and then another to click on it) when it would only take one if >> that arrow for each category was always visible. > > > Doru is right, always visible arrows would pollute UI. > > I do not see why. > A user interface is not something that we should click randomly at to > learn how to use it. > > A compromise solution would be to show them on mouse hover - one click + > not overcrowded interface. > > > may be > but you can ask yourselves why so many people do not get how to use > Spotter. > I asked again today to people how to show the pane on the right and nobody > knew obviously. > > > Cheers, > Alex > > > >

Jan. 22, 2016

Re: [Pharo-dev] another spotter question

by stepharo

Hi aliaksei > Hi Stef > > I saw an early version of Spotter with arrows near each item and it > was IMHO awful. But still, pencils taste differently for each of us ;) > I do not know. May be the arrow should not be on every element but just on the group/category may be the colors should be deemed. > I can agree with you that people "do not get how to use spotter". > However it depends on how we define "use spotter". From my prospective > almost all do understand how to use main feature: searching. > I think the whole discussion is about more advanced features. > No it is about frustration. I get a list in front of my nose and I have no clue how to access it. I click on it and it does not work. I have to read blog to see something and I have no clue how to obtain the same result. This kind of thing. > Let's talk about how to open preview(pane to the right) in context of > learnability which consists of multiple design principles. During our > analysis we will try to determinate violated ones and see how they can > be fixed. > > a) Familiarity. It consists of guessability which is surely violated - > I can not imagine anyone who could guess that in order to open preview > she should click on arrow to the right of the item (I talk about > intentional click, not random one to see what will happen). > ok > Second part describes how prior knowledge applies to new system. If we > would take Pharo as new system, then principle is finally busted > because I never saw such behaviour anywhere else - it was invented in > spotter. If new system would be spotter in context of Pharo, then > still violated as clicking on arrow is not used anywhere else in Pharo. > If you put a little triangular icons on top of the arrow then people will certainly undertsand that they can click on it. My point is ask yourself why many people do not know how to open the pane. I could not find it. Once I got it I asked around and really few people know it. > > Possible way to fix familiarity principle is to spread usage of arrow > to the whole Pharo (or world) or to modify its design to improve > guessability by adding preview icon/label/whatever on the arrow. > > b) Generalizability. Meaning that user can extend specific interaction > knowledge to new situations. Clicking on arrow is only used in one > place in spotter - so there is no chance for user to extend not > existing knowledge. Violated. > > Fix is similar to familiarity - clicking on arrow to expand/open new > pane should be used in more places. > I do not think. > c) Predictability. Consists of determinism and operation visibility. > Determinism is not violated because effect of clicking on arrow can be > immediately observed by user. However, operation visibility is > violated - arrow does not change depending whether preview is > available or not. > > To fix operation visibility we need to change arrow color/icon > depending on availability of preview. > You do not reply to the point that to see that I can interact with a group of element I have to select the first one. Currently it only work because some people use arrows. I never because there are at the bottom of my keyboard. > d) Synthesisability. Not violated - user can easily observe effect of > past operations. Preview has only two states: on and off. > > e) Consistency. We can not say anything, because there are no similar > situations in the system. > > To conclude, an action to open preview should be improved. The most > easiest fix would be to add something on top of arrow to make it > obvious (improve guessability) what clicking does. > yes to improve the fact that we may click on something. > > More preferred one IMHO is to expose arrow usecases and teach users so > that generalizability would start playing a role. > I do not get it. You should understand that Pharo can be used with a mouse. > > Sorry for long email > Alex > > > > Le 20/1/16 14:30, Aliaksei Syrel a Ã©crit : >> On Wed, Jan 20, 2016 at 12:59 PM, Ben Coman <btc(a)openinworld.com >> <mailto:btc@openinworld.com>> wrote: >> >> +1. Its annoying that it takes two clicks to dive into categories >> like "Implementors" (one to click an item under the category to >> make the arrow appear, and then another to click on it) when it >> would only take one if that arrow for each category was always >> visible. >> >> >> Doru is right, always visible arrows would pollute UI. > I do not see why. > A user interface is not something that we should click randomly at to > learn how to use it. > >> A compromise solution would be to show them on mouse hover - one >> click + not overcrowded interface. > > may be > but you can ask yourselves why so many people do not get how to use > Spotter. > I asked again today to people how to show the pane on the right and > nobody knew obviously. >> >> Cheers, >> Alex >

Jan. 22, 2016

Re: [Pharo-dev] another spotter question

by David Allouche

> On 22 Jan 2016, at 10:23, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Sorry for long email > I found it rather short and synthetic ;-) At least compared to my recent messages.

Jan. 22, 2016

Re: [Pharo-dev] another spotter question

by Aliaksei Syrel

Hi Stef I saw an early version of Spotter with arrows near each item and it was IMHO awful. But still, pencils taste differently for each of us ;) I can agree with you that people "do not get how to use spotter". However it depends on how we define "use spotter". From my prospective almost all do understand how to use main feature: searching. I think the whole discussion is about more advanced features. Let's talk about how to open preview(pane to the right) in context of learnability which consists of multiple design principles. During our analysis we will try to determinate violated ones and see how they can be fixed. a) Familiarity. It consists of guessability which is surely violated - I can not imagine anyone who could guess that in order to open preview she should click on arrow to the right of the item (I talk about intentional click, not random one to see what will happen). Second part describes how prior knowledge applies to new system. If we would take Pharo as new system, then principle is finally busted because I never saw such behaviour anywhere else - it was invented in spotter. If new system would be spotter in context of Pharo, then still violated as clicking on arrow is not used anywhere else in Pharo. Possible way to fix familiarity principle is to spread usage of arrow to the whole Pharo (or world) or to modify its design to improve guessability by adding preview icon/label/whatever on the arrow. b) Generalizability. Meaning that user can extend specific interaction knowledge to new situations. Clicking on arrow is only used in one place in spotter - so there is no chance for user to extend not existing knowledge. Violated. Fix is similar to familiarity - clicking on arrow to expand/open new pane should be used in more places. c) Predictability. Consists of determinism and operation visibility. Determinism is not violated because effect of clicking on arrow can be immediately observed by user. However, operation visibility is violated - arrow does not change depending whether preview is available or not. To fix operation visibility we need to change arrow color/icon depending on availability of preview. d) Synthesisability. Not violated - user can easily observe effect of past operations. Preview has only two states: on and off. e) Consistency. We can not say anything, because there are no similar situations in the system. To conclude, an action to open preview should be improved. The most easiest fix would be to add something on top of arrow to make it obvious (improve guessability) what clicking does. More preferred one IMHO is to expose arrow usecases and teach users so that generalizability would start playing a role. Sorry for long email Alex Le 20/1/16 14:30, Aliaksei Syrel a Ã©crit : On Wed, Jan 20, 2016 at 12:59 PM, Ben Coman <btc(a)openinworld.com> wrote: > +1. Its annoying that it takes two clicks to dive into categories like > "Implementors" (one to click an item under the category to make the arrow > appear, and then another to click on it) when it would only take one if > that arrow for each category was always visible. Doru is right, always visible arrows would pollute UI. I do not see why. A user interface is not something that we should click randomly at to learn how to use it. A compromise solution would be to show them on mouse hover - one click + not overcrowded interface. may be but you can ask yourselves why so many people do not get how to use Spotter. I asked again today to people how to show the pane on the right and nobody knew obviously. Cheers, Alex

Jan. 22, 2016

Re: [Pharo-dev] Spotter suggestions

by David Allouche

> On 21 Jan 2016, at 22:36, stepharo <stepharo(a)free.fr> wrote: > > Le 20/1/16 10:39, David Allouche a Ã©crit : >> Since you asked to keep challengingâ¦ >> >> Preamble: Sorry, I did one of those long messages again. I hope I am not annoying people with that. > > Not at all thanks for sharing that. > I appreciate that you take the time to write it because I'm a lot more intuitive and have not the time > fully develop my gut feeling. So I sound harsh and at the end I do not use the features. > And people get sad when I say it. Thanks for the kind words. :-) I hope that will motivate Tudor to read my messageâ¦

Jan. 22, 2016

[ann] spotter processors as settings

by Tudor Girba

Hi, We now have a new little feature in Spotter. Take a look: Basically, you will get a setting for each processor defined in the image. This happens dynamically. If you disable the setting, the processor will not be available anymore. Please give this a try and let us know what you think. We would also like a code review related to the way we deal with dynamic settings. Right now, the magic is done in GTSpotterExtensionSettings (this is real magic - read the class comment), but the current solution relies on a doesNotUnderstand: to maintain the list of disabled processors. I would more prefer it if we could create a DynamicSettingDeclaration that would be able to pass arguments to one central selector. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

Jan. 22, 2016

Re: [Pharo-dev] Pharo bootstrap

by phil＠highoctane.be

Craig, Apologies for being blunt, but supercool stuff that I know about but am not able to use is not of any use to me. >From my perspective, I am very frustrated to not be able to use: - Context in Pharo - Your remote running of tiny images in my Pharo browser (including the sonar ping sound when messages are landing remotely) - Using WebDav for looking into my images using your WebDav component That's a hell of a lot of super great tech that hasn't seen the light of day in the Pharo community (think being able to explore the image as a filesystem, edit the methods in Vim in a terminal [yes, this is actually cool to me], drag and drop binaries in these folders to import/export binary resources into the image). It is frustrating to see that what could turn into a superb capability of the tooling is running on your box but is not available for use by us (me) the common people. It is your code, you do what you want. I'd live to see it running (even super badly, which I don't think would be the case) on Pharo. Peace, Phil On Thu, Jan 21, 2016 at 7:39 PM, Craig Latta <craig(a)netjam.org> wrote: > > Hi Phil-- > > > ...prior art is not running on my environment. So, it is irrelevant > > for my current activities. > > You weren't talking about your current activities before, you were > talking about some allegedly innovative capability. > > At any rate, I do have versions of Context for Pharo and other > Smalltalks, which I intend to release this year. I wanted to deal with > SqueakJS after Squeak, then Pharo, then VisualWorks, etc. > > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > >

Jan. 22, 2016

Re: [Pharo-dev] another spotter question

by Ben Coman

On Fri, Jan 22, 2016 at 5:27 AM, stepharo <stepharo(a)free.fr> wrote: > > > Le 20/1/16 14:30, Aliaksei Syrel a Ã©crit : > > On Wed, Jan 20, 2016 at 12:59 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> +1. Its annoying that it takes two clicks to dive into categories like >> "Implementors" (one to click an item under the category to make the arrow >> appear, and then another to click on it) when it would only take one if that >> arrow for each category was always visible. > > > Doru is right, always visible arrows would pollute UI. > > I do not see why. > A user interface is not something that we should click randomly at to learn > how to use it. > > A compromise solution would be to show them on mouse hover - one click + not > overcrowded interface. > > > may be > but you can ask yourselves why so many people do not get how to use Spotter. > I asked again today to people how to show the pane on the right and nobody > knew obviously. For a while I have thought it would benefit from a thin grey triangle line, just to add a bit more feature to draw the attention. cheers -ben

Jan. 22, 2016

Re: [Pharo-dev] Use cases for methods with optional parameters

by Ben Coman

On Wed, Jan 20, 2016 at 11:08 PM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > Hi, > > I would like to study the impact of adding optional parameters to > keyword methods in Pharo. The goal of optional parameters is to > facilitate the implementation of methods where some parameters are > optional. For example, Seaside has: > > WAComponent>>request: aRequestString label: aLabelString > default: aDefaultString onAnswer: aBlock > > ... > > This method of 4 arguments has only 1 required argument (aRequestString) > and 3 optional ones. In the current implementation, this results in 7 > additional methods that only delegate directly or indirectly to the one > above: > > - request: > - request:default: > - request:default:onAnswer: > - request:label: > - request:label:default: > - request:label:onAnswer: > - request:onAnswer: > > Before starting to implement anything, I need to know if it makes sense. > If you want to help me, please send me all the use cases you have by > giving me: > > - the library name (and URL if not in Catalog), or "pharo" if it's in > Pharo > - the class where this happens > - the range of selectors that make sense > > For the example above, this would be: > > - Seaside > - WAComponent > - request:* I don't have any use cases right now, but I'll keep my eyes open. But an example (that is maybe too basic to mess with) is the #at:ifAbsent: pattern. For example, the following would be "deleted" Dictionary>>.at: key ^ self at: key ifAbsent: [self errorKeyNotFound: key] and you would only have.... Dictionary>>at: key ifAbsent: aBlock <optional: ifAbsent default: [ self errorKeyNotFound: key]> The big in-Image example would be... TClass>> subclass: aName uses: aTraitCompositionOrArray instanceVariableNames: someInstanceVariableNames classVariableNames: someClassVariableNames poolDictionaries: someSharedPoolNames package: aCategory <optional: uses default: {}> <optional: instanceVariableNames default: ''> <optional: classVariableNames default: ''> <optional: poolDictionaries default:''> <optional: package 'Unclassified'> Now I wonder about senders & implementers searchability, and if "virtual" methods are generated in all combinations of optional parameters and show up in the system browser list, but show the "main" method as their source. Maybe it works a little like traits. cheers -ben

Jan. 22, 2016

Re: [Pharo-dev] Pharo bootstrap

by Craig Latta

> > I am pretty sure that the people behind the Pharo Bootstrap project > > are aware of the existing literature. > > oh yes and even of things that were not written in papers. :) Papers are no longer the only way to publish, and paper-writers are still obligated to cite prior work however they become acquainted with it. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 21, 2016