School of Design, Communication, and Information Technology

INFT6009 Cloud and Mobile Apps Assignment

Summary
Your task is to design, document, and build a mobile app using the tools and techniques taught in the
course, and also to participate in an online developer community.


Due dates and weighting
The assignment is made up of four parts, with three different submission dates, as summarised below.
Each part is due at 10pm on the Friday of the specified week. The total weighting for the assignment is
45% of the mark for the course.

Part Description Worth Due
A Draft app using TouchDevelop 10% Week 6 (Fri 4 July)
B Comments on other students draft apps 5% Week 8 (Fri 18 July)
C Response to comments 5% Week 11 (Fri 8 Aug)
D Final app using TouchDevelop or Visual
Studio
25% Week 11 (Fri 8 Aug)


Assignment overview
There is really no limitation on the kind of app you can write for this assignment. You might write a
game, a utility, something that your employer might use; you might write something similar to an
app that already exists on another platform, but that youre confident hasnt yet been released for
this platform. Use your observation and your imagination.

Recently one of your lecturers needed a good, clear timer that counts down to show conference
speakers how much time they have left to speak. Thats easy enough to implement, but hardly
challenging. But it would be possible to beef it up to make it challenging. It should clearly allow
different overall times. It might sound a small alert with five minutes to go, a louder alert with two
minutes to go, and something persistent when time is up. It might change the text colour or the
background colour at these same points. It might have variable settings, so that the user can decide
what audible alerts and what visual effects will take place at what times. With these and other
features that the creator might think of, even something this simple could become a reasonable app
for the assignment.

As another example, one of your lecturers recently saw an iPhone app with which users can create
various sonic screwdrivers (people not familiar with Doctor Who may turn off at this point), then
fire them, with appropriate sound effects. If such an app is not already available for the Windows
platform, it could be recreated for this platform with proper acknowledgement to the original app.

If you have an idea for an app and are not sure whether its suitable, discuss it with your lecturer.


Handing in your work
All of your development work will be submitted by way of the TouchDevelop cloud community.
Your own app will be published to TouchDevelop, your comments on other students apps will be
lodged with their apps, and your responses to other students comments will be lodged with your
app.

In addition to the TouchDevelop submission, you will be required to give the lecturer a signed
cover sheet attesting that, except where otherwise acknowledged, the work is entirely your own.

You will also be asked to demonstrate your app to the lecturer in the tutorial following the final
submission.


Individual work
This assignment is meant to be your own individual work, although in the descriptions below we try
to make it clear that you are free to use ideas, images, and code from other sources, so long as you
clearly document which bits come from what sources.

What we do not want to see is students working together and producing joint code, or students
writing code for other students in the course. If this appears to have happened, the students will be
referred to the Schools Student Academic Conduct Officer with a recommendation that they be
given marks of zero. Regardless of whether the original work was done by one student or shared by
several, all will receive the same penalty. For this reason, students are urged not to ask other
students for their work, and not to share their work if they are asked. Interaction between students
should not go beyond general discussion of approaches to the assignment.


Deadlines and consequences for late submission
The various phases of the assignment are due at 10pm Australian Eastern Standard Time (+10
UTC) on the Fridays of week 6, week 8, and week 11 of semester. Late submissions will be subject
to the standard University penalty of 10% per day or part day by which they are late (with the
weekend counting as a single day). Submissions more than five days late will be worth no marks at
all.

The signed cover sheet must be handed in no later than the tutorial following the final submission
deadline. If the signed cover sheet is not received, the assignment will not be marked.


Assignment details
The details of the four parts of the assignment are described on the following pages.
Part A: draft app
Due 10pm Friday 4 July (week 6)

In this part of the assignment you will prepare a draft version of your final project. This is to check
that you are on track with your work towards the final project, and to begin the process of online
discussion between all students and the wider TouchDevelop community. You must prepare this
draft using TouchDevelop. A draft prepared using Visual Studio or other programming environment
is not acceptable. However, for the final version of the app (part D) you will have more freedom
(see below).

Because your work will be commented on by other students, you may wish to remain anonymous,
but this is up to you. When you choose a username, bear in mind whether you wish to be identified
to other users. If you wish to remain anonymous, choose a username that will not identify you to
people who know you, and do not identify yourself in comments or other parts of your code.
Remember that anything you publish on the TouchDevelop cloud cannot be removed, so be careful
what is included in your code.

What is expected in the draft:
Any code, including empty actions where development is still required
Bits of code that test some of your ideas
Comments explaining how you will implement your ideas. There should certainly be design-
level comments, at the top level of your script, under script properties, and there should also
be comments within the code.
Art work, sounds or other media associated with the script (see copyright below).

What is not acceptable:
Vague statements about what your project will do, with no evidence of any plan or progress
towards your goals.
A completely unrealistic or over-ambitious idea for a project with no concrete idea of how it
will be achieved.
Code, media or other contributions copied from another source with no acknowledgement.

Copyright: if you need photos, you can use your own photos, or those of others where you have
permission, or use media from Wiki commons. However, if you use anything (images, code, words,
ideas) that is somebody elses, you must properly acknowledge this. If you do use your own images,
be aware that the default option is to upload them to the TouchDevelop cloud, where every
TouchDevelop programmer can access them. Alternatively, you can access photos direct from a
specific url. If you wish to do this, you will need to have your photos on some web site from which
they can be accessed.

Plagiarism: You are encouraged to make use of code from other TouchDevelop scripts. However, if
you do so, you must clearly acknowledge all sources of material. This applies to the final project as
well as to the draft version. Remember that presenting the work of others as if it were your own
work is plagiarism, and is not an acceptable practice.

Submission: your draft app should be published in TouchDevelop. You can publish as many times
as you like, but the version that is marked will be the last version that was published before the cut-
off date and time. Only one version will be marked do not expect the marker to give marks for
multiple versions. Once you have published your script to TouchDevelop, find the unique ID code
of your script. (Be sure to get the code of your script, not your unique user code.) Submit the code
to Blackboard as follows: on the Assessment page, click on the Draft Assignment link; in section2,
Assignment submission, click on Type submission, then type the ID in the textbox that appears. Be
very careful: if you make a mistake in the typing, we will not have access to your app.

Note: Of course you will continue to work on your app over the next two weeks, but DO NOT
REPUBLISH IT! If you do, people will be commenting on different versions of it, leading to at
least two problems: first, the comments might not all make sense with regard to the latest version;
and second, the comments might not even all be in the same place there might be some with one
version and some with another.

If you do want to publish further versions during this two-week period, create a new app based on
this one, check that it has a different ID, and publish the new one while leaving the draft as it was
submitted.


Marking scheme:
Marks Item
2 Overview of app, clearly explained using code fragments, comments, and/or diagrams, and
in the script properties comment field.
2 Explanation of the aims of the project. How far do you intend to go with the app, what will
you include, and just as importantly, what will you leave out because of a lack of time?
2 Explanation of your user interface design, and evidence of good user interface design.
Your draft should give examples of the user interface and explain how the user will
interact with the app.
2 Evidence of an effort to design for a mobile platform (such as use of accelerometer, small
screen, GPS etc).
2 Evidence of a serious effort being made


Part B: comments on other students draft apps
Due 10pm Friday 18 July (week 8)

Soon after you have submitted your draft app, you will be given the unique ID codes that identify
the draft apps of ten other students who are doing INFT6009, possibly on other campuses. You will
be asked to comment on all ten of these apps, which will be chosen at random to ensure fairness and
to ensure that every student will have the benefit of multiple comments. You do not need to submit
anything to blackboard your lecturer will be able to find your comments on the TouchDevelop
site. Only comments made before the cutoff date will be considered.

You will receive half a mark for each app you comment on, so long as your comments are
meaningful, positive in tone and have the potential to make a contribution to the work. Marks are
awarded for comments that suggest improvements to the project design of other students. Comment
should be made in a positive way. No marks will be given for general criticism that does not suggest
improvements.

You are not restricted to one comment per script; you may post several comments on the same script
if you think it will be helpful.

As you provide comments on ten other apps, you will receive ten or more comments on your own
app. The next part of the assignment will give you an opportunity to reply.

Examples of poor and unhelpful comments:
Your app is useless (too negative)
You could improve this app (not specific enough how could it be improved?)
Your app crashed (not specific enough where did it crash?)

Examples of constructive comments:
I found it difficult to line up the circles as they were moving too fast.
The script crashed when I loaded a very small image. It crashed at the 3
rd
line in the
ProcessImage() action. I think you need a check for very small images.
I could not work out how to start when I have an empty address book in the phone it seems
to assume I will always have some contacts in there.
The user interface is not clear, because its not obvious what to do after you select option A
from the list.

Marking scheme:
Marks Item
0.5 Helpful, constructive, positive comment on one of the ten apps you are assigned
4.5 Similarly for the other nine apps you are assigned


Note: If you are late submitting the ID code of your draft app, it is possible that the allocations will
already have been made. It might not then be possible to allocate you ten apps to comment on, or to
allocate ten other students to comment on yours. This will clearly affect your mark for this part of
the assignment and for the next part. It would therefore be wise not to be late with Part A.
Part C: response to comments
Due 10pm Friday 8 Aug (week 11)

The previous part of the assignment will provide you with ten or more comments on your draft app.
In this part of the assignment you have the opportunity to respond. You must respond to each
comment made about your draft design. Your response must address the points raised by the
comments, either explaining how you will develop your project design to take account of the
comments, or explaining why you are choosing not to do so.

For example, say you receive a comment that says The user interface is not clear, because its not
obvious what to do after you select an option from the list. Your response might be along these
lines: I will add code so that as soon as you select an option, two buttons will be displayed: one
labeled go, the other labeled back. At the same time the options will be greyed out and cannot be
changed. This will allow the user to choose between pressing go to continue, or pressing back,
when the options will be displayed and active once more.

As another example, you might receive a comment saying This is a great idea, but it would be
much better if you were able to include real-time actual aircraft movements in the vicinity of the
airport. You might reply Good suggestion, and possibly a direction for future development, but I
believe this is beyond the scope of what can be achieved in the timeframe of this assignment.

You will not be marked for each individual response, as some comments will naturally be more
challenging than others. Also some comments you receive may be vague, unclear, or unduly critical.
You should answer all comments as best you can, and the marks you receive will take into account
the quality of comments that you have to work with.

Marking scheme:
Marks Item
1 All comments are responded to
1 Vague comments are addressed by asking for further information or clarification*
1 All responses are polite, mature, and positive in tone
1 All comments are satisfactorily addressed*
1 At least one response significantly enhances your project design*
* If any of these is not applicable for example, there are no vague comments, or there
are no comments with the potential to enhance your app the marks will be adjusted
appropriately

Part D: final app
Due 10pm Friday 8 Aug (week 11)

In this part you will present the final version of your project, using either TouchDevelop or
Microsoft Visual Studio and C#. The final project is expected to be a development of your earlier
draft. If your project has departed significantly from your draft version, you must add some
explanation of why this is so. As with the draft, do this using comments at the top level of your
script, under script properties.
Your submission should be a fully working app that will work on a mobile device. You should aim
to use properties of a mobile device. This will mean paying attention to the screen dimensions and
the placement of items on the display.
Your submission should take into account the feedback you received on your draft. So if you replied
to comments saying that you would change a particular feature of your app, your final project
submission should reflect this. If parts of your app are buggy, it is better to leave them out. A robust
app with a few features is better than a buggy app with many features.
There is no requirement to respond to any further comments at this stage.

Submission: your assignment should be submitted to TouchDevelop by publishing your script. If
your assignment was created using Visual Studio then you must zip all project files and upload to
Blackboard by the due date. Because you might have a different script from your draft, once again
find the unique ID code that describes your script and submit it to Blackboard, in the same way that
submitted the ID of your draft assignment. You can submit as many times as you like, but the
version that is marked will be the last version that was uploaded before the cut-off date and time.
Only one version will be marked do not expect the marker to give marks for multiple versions.

Cover sheet: as well as submitting your app by way of TouchDevelop or as a zipped file to
Blackboard (for Visual Studio projects), you are required to give the lecturer a signed cover sheet
attesting that except where otherwise acknowledged, the app is entirely your own work.

Please note that the copyright and plagiarism comments relating to the draft also apply here. If you
use the work of other people for which permission is required, it is your responsibility to obtain and
document this permission. It is also your responsibility to clearly indicate which parts of the project
are your own work and which parts are the work of others. You are encouraged to use resources
from other scripts and libraries, but you must ensure that you properly acknowledge them.

Marking scheme:
Marks Item
5 User interface design is clear, it is obvious what the user has to do, screen layout is clear
and obvious.
5 Correct operation of the app as compared to the description. In other words, if the
description says the app does something, it should actually do that. There should be no
bugs, and the program should work as specified.
5 Readability of code, well named variables.
5 Comments explaining how the code works. Clear description of which parts of the
software are original, and which parts are derived from other sources.
5 Use of mobile platform features (such as use of accelerometer, small screen, GPS, etc).