Old components in Rhino 6 / GH v1.0+ obscure workings of challenge A4
Opened this issue · 6 comments
Hey Dan, thanks again for creating and uploading these challenges. I recently used GH_Challenges_A_Intro_to_Grasshopper in a class and thought I'd pass on some thoughts on possible improvements.
In this case, the newer versions of Grasshopper have deprecated the previous versions of the multiplication and subtraction components. As a result, they show up with an "OLD" banner across the title block, which happens to perfectly obscure the "-" or "x" symbols. For some people who were quite new to GH this was enough to trip them up on Challenge A4.
Not totally sure what the solution here would be; perhaps a split download for GH >1.0 vs <1.0? That sounds like a pain to maintain though.
Related to this: changes to text render in GH <1.0 mean that the panels labelling each channel (i.e. "Challenge C8") are heavily truncated which means that people don't realise there are specific labels/numbers for each challenge.
Hi @philipbelesky , thanks for these comments way back in March! It's a good point. I think I'm going to try to prioritize GH 1.0, partially because I have a great deal of students who use Rhino 6. If this turns out to be a problem, then there's at least a temporary solution of having people download previous releases from this repo.
Also - I really appreciate your comments and PRs, and would appreciate future feedback & discussion on how you've been using the challenges, and what you would change!
Agree regarding prioritising Rhino 6, particularly now that the macOS equivalent is out.
My use case for these is part of core communications/representation course we teach to students at start of their 2nd year of a Bachelor of Architectural Design. It’s relatively different to teaching computational techniques in an architectural context as we focus on parametric terrain generation/analysis and on the use of parameters to model change over time rather than design variations.
In that class we try to introduce Grasshopper quite gradually and focus on a small set of concepts/interfaces that can be used to achieve a task that relates to the assignments or a tangible design outcome. So, early on, we might look at the basics of creating/editing parameters and then use that knowledge to ‘remix’ a precedent project.
Last semester I used the Challenges here, and a few similar definitions I’d made, as part of the first half of the lesson that introduces the general mechanics/concepts, rather than having an instructor demo/describe on a projector with students follow along. Having the definition itself be ‘self-teaching’ is a great way to free up instructor’s time for targeted help, reduce the need for students to feel like they need to record what the instructor is doing, and provide a resource that can be revisited outside of class.
I’ll see if I can figure out a way to merge in some of the new Challenges I’ve made if that’s of interest - currently we use those, and your existing definitions, in quite a different order/sequence.
That sounds very interesting! Yes, I would love to see your other challenges and if you have ideas of merging them in or adding them to a different sequence.
I've also been thinking of restructuring the challenges around growing a 'vocabulary' - perhaps this is what you mean when you "focus on a small set of concepts/interfaces"?
One of the more helpful language learning processes I've had is when I tried to teach myself Arabic for a month-long trip. Among several textbooks, the most effective and helpful textbook was one that started off with a focus on two characters, and their pronunciation and related words.. and then adding another character, and then another character, gradually increasing the scope and vocabulary. In contrast, the 'learning the basics' approach was too much information all at once. This incremental approach is also akin to what Seymour Papert calls 'Microworlds', and I think restructuring or creating alternative tracks for the challenges to growing a vocabulary might be an interesting thing to do. Would love to see your challenges or merge them in if you'd like!
Also a related functionality that I've briefly talked about with Andrew Heumann is to create a testing suite for Grasshopper -- effectively creating the "Correct!" functionality as it's own thing to enable test-driven development as well as teaching..
Agree that the Papert/vocabulary approach would be very promising! In both the core course I teach, and a studio/workshop setting I've found it is really valuable to be able to compose the teaching to the scope of the task involved in a more modular fashion. As mentioned, the 'learning the basics' approach presumes a linear pathway where concepts dovetail together. However, in a studio setting, Grasshopper might be introduced just as a way of applying a particular analytic technique rather than as part of a more comprehensive parametric design process. In that case, large parts of that basic track become superfluous (e.g. creating or modifying geometry) while others become more important (e.g. controlling visualisation options; filtering lists; baking). A diverse vocabulary of challenges would be a great aid with this approach.
I'm not teaching that core course again until early next year, but I'll see if I can tidy up the challenges I've made/adapted to run them by you sometime before then.
I'd be also be interested to hear about any ongoing efforts with a testing suite in Grasshopper. My first guess is that it would look like having components that model different types of assert conditions. This plugin mentioned in this thread might be worth checking out, and it looks like it might be a capacity that is bundled into Grasshopper 2.