KIT305/KIT607

Posted 2021-09-04 vb4xpudt

KIT305/KIT607
Assignment 2
Implementation and Evaluation of a Mobile Application
Journal and Mood Tracking Application
Due Date
The assignment has three assessable components:

• The application code (worth 50%; pair-based work), due on Monday 20th May 2019 23:55 (week 12).
• A report (worth 40%; pair-based work), due on Monday 27th May 2019 23:55 (week 13).
• A demonstration (worth 10%; pair-based work), due in your scheduled tutorial (week 13).
  Background
  In assignment 1, your task was to design and prototype a native mobile application that allowed a user to create and
  modify journal entries and track their mood.
  Your task for this assignment 2 is to now implement and evaluate a mobile android or ios application that provides
  the functionality. An updated list of requirements and additional requirements is provided in this document.
  In the week 7 tutorial and in your own time, you will evaluate your different prototypes from assignment 1, to
  determine which ones meet the usability goals discussed in this unit, and which should form the basis of your
  assignment 2 code. Note that you are not required to match all of the functionality or visual style from assignment 1,
  but you should aim for some similarity between your assignment 1 and assignment 2 work. Functionality from
  assignment 1 which is not specified in the “Code” section of this document is not required to be complete (for
  example, if your assignment 1 featured a login page, you are not expected to make this function, but you are
  encouraged to include a non-functional version of this in the app if you have time).
  The goal of this assignment is to assess your ability to implement and evaluate mobile applications, and to
  demonstrate your understanding of the fundamentals of mobile device programming when applied to a practical
  context.
  Group Work
  This is a pair-based assignment. Group members will need to agree on a target mobile OS (Android or iOS), and - after
  some usability think-aloud testing of the available prototypes – agree on the design that is to be implemented in code.
  You MUST have a partner chosen by your week 7 tutorial. If you have difficulties finding a partner, use the
  discussion board on MyLO, and speak to other students looking for partners. You will be assigned to a group in week
  7.
  Use the following link to register your group (only one group member needs to do this):
  https://forms.gle/srcK1HwaHD6...
  Changes to group members MUST be approved by the Unit Coordinator. Late changes may not be approved.
  Group members should contribute equally to ALL components of the assignment (report, code, demonstration). This
  assignment will be subject to peer assessment, further details will be provided on MyLO.
  Code (50%)
  When you create your application, please use the following bundle identifier:
  au.edu.utas.username.assignment2
  (replace username with the username of one of the group members)
  The Android or iOS application that you are to implement must consist of at least:
• A way of entering a new journal entry and saving it.
  o At a minimum, journals should consist of a title, text, and a date of when the journal entry is saved.
  Extra meta-data such as location or tagged friends is not required to function correctly.
  Storing an image is considered an additional requirement (see below), not a core requirement
  for this assignment.
• A way of showing a user’s past journal entries, and seeing more information about them.
• A way of editing and deleting previous journal entries.
• A way of selecting a current mood (this can be separate to creating journal entries or integrated into creating a
  journal entry).
• A way of seeing how a user’s mood has changed in the past.
  o As a core requirement, this needs only to list past moods. Displaying a graph is considered an
  additional requirement (see below).
  Data entered by the user should persist between runs of the application. You can use any data persistence method
  taught in this unit to accomplish this (e.g. SQLite, file writing, or SharedPreferences/UserPreferences). You should not
  “pre-fill” the database with user-entered information (such as existing journal entries), as the application should
  function (not crash) when the user has just opened the application for the first time. Remember that any testing data
  you enter while developing your application will not be visible to your marker, as they will be installing a fresh
  version of your application on their emulator.
  An important feature of your application will be its usability, i.e. learnable, memorable, efficient, failure-resistant,
  forgiving, and satisfying. For the purpose of this assignment, particular emphasis will be placed on the “efficiency”
  aspect of usability. This means that if users choose to, they can create a short journal entry quickly, without too many
  additional steps.
  Aside from checking for functionality, your program will be assessed on its robustness (i.e. does the application
  crash), usability, and aesthetics. You will not be assessed on your coding style, commenting, or indentation, however
  given the scale of this application, you are advised to do this to assist in development.
  Remember to leave enough time to test your application on the School Mac computers. There may be some problems
  when you transfer a project from a personal laptop, so you need to leave enough time to solve these.
  When transferring an Android Studio project between computers, use the File -> Export to Zip… option to avoid errors.
  Additional requirements
  To gain higher marks, additional functionality should be added based upon the list below. Use the CRA below to
  work out how many marks you will get for completing these additional requirements.
• The user can store an image in their journal by taking a picture using the phone.
• The user can share a journal entry to another application (such as email, chat program). The shared data,
  should just be a plain-text version of the journal entry (you do not need to implement user accounts or a server for
  this, see the lecture slides for information on sharing).
• The history of the user’s mood over time is shown using a graph.
  o You are allowed to use a 3rd-party plugin for drawing a graph for this part of the assignment (as long
  as you cite the author).
  If your assignment 1 prototype doesn’t include functionality for these requirements, you can still implement this by
  adding this to your application.
  Check the CRA at the end of this document to see the weighting of each component.
  Report (40%)
  You will have been reading many articles throughout the semester that report on the design, iterative refinement, and
  evaluation of new mobile and ubiquitous computing applications. Your readings have also been complemented by
  articles on interaction design and discount usability methods. Accompanying the implementation of your application
  will be a report outlining how you were able to apply the process of usability testing (and specifically think-aloud
  evaluation) to iteratively improve the design and usability of your application.
  You must write a report that is up to six (6) pages long (single-spaced, 10pt Times font). This page count includes figures
  and tables, but excludes references.
  Your report should include the following sections:
• Introduction;
• Description of Application (including selected screenshots of lo-fi prototype and final application);
• (Usability) Methodology;
• Results;
• Discussion;
• Conclusions; and
• References.
  The Methodology section will outline the usability testing that was employed. It will also include details on how the
  testing was conducted, including a description of the user participants and the test-tasks that were chosen for the
  think-aloud evaluation (with a table showing tasks in rows and requirements in columns; see week 02 lecture). It is
  expected that for a HD-level assignment, that you conduct iterative testing across at least three different prototypes.
  Check the CRA for what is required.
  The Results section will report the results of the usability testing. You should present a table of results, however only
  simple summary statistics are necessary; you are NOT expected to conduct accurate statistical analysis such as t-Tests,
  ANOVAs, or correlation). The purpose of this section is to show that you understand the testing process and have
  conducted testing, not to get perfect usability scores. You will not be assessed on whether or not your results were
  positive or not.
  The Discussion section will provide a self-assessment critique of performance on all of the above criteria, and will
  include a summary of the strengths and weaknesses of the application. You should refer to your results section to
  back up your statements with data.
  The report will also reference the set readings, lecture slides, and other literature and resources as appropriate to
  justify decisions and provide background information.
  Demonstration (10%)
  In addition, you are required to demonstrate your application during the week 13 tutorial timeslot. The
  demonstrations will be limited to four (4) minutes total. All group members must participate in the demonstrations,
  and the 4-minute timeslots will be strictly enforced to ensure that all presentations are completed within the tutorial
  session. The group demonstrations will need to:
• State the goals of the work for a broad public;
• Outline the design and testing that was conducted;
• Provide a convincing example of how a person would use the prototype (using either the emulator, a series of
  screenshots, or a physical device); and
• Provide convincing evidence that the application meets its goals.
  You may choose to create a PowerPoint presentation, but this is not necessary. You choose how to best communicate
  the information above.
  If you choose to use a physical device for your demonstration, you must ensure you have tested your application
  thoroughly on the device prior to the demonstration. There will be no time during the tutorial to deploy to the device,
  you must do that at well before your allocated time.
  Assignment Submission
  The following files must be submitted via MyLO before 23:55 on Monday 20th May (Week 12):
• One zip file, containing the project files. The zip filename should start with your UTAS account name (either
  members’ name is fine).
  o For Android, you should create this ZIP file using the File -> Export to Zip option. Submit the ZIP file
  which is created.
  o For iOS, you need to find your .xcodeproj file and project folder in Finder, select them both, right-click
  and choose “Compress”. Submit the ZIP file which is created.
• A group assignment coversheet (available from the ICT website):
  http://www.utas.edu.au/__data...
  The following files must be submitted via MyLO before 23:55 on Monday 27th May (Week 13):
• The group report, in PDF format, with a filename that starts with your UTAS account name (either members’
  name is fine).
• A group assignment coversheet (available from the ICT website):
  http://www.utas.edu.au/__data...
  Only one group member needs to submit these deliverables.
  Peer assessment submission items are to be announced on MyLO, and will be due in Week 13.
  Make sure to test your application on the University Mac machines in UC215 before submitting your assignment.
  Unzip your application to the desktop of a lab machine you haven’t used before. Test that application opens and
  compiles in Android Studio/XCode, and runs in the emulator. Android applications will be tested using a Nexus 5X
  emulator. iOS applications will be tested on an iPhone X simulator. (If you have errors attempting to run your project,
  be sure to try Build -> Clean Project, and running again).
  Plagiarism and Cheating:
  Practical assignments are used by the Discipline of ICT for students to both reinforce and demonstrate their
  understanding of material which has been presented in class. They have a role both for assessment and for learning. It
  is a requirement that work you hand in for assessment is your own.
  Working with others
  One effective way to grasp principles and concepts is to discuss the issues with your peers and/or friends. You are
  encouraged to do this. We also encourage you to discuss aspects of practical assignments with others. However, once
  you have clarified the principles of the problem, you must develop a solution entirely by yourself in your pair. In
  other words; you and your partner must develop the application yourselves. You can discuss problems, but not share
  solutions. Assistance with solutions should be provided by staff.
  Cheating
  Cheating occurs if you claim work as your own when it is substantially the work of someone else.
  o This includes the use of third-party code from online resources.
  Cheating is an offence under the Ordinance of Student Discipline within the University. Furthermore, the ICT
  profession has ethical standards in which cheating has no place.
  Cheating involves two or more parties.
  o If you allow written work, computer listings, or electronic versions of your code to be viewed,
  borrowed or copied by another student you are an equal partner in the act of cheating.
  o You should be careful to ensure that your work is not left in a situation where it may be used/stolen
  by others.
  Where there is a reasonable cause to believe that a case of cheating has occurred, this will be brought to the attention
  of the unit lecturer. If the lecturer considers that there is evidence of cheating, then no marks will be given to any of
  the students involved and the case will be referred to the Head of Discipline for consideration of further action.
  Note: You are allowed to use a 3rd-party plugin for drawing a graph for the “mood tracking graph” part of this
  assignment, and you may use the built-in SQLite implementation provided in tutorials. You may not use any other
  3rd-party plugin for any other part of this assignment.
  KIT305/KIT607 Assignment 2, Semester 1, 2019: Implementation and Evaluation of a Mobile Application
  Criterion High Distinction (HD) Distinction (DN) Credit (CR) Pass (PP) Fail (NN)
  Code (50%; ILO2)
  Students are to produce a journal and mood tracking
  application
  Functionality – Journal List (30%):
  The application should have a way of showing a
  user’s past journal entries, and seeing more
  information about them.
  The application should have a way of editing and
  deleting previous journal entries.
  A custom layout/view for each entry is used,
  showing appropriate detail for a summary
  screen.
  The user can delete entries from the journal.
  The user can modify entries in the journal
  without needing to delete and re-add the items.
  The user can see more detail about a journal
  entry by navigating to a journal page and
  sensible choices were made for this.
  The interface for this part is highly intuitive;
  provides a consistent look and feel and usage
  across all screens and is aesthetically pleasing.
  Application never crashes and has been tested
  thoroughly to avoid the existence of bugs.
  The journal can be filtered or searched in some
  way.
  A custom layout/view for each entry is
  used, showing appropriate detail for a
  summary screen.
  The user can delete entries from the
  journal.
  The user can see the quantity required for
  each item.
  The user can modify items in the list
  without needing to delete and re-add the
  items.
  The user can see more detail about a
  journal entry by navigating to a journal
  page and sensible choices were made for
  this.
  The interface for this part is intuitive and
  aesthetically pleasing.
  Application never crashes. There are only
  very minor bugs (if any).
  A custom layout/view for each entry is
  used, showing details of each journal
  entry.
  The user can delete entries from the
  journal.
  The user can see more detail about a
  journal entry by navigating to a journal
  page.
  The interface for this part is somewhat
  intuitive.
  There are only some bugs (if any) in the
  application and/or very rarely crashes.
  The title of each journal
  entry is listed.
  The user can delete
  entries from the journal.
  A basic list view is
  provided.
  The user can see more
  detail about a journal
  entry by navigating to a
  journal page.
  There are only some
  bugs (if any) in the
  application and/or rarely
  crashes.
  The application does not
  compile OR crashes on
  start-up OR crashes
  frequently.
  The user is unable to view
  all journal entries or is
  unable to delete items.
  Functionality – Add Entry (15%):
  The application should have a way of entering a
  new journal entry and saving it.
  At a minimum, journals should consist of a
  title, text, and a date of when the journal entry
  is saved.
  Users can add journal entries with a title, text,
  date, and sensibly-chosen additional metadata.

The interface for this part is intuitive and
aesthetically pleasing.
Users can add journal entries with a title,
text, and a custom date, and additional
meta-data.
The interface for this part is intuitive and
aesthetically pleasing.
Users can add journal entries with a title,
text, and a custom date and time.
The interface for this part is somewhat
intuitive.
There are only a few bugs (if any) in this
part of the app.
Users can add journal
entries with a title, text,
and the current date
and time.
There are only a few
bugs (if any) in this part
of the app.
The application does not
contain functionality to add
journal entries.
Crashes prevent the user
from adding journal
entries.
Functionality – Mood Tracking (15%):
The application should have a way of selecting a
current mood (this can be separate to creating
journal entries or integrated into creating a journal
entry).
The application should have a way of seeing how
a user’s mood has changed in the past.
Users can enter their mood without having to
create a journal entry. Users can select a
custom mood (if appropriate to design of app).
Users are able to see a history of their moods.
Sensible choices are made for this display.
The interface for this part is intuitive and
aesthetically pleasing.
Users can enter their mood without having
to create a journal entry.
Users are able to see a history of their
moods.
The interface for this part is intuitive.
Users can enter their mood without having
to create a journal entry.
Users are able to see a history of their
moods.
The interface for this part is somewhat
intuitive.
There are only a few bugs (if any) in this
part of the app.
Users can select a
mood when creating a
journal entry.
There are only a few
bugs (if any) in this
screen.
The application provides
no functionality for
entering a mood, or
crashes prevent this part
of the assignment being
assessed.
Functionality – Data Persistence (15%):
Data entered by the user should persist between
runs of the application. You can use any data
persistence method taught in this unit to
accomplish this (e.g. SQLite, file writing, or
SharedPreferences/UserPreferences).
All data entered by the user persists between
runs of the application.
There are no noticeable bugs with the
persistence.
The application functions when there is no data
in the database.
All data entered by the user persists between runs of the application.
There are only some bugs (if any) with the persistence.
The application functions when there is no data in the database.
Most data entered by
the user persists
between runs of the
application.
There are only some
bugs (if any) where
some data does not
save.
The application
functions when there is
no data in the database.
Data does not persist
when the application is
closed and re-opened.
Usability - Efficiency (5%):
The application should make it easy for user to
quickly create short journal entries.
The interface provides well-thought out
functionality for making creation of journal
entries a quick process.
Basic functionality for making the creation of journal entries quickly is provided.
There are no noticeable bugs with this implementation.
Basic functionality for
making the creation of
journal entries quickly is
provided.
There are only some
bugs with this
implementation.
The application does not
have any design decisions
that make creating a
journal entry a quick
process.
Additional Functionality – Camera (10%):
The application should allow the user to add
images to their journal entries.
The application allows you to choose a photo
from the phone’s image gallery or camera and
add it to a journal entry.
The image is displayed on the screen after the
user selected the image and throughout the
rest of the app.
The image is saved to the database (either file
URL or image data is fine).
There are no bugs with the camera
functionality.
The application allows you to choose a photo from the phone’s image gallery or camera
and add it to a journal entry.
The image is displayed on the screen after the user selected the image and throughout
the rest of the app.
The image is saved to the database (either file URL or image data is fine).
The application allows
you to choose a photo
from the phone’s image
gallery or camera and
add it to a journal entry.
The image is displayed
on the screen after the
user selected the
image, but the image
does not persist on
consecutive runs.
The application features
no camera functionality or
the camera functionality
crashes the app when
triggered.
Additional Functionality – Sharing (5%):
The application should allow the user to share
a journal entry to another application on the
phone (such as email, chat program).
The application allows you to use the OS’ builtin
sharing functionality to share a text version of
a journal entry with all details (title, text, date,
mood).
Bonus (difficult): The user can share the text,
AND image attached to the journal entry.
The application allows you to use the OS’ built-in sharing functionality to share a text
version of a journal entry with most details.
The application allows
you to use the OS’ builtin
sharing functionality
to share the title of the
journal entry.
The application features
no sharing functionality or
the sharing functionality
crashes the app when
triggered.
Additional Functionality – Mood Graph (5%):
The application should display a graph to
showing the history of the user’s mood.
The application shows a visually pleasing graph
which uses data from the database (or other
data persistence method).
The graph can be filtered by different time
periods.
There are only a few bugs (if any) with the
graph functionality.
The application shows a simple graph
which uses data from the database (or
other data persistence method).
The graph can be filtered by different time
periods.
There are only some bugs (if any) with the
graph functionality.
The application shows a simple graph
which uses data from the database (or
other data persistence method) but doesn’t
change when the user selects different
time periods (but options still visually exist
to select a time period).
There are only some bugs (if any) with the
graph functionality.
The application shows a
simple graph (that is not
simply a static image).
The graph uses data
from the database (or
other data persistence
method).
The application does not
feature a graph or the
graph crashes the app
when displayed or a static
image is shown for the
graph.
Report (40%; ILOs 1,3,4)
Student is to create a report up to 6 pages long.
Description of Application (25%; ILO3)
The report will describe the functionality that has
been implemented; including images of the low-fi
prototype and final application.
All core functionality is explained in a concise,
and well-written manner.
Screenshots are clear and show the core
functionality of the app.
A reasoned description of how the final
application and lo-fi prototype differ is
provided.
All core functionality is explained in a
well-written manner.
Screenshots are clear and show the core
functionality of the app.
A description of how the final application
and lo-fi prototype differ is provided.
All core functionality is explained.
Screenshots show the core functionality
of the app.
Report contains an
overview of the
functionality and some
screenshots.
Fails to provide a
description section.
Methodology (25%; ILO4)
The report will outline the usability testing that
was conducted and the procedure in which it
was conducted.
The employed usability testing is welldescribed
and well founded; and accompanied
by clear usability test tasks and success
requirements.
Choice of methodology is well-justified.
At least three prototypes are evaluated over
multiple rounds of testing (i.e. iterative testing is
conducted).
The employed usability testing is welldescribed;
and accompanied by clear
usability test tasks and success
requirements.
At least three prototypes are evaluated.
The employed usability testing is welldescribed.

At least two prototypes are evaluated.
At least one prototype
is evaluated, and most
required details of the
testing procedure are
described.
Methodology follows
the recommendations
for this unit.
Fails to provide a
methodology section.
Results (25%; ILO4)
The report will report the results of the
usability tests.
Results are complete (and in a concise table)
and include completion times with summary
statistics. Results match the methodology
described in the report.
Results are complete (and in a concise table), and match the methodology described in
the report.
Basic results are
provided.
Fails to provide a results
section, or some results
are missing or
inconsistent with the
methodology section.
Discussion, Conclusion, and Overall
Report Style (25%; ILO1)
The report will provide a self-critique of the
application’s performance, including strengths
and weaknesses of the application.
The report will link to the set readings and other
literature and resources as appropriate.
A thorough and insightful discussion of the
results exists, sensibly highlighting ways future
versions of the app could be improved.
Report covers all of the required sections. It is
very well structured, has the required length,
and has a logical flow between sections.
English conventions of spelling, grammar, and
punctuation are excellent.
Academic referencing is consistent, with
many references beyond the set readings.
A thorough discussion of the results also
exists.
Report covers all of the required sections.
It is well structured, has the required
length, and has a logical flow between
sections
English conventions of spelling, grammar,
and punctuation are excellent.
Academic referencing is consistent, with
some references beyond the set
readings.
A detailed discussion of the results is
provided.
Report covers all of the required sections.
It is well structured, has the required
length, and has a logical flow between
sections
English spelling, grammar, and
punctuation are good.
Academic referencing is consistent,
linking to the set readings.
Some discussion of the
results is provided.
Report covers all of the
required sections.
Academic referencing
links to the set
readings.
Fails to provide a report,
or report is missing some
required sections.
Demonstration (10%; ILO5): Within the allocated 4-
minute group timeslot, students are to:

• State the goals of the work for a broad public.
• Outline the design and testing that was
  conducted.
• Provide an example of how a person would use
  the prototype.
• Provide evidence that the application meets its
  goals.
  The demonstration convincingly covers the
  required objectives and holds the attention of
  the audience. It is clear and rehearsed; flows
  nicely over the different topics and speakers.
  The demonstration is coherent, interesting, and
  informative; eye contact is made; and the
  demonstration is complete within 4 minutes.
  The demonstration is not rushed.
  The demonstration convincingly covers the
  required objectives. It is clear and
  rehearsed; flows nicely over the different
  topics and speakers.
  The demonstration is coherent; and
  complete within 4 minutes.
  The demonstration is not rushed.
  The demonstration covers the required
  objectives.
  The demonstration is clear and rehearsed
  and complete within 4 minutes.
  The demonstration
  somewhat covers the
  required objectives.
  Fails to demonstrate.
  WX：codehelp