New Website
AppLab
AppLab
This page is being redesigned for the 2022 school year and is being constantly updated.
Be sure to REFRESH this page daily so that you are seeing the latest updates.
Follow the directions on this page. However, if you get stuck and/or something doesn't make sense, contact your teacher immediately.
Three-week projects are just that - projects that are completed in (usually) three weeks. These are generally projects where students can pick the topic. The grade will be based on these big criteria:
The overall PLANNING and PREPARATION for the project
The ability to honestly REFLECT, ASSESS, and make appropriate ADJUSTMENTS (as necessary) to the project build plan.
The quality of final ARTIFACT. This will be assessed in the following ways:
The UX (User Experience) of the finished product (does the program actually work, etc.)
How well the student follows good programming conventions when writing the code (whitespace, indentation, comments, naming conventions, user-created functions, organization/structure, etc.).
How well the student incorporates NEW coding structures that demonstrate learning and growth as a programmer. (i.e., don't show me what you already know how to do. Show me that you can learn and incorporate new ideas).
The weight of each of these criteria varies depending on the time of year and the project. Be sure to check your Daily Class Announcements for any changes/updates to the information on this page.
The THREE-WEEK project can be broken up into FIVE main chunks:
Iterative Project Development (building, testing, and continually making small improvements/adjustments)
While we generally do these in order, there is overlap between the last four chunks. For example, we are constantly reflecting on the project from the very first day (via our programming journal) and there are Reflection elements built in to the Iterative Project Development . . . that, in turn, can cause us to go back and refine our original plan. This is a very interactive and flexible process.
The Project Proposal can be chunked into TWO main steps:
Determine the Scope of your Project
What do you plan to build (a new project or are you extending another project)?
How much time do you have to build it?
Create your Project Proposal (ONE-PAGER)
First, you will need to decide what you want to do for your THREE-WEEK project. You have the following THREE basic options:
NEW PROJECT: You can create a NEW project from scratch. You are only limited by your imagination. If you are having trouble coming up with a project idea, here are some suggestions:
A WebLab Project (website)
A GameLab Project
Interactive animation/card
a 2D arcade-style game
An AppLab Project
a quiz game (trivial, personality, etc.)
a web app
a CYOA game (or an advanced CYOA game)
Code.org Enrichment
Learn new coding principles in order to make more advanced games/projects.
PROJECT EXTENSION: If you don't want to build/learn something new, you can EXTEND a previous project to make it better than it was before. You do NOT need to be the creator of the original project in order to EXTEND a project. There are many starter game projects that are available for extension. However, you may NOT attempt a game extension if you have never completed a project from scratch before. You must attempt at least one original project from scratch BEFORE you attempt to EXTEND a project.
BUILDING KNOWLEDGE: Instead of creating a new project (or extending an old project) you can instead use your time to do a deeper dive into skill building to help you with your future projects. Some possibilities include (but are not limited to):
Code.org: U7: AI and Machine Learning.
Advanced CYOA Programming (use lists and datasets to extend the functionality of your game simplify the extendability of your game strands).
Extend a Game Starter from the GameLab Tutorial Site.
Once you've selected your project type (NEW or EXTENSION), and your coding environment (WebLab, GameLab, or AppLab), you will create a ONE-PAGER (project proposal) for the idea you want to build/learn.
NOTE: Every time you start a new three-week project, you will need to submit a new ONE-PAGER to your teacher for approval - even if you are doing an EXTENSION project or a SKILL BUILDING project.
A typical ONE-PAGER is just like it sounds - a one page document about your project. This one page is like a resume for your project. It should contain all the important facts about the project you intend to build. The ONE-PAGER is what you submit to see if you project is approved. If you project gets approved, you can move on to the next step. If your project is NOT APPROVED, you will need to fix your ONE-PAGE and resubmit again for approval.
Typically, your ONE-PAGER is printed in hard-copy form. However, we will be creating and submitted a DIGITAL document. Since we will be submitting a digital document, you can use up to TWO pages of the digital document (but no more).
Additional information to include in your ONE-PAGER is listed below. Review the section that applies to the type of project that you intend to complete for further details and the link to your ONE PAGER form.
For any game project, be sure to also include the following information:
How does the basic game function? How do you play? What is the role of the user? Do you control a character/avatar? Do you use the mouse/keyboard? etc.
Objective of Game (how do you win? // how do you level up?)
A sketch (or sketches) of the various states of your game (splash screen, game play, levels, boss, game over, etc.). All games are different so what you sketch will depend on YOUR game. Your sketch(es) should make it clear to a stranger what you expect your final game will look like AND what the experience will be like.
On your sketch(es), you should identify all the sprites/variables you plan to use, the naming convention for the sprites/variables, and the expected behavior (functions) of your sprites. Be as detailed as possible.
For any website project, be sure to also include the following information:
What is the purpose of your site (why would people want to use your website)?
How does user navigate the Website? What does the main navigation look like and what does it include?
A wireframe sketch of the final version of each page of your site (all websites MUST be a minimum of three pages). Your wireframe sketches should detail all the main areas on your page and describe all the UI elements the user will interact with.
Clearly identify the main HTML elements and include the major CSS rule sets you plan to use.
For an App
What is the purpose of the App? Why would people want to use your app?
How does a user navigate your App?
A wireframe sketch of each UI screens that the user may interact with.
Each wireframe sketch should identify all of the screen elements (everything the user can and cannot see), proper naming conventions, and describe the basic purpose and function of any UI elements that the user actually interacts with.
Once again, remember that the formatting of the ONE-PAGER document is entirely up to you. Arrange your page in a way that best communicates your information. Use use solid visual communication and design strategies.
When you are finished, submit your document per the assignment instructions (usually in Google Classroom). If you are unsure how to submit your document, review the instructions on the Daily Class Announcements.
NOTE: Your ONE-PAGER / PROJECT PROPOSAL MUST BE APPROVED before you can get access to your PROJECT PREP materials.
NOTE: This section is for non-gaming apps. If you are making a game app, refer to the GAME PROJECTS section above.
For any App project, be sure to also include the following information:
What is the purpose of the App? Why would people want to use your app?
How does a user navigate your App?
A wireframe sketch of each UI screens that the user may interact with.
Each wireframe sketch should identify all of the screen elements (everything the user can and cannot see), proper naming conventions, and describe the basic purpose and function of any UI elements that the user actually interacts with.
Once again, remember that the formatting of the ONE-PAGER document is entirely up to you. Arrange your page in a way that best communicates your information. Use use solid visual communication and design strategies.
When you are finished, submit your document per the assignment instructions (usually in Google Classroom). If you are unsure how to submit your document, review the instructions on the Daily Class Announcements.
NOTE: Your ONE-PAGER / PROJECT PROPOSAL MUST BE APPROVED before you can get access to your PROJECT PREP materials.
Once again, remember that the formatting of the ONE-PAGER document is entirely up to you. Arrange your page in a way that best communicates your information. Use use solid visual communication and design strategies.
When you are finished, submit your document per the assignment instructions (usually in Google Classroom). If you are unsure how to submit your document, review the instructions on the Daily Class Announcements.
NOTE: Your ONE-PAGER / PROJECT PROPOSAL MUST BE APPROVED before you can get access to your PROJECT PREP materials.
Planning for your THREE WEEK PROJECT is important to get your project started off on the right footing. If you plan well, the rest of your project usually runs smoothly. If you plan poorly, you may encounter a lot of frustration while trying to build and complete your project.
The Project Planning can be chunked into FOUR (or FIVE) main steps:
Establishing and setting up your Programming Journal
Completing the Daily Entry sections of Your Programming Journal
Completing the "Prep" section of your Programming Journal
Completing the Version Schedule in your Programming Journal
Complete a Paper Prototype for your project (App projects only - not applicable for other project)
Once your ONE-PAGER IS approved, you will get access to your Programming Journal. The programming journal is usually located in Google Classroom. If you are having trouble locating it, refer to the Daily Class Announcements for details.
Your programming journal is where you will document your project scope, project planning, AND where you will keep a record of what you complete each day through the project cycle. As you progress through this project, it will be where you keep track of all your hurdles and all your success as you iterate through your builds.
As soon as you get access to your PJ, your should complete your COVER PAGE.
The first day you get access to your programming journal, you will need to begin completing the daily entries. There should be an entry recorded for each day of the project.
The video below will explain how to fill out the DAY OF PROJECT and WORK DAY portions of your programming journal.
NOTE: There are several versions of the programming journal - each one tailored to a specific type of project. Therefore, what you complete for prep work will vary slightly from project to project.
The first several pages of your PROGRAMMING JOURNAL are dedicated to your planning documents. All programming journals (PJ) have a cover sheet as the first page. Somewhere, several pages in, you will find the Version Schedule (VS) Table. Everything from the COVER SHEET up through the VS is considered part of your PREP work for your project. Fill out each page/table as required for your project. Be as thorough and as detailed as possible. The more you pay attentional to all the detailS in the PREP section, the easier your BUILD will be.
Full directions for this step are usually included in the Daily Announcements.
Since the Version Schedule (VS) has a bit more detail to it, there are special instructions for that section below.
The VERSION SCHEDULE (VS) is the final step of your PREP work. The VS serves several purposes:
It helps you plan your project by identifying all the iterative steps you plan to build throughout the project
It helps you manage your time by either:
helping to keep you on schedule, or
knowing when you might need to adjust your plan because you are too far behind (or too far ahead) of schedule.
It keeps links to archives of your completed builds for quick access.
The TASK column will help you organize your build. This column should list a description of each iteration/build of your project. You should organize the tasks in the order that you plan to complete each of these builds. This part of the table should be completed first. Once you've laid out all your builds, and you have them organized in a logical, sequential order, you can begin to complete the rest of the table.
The SCHEDULE TO FINISH column will help you plan out and schedule your time. Look at each task. How long will it take you to complete that task? What day to you expect to complete that task? Remember, you only have three weeks. Many students start with a specific plan for their project. Then, once they plan out how much time it will take to complete each task, they realize that they may need to modify (add or remove tasks) in order to either finish the build in three weeks OR in order to continue iterating their project over the course of three weeks.
In the VERSION column you will list VERSION NUMBER that you assign for that task. Your numbering system should match the modified semantic versioning we use for our class projects (see the section below for more information). Be sure to identify your major updates vs. your minor updates vs. your "baby-steps."
The DATE COMPLETED column will only be filled out when you successfully complete a working version of that task/build AND you have linked to the REMIXED version of that project. Your task is not considered complete until it is bug free, archived, and linked to your VS. Only then should you fill out the Date Completed section of your VS.
As you are working, you may find that some tasks take longer than your had anticipated and you might complete other tasks sooner than anticipated. This is normal. It's hard to predict, in the very beginning of your project, exactly how everything will play out in the future. Even if you find that you are getting wildly behind schedule, don't adjust your VS. Just keep an accurate record of when you complete your work.
However, if you find that you are way ahead of schedule, you will need to modify your VS by adding more tasks to complete. Remember, your goal is to continue to iterate throughout the entire three weeks of the project. Do NOT, under any circumstances, stop working if you complete all your tasks. Your job is to keep iterating for all three weeks. At the end of three weeks, you will submit what you have.
If you are starting a NEW project, your version numbering should start at 0.0.1 and (ideally) the final version of your project should be version 1.0.0 (a fully functional and complete project - ready for people to use and enjoy). However, depending on the scope of the project, you may not be able to build a project from 0.0.0 to 1.0.0 in three weeks. Therefore, it is possible to submit a project that is still incomplete (has not reached version 1.0.0) and still receive a good grade. Likewise, it is also possible that you could complete a fully functional project (made it to 1.0.0) and receive a poor grade because the project you planned out for your three-week project could have been finished in one week. EVERY. PROJECT. IS. DIFFERENT.
Remember, your goal is to continue to iterate for the entire three weeks. Your grade is based more in the journey (constant iterative development) rather the end (whatever project you end up with).
Our class versioning system follows the basic principles of Semantic Versioning but is adapted for our class use. We still use three places with each number separated by a dot (i.e., X.Y.Z where each letter represents a number).
It is important to note that this is NOT a decimal system. Each number (X, Y, or Z) can be any size. For example, 1.6.2 is just as valid as 2.823553.38 - it all depends on how you identify the tasks in your build. For our class we are usually trying to build our project up to VERSION 1. Version 1 is usually considered your first major release of your completely finished, working, and stable project. Therefore, unless you are extending an already working project, all your version numbers will likely be somewhere in the range from 0.0.0 to 1.0.0.
The X place holds the major version number. This is what we usually hear about with games. Is this version 1 of the game or version 3 of the game. It is reserved for major releases. In our class, if we take a game as an example, we would consider version 1.0.0 to be a fully working game with a splash screen, end screen, a scoreboard to keep track of stats, and multiple levels of increasing difficulty.
The Y place holds the major improvement to your program as you iterate though the builds towards version 1. For example, version 0.4.0 would be two major iterations BEFORE version 0.6.0 but neither of these iterations (versions) would be our final fully functional program (which would be 1.0.0).
The Z place holds all the iterations of your build as you work through your major improvements. In class, we usually call these the baby-steps of your iterations. These are the tiny changes you make in between major improvements of your build. For example, if between version 0.4.0 and 0.5.0 there were SIX baby-steps that I needed to accomplish the make this change, I would expect to see all of the following version numbers (listed in order from oldest (top) to newest (bottom):
0.4.0
0.4.1
0.4.2
0.4.3
0.4.4
0.4.5
0.4.6
0.5.0
If 0.4.6 is the last baby-step I need to do to finish my next major change, I don't need 0.4.7. Instead I jump straight to 0.5.0. Remember, this is NOT a decimal system. It is not uncommon to have version numbers that look like this: 0.17.32. It all depends on YOUR task list.
Finally, EVERY TIME you change your versioning (which is every time you complete a specific task) you should have a saved (REMIXED) file of the game at that version. EVERY saved version of your project should be bug free.
Never REMIX a "broken" project and never leave a task unfinished. ALWAYS make sure your new task is working BEFORE you move on to the next step.
If you are new to versioning, you should checkout the sample used on the DODGER game starter tutorial before you get started. Additionally, you should watch the two videos below to give you more background.
Still a little confused about how the versioning system works? Watch this video where I analyze the version numbering system used for the Dodger Game Starter Tutorial.
Still confused about how to fill out the versioning schedule in your PROGRAMMING JOURNAL? Watch this video where I evaluate and critique some previously submitted programming journals.
NOTE: This section is not completed for all projects. Generally, this is only completed for non-game web apps.
Sketch out, in detail, all parts of your project. This is different, and much more detailed, version of what you submitted with your ONE PAGER. This is an ANALOG version of the digital project you are trying to create.
If you are required to submit a digital document for this, most students find it easiest to create your actual paper prototype (on paper) and then take pictures of your completed work. Then, on your digital document, you can explain what is in your pictures.
Additionally, if you have an assignment posted in Google Classroom for the PAPER PROTOTYPE, please check for any specific directions there before you complete this step.
Building a programming project is a series of small, incremental steps. Because most programming languages are so exact, it is important that you constantly test your work to catch, and fix, all bugs as they happen.
Using your Version Schedule (VS) as your guide, you should attempt to tackle your first build (or whatever the next build is in your list).
Once you have completed your task (from your Version Schedule (VS)), you need to test and make sure that your build is bug free and stable/working. If you find bugs, you must fix them before you move on.
If your build/task is stable and bug free, you need to make an archive of that build so that you will have it for future reference. It should be a snapshot of that moment in your project.
Do NOT continue to iterate an archived build.
Once you have archived your build, create a link to that archived build in your Version Schedule so that you can have quick access to it when needed.
At this point, you should review your Version Schedule (VS). Are you on track? Do you need to modify anything regarding your project? If you do, make those changes to your VS. If not, select the next task in your VS and repeat the steps above.
Continue this process every day until the project is over.
Refer to the documentation in the Daily Class Announcements (the information below is old and waiting to be updated)
Use the following links to submit and/or view game projects UNLESS your teacher has specifically given you an alternate submission form (which is not uncommon, by the way). Check your Google Classroom posting for correct details BEFORE you submit:
Game Project Submission Form - Use this form to submit the SHARED LINK from Code.org for your current game project.
Game Project Spreadsheet (Archive) - Use this spreadsheet both to make sure your link has been properly submitted AND to access links from other archived game projects.
NOTE: Check out the Peer Evaluations page if you need a reminder of how the peer evaluations work.
In order to get ready for the Peer Evaluations, you will need to submit:
your most recent working build of your program
a link to your Programming Journal (PJ). Make sure you have changed the SHARING settings to GUHSD and that others have VIEWING rights only (do not give EDITING rights to anyone).
Two "Artist" questions to get specific feedback about your project.
Use the form below to submit your work and use the spreadsheet to make sure that your work was submitted correctly.
Three Week Project: Peer Evaluation Prep: Submission Form
Three Week Project: Peer Evaluation Prep: Spreadsheet
NOTE: Do NOT complete this step until you are instructed to do so in the Daily Class Announcements.
Follow these directions to complete the responder portion of the Peer Evaluations:
Use the Spreadsheet from the Peer Evaluation Prep activity to find your group.
Use the links in the spreadsheet to review the work of each of your group members
When you are finished reviewing the work:
Complete one Peer Evaluation: Responder form for EACH MEMBER OF YOUR GROUP.
Check the Peer Evaluation: Responder Submission Spreadsheet to verify that your work was submitted properly.
NOTE: The spreadsheet from the Peer Evaluation Prep activity is slightly locked down so you will NOT be able to copy in the usual way that you can on most documents. If you want to copy something from that spreadsheet so that you can paste it in the "Responder" form (like the Artist Questions), you will need to copy your information from the "fx" bar above the column headers of the spreadsheet. For example, if I want to copy the information from cell G2, I would select G2 in the spreadsheet, go up to the "fx" bar above the column headers, and copy the information from the "fx" bar, rather than the G2 cell. I can now paste the information from cell G2 into my form.
[Hidden]
[Hidden]