Notebook Recommendations from Judges
At the preview, saw some good notebooks… But as in all things, there is room for improvement.
Missing / needed / suggestions:
1. Index or table of contents – where to find the material included in the notebook.
2. Goal or problem to be solved – some teams put in the rules and / or the field of play.
3. Sketches, photos, diagrams – These are always helpful for planning and brainstorming. Late design sketches, photos, diagrams should be labeled (at least major components or design elements) – not as necessary in initial sketches / brainstorming but doesn’t hurt.
4. Parts lists – Some teams said the parts don’t have names (they can create their own name or description, such as straight metal strip with 30 holes or L metal 11” long). Another team stated that they had changed their design so many times that the labor to keep the parts list was overwhelming, I suggested Excel (ideally) or Word which would keep them from rewriting the parts list – that teams said they never considered that but agreed that would ease the tracking of the parts list.
5. Documentation of processes used in the design, including dates. This includes work done as well as documenting any testing and results / changes. All teams told me that they made changes but few teams documented the changes – what the changes were, why the changes were needed. One team commented something along the lines of “Well all the changes would be because it didn’t work when we tried it.” My answer was “Not necessarily – maybe you planned something but you did not have the parts or the design was not to specs in height / width / weight.”
6. Program with comments included in the program. Several groups commented that the program would not print well, in that the printer kept cutting some of it off. We have a solution from last year which was to copy and paste it into Word or another Word processor, although the coloring is nice from the development application. I believe line comments in C are placed after the command and are // then the comment. The programmer in me even says it is OK to comment out old code (comments mean that anything after the start of the comment on that line does not execute) but leave it in the program saying this is old / does not work / was for testing purposes.
7. Wiring diagram or schematics.
The overall purpose when judging the notebooks was “Can I take this notebook and figure out how to make exactly what you have made. Do I know what parts I will need, how to program it, what it should look like, and what mistakes not to make because you have already found them.”
Missing / needed / suggestions:
1. Index or table of contents – where to find the material included in the notebook.
2. Goal or problem to be solved – some teams put in the rules and / or the field of play.
3. Sketches, photos, diagrams – These are always helpful for planning and brainstorming. Late design sketches, photos, diagrams should be labeled (at least major components or design elements) – not as necessary in initial sketches / brainstorming but doesn’t hurt.
4. Parts lists – Some teams said the parts don’t have names (they can create their own name or description, such as straight metal strip with 30 holes or L metal 11” long). Another team stated that they had changed their design so many times that the labor to keep the parts list was overwhelming, I suggested Excel (ideally) or Word which would keep them from rewriting the parts list – that teams said they never considered that but agreed that would ease the tracking of the parts list.
5. Documentation of processes used in the design, including dates. This includes work done as well as documenting any testing and results / changes. All teams told me that they made changes but few teams documented the changes – what the changes were, why the changes were needed. One team commented something along the lines of “Well all the changes would be because it didn’t work when we tried it.” My answer was “Not necessarily – maybe you planned something but you did not have the parts or the design was not to specs in height / width / weight.”
6. Program with comments included in the program. Several groups commented that the program would not print well, in that the printer kept cutting some of it off. We have a solution from last year which was to copy and paste it into Word or another Word processor, although the coloring is nice from the development application. I believe line comments in C are placed after the command and are // then the comment. The programmer in me even says it is OK to comment out old code (comments mean that anything after the start of the comment on that line does not execute) but leave it in the program saying this is old / does not work / was for testing purposes.
7. Wiring diagram or schematics.
The overall purpose when judging the notebooks was “Can I take this notebook and figure out how to make exactly what you have made. Do I know what parts I will need, how to program it, what it should look like, and what mistakes not to make because you have already found them.”