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?
It’s definitely a skill, and once we switch to vector/shader based icons then we can render them crisply at any zoom level.
Too big of a breaking change at this point.
Because the length of a component would then become highly variable, much more so than the height is under current conditions. This in turns means a lot of wasted pixels per component above and below the name. Not to mention that the spacing between adjacent component will have to be adjusted all the time because the width of components changes all the time.
That’s not going to happen. Vertical slides
[Feature Request] Vertical oriented GH definitions
So the solution to names being too hard to read is to not display them? Pretty Gordian… If it makes sense to pick a smaller font size then we should do that regardless.
That’s sort of the direction in which I’m going. Except I’d prefer components to look simple yet recognisable at default zoom, and start displaying more details as you zoom in.
I wonder if something like this might be of any value. NOTE: I have zero idea of what this might break…but I’ll throw these out there…
1 - I think a future version of YAK will probably make this less than useful, but maybe a flyout/collabpsible menu on the left side of the canvas with links to any plug-ins used, (predicated on some standard/code addition plug-in authors would need to add)
2 - A new type of panel that could include image/icons? Authors of definitions could use something like this “GetComponents2” compnent, and it could write all the used components to some type of legend?
(NOTE: I wrote the “GetComponents2” component for internal use)
All of this seems a bit heavyhanded…and outside of solving a problem of being able to deciper which components were used, based on a screen shot of a definition that displays icons…there might be diminishing returns on this idea…
This in general is a bit weird. Either someone wants to share the file in which case they can share the actual file, or at least provide an image with the required information, or someone doesn’t want to share the file in which case what business is it of yours to try and reverse engineer it?
There is clearly a conflict of interest here; why make an image of your file public at all if you don’t wish to share it? But in terms of actually sharing data, that is already perfectly possible.
ps. I don’t mean ‘you’ specifically @chanley, I meant ‘you’ in the generic.
No worries @DavidRutten. I agree. I think the simple version is like you said…just share the file!
ps. for the record…I prefer icons 
pps…I do think a new panel type that supported icons/symbols or something would be pretty rad.
