Side note #1:The first two days of learning delved into most of the topics from the first four units of the 10 Minutes of Code activities, including user input (via parameters or Request statements), output (Disp, Text), variables, data types, conditionals (If, If…Else), and loops (For, While, and DoWhile). Additionally, we applied many of these same concepts to tasks with the Innovator through the first two units of the 10 Minutes of Code for the TI-Innovator Hub activities.

Side note #2:Our use of debugging activities was inspired by the work of Amin Lalani & Georgia Stuart at UT Dallas.

We started Day 3 with a **Debugging Problems** TNS file. The file was composed of 10 Problems. Each Problem contains a **Program Editor** page, like this one:

with a corresponding **Calculator** page, like this one, on which to run/execute the program:

Each program (named **debug_1**,** debug_2**, etc.) contained at least one error. Participants worked in pairs to debug/fix each program. In so doing, participants reviewed, applied, and discussed:

- How to compile a program in the
**Program Editor**(using**Check Syntax & Store**) - How to run/execute a program in a
**Calculator**page (including the use of the**var**button to summon program names) - Syntax for the TI-Nspire programming language
- Variable naming conventions
- Data type considerations (including concatenation)
- Control structures, including conditional statements and loops
- Logic and conditional statements
- User input mechanisms (including parameters and Request statements)
- Error types (including compilation errors & execution errors) and error messages
- …and more!

Some of the programs involved *minor* errors. For example, the **debug_1** program shown above—participants determined that the string in the **Disp** statement should have been in double quotes (“) and not single quotes (‘). Here’s a quick GIF of troubleshooting this program:

Here are two other programs from the TNS file. What errors do you see? How might we debug these programs? What important CS topics connect to these errors and/or fixes?

It was incredibly valuable for participants to troubleshoot and debug these programs dynamically on the handheld calculators. They could fix errors as they found them and then compile and execute the edited program right away to test their “fixes”. On numerous occasions participants fixed one or more parts of the program, but then discovered another error when they ran the edited program.

Our brains often “fix the code for us,” helping us read the *intention* of the code, but perhaps missing some of the subtle errors specific to the coding language. This activity helped us review and apply programming skills specific to the TI-Nspire language, while also discussing larger computer science topics and content applicable across languages.

Additionally, we experienced the *cognitive difference* between writing a program from scratch and *debugging* an already written program. It *feels different* to debug–to find and correct errors in already written code–than to “code from scratch”; there was important learning to be had in this space.

Give it a try yourself! Here’s a copy of the TNS file with all 10 debugging programs in it. Each program does not necessarily have a unique solution—there may well be more than one way to “fix” the program so that it runs as intended, but with different code structures under the hood.

Also, Toni and I wonder…what would similar **debugging programs** look like that included TI-Innovator commands/components? What sort of errors would be helpful for learners to confront, discuss, and debug in regards to Innovator programs?

Here are some rough draft ideas for possible Innovator debug programs:

What other programs and/or lines of code might be valuable to include in a set of

TI-Innovator debugging problems?What other value do these debugging activities bring to the learning experience?

]]>

If you want to learn about Foldables, definitely start with the master, Dinah Zike herself! Check out her website and her *amazing resources—*guaranteed to spark your creative juices about how you can use 3D graphic organizers to help students organize their learning!

My professional journey with Foldables began several years ago when I had the incredible opportunity to attend a Dinah Zike Academy in Comfort, Texas. **I cannot recommend this professional development experience enough.** In just a few short days I went from knowing next-to-nothing about Foldables and journaling to feeling like an Interactive Notebook ** pro**—fully prepared to take my Foldable learning and apply it in my high school math and science classes that fall. I owe so much of my Foldable work to Dinah and her wonderful team!

The first step to creating a digital Foldable is to **sketch it out on paper**. Might seem counterintuitive, but this sketch will give you a “feel” for how the Foldable will look, info on how many columns/rows you will need later, and will also help with correctly “double-siding” your Foldable if you choose to tackle that (see my upcoming post on creating double-sided Foldables). Your sketch doesn’t have to be fancy or to-scale*—*just include your tabs, your labels for those tabs, and at least one anchor tab (for gluing your Foldable down into its final home*—*a journal, composition book, bound book, etc.).

Here’s a quick sketch of a Foldable we’ll create throughout this post*—*a **Solving Quadratic Equations** Foldable for use in Algebra I:

This is a 4-tab Shutterfold Foldable that opens like a pair of shutters on a window.

Not sure where to start with your Foldable design? Check out the samples here to get started!

With your paper sketch complete, you’re ready to create your digital version. I create my Foldables in Microsoft Word. I like the robust suite of editing options provided in Word, as well as the precise design tools that aren’t *yet* available in GoogleDocs.

Here we go with some step-by-steps…

Open Microsoft Word and create a new, blank document. Click on the **Insert** ribbon, then select **Table**. Highlight the size of your desired table. Based on my sketch, I’m going to need a 2 row by 4 column table, so I’ll select that.

Here’s the inserted table, which will act as the “frame” for our Foldable.

This “frame” needs a bit of work to make it into our finished Foldable. We’ll start by selecting the whole table in order to make changes to it. Hover over the upper left corner of your table, making the four-way icon appear.

Left-click on this four-way icon to select the entire table.

Next, hover over and then right-click on the four-way icon to display a context menu. Select **Table Properties** from near the bottom of this menu.

This will open up the **Table Properties** menu. On the **Table** tab, click on **Borders and Shading** at the bottom.

From here, you can change the border width. A thicker border makes your Foldable much easier to cut out! Click the drop-down menu under **Width** to change the width from **½ pt** to **6 pt**. Now your Foldable will have thick borders for easier folding and cutting.

Next, you can resize the widths and heights of your rows and columns to match your needs. Hover over the column/row dividing line, then click and drag to resize the columns and/or rows. Here’s a short GIF overviewing this process:

Worried that your rows aren’t exactly the same size? Highlight both rows, then right click to bring up the context menu. Use the **Distribute Rows Evenly** option to make your rows the exact same width.

**Confession here:** I hardly ever resize my columns/rows “by hand” like this… Instead, I enter exact row and column values in the **Row** and **Column** tabs in the **Table Properties** menu. More on this in a follow-up post…!

To create cohesive anchor tabs, we need to merge the two cells in the first column and then merge the two cells in the last column. Start by highlighting the two cells you want to merge. Then, right click on one of the highlighted cells to display the context menu. Click on **Merge Cells**.

Now, our Foldable looks like this*—*it has the right shape, thick borders, and two anchor tabs for gluing!

Now we’re ready to enter our content.

The standard for solving quadratic equations in Algebra I (in Texas) states:

A.8A: The student is expected to solve quadratic equations having real solutions by factoring, taking square roots, completing the square, and applying the quadratic formula.

So, we’ll title the four tabs using the wording from this standard.

I think Foldables are much more powerful when they have a **relevant image, graphic, or mathematical notation** on the corresponding tabs. Here I’ll include a sample quadratic equation that we can use to illustrate each solution method. I used Word’s built-in **Equation Editor** to enter these equations. Here’s a quick GIF showing how to insert an equation:

And the Foldable now has a relevant equation on each tab:

You could also include images, tables, graphs, geometric figures, etc. on your tabs*—*something that helps illustrate the big idea for that tab/topic.

**One last finishing touch:** I like to include the title of my Foldable written along the anchor tabs. Type the title into the anchor tab cell and then select the **Text Direction** options under the **Layout** tab in the **Table** ribbon.

Repeat on the other anchor tab and voila…!

A customized, professional, digital Foldable for use with your learners*—*designed exactly the way you like it!

What kinds of Foldables will you create using these tips?

What other tips do you have for creating digital Foldables?

]]>

In designing learning experiences for new-to-CS educators, Toni and I considered how Foldables might dovetail nicely with the 10 Minutes of Code activities provided by Texas Instruments. The 10 Minutes of Code activities do a phenomenal job of crafting short learning episodes that provide students with bite-sized instructional episodes (see the Skill Builders) followed by opportunities to apply their new learning (see the Applications).

Toni and I wanted to *build *on these 10 Minutes of Code activities by layering additional content connections that deliberately drew out and discussed some of the computer science topics that are operating within the 10 Minutes of Code activities. Specifically, we were working to develop Foldables that formalized CS topics that were important for a beginning teacher of CS to know (as defined by the TExES Computer Science 8-12 certification requirements in Texas).

Our Foldable work is inspired by the top-notch work of Dinah Zike and her crew from Comfort, Texas. If you are new to the world of Foldables, be sure to check out Dinah’s site. Dinah has a ton of resources that support Foldable use and creation in all grade levels and subject areas. Here are some of my favourites: Notebook Foldables, Big Book of Math for MS and HS, and her Notebooking Central resources for Math.

Toni and I wondered: What would Foldables look like in computer science? This led us on a fun journey…! Here are some of the highlights.

Here is a Three-Tab Foldable that overviews introductory Program Protocols, including how to Create (using the Program Editor), Compile (using the Check Syntax & Store command), and Run (using a Calculator page) a program on the TI-Nspire handheld. These ideas connect to the work done in the **Unit 1: Program Basics—Skill Builder 1: Introducing the Program Editor** 10 Minutes of Code activity.

Here’s another example of a Foldable that uses a screenshot of a program and its output for a given set of actual parameters. This Shutterfold Foldable (with an inlaid screenshot) was used to annotate some details about Formal and Actual Parameters after we wrote our first program that used parameters (in the **Unit 1: Program Basics—Skill Builder 2: Arguments & Expressions** 10 Minutes of Code activity).

** **

Here’s one of my favourites: a Matchbook Foldable that outlines how a For Loop operates. We used this Foldable to identify the four parts of a For loop, as well to practice tracing out a loop using a table. Notice the inclusion and annotation of a screenshot of the program. This Foldable formalized ideas from the **Unit 4: Loops—Skill Builder 1: For Loops** 10 Minutes of Code activity.

Here’s an awesome tweet from a learner in one of Toni’s workshops and his work with this exact Foldable! Love it!

We created similar Matchbook Foldables for While Loops and Do While Loops, but then also created this Three-Tab Foldable to compare and contrast the three types of loops (For, While, and Do While). This Foldable helped learners step back and consider the important similarities and differences across the three loop types that were studied throughout the **Unit 4: Loops **10 Minutes of Code activities.

Here’s an example of using a Shutterfold Foldable to document and analyze two Computer Science techniques (specifically, using Counters and Accumulators). This builds on the ideas used in the **Unit 4: Loops—Application: Bank Notices** 10 Minutes of Code activity. Consider how a Foldable like this serves as a way to consolidate new information, but also as a helpful resource for later reference and use.

We have received really positive feedback about how these Foldables helped learners step back from the coding experiences and synthesize the ideas they were learning about and experimenting with in a meaningful way. The Foldables helped to organize and chunk the main ideas and were also really handy for revisiting ideas throughout the learning episodes.

The examples above are a sampling of the Foldables that Toni and I have created for formalizing CS topics. We love doing this work!

What other topics from computer science might be a good fit for Foldables? What other strategies might be effective for creating powerful Foldables for CS topics? How might Foldables dovetail into work with the TI-Innovator Hub and those 10 Minutes of Code activities?

]]>

[Part 1 of this blog post discussed the original Math Talk and an **Open Strategy Share** discussion structure.]

Here is a “spin-off” Math Talk that emerged from the **Open Strategy Share** discussed in Part 1.

The group was presented with this sketch from one of their peers and asked to consider whether this image represented ¼ shaded. Note that the learner used a dot to mark the intended midpoint of the bottom of the square.

Does the image above represent ¼ of the square shaded? How do you know?

We discussed this representation in pairs and small groups, then we shared some of our thinking whole group. For this particular Math Talk, we were using a **Why? Let’s Justify** discussion structure. Instead of trying to generate multiple solution pathways, we were considering one particular (potential) solution and working on justifying why this was or was not a solution.

Kazemi & Hintz (2014) summarize the goal of this structure as “to generate justifications for why a particular mathematical strategy works” (p. 3). Kazemi & Hintz continue: “During a Why? Let’s Justify discussion, the talk narrows upon a general claim in order to closely examine the mathematics and generate a discussion for it.” (p. 74).

The following justifications emerged from the group:

**B** suggested that the shaded triangle did represent ¼ of the square, since the base was half of the square’s side length and the height of the triangle was equal to the side of the square.

This verbal description resonated with some learners in the group, but others were unconvinced.

**S** suggested that so long as the bottom vertices of the triangle remain unchanged the top vertex of the triangle could actually lie anywhere along the top side of the square — and the triangle would always have ¼ of the area of the square. We sketched out some examples of **S**’s idea:

**S** contended that all three of the triangles shown above represent ¼ of the square shaded in. The group agreed that the yellow triangle (a right triangle with its top vertex at the midpoint of the upper side of the square) definitely represented ¼ of the square, but some learners remained unconvinced about the other two examples.

**A** suggested that we draw in an **altitude **for each of the triangles we had sketched as a group. Our diagrams now looked like this:

Adding in this additional structure (the altitudes) *revealed* something that wasn’t yet visible for all learners — namely, **S**’s contention that all three triangles had the same base and height, so must have the same area.

[Side note: This is a great example of what Jill Gough and Jennifer Wilson describe as “adding in an auxiliary line…to make what isn’t pictured visible” from their learning progression for SMP 7:

I can look for and make use of structure. Check out their fabulous and thoughtful work on their blogs linked above.]

Consider how this Math Talk feels different than the **Open Strategy Share** version shared in Part 1 of this post. The **Why? Let’s Justify** discussion structure took us into another part of the mathematics — not merely considering a wealth of different approaches, but deeply considering one approach and focusing on creating convincing explanations to justify the mathematics used in that strategy.

In discussing the **Why? Let’s Justify** structure, Kazemi & Hintz (2014) contend: “Certain types of mathematical ideas lend themselves to a discussion that generates a justification for that idea” (p. 74). Not every problem or prompt is innately geared towards this particular discussion structure.

So what made this particular mathematical idea (specifically that the green triangle shown above does or does not represent ¼ of the square) a good fit for a **Why? Let’s Justify** discussion structure?

First, this particular representation did not *look* like ¼ of the square at first glance. A deeper analysis of the shape was required in order to determine whether or not it represented ¼ of the square–and deeper still to justify *why*.

Second, during the **Open Strategy Share** for the preceding Math Talk, most of the group’s sketches of ¼-shaded involved only congruent shapes. The approach used in this **Why? Let’s Justify **discussion did not subdivide the square into congruent shapes/pieces. Learners would have to rely on different reasoning (*beyond* subdividing a shape into congruent pieces and shading ¼ of the congruent pieces) to justify whether or not this specific triangle represented ¼ of the square.

Third, this particular triangle exposed that we (as learners) lose some of our intuition about triangles when they are obtuse triangles. We don’t often “see” the altitude of an obtuse triangle in the way that we see (and reason with) the heights of acute and right triangles. This drawing exposed some of that loss of intuition and made us dig deeper into *why* something was true.

For these three reasons (and perhaps others?), this prompt providing a meaningful task for learners to engage in a **Why? Let’s Justify** discussion routine.

**Side Note:** Kazemi & Hintz (2014) challenge that “During the discussion, we need to listen for procedural descriptions that students might give and be sure not to have the conversation stop there. When we press beyond procedural explanations into explanations that include reasoning, we are supporting students in justifying their ideas” (p. 56).

This paragraph still convicts me. Did I press far enough in the justification discussion outlined above? *Why* does any triangle with a base half the width of the square and a height of the square have an area of ¼ of the square? Maybe I should have pushed our thinking a little bit further here…

How does the

Why? Let’s Justifydiscussion structure compare to theOpen Strategy Sharestructure? In what ways does it open up a different part of the mathematics? What additional considerations might a teacher attend to when planning a Math Talk like this?

(See Elham Kazemi & Allison Hintz’s book Intentional Talk: How to Structure and Lead Productive Mathematical Discussions for more information on the **Open Strategy Share** and **Why? Let’s Justify** discussion structures.)

]]>

Consider the following Math Talk:

Take a few minutes (say, time yourself for 3 minutes) and sketch squares where ¼ of each square is shaded in a different way. One ground rule first… Let’s say that the following two depictions represent the same “way” to shade ¼ of a square. Instead of sketching different iterations of the same “type” of ¼…can you shade ¼ in a different way? How many different ways? Set your timer and see where your brain takes you…!

Where did your brain take you? How many different ways of shading ¼ of a square did you generate?

After working on this task individually for 2-3 minutes, learners share their thinking with their tablemates. In so doing, they consider and discuss *Did we all approach this task the same way?* and *What additional approaches did my peers use?* and *What additional ideas do we now have as a group because of discussing each other’s work?*

We have led this Math Talk with multiple groups of adult learners. Here is a sample of the collective work that has come out of this individual think time followed by small group discussion time:

What would you do with this work? What is the benefit of orchestrating an

Open Strategy ShareMath Talk over some of these examples?

Kazemi & Hintz (2014) suggest:

“Open strategy sharing is typically the first way to get mathematical discussions going in classrooms. It’s like having a good, basic recipe for a soup from which you can make all kinds of variations. Open strategy sharing allows you to nurture the norms needed for a productive math-talk community. And you can use this discussion structure to model how students should talk with one another.” (p. 17)

I particularly like how the Open Strategy Share discussion structure provides an initial access point for teachers looking to introduce or enhance math talk in their classrooms. Also, as Kazemi & Hintz discuss, these structures provide wonderful opportunities for students to learn *how to talk about mathematics*.

But, if this is the “basic recipe for soup,” what would your *variation* be? What would you choose to highlight or spin off from for a follow-up Math Talk at some later time? Where else *instructionally* might this Math Talk go?

Check out Part 2 of this blog post to see a sample follow-up Math Talk that utilizes the **Why? Let’s Justify** discussion structure.

(See Elham Kazemi & Allison Hintz’s book Intentional Talk: How to Structure and Lead Productive Mathematical Discussions for more information on the

Open Strategy Sharediscussion structure.)

]]>

This is a dilemma Toni and I have faced on a number of occasions. One approach that we have found particularly helpful for these situations is what we call “Cooking Show CS”.

Consider a cooking show for a minute… Time is not spent *equally* on each part of the cooking experience. Rather, some parts—the really important parts—are *slowed down* and discussed and modeled in great detail. Other parts—the not-so-important parts—are sped up considerably or even skipped entirely. Like, seriously, when does a cooking show include “real-time footage” of a recipe baking second-by-second in the oven?? We don’t *need* to see that—we get it. We often *do* need to see the preparation *and* the active cooking *and* the tips and tricks *and* the cooking “theory” being applied to this particular recipe. So that’s where a cooking show spends its time.

What would the CS equivalent of this be? What would it look like for a CS “recipe”/program/project to *slow down* and focus deeply on the preparation *and* the active computational thinking *and* the tips and tricks *and* the computer science theory…while speeding up or skipping entirely the parts that we don’t need to *see* or *do* in their entirety?

Here are two vignettes of how Toni and I have tried to used “Cooking Show CS” in 1 hour conference sessions.

Side Note:We don’t think that this pedagogy is always effective or that it is necessarily thebest approachin all instances. Rather, we contend that there are times (i.e. short conference sessions) where it might meet a need—allowing participants to “develop” (or co-develop) a program in one hour that otherwise might take them much longer.

In this particular session, new-to-CS learners were learning about introductory CS control structures, including sequential, branching, and iterative pathways. Participant pairs worked together to make sense of block-based pseudocode for this particular program, then we collectively translated this pseudocode into the text-based language of the TI-84+CE (by hand — more on that decision later). (Toni or I will share more about the block-based pseudocode we used for this activity in a later post.)

We ended up with the following program coded *by hand on paper*:

:Disp “GUESS IS TOO HIGH”

:Wait 0.5

:Send(“SET SOUND 1046.5 TIME 0.5”)

:Wait 0.6

:

:Disp “GUESS IS TOO LOW”

:Wait 0.5

:Send(“SET SOUND 65.41 TIME 0.5”)

:Wait 0.6

:

:randInt(1,20)→N

:

:Input “GUESS? “,G

:

:While N≠G

:

:If G<N

:Then

:Send(“SET SOUND 65.41 TIME 0.5”)

:Wait 0.6

:

:Else

:Send(“SET SOUND 1046.5 TIME 0.5”)

:Wait 0.6

:End

:

:Input “GUESS? ”,G

:

:End

:

:Disp “YOU WIN!”

Getting to this point *took time*, as we carefully constructed, deconstructed, and discussed the various computer science principles at play in our program. How were we possibly going to have time to code this program into the calculators, as well?

Here’s where “Cooking Show CS” came into play.

Toni and I created a partially pre-made version of the program (called NUMGAME) and uploaded it onto all of the handhelds in the room. Instead of starting from scratch, participants opened up NUMGAME to find the first 9 lines of code already coded into the program—specifically, the lines highlighted below:

We helped participants navigate through entering the remaining lines of code into the “pre-prepped” program. Most participants finished coding these commands into their handhelds in time to test and run their programs, but a few did not.

We had considered this possibility, so we also preloaded a program called NUMGAME2 onto all of the handheld calculators. This program included all of the lines of code we (as a group) had collectively coded by hand.

This, to us, was akin to the moment in a cooking show where the chef puts a “raw” dish in the oven, but then a few minutes later pulls out a “finished” dish that had already been cooking for the full amount of time. Our choice here was purposeful: We wanted all participants to experience success with the program that they had helped write, even if they didn’t have time to “type in” each line of the code.

We included two additional “pre-cooked” programs for participants to consider, as well—NUMGAME3, which added in additional context for the user, visual (LED) outputs, and a celebratory tone when the user guessed the correct number; and, NUMGAME4, which abstracted the program so the user determined the upper bound on the range of possible numbers and also included a counter that tracked and displayed the number of guesses the user needed to guess the number. Participants were given a few minutes to run each of these programs and then *predict* what the changes in the code might look like in order to result in these “enhanced” versions of the program.

Toni has written here about the “Respect the Beep” session we have led where we use the TI-Innovator and the Ultrasonic Ranger to model a vehicle’s back-up sensor. I discussed this same program (but through a pedagogical lens) in this post about Introducing CS with Flowcharts.

When we led this activity in a conference session earlier this summer, we had a sequence of three programs we were planning to write as a collective group.

Here is the finished code that we wanted to arrive at for the first program:

Toni and I decided to create and provide participants with a pre-made file with the following parts of the program already “cooked”:

Including these commands allowed us to: save a few minutes of coding time in the conference session; and, focus primarily on the theory and syntax of sending and receiving commands from the Ranger, rather than just the digital connections.

Wrapping a While loop around the data collection part of this program doesn’t take a lot of extra time, so that’s something we had participants do themselves, as well, resulting in a program of:

P.S. Highlighting text using the **Shift** button and then inserting a **While…EndWhile** loop from the **Menu **will insert the While loop *around* the highlighted text. Here’s a little GIF showing this tip:

Fun tip! Highlight code w/ SHIFT key; insert control structure from MENU to wrap code into loop/conditional. @TICalculators #MTBoS #T3Learns pic.twitter.com/FdOjA1SwIn

— Michelle Rinehart (@HowWeTeach) July 4, 2017

However, we did run out of time for participants to code in the final branching structures that were to be housed inside the While loop. Here was our end goal:

How might we have used another “Cooking Show CS” program here to help us meet our instructional goal in the short amount of time we had with these learners? Toni and I have considered using an “almost done” version of the file that looks like this:

where participants would fill in the output commands (represented above by the highlighted blank lines) within the various branches of the program.

What are your thoughts? How might using a “cooking show” approach for a CS lesson/activity/presentation allow us to focus more on our CS instructional goal and less on aspects that participants perhaps don’t need to see or do in their entirety?

]]>

How might we use a Math Talk to help students sense-make about solving equations? How might this same Math Talk help students work on **showing what they know** and **making their thinking visible**? How might a **Compare & Connect** discussion routine overlaid on this Math Talk help deepen our understanding of strategies for solving equations? Let’s explore these ideas further…!

Here is one of my favourite Math Talks:

(Note: The idea for this particular Math Talk came from a session I attended at NCSM 2016 led by Crystal Lancour & Jennifer Trievel of Delaware. Thanks, y’all!)

Take a minute and think about how you would respond to this prompt. Can you solve this problem *without* first “translating” it into algebraic notation and solving via algebraic manipulation? Rather, can you solve this problem *visually*?

Also, can you (as Jill Gough and Jennifer Wilson encourage us to do) “show your work so that a reader understands without having to ask [you] a question”? (See more on Jill & Jennifer’s #ShowYourWork progressions here.)

How might we **make our thinking visible** for how we solved this problem?

Here is how S, a recent conference session participant, made her thinking visible:

She explained her thinking aloud as:

I removed 4 horses from each side. Then I was left with the fact that 2 elephants were as strong as 8 horses. I divided these 8 horses into two equal groups showing me that each elephant is as strong as 4 horses.

When asked “Did anyone else solve the problem this way?” the majority of the participants indicated that they solved this problem the same way as S had.

L, however, had a different approach. Here is how she made her thinking visible:

Can you understand what L did without asking her any questions? How is her approach similar to and different from S’s approach?

L explained her thinking to the group in this way:

I started by dividing the problem in half. I knew that if 2 elephants and 4 horses were as strong as 12 horses, then 1 elephant and 2 horses must be as strong as 6 horses. Knowing that 1 elephant and 2 horses were as strong as 6 horses, I removed 2 horses from both sides of this situation, leaving me with the fact that 1 elephant is as strong as 4 horses.

How did L *look for and make use of structure*? And, does her method work all the time?

We quickly considered what the corresponding algebraic manipulation might have looked like for S and L’s approaches. We decided to represent the strength of an elephant with the variable * e* and the strength of a horse with the numerical value of 1. Here is what we came up with for the corresponding algebraic methods for these two visual solution pathways:

**S’s Method**

**L’s Method**

Do both of these methods work every time? When might S’s method be advantageous? When might L’s method be advantageous?

Why might it be important for students to **Compare & Connect** these two methods in a Math Talk? (See Elham Kazemi & Allison Hintz’s book Intentional Talk: How to Structure and Lead Productive Mathematical Discussions for more information on the **Compare & Connect** discussion structure.)

Also consider:

How does L’s method push back on well-intentioned but over-structured “procedures” we might teach our students for solving equations?

More on this idea in an upcoming blog post on **Sense-Making for Solving Equations**.

]]>

Here’s the description for this session:

How can effective Number Talk routines be adapted to meet the needs of secondary classrooms? Explore strategies and resources for implementing Math Talks in Gr. 6-Algebra. See how Math Talks can provide opportunities for students to communicate and justify mathematical ideas, reasoning, and arguments within a concise, organized classroom structure.

Here are the mathematical goals for this particular session:

Look familiar? These are excerpts from two of our **Mathematical Process Standards** here in Texas (the Texas equivalent of the CCSS’ Standards for Mathematical Practice (SMPs)).

Our pedagogical and instructional objectives for this session included:

Here is the participant handout from this session and here is the card sort with samples of secondary Math Talks.

I’ll unpack this conference session further in future blog posts. Just sharing the resources to start the conversation…!

**Update:**

- Explore the opening Math Talk from this conference session in the post
**Math Talk: Solving Equations Visually**. This post also explores the**Connect & Compare**discussion structure. - Explore another Math Talk from this session in the post
**Math Talk: 1/4 of a Square (Part 1)**. This post also explores the**Open Strategy Share**discussion structure. - Explore how the second Math Talk was extended in the post
**Math Talk: 1/4 of a Square (Part 2)**. This post also explores the**Why? Let’s Justify**discussion structure.

Interested in joining this conversation live? Come join in this session live at CAMT 2017 in Fort Worth, TX or NCTM Regionals 2017 in Orlando, FL!

]]>

Here’s an example of just such a learning experience where a fellow educator recently deepened and broadened my understanding of the **SET COLOR** command on the TI-Innovator.

First, some background. Earlier this month, during a **Teaching Computer Science with TI-Nspire **workshop, we spent lots of time exploring different data types (including strings, floats, ints, etc.) and working with input and output commands related to these data types.

We learned how to **Disp**lay output to the program’s user, including output made of different data types such as in the **hypotenuse** program shown below:

Running the **hypotenuse** program with actual parameters of 3 and 4 yields:

We informally called this use of the comma (**,**) in the **Disp **command

**Disp** __, __, __, …

where any given blank could contain a string (in quotes) *or* a variable (string variable or numeric variable).

We later realized that the comma wasn’t our only (or even best?) way to concatenate, as we discovered when we ran into a program like this:

In this case, with the **Request** statement, we couldn’t use the comma to “concatenate” as we had done before with the **Disp** statement. We realized that this was due to the syntax of the **Request** statement, which looks something like this:

**Request “[message to user]”, variable_to_store_response**

The comma wouldn’t work to “concatenate”/connect output together here, since the **Request** statement was only expecting one comma in its syntax. (Side note: **Request** can actually receive a second comma followed by a 0 to suppress the user input, but that’s another story…! :))

Instead, we used the ampersand (**&**) to concatenate within the **Request** statement shown above.

From there, we wondered whether the comma (,) really *had *been concatenating for us earlier. We set off to investigate this further.

What do you think the output of this program would be?

Notice how the numeric variable * age* displays without a problem when using the comma (

Here is the output from running this program:

Notice anything interesting…?

We noticed some spacing issues. Namely, that the **Disp __,__,__** approach inserted a space between each **__** element, while the **Disp** [string]**&**[string]**&**[string] approach did not insert spaces between the various strings (as is true of typical concatenation).

Interesting… We were stretching our thinking and making connections about data types, output formatting, and concatenation methods.

Then, came this activity late in the second day…

We were learning how to code output to the RGB LED that is built into the TI-Innovator. We quickly learned that the syntax for sending colours to the RGB LED is:

**Send “SET COLOR # # #”**

where each of the three #’s is an integer from 0 to 255. We explored the effects of changing these numbers in order to determine what each of the three numbers controlled and how it controlled it.

Here is a screenshot of a program that turns on the red LED within the RGB LED at full intensity:

However, we had a problem. Our program, as currently written, wasn’t all that helpful. Specifically, our program coded only one particular colour — and if we wanted to display another colour, we had to go into the code for the program and make changes there. This wasn’t very user-friendly!

We decided to abstract our program so that the user could display whatever colour they wanted by entering three values for the *red*, *green*, and *blue* intensities.

For the sake of expediency in coding (at the sake of user-friendliness for users who didn’t write the program), we decided to pass these values into the program as formal parameters (i.e. via **colour( r,g,b)**). We updated our three colour intensity values in the

We had a great discussion about what was going on and going wrong here… Specifically, we were sending a *string* to the Innovator to be translated into visual output. The * r*,

No worries, as I knew where this was going. (This is that “*knew*” thing I was talking about earlier…) I swooped in and saved the day by introducing the **eval()** command, which evaluates the value of the variable and pastes that into the Innovator string output/send command, instead. Our code now looked like this and worked as intended:

But then…the magic. Someone looked at this problem differently…

T, one of the participants in the room, piped up with “I found another way to do it…! An even more efficient way!” We pulled T’s screen up on the Navigator system and considered his code:

Discussion abounded.

“Wait — doesn’t Send “SET COLOR…” need three values in it?”

“Oh, he’s concatenating with the commas!”

“Don’t we need spaces between the numbers?”

“Could you use ampersands instead?”

“This is like how we used theDispstatement!”

“Wait — does that work?!”

I was surprised by T’s discovery (*I had never seen this approach before!*) and delighted (*of course that works! How fun!*). It was a wonderful moment of learning that cemented many ideas we had considered over the course of two days — and provided us with additional flexibility for coding a new command we were just learning to use.

What are your thoughts?

What might the value be in using syntax of **Send “SET COLOR eval( r) eval(g) eval(b)”** for a program like this?

What might the value be in using syntax of **Send “SET COLOR ”, r,g,b** ?

What does each method add to our coding arsenal and/or to our understanding of CS topics?

And…is there another way?

]]>

Our goal for the end of a 60-minute conference presentation is usually to have participants code out (on a calculator and also (usually) by hand) a rather complicated program — but, more importantly, to have *made sense* of said program.

In a recent conference session, our goal was for participants to code a program that modeled a back-up sensor on a car, complete with audio feedback based on how far the “car” was away from an object. This particular program (see Toni’s post here for more information) included sequential, branching, and iterative elements, as well as commands related to connecting to, collecting data from, and disconnecting from an actuator (or peripheral device). These are a lot of different elements for someone who is new to CS to integrate!

How might we design learning experiences to support sense-making around these varied commands/structures…in a way that is accessible for new-to-CS learners?

One approach that we have found particularly effective for this work is using flowcharts — specifically, using flowcharts that develop over time. Rather than just jumping right into this rather complicated flowchart (again, complicated for a new-to-CS learner!):

we instead provided the following blank flowchart and had participant pairs brainstorm what commands might need to go into this flowchart (and in what order) in order to read and display a distance measurement from an Ultrasonic Ranger attached to the Innovator.

Note that the task of collecting and displaying a distance measurement is not our end goal, which is to model a back-up sensor — but we deliberately wanted to decompose this program/situation into simpler situations first. In this case, before we model a full-on sensor, how might we code the Innovator just to collect and display a data measurement?

A quick debrief of ideas from the whole group (plus some information from us on what these commands look like for the Innovator) led to this filled-in flowchart:

With a completed flowchart, we quickly “translated” the pseudocode in this flowchart into the programming language of the TI-Nspire and TI-Innovator. Participants checked that their programs collected and displayed a valid distance measurement as intended.

Next, we asked participants to consider, *What if we wanted to collect data measurements repeatedly, instead of just once?* We provided the following blank flowchart and had participant pairs consider what commands might go in each element of the flowchart.

Participants talked through lots of important ideas here, including: *What should go in the “decision diamond”? What commands should happen “outside” of the loop structure? What commands should happen again and again (i.e. inside the loop structure)?*

Debriefing these ideas whole-group led to the following completed flowchart:

We quickly coded these additional commands/structures into the program we had started earlier and tested our new programs.

Now, our program collected distance measurements again and again until the distance was less than 0.01 meters. For the sake of our model, we said that this value represented the back-up sensor turning off after a collision — *whoops*!

However, our sensor wasn’t giving us very helpful feedback! It was displaying the distances, but who would be *reading* that display while backing up?! We wanted to add in audio feedback (beeps!) that alerted us if we were nearing an obstacle. Specifically, we wanted there to be two “levels” of audio feedback — warning beeps if we were nearing an object, but then a more urgent set of warning beeps when we got really close to an object.

We provided the following flowchart for participant pairs to discuss:

which led to a final debrief and this filled-in flowchart:

Here we were, finally, at our programmatic goal! We had collectively developed a program (in flowchart form and in coded form in our calculators) that modelled a back-up sensor.

Yes, it took a while to get there, but the time spent *sense-making* about the earlier situations and flowcharts helped participants develop and use appropriate CS structures and logic while creating this more complex program. We were thrilled with the engagement, discussions, and explanations from our participants, many of whom were new-to-CS learners!

**Side Note:** When leading this conference session, we ran out of time during the calculator coding of the final part of the program. We have discussed some time solutions for this for future presentations of this conference session including having participants code the first program on the calculator, but providing “almost complete” versions of parts 2 and 3 already on the calculator. This will cut time out of the session without losing any of the time that focuses on sense-making about the code.

To create these flowcharts we used the LucidCharts Diagrams Chrome extension, which allowed us to create and store these flowcharts in GoogleDrive.

Here’s a copy of our handout from the conference session; we wanted participants to leave with copies of the completed flowcharts so that they could later replicate this work on their own devices.

How else have you used flowcharts to introduce CS topics to new-to-CS learners? What other pedagogical or instructional approaches have been effective for making CS accessible to all?

]]>