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 1**point sensible font.
Paragraph structures are typically **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:

請(qǐng)加QQ：99515681 或郵箱：99515681@qq.com   WX：codehelp