Closed cdsmith closed 5 years ago
I think it may be productive to distinguish between the base library and the curriculum library. In my opinion, the base library should provide as many primitives as necessary to make anything possible, but no more than that.
On the other hand, the curriculum library (or "a curriculum library") could restrict those options to fit a particular curriculum, or it could add additional functionality built on the base library, as I do with the Extras modules.
Even though this is not exactly the topic of this thread, it is strongly related.
In this particular case, the base library should provide ways to create all the shapes in either solid, outlined or full version.
Then, a curriculum library could restrict the shapes available to just a few of those. For example, polygon
and rectangle
are
redundant for the base library, since polygon
would be enough. However, rectangle
makes sense in a curriculum library, as square
would too.
Another example: styledLettering
and all kinds of crazy colors are heavily used by high school students, who really want to customize
the look of their designs. Even though we only teach the basic pre-defined colors at the beginning, students skip ahead and figure out
how to work with RGB colors right away. However, middle school students may be more amenable to using just a few colors and the standard font.
So, a high school curriculum library may not need a rich set of predefined colors, while a middle school curriculum library may offer
just pre-defined colors and the color modifiers (light,dark,mixed,etc.)
On Tue, Nov 27, 2018 at 10:14:35PM -0800, Chris Smith wrote:
I don't know an easy way to do this, but @marcianx pointed out that if we're looking at reducing the number of colors in the name of avoiding cognitive load and memorization early in the class, it's actually the primitive pictures that play a bigger role in that. We have:
circle
thickCIrcle
solidCircle
rectangle
thickRectangle
solidRectangle
lettering
styledLettering
(I don't teach this one)polygon
thickPolygon
solidPolygon
polyline
thickPolyline
closedCurve
thickClosedCurve
solidClosedCurve
curve
thickCurve
arc
thickArc
sector
blank
codeWorldLogo
coordinatePlane
They do follow a lot of common patterns (plain/thick/solid variants, and polygon/polyline/closedCurve/curve), but it's still a huge list of vocab!
- Some primitives are redundant. For instance, rectangles can be defined as polygons, and circles as arcs. But those are cases where students need to practice with simple shapes before introducing the more general form.
- We could avoid the combinatorial explosion by following the Elm GraphicsSVG route, where
Stencil
andShape
andCollage
are different types. But this just adds its own form of complexity.- We could just eliminate primitives that are rarely used. I suppose the candidates would be
styledLettering
,arc
andthickArc
andsector
, and all thecurve
functions, for a savings of 9 primitives. But these were each added for a reason, either because students want them, or because they exercise math skills that are part of the goal!- As one stretch idea, we could eliminate the
thick
variants of shapes, and instead have all shapes drawn by a line of fixed thickness, which could then be scaled up or down to get a thicker line. This makes some simple pictures much harder to draw, but it removes the most complex primitives -- and also helps to fix some thorny issues with #649 by just definingblank
as the right picture when scaling by 0.I strongly suspect the right answer here is to do nothing. Perhaps we could postpone learning the polygon and arc families of functions until later in the curriculum sequence if the choices are really so overwhelming, but no need to take them away.
But I wanted to document the thought given to the question.
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/google/codeworld/issues/783
"Make anything possible" is quite a high bar! Off the top of my head, some of the things we can't do that are possible in other libraries include: dotted line variants of shapes, gradients, fill patterns, and constructive area geometry (#28).
Point taken, though. I guess I just mean that there's a kind of bias involved in not wanting to lose any capabilities, when we have for years been coping with limitations in the name of simplicity. The question is whether we've made the right choices. I can't think of a much more compelling design trade-off yet, but I explicitly want to avoid missing chances because of a never-give-an-inch attitude toward the current feature set.
It seems to me that the trade-off between limitations and simplicity is not absolute, but it depends on variables such as the grade-level of the target population.
I guess what I wish for is a mechanism to be able to set the trade-off level within some range [maxSimplicity .. maxCapabilities]
On Wed, Nov 28, 2018 at 06:45:25AM -0800, Chris Smith wrote:
"Make anything possible" is quite a high bar! Off the top of my head, some of the things we can't do that are possible in other libraries include: dotted line variants of shapes, gradients, or fill patterns, or some of the tricks you can play with constructive area geometry (see #28).
Point taken, though. I guess I just mean that there's a kind of bias involved in not wanting to lose any capabilities, when we have for years been coping with limitations in the name of simplicity. The question is whether we've made the right choices. I can't think of a much more compelling design trade-off yet, but I explicitly want to avoid missing chances because of a never-give-an-inch attitude toward the current feature set.
-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/google/codeworld/issues/783#issuecomment-442471467
I doubt there's a continuous version of that trade-off that can be made automatically. There are substantial design differences between the various choices. But new modes with different libraries is worth considering. I think it's independent of this bug, and related to #138.
Feel free to flesh out a proposal there. As I see it, the major challenges are:
In that post-configs world, one could see this bug as being just about whatever configuration currently captures the existing codeworld-mode API.
I still don't see an easy way to simplify the set of primitives that's better for most use cases. I doubt one exists. So I'll defer to #138 instead, and close this issue.
I don't know an easy way to do this, but @marcianx pointed out that if we're looking at reducing the number of colors in the name of avoiding cognitive load and memorization early in the class, it's actually the primitive pictures that play a bigger role in that. We have:
circle
thickCIrcle
solidCircle
rectangle
thickRectangle
solidRectangle
lettering
styledLettering
(I don't teach this one)polygon
thickPolygon
solidPolygon
polyline
thickPolyline
closedCurve
thickClosedCurve
solidClosedCurve
curve
thickCurve
arc
thickArc
sector
blank
codeWorldLogo
coordinatePlane
They do follow a lot of common patterns (plain/thick/solid variants, and polygon/polyline/closedCurve/curve), but it's still a huge list of vocab!
Stencil
andShape
andCollage
are different types. But this just adds its own form of complexity.styledLettering
,arc
andthickArc
andsector
, and all thecurve
functions, for a savings of 9 primitives. But these were each added for a reason, either because students want them, or because they exercise math skills that are part of the goal!thick
variants of shapes, and instead have all shapes drawn by a line of fixed thickness, which could then be scaled up or down to get a thicker line. This makes some simple pictures much harder to draw, but it removes the most complex primitives -- and also helps to fix some thorny issues with #649 by just definingblank
as the right picture when scaling by 0.I strongly suspect the right answer here is to do nothing. Perhaps we could postpone learning the polygon and arc families of functions until later in the curriculum sequence if the choices are really so overwhelming, but no need to take them away.
But I wanted to document the thought given to the question.