Grasshopper

algorithmic modeling for Rhino

I love the GH discussion forum for finding answers to in depth questions however, a traditional help document (F1) would be more effective at times, particularly for beginners.  I also am well aware that the reason there is not a traditional help document for GH is largely an economic one. Since GH is currently free and continues to change (read: improve) it is difficult to expend the additional energy necessary to generate (and keep current) a help document.  I must say I agree with the McNeel decision to put all their available capital energy into advancing the functionality of GH rather than spending it on creating a help system.  

 

However, I have an idea that could benefit GH, its users, as well as its developer, in a major way.  Is there a way for the users of GH to "give back" to GH by producing an open source help document.  Surely there is some internet tool that would enable the users to easily draft and edit a help document.  Something similar to wikipedia with edit-ability.  The idea is for each GH user to pick a single component to research; i.e., create examples of, document syntax requirements, explain the components uses, and link to relevant discussion forum articles. 

 

With as many users as there are, it seems like no one would have to do too much.  If everyone did just a small portion, the help document would get done.  Then over time it could be refined over time by the same community.   I am not sure how to organize such an effort.  Does anyone have any thoughts about the viability of a community written help document?  Has it been done before?  Are there any online tools particularly suited to producing a help document format that would facilitate the logistic of a project like this? Does anyone else see a need for a traditional help document?

 

Stan

 

Views: 2106

Replies to This Discussion

agreed I also wish there was a place on GH to access ghuser files. Like how sketch-up has the 3d warehouse.

maybe "food4grasshopper"

 

 

We were thinking about a wiki a while back.  http://www.grasshopper3d.com/forum/topics/grasshopper-changes-so-much

 

We could do ghwiki.mcneel.com...

 

Nice idea!

 

But...I have some experience in wiki management in a research group and the hardest work was find a layout to fit the content inside. The first thing to do is to write a stylesheet and some rules to publish new information. 

 

Then, we need to find a correct tree or not-tree structure to index help chapters, examples, theory pages (geometry theory related to some tools, plugins, etc...) and whatever...

 

The third thing to do is write and share our knowledge...and try to put our best here.

 

I like the idea...I told the same in the post that Luis links.

Luis,

The older I get, the more I am convinced there is no such thing as a completely new idea.  The more multiple people are independently enlightened with the same idea the more it reinforces the validity of that idea.  I think you were definitely on to something almost a year ago.  It does seem that if a similar amount of energy went into a help document as goes into responding to this forum the help document would be written in a short time.  As a result, the questions submitted to the forum would most likely reduce because the help document would have answered a great many of the questions.

 

Angel, 

I am happy you have experience in such an effort.  You have a laser focus on the first key steps.  I like your idea of the style sheet and an index as a framework to maintain some consistency.  It would be nice if people could sign up for a particular topic and the index could show a place holder for the responsible person for each specific topic so no one else would waste their time trying to work on the same topic that someone had already committed to. 

 

Stan

http://wiki.mcneel.com/grasshopper/home/documentation

Now we just need some instructions on how to edit...

 

Angel, I think the McNeel system has all sorts of style already in place...later this wiki format can be rendered over here on grasshopper3d.com. 

 

Where do we start with the categories?

 

How about using the component tab headings?

Chris

then sub categories of panels

These both sound like a natural place to start.  Does anyone have a listing of Tab Headings, sub categories, and components.  If not, I will just start typing these up to create a start of an index.

 

Stan

 

 

Go to the Help Menu and export help. In the folder that you choose for the help files you will find a Summary sheet with a list of all components

Ok, this structure is fine for a 'Components Overview.'  I could see each component explained ina way which is already like in the help file, but maybe with an example or examples of how to use it ala the Rhinoscript help doc.

 

There are other areas we need to cover...

Functionality / Usage /GUI

Data Types

Data Structures / Data Topology

to name a few...

That topics could be linked to related components (data topology || path mapper)...but we need a big bag to put inside generic (not component related) topics. I propose divide help content in: theory/basic knowledge, components and GUI explanation and link later some topics to others.

If I try to find something related to path mapper I'll find the component description and usage (inputs/outputs, usage, ...)and links to data topology theory, links to example files (forum files)...

What do you think about guys?

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service