A Project for Your Community

Most student projects begin with an idea: “Let’s make an app!” Then the team spends weeks building it, and finds at the end that nobody needs it, or that it solves the wrong problem. Good projects begin the other way round: with people, and a problem they really have.

A user is a person who will use what you make. A need is something a user has to do, or wants, and finds hard now. Your first job is to find a real need, and the only reliable way to find one is to talk to the people who have it, and watch them.

Asking well

An interview is a planned talk with a user, to learn about their life and the problem. It sounds easy, but the most natural questions are the worst ones. Ask “Would you use an app that reminds you about the pump?” and almost everyone says yes, to be kind. Then nobody uses it.

So ask about what they do now, and about real times in the past, not about your idea and not about the future:

• “How do you find out what the ward office has decided?”
• “Tell me about the last time the tank overflowed. What happened?”
• “What did you do the last time you couldn’t find a book?”

Then listen much more than you talk. When they say something interesting, ask “Why?” or “Can you show me?” Write down their own words. Don’t describe your idea until the end, if at all.

Watching

What people say they do and what they really do are often different. So, when you can, observe: watch someone do the task the way they do it now. Stand by the ward office’s notice board for half an hour and count who stops, who reads, and who asks someone else to read it for them. Sit in the library and see what students do when they can’t find a book. You will see problems nobody thought to mention.

Ask before you watch someone closely, and tell them why. You will learn more about privacy and the people you work with later in this unit.

After the interviews, write down what you learned in one sentence, a problem statement: who has the problem, what they need, and why it matters.

Students in Classes 3 to 8 can’t find out whether the library has a book, or where it is, without asking the librarian, who is busy with other classes.

A problem statement names people and a need, not a solution. It doesn’t say “we will make a Python program”. That keeps you open to the best answer.

Next, decide what the thing you make, your product, must do. These are its requirements. Sort them into three lists:

• Must have: without these, it doesn’t meet the need. Keep this list short.
• Nice to have: these would help, but the product works without them. Do them only if there is time.
• Not this project: good ideas that are too big, too risky or not what the users asked for. Writing them down stops the team arguing about them again.

For each must, write a success check: a test that shows whether it is done, in words a user would understand. “A Class 4 student can find which shelf Muna Madan is on, typing it in her own way, in under a minute.” A success check is like a test in Unit 3, but for people as well as programs.

Which tool?

In this book you have three ways to build something. Choose the one that fits the need, not the one you like best:

A project like this is too big for one person in nine periods, and it is better done together: different people notice different things. But a team only works if everyone in it can take part, learn and be heard. Working so that every member contributes, whatever their gender, language, confidence or what they have at home, is called inclusive collaboration. Professional programmers work this way too: most software is written in teams, and a program that only one person understands is a risk.

Roles

Give each member a role: a job they are responsible for. With four members, for example:

In a team of two or three, each member holds more than one role. A role says who makes sure a job gets done, not who does all of it. Everyone builds and everyone tests. Swap roles halfway through, so that each person does more than one kind of work.

Pair programming

When two people build together at one computer, one is the driver, who types, and the other is the navigator, who reads every line as it is typed, spots mistakes and thinks about the next step. This is pair programming. Swap every 10 minutes or so, so that both type and both think. It also means two people understand every line, so the team isn’t stuck if one is absent.

A team agreement

Before you start, write a short team agreement: the rules you all promise to follow. For example:

1. Everyone gets a turn at the keyboard, the person with no computer at home first.
2. Before deciding, each of us says our idea once, the quietest first.
3. We may disagree with an idea, never laugh at a person.
4. When we can’t agree, we try both with a user, and the user decides.
5. We meet and plan where everyone can come: at school, or on a phone every member has.
6. We speak Nepali, English or another language we share, whichever helps.
7. The record keeper writes down who did each part.

A team that tries to build everything at once usually ends with nothing that works. Instead, build a first version that is as small as possible but already helps: the musts only, and only the simplest form of each. Test it. Then improve it, a step at a time. Figure 11.2 shows the whole project.

Break the work into tasks, each small enough to finish in one period, just as Unit 4 breaks a program into functions. Write them in a table: what, who, by when, done. Here is part of the library team’s plan:

Keep each version of your work, named as in Unit 8 (library-finder-v01.py, library-finder-v02.py), and keep a project log: a few lines each period saying what you did, what went wrong and what you decided. When something breaks, you can go back to the version that worked. When you present, the log tells the story of what changed and why.

You have tested programs with chosen inputs (Unit 3) and watched someone use a web page (Unit 5). Testing a project with its users joins the two.

First, test it yourselves: run every success check and a table of ordinary, edge and wrong tests, and fix what fails. Never give users something that crashes on the first try.

Then test with users:

1. Choose different users. Who might use it differently from you? Someone older, someone younger, someone who reads Nepali more easily than English, someone with an older phone or a weak signal, someone who can’t see or hear well, someone who has never used anything like it. People who differ in these ways are called diverse users. A product that works for all of them works better for everyone.
2. Give each a task, not a tour: “Find out where Karnali Blues is.”
3. Watch, and don’t help. Ask them to say aloud what they are thinking. Write down where they stop, what they try, and what they say, in their words.
4. Afterward, ask what was hard, and thank them.

Then write what you found in a findings table, and decide what to change. Fix the problems that stop people first, then the ones that slow them down; the small things last, if there is time.

A team in Bhaktapur talked to their ward secretary. She said the ward office posts notices on a board outside, but many people never pass it: people who work all day, older people who don’t walk far, families who moved away for work. The team watched the board for an afternoon: in two hours, nine people stopped to read it. Their problem statement:

People in Ward 5 miss notices about vaccination camps, trainings and meetings, because the notices are only on the board outside the office.

They chose a web page (Unit 5), because notices are information many people read. Their musts: this month’s notices, each with its date and place, in Nepali and English; the office’s hours and phone number; readable on any phone. Their limits, written down from the start: the ward secretary must approve every notice before it goes on the page; someone at the office must take over updating it, or it will soon be out of date; and the board outside stays, for people who aren’t online.

They built a first version and tested it with four people. Here it is, with what each tester said.

The library team’s first version (Unit 3’s linear search, with a second list for the shelves) passed all the team’s own tests:

titles = ["Muna Madan", "Palpasa Cafe", "Karnali Blues", "Seto Dharti", "Sumnima", "Shirishko Phool"]shelves = [2, 5, 5, 3, 2, 3]target = input("Which book? ")i = 0found = Falsewhile i < len(titles) and not found:    if titles[i] == target:        found = True    else:        i = i + 1if found:    print(target, "is on shelf", shelves[i])else:    print("Sorry, we don't have", target)

Which book? Muna MadanMuna Madan is on shelf 2

Then real users tried it, and the findings table above shows what happened. A Class 4 student typed the title in small letters:

Which book? muna madanSorry, we don't have muna madan

The library does have it. The program is right by its own rule: "muna madan" == "Muna Madan" is False, because a small letter and a capital are different characters. But for her, the program is wrong, and it told her something untrue. An algorithm that works well for some people and badly for others is biased, like Grade 7’s models trained on one-sided examples, even when nobody meant it to be. This one favors users who type exactly as the team did.

Changing the algorithm for its users

To fix it, the team changed the algorithm, not the users. They needed two tools: one you met in Unit 4’s quiz, and one they looked up in Python’s documentation, as Unit 4 showed:

• .lower() gives a copy of a string with every capital made small: "Muna Madan".lower() is "muna madan". Comparing two strings after .lower() ignores capitals.
• in between two strings (the new one) is True when the first is found anywhere inside the second: "karnali" in "karnali blues" is True. (In Unit 3 you used in to ask whether an item is in a list; between strings, it looks for a piece of text.)

A word can be in several titles, so the search can no longer stop at the first match. Version 2 looks at every title with a for loop, prints each one that matches, and counts them. The question “does this title match?” got a small function of its own, as Unit 4 teaches, so that it can be tested alone and changed in one place. The team also added the books’ Nepali titles, for younger students who read Nepali more easily, and replaced the untrue “Sorry, we don’t have it” with a message that says what to do next.

def matches(target, title, nepali_title):    """Return True if target is inside either title, ignoring capitals."""    return target.lower() in title.lower() or target in nepali_title titles = ["Muna Madan", "Palpasa Cafe", "Karnali Blues", "Seto Dharti", "Sumnima", "Shirishko Phool"]nepali = ["मुनामदन", "पल्पसा क्याफे", "कर्णाली ब्लुज", "सेतो धरती", "सुम्निमा", "शिरीषको फूल"]shelves = [2, 5, 5, 3, 2, 3]target = input("Which book? A word from its title is enough: ")found = 0for i in range(len(titles)):    if matches(target, titles[i], nepali[i]):        print(titles[i], "(" + nepali[i] + ") is on shelf", shelves[i])        found = found + 1if found == 0:    print("No book found with", target, "in its title.")    print("Check the spelling, or ask the librarian.")

Which book? A word from its title is enough: karnaliKarnali Blues (कर्णाली ब्लुज) is on shelf 5

Run it, and try muna, SETO, सेतो, phool and Harry Potter. The function matches(), lines 1 to 3, does all the work. target.lower() in title.lower() makes both small, then looks for the target inside the title. Devanagari has no capital letters, so the Nepali titles are searched as they are. It returns True or False, so line 11 can use its answer straight in an if, as Unit 4’s is_even() was used.

Changing an algorithm that does harm

The librarian then asked for one more thing: a list of late books, to pin on the notice board. The team’s first try did exactly what she asked:

names = ["Aarati", "Bikash", "Dawa", "Gita", "Hari"]days_late = [0, 12, 0, 3, 30]print("LATE BOOKS")for i in range(len(names)):    if days_late[i] > 0:        print(names[i], "is", days_late[i], "days late. Fine: Rs", days_late[i] * 2)

LATE BOOKSBikash is 12 days late. Fine: Rs 24Gita is 3 days late. Fine: Rs 6Hari is 30 days late. Fine: Rs 60

The program has no bug. But when the team showed it to some students, one said quietly that Hari’s family couldn’t pay Rs 60, and that the whole school would read it. A list like this shames students in public, for something that is between them and the library. So the team changed the algorithm: the notice board shows only how many books are late, and each student finds out about their own at the library desk, by their roll number.

names = ["Aarati", "Bikash", "Dawa", "Gita", "Hari"]days_late = [0, 12, 0, 3, 30]late = 0for i in range(len(names)):    if days_late[i] > 0:        late = late + 1print(late, "books are late. Please bring them back this week.") roll = int(input("Roll number: "))i = roll - 1if days_late[i] > 0:    print(names[i] + ", your book is", days_late[i], "days late. Fine: Rs", days_late[i] * 2)else:    print(names[i] + ", you have no late books.")

3 books are late. Please bring them back this week.Roll number: 2Bikash, your book is 12 days late. Fine: Rs 24

The data is the same; what the program shows, and to whom, has changed. Lines 1 to 7 are for everyone; lines 9 to 14 are for one student at a time, with the librarian.

A team asked their families what went wrong at home. Three of them told the same story: someone switches on the pump to fill the roof tank, gets busy, and forgets; the tank overflows, wasting water and electricity; once, a pump ran dry and burnt out. A shop-bought water level controller does the whole job (Unit 7), but none of these families had one. So the team made a pump reminder on the board: press A when you switch the pump on, and it beeps when the tank should be full.

They timed their own roof tank: it took 8 minutes to fill. For testing on this page, the program counts a second as a minute, so you don’t wait 8 real minutes. On a real board, MINUTE would be 60000, the number of milliseconds in a minute.

Before using it, the team tested it at home with their families. The findings:

• Hajurama, who is 76, was in the kitchen when it beeped: “I never heard it.” Older people often lose high notes first, and 2,500 Hz is high. The beeps also stopped after four seconds, whoever had heard them.
• Didi pressed A and saw nothing: “Is it working? Did it hear me?” The display stayed blank for 8 minutes.
• Bhai saw the tank overflowing early, because the water pressure was high that day, and switched off the pump. The reminder beeped anyway, minutes later, and there was no way to stop it.

The team also wrote down its limits. The reminder doesn’t know how full the tank really is: on a day with low water pressure it fills more slowly, and the reminder beeps too early. A real level sensor, such as a float switch at the top of the tank, would know: a real micro:bit can read a switch wired to one of its pins, and beep when the water lifts the float, however long the tank took. That would be version 3. The board must stay dry, and nobody in the team touches the pump’s own wiring: mains electricity is a job for an electrician.

When you present your project, people need to know which parts are yours, which came from others, and how you treated the people who helped.

Credit every source

You learned how to credit pictures and music in Grade 6 and Unit 6. In a project, credit everything you used that you didn’t make: photos, icons, music, text, data, and code. If a few lines came from a book, a website or a classmate, say where, in a comment beside them. The search in our library finder came from Unit 3 of this book; its credits say so.

Credit every teammate

Say who did what, honestly. Not “we all did everything”, but each person’s real part: who interviewed, who built which part, who tested, who kept the records. It is fair to each member, and it is how a teacher can mark each one fairly.

Say how you used AI

If you used an AI tool, say how, in a short AI-use note, as Unit 10 explains: which tool and when, what you asked it, what you used from its answers, and how you checked them. Never hand in code an AI wrote that you can’t explain line by line: you must be able to answer any question about your own product.

Here are the library team’s credits, at the end of their program:

Library Finder, version 3, Mangsir 2083Made for the school library and the students of Classes 3 to 8. Team:  Aarati: interviews and user tests, presentation  Bikash: the search, the Nepali titles  Dawa: the late-books list, the test table  Gita: the book list, the project log, these credits Thanks to: our librarian, who told us what she needed and testedevery version, and the 9 students who tried it. Sources: the linear search from Grade 8 Computing, Unit 3."in" between two strings from the Python documentation(docs.python.org). AI-use note: Bikash used a chatbot (its name) on 3 Mangsir 2083 toask what an IndexError means and how to stop one. We used itsexplanation, wrote the fix ourselves, and tested it with rollnumbers 0, 1, 5, 6 and 9. The book list and these credits: CC BY 4.0, the team above.

Your own license

Your project is your work, and your team owns it (Grade 6). You can share it under a Creative Commons license, as you learned in Unit 6, so that others can use it with credit. For a page’s words and pictures, a Creative Commons license fits well. For program code, Creative Commons itself advises a license made for software instead; ask your teacher before choosing one.

The privacy of the people you work with

The people who help you trust you with their time, their words and sometimes their problems. Look after them, using what you learned in Unit 9:

• Ask first. Tell them who you are, what the project is and what you will do with their answers. They may say no, or stop at any time.
• Record only with permission: a voice recording or a photo needs their yes, and a child’s photo needs a parent’s and the school’s permission too.
• Keep names out of your notes and presentation unless they agree: “User 2, a grandmother, about 75” is enough.
• Never put real people’s data in a test. Use made-up names and numbers, as this unit does. The real list of borrowers stays with the librarian.
• Delete recordings and notes you no longer need when the project ends.

At the end, show your product to your class and, if you can, to its users. A good presentation is short, about five minutes, and every member speaks. It tells a story in this order:

1. The need. Who has the problem, in their words: “I never know when the vaccination camp is.”
2. What you made. Show it working, live: a user’s real task, from start to finish.
3. What testing changed. Version 1 beside the final version, and what each user taught you. This is often the most interesting part.
4. Its limits, honestly, and what you would do next.
5. Credits: your sources, your AI-use note, and who did what.

Then, if the product is to be used, hand it over: show the user how to use it, give them a short written guide, and agree who will keep it up to date.

After presenting, each member writes a short reflection in their own words: what you did, what you learned, what was hard, and what you would do differently next time.

Start your page or your device here; for a Python program, press Edit on the program below. Your work is kept in this browser, so copy it into a file (Unit 8) at the end of each period too.