Project: Topic Proposal

The project will be completed in groups of up to 4 people. While you can work individually, it's strongly encouraged to work with others to practice collaboration and to keep the workload manageable. You can pick your own group, and we will help you find teammates as well.

The first step in completing your Project is for your group to chose what kind of web application you would like to implement.

Your app will be an interactive website of your own choosing and design, which users are able to modify and interact with some data or information. You can build a sophisticated web application of your own design, or create a new web platform for a real client such as a student organization, an artist, a non-profit, or a local business.

To see some previous examples of projects, check out this video of past projects Links to an external site..

To be clear: you will be creating an interactive app, not just a web page with static (unchanging content). The goal of the project is to implement a dynamic, interactive system—not just create a web page with information/content on it. You shouldn't be spending time gathering or writing content for the page, rather instead you'll spend time designing/implementing its appearance and interactions. So focus more on what users will do, rather than what they will "see".

In the end, your completed project will need to support at least "two and a half" significant interactive features (the "half" can be a smaller feature). By "feature", we mean a specific set of user interactions that are used to achieve some goal (similar to a use case Links to an external site.). For example, a recipe app might allow the user to (1, small) search and filter for specific recipes, (2) organize (and reorganize!) those recipes into a "recipe book" for later use, and (3) upload new recipes the site. A chat application might allow the user to (1) send messages to other people and (2, small) organize messages into different "channels" or groups, and (3) create groups of people/friends who can receive messages.

• Note that all of these examples involve complex interactions. A feature is not just a single button to press. "Viewing" content isn't a feature, nor is navigating to see different content. An interactive feature involves the user providing input in order to change some of the data displayed in the app.
• A "quiz" is often just a small feature (it's just a filter form); think about what users will do other than answering questions.
• "Liking" or "favoriting" something only counts as a (small) feature if there is some purpose to flagging or saving that item.
• Any "comments" or "reviews" need to be more than just generic text boxes—they need to be meaningful to the app's functionality!

The most common types of features that student apps include are data organization and data collection features. A data organization feature lets users take take existing data and re-organize it to their own purposes. For example, an app feature could let users create a "binge-watching" list by selecting shows/movies from a larger list (which they can then save or print out). A data collection feature lets users provide their own data to the app. For example, a feature could let users upload pictures of rare birds that they see to share with others. But you are welcome to include any kinds of (client-side) features that you want—this is your project!

• Thinking about your project as being a "data-driven application" tends to lead to more successful projects. Consider what kind of data your app will be managing, and how users will produce, modify, and interact with that data. Note that this should more likely be something like "user data" rather than a 201-style data set—Twitter's "data" is the tweets people post.

  • To be clear: you do not need to find or use a "data set"; the data that your app will show will almost certainly be user generated. You're welcome to use an external data set if you wish, but it is not required.

  • It's very difficult and outside of the scope of the course to handle remote authentication, so APIs that require it (like Spotify) should not be used.

• Your app will also support data persistence—some data or input that the user provides will need to be available on subsequent page loads or when accessed from another computer. In short: your app will use a "database" of a sort. Your app could persist how data has been organized (e.g., the list of selected movies/shows), data that is contributed by the entire user-base (a "crowdsourced" data set, such as pictures of birds), or just user-specific data (preferences, personal notes, etc). The data persistence needs to be meaningfully integrated, so think about what kinds of features will involve storing data to a database.

  • Integrating the database will be the last thing we learn to do in this course—we will get there, but it will feel like a hole in your project for a while.

• Your features will need to be integrated with each other—think about what makes the app work holistically together. You can't have an app that is three totally independent pieces of functionality that just happen to live at the same location.

• Your application needs to be a complete, usable system. You cannot only make the "client-side" portion of your app and leave the important functionality to future work. For example: you cannot make a store front for a "hypothetical" e-business if there's no actual products to deliver. Every form and interaction needs to do something meaningful.

  • It is not possible to send an email from a client-side app, nor to securely process credit-card information. Do not consider those as potential features.

• Importantly, we'll need to be able to see the full range of features of your app within a single usage section so that we can grade it. Anything that happens on a timescale of days (e.g., "log something else tomorrow") or weeks needs to also provide some way for us to test it.

For more details about the requirements of your project, see the full Project assignment description.

As long as you meet the requirements, you are welcome to create a project involving any information problem you wish.

• You'll be spending a lot of time on this, so think about what gets you excited! What are your passions, hobbies, goals? What kinds of web app might support that? Talk to your classmates about their ideas as well.

• I encourage you to think about what kind of information web app would make the world a better place. Supporting social justice is a great way to get your professor excited about your project (which is always good).

• Don't worry about the "business value" of your app. This is an educational exercise. That said, your app still needs to provide some "real" functionality to someone—it cannot just be "toy" code with nothing holding it together. Think about what makes the app worth your time to develop. What will make a good "portfolio piece" to show off to others?

  • Your project doesn't doesn't need to be "practical" (it's just for practice building), but we will be asking you to think about the practicalities of your system when coming up with your project. That's what we do in Informatics!

Cautioned project ideas (e.g., projects that have not worked well in the past, but you can try if you want) include:

• Budget management apps. These tend to be particularly challenging to effectively present and interact with.
• Roommate management/cost-sharing apps. Students really struggle with figuring out how to design app usage around multiple people.
• Exercise routine apps. Being able to suggest or recommend what exercises to do is a lot more complex than students think!

Forbidden project ideas (which are not allowed this quarter) include:

• No "movie apps". There are too many examples of these online to borrow from; do something on your own!

• No "recipe apps". These tend to just duplicate existing data and often fail to meet project requirements.

• Generic "chat" or forums" not be accepted as a feature on its own. We'll build a basic chat app in lecture as a demo (see an example of the chat demo Links to an external site.); your project needs to be something else or something beyond that. If you want your app to include some kind of social communication as its primary purpose (e.g., you're making a Slack clone), then you need to support social interactions by providing some kind of moderation or other ways to avoid spam/trolling/harassment—just letting people post messages isn't sufficient for a feature.

Feel free to post about any project ideas on Ed; this can help you find people to work with as well as collaboratively brainstorm about topics!

The Proposal

In order to ensure that you've considered and thought about a topic (and to practice your HTML skills!), you will create a small web page describing the web app you intend to create. This step is intended to get you thinking about your project early, while it's easy to change ideas. You can locate any data or resources that you need now before you get too deep into implementation. You can change topics later if you wish, though doing so might increase the amount of time/work needed to make a satisfactory project. Pick an idea you will be happy with now!

You will be completing this proposal as a group. Note that each group member will need to contribute code to this web page to demonstrate your ability collaborate over git.

Getting Setup

You will need to use GitHub Classroom to create a private code repository for your project's source code. One member of the group will need to create the repo by visiting the following link:

https://classroom.github.com/a/_hpcD-G3 Links to an external site.

You will need to accept this assignment to create your code repo. This repo will have the name info340-wi25a/project-yourusername (replacing yourusername with your GitHub user name), and you can view it online at https://github.com/info340-wi25a/project-yourusername (replacing yourusername with your GitHub user name). You are welcome to rename this repo to something that better fits your group and project if you wish.

Do not fork this repository!

The person who accepted the assignment will then need to add their partner(s) as a collaborator Links to an external site.. This will allow you both to be able to push to the repository and collaborate on the code. Be sure to give your partner admin access to the repo!

All group members will need to clone the repo to their local machines so you can create and edit the source files for your page.

• There is no starter web code (you need to make your own .html and .css files).

Working as a Group

You will need to work as a group to both write and code your proposal.

All group members have to contribute to all aspects of the project. (This project is how you demonstrate that you have learned the course material, and we need to see everyone demonstrate that). This means that we need to see at least one git commit (that substantively modifies the code) for each member of the group. This is to demonstrate that each person is able to contribute to the repository and had some input into the proposal.

Of course, making sure each person commits can seem tricky and a little silly because there isn't a lot of "work" in the proposal. So some potential ways to organize this:

• Have one person commit the code for the problem/data description, and one person commit the app description. The whole group must collaborate on writing those descriptions (you can coordinate via a Google Doc or something), but you can split up the actual "coding" work.

• Normally it's not acceptable to have one person implement the content and another implement the appearance, but for the purposes of this proposal only it's fine if one person wants to write/commit the HTML and one person wants to write/commit the CSS. But I strongly encourage all group members to work on both for practice!

We will be looking for at least 1 commit for each person, and those commits each need to add something meaningful to the proposal document (not just "formatting" or fixing a typo). A proposal will not be considered "satisfactory" if not everyone contributed to it.

Proposal Requirements

Your proposal will need to provide the following information:

Problem/Data Domain

Your proposal will contain a short description of the topic domain and the information/data you'll be presenting, explaining the problem to someone who doesn't know anything about it! Your description should include enough information to:

1. Provide an overview of the general topic or question of interest (e.g., "what is meant by 'homelessness' and why is it a particular problem in Seattle?").
2. Identify an information technology problem in that space (e.g., "what information problems related to homelessness are unaddressed?").
3. Identify at least 1 previous or existing attempt to solve this problem (e.g., "what other web apps attempt to address homelessness? What has already been tried?")

In short: let us know what you are interested in, and identify a problem that you think needs solving (and that might be amenable to a technological intervention) while also considering what has come before.

• While social injustices are the problems most worth attacking, your project could also address smaller, or more personal "problems". What is something that makes your life worse, and that you think that a web app might be able to help with?

This description should be 1-2 paragraphs (~150-250 words) in length. Your overview should explain "what" the problem is and "why" it needs addressing (including why any currently existing apps are insufficient). You will need to include references to other resources to help clarify your explanation of this problem.

App Description

Be sure and review the overall project requirements for more details about the scope and requirements for your project.

Your proposal will also contain a description of the web app that you will create to help address your chosen problem (a proposed "solution"). Think about what kind of a web app would help with this problem, and how people would use that app to make their lives better in some way. What is the "use case" or "user story" Links to an external site. for the app?

• Remember that this app will be interactive—it will need to contain buttons, forms, etc that let the user provide some kind of input and modify how data is presented to them. Thus your app will need to do more than just be something for the user to read; it needs to give the user something to do.

Your app should also be described in 2-3 paragraphs. In particular, you should make sure to address:

1. Who are the users of the application? That is, who will be accessing the website? What impacts might this app have on minority groups?
2. What will the users do with the web app? What kind of interactive features are you expecting to provide? Remember that you app will need to include at least "two and a half" significant features; be sure to explicitly identify and explain what all of them are! Remember:
   • Remember that "viewing" information or navigating ("going to") to something isn't a feature!
3. What kind of information will the users be viewing? If intend to use data from an external source (a csv file or an API), include a link and citation to that data.
   • If you insist on using an API, confirm that you'll be able to access it from a client-side app by testing it at https://joelwross.github.io/cors-test/ Links to an external site.. If you can't get data back from this testing site, then it won't work with your project.
4. How will using this app help to solve your chosen problem? That is, how is it a solution to the problem you described?
   • Remember the app doesn't need to have "business value". But as Informatics students we care about the practical usage and impacts of systems, not just their implementation. Be sure to consider that in your proposal!

Web Page Requirements

You should present the above information (Problem Description and App Description) in the form of a basic web page implemented with HTML and CSS. Create a new proposal.html file in the root of your project repo. This web page should include the following content:

1. An appropriate page structure (including a <head> element with a <title>). The basic web page template Links to an external site. is a good place to start.

2. A <header> containing a title for your page as a top-level heading (<h1>).

3. Different <section> elements for each major part of your page (e.g., Problem Description, Proposed Application). Note that a functionality walkthrough would be appropriate as a "subsection" (e.g., a <section> within a <section>).

4. Use appropriate HTML elements to semantically organize the content. For example, you might describe the different interactions a user can perform using an unordered list.

5. Include hyperlinks to at least two (2) outside resources, references, or data sets related to your topic. These can be links to other applications in the same problem space. If you'll be using an existing data set, be sure to link to that!

6. You will need to include some CSS styling. Create a new css folder inside of your repo, and a new proposal.css file inside of that folder. The styling can be whatever you want (change the font, background, etc), but you should include at least two (2) rules that change at least three (3) different properties total.

   • Adding some spacing around the content is a great use of CSS.

Deployed Web Page

You will need to "publish" your proposal webpage to GitHub Pages by creating a gh-pages branch and merging the changes from your main branch into it. push these changes to GitHub, and you should be able to visit your page at

https://info340-wi25a.github.io/project-yourusername/proposal.html

You should publish your app to this URL for grading purposes (it lets us look at your site). However, if you later want to change the URL associated with the page, it is possible to either specify a custom domain Links to an external site., or otherwise change the repo name.

Tag Final Commit

Because you will be iterating on the course project and continuing this development across multiple deliverables, you will need to mark your final commit for this stage. This will allow you to easily get back to that point (e.g., if you decide to move in a different direction), and make sure that we are reviewing and grading the correct version of the code.

To mark this commit, you should add a tag Links to an external site. using git. A tag is a lightweight annotation for a commit—like a nickname for it. You can tag the current commit (which should be on the main branch) using the git tag command, giving it the name proposal:

git tag proposal

This will tag the last commit. You can check that this worked by running the git tag command with no arguments and see your tag listed.

You will also need to explicitly push your tag to GitHub:

git push --tags

You can see a list of all tags in the "Tags" section of your GitHub repo (linked from next to the branch selector). We will grade whichever commit has been tagged proposal. If you add further changes to your proposal, be sure to retag it (e.g., proposal.1, proposal.2 is fine) and push the updated tag!

Submitting the Proposal

To submit your project, do the following:

1. Confirm that the project proposal is complete and meets all the requirements. Please proofread your proposal so there are no glaring typos or errors. Think about the "user experience" of reading it!

   (Although not required, it's a good idea to also update the README.md file to describe your code repo).

2. add and commit the final version of your work, tag your commit, and push your code and tag to your GitHub repository (we will be grading the code at the proposal tag of the main branch). Also make sure you've pushed the final, "publishable" version of your work to the gh-pages branch.

3. Submit both (1) a link to your code repo and (2) a link to your published web site to Canvas using the button at the top of the page.

Grading Rubric

This proposal will be created as "satisfactory" or "not-satisfactory". A satisfactory proposal is one that provides all of the required information in a well-structured/written HTML file, and that has commits from all group members. If there are errors in your HTML code or commits are missing, you will need to address that before this can be considered satisfactory.

• You won't need to fix problems with or update the proposed idea at this stage though, but I encourage you to take feedback to heart as you start working on the rest of the project!

You may resubmit this proposal repeatedly (until the first draft is due) until it is satisfactory.