代做Mobile HCI (H/M): Coursework Exercise
時間：2024-02-22 來源： 作者： 我要糾錯
Mobile HCI (H/M): Coursework Exercise
1. Introduction
For this coursework exercise, you will be conducting a small research project that
aims to develop and evaluate an alternative input technique for activating on-screen
buttons on handheld or head mounted mobile devices. You will need to design,
implement, and evaluate an input technique prototype, then produce a written
report that describes your design and development process, and presents the
findings of your evaluation. This is an individual assessment and cannot be
completed as part of a group.
You are expected to produce a functional implementation of your input technique,
so that a user can complete a range of appropriate interaction tasks on a mobile
device. You cannot use design tools like Figma or Adobe XD for this assessment – we
want to see some form of development that yields a working prototype of your
designs. You are required to submit source code and your report needs to explain
the implementation of your input technique.
We recommend using the development technologies we use in the lab exercises for
this course. If you complete the lab exercises, then you will have sufficient
prototyping skills to accomplish an excellent project. You are, of course, welcome to
use alternative platforms (e.g., native Android or iOS development). You are also
allowed to use additional frameworks and libraries to support your implementation,
remembering that all third-party code should be clearly identified and referenced.
When assessing your work, our focus will be on process rather than product. Your
input technique does not need to be cutting-edge or use a highly complex design
that rivals the state-of-the-art in mobile human-computer interaction research. We
are not just assessing your coding abilities or your abilities to produce a working
implementation entirely from scratch. It is fine for your work to replicate or take
inspiration from existing input techniques.
Instead, we place emphasis on going through a quality research process, e.g., a
thorough design process that yields well-justified input technique designs, a robust
development process that leads to high quality functional interactive prototypes,
and an appropriately detailed evaluation process that gives good insight into the
efficacy of your designs.
2. Input Technique
Your input technique needs to allow a mobile device user to activate buttons
without directly tapping on them via the touchscreen. Users must be able to activate
one button from at least five available buttons independently, using your input
technique – so you cannot just implement a simple mechanism for activating a single
button or triggering a single input event.
1
You can use almost any interaction modality for input recognition (e.g., motion,
orientation, speech, gesture, gaze, etc). You could take inspiration from the lab
exercises, and you could incorporate alternative input modalities like those
considered in the lectures.
You can use the touchscreen for input, so long as users are not simply tapping on
buttons directly to activate them like with conventional touchscreen use. Instead,
you could take inspiration from existing touchscreen input techniques like marking
menus [1], offset cursor techniques [2], motion correlation gestures [3], etc.
Your implemented prototype should allow users to complete button activation tasks
– e.g., present several buttons from which one must be activated. The prototype
should be sufficiently functional to allow an evaluation to take place.
You can use any form of button design and button layout you like, so long as users
can activate one button from five or more available targets. Buttons do not need to
always be visible – e.g., they may not appear until the user initiates some
interaction, or you may choose to design an entirely non-visual interaction
technique. Buttons do not need to provide any functionality and there is no specific
application context – you may choose to just label buttons from Button 1 to Button
N, or you could alternatively base this on an example interaction context (e.g.,
buttons for controlling music playback).
3. Project Outline
For this coursework project, you are expected to design, implement, and evaluate a
prototype for a novel input technique. You will then submit a written report that
discusses your work throughout the full research process.
In this section, we give an outline of what we would like to see in the report – this
will let you see what we expect from the project and should give guidance about
what to include in your report.
You should read through this section (and the rest of the handout) in its entirety
before you begin the project work. This will hopefully avoid any unexpected
surprises – e.g., coming up with design ideas that you cannot implement or evaluate.
3.1. Interaction Technique Design
You should design one input technique – i.e., a series of actions that a user can take
to intentionally activate a particular button in an arbitrary user interface layout.
Consider available input modalities (e.g., device motion, device orientation, touch,
speech, mid-air gesture, pressure). What modalities are available for the device that
you are going to use? What modalities could feasibly be incorporated into an
interactive prototype? We recommend choosing one or two input modalities only
(e.g., using motion only, or combining motion and speech); avoid overly complex
multimodal designs as this likely exceeds the time available for this assessment.
2
Having identified your potential input modalities, you should consider the actions
necessary for button activation – i.e., what do users need to do to target and
activate a button, and how could you recognise those actions? Can you clearly define
conditions or criteria for recognising that those actions have taken place – i.e., how
do you know the user intended to activate that button? How can you tell the
difference between an intentional and unintentional action? Are there any
constraints or implications for user interface layout – i.e., do buttons need to be
arranged in a particular way, placed in a particular position, have a certain
appearance, etc? Are there any limitations of your design – e.g., maximum number
of available buttons? Engage with these questions to help you come up with a more
formal definition of your input technique. Be creative.
Once you have a better idea of your input technique behaviour and functionality,
you should think about how your technique can be incorporated into a usable user
interface design. There are two key things to think about at this stage: what kinds of
feedback do users need, and how should buttons be arranged and presented on the
device?
In terms of feedback, consider what your users need to know to understand the
current state of the input technique. How do they know they are interacting
correctly? How do they recognise if their actions are causing an effect on the
system? How do they know if a button has been targeted? How do they know if the
desired button was activated correctly? Think about how you can provide
information and feedback to your users so that they can form a better
understanding about how your input technique works.
In terms of button layout, consider how you might arrange buttons in your
interactive prototype. The goal is not to exhaustively identify the range of potential
user interface layouts or designs, but to encourage you to come up with at least one
button layout that you will incorporate into your prototype – because your users
need to activate something.
As an outcome from this phase of the project, you should have a design specification
for your input technique. This specification should describe the actions taken by a
user to target and activate a button and should identify how the user interface
changes in response to user input. You should consider trying to formalise this as a
state diagram for a finite state machine – e.g., what are the possible states of your
input technique, what conditions cause a transition from one state to another, and
how does the user interface react to changes in state?
Your report should describe the design and rationale of your input technique.
Discuss why your chosen approach was selected and why you think it is appropriate
for your chosen mobile device or interaction context. What are the potential
strengths and weaknesses of your design? What made you choose this design? You
may wish to discuss similar existing input techniques, e.g., from consumer
technology or research papers. You could also discuss alternative ideas that you
considered and discarded, as this gives better insight into your interaction design
process. Use diagrams or sketches to illustrate and communicate your input
technique’s intended behaviour.
3
A thorough design process will make implementation more straightforward – e.g., by
forcing you to think about how your system will function – so don’t rush ahead to
begin development.
3.2. Prototype Implementation
You should begin implementing an interactive prototype of your input technique.
This prototype should present multiple buttons to the user and allow them to
activate those buttons by using your input technique. The buttons do not need to do
anything when activated – i.e., no features or functionality need to be provided.
However, it should be clear to the user that the selection is complete, e.g., through
appropriate feedback. You may wish to implement multiple button layout
prototypes for a more comprehensive evaluation in the next phase of the project –
e.g., to give insight into how your technique performs with different button layout
parameters.
During development, consider the robustness of your implementation. What are the
edge cases for your input recognition? Do you need to take steps to mitigate falsepositive or false-negative recognition? Are there any undefined state transitions? Is
there anything that might be unclear to the user about how the system is behaving?
Using existing libraries and frameworks is fine, although we expect there to be some
level of technical complexity in your project – e.g., a project that simply instantiates
a marking menu using an existing library may not score as highly as one that
implements the marking menu interactions itself. You can use the lab exercises as
the basis of your implementation, but we would like to see improvements or
adaptations to the design and implementation of those input techniques – i.e., you
cannot just conduct an evaluation of the lab exercise solutions without substantial
change.
As an outcome from this phase of the project, you should have an implemented
prototype that demonstrates your interaction technique. Your implemented
prototype may differ from your initial design – that’s fine.
Your report should discuss the development and implementation of your prototype.
Explain how you implemented your input technique and discuss any additional
design decisions made during implementation. You likely encountered many
challenges about how best to implement something – e.g., choosing appropriate
sensor thresholds, choosing appropriate button layouts, choosing the ‘best’ way to
present feedback, etc.
If you want to incorporate novel interaction modalities (e.g., hand tracking, eye
tracking) feel free to ask us for advice about how to get started.
3.3. Evaluation
Now you should have a functional prototype that you can evaluate with other
people. There are two aims for the evaluation: (i) to evaluate the efficacy of your
input technique; and (ii) to provide empirically supported design recommendations
about how to use the technique successfully (e.g., about how to design usable and
effective button layouts).
4
There are many evaluation methodologies you could use, and we are quite open
minded about how you do this. However, your chosen evaluation methodology
needs to involve users interacting with your prototype. You cannot, for example, use
surveys with screenshots or videos that illustrate interaction. Instead, you need to
choose an evaluation approach that involves users interacting with your prototype,
e.g., to complete a series of button activation tasks.
For a stronger evaluation, you may wish to compare your own input technique to
conventional touchscreen activation as a baseline condition – although this is not
required.
In terms of evaluating efficacy, think about what evaluation data you can collect to
enable you to reflect on the strengths and weaknesses of your input technique
design. For example, can you measure things like task completion time, button
activation success rate, etc? You may also use survey and qualitative data to give
further insight, e.g., through standard usability surveys, design heuristics, and
interview questions.
In terms of providing design recommendations, think about how your design can be
used to help interaction designers use your designs successfully. For example, can
you design your evaluation with different button sizes, button layouts, feedback
types, etc, to determine how effective different options are? Rather than a simple
evaluation that concludes ‘it works’, we want to see your evaluation try to identify
when ‘it works’ (or when it might not).
As an outcome of this phase of the project, you should have data and feedback
which you can use to evaluate your input technique. Reflect on what worked well
and what did not. Think about potential areas for improvement or future research.
Consider how your results can be used to present design guidelines or
recommendations for others.
Be honest and open to critique when analysing your evaluation results. We don’t
expect things to be perfect, so don’t avoid talking about things that did not work as
well as expected – otherwise you won’t have much to talk about and are potentially
missing out on extra marks! Remember, the emphasis is on process not product – we
don’t care if your results show it was amazing, we’re more interested in the
evaluation process that you go through.
Your report should describe your evaluation design and justify why you chose to
evaluate your prototype in that way. You should also present and discuss the
findings from the evaluation. Finally, you should discuss what you would do as future
work if you had more time to continue to refine your design – e.g., would you
implement your interaction technique differently, or would you choose entirely new
interactions instead?
When considering evaluation for your project, be conscious of the School of
Computing Science ethics procedures for student projects. Avoid evaluation tasks
that expose your participants to potential risks. In the interests of time, we
recommend avoiding any evaluation designs that would require further ethics
approval. Chat to us about this if you’re unsure.
5
3.4. Advice on Project Planning
In this section of the handout, we have given you quite detailed suggestions about
what you should do during the coursework project. We have presented the project
in terms of three key phases with clear outcomes from each phase. We recommend
using this structure to create a rough plan for your project. You should anticipate
spending most of your time on implementation and evaluation, so make sure you
start the project early to give yourself plenty of time for these. The earlier you start
on design, the more time you will have to ask questions and get feedback.
Towards the end of the semester, there will be no lab exercises; instead, lab
sessions will be left free for you to work on this coursework. These lab sessions are
the ideal time to run your project evaluations because you’re all going to be in the
lab at the same time. Please be willing to take part in other students’ evaluations
and, in return, ask them to take part in yours.
4. Submission
You should submit a written report, the source code for your interactive prototypes,
and any data gathered during the evaluation process. The tentative submission
deadline is Monday 11 March at 16:30 and everything should be submitted via
Moodle.
4.1. Report
Your report should use the template provided on Moodle and should describe all
aspects of work completed during the project. There is no expected structure, but
the project outline in this handout should give you a good idea about what we would
like to be included in the report. Your report should be a maximum of 6 pages and
should be submitted as a pdf. References and appendices do not count towards the
page limit, so cite as many papers as you like!
4.2. Source Code
You need to submit the full project source code of your final interactive prototype. If
you do not submit this, your project may not be marked. You should submit a zip
archive containing the full project source (in a state where the markers can deploy or
run it), or alternatively should provide a link to publicly accessible source code (e.g.,
an accessible Glitch project or GitHub repository).
Remember that the aim of this coursework exercise is to develop and evaluate an
interactive prototype, so that you can test your interaction designs. It does not need
to be a fully functional system and it does not need to be perfectly engineered. We
are not assessing code quality; we are mainly interested in seeing how you
implemented your prototype.
4.3. Evaluation Data
You need to submit any data collected as part of the evaluation process, ensuring
that no personal data is included (in compliance with the ethics process for student
evaluations). This may include quantitative measures of task performance, survey
data, interview data, etc. You should submit a zip archive containing all data,
separate from your source code. If you do not submit this, your project may not be
marked.
6
5. Grade Descriptors
A1-A5 Excellent
Excellent design process leading to a highly innovative and well-justified input technique
design. Excellent technical prototype that provides a robust and thorough implementation.
Excellent evaluation involving a variety of input tasks, shows great attention to detail, and
gives very good insight into the usability of the input technique. An excellent report that
clearly describes the research process and shows excellent reflection on evaluation results.
B1-B3 Very Good
Very good design process leading to an innovative and well-justified input technique design.
Strong technical prototype that provides a robust and thorough implementation. Very good
evaluation involving a variety of input tasks, shows good attention to detail, and gives good
insight into the usability of the input technique. A very good report that clearly describes the
research process and shows very good reflection on evaluation results.
Satisfactory design process leading to a mostly well-justified input technique design.
Adequate technical prototype that provides a mostly working implementation. Good
evaluation with some appropriate input tasks and gives some insight into the usability of the
input technique. A satisfactory report that describes the research process and shows some
limited reflection on evaluation results, though may lack critical insight.
Poor design process leading to a barely justified input technique design. Poor technical
prototype that offers an unreliable implementation. Poor evaluation with a limited range of
input tasks and gives poor insight into the usability of the input technique. A poorly written
report that describes the research process in limited detail.
C1-C3 Good
Good design process leading to a well-justified input technique design. Strong technical
prototype that provides a mostly working implementation. Good evaluation with some
appropriate input tasks, shows good attention to detail, and gives good insight into the
usability of the input technique. A good report that describes the research process and
shows good reflection on evaluation results, though may lack critical insight.
D1-D3 Adequate
F1-F3 Poor
E1-E3 Weak
Weak design process leading to a poorly justified input technique design. Satisfactory
technical prototype that provides a mostly working implementation. Weak evaluation with a
limited range of input tasks and gives limited insight into the usability of the input technique.
A poorly written report that describes the research process in limited detail.
G1-G2 Very Poor
Very poor design process that does not adequately justify the input technique design. Barely
functional technical prototype. Poor, or no, evaluation that gives very poor insight into the
usability of the input technique. A very poorly written report that describes the research
請加QQ：99515681 郵箱：99515681@qq.com WX：codehelp
標簽：
掃一掃在手機打開當前頁
注：本網條致力提供真實有用信息，所轉載的內容，其版權均由原作者和資料提供方所擁有！若有任何不適煩請聯系我們，將會在24小時內刪除。
無相關信息 昆明生活資訊
昆明圖文信息
|
|
|
|
|
|
|
|