Something that might be interesting then would be for you to go through modelabs primer and document what you think is missing. It might be helpful for mcneel’s future documentation, and also so that they don’t invest time reinventing the documentation there already (or maybe they can just buy rights to modelabs primer and edit/adapt from there).
Hi Brenda,
I have zero experience in programming and absolutely no math background, just a fascination with the world of algorithmic design that Grasshopper has opened up for me. Since I’m busy as a guitarmaker I also have limited study time .
I started by buying Luis Fraguada’s video tutorial series “Visual Programming in Rhino3D with Grasshopper” to jumpstart a basic understanding of how to start putting some of the pieces together. This was tremendously helpful, and I still go back sometimes to review.
Next I started watching discourse for examples I could work through making things that interested me.
Concurrently I started trying to incorporate instanced Rhino objects in simple GH definitions.
Finally I have started building stuff I really need so I can’t back down.
I have a long. long way to go, and sometimes I have to remind myself I am having fun but slowly the door is opening.
Like you said, everyone learns differently.
1 Like
David,
Have you all considered using a wiki-based documentation system for grasshopper 2? I’m imagining something that if you right-click on a component, a web-based wiki would come up. The main page would contain a crowd-sourced explanation of the component with links to downloadable files or links out to external sources (wikipedia, academic papers, plugins, etc.). The discussion page would essentially be registered Rhino forum users discussing the component’s function and best practices similar to the wikipedia discussion pages for each entry. Editors who approve changes to the main page for each component could be made up of a few McNeel employees and select superusers who have contributed a lot over the years to the forum/Ning site. McNeel could establish certain templates for the type of content that a help page would need to have and then let the Grasshopper community complete it. This way the Help docs are live and can be updated by the community with new changes to Grasshopper.
Somewhat, depends a bit on your definition of what a wiki is.
What we want to achieve is:
- Completely open system so plug-ins (or anyone really, not just 3rd party developers) can supply their own documentation and that content just becomes an integral part of the whole while it’s installed.
- All source material is directly available for editing by anyone who wishes. Translations, study course material, in-office documentation, … you name it, someone can add it.
- Auto-generate as much content as possible from the runtime information.
- Provide explanations and an example file for each component. In reality I imagine the same example file will be re-used to explain several components, that just massively reduces the workload and makes sense in general. We imagine these files to be relatively small. Not quite as summary as the tooltip-aggregate in GH1 help files, but not much bigger either. Think of these as an academic-paper-abstract length and depth.
- Provide more in depth content about specific topics. What is surface parameterisation? How does data-tree notation work? What is a CieL*A*B* colour space? What is the runtime-complexity of a fixed-radius Poisson sampling? Think of these as essay length and depth.
- Provide a comprehensive glossary of terms. One liners really, with links to relevant topics.
- It has to work off-line.
As for the implementation, the idea is that a body of documentation is just all the files in a specific folder. There will be a bunch of text files with the *.term extension for glossary entries, some *.topic files and of course various images and *.ghz example files. Each of those files is loaded and interpreted when viewed, so nothing is pre-compiled into proprietary or obscure formats. It will not however be editable ‘in-situ’, which is what most wikis are.
So for example a *.term file is just plain text which looks like this:
# Data written on Friday, January 18, 2019 at 17:12:34.
Word: Word (ignored, the filename is the actual word)
Definition: The smallest unit of language containing meaning. Words often have _synonyms_, i.e. other words which have a similar or even identical meaning, as well as _antonyms_ which are words with opposite meanings.
Furthermore words can have multiple meanings all of their own, which makes translating a text into another language very difficult.
If you wish to find the various meanings of words, use a _dictionary_. If however you wish to find synonyms or antonyms, you must use a _thesaurus_.
IPA: /wɜːd/
Internal:
External: [Dictionary.com](https\://www.dictionary.com/browse/word)|[Thesaurus.com](https\://www.thesaurus.com/browse/word)|[Wiktionary.org](https\://en.wiktionary.org/wiki/word)
Author: Robert McNeel & Associates (c) 2019
Notes: This is a test project glossary term.
which can either be edited directly in Notepad or GitHub, or you can use the standalone editor we provide:
5 Likes
Looks perfect. I can see how that would be a ton of work. Good luck and let us know how we can help.
If I may chime in, it would help to also have a few pictures and ideograms, as well, such as a image the current component icon, and some helper graphics, sort of like Rhinos current help system.
I think that Grasshopper is a excellent and well-thought out tool, worthy of further integration and teaching resources. Further integration might also benefit from a reduction of size and startup time by using Rhino3D’s bar and icon services, as well reducing menu code, such as the color picker, in that there need be only one.
To sum up, and it’s not my place to speak for everyone, but I am for Grasshopper; even if it was an experiment, it was one that works.