University of New Hampshire, Department of Computer Science

Information Technology 502
, Intermediate Web Design

Spring 2020

Jump to navigation

Team Project

April 24 update: Special adaptations for the COVID-19 situation

As with the Individual Project, the current situation is going to necessitate some changes to the Team Project. And, as with that project, I have decided to place the requirements that have changed in this box. In short, everything not explicitly mentioned here at the top of the page will remain the same as it is described below in the original page.

First, I need to adjust the deadlines.

  • The Presentation is now due at 9:40 AM on Thursday, April 30 for all six teams. Since we are not tied to the class meetings, there is no particular reason for half the presentations to be on Tuesday and the other half on Thursday.
  • The implementation deadline is also 9:40 AM on Thursday, April 30. That gives everyone two more days to work on tying up the loose ends. Note that you signal the completion of your implementation by sending me an e-mail containing its URL.
  • The Final Report deadline has been moved to noon on Wednesday, May 6, to allow more time for you to review the presentation videos and implementations prior to casting your votes.

Obviously, submitting the Final Report in hard copy isn’t going to work very well this semester, so the Final Report should now be emailed to me as PDF attachment.

The only other things that need to change are the expectations for the Presentation. As with the Individual Project, my strategy is to leave things as flexible as possible, so that each team can pursue a solution that best suits their situation.

I plan to stick with the video model we used for the Individual Project, but it is going to be complicated by the fact that you cannot get together in person to record a single video as a team. As such, I am flexible on the format. If you have someone on your team with the interest, software, time, and knowledge to collect videos from each member and combine them into a single unified video, feel free to do so. However, that is neither required nor expected. You are perfectly welcome to have one member of the team record the whole presentation (presumably with support from the rest of the team) as a single video. You are also welcome to submit several separate videos made by individual team members. However, if you are submitting multiple videos, it must be clear via the submission process in which order they should be viewed, and they should flow together to the greatest extent possible to come across as a single coordinated presentation (not just several separate videos about the same project).

As with the Individual Project presentation videos, the preferred submission format is a URL for each video. If you are submitting multiple videos, I would like to get one email from a representative of the team containing all of the URLs and clear guidance on the expected viewing order.

Overview

In the professional arena, Web design and development projects are very seldom solo endeavors. Instead, most professional Web projects are team efforts. Therefore, Web designers must be able to collaborate with others as a productive member of a team with a common objective.

Working productively as a member of a team is about more than simply showing up for meetings. In fact, it’s about more than just doing your share of the work. It’s about working together to overcome individual weaknesses and enhance individual strengths.

A good team player understands that productive teams are more than the sum of their parts. That is, if we assume that an average individual’s productivity can be quantified by the variable p, then we should expect the total productivity of an effective four-member team to be well in excess of 4p. This is because a good team works together to support its members and helps them bring out their best.

The team project is intended to give you a taste of what it’s like to work as a member of a Web design team. In all likelihood, you will find that it has its ups and its downs. The project is therefore designed to help you take advantage of the ups and work through the downs.

The team project will occupy you to varying degrees throughout the semester. To help ensure that each team manages their time in a manner that will allow successful completion of the project, there will be numerous checkpoints with deliverables due at various points throughout the semester. Unless I announce otherwise, these checkpoint deadlines will be considered non-essential. Failure to meet them will reflect poorly on your team’s performance, but the penalty for a single missed deadline will not be catastrophic. Consistent failure to meet these deadlines, however, will likely have a significant impact on your team’s grade.

Team formation

An important difference between groups and teams is that teams are more formally structured. Effective and productive teams are much more likely to arise from a process that seeks to distribute talents among teams than from a process that encourages friends to band together for purely social reasons.

To this end, I intend to assign students to teams, not to let students form their own teams. This process will be completed in class.

Teams will consist of three to five students (with four being the target number), and will be formed as early in the semester as possible.

Once formed, teams will remain together throughout the semester. Part of learning to work together as part of a team is learning how to overcome your differences and reach a consensus. I will be available throughout the semester to assist teams in these endeavors, but breaking up or reassigning teams will generally not be an option. After all, in the professional world you seldom have complete control over your teammates and must learn to work with them instead.

Getting started

One of the first things your team must do is identify an acceptable project. This project idea may arise internally as the personal vision of a team member, or it may be found externally by networking with friends, family and employers or the time-honored tradition of “pounding the pavement.” Regardless of where you find your idea, it’s important to begin by ensuring that all members of the team are interested in and excited by it.

I encourage teams to identify and select practical, real-world projects. If you can find a company, organization or individual who could benefit from your efforts, that will give you excellent experience working with a client. Even if your team chooses to pursue the personal vision of a team member, that team member must be willing to serve double-duty as both fully contributing team member and client. In short, whatever project you choose, there must be at least one individual who can be identified as the client or stakeholder.

My recommendation is that you think carefully about the stakeholder when deciding which project to undertake. External stakeholders are generally preferable to a team member acting as stakeholder. Stakeholders located near enough to campus to allow for face-to-face meetings are generally preferable to those accessible only by phone and e-mail. A stakeholder who is excited about and committed to the project is highly preferable to one who needs to be convinced that the project is a good idea.

Projects may involve the creation of a Web site from scratch or the redesign of an existing Web site, but your choice of project must be suitably ambitious to occupy your whole team for the entire semester. If you find a project that appeals to the group, yet seems too ambitious to tackle in a single semester, consider “carving out” a project as the first phase of some larger ongoing project (that will be completed after the course). If you choose this approach, however, be careful to define the parameters clearly so that all team members understand the objectives for the team project and what, if any, obligations will persist once the course ends.

I am not placing any particular minimum or maximum on the number of pages a project may involve, since a 100 page site with pre-existing content and a similar design across all pages could conceivably be far less work than a 10 page site built from scratch using differing designs for each page. As a team, you will need to evaluate each project idea to ensure that you can define the project parameters in a way that makes it sufficiently challenging yet achievable.

The wisdom of the ancients

Previous semesters’ teams have submitted comments at the end of the semester reflecting the lessons they learned while completing their projects. You may wish to review their reports of Lessons Learned both before you begin and as you progress through your own Team Project, as the issues they encountered are very likely to be similar to those you will encounter.

Expertise from the authors

The reason you are required to read several textbooks during the first half of the semester is to enhance your knowledge and capabilities as a Web designer. Toward that end, you will be expected to apply the knowledge you acquire from these books toward your Team Project.

As you read each book, take appropriate notes and consider how that material might be applied to your Team Project. As you apply material from each book to your project, make note of the fact. These notes will make it easier to write your checkpoints and final report at the end of the project.

Free riders

Teams will be expected to work through their differences in the interest of achieving their objectives. Individuals will be expected to contribute their fair share of the effort necessary for the team to accomplish that.

I strongly recommend that each team delegate the necessary tasks in a manner that involves all team members in all phases of the project. This is much more likely to result in an enjoyable and successful experience than a “relay race” approach in which each team member does their part and then passes the results on to the next team member. Think of it as the difference between a braided rope and a chain. If one link in a chain breaks, the entire chain fails. However, if one strand of a braided rope breaks, the remaining strands can often hold on until the job is done!

As with any team endeavor, it is possible that some people will feel that one or more of their teammates are not contributing satisfactorily to the advancement of the team’s efforts or that they themselves are carrying more than their fair share of the workload. Unfortunately, this is often just a fact of life, and it’s in your best interest to learn how to resolve such issues amongst yourselves whenever possible. However, any member of any team may at any time express their concerns directly to me and request my intervention.

Each case is different, but in general I will try my best to use whatever time remains in the semester to resolve the issue as fairly as possible. While I reserve the right to take whatever actions I feel will best serve the long term success of the team and fairness of the grading, here is a (far from exhaustive) list of possible outcomes:

It’s worth noting that many separate factors contribute to the outcome in any particular case, not least of which is when that case is brought to my attention. The sooner I am made aware of potential problems, the more likely it is that I will be able to address them in a way that benefits everyone involved. So do not ignore or defer problem situations any longer than necessary. At the first sign of trouble, begin your efforts to resolve the issues amongst yourselves. As soon as it becomes clear that those efforts are failing, get me involved. If you wait until the end of the semester to notify me of a problem that has been building over time, you will bear some of the blame for delaying my involvement and my involvement will likely be less effective as a result.

Should an issue requiring my involvement arise, one of the first things I am likely to request from every team member is a report of their activities and contributions over the course of the project. I will expect the claims in this report to be verifiable through concrete evidence whenever possible. Since I am not directly involved in your team’s activities, these cases often result in a claim/counter-claim scenario, where one or more individuals make a claim, and others contradict it with a counter-claim. As such, I will rely upon these reports to build a less biased understanding of what has actually transpired, and once I begin an investigation I will request them in relatively short order from all team members.

Since there is no way to predict which teams will eventually experience problems or when those problems will come to light, it is highly recommended that you keep your own meticulous records throughout the project. Retain records of as many communications with your teammates as you can; keep notes on team meetings and collaborative work sessions; keep copies of any files, code, and/or content that you have contributed; and generally look to protect yourself and your teammates from the possibility of inaccurate accusations. When conflicts arise amongst claims, I will generally give greatest credence to the claim that is supported by the strongest evidence.

Checkpoint #1

Due Thursday, February 6, in class

The first checkpoint submission centers around creating a team resumé. Its purpose is to let you (and me) get a sense of what talents and interests your individual members bring to the team and what you’re currently thinking with respect to the project.

While the resulting documents are expected to be reasonably formal and professional, I am not going to dictate a specific format. There is no need for fancy bindings or covers, but you should produce something that your team would feel comfortable sharing with someone who was thinking about hiring you for a project.

Since you may, in fact, find that you have the need for just such a document, and since the requirements will result in the inclusion of information that you might not necessarily wish to share with a potential client, it is acceptable for your checkpoint submission to consist of multiple documents, as long as those documents are formatted in a consistent way and subdivided in a rational and meaningful manner.

In short, as long as you meet the requirements outlined below, I am allowing you the freedom to do so in whatever manner best suits the needs and style of your team.

The checkpoint submission must satisfy the following minimum requirements:

A sample of this checkpoint submitted in a previous semester is available for you to review. The requirements were somewhat different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.

You may also find it helpful at this point to consider some of the lessons other teams in previous semesters have learned as they completed the project.

Going beyond these requirements is perfectly acceptable if you feel it is warranted.

Checkpoint #2

Due Tuesday, February 25, in class

The second checkpoint submission centers around generating a product plan that sets the direction for your project. This is the point by which you will need to have settled on one idea and developed your plan for how to realize that idea on the Web.

For this checkpoint submission, I recommend that you consider the guidance available in Section 1 of the Cohen book. You may follow the boilerplates she provides throughout the section or write in accordance with your own format. However, the end result should be thorough and professional in its coverage and its presentation. Again, fancy bindings and covers are not necessary, but careful proofreading and polished formatting are.

Different teams and different project ideas are going to result in different needs for the product plans, so I am not going to specify a specific format. However, I will expect your product plan to include at least the following sections:

Administrative
Use this section for administrative details such as the name, hosting and URL of the site you plan to create. This section should also describe the stakeholder and provide their position and contact information. It should also provide an overview of the stakeholder’s business or organization.
Mission statement and goals
Use this section to present your project’s mission statement and the list of goals you have for the project.
Target audience
Use this section for the results of your target audience analysis. It should include your user profiles and your estimates of audience size. It should also include at least one persona for each user profile and your predictions regarding traffic patterns.
Features
Use this section to describe your site’s features. Be careful to define a feature set that is achievable given the skills of your team and the constraints of an academic schedule. Also, you will probably want to focus your energy on content-related features, since this is not a course on Web programming. Features that require programming are not prohibited, but they will not weigh particularly heavily in my grading considerations. You want your project to be challenging and meaningful, but also achievable. It is permissible for you to differentiate between those features that you intend to complete during the semester and those which will be eventually added to the site (by your team or others) after the semester is over. If no such differentiation is made, all features listed will be assumed to be objectives for the semester. This section should also include several scenarios involving the personas from the previous section and the features described in this section.
Competition
Use this section to present the results of your evaluation of the project’s potential competition. List and describe the competitors you have identified and explain the threat they pose and how you intend to address it.
Promotion
Use this section to present your plans for eventually publicizing and marketing the results of your project. While you won’t necessarily be required to implement this plan before the semester ends, it’s important for you to give these matters careful consideration very early on in the project development process.
Team
Use this section to list your team members, their areas of expertise, and the major roles they will be fulfilling for the team. For this section, you will probably be able to adapt portions of your Checkpoint #1 submission, firming up any details that may have been left undecided at that time.
Readings
Use this section to describe the ways in which you foresee being able to apply the material in the assigned readings completed so far to your project. This is not meant to be either an exhaustive or a binding list; it is simply meant to keep you thinking about how the readings may apply to your work.
Assumptions
Use this section to detail any assumptions that are implicit in your current plan.

Depending upon the nature of your project, you may find it necessary to include additional sections in your product plan. These sections may include, but are not limited to, sections describing your expected revenue model and your budget.

There will not likely be much need for a section describing your projected schedule, since I will be largely setting your schedule throughout the semester. However, if you expect your project to continue beyond the end of the course, feel free to provide a section describing the overall schedule of what you intend to accomplish within the course and what you expect to do after the course is complete.

A sample of this checkpoint submitted in a previous semester is available for you to review. The requirements were somewhat different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.

As always, these are minimum requirements; you are welcome to go above and beyond them if you feel your situation warrants.

Checkpoint #3

Due Thursday, March 12, in class

The primary objective of the third checkpoint is to establish the underlying structure of your project site. By the time you submit this checkpoint, your design process should be well underway. Be sure to reference the documents you produced for the second checkpoint as you work toward the third checkpoint. This will help ensure that your design evolves in a manner consistent with your overall plan for the site.

For this checkpoint submission, you may want to reference the guidance available in Section 2 of the Cohen book. You may find Cohen’s advice a helpful place to start, but you are likely to find that you need to go well beyond the boilerplates she provides. However you choose to proceed, the end result should be thorough and professional in its coverage and its presentation. As before, fancy bindings and covers are not necessary, but careful proofreading and polished formatting are.

As with the product plan, different teams and different project ideas are going to have different design needs, so I have not specified a format. However, I will expect your checkpoint submission to include at least the following sections:

Information architecture
Use this section to document your information architecture. Pick one or more documentation styles that you feel will successfully encapsulate the results of your efforts to develop a solid underlying framework for the informational content of your site. Be sure your documentation conveys the summary nature of the information chunks, your prioritization of those chunks, the organizational principles you’ve chosen to use, and the relationships you’ve chosen to represent among the chunks. Remember that your information architecture needs to reflect the goals and priorities set forth in your second checkpoint submission!
Labeling
Use this section to present the labels you intend to use throughout your site. Be sure to categorize the labels on the basis of your intended use for them (global navigation, local navigation, search keywords, etc.) Your choice of labels should be directly influenced by the information architecture described in the previous section.
Navigation
Use this section to describe your intended navigational system(s) for the site. Be sure these descriptions are tied directly to the labels presented in the previous section and that the site navigation reflects your information architecture.
Conventions
Use this section to explore your use of Web conventions. Start with a list of all the conventions your team can think of that might pertain to your project. Then, decide which of these you intend to follow and which you intend to defy. For those you intend to defy, be sure to explain your justification.
Usability
Use this section to present the results of your usability analysis at this stage in the process. This analysis should include at least some contact with an actual member of your target audience to obtain their feedback on your information architecture, labels and navigational system. It may also include team-generated insights using the personas and scenarios presented in your second checkpoint submission. You should include details on who was tested, how they were tested, what (if any) conclusions you were able to draw from the testing, and what (if any) changes were made to your thinking as a result.
Readings
Use this section to explore how you have applied the material in the assigned readings done to date toward your work on the project. Include plans or predictions as to how the readings may apply to work yet to be done.

A sample of this checkpoint submitted in a previous semester is available for you to review. The requirements were somewhat different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.

As always, these are minimum requirements; you are welcome to go above and beyond them if you feel your situation warrants.

Checkpoint #4

Due Thursday, April 2, in class

The primary objective of the fourth checkpoint is to finalize your design and set the stage for your team to actually begin the process of building your project site. Be sure to reference the documents you produced for the previous checkpoints as you work to complete this checkpoint. Bear in mind that these are meant to be simply checkpoints along the way in a single cohesive project, and resist the temptation to treat them as individual projects.

This checkpoint submission will likely require a bit more creativity than the previous checkpoints. If you have been utilizing the Cohen text, you will find that she offers far less specific guidance. However, feel free to use that guidance as a starting point. Hopefully, by this point in the semester, the individual expertise of your team members will be starting to come “on line” as they finish their individual projects. As before, the end result of this checkpoint should be thorough and professional in its coverage and its presentation. Fancy bindings and covers are not necessary, but careful proofreading and polished formatting are.

At this point, each team will likely be so deeply involved in the specifics of their project that it makes virtually no sense to dictate a specific format for this checkpoint. Instead, I will endeavor to describe what I expect in a general sense and let each team decide how best to implement those objectives for their project.

The submission for this checkpoint should be the culmination of your design process. I will expect it to explain how you intend to realize the goals and implement the features stated in your second checkpoint submission. I will also expect it to clearly lay out a plan for building a site that is consistent with the information architecture, labeling and navigational systems presented in your third checkpoint submission.

You may use any forms of documentation that you feel will work for your needs, but you should at least include page grids (or schematics/wireframes), page designs and coding guidelines.

Page grids establish the basis for the page layouts you intend to use. There should be one page grid for each distinct page layout you intend to use.

Page designs describe the presentational specifics for a page. Typically, there will be one page design for each page grid, but that’s not absolutely necessary. One page design may suffice for your whole site, or you may find it necessary to associate different page designs with a single page grid. Include as many details as possible in the page design with respect to color, spacing, typography, imagery and any other aspects of the design that need to be recorded. Note that section 12.2 of the Grant text briefly discusses what a typical page design document might entail, at least in part.

Coding guidelines lay out guidance for your team members to follow as they begin building the pages of the site so that there is consistency of coding techniques and formatting styles throughout the site. The more thoroughly defined your coding guidelines are, the more consistent the code produced by different team members will be. This, in turn, will make it much easier for team members to read, understand and (if necessary) fix the code of others.

In short, if you do your page grids, page designs and coding guidelines properly, an outsider should be able to join your team at any point and immediately become a useful contributor to the project by producing pages. In other words, the combination of these three documents should provide all the information needed to implement the pages of your site, with the exception of the actual content.

This checkpoint should also contain an update on the progress of your usability analysis, using prototypes or paper mock-ups to test the usabilty of your design with at least one representative member of your site’s target audience.

Finally, this checkpoint should continue to update me with regards to how you are applying the material from the assigned readings toward your work on the project. The more carefully you consider this aspect of the checkpoint, the easier it will be to complete this section of the final report.

As always, these are minimum requirements; you are welcome to go above and beyond them if you feel your situation warrants.

A sample of this checkpoint submitted in a previous semester is available for you to review. The requirements were somewhat different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.

Upon completion of this checkpoint, your team should begin implementing your site in preparation for your team project presentation. These presentations will begin in class on Tuesday, April 28.

Presentation

The presentation schedule will be incorporated into the overall schedule for the semester. The plan is for them to begin in class on Tuesday, April 28.

Note that the specific schedule of which team is presenting at which time will be intentionally announced only a day or so before Tuesday, April 28. As such, each team should plan as if they will be presenting to the class on Tuesday, April 28. The reason for this is to prevent teams that might have some extra time to finalize their project from having an unfair advantage over teams that do not. Teams that do find they have extra time to prepare are welcome to use it — that is, you are not prohibited on working on your project after Tuesday, April 28 — but no team should plan on having that extra time.

You must provide me with a link to your project site’s current home page at least 24 hours prior to your scheduled presentation (though you are free to continue making changes to the site itself).

Each team will have 20 minutes of class time to present the end results of their project to the class. You may choose to present as a team, or you may elect a single representative to make the presentation on behalf of the team. Presentations that occupy significantly more or less than the allocated 20 minutes will be penalized in the grading

Each presentation should cover at least the following points:

After each team’s presentation, there will be up to 5 minutes available for questions, suggestions and/or critiques from the rest of the class (and me, of course!). During this phase, all team members will be expected to be available for questions, even if they did not participate in the presentation itself.

Final report

Due Monday, May 4, no later than noon
No late submissions will be accepted!

The final report should be essentially a formalized, written version of the presentation described above. It should cover all the points outlined for the presentation above, with two additional areas of discussion: voting and team member statements. It will also involve the submission of your lessons learned coded in HTML.

Voting

Each team will be allocated one vote in each of four categories. The categories correspond to the four assigned textbooks from the first half of the semester.

For each of these four textbooks, decide which of the completed Team Projects best demonstrates adherence to the primary theme(s) of that book. Work from the notes you took during the team presentations, any questions you may have asked, and your own individual examination of the other teams’ sites.

Since you must cast your votes as a team, it is important that you come to consensus before proceeding. Please note that a team may not cast a vote for itself, but you may vote for the same team in more than one category if you feel doing so is warranted. Once you are ready to cast your votes, be sure to thoroughly explain the rationale behind each vote your team casts. Your votes will not be considered in your grade, but the quality of your explanations will be.

Team member contributions

Each team member will add a personal statement explaining what they learned from the course and the project and how they were able to apply their abilities and expertise (both pre-existing and new-found) to the team’s efforts. These statements should go into significantly greater depth and detail than the team presentation did.

A sample of the final report submitted in a previous semester is available for you to review. The requirements were significantly different when it was written, but it does demonstrate the level of thoroughness and professionalism I am ideally seeking.

Lessons learned in HTML form

The lessons learned section of your final report should also be submitted as an attachment to an e-mail message. Please code up the lessons learned as one or more HTML lists (unordered, ordered, or definition), nested if necessary. Just the HTML for the list(s) is sufficient; it does not need to be a complete HTML document. This will allow me to easily include your lessons learned in the course website for the benefit of future students.

Here are links to the team projects and presentations:

TBA