2811 User Interfaces
Coursework 3: The Process
Final Summative Group Project
Date set: 15.11.23
Date due: 14.12.23 - 2pm
Weighting: 100%
Goals for this CW:
Apply the user interface knowledge we have learnt
Experience the interaction design lifecycle as a group
Design, evaluate, and develop a complex GUI application in Qt
Present your research in a written report
Demonstrate the process of each iteration in a short video (circa 1 minute)
Create a short (circa 1 minute ‘showcase’ video of your final product
Produce a 6 page Written Report (including images)
Your task:
Build a video-based application in Qt
Your group is provided with the Tomeo Qt prototype, as starter code toward your first
iteration for the following opportunity:
THE SCENARIO
Based on the recent success of BeReal (aimed at teenagers / young adults)
Marketing and our Product Owner have suggested we create a prototype app
(MVP) offering a similar range of functionality but video rather than photo.
We need to create a prototype to present at the next Senior Leadership Team
meeting. It's a short turnaround (again), only four weeks until the next meeting.
In our Product Development meeting, your line manager suggested we first
build out on a previous prototype ‘Tomeo’ that our company trialed for an
'outdoor enthusiast' video player app, as a first iteration / proof of concept.
While the UI needs some work, the Qt/C++ functionality provides a sufficient
framework to get you started.
We can aim to continue refactoring the Tomeo code or you could create totally
original code once familiar with the apps video handling structure and approach.
The product owner and marketing don't really care about the codebase (as long
as it's in Qt), they just need a working protype proof of concept, ideally
something we can interact with and demonstrate.
As this is a global product for a wide audience, what they do care about is
Universal Usability & ideally some Internationalisation.
As we've got several dev squads at various international offices working on this,
you will get feedback on your prototype from another dev squad, during the 3
rd
sprint (29
th
Nov - 6
th
Dec). You’ll need to complete an Ethics form for
compliance. No need for intense testing, just a short usability questionnaire will
be fine. Can I leave you to arrange those please.
Don't forget to show where you've implemented their suggestions in your
weekly video, it's good for team morale and workplace culture.
As there will be Dev Leads and a VP’s joining the meeting, they've asked if we
can produce three short videos, around 45s-1.20m each, documenting our
weekly sprint iterations and outcomes.
We also need to create a final Showcase video (1m20 - 1m45) of your final
MVP prototype app to demo the full range of functionality. These will be shared
on our social media channels so make sure they’re aimed at a general
audience.
The app is mobile &/or tablet first but a desktop version is something we want to
aim for as well. Lets focus on a responsive mobile UI first.
You should include a video screengrab of the app in the Showcase video, and
also replace Tomeo’s videos with your weekly videos and the final showcase.
Any questions, just get in touch with me on the usual channels…
Getting started:
Before the first iteration, everyone should get the Tomeo prototype running.
Open the zip file and open the .pro project in QtCreator.
You will probably have to configure Qt (consider setting some initial
internationalisation language options here):
On Windows use Qt 5.13 to use the multimedia plugin
On RedHat (in the lab & feng) use Qt version 5.13
On Ubuntu (Linux) please also use Qt/5.13; we also had to install:
sudo apt install gstreamer1.0-plugins-good
Run the project. When a dialog pops up, click yes to open the video files.
Extract the videos and set the absolute path of the videos directory as the first command
line argument to the project.
Run the Tomeo prototype in Qt Creator, explore its (limited and buggy) functionality.
Explore the code. In particular note the following classes, and read any Qt
documentation you need to:
tomeo.cpp: contains the main method and creates a list of video files that have
thumbnails.
the_button.cpp: a subclass of QPushButton which shows the icon, and has a
signal (jumpTo) that is fired when someone clicks it.
the_player.cpp: a subclass of QMediaPlayer which controls the playback of the
video in the QVideoWidget class.
By this point you are already in a group. Contact me NOW if you are not assigned a group
(available to check on Minerva). It is YOUR responsibility to contact us if you are not in a
group. We will not accept late responses. You will fail this module if not in a group.
Make contact with your group on Minerva; ensure each member has made contact (update
the weekly group evaluation on Feedback Fruits). Contact Julian directly if you have
concerns about group members and their participation.
Arrange a first meeting time with your group members as soon as possible, online or in
person. Plan to meet at least twice a week (Wednesday mornings and Friday afternoons
might be good times), as well as plan in advance how many hours per week you will be
able to commit to.
In the first meeting:
Document this and all following meetings
(you could take turns making notes in each one)
Exchange contact details with your group members,
Set up a shared code repository (e.g., git, GitLab, Github....),
and a platform for shared process documentation (e.g. Office 365, Miro.com,
githubPages etc.).
Arrange a number of weekly times to meet, discuss and update each other on your
progress (also async via online platforms e.g. MS Teams) throughout.
Explore the initial Tomeo prototype together.
Develop your requirements.
For this coursework you should propose realistic requirements for yourselves, as well as
gathering data from the Top Hat survey:
■ perform an initial analysis to scope the possible requirements
■ construct use-case scenarios for your system
■ plan, eg with a shared Kanban Board, for your first sprint iteration
(& repeat for remaining sprint iterations)
During the first week
Design, present and discuss alternative designs that satisfy your use-cases.
We recommend one per person. You can discuss and incorporate the various aspects of
each.
Vote if unable to agree collectively
(i.e. vote on all, removing one each time and keep voting until one remains).
Weekly Process
You will complete at least 3 development iteration cycles of your app before the due date
above. For this coursework, one iteration consists of:
i. prototyping an improvement
ii. implementing the prototype
iii. evaluating the prototype
There is no requirement to continue with the Tomeo starter code but you are welcome to
do so if it simplifies the process
Material to Submit
You will create process documentation throughout the project that will be the foundation of
your report - detailing the design processes with a range of the following suggested
approaches:
1. Approaches to analysis based on the UI Lecture material provided, requirements, usecase
scenarios, constraints and the prototypes which refine your iterations.
2. Further material for the report could include the platforms you are targeting (desktop,
mobile, web, etc...), with images that support and demonstrate those (if implemented).
3. All our development will take place on the Desktop with Qt and C++, but we can easily
design for other hardware / software.
4. Examples of content for your group report should include examples of each cycle (these
examples are not compulsory or limited to), e.g.:
i. prototypes
a. Writing describing the goal of this cycle and the reason this was selected as the
highest priority.
b. the name of the prototyping technique and any software used and why chosen
(technique: sketch, wireframes, video, native....software: Photoshop, Gimp, Qt
Designer, etc...)
c. Writing highlighting the theoretical motivation behind the design shown in your
prototype(s).
d. Writing providing justification for the chosen group working technique (eg Scrum,
Agile).
e. Writing providing evidence for the chosen group working technique (including,
photos, screenshots of the Kanban board, etc...).
f. Writing exploring the design and the process and evolution (including photos,
screenshots of wireframes, paper prototypes, etc...)
ii. code
a. Writing illustrating the UI improvements
b. a table describing differences between the prototypes and the implementation
(improvements, time constraints or technical difficulties).
iii. evaluation
a. the name of the evaluation technique used (heuristic evaluation, cognitive
walkthrough, questionnaire, etc...)
b. Writing describing why this technique was chosen.c. Writing describing the outcomes of the external evaluation and whether the
changes for that final cycle were accepted, changed or rejected (and why).
d. evidence of the evaluation (a table of the results, anonymous images of the
evaluations, etc…)
Videos
Weekly videos.
45s- 1m20s demo videos that can be submitted, documenting each protype/sprint.
They should illustrate the main ways how they satisfy your requirements of that sprint.
Showcase Video
One video 1m-1m30s showcasing your work and final production
Ethics
An ethics statement, explaining how you complied with the university regulations for ethical
research with people. Include an example information sheet and template consent form.
Do not include the completed forms themselves.
How and why you should do this will covered in an upcoming lecture.
ReadMe / HowTo
A README/HOWTO of how to run your software.
Notes:
Ask questions on MS Teams main channel as usual.
The page limit on documentation is intended to make you choose your language and
conclusions carefully.
A page may be 1 or 2 (double) column, in an 11-point sensible font.
Paragraph structures are typically 1-2 statements giving an overview, followed by 6-8
sentences supporting the statement.
The writing should illustrate your understanding of UI theory, iteration processes and
terminology learnt throughout the module.
Note that our emphasis here is not totally focused on writing code as the final output. We
care (and award a range of marks for) the design process you go through, the effective UI
and the (limited) functionality of your app.
It is acceptable to reject the result of an iteration if there is a well presented reason. In
Scrum we often speak of ‘fail early, fail fast.’
? Examples of iterative development could include:
... the workflow (e.g., how to demonstrate group working and collaborative decisionmaking
during iterations – Kanban is good for this process)
... wireframes of initial and ongoing designs
...the visual design of the system (e.g., colours, spacing, icons, menus etc.)
...a flowchart or mindmap etc. showing proposed video functions.
We are developing a prototype, so it is acceptable for certain parts to be partially
developed. You should develop all necessary components of the system to evaluate the
central concept of your weekly iteration. However, some peripheral functionality may be
partial.
For example:
A "load" button may just show a dialog saying "you selected a video" before
showing the loaded video, rather than creating a full file chooser.
A range of effects and tools can be ‘just’ buttons / menus
Video thumbnail images may be loaded from disk rather than computed or from
network storage (the given prototype does this).
You could consider running different iterations in parallel (at the same time) to spread the
work between group-members, as long as iterations are branched then merged into a
single code base if successful. For example:
different people could perform parallel cycles to prototype, evaluate, and code the
layout of the home screen - then one is picked to be taken forward.
different components could be built by different pairs of people – a dialogue box
could be a parallel cycle to the main screen visual design.
!!!Keep backups of everything!!!
Submitting
All multimedia (video, still images, audio including potential sound-sets) should be
submitted within your final zipped submission (due 14th December 2pm).
Recording
If required you can record video on Feng/Red Hat with ctrl + alt+ shift + r
We do not assess the quality of videos (noise, camerawork etc... they are beyond the
scope of this assignment). But they should be clearly understandable on a first viewing
when the accompanying presentation is delivered.
There is no requirement for your videos to contain an audio track but if they do please
make sure they contain subtitles.
Further requirements
Use a sensible and consistent code style. Ensure comments are helpful.
Marking
Marks will be awarded for:
The quality of your scoping analysis and scenarios for the given task.
The quality of your prototypes and evaluations, as well as how well they match your
chosen scenarios.
The application of a wide range of ID/UI/UX theory (as taught in the module) to your
groups motivations and decisions.
The variety of prototyping and evaluation techniques applied.
Completing at least THREE iterative cycles.
Developing significant and creative improvements to the Tomeo application which match
your scenarios.
The quality of your code.
The quality of your documentation process and writing, including:
structure
arguments and supporting information
Your ethics compliance documents
Contributions:
All members of your group will be assigned the same mark, peer assessed
contributions of group members via Feedback Fruits will be additionally submitted.
We reserve the right to penalise group members who were found to not contribute
significantly to the project.
10 (ten) marks are reserved for a range of individual tasks (via Feedback Fruits)
throughout The Process lifecycle.
To submit the documentation:
Your submission should be a zip file containing: