Write a html or css program for Q less

 I’m working on a html / css multi-part question and need support to help me learn.

In this semester project, you and your classmates form Project Teams and practice software engineering skills described in the textbook.

You can make anything, as long as it is hosted and publicly accessible on the internet, using HTML, CSS, and JavaScript standards. It doesn’t have to have a server-side component. It does not have to use specific client or server side technologies, but I recommend popular frameworks such as React and Vue on the client, Django, Flask, and Firebase on the server. You can host your projects anywhere, including Heroku, Firebase, or hundreds of other options.

Because the timeline for the project is so short, you will learn is how to organize your work and your teamwork to be productive. Keeping your project simple is essential to learning these skills.

As noted in Stage 1 and Stage 6 below, you’ll have the option of recommending a teammate be “fired” you do not believe fulfilled the duties of their role. If everyone on a team fires a person, and your instructors agree with the rationale, they will lose 80% points in the semester project. Be an engaged, communicative teammate.

PLEASE READ THE FOLLOWING INSTRUCTIONS COMPLETELY AND CAREFULLY

STAGE 1: 9/14 – 9/25 (SUNDAY), 11:59PM(CST). CREATE TEAMS, SELECT AND DESCRIBE A DESIGN PROBLEM (5 POINTS)

Teams and member roles were assigned according to your responses on the self-introduction discussion. Every team must have one PM, one Designer, and one or two Developers. If your team wants to swap two or more members’ roles, communicate this to your instructor right now.

Note, at the end of this course in Stage 6, you’ll have the option of “firing” teammates. You won’t be able to fire them in the middle of the semester, but if at the end you believe your teammate did not fulfill the obligations of their role, you will be able to recommend they be “fired.” If all of your teammates in an organization “fire” a person, the fired person will lose 80% of points in the semester project. Therefore, remember that at all times, you should fulfill your duties.

Once the team is formed, your team’s designer should lead a conversation about: what problem do you want to solve.

Remember that problems are not solutions—they are a narrative about some way the world functions that has unwanted consequences. For example, climate change is a problem, solar energy is a solution; diabetes is a problem, chronic disease management in primary health care is a solution. Solutions are what you make to change the causality of a problem so that its consequences no longer occur.

Discuss, debate, and deliberate to arrive at a problem you’re all excited about solving this semester.

Because we’ll have limited time in this class to build and deploy a software solution, here are a few constraints on the problem you choose:

• It should be a small problem, not requiring a massive, complex solution.
• It should be something you can build with web standards (HTML, CSS, and JavaScript).
• It does not have to be novel. It can be a major extension or adaptation of an existing software solution. You must fully document what your team’s contribution to make it significantly different from the existing software solution.

To represent your problem, your Designer should write a description of your problem, which details the scope of the problem, its consequences in the world, the things that cause the problem, and why existing solutions don’t resolve the problem.

Note, as state above, your problem should not refer to a solution; “a solution that does X does not exist” is not a statement of a problem. That’s like motivating the need for Instagram by saying “The world is broken because it doesn’t have Instagram.” The problem motivating Instagram would be something like, “People love sharing photos, but all existing solutions for sharing them involve clumsy, impersonal file sharing.”

STAGE 1 SUBMISSION INSTRUCTIONS:

Team’s Designer posts a following information: team members’ names and their roles (1 point), a clear, concise, logically sound problem statement that defines the problem being solved (1 point), its consequences in the world (1 point), the things that cause the problem (1 point), and why existing solutions don’t resolve the problem (1 point). Problem statements that are unclear, verbose, logically flawed will lost the majority of the points.

Team Meetings: This project is TEAM based. Therefore any meeting where the team meets to discuss the project must be recorded. Since this is an online course, then the Project Manager needs to schedule online meetings.

The University provides student Zoom accounts ( https://servicecenter.twu.edu/TDClient/1956/Portal/KB/ArticleDet?ID=111640Links to an external site. ) and Zoom supports 40 minutes in each recorded session to be saved on local computer. These team meetings need to be recorded and uploaded to PM’s TWU Google drive. Submit the link to the video along with the written description/summary of the meetings the designer completes above.

STAGE 2: 9/26 – 10/2 (SUNDAY), 11:59PM (CST), DESIGN A SOLUTION TO THE PROBLEM DEFINED IN STAGE1

Team’s DESIGNERS needs to lead and document the discussion while you and your teammate’s brainstorm. The solution should have the following constraints:

• Your design must be interactive. It cannot be static content; it must accept and respond to some form of user input.
• Your design should be something your team can implement in 4 weeks of part-time effort. Your solution should be a minimally viable product (Links to an external site.), which provides value to your target audience, but doesn’t necessarily achieve all possible functionality. That means real functionality and real content (if appropriate), but not all the functionality you can imagine or all of the content you can imagine. Think of YouTube, just video playing, basic video uploading, like and dislike buttons. That’s enough to provide the smallest possible value that YouTube can provide (and probably pretty close to what they initially launched).
• Your solution must be build for the web. At the end of the semester, you’ll deploy your solution, and sharing should only require visiting a single link on a website. No mobile apps allowed.
• On the front end, your solution must use HTML, CSS, JavaScript, and/or React.
• You also need to have a hosting location for the project. You can host your projects anywhere, including Heroku, Firebase, or hundreds of other options. This needs to be completed and proof the hosting has been obtained needs to be documented (screen shot of the web interface, email showing you have signed up, etc.) and uploaded on this step.

Team’s DESIGNERS writes a brief design specification that details the interaction design for your solution. A design specification details what the software will do in terms of functionality, but not how. Your specification is good if someone could read it and understand the user experience of your application and rationale for your design choices. Everything else about how it might be implemented is work for later. Any meetings completed must have the recordings uploaded, link to the video submitted with the written description.

Your can use Appendix A in the textbook as a template for your design specification and it must include the following sections:

Problem. This is a revised version of the problem statement from Stage 1.

Solution. This section must detail every design decision necessary for engineering your solution, including every screen, every error, every algorithmic functionality, and every detail about the textual and visual content of your design. If your solution is software, a software engineer should be able to read your specification and build your solution without asking you any questions. Embed mock-ups of screens throughout the text of this section to visually specify your design. Because of the short timeline, it’s okay if these are hand-sketched.

Note that you only have one week to do this. That means that your design really can’t be that complicated from an interactive perspective. Keep your solution simple.

Example Specification

Below is a very simple example specification that conveys the structure that I’m looking for, but not the level detail. (I expect your solutions to be more complex and include more detail about every possible state the user might enter). Sketched mock-ups are acceptable.

Problem

Many children in the world still memorize multiplication tables for numbers 0-10. This memorization helps them thrive in a world where small multiples are abundant in everyday tasks. However, paper-based forms of memorization are slow to grade, slow to practice, and thus often quite boring. This takes valuable class time away from elementary school students, while also creating the impression that arithmetic is slow and boring.

Solution

We envision a multiplication table game in which players receive a series of 1-digit multiplication problems, including digits 0 through 10 (0 x 0 through 10 x 10). Each successive problem is based on past correct and incorrect answers. When a player correctly answers all possible pairings of digits three times in a row, the player wins. Otherwise, the game continues to present problems that they have yet to answer three times correctly successively.

The interface is simple. There is one main screen for solving multiplication problems: a multiplication problem, and a keypad for entering the answer’s digits with backspace and check-mark keys.

Players tap the digits to enter a number up to three digits long. They can tap the backspace key to delete a number, all the way back to an empty answer. They can tap the check-mark to enter the number. When backspace is pressed on an empty number, nothing happens. When three digits have been entered, the keypad buttons become disabled by turning gray.

When a player submits a number by tapping the check-mark, the game shows a correct (Yes that’s correct) or incorrect (Nope wrong answer) screen for 2 seconds before displaying the next problem.

After the answer screen , the game selects a new problem by finding a random pairing of digits 0-10 that the player has not yet successively answered 3 times correctly. The order of the digits does matter (7 x 3 is different from 3 x 7).

Once the player has won the game, they see the game-over screen, which also provides the option of resetting the play history to start the game over.

A mock-up that says “You’ve mastered multiplication” with a button that says “master it again”

The game contains no sound, no keyboard support. The game’s interface layout is responsive to screen size, but uses the same interface layout for all platforms.

STAGE 2 SUBMISSION INSTRUCTIONS:

Team’s Designer submits design specification with clearly defined Problem (1 point) and Solution (4 points), -0.5 point for every interactive detail that is critical to solving the problem that is not specified. It’s okay if visual details are not specified, since those can be changed easily. I want to see the core functionality of your application fully specified. Along with the recordings from the meetings.

STAGE 3: 10/3 – 10/9 (SUNDAY), 11:59PM (CST), REQUIREMENTS ENGINEERING.

Stage 2 gives you a detailed specification of your design, detailing every interactive detail (and likely many of the visual details) of your solution to the problem you selected. Your next task is to translate your design into a set of unambiguous requirements, each expressed in natural language.

Writing down requirements is useful for at least three reasons:

• The very act of articulating them will help you notice ambiguous or unstated assumptions about your design.
• Your list of requirements can act as an implementation to do list
• Your list of requirements will directly inform your testing plan

Your list of requirements will be the basis of your Stage 6 grade, which is assessed on the proportion of requirements that you’ve met. (Though this assignment isn’t creating the final list you’ll be held to; this is just a first draft. You’ll have many chances to revise them before you begin your final sprint).

Each requirement should be a single, precise, verifiable fact that must be true about your implementation. Here’s an example from our arithmetic practice example from Stage 2 that violates all of these principles:

The system should count up all the answers and display them.

The statement above includes two requirements (counting and displaying), it’s vague about what it means by “counting the answers” and “displaying” them, and because it’s vague, it’s not verifiable. Here’s a better version of the counting requirement:

The system should compute the proportion of correct answers as the total number of correctly answered questions divided by the total number of questions asked.

That requirement is singular, precise, and verifiable.

Each of your projects has a different number of requirements, so I can’t say how long your list needs to be. If I had to guess, I’d say you’ll have anywhere from dozens to hundreds. Sound daunting? Here’s your motivation: another way to think about requirements is as a complete to-do list for your implementation and testing work. The more complete, precise, non-conflicting, and verifiable your requirements, the easier it will be to get started, plan your effort, and ensure you can get the work done on time. All of those things are necessary for great engineering (and for a good grade in this class).

As a team, you need to create a requirements document. To make the requirements easier to navigate and understand, organize your requirements into sections, grouping sets of related requirements. Each section should be linked to a part of your design specification, when appropriate, so it’s easier to understand what the requirements concerned. Each requirement should be precise, verifiable, and non-conflicting. The set of requirements overall should be complete with respect to your design specification.

To translate your design into requirements, review your design specification. Go through each part of it, identifying places where your specification states that something must be possible and convert all of those into requirements. You may also find that your design specification doesn’t state that something is required, but you know it is required. Write these down as requirements as well.

Team’s DEVELOPER(S) with your PM and Designer, read through your design specification draft and extract as many requirements as you can.

STAGE 3 SUBMISSION INSTRUCTIONS:

Your team will submit a requirements document using the template in textbook’s Appendix B. (We’ll use this as a snapshot of your requirements for future Stages). Along with the links to recordings of the teams meetings.

Your requirements will be graded on a 5 point scale, with the following possible deductions:

• Precision. Every requirement that could have been phrased unambiguously but was not loses 0.2 points. How precise? It should only one one interpretation.
• Verifiability. Every requirement that cannot be verified loses 0.2 points. How verifiable? If we can’t think of a way to verify it, than it’s not verifiable. (That means you should be able to think of a way to verify it).
• Conflicts. Every pair of conflicting requirements loses 0.2 points.
• Completeness. Every requirement the reader can think of that was not included loses 0.2 points. Think of every edge case!

Note that in this grading scale, it’s really easy to get a zero if you don’t think really carefully about every detail. Scour your design specification for every little detail, generating as many requirements as you can, and then generate even more. Remember that the more detailed you can get, the better your engineering to do list for later! Save yourself the future effort of generating these lists by doing a thorough job now, which will help you plan.

Also, if you’re wondering how much detail to include in requirements (independent of precision and variability), focus on the details you really think matter for your design, and only include those. For example, if you’re writing a requirement about an error message, and you’re trying to decide whether to include the actual error message in the requirement, ask yourself: how much does the actual message matter for the qualities you’re targeting? Maybe it really matters, and so you want to be sure to it’s implemented exactly as specified. Maybe all that matters is that there is a message, but not what the message is. Use your discretion to decide what must be met, and focus on those details.

STAGE 4: 10/10– 10/23 (SUNDAY), 11:59PM (CST) ARCHITECTURE AND PLAN.

ARCHITECTURE

In Stage 3, you detailed what your software is going to do from a design perspective. All of those choices you made are about the problem you are solving with the software; those details concern the world. In this Stage, you’re going to specify how you’re going to achieve those requirements, defining your software’s architecture.

To simplify this, we’re going to use the architectural concepts relevant to the Model-View-Controller and Client-Server architectures:

• Client-Server architectures involve two kinds of components—clients and servers—exchanging messages with each other. On the internet, these messages are http requests.
• Model-View-Controller architectures involve a model to persist and retrieve data, views to display data and elicit it from users, and a controller to implement the application’s logic for passing data back and forth between the model and views, as well as manipulating data.
• In web applications, models, views, and controllers can live on either the client, the server, or both. For example, when you use a database, the model is on the server side. But your application might only store data on the client side if it only needs to persist data on the device accessing the site. It might also persist all data on the server, but then send all of the data on the client, so there are actually models on both the client and the server. The same is true of views: some applications render all HTML/CSS/JavaScript views on the client side, while others render all HTML and CSS on the server.

Your job in this Stage is to decide how you’re going to organize your clients, servers, models, views, and controllers. To do this, your team is going to create two things.

1. A DESCRIPTION OF ALL COMPONENTS

First, write a Word file that specifies all of the models, controllers, and views in your application. For each, describe:

1. What the component’s responsibility is
2. Whether the component resides on the client, the server, or both
3. What other components the component needs to communicate with and precisely what they will communicate.

Here’s an example of a description of a model component for our arithmetic game example from previous Stages:

LearningModel

• This component is a model that stores all of the questions the game has asked the player and all of the answers the player has given to the game.
• The model resides only on the client.
• Only the GameController communicates with the model. It communicates the following:
  • The GameController can ask the LearningModel to store a question/answer pair
  • The GameController can ask the LearningModel for the proportion of correct answers
  • The GameController can ask the LearningModel for all of the stored question/answer pairs.

The architecture of the game would therefore also contain descriptions of the GameController, but also several views components that implement the user interface of the game, such as the view that displays the question, the view that displays the answer, the start screen view, etc.

How many components should you have? There is no right number, but consider a few extremes. If you only had one monolithic component, where there was no encapsulation between any of the data and functionality, you’d have a big “ball of mud” architecture that’s going to be hard to understand, and therefore hard to evolve and repair. If you had a thousand little components for every tiny bit of functionality, most of your code would be communicating between components. You want something in the middle, where there’s enough division of responsibilities that everyone on your team can understand how the functionality is organized, but not so many that you’re writing a lot of extra code just to make things talk to each other.

Note that you don’t have to specify components you aren’t building. For example, if you choose to use something like Firebase, you don’t need to specify Firebase. But some of your components may need to mention that they’re going to communicate with cloud storage to store and retrieve data. Additionally, you’ll likely have a client-side model of data in the cloud storage, so your client side components can access the data.

2. STUBS FOR ALL COMPONENTS

Once you have all of your components described, create stubs to represent all of these components and their functionality as source files. A stub is a partial implementation of something in source code, intended to help you architect the larger pieces of an implementation without fully implementing them.

For example, here is a stub of a function that takes an age in years and returns an array of strings describing civil rights movements that someone likely experienced in their life:

function getCivilRightsExperiences(age) {

// TODO Replace with actual algorithm

return ["Voting rights act of 1965"];

}

Notice how the stub specifies the inputs and outputs, but nothing about how they’re computed? It’s just a stand-in for functionality you’ll eventually write.

Since you’re using HTML, CSS, JavaScript, and/or React, there are a few clear implications for the kind of stubs you’ll create:

• All of your views will either be React components or some combination of HTML, CSS, and JavaScript. When you make each component, you’ll have to decide how you’ll be implementing them.
• Your model will either be some form of JavaScript on the client side or any arbitrary combination of server-side scripting language and/or a database.
• Your controller will either be JavaScript, a React component, or a server-side script, depending on where you decide to implement your application logic.

None of these components need to have functionality, but they do have to have names, source files, and all of the function headers, with arguments, return values, preconditions, and post-conditions, to specify the requests that the component can receive from other components. For example, the LearningModelmodel above should have functions defined for the three functions the GameController can call on the MasteryModel.

While you’re producing a document, the real goal of architecture is to make sure everyone on your team has a consistent, detailed understanding of the architecture. If they don’t, you’ll end up with a ball of mud. To test this, quiz each other on the architecture you have planned: can each of you explain it in detail? If not, keep explaining it to each other until you have the same understanding in your heads and in your document.

Developers Your goal is to complete as much of the architecture as you can in the discussion.

STAGE 4 ARCHITECTURE SUBMISSION INSTRUCTIONS:

Developer(s) – Submit a Word file containing your architecture description and source files that contain Stubs. We will review the architecture description and all of the source files to determine your grade. Along with links to recordings of the teams meetings.

The most important qualities of an architectural specification are clarity and consistency. If something is unclear or inconsistent, your collaboration will be constantly interrupted by the need to clarify and you’ll likely write code that you have to discard or change because of your misinterpretations. To incentivize you writing a clear, consistent document, for every unclear or inconsistent detail include, your team will lose 0.2 points. We will read both your document and your code for clarity and consistency.

PLANNING

Now that you’ve translated your design into requirements, and your requirements into an architecture, it’s time to plan how you’re going to work together to build your application.

Project Manager’s, create a Word file containing the following questions for the team to answer:

1. How will you coordinate your work?
   • Who will coordinate the work?
   • What will their project management practices be?
   • Will you have meetings? How frequently? Who plans their agendas?
2. What tools will you use to communicate?
   • For each, articulate the alternatives and why that is the best choice.
3. Who will own component in your architecture?
   • Owning them means being responsible for writing them and making sure they are functional and correct.
   • For each component, list the one person who is in charge of getting it done.
4. What is your timeline?
   • Include a list of milestones you’ll reach and deadlines for each.
5. How will you verify that you’ve met your requirements?
   • For each requirement in your requirements document, detail how you will verify it, and if you won’t verify it, justify why you won’t. This is called an acceptance testing planLinks to an external site.
     • If you propose to write a tests, what exact tests will you conduct and what will count as each test passing?
     • If you propose to conduct reviews or inspections, how will you analyze the code?
     • If you write a proof, what property will you prove?
     • If you conduct a review or inspection, what aspects of the code will you inspect to verify the requirement is met?
   • For all of the requirements, how will your verification be integrated into your process? Will you run automated tests after every build? Before every commit? When will you conduct inspections and who will be involved?

For each answer you provide, provide a written justification that explains the rationale behind your decisions, given what you know about what you need to build. I want to incentivize you to think deeply about each of these choices, to make sure your process decision actually makes sense.

To make a good plan, brainstorm disasters that might happen and test your plan against them. Illness, injury, API limitations, difficult to fix bugs: how resilient is your plan to all of these crises?

STAGE 4 PLANNING SUBMISSION INSTRUCTIONS:

Submit the Word file (your plan) in Canvas. Along with links to recordings of the teams meetings.

A good process is consistent with reality. You’ll get 5 points if you 1) answer all of the questions above and 2) the answers you provide are account for the reality of your schedules, availability, and time. For every part of your process that seems either unnecessary, vague, or infeasible, you will lose 0.2 points. To make sure that your proposed process doesn’t have these elements, be explicit not just about who is doing what, but what exactly they are doing and whythey are the right choice and why they have sufficient time, expertise, and resources to do it. Being explicit will help us assess how rational your decisions are, but more importantly, it will help you be more rational about your decisions.

STAGE 5: 10/24 – 11/22 (TUESDAY), 11:59PM (CST): RELEASE

In about four weeks, you’re going to launch your 1.0 product. Excited? Daunted? I hope both! If you’ve done a good job preparing for your implementation phase, there are several things that should make your process smooth and uneventful:

• You should know what components you need to build and who is building them.
• You should know how you’re going to verify that your product meets its requirements.
• You should know how you’re going to coordinate and communicate over the next few weeks.
• You should know what technologies, APIs, platforms, and languages you’re going to use.
• You should know how to build your project.
• You should know how you’re going to test your project.

If each of you is putting a solid 6 hours per week of implementation time, you should have plenty of time to reach this deadline.

Team’s Project Manager must lead the team in a discussion of the grading criteria. What implications does it have for your work that you haven’t already accounted for?

Next, review your plan to make sure everyone agrees on it:

• Who owns what?
• What are your milestones?
• How will you communicate and coordinate your work?
• How will you use the class time (3 hours) and study time (additional 6 hours) over the next four weeks? and you can check in with the instructor if you have questions about the work or grading criteria.

You should have answers to all of these in the documentation you wrote for your previous Stages. Review them and make sure everyone has the same understanding of their responsibilities.

STAGE 5 SUBMISSION INSTRUCTIONS:

Your team’s Project Manager submit three things for credit:

1. You must post the URL to the live site, using Team # as the title of your post.
2. You must submit your annotated requirements document in Canvas, as described below.
3. Links to Recordings of the teams meetings.

A successful launch gets 15 points. To determine a “successful” launch, we’ll consider two factors:

• The proportion of requirements you met.
• How well you correctly implemented your planned requirements.

To evaluate how many of your planned requirements you met, you’ll annotate all of the requirements in your requirements document as either complete or incomplete.

If there are requirements you cannot meet because they turned out to be impossible for reasons out of your control, you can mark it as impossible and explain why. Your job is to persuade us there was no way to meet it. If you persuade us, you will not be marked down for impossible requirements.

If there are requirements you revised from when you first submitted them, you mark them as revised and explain why you had to revise them. Your job is to persuade us that it needed to be revised. These will be treated as complete, and be included in the total number of requirements. If you persuade us, you will not be marked down for revised requirements that are complete.

Your requirements should already be numbered; put the appropriate tag above immediately after the number, so we can easily count and classify your progress. We’ll count the proportion of your planned requirements that are complete and multiply it by 15, rounding to the nearest integer. We will verify each requirement tagged complete by attempting to use your application. If we can’t verify it, then we will not count it as complete.

Finally, a note on failed launches: if we can’t verify your completed requirements because we can’t launch your application, that is considered a major defect and you will lose 90% of the Stage 5 grade.

 

STAGE 6: 11/28 – 12/6 (TUESDAY), 11:59PM (CST): REFLECTION

Individually, write an around 1,000 word statement, writing a paragraph about each question:

• What worked well about your team’s process? Why?
• What did not work well about your team’s process? Why?
• What tasks and activities did you personally do well? Why do you think you excelled at them?
• What tasks and activities did you personally do poorly? Why do you think you struggled with them? What might might you do to improve in the future?
• Does anyone on your team deserve recognition as an MVP (Most Valuable Player) (optional)? The MVP should epitomize some combination of leadership, open-mindedness, honesty, resilience, resourcefulness, and persistence. Describe to examples of a time this teammate exhibited these qualities.
• Are there any teammates you would like to “fire” (optional)? (If everyone on a team fires the same person, they lose 80% of the Project grade). Justification for firing include major failures to fulfill the duties of their roles:
  • A project manager failing to manage the project.
  • A designer that didn’t design.
  • A developer that didn’t build.
  • Any teammate that minimally contributed to the team’s goals.
  • Any teammate that was severely unresponsive, uncommunicative, or unreliable.

STAGE 6 SUBMISSION INSTRUCTIONS

You’ll submit this report on Canvas as a Word file, individually.

Covering the topics above is enough for the full 5 points. If you don’t cover all of the criteria above, we’ll give partial credit proportional to what you cover. Because of the short timeline to write this reflection, your work should be clear enough to be understood.