Ok I want to find all the implementors that contain the word time. I type time and I see #implementors as shown in the attachement. How do I get the full list of such methods? I have the impression that I will have to retype the query with #implementors. Now I do not get why I cannot click on the label #implementors it feels like behind a glass and getting frustrated. Stef
Hi,
On Jan 19, 2016, at 6:11 PM, stepharo <stepharo@free.fr> wrote:
Ok I want to find all the implementors that contain the word time. I type time and I see #implementors as shown in the attachement. How do I get the full list of such methods?
I have the impression that I will have to retype the query with #implementors. Now I do not get why I cannot click on the label #implementors
it feels like behind a glass and getting frustrated.
Hmm. Thanks for describing this way of working. Here is the thing. We observed users working with this, and they all used predominantly the keyboard. So, we favored keyboard use. This is not an argument for anything, and it does not mean that that is the best design, I am just telling you how we designed it. Things can change, and this is why it is important to understand how people tend to use the UI. So, every (and only) selection has actions. In your example, the #Menu category has a right arrow next to it. If you click on that you âDive in categoryâ. That means that if you want to dive in #Implementors, you navigate there, and then you get the option of diving in. We consciously chose to not show all actions all the time because that would have led to an overcrowded UI with too many things to choose from. Right now, you have 5 main things to click on and that is it. Now, hearing your scenario, it seems to make sense to make the category clickable as well and make it dive in that category. We will look at it (or maybe someone else does it beforehand :)). Thanks. Does this make more sense now? Doru
Stef
<icfedjib..png>
-- www.tudorgirba.com www.feenk.com "When people care, great things can happen."
Hmm. Thanks for describing this way of working.
Here is the thing. We observed users working with this, and they all used predominantly the keyboard. So, we favored keyboard use. This is not an argument for anything, and it does not mean that that is the best design, I am just telling you how we designed it. Things can change, and this is why it is important to understand how people tend to use the UI.
So, every (and only) selection has actions. In your example, the #Menu category has a right arrow next to it. If you click on that you âDive in categoryâ. That means that if you want to dive in #Implementors, you navigate there, and then you get the option of diving in.
We consciously chose to not show all actions all the time because that would have led to an overcrowded UI with too many things to choose from. Right now, you have 5 main things to click on and that is it.
Now, hearing your scenario, it seems to make sense to make the category clickable as well and make it dive in that category. We will look at it (or maybe someone else does it beforehand :)). Thanks.
Does this make more sense now?
Yes! I do not get why keyboard is orthogonal to direct access. To me what I hate in UI is UI that are showing information but do not let you access it. How can I see that I can do something on the list? The arrows only arrive when I click on ........ So I was trying to click on the label and it did not work. Of course I must click on the first element of the list so that the arrow show up on the element and the label!!!!! What??? Seriously doru. You should have asked UI blind like me to test Spotter. I would have recorded a session and you can see that there are glitches that you do not even see. I'm just continuously bumping on them. This is why I could understand Spotter and use it only to find a class. This is why I like the grabbing possibility of file on mac via the icons and the navigation from there because I see the file it is in front of my nose and I do not to jump into a file system (like a mail download folder I have no clue where it is) to grab it. So to me Spotter should offer the same. Show information and let me grab it. Especially when this is on the suggstion list. I do not understand how you solve the problem I got with shortcut btw. You see the point is the following. Diving can be frustrating. If on click on the labl you get the list then it can work really well.
Doru
Stef
<icfedjib..png> -- www.tudorgirba.com www.feenk.com
"When people care, great things can happen."
I also struggle with Spotter, I learn something new all the time. I also use Spotter all the time. I understand that there is great value in starting from a couple of simple principles and see how they can combine in many different ways. Something with good internal logic is easier to explain, use, maintain, evolve. Spotter is quite different than the other tools that we had before, for me it feels more like the Google search field. It is not possible to have a totally obvious interface, no more than a code browser or a debugger, or programming can be self explaining. Of course, we should try to make it better if we can. I am very happy that we have something as powerful and advanced as Spotter (and its family). I think we are totally on the right track.
On 19 Jan 2016, at 20:30, stepharo <stepharo@free.fr> wrote:
Hmm. Thanks for describing this way of working.
Here is the thing. We observed users working with this, and they all used predominantly the keyboard. So, we favored keyboard use. This is not an argument for anything, and it does not mean that that is the best design, I am just telling you how we designed it. Things can change, and this is why it is important to understand how people tend to use the UI.
So, every (and only) selection has actions. In your example, the #Menu category has a right arrow next to it. If you click on that you âDive in categoryâ. That means that if you want to dive in #Implementors, you navigate there, and then you get the option of diving in.
We consciously chose to not show all actions all the time because that would have led to an overcrowded UI with too many things to choose from. Right now, you have 5 main things to click on and that is it.
Now, hearing your scenario, it seems to make sense to make the category clickable as well and make it dive in that category. We will look at it (or maybe someone else does it beforehand :)). Thanks.
Does this make more sense now?
Yes! I do not get why keyboard is orthogonal to direct access.
To me what I hate in UI is UI that are showing information but do not let you access it.
How can I see that I can do something on the list? The arrows only arrive when I click on ........ So I was trying to click on the label and it did not work. Of course I must click on the first element of the list so that the arrow show up on the element and the label!!!!!
What???
Seriously doru. You should have asked UI blind like me to test Spotter. I would have recorded a session and you can see that there are glitches that you do not even see. I'm just continuously bumping on them. This is why I could understand Spotter and use it only to find a class.
<adhaefha..png>
This is why I like the grabbing possibility of file on mac via the icons and the navigation from there because I see the file it is in front of my nose and I do not to jump into a file system (like a mail download folder I have no clue where it is) to grab it. So to me Spotter should offer the same. Show information and let me grab it. Especially when this is on the suggstion list.
I do not understand how you solve the problem I got with shortcut btw.
You see the point is the following. Diving can be frustrating. If on click on the labl you get the list then it can work really well.
Doru
Stef
<icfedjib..png>
--
www.tudorgirba.com www.feenk.com
"When people care, great things can happen."
Yes me too but - discoverability should be improved - a nice way to know if you are right is that students with 1 hour lecture in Pharo can use it because this is what I do. I give a lecture and ask them to code one class. - also writing doc for dummies is good because you have to write and explain how such tools are working. Stef Le 19/1/16 21:36, Sven Van Caekenberghe a écrit :
I also struggle with Spotter, I learn something new all the time.
I also use Spotter all the time.
I understand that there is great value in starting from a couple of simple principles and see how they can combine in many different ways. Something with good internal logic is easier to explain, use, maintain, evolve.
Spotter is quite different than the other tools that we had before, for me it feels more like the Google search field.
It is not possible to have a totally obvious interface, no more than a code browser or a debugger, or programming can be self explaining. Of course, we should try to make it better if we can.
I am very happy that we have something as powerful and advanced as Spotter (and its family). I think we are totally on the right track.
On 19 Jan 2016, at 20:30, stepharo <stepharo@free.fr> wrote:
Hmm. Thanks for describing this way of working.
Here is the thing. We observed users working with this, and they all used predominantly the keyboard. So, we favored keyboard use. This is not an argument for anything, and it does not mean that that is the best design, I am just telling you how we designed it. Things can change, and this is why it is important to understand how people tend to use the UI.
So, every (and only) selection has actions. In your example, the #Menu category has a right arrow next to it. If you click on that you âDive in categoryâ. That means that if you want to dive in #Implementors, you navigate there, and then you get the option of diving in.
We consciously chose to not show all actions all the time because that would have led to an overcrowded UI with too many things to choose from. Right now, you have 5 main things to click on and that is it.
Now, hearing your scenario, it seems to make sense to make the category clickable as well and make it dive in that category. We will look at it (or maybe someone else does it beforehand :)). Thanks.
Does this make more sense now?
Yes! I do not get why keyboard is orthogonal to direct access.
To me what I hate in UI is UI that are showing information but do not let you access it.
How can I see that I can do something on the list? The arrows only arrive when I click on ........ So I was trying to click on the label and it did not work. Of course I must click on the first element of the list so that the arrow show up on the element and the label!!!!!
What???
Seriously doru. You should have asked UI blind like me to test Spotter. I would have recorded a session and you can see that there are glitches that you do not even see. I'm just continuously bumping on them. This is why I could understand Spotter and use it only to find a class.
<adhaefha..png>
This is why I like the grabbing possibility of file on mac via the icons and the navigation from there because I see the file it is in front of my nose and I do not to jump into a file system (like a mail download folder I have no clue where it is) to grab it. So to me Spotter should offer the same. Show information and let me grab it. Especially when this is on the suggstion list.
I do not understand how you solve the problem I got with shortcut btw.
You see the point is the following. Diving can be frustrating. If on click on the labl you get the list then it can work really well.
Doru
Stef
<icfedjib..png>
--
www.tudorgirba.com www.feenk.com
"When people care, great things can happen."
On Wed, 20 Jan 2016 at 3:37 AM stepharo <stepharo@free.fr> wrote:
Hmm. Thanks for describing this way of working.
Here is the thing. We observed users working with this, and they all used predominantly the keyboard. So, we favored keyboard use. This is not an argument for anything, and it does not mean that that is the best design, I am just telling you how we designed it. Things can change, and this is why it is important to understand how people tend to use the UI.
So, every (and only) selection has actions. In your example, the #Menu category has a right arrow next to it. If you click on that you âDive in categoryâ. That means that if you want to dive in #Implementors, you navigate there, and then you get the option of diving in.
We consciously chose to not show all actions all the time because that would have led to an overcrowded UI with too many things to choose from. Right now, you have 5 main things to click on and that is it.
Now, hearing your scenario, it seems to make sense to make the category clickable as well and make it dive in that category. We will look at it (or maybe someone else does it beforehand :)). Thanks.
Does this make more sense now?
Yes! I do not get why keyboard is orthogonal to direct access.
To me what I hate in UI is UI that are showing information but do not let you access it.
How can I see that I can do something on the list? The arrows only arrive when I click on ........ So I was trying to click on the label and it did not work. Of course I must click on the first element of the list so that the arrow show up on the element and the label!!!!!
What???
Seriously doru. You should have asked UI blind like me to test Spotter. I would have recorded a session and you can see that there are glitches that you do not even see. I'm just continuously bumping on them. This is why I could understand Spotter and use it only to find a class.
This is why I like the grabbing possibility of file on mac via the icons and the navigation from there because I see the file it is in front of my nose and I do not to jump into a file system (like a mail download folder I have no clue where it is) to grab it. So to me Spotter should offer the same. Show information and let me grab it. Especially when this is on the suggstion list.
I do not understand how you solve the problem I got with shortcut btw.
You see the point is the following. Diving can be frustrating. If on click on the labl you get the list then it can work really well.
Doru
Stef
<icfedjib..png>
--www.tudorgirba.comwww.feenk.com
"When people care, great things can happen."
On Wed, 20 Jan 2016 at 3:37 AM stepharo <stepharo@free.fr> wrote:
Hmm. Thanks for describing this way of working.
Here is the thing. We observed users working with this, and they all used predominantly the keyboard. So, we favored keyboard use. This is not an argument for anything, and it does not mean that that is the best design, I am just telling you how we designed it. Things can change, and this is why it is important to understand how people tend to use the UI.
So, every (and only) selection has actions. In your example, the #Menu category has a right arrow next to it. If you click on that you âDive in categoryâ. That means that if you want to dive in #Implementors, you navigate there, and then you get the option of diving in.
We consciously chose to not show all actions all the time because that would have led to an overcrowded UI with too many things to choose from. Right now, you have 5 main things to click on and that is it.
Now, hearing your scenario, it seems to make sense to make the category clickable as well and make it dive in that category. We will look at it (or maybe someone else does it beforehand :)). Thanks.
Does this make more sense now?
Yes! I do not get why keyboard is orthogonal to direct access.
To me what I hate in UI is UI that are showing information but do not let you access it.
How can I see that I can do something on the list? The arrows only arrive when I click on ........ So I was trying to click on the label and it did not work. Of course I must click on the first element of the list so that the arrow show up on the element and the label!!!!!
+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. cheers -ben
What???
Seriously doru. You should have asked UI blind like me to test Spotter. I would have recorded a session and you can see that there are glitches that you do not even see. I'm just continuously bumping on them. This is why I could understand Spotter and use it only to find a class.
This is why I like the grabbing possibility of file on mac via the icons and the navigation from there because I see the file it is in front of my nose and I do not to jump into a file system (like a mail download folder I have no clue where it is) to grab it. So to me Spotter should offer the same. Show information and let me grab it. Especially when this is on the suggstion list.
I do not understand how you solve the problem I got with shortcut btw.
You see the point is the following. Diving can be frustrating. If on click on the labl you get the list then it can work really well.
Doru
Stef
<icfedjib..png>
--www.tudorgirba.comwww.feenk.com
"When people care, great things can happen."
On Wed, Jan 20, 2016 at 12:59 PM, Ben Coman <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. A compromise solution would be to show them on mouse hover - one click + not overcrowded interface. Cheers, Alex
Le 20/1/16 14:30, Aliaksei Syrel a écrit :
On Wed, Jan 20, 2016 at 12:59 PM, Ben Coman <btc@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
On Fri, Jan 22, 2016 at 5:27 AM, stepharo <stepharo@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@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
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@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
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@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
I was talking about clickable arrow to open preview ;) On Jan 22, 2016 10:47 AM, "stepharo" <stepharo@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@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
I think that it is really hard to figure out that the arrow is clickable if you do res shift and see it highlighted. I mean, it doesnât look like a button or anything special⦠Cheers! Uko
On 22 Jan 2016, at 11:08, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
I was talking about clickable arrow to open preview ;)
On Jan 22, 2016 10:47 AM, "stepharo" <stepharo@free.fr <mailto:stepharo@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 < <mailto:btc@openinworld.com>btc@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
<IMG_20160122_110543.jpg>
Le 22/1/16 11:08, Aliaksei Syrel a écrit :
I was talking about clickable arrow to open preview ;)
Ok I thought that you also talked about the other. For this one, I would just put a little triangular icon on top and going the in same orientation because then this is clear that this is a kind of button.
On Jan 22, 2016 10:47 AM, "stepharo" <stepharo@free.fr <mailto:stepharo@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@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
On 22 Jan 2016, at 11:08, Aliaksei Syrel <alex.syrel@gmail.com> wrote:
I was talking about clickable arrow to open preview ;)
Oh wow! I had no idea you click that area to toggle the preview! Even with the shift hints. At the very least, it needs something more in the shift hints than just a change in background color!
participants (7)
-
Aliaksei Syrel -
Ben Coman -
David Allouche -
stepharo -
Sven Van Caekenberghe -
Tudor Girba -
Yuriy Tymchuk