Computational thinking and design process with Littlebits droids

Cybersecurity First Principles in this lesson

• Abstraction: An abstraction is a representation of an object or concept. It could be something such as a door, a speedometer, or a data structure in computer science. Abstraction decouples the design from the implementation. The gauges in an automobile are an abstraction of the performance of a car. A map is an abstraction of the earth.

• Modularization: The concept of modularity is like building blocks. Each block (or module) can be put in or taken out from a bigger project. Each module has its own separate function that is interchangeable with other modules.

• Resource Encapsulation: Encapsulation is an object oriented concept where all data and functions required to use the resource are packaged into a single self-contained component. The goal is to only allow access or manipulation of the resource in the way the designer intended. An example, assume a flag pole is the object. There are fixed methods on how the flag pole is to be used. Put the flag on, take the flag off, raise or lower the flag. Nothing else can be done to the flag pole.

• Simplicity: Simplicity allows a person to better understand hardware and software. Without the clutter of unnecessarily complicated code and interfaces, the software will be more understandable by people that will update the code when requirements change. It will be easier to understand by the testers and they will be able to spot problems sooner. By keeping software as simple and as focused as possible, the reliability and security is greatly increased.

Introduction

In this lesson, we will learn how components can be used to solve a problem by decomposing it into sub-problems. We will also learn about how the design process can be applied to imagine a problem, think about different solutions, and then iteratively make attempts to solve it - getting better solutions at each iteration. The Littlebits Scratch programming interface will be used as an organizing technology platform for these activities.

Goals

By the end of this tutorial, you will be able to:

• express the key steps of the design process
• conceptualize and decompose a problem into smaller sub-problems using components
• program in scratch to solve a physical challenge

Materials Required

• Littlebits Droid Inventor Kit
• Number bit
• LED bit
• Sound trigger bit
• Temperature sensor bit
• Button bit
• Wire bit
• USB power bit
• Rechargable battery pack

Prerequisite lessons

Intro to components using Littlebits Droids

Table of Contents

• Computational thinking and design process with Littlebits droids
  • Cybersecurity First Principles in this lesson
  • Introduction
  • Goals
  • Materials Required
  • Prerequisite lessons
  • Table of Contents
  • The Design Process
  • Scratch 101 in Littlebits App
  • Exercise: Apply design thinking to solve a problem with Littlebits
  • Additional Resources
  • Lead Author
    • Acknowledgements
    • License

The Design Process

Design is more than sitting down and starting to code. In the real world when faced with a complex problem, companies, and individuals need a systematic process to think about the problem, consider all of the stakeholders and come up with a solution. In this lesson, we examine a 5-step design thinking process created by the Hasso-Plattner Institute of Design at Stanford. Their process is iterative and non-linear.

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

Empathizing and Defining

I group these two stages together as they are very iterative.

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

Before trying to solve a problem, one must understand it. Complex real-world problems involve more than one stakeholder. If you are trying to design software, for instance, you need to cognizant of all of your users, not just some of them. Implicit bias (where problem solvers accidentally leave some users out) can be a real issue if problem solvers don’t empathize with their users. In this sense, empathizing is the part of the design process where we observe and study our user base, build user stories that describe who our users are and what they want to do with our product, and then make sure we have coverage across our user population. Empathy is also important for setting aside our assumptions so that our product can meet the needs our users and not ourselves.

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

After we have gathered some data about our users and empathically considered their perspective, we can begin to define the problem. It should be noted that the define stage is not done once we initially define the problem. We will keep returning to the problem statement as we test our potential solutions. With definition, we want to make problem assumptions clear and define the requirements for any potential solution.

Some processes for empathizing and defining the problem

A good technique for empathizing and defining the problem is affinity diagramming. This technique helps development teams consider multiple perspectives and is a great process to use with groups of users from the target population.

For affinity diagramming, you need some sticky note cards, a few ink pens or markers, and a few questions. The questions get posed the group. Individuals in the group think up their answers and write them on the note cards, and then the facilitator goes note by note and the group decides how to categorize the notes. No note is bad.

This can produce some interesting categories that help define and contextualize the problem.

User stories are another useful technique for contextualizing a problem. User stories are used pretty extensively in software design and development - particularly in teams using a process called Agile.

A user story is generally written as:

As a type of user, I want to some action, so that I can rationale.

an example would be:

As a instagram user in highschool, I want to post pictures of myself and my friends, so that I can build my social status at school.

This may create very different requirements that a different kind of instagram user with different actions and rationales, e.g.

As a company on instagram, I want to post pictures of my products, so that I can build brand recognition.

Both statements help define requirements for any potential solution.

Exercise:

• Read https://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template
• Read https://uxdict.io/design-thinking-methods-affinity-diagrams-357bd8671ad4
• try it

Ideating

Once we can begin to stabilize the problem definition, we can start zoning in on solutions. The ideation phase is very important to help us find as many possible solutions to the problem as possible - so that we can pick the best one. Often times, computer scientists and developers don’t ideate enough before jumping into development. This can lead to some myopic focus on one particular design - that might be bad.

When ideating, there are several techniques you can use to come up with good ideas.

One is obviously brainstorming - where the team sits around a table and thinks up different ideas to address the problem. Brainstorming is great, but it is better applied as a second step.

First, a technique called worst possible idea is a good starting place. Worst possible idea runs counter to out notions of solving a problem, but its a helpful exercise. Here, participants come up with the absolute worst solutions to a problem that they can think of. Bad solutions are considered for why and how they are bad - to list out all the reasons.

Going through this process, the group begins to get a notion of the solutions to avoid. This is a great time to introduce brainstorming. The group can start to frame new ideas in terms of how they avoid the mistake and pitfalls of the bad ideas. This can help break town team-dynamics barriers that often emerge whenever a particular team member becomes attached to their particular idea.

Exercise:

• Read https://www.interaction-design.org/literature/article/learn-how-to-use-the-best-ideation-methods-worst-possible-idea (~5 min read)
• try it

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

Prototyping and Testing

Prototyping is the stage where you start making. Prototypes should not be full-fledged at the beginning. Since we aren’t always sure if an idea coming out of the ideation stage is really going to work, we don’t want to spend too much time on it at first. Prototypes can help to identify whether or not an idea will pan out. Often prototypes lead to new ideas - because different members of a team begin to bounce ideas off one another to create better ones.

As you progress, prototypes need to be tested.

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright licence: CC BY-NC-SA 3.0

Testing a prototype helps us to learn whether or not it succeeds (i.e. does it meet the requirements of the problem) and can help to refine the definition of the problem - if we learn something about the problem that we hadn’t thought of before.

Scratch 101 in Littlebits App

Try coding your droid.

• Go to the mission interface in the inventor kit app
• Try missions 11 (with secret handshake) and 18
• How could you combine the scratch interface with various inputs and outputs to solve a problem?

Exercise: Apply design thinking to solve a problem with Littlebits

The problem: Navigate a course, drop an object on the dropzone, and drive out.
The twist: You must drive and deliver the object using a scratch program written on your R2-D2.

Work in teams.

Tips:

Make sure to use the design process, in this case since the problem is defined, focus on the ideating, prototyping, and testing phases Consider decomposing the problem into subproblems and solving each one of them You can use parts from more than one droid kit, just make sure everyone gets their parts back at the end.

Reflection and takeaways

The design process is useful for conceptualizing a problem and exploring different solutions that meet all of your user’s needs or meet the requirements of the problem. Often, breaking a problem down into subproblems can help you tackle complex issues. Components can be used in more than one way for more than one purpose. This leads to reuse and is a positive side effect of modularization and resource encapsulation.

Additional Resources

For more information, investigate the following:

• Littlebits - Overview of concepts and available bits
• Scratch Studio - Practice learning scratch
• Advantages of User stories
• Affinity diagramming process
• Worst Possible ideas

Lead Author

• Matt Hale

Acknowledgements

This lesson was inspired and informed by a blog post written by Rikke Dam and Teo Siang. Materials in this lesson are used consistent with their CC-v3 license.

License

Nebraska GenCyber
is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Overall content: Copyright (C) 2017-2018 Dr. Matthew L. Hale, Dr. Robin Gandhi, Dr. Briana B. Morrison, and Doug Rausch.

Lesson content: Copyright (C) Dr. Matthew L. Hale 2018.

This lesson is licensed by the author under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.