Shared Presence¶
Collective Visibility for Group Projects¶
A shared presence is an optional, outward-facing artefact that communicates what your project is, who is behind it, and how it is progressing — to clients, supervisors, and external readers including potential employers.
It is not a requirement. It is not assessed. It is not a replacement for individual documentation or individual showcases.
It is the collective layer that connects individual work to a shared project context — and, done well, it is one of the most professionally useful things a group can build during a final-year project.
What This Section Is For¶
Most group project websites look the same. A title, a short description, a list of names, a YouTube link added in the final week. These sites exist because someone asked for them. They communicate almost nothing about the quality of thought behind the project, and they do nothing for the individuals who built them.
This section is for groups who want to do something different — who want to build a shared presence that is live across the project, that explains rather than lists, and that gives each team member a collective anchor to point to from their individual work.
The guidance here is practical. It covers what a shared presence actually does, what distinguishes a meaningful one from an empty one, and how to build it across a range of disciplines and platforms.
What This Section Contains¶
What Is a Shared Presence establishes the conceptual foundation. It covers what a shared presence does for different audiences, what makes one meaningful rather than decorative, and the single most important quality to build in from the start. Read this first, regardless of your discipline or platform choice.
Building a Project Website is written specifically for Computer Science, IT, and Engineering groups building a live site using GitHub Pages. It covers what the site should contain, why each element matters, and how to get it published and maintained across the project.
Shared Presence for Other Disciplines addresses groups in design, data science, education, business, marketing, and other fields — including platform options appropriate to each discipline and the content considerations specific to each type of project.
How to Navigate This Section¶
If your group is in CS, IT, or Engineering and is comfortable building a website: read What Is a Shared Presence first, then move to Building a Project Website.
If your group is in another discipline or prefers a non-website approach: read What Is a Shared Presence first, then move to Shared Presence for Other Disciplines.
If you are unsure whether to build a shared presence at all: read What Is a Shared Presence and decide from there. The answer is usually yes, if your group is willing to start early and update it consistently.
Timing matters more than platform
The most important decision about a shared presence is not which platform to use — it is when to start. A shared presence begun in the first or second week of the project captures the full story: problem definition, decisions, pivots, milestones, and outcomes. One begun in the final month captures only the ending. Start early, start simply, and update it as the project develops.
How Shared Presence Relates to Guide A and Guide B¶
Guide A supports individual record-keeping during the project. Guide B supports individual showcases after the project. A shared presence sits alongside both — it draws from the same project work without duplicating individual records, and it provides a collective anchor that each individual showcase can reference.
The relationship is additive, not substitutive. Individual records remain private. Individual showcases remain individual. The shared presence is the layer that makes the collective project visible to readers who need context before individual contributions make sense.
Begin with What Is a Shared Presence.