CSC 2002S: MOBILE DESIGN & DEVELOPMENT

Melissa Densmore – 2022

INTRODUCTION
You have two assignments for this class. For MDD1 (Phase 1, due 16 September) you will
demonstrate that you can create a basic Android application. For MDD2 (Phase 2, due 30
September) you will use what you are learning about design to prototype an improved
application. MDD2 (0.8) is weighted higher than MDD1 (1.2); each assignment is marked
separately.

You may work on both assignments individually or in pairs. If you choose to work in pairs, only
one person should submit the assignment, which should clearly indicate both names and both
Campus ID numbers.

To help you plan and prepare, both assignments are being released and described in this
document. It is highly recommended that you look through this document and get started on
MDD1 right away; setting up Android Studio can take a lot of time. Android Studio is also tested
and installed on the lab computers, please contact [email protected] if you need technical
assistance.

MDD1 (PHASE 1) AN ALPHABET BOOK

Due Friday, 16 September at 22:00

Marks – 40 points

You will implement an alphabet book in Android. Included as an attachment in this assignment is
a set of 26 images, one for each letter of the alphabet1. There are two main views for the app, an
overview page, which has a button for each letter of the alphabet, and a letter page, which will
show the image corresponding to the selected letter.

On the letter pages, there should be five buttons:

• First page (‘A’)

• Previous page
• Next page
• Last page (‘Z’)

1Images sourced from Emoji One library, except for Y – ‘yield’ and Z – ‘zipper’,
which have been sourced from Wikipedia Commons.
 • Overview

When you open the application, it should always open to the last letter (or page) viewed, unless it
was last opened on the overview page, in which case it should open on the overview page. The
images should be stored on the phone filesystem rather than compiled into the application under
resources. If you choose to use icons for the buttons or the overview page, you may place those
in the resources.

Please submit your source code, a compiled APK that will run on a Google Pixel 4A emulator
running Android 10 (API Level 29), and your demo recording. All files should be put into a
single archive, which should be named according to your student number(s) and the assignment
number, e.g. ABCXYZ001_MDD1.zip or ABCXYZ001_DEFTUV001_MDD1.zip. Upload the
file and then ensure that you have uploaded the correct file.

You may develop your app in whatever environment you prefer (Android Studio is
recommended). However, you should test that it runs with the emulator that comes with Android
Studio.

Your demo recording should include a code walkthrough demonstrating each point on the
marking rubric

I highly recommend that you start working on this right away. The biggest barrier in getting this
assignment done is often getting your development environment configured and running, rather
than the code itself. Please reference the Android Developer tutorials and other resources on
https://developer.android.com/training/index.html.

MARKING
CODE: 40 MARKS (WEIGHTED 0.8)
This phase will be marked on how well you follow Android conventions and make use of the
facilities provided in the Android SDK. You will not gain extra marks for advanced functionality.
This phase will be assessed on the recorded demo, submitted apk and code alone.

Category Description Points

Demo Does the APK run as prescribed? 5
15 points Overview: Are there buttons for each letter, which 2
display the corresponding letter?
Back: Does the app handle the back button 2
appropriately?
Previous Page: Is the button implemented correctly? 2
Next Page: Is the button implemented correctly? 2
First/Last Page: Do the buttons take you to ‘A’ and ‘Z’? 2
Images: Do all the images display correctly? 1
Code Overview Page: Is there code/xml for the overview? 2
10 points Overview Button: Is there code/xml for a button? 2
based on code Previous Page: Is there code/xml for the button? 2
review; messy or Next Page: Is there code/xml for the button? 2
unannotated code First/Last Page: Is there code/xml for the buttons? 2
to receive partial or
no credit
Following Layout: Is the layout specified in an xml file located in 2
Conventions the res/layout directory?
15 points
Resources: Icons contained in resources. Strings should 2
be specified in res/values/strings.xml and not
hardcoded in the layout or the java files
Activity Bar: Is there an activity bar, preferably with at 1
least one of the four buttons?
MVP Model: Are there classes that clearly correspond 3
to the model and the presenter?
Model = Representation of and access to the images
View = How the model is shown to the user, the
interface
Presenter = Manages user input and model updates
Activity: appropriate methods should be implemented 2
to retain state (i.e. current image) when app is
destroyed, paused, or stopped
Images: Images should be accessed using an Image 1
Factory that will allow later developers to easily recode
where images might be stored and how they are
rendered
Multi-threading: Images should be loaded in the 2
background and not block the main thread
Memory Management: Bitmaps should be sampled so 2
the app does not run out of memory rendering hi-res
images unnecessarily

MDD2 (PHASE 2) M AKE-YOUR-OWN ALPHABET BOOK

Due 30 Septemberat 22:00 SAST (Vula Time)

Marks – 60 points

You need to design and prototype a more advanced alphabet book. Users should be able to
customize the alphabet book, taking their own photos or using their own images for the different
letters. You should start by listing four or more new features or design changes for the system,
explaining why you think those features are useful on a mobile device. Do not just give personal
opinion - think about the social issues discussed in lectures, and design patterns you may have
seen in similar apps. You may consider showing your app from MDD1 to a potential user to seek
feedback; in which case you can quote feedback to support your design. For the purposes of this
assignment a feature is a significant piece of functionality encompassing a particular user goal,
rather than individual buttons or settings.

Next, you need to design how the interface for this functionality will appear. To that end you
need to create a prototype and annotate it with a rationale for your design; be prepared to explain
why your design looks the way it does with reference to the design ideas in the lecture. Simply
stating that you think your design looks nice does not constitute an acceptable rationale. The more
(relevant) information you can give about why the interface looks the way it does, the more
marks you will receive. Where relevant, reference specific design principles and sources using
academic conventions for referencing2.

You do not need to implement this as an android application – you may use any prototyping tool,
such as Invision, POP, Fluid UI, or PowerPoint. Hand-drawn images may also be acceptable, but
you should justify and discuss the fidelity of the prototype.

For this assignment, you will submit a written report of up to 3500 words, containing:

• Overview of the solution architecture: Describe your problem statement, your target
audience and any assumptions you have made. Then provide an overview of the solution
and how it meets the needs of your target audience.
• Overview of the solution’s interface, showing how the features you choose fit together in
the overall solution.
• A list of features with an explanation for their inclusion
• An initial design for each feature. This will consist of a number of screenshots, with clear
markings of how one transitions from one screen to the next. It may be easiest to have a
diagram with numbered elements and refer to those numbers in the text. Be sure to show
how errors or edge cases would be handled in your design. Diagrams may be hand-drawn
if desired but must be clear to the reader.
• For each feature, justify the design; explain why it looks and works the way it does. Do
not just state the name of relevant design principles but make an argument for why others
will appreciate your design.
• If relevant you can also discuss the ways in which guidelines conflict with your chosen
approach; explain your reason for deviation (e.g. conflicting guidelines + prioritizing
specific user needs).

Upload a single Word or PDF document, which should be named according to your student
number(s) and the assignment number, e.g. ABCXYZ001_MDD2.docx or
ABCXYZ001_DEFTUV001_MDD2.docx. Upload the file and then ensure that you have
uploaded the correct file.

MARKING (60 MARKS)

OVERALL ARCHITECTURE : 5 MARKS

2Do not reference lecture slides. It is sufficient to reference specific principles by name, but ideally you will
make reference to primary sources (e.g. published ACM papers).
Give an overview of your target audience. Based on this, describe and give a rationale for an overall
architecture for your digital solution. If it is a mobile app – will this be a web app or a native android
app? Is a server required to interface with the app? If it is something different, how is it all put
together? Discuss how your choices include or limit use of your solution by different populations.
Will it work for bandwidth-constrained users? If you are still in the paper prototyping stage, propose
an architecture and justify it.

Score Description
Not complete (0) No answer, or answer fails to give an overview.
Poor (1-2) No rationale given, or architecture is incomplete or unclear.
Sufficient (3) Good description of overall architecture. Sensible rationale
based primarily on developer constraints.
Good (4) Good description of overall architecture. Sensible rationale
linked to target audience needs. Target audience and their
requirements are clear.
Exemplary (5) Strong discussion and targeting of the architecture to a
target audience. The proposed solution is likely to be
inclusive of a wide audience (e.g. accessible, bandwidth-
friendly).

OVERALL DESIGN AND LAYOUT : 10 MARKS

Provide an overall design for your finished app, showing how all of your features will interact. Make
sure this corresponds to your explanations with the rest of the assignment. You should discuss your
target users and state any assumptions. Specifying the device(s) that the app would run on may be
helpful too.

Score Description
Not complete (0) No layout section or screenshots provided
Poor (1-3) Screenshots incomplete or screenshots provided but it is not
clear how the different features and screens will interact.
Minimal (4-5) Layout is specified but the features or designs do not mesh
well together, or are confusing to the projected user.
Sufficient (6-7) Interactions between features are clearly specified, with
markings for how various features are invoked, and how
different user interactions lead to changes in screen layout.
Fidelity of the prototype discussed and justified.
Good (8-9) All of the above, and the screenshots adhere to the
appropriate platform design principles (probably android).
Clear synthesis of the app overall (i.e. consistent fonts,
buttons, etc).
Exemplary (10) Strong discussion and targeting of the designs to a target
audience, complete application specification, accounting
also for application and user errors.
FEATURE RATIONALE AND DESIGN: 45 MARKS
Each feature is worth 15 marks. Up to three (3) features will be marked. Please remember that a
feature is a full concept rather than a single button or setting.

• Feature Rationale (5 marks): Fully justify the three (3) features that you decided to
include. Include details of any research or experience that led you to choosing them with
referencing.
• Design (5 marks): Document your screenshots, showing how to trigger transitions, and
clearly showing the interface for your feature.
• Design Rationale (5 marks): Explain your design fully, linking it to the concepts and ideas
that you were taught in class. Include in this the ways in which it conforms to the different
standards and models, if appropriate. Every design decision should be motivated.

Not Done (0) Fair (1-2) Good (3-4) Excellent (5)

Feature No feature Feature described Feature justified. Clearly articulated and
Rationale specified. adequately but not cited rationale for
justified. feature.
Design No design Prototype provided Clearly depicted Innovative prototype,
Prototype specified, or (of any fidelity) but prototype clearly articulated,
design unclear. transitions and including leverages affordances
where it fits in the transitions, error and mappings in an
existing app are handling intuitive way.
unclear and synthesis
with current app
Design Design not Justification is Justification Justification correctly
Rationale justified. given but doesn’t includes either an references both
reference design explanation of appropriate standards
principles or other how it adheres to and HCI design
concepts taught in standards and concepts.
class models or it is
linked to HCI and
design concepts

OVERALL DESIGN AND LAYOUT : 10 MARKS

Provide an overall design for your finished app, showing how all your features will interact. Make
sure this corresponds to your explanations with the rest of the assignment. You should discuss your
target users and state any assumptions. Specifying the device(s) that the app would run on may be
helpful too.

Score Description
Not complete (0) No layout section or screenshots provided
Poor (1-2) Screenshots incomplete or screenshots provided but it is not clear how the
different features and screens will interact.
Minimal (3-4) Layout is specified but the features or designs do not mesh well together or
are confusing to the projected user.
Sufficient (5-6) Interactions between features are clearly specified, with markings for how
various features are invoked, and how different user interactions lead to
changes in screen layout
Good (7-8) All of the above, and the screenshots adhere to the appropriate platform
design principles (probably android). Clear synthesis of the app overall (i.e.,
 consistent fonts, buttons, etc.).
Exemplary (9-10) Strong discussion and targeting of the designs to a target audience, complete
application specification, accounting also for application and user errors.