Why the icons use in grasshopper tutorials and not the full names display mode?

grasshopper
python

#1

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?


(Aris Nikolopoulos) #2


#3

Lol ok I see its an ongoing crisis.


(Aris Nikolopoulos) #4

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.


#5

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!


#6

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.).


(David Rutten) #7

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.


#8

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


(David Rutten) #9

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.


(Michael Pryor) #10

(GH2 will support vector and shader based icons,

+1


#11

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


#12

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.


(David Rutten) #13

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.


#14

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


#15

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.


(David Rutten) #16

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.


#17

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. :slight_smile:

GH is better than many people understand. :slight_smile:

// Rolf


(David Rutten) #18

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:

  • Use a named group.
  • Override the nickname and make sure display is set to show the nickname.
  • Place a text panel near the components with a comment.
  • Place a scribble near the components with a comment.

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.


#19

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


(Tom) #20

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?