New Website
WebLab
WebLab
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.
Follow the directions on this page if you are attempting to create a NEW WEBSITE in Code.org's WebLab.
Remember, that the directions on this page are general directions. They should work for most kinds of websites that can be built in WebLab. However, since each website is unique, some of the instructions may need to be modified and some may not apply to you at all.
If you have any questions about your build, be sure check with your teacher immediately for clarification.
Remember that each THREE-WEEK PROJECT is usually completed in three weeks (or 15 normal school days). However, due to external factors, the exact time allocated for this TWP could be more or fewer than 15 school days. Check the Daily Class Announcements for full details on the time frame for this project.
The general criteria for grading will be based on the following:
How well a student properly PREPARES and PLANS OUT the entire project before attempting the first skeletal HTML build.
How well the student honestly REFLECTS, ASSESSES, and makes appropriate ADJUSTMENTS (as necessary) to the project build.
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 THREE-WEEK project can be broken up into FIVE main chunks:
Project Proposal
Project Planning
Iterative Project Development (building, testing, and continually making small improvements/adjustments)
Final Project Submission
Evaluation, Feedback, and Reflection
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.
Your project should be 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 (content, how many pages, etc.)?
How much time will it take to build each component of your project?
How much time do you have to build it?
Create your Project Proposal (ONE-PAGER)
You will need to decide what you think you can accomplish in the time we have allocated for this project. Coming up with a REALISTIC idea of what you can successfully build over the 15 days is an important skill to develop. We are not looking for the best project you can make. We are looking for the best project you can make in 15 days. Make sure you understand the difference and keep that in mind as you craft your ONE-PAGER.
Note: it is always better to over-plan (and not get to everything) than it is to under-plan and finish early. Wherever you ultimately end up on Day 15 with your project, you should be working to make improvements during every day of the project cycle.
First, you will need to decide what kid of website you want to build.
Next, you will need to break down each of the components that are a part of your new site. Think of things like:
CONTENT: What kind of content will be on your page. What text information will you need? Will there be media (pictures, sounds, graphics, videos, etc.)? If so, where will they come from? Do you have rights/permissions to use that material?
LAYOUT: How will you arrange your information on each page? What colors/theme will you use? How will users navigate your site?
BUILD: How long will it take you to build the HTML Draft? How long will it take you to add in the CSS? Is there anything NEW you need to learn how to do in order to complete your build?
Then, you will need to estimate how much time it will take to complete each step of your work above:
How much time will it take to gather all your content, verify permissions, and cite your sources?
How much time will it take to plan out your design and allocate where each piece of your content will reside on your page?
How much time will it take to set up a working navigation throughout your site? How much time will it take to build a full working HTML draft with all your content? How much time will it take to layer in your CSS to complete your final design/layout?
Finally, you will need to know how much time you have from start to finish for this project. Most TWP cycles are for 15 school days. However, you can expect at least TWO full school days to be devoted to some sort of peer evaluation. You can also expect to lose up to ONE DAY EACH at the beginning and end of your project (as you ramp everything up at the beginning and your wind everything down at the end. That really leaves you closer to 10 full work days to complete your project. Make sure you budget your time appropriately and/or modify your project to fit your project cycle.
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).
When your ONE-PAGER gets approved, you gain access to your PROGRAMMING JOURNAL.
For any website project, be sure to include the following information on your ONE PAGER:
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 what you think the final version of each page will look like (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.
Make a copy of the New Website: ONE-PAGER document, follow the embedded DIRECTIONS in the document, and refer to the ONE PAGER Components section (above) to help you complete your proposal.
Keep the document PRIVATE but give your teacher COMMENTING rights. You can't earn any points for your work if I can't see your work.
Remember that the formatting of the ONE-PAGER document is entirely up to you. Each project is different so each ONE PAGER will be arranged differently from other projects. Arrange your ONE PAGER in a way that best communicates the information that you need to communicate. Be sure you use solid visual communication and design strategies.
When you are sure you have completed all the requirements for the ONE-PAGER, go to the ONE PAGER section of the Three Week Project: Submission Forms page to submit your digital document for approval.
Once your ONE-PAGER IS approved, you can start earning points on the rest of your project.
Your first big assessment will be on the quality of the PLANNING you do before you start your build.
To get your project started off on the right footing, you need a solid plan for the next three weeks.
If you plan well, the rest of your project usually runs smoothly. If you plan poorly, you will likely encounter a lot of frustration while trying to build and complete your project.
The Project Planning can be chunked into FOUR main steps:
Establish and set up your Programming Journal
Complete the Daily Entry section of Your Programming Journal (one entry completed for each day of the project).
Complete the Version Schedule in your Programming Journal (this should be completed prior to starting your first build).
Complete the "Prep" section of your Programming Journal (this should be done prior to starting your first build).
Note: be aware that you cannot make up any of your planning work after you begin your build. Once you've started your build, you have moved beyond the PLANNING phase (and beyond the ability to earn any more points for this portion of your project). Therefore, be sure you have completed all your planning steps before you begin working on any portion of your digital build.
Your programming journal is where you will document your project scope, your project planning and prep work, AND where you will keep a record of your daily reflections about your work/progress throughout the project cycle.
As soon as you get access to your PJ, your should complete your COVER PAGE.
Make a copy of the New Basic Website: Programming Journal.
The directions for completing each section of the PJ are listed throughout the rest of this PROJECT PLANNING section on this website. Keep reading for all the details.
In order to make your document available for periodic checkups (as well as your final submission), you are going to SUBMIT your document NOW. Don't worry, you can keep on making edits to your document after you submit.
Before submitting, be sure to keep the document PRIVATE but give your teacher COMMENTING rights. You can't earn any points for your work if your teacher can't see your work.
Go to the Programming Journal section of the Three Week Project: Submission Forms page to digitally submit your work.
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.
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: 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 (after the Version Schedule) are dedicated to your planning documents. Everything from the VS to the first Daily Journal Entry should be part of your PREP work and all the documents should be completed before you attempt to build your project.
Fill out each page/table as required. 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.
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.
Since Peer Evaluations are a whole-class project, and not all students are completing the same project for their THREE WEEK PROJECT, you will need to navigate to the Peer Evaluations section of the TWP Submission Forms Page to complete the Peer Evaluations for this project.
Make a copy of the TWP: New Website: Final Reflection and Self Evaluation document and follow the embedded instructions.
Navigate to the Final Reflection section of the TWP Submission Forms Page to submit your work.
[Hidden]