Intro to App Design

A user interface is the inputs and outputs that allow a user to interact with a piece of software. User interfaces can take many forms — buttons, menus, images, text, and graphics.

Input is data put in by the user that is sent to a computer for processing by a program. Output is data put out by the computer that is sent from a program to a device.

Both can come in a variety of forms:

Inputs usually affect the output a program produces, and output is usually based on the program's input or on what the program already had stored.

Some elements do both

This is the part worth pausing on. It's tempting to sort every element into "input" or "output," but the sorting isn't always clean.

An image can be both. It outputs information to the user — it's a picture they look at — and it can be a clickable button that sends input when tapped.

A text box works the same way: it can display information the program produced, or collect what the user types, or both on different screens of the same app.

When you're deciding whether an element is input or output, ask what it's doing in that moment, not what kind of element it is.

Input comes from more than users

A program's input doesn't have to come from a person. Input can also come from other programs, and an event — a key press, a mouse click, the program starting — supplies input data to a program too.

That's why events matter so much in app design: every tap and click is input arriving.

Designing a user interface

The design of a program includes deciding what its interface has to do. Program requirements describe how a program functions, including the user interactions it must provide, and a program's specification defines those requirements.

The design phase of a program may include:

• brainstorming
• planning and storyboarding
• organizing the program into modules and functional components
• creating diagrams that represent the layouts of the user interface

People design user interfaces to meet a user's needs — and they don't always get it right. That's why the design work happens on paper first, and why feedback from real users matters before you commit to a layout.

A program statement is a command or instruction — sometimes also called a code statement. A program is a collection of program statements, and programs run (or "execute") one command at a time.

There are two different ways a program can run.

Sequential programming

Sequential programming is when program statements run in order, from top to bottom.

• No user interaction
• The code runs the same way every time

setScreen("homeScreen");
setProperty("titleText", "text", "Welcome!");
playSound("sound://intro.mp3", false);

Those three statements run first, second, third — every single time the app starts. Nothing the user does changes the order.

Event-driven programming

Event-driven programming is when some program statements run when triggered by an event, like a mouse click or a key press.

• Programs run differently each time, depending on user interactions

onEvent("dogButton", "click", function() {
  setProperty("dogImage", "image", "dog.png");
});

The code inside that block doesn't run when the app starts. It waits. It runs only when someone clicks dogButton — and if nobody ever clicks it, that code never runs at all.

An event is associated with an action and supplies input data to a program. Events can be generated when a key is pressed, a mouse is clicked, a program is started, or any other defined action occurs that affects the flow of execution.

Comparing the two

In event-driven programming, program statements are executed when triggered rather than through the sequential flow of control.

Real apps use both

An app isn't one or the other. Most apps you build in App Lab will:

1. Run some sequential code at startup — set the screen, set up the look of things
2. Then sit and wait, running event-driven code as the user taps around

// Sequential — runs once, at startup
setScreen("homeScreen");
setProperty("scoreLabel", "text", "Score: 0");

// Event-driven — runs only when clicked, possibly many times, possibly never
onEvent("playButton", "click", function() {
  setScreen("gameScreen");
});

Being able to look at a piece of code and say which kind it is — and explain what happens when the program runs — is the skill this concept is really about.

Debugging is finding and fixing problems in an algorithm or program.

Every programmer debugs constantly. It isn't a sign that something went wrong — it's most of what programming actually is.

A process for debugging

Rather than staring at code and hoping, work through these four steps:

1. Describe the problem

• What do you expect it to do?
• What does it actually do?
• Does it always happen?

2. Hunt for bugs

• Are there warnings or errors?
• What did you change most recently?
• Explain your code to someone else
• Look for code related to the problem

3. Try solutions

• Make a small change, then test it

4. Document as you go

• What have you learned?
• What strategies did you use?
• What questions do you have?

"What did you change most recently?" solves a surprising number of bugs on its own. If it worked ten minutes ago and doesn't now, the answer is almost always in what changed between then and now.

Debugging strategies

Keep your code clean

• Use clear, meaningful IDs for your elements
• Keep your code organized in chunks that do the same thing
• Use comments to explain your code
• Write code using blocks

Run your code

• Run it a lot — every time you add a command or two
• Slow it down with the speed slider and watch how it runs
• Use console.log to get output; add extra output statements throughout your code to see what parts are running

Use classmates and resources

• Talk the problem out with a partner or classmate
• Compare your code to examples you know work
• Read documentation to learn how a block is supposed to work
• Hand trace your code to track what's happening

Explaining your code out loud to someone else is on this list for a real reason. Saying it step by step forces you to check what the code actually says instead of what you meant it to say — and people often find the bug mid-sentence, before the other person has said anything.

Kinds of errors

Knowing which kind of error you have tells you where to look:

Effective ways to find and correct errors include test cases, hand tracing, visualizations, debuggers, and adding extra output statements.

Documentation and comments

Documentation is a written description of how a command or piece of code works or was developed.

A comment is a form of program documentation written into the program to be read by people, and which does not affect how a program runs.

// Show the dog picture when the button is clicked
onEvent("dogButton", "click", function() {
  setProperty("dogImage", "image", "dog.png");
});

That first line is a comment. The program behaves identically with or without it — it exists purely for the humans reading the code.

Programmers should document a program throughout its development, not at the end. Documentation helps in developing and maintaining correct programs, whether you're working alone or with a partner.

Not every programming environment supports comments, so other methods of documentation may be required.

Why bother?

Two reasons that show up immediately in this class:

• Your partner has to read your code. On a collaborative project, comments are how the other person knows what your half does without asking you.
• You will forget. Code you wrote last week is written by a stranger. A one-line comment saves you re-deriving what you already worked out.

The developmental design process is the steps or phases used to create a piece of software, typically in a collaborative environment. It may involve investigation, designing, building, and incremental and iterative testing.

The point is that you don't just start coding. Building an app that works for real users means planning before you build and revising after you test.

The phases

A development process can be ordered and intentional, or exploratory in nature. There are multiple development processes, but these phases are commonly used:

Iterative and incremental

Two words describe how a good process runs, and they mean different things:

Iterative — the process requires refinement and revision based on feedback, testing, or reflection throughout. This may require revisiting earlier phases. You don't finish "design" and never return; feedback sends you back.

Incremental — the process breaks the problem into smaller pieces and makes sure each piece works before adding it to the whole. You don't build the entire app and then run it for the first time.

These two together are why "run your code every time you add a command or two" is good advice and not just fussiness. Incremental building is what makes debugging manageable.

Investigation

The design of a program incorporates investigation to determine its requirements. Investigation helps you understand and identify the program's constraints, as well as the concerns and interests of the people who will use it.

Ways to perform investigation:

• collecting data through surveys
• user testing
• interviews
• direct observations

Interviewing classmates about what they already know — and what they'd want to learn — is investigation. It tells you what your app actually has to do before you spend time building the wrong thing.

Design

Program requirements describe how a program functions and may include a description of user interactions the program must provide. A program's specification defines those requirements. The design phase outlines how to accomplish a given specification, and may include:

• brainstorming
• planning and storyboarding
• organizing the program into modules and functional components
• creating diagrams representing the layouts of the user interface

This is why the app planning happens on paper first. Sketching the screens and the flow is cheaper to change than code is.

Collaboration

Working with a partner isn't just logistics — it changes the quality of what gets built.

Benefits of collaboration: it can decrease the size and complexity of tasks required of individual team members, it facilitates multiple perspectives in developing ideas, and it can make it easier to find and correct errors during the development process.

The College Board framing adds two more:

• Effective collaboration produces a computing innovation that reflects the diversity of talents and perspectives of those who designed it
• Collaboration that includes diverse perspectives helps avoid bias in development

Consultation and communication with users are important aspects of developing computing innovations. Information gathered from potential users helps you understand the purpose of a program from diverse perspectives and build something that incorporates them.

The process in this project

The app project walks through the whole cycle:

Step 7 is the iterative part made concrete: feedback from a classmate sends you back to change the app. That loop is the process, not a sign you did step 5 wrong.

These are the App Lab commands and blocks introduced in Unit 3. Each one is a program statement — a single command or instruction.

Each command is shown as the block you see in App Lab, followed by the same thing written as text so you can read the exact syntax.

console.log()

console.log("message");

Outputs information in the console. Useful in debugging to check information in your app.

The output is only seen by the developer, not by the user of the app. Putting console.log statements through your code is one of the fastest ways to find out which parts are actually running.

setProperty()

setProperty("id", "property", "value");

Changes the look or property of a user interface element. For example, you can change the text in a text box or change the color of a button.

The three parts:

setProperty("scoreLabel", "text", "Score: 10");
setProperty("playButton", "background-color", "green");

setScreen()

setScreen("screenId");

Sets the screen of the app — this is how you move a user from one screen to another.

setScreen("gameScreen");

playSound()

playSound("url", "loop");

Plays audio. It takes two parameters:

playSound("sound://category_hits/hit_1.mp3", false);

onEvent()

onEvent("id", "type", function() {

});

The code inside an onEvent() block runs when triggered by an event, such as a mouse click or a key press.

onEvent("dogButton", "click", function() {
  setProperty("dogImage", "image", "dog.png");
});

This is the block that makes an app event-driven. Everything inside it waits for the user.

randomNumber()

randomNumber(1, 10);

Generates a random number between the first number and the second number, inclusive. "Inclusive" means both endpoints can come up — randomNumber(1, 10) can return 1 and can return 10.

setProperty("diceLabel", "text", randomNumber(1, 6));

Quick reference

---

App Lab block images are from Code.org's AP Computer Science Principles curriculum, used here for classroom instruction. Code.org curriculum is released under CC BY-NC-SA.