代做data编程、Python/c++程序代写

日期：2024-02-22 08:57

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

process in limited detail.

H No significant attempt.