Hi All
I want to start a discussion around Icon use in tutorials in grasshopper.
Why would anyone whose aim it is to share grasshopper want to make life so difficult for people learning grasshopper?
I spend hours trying to figure out what this or that icon means. Wouldnt it be simpler in tutorials at least to use the draw full names display mode?
Or at least be very clear what the icon means in the text that accompanies the tutorials.
thoughts?
Lol ok I see its an ongoing crisis.
I donāt know if itās a crisis but people have different tastes on the matter. Personally Iām an icon guyā¦
but in any case it adds a little chaos to the melody.
As far as understanding goes, usually in tutorials or posts you get the file itself which you can display any way you want.
Also, lately most people use bifocals which makes things even simpler.
Oh, and a little tip: I donāt know if you know it, but by alt+ctrl+LMB ing on a component, Grasshopper shows you where it is on the tabs.
I can understand why itās better to work using the icons but for tutorials, especially ones on the net where you cant access the files. It adds another layer of complications.
Bifocals is definitely the way forward it some of the tutorials writers out there. Thanks!
For me, icons require memorizing a completely separate mental dictionary compared to using words Iām already familiar with.
Most people? Those labels are OK but take more room on the canvas to avoid overlap. I canāt follow a model that is spread out too widely, requiring constant panning and zooming to understand whatās going on. There is an old rule of thumb in conventional programming languages that functions should never take more than a single screen (roughly 25 lines of text) so you can take it all in at a glance. There can be exceptions but generally it was better to break up the code into smaller functions (blocks, methods, procedures, etc.).
Some pros and cons as I see it:
Names are mutable so thereās no guarantee that the name visible on a component is also the name under which youāll find it on the toolbars. (Technically icons are mutable too, but almost nobody ever does this.)
Icons tend to have distinct styles, both within plug-ins and within categories. If you see āOffsetā it doesnāt tell you anything about what sort of data type weāre dealing with, whereas the icon for curve offset, surface offset, plane offset are all reasonably self-documenting.
It is difficult to read vertical text.
It is easy to search for text, not easy to search for icons (unless someone is using Chinese or Hebrew or Sanskrit or or or). Iāve been thinking about creating an icon matcher for GH which would allow you to point at an icon on your screen and it would give you the N most similar icons, but it never quite got beyond the idea stage.
Text displays crisply on all zoom levels, bitmap images do not. (GH2 will support vector and shader based icons, but I imagine some plugins will still use bitmaps.)
Icons are always the same size, text is not.
Names more easily collide with each other, it is far less likely that two icons just happen to be very similar.
Especially #2 is a problem for me. I do not like angled or vertical text and for this reason alone components will look different. I havenāt fully settled on a style yet though.
Very good points. I think its a bit selfish not to think of non-English speaking users.
Perhaps an icon search could easily be incorporated into google image search somehow.
If someone were to load the icons with the respective name (and function) onto a site with a good SEO. It would be quick to just āgoogle this image?ā
Anyway, I think Iāll just use the forum in future to ask rather than get frustrated trying to look for an icon.
Although a side benefit is that I am learning more. Whenever I have to go through all the toolbars icon hunting.
Thanks David, speaking about icons. Iāve always thought your hands in face avatar is really funny! I hope all our questions donāt drive you crazy!! lol
Most people assume itās despair, but mostly it was a compromise between the idea that itās considered professionally approachable and friendly to use your actual face and name online and me not really wanting my face to be all over the web. So itās just me hiding rather than groaning.
As for the image search, yes I did consider Google but in the end it just seemed a bridge too far. The big benefit of using an online database of icons is that it can tell you what icon it is even if you donāt have it installed. The downside is that it needs a lot of upkeep whenever new components are added.
(GH2 will support vector and shader based icons,
+1
For visual instructions, especially for new users to GH, thereās really no alternative to named components, since names are searchable. (bifocals is our friend)
It doesnāt matter if one, three or ten components show up for a search term, as long as one of them is what you are searching for.
A combination of icon and names is ideal, because then you know which one to pick from a search result.
// Rolf
The ability to rename components causes confusion when the text label no longer describes their function, but describes their āIDā in the model instead. Much better practice is to rename the inputs and outputs instead of changing the component name/text label.
Yeah thatās what Iām thinking as well. Always draw the icon, and then draw the component name as well (horizontally!) as soon as thereās sufficient space within the capsule shape. Maybe that requires slight zooming in, maybe thereās always space, maybe itās customisable.
No, it doesnāt. Names are for communication. If the message is clear, thereās no problem. This is why people use Aliases in all kinds of contexts.
A beloved child has many names. (I have seven. Children).
// Rolf
Yes, it really does. It would be fine with me if that ability were disabled. Itās equivalent to changing a componentās icon so you canāt tell what it does anymore by looking at it.
But they are also there so you can recognise things. In textual programming you get to pick the names of methods and classes you write, but itās usually impossible or at least cumbersome to rename existing elements.
There are plenty of ways to document a network, changing the names of things is only one of these, and not one Iām particularly thrilled about.
From a strict programming point of view there are good reasons for consistent naming. But the problem is related to generalization and specialization, which is very obvious especially in an environment like GrassHopper, where standard components are very āgenericā.
But in a specific context (in a network) a generic name may not even hint about what functionality a component contributes to the context. I see that all the time. (Superclass āTranslateā. But a dog is Running, and a Kangaroo is Jumping, and a ā¦ fill in). Subclasses of a generic concept. Words chnage depending on context. See more on DSL below.
And, when multiplying things, are you the āincreasingā something? Or āstrengtheningā something? Aso.
Naming things according to context is also related to a recent buzz word DDD (āDomain Driven Designā) and DLS (Domain Specific Language).
Quoting from the DDD article:
Concepts of the model include:
Context
The setting in which a word or statement appears that determines its meaning;Domain
A sphere of knowledge (ontology),
influence, or activity. The subject area to which the user applies a program is the domain of the software.
This is one of the most important, while overlooked, aspects of design processes involving IT-experts (which are using one language or ālingoā) while people with the actual domain knowledge speaks a completely different language. Hence the need for DSL.
It is not the domain experts that should adapt their language (their skills and expertice is actually defined in their language, and not in very artificial āIT-termsā that has more with computer technology or math to do than the problem domain itself.
To sum up:
The ability to rename a Multiplication component to āStrengthenā (a muscle contraction or whatever) is crucial. Itās essential in modern IT development. It even has a name - DDD or DSL. 
GH is better than many people understand.
// Rolf
I agree with all of that (and thanks for the links, I hadnāt read about this stuff before), but what is needed is to associate some string with a component, it doesnāt necessarily have to be the name that gets changed. It is also quite common for 2 or 3 or 4 components together to perform a āsingleā action and it would be nice if the method for labelling extended to small groups of components.
In Grasshopper 1.0 you have basically four options:
Well, 5 if you also include sketch curvesā¦
I am quite partial to groups, because they scale well to larger amounts of component and can be nested and colour-coded, but they could certainly be improved.
Groups has a very big potential, yes. It can easily play the role of context, a bit like words can have different menings in different sentences. Groups has potential.
// Rolf
Iām having great trouble making descriptive icons with only 24x24 pixel (could be me only).
Why not increasing them by a factor of 5. Could be shown only when hovering over, if components getting too big then. But in my opinion, such small icons hardly give any valuable feedback.
Iām not having trouble reading names flipped 90 degrees, but if this is a problem for a lot of people,
why not simply writing it from left to right then? You could argue that components width is getting to big, but if you change the wire appearance you could create definitions going from top to button instead of going from left to right. Or you limit displayed text to 10 chars only and decrease font size a bitā¦ Or you integrate both, icons and text and simply life with bigger components. Would that be such a big problem?
