Course Syllabus

Course Description

This course will teach you the skills and techniques necessary for creating sophisticated and accessible interactive web applications. It focuses on the client-side languages, tools, and libraries that professionals use to build the web sites you use every day. We will learn not only the basic syntax and mechanics of web development, but also the best practices that separate professional developers from amateurs. Upon completing this course, students will be able to build robust web applications, and will have the foundation for independently learning new skills in the ever-changing world of web development. This course is intense and our expectations are high, but we will make sure that everyone, including those totally new to web programming, are able to succeed.

either CSE 123, 143, CSE 154, or CSE 163; and INFO 201

Learning Objectives

After completing this course, students will be able to:

  • Produce web pages that are well-formed, standards-compliant, semantically rich, and universally accessible.
  • Style the appearance of those pages to create intuitive, usable, and engaging experiences for human readers on different kinds of devices.
  • Create interactive and feature-rich web applications leveraging existing programming frameworks, libraries, and APIs.
  • Interpret software documentation in order to reuse packages, APIs, and tools for web development.
  • Use development tools to automatically manage, implement, and validate web applications.
  • Use version control systems to collaborative manage software projects.
  • Critically examine the values underlying tools, APIs, and other web technologies prior to selecting them.
  • Consider how the design and implementation of web applications can shape who can and cannot access information online.

Course Structure

As with any form of computer programming, the best way to learn web development is by doing it. Moreover, web programming is a constantly and rapidly changing discipline, so professional developers need to constantly learn new tools and techniques on their own.

Thus the overall structure of this course is to provide you with the resources and information needed to learn the material (via videos, the course book, and in-class lecture demos) and the opportunities to practice and learn that material by doing (via the assignments). But it will also require you to take significant responsibility for your own learning: it is up to you to read the course materials, attend lecture demos, attempt the assignments, and to be willing to ask questions and seek help if there are any problems. You are accountable for your own learning—but we are here to help!

Class Meetings (Lectures)

Lecture time will be used to review and demo the material—providing the kinds of examples and practice that work better synchronously. Lectures will not necessarily cover all material needed for the course; you are responsible for learning additional details from the course textbook and other provided resources. Coming to lecture will not be sufficient on its own—but it's still a really good idea!

This course is offered in an "in-person" modality; students are expected to attend and participate in class meetings. However, in order to accommodate students, all lecture meetings will also be live-streamed through Zoom. Lectures won't create a true "hybrid" experience—we'll focus on students who attend in person, and the quality of any streaming may vary—but that option will be available for students who need it.

Pro tip: Make an effort to attend and engage with every class meeting! It's really the best way to learn the material and succeed in the course. There is a really strong correlation between who comes to lecture and who gets high scores in the course.

Lab Meetings

Lab meeting time will be used primarily to collaborate on the group project. All students are required to attend lab section with their group.

Most lab meetings will have a graded check-in or deliverable to help encourage participation.

Safety Precautions for In-Person Meetings

Per the University of Washington COVID-19 policies, the University recommends wearing a high-quality mask inside UW facilities, and masks are strongly recommended indoors the first two weeks of each quarter. However, you are not required to wear a mask, and your choice about masking will have no effect on your grade or your standing in this class.

Masks remain an important tool against respiratory illnesses of all kinds and offer greater protection that can help all in our community feel safe. When you mask up, choose a well-fitted, high-quality mask — such as a KF94, KN95, N95 or surgical mask — which when worn correctly protects you as well as those around you. People need to or choose to wear masks for a wide range of reasons, and we should not make assumptions. It is critical that we respect their needs and choices and that we extend each other grace.

Wearing a mask is a curtesy to those who may be more vulnerable to COVID-19, including those of us who have vulnerable family members at home. I will be wearing a mask during class meetings, and encourage you to do the same.

Inclement Weather

In the case of snow, fire, or other climate-based events that make traveling difficult or dangerous, class meetings (lectures and labs) will be held synchronously on Zoom instead of in-person. We will strive to announce any changes in modality by 10pm the previous evening.

Assignments

Find complete assignment details and due dates on the Assignments page.

This course will involve two types of assignments:

Problem Sets

Each topic in this course will be accompanied by a number of practice problems. Each problem is a directed programming exercise designed to give you practice with a particular web development concept. Problem sets are automatically graded (and you can attempt them repeatedly until all their functionality checks pass). Problem sets will be graded on a "completion" basis: you will get credit when the problem is finished and passes its checks.

Course Project

You will complete a group project that brings together the concepts learned through the exercises. This project will be an interactive web applications of your own design—the requirements are open-ended enough to let you develop something that is of interest to and appropriate to you.

The project will be completed in groups of 2-4 people in order to practice collaboration and to keep the workload manageable. You can pick your own group, and we will help you find teammates if needed.

The project will be completed iteratively, meaning you'll be working on it in pieces (turning in these pieces as you go). The project has 4 main deliverables:

  1. The proposal: a short written description of what web application you'll be building. This will let you get feedback on your idea early to make sure you're headed in the right direction.

  2. The first draft: a "static mockup" of your project using HTML and CSS. This version of the project won't be interactive or have any functionality, but it will provide the complete structure and appearance of all the content.

    You can think of this as the "midterm" draft.

    We will evaluate and score the draft to give you feedback on how your project is going. However, your work will be considered as a "draft"—it's okay to have some problems or issues that you will fix later!

  3. The second draft: a conversion of your static mock-up into a React application. This will primarily involve refactoring—restructuring the code without necessarily changing what it does. Completing this draft will make sure you're ready to complete the project's functionality in React.

    We'll evaluate this draft to make sure that you're on track to finish the final deliverable. As long as you have made sufficient progress towards the final React version of the application you will get credit for meeting this deliverable.

  4. The final product: the completed working app build using the React framework, meeting all of the requirements.

See the specific assignments for more details about each deliverable.

In addition, each week's lab deliverables will involve work on your project. You must attend and participate in the lab activity in order to receive credit for that lab. See the lab assignment details for more information.

Correspondence

We will send out official course announcements and information by posting them as Canvas announcements. Please make sure you have enabled notifications so you don't miss anything!

We will be using Ed Discussion for questions and help. Ed is a Q&A message board specifically designed for helping you get help fast and efficiency from both teaching staff and your classmates (and was designed for programming courses in particular!). You can find our class page at https://edstem.org/us/courses/66394/discussion/—you should have access through your UW account, but let me know if you have any problems. I strongly encourage you to use Ed to ask questions (rather than sending me an email). It will allow you to better structure questions and facilitates the kinds of back-and-forth that come up when talking about programming. This also lets you get support from all of the teaching staff as well as any of your classmates all at once!

  • Yes, this means that if you know the answer to a question, you should share that!
  • Note that while you can easily post code snippets, please don't post solutions to assignments or exercises; don't deprive others of the chance to learn!
  • If you need any help accessing or using Ed, please let us know.

Make sure to check this guide for how to most effectively ask coding questions and get helpful answers as fast as possible!

The best way to get questions answered will be on Ed. If you post a message, we will try to get back to you as soon as we can. Please be patient if we are not able to respond to any messages immediately; we may need time to get to and focus on your questions.

You are also welcome to email me at any time. When emailing, please make sure to sign your emails! This will let me know who is writing and will help us to better answer questions. Please do not send me messages through Canvas; they tend to be hard to track and respond to! You can also reach me on Microsoft Teams.

Official office hours are listed on the home page, but I'm also more than happy to try and schedule separate appointments at a time that works well for you if needed. Don't be shy; please ask for help if you need it.

You are NOT expected or required to learn everything on your own! The best way to learn is to ask questions. Please don't be shy or embarrassed; ask for help if you need it! We are here for you!

Grading and Deadlines

Your grade in this course will depend on your completing the problem sets and project to demonstrate a satisfactory level of mastery. But honestly, grades in a course should be the least of your worries. Our goal is to try and reduce course stress and provide some flexibility in deadlines, as noted below.

Problem Sets

Problem sets are graded on a "completion" basis. If your exercises pass all their checks, you get full credit for that set. We'll also give partial credit if only a percentage of checks pass (as long as you turn them in).

Problem sets are due on the date listed on the Assignments page. However, we will provide a "grace period" for all problem sets—you can turn each in up to 2 days late at no penalty. After that, problem sets can be turned in for a maximum of 80% credit. Problem sets will only be accepted for limited period after the deadline—you cannot turn in everything during the last week. See the specific assignment pages for details. These deadlines are intended to help keep you on track, while also accounting for difficulties people may have.

Project

Projects will be graded on a rubric assessing at a high level whether you've demonstrated that you understand and can successfully apply the concepts. See the individual project specifications for details.

You are expected to complete each project deliverable by the date listed on the Assignments page. There is no grace period for project deliverables (neither drafts nor the final version); this is to make sure we have time to grade them and give you feedback. Late project deliverables will not be considered satisfactory (so generally earning 75% or less).

The projects are developed iteratively, which is why there are multiple drafts. Part of iterating through a software project is making mistakes and then fixing them. As such, a deliverable that fixes noted problems in the previous draft can cause the score in that previous draft to be increased by up to 20%. For example, if you score an 75% on draft 1, fixing those problems in draft 2 can increase draft 1's score from 75% to 95%. This change only applies to the immediately preceding draft (so the final draft won't increase the score of draft 1).

We also can and will provide extensions/etc. for emergency situations, such as illness or other external circumstances that mean you cannot make any of these deadlines. Please let us know ahead of time—we will be unable to make adjustments at the last minute. If you get sick, please give us a quick heads-up to let us know so we can be ready to help.

Final grades are determined based on the iSchool Undergraduate Grading Scheme. Overall, I urge everyone to focus not on the grade itself but on learning what's necessary to earn high scores; the grades will follow from that.

Grading Groupwork

All software is built in teams. iSchool courses such as this one aim to give you experience working in teams. Apart from the logistic benefits, practicing teamwork—even when there are problems—is how you will learn to thrive in all work settings in the future. Moreover, being in a group enables you to help each other learn. You are not expected to do things "on your own"; instead you should seek help from your teammates (and provide help to your teammates when they need it!).

In this class we grade group work (projects, etc.) as a single assignment: all group members receive the same score for that project. We do not grade each "part" or each person's work separately. You are a team, not just 4 people doing individual work in the same Github repository. In academia and in the “real world”, teamwork is evaluated based on the success of the team, not on the work of any individual. If a teammate is struggling to complete some work, it is your responsibility to help them learn.

Students with particular strong or particularly weak contributions and support of the project will have their scores adjusted slightly. For example, students who do extra work performing project management or supporting/teaching other students will have their scores increased (earn "extra credit"). Students with poor communication or who miss group-set deadlines may have their scores reduced. Such teamwork contribution will be assessed holistically through peer evaluations.

Thus the best way to ensure that you've contributed your fair share is to communicate with your teammates so that you are all in agreement about what is fair. Everyone staying in touch is the best way to keep work from being or seeming unfair.

At the same time, your individual grade in the course needs to reflect your individual mastery of the course material. Thus in order to earn full credit on the project, each individual will need to demonstrate that they understand the material. We will review each individuals work and git commit history in order to confirm that your contributions demonstrate proficiency with all course concepts. Students who do not do this will not earn full credit on the project. Note that students must contribute work through individual git commits in order to receive full credit on the project.

Resources & Accommodations

During this time of an international health and social crisis, students are encouraged to be attentive to their needs for health and well-being (physical and mental). Students are susceptible to COVID, flu, colds, or other common illnesses due to stress, overwork, and disruption of routines (diet, exercise, sleep). Caring for family and friends who are ill adds another responsibility competing for your time. Please do your best to attend to your self-care during this time.

If health-related needs are delaying you from completing coursework, please contact your instructor. Faculty in the iSchool have been encouraged to be accommodating and give deadline extensions of up to one week without any academic penalty. If you need more time, please propose a schedule to your instructor that indicates how you can return to keeping current with your assignments. Allowing extensions is entirely at the instructor's discretion.

If your personal illness or family need is severe and will prevent you from completing the class, please let your instructor know and then contact your Academic Advisor to discuss all your options.

A number of challenges from a variety of directions can affect your ability to bring your optimal attention and energy to a course. Student Resources is a set of links to campus resources that UW makes available to students in trying to mitigate and cope with some of these challenges. This includes disability accommodations, physical and mental health, and community connections among others. If you are having any difficulties, please contact your academic advisor for support, or Health & Wellness at http://livewill.uw.edu. Furthermore, please notify the professor if you are comfortable in doing so. This will enable me to provide any resources that I may possess.

Washington state law requires that UW develop a policy for accommodation of student absences or significant hardship due to reasons of faith or conscience, or for organized religious activities. The UW's policy, including more information about how to request an accommodation, is available at Faculty Syllabus Guidelines and Resources. Accommodations must be requested within the first two weeks of this course using the Religious Accommodations Request form available at https://registrar.washington.edu/students/religious-accommodations-request/

I encourage all students having difficulty, whatever the reason, to consult privately with me at any time.

Academic Conduct

The standard iSchool and UW academic policies that apply to all of our courses, apply here as well.

Diverse backgrounds, embodiments, and experiences are essential to the critical thinking endeavor at the heart of higher education. We expect you to be respectful of the many social and cultural differences among us, which may include, but are not limited to: age, cultural background, disability, ethnicity, family status, gender identity and presentation, citizenship and immigration status, national origin, race, religious and political beliefs, sex, sexual orientation, socioeconomic status, and veteran status. Please talk with me right away if you experience disrespect in this class—from any source (including teaching staff)—and I will actively work to address it.

Collaboration

The iSchool encourages and supports collaboration. The goal of this course is to learn the material—to be able to create new web-based information systems on your own. You are encouraged to use any available resources, including your classmates, to learn these skills. You are welcome to discuss exercises and problems with others, to work through challenges in pairs, to seek help if you get stuck, and to share guidance and expertise if requested. Help each other to become experts!

But "collaboration" does not mean just copying other people's code and trying to pass it off as your own. You can discuss problems and even work through solutions together, but the final product (the code you create and submit) should come from your own brain and your own hands.

The point of assignments is for you to learn to complete them. This includes the entire process of getting the solution—including the false starts, bugs, misconceptions, and mistakes—because the learning occurs in the doing. Completely apart from the ethical issues, copying a solution without understanding deprives you of the whole point of the assignment, and frankly is a waste of your time.

A good rule of thumb: When working on an individual assignment, no other student's code should ever be on your computer. Not ever shown on your screen (including as an image or screenshot), not saved to a file on your harddrive, not found in an email under your account, etc.. You can verbally talk through the code to write, but make sure you understand what and why your implementation works—and if you're not sure, ask!

  • DO: Ask people (especially the professor!) for help finding and solving bugs.
  • DO NOT: Let someone else type code for you.
  • DO: Talk through problems sets in pairs.
  • DO NOT: "Split up" problem sets so you only do half the work.
  • DO: Give credit when you get help or advice from someone.
  • DO NOT: Copy or adapt an assignment from a previous quarter.
  • DO: Feel free to research techniques that aren't covered in class
  • DO NOT: Copy-and-paste code from the internet or from code generators (especially if you don't understand its syntax!)
  • DO NOT: Make your problem set repositories public so that others can see them.

Code Reuse

Although professional web developers often reuse code they find on the web, they also take the time to understand what that code is doing, customize it to their specific context, and cite the source so that they can find it again later. They "make it their own". If you want to use a snippet of code you find on the web, you MUST do the following:

  1. Include a reference to where you found the code (a URL in a comment is fine). Including more than a line or two of un-cited code, or otherwise failing to give appropriate credit, is a form of plagiarism and so is considered cheating..
  2. Take the time to understand how and why the code works (otherwise you aren't actually learning anything!). Adding detailed comments explaining what the code does in your own words is a good way to demonstrate that you actually understand it.
  3. Make the code your own; do not just copy and paste it directly into your project. Choose exactly what pieces of a sample are necessary for your work (you usually don't need everything). Adjust variable and function names so they are appropriate for your situation. Ensure that the code matches the style and usage guidelines required for the class.

This course is about learning web development; you won't learn anything from just copying other people's code—even if the final product "works". It's fine to learn from other sources, just be honest about it.

It is not acceptable to implement your projects using any pre-defined templates (e.g., in which you just fill in the content), following a tutorial verbatim, or using other similar "pre-built" work. The projects you submit should be entirely implemented by you for this course. You are welcome to get design ideas from other sources or look up how to achieve specific effects, but the entire page or app needs to be coded by you, not by someone or something else. If you include more than 1 line of code from another source, you must include an appropriate citation. You will not receive credit for code you do not write yourself.

Generative AI / ChatGPT Usage

Code generating AI tools such as ChatGPT, GitHub Copilot, and similar are undeniably useful for doing programming, and are being adopted and integrated into all sorts of professional development practices (though the practical effectiveness and reliability of such tools is an open question). In Informatics we want to be able to embrace new information systems and learn to use them effectively and ethically.

However, relying too heavily on AI tools can limit your own skill development—which is necessary to assess the quality of code generated by AI, to understand how to integrate it into the software systems you're developing, and to be able to work in contexts where such AI tools may not be available. You need to learn the foundations in order to effectively use these tools. The goal of this course is for you to learn how to develop and write the code needed for client side web applications—which is different than learning how to generate such applications with an AI tool. Generating code with AI doesn't help you learn it (see e.g., this experiment).

With that in mind, in this course we ask you to follow the below ethical guidelines when using generative AI tools such as ChatGPT, CoPilot, or similar:

  • For problem sets, keep AI tool usage to an absolute minimum (i.e., do not use). Problem sets are for you to practice learning implementation steps and patterns yourself—typing it out on your own is important!

    • Using AI tools to help fix final bugs after you have attempted them on your own is acceptable.
    • Putting the instructions into a code generator and turning in the result—even with your own adjustments/fixes—is not acceptable.
  • You may use AI tools to support you in completing the project. The project still needs to be implemented by you and your team (we're not assessing the AI), but you can use it to help you out.

    • Having AI tools produce boilerplate code templates or scaffolding (which you modify) is acceptable.
    • Using AI tools to help find and solve bugs is acceptable.
    • Having AI tools generate entire features or projects is not acceptable
  • If you use AI tools, you must still abide by the formatting, structure, and content requirements for the project. That means using the approaches, techniques, and coding style that we are teaching (and you're supposed to be learning!). You will need to critically assess any AI generated code and actively modify it to meet the expectations of this course.

  • If you use any AI tools, you must cite/acknowledge that support in two ways:

    1. Include a brief comment in your code or in the git commit message for that work acknowledging that code was generated by an AI tool. This doesn't need to be highly detailed; it is intended to help you be mindful of your usage at the time it happens and to provide a "paper trail" if anything goes amiss.
    2. With each project deliverable you will be asked to provide a short statement about your use of AI tools overall. This is to provide more details, and to help us understand how students use the tools to guide future policies!

    These acknowledgements are not intended to be burdensome; their purpose is to help keep you cognizant of your own usage (and reflect on "is this still my work?" "Am I actually learning the material so that I could do this on my own?").

Additionally, please note that using such tools may imply donating your work and data to the companies that deploy and manage those tools. I encourage you to be considerate of your own privacy when using such tools. Please take reasonable steps to avoid making assignments easier for future iterations of the course (e.g., once the tool provides a correct answer, don't give it positive feedback).

In short: you may use generative AI systems in this class, but you should do so ethically and critically. Don't use AI on problem sets; you can use it for projects, but cite/acknowledge your usage.

Some text has been adapted from Professor Jennifer Mankoff.

Academic Honesty

The consequences of academic dishonesty are not worth the risks. The simple rule is: do not claim anyone else's work, code, words, or ideas as your own. If you're in doubt, come talk to me in advance.

If we determine that you violated the collaboration policy and plagiarized code, you will get an automatic zero on the assignment, and we will file an academic misconduct report with the Associate Dean of Academics. Note that both students will be considered to be at fault in the case of unauthorized code sharing.

If you're having problems in the course, come and speak with me; never take the shortcut of copying someone else's work. It isn't worth it.

Course Summary:

Date Details Due