swift IOS代写： KIT305/KIT607 Assignment 2

KIT305/KIT607 Assignment 2 (Revision 1)

Implementation and Evaluation of a Mobile Application Shopping List Application

Due Date

The assignment has three assessable components:

– The application code (worth 50%; pair-based work), due on Mon.28.May.2018.15:00 (week 13).
– A demonstration (worth 10%; pair-based work), due in your scheduled tutorial (week 13).
– A report (worth 40%; pair-based work), due on Mon.28.May.2018.15:00 (week 13).
Background

In assignment 1, your task was to design and prototype a mobile application that allowed a user: to easily create and maintain a shopping list, and track their grocery shopping expenditure.

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, you and your partner will determine which prototype from your combined 6 will be used to form the basis of your assignment 2. Note that you are not required to match all of the functionality from assignment 1, but there should be some visual and functional similarity between your assignment 1 and assignment 2. 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 100% for the assignment, but you should include screens with sample buttons for navigation).

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 the end of week 07. If you have difficulties finding a partner, use the discussion board on MyLO, and speak to other students looking for partners. Ideally, your partner should be from the same tutorial session as you. If not, you will need to schedule your time so that you can both be present in the same week 07 and week 13 tutorial session (week 7 is for think-aloud testing, and week 13 is for a group demonstration). Partners do not need to be from the same unit code (i.e. KIT305 or KIT607).

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 screen which shows the user’s actual shopping list. At a minimum this list should show what items the user hasn’t yet purchased, and provide a way of letting the user indicate that they have purchased an item.
– A screen which allows the user to add items to their shopping list. At a minimum, users should be able to enter the name and quantity of the item. This part of the application should be forgiving (according to the design principles we covered in the week 03 lecture).
– A screen (or screens) which allows the user to track which items they have purchased already, and choose to enter the price of the items so that they can track expenditure. Users should be able to filter this list by items purchased in a given day, week, month, or year.
If you feel some of the interfaces in these minimum requirements would be better suited to using multiple screens, you may do so. You may have additional screens, or include extra features on the screens listed above.

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 information user-entered information (such as items in the shopping list), as the application should function (not crash) when the user has just opened the application. 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 the 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 “forgiving” aspect of usability. This means that your application should allow a user to correct accidental and incorrect entries.

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.

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 with each item in their shopping list by taking a picture using the phone.
– The user can share their list via to another application (such as email, chat program). The shared data could be
a fake URL to the list, or a text version of the list (you do not need to implement user accounts or a server for this).
– A graph is displayed on the purchase summary screen (item number three in the list above).
If your assignment 1 prototype doesn’t include functionality for these requirements, you can still implement this by adding this to your application.

If your assignment 1 prototype does include functionality for these requirements, you may change the functionality to match this specification to make programming easier.

You are not required to make multiple lists function.
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 (specifically think-aloud evaluation) to improve the design and usability of your application.

You must write a report that is up to six (6) pages long. It must be in the SIGCHI Extended Abstracts format used for Works-In-Progress (WIPs). A Microsoft Word template exists for this format and is available to download from:
>> http://st.sigchi.org/sigchi-paper-template/SIGCHIExtendedAbstractsFormat.docx 1

Your report should include the following sections:

– Abstract;
– Introduction;
– (Prototype) Design;
– (Usability) Methodology;
– Results;
– Discussion;
– Conclusions;
– Distribution of Work; and
– References.

Your report will also include Author Keywords and ACM Classification Keywords2.

The Design section of your report will outline how your application can be used to provide the functionality requested in the assignment specification above. This section should include a walk-through of the main parts of the application.

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 tasks that were chosen for the think- aloud evaluation (with a table showing tasks in rows and requirements in columns). Usability testing may be:

1) Early (formative) testing on a low-fi Balsamiq or paper prototype.
2) Late (summative) testing on hi-fi Android or iOS code prototype.

You need only conduct ONE of these two types of testing for this assignment.

The Results section will report the results of the usability testing, in a table, and showing tasks as rows and each user’s performance as columns, with each cell showing whether the user succeeded at the level demanded by the requirement (e.g. unaided, or requiring assistance, or failed). The completion times for the test tasks may also be included in this set of results (only simple summary statistics are necessary; you are NOT expected to conduct accurate statistical analysis such as t-Tests or ANOVAs). 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.

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 indicate in what ways the usability testing impacted your design (note: some feedback from testing may not be achievable with our current skill-set in mobile programming—you will not be penalised for not incorporating this feedback into your Android or iOS application). You should refer to your results section to back up your statements with data.

1 You need only conform to the template styles for headings, and body text. You may ignore most of the additional requirements described in the template document.
2 ACM Computing Classification System for Keywords (1998): http://www.acm.org/about/class/ccs98-html

Your report should indicate in at least 3 or 4 sentences which group members did which aspects of the assignment. Recall that you cannot have one group member complete all the coding and the other complete all of the report.

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, or use your PDF and code for the presentation.

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.

If your partner is from a different tutorial session you must ensure you attend the tutorial session listed on the demonstration schedule.

Assignment Submission

The following files must be submitted via MyLO before 15:00 on Mon.28.May (Week 13):

– 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 can 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/assets/pdf_file/0005/161375/GroupAssignmentCover.pdf
– The accompanying group report, in PDF format, with a filename that starts with your UTAS account name (using the same members’ name as above).
Only one group member needs to submit these deliverables.

Make sure to test your application on the University Mac machines 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 8 Plus emulator. (If you have errors attempting to run your project, be sure to try Build -> Clean Project, and running again.

Additional marks will be awarded for applications with layouts which work on multiple different device types, but this is not required to pass the assignment.

KIT305/KIT607 Assignment 2, Semester 1, 2018: Implementation and Evaluation of a Mobile Application
Criterion	High Distinction (HD)	Distinction (DN)	Credit (CR)	Pass (PP)	Fail (NN)
Code (50%) ILO2
Functionality – Main List (30%): The application should include a screen which shows the user’s actual shopping list. At a minimum this list should show what items the user hasn’t yet purchased, and provide a way of letting the user indicate that they have purchased an item.	A custom layout/view for each list item row is used. The user can delete items from the shopping list. 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. Navigation to the other screens is provided and sensible choices were made for this. The interface 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 list can be filtered by tags or categories. Bonus: Users can create and maintain multiple lists.	A custom layout/view for each list item row is used. The user can delete items from the shopping list. 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. Navigation to the other screens is provided and sensible choices were made for this. The interface is intuitive and aesthetically pleasing. Application never crashes. There are only very minor bugs (if any).	A custom layout/view for each list item row is used. The user can delete items from the shopping list. The user can see the quantity required for each item. Navigation to the other screens is provided and sensible choices were made for this. The interface is somewhat intuitive. There are only a few bugs (if any) in the application. Application doesn’t crash.	The shopping list displays items the user has yet to purchase. The user can delete items from the shopping list. A basic list view is provided. Basic navigation to other screens is provided. There are only some bugs (if any) in the application and/or very rare crashes.	The application does not compile OR crashes on start-up OR crashes frequently. The shopping list does not meet the minimum requirements from the specification, or does not contain a list view.
Functionality – Add Item (15%): The application should include a screen which allows the user to add items to their shopping list. At a minimum, users should be able to enter the name and quantity of the item.	Users can add items to the shopping list both by entering in the full name into a text field and by selecting from a pre-set list of items. Users can set the quantity of the item they want to add and additional information such as tags or categories. Well thought-out and usable functionality for filtering the list of pre-set items / remembering frequently-used items is implemented. The interface is intuitive and aesthetically pleasing.	Users can add items to the shopping list both by entering in the full name into a text field and by selecting from a pre-set list of items. Users can set the quantity of the item they want to add and additional information such as tags or categories. Basic functionality for filtering the list of pre-set items / remembering frequently- used items is implemented. The interface is intuitive and aesthetically pleasing.	Users can add items to the shopping list either by entering in the full name into a text field or by selecting from a pre-set list of items. Users can set the quantity of the item they want to add. The interface is somewhat intuitive. There are only a few bugs (if any) in this screen.	Users can add items to the shopping list either by entering in the full name into a text field or by selecting from a pre- set list of items.	The shopping list application does not contain functionality to add items. Crashes prevent the user from navigating to the add item screen (or from using the add item interface).
Functionality – Expenditure Screen (15%): The application should include a screen (or screens) which allows the user to track which items they have purchased already, and choose to enter the price of the items so that they can track expenditure. Users should be able to filter this list by items purchased in a given day, week, month, or year.	Users can see a filterable list of all the items they have purchased from the main shopping list. The total cost of items is displayed. The user can permanently remove items from this list, and the total cost of items updates. The interface is intuitive and aesthetically pleasing.	Users can see an unfiltered list of all the items they have purchased from the main shopping list. The total cost of items is displayed. The user can permanently remove items from this list, and the total cost of items updates. The interface is intuitive and aesthetically pleasing.	Users can see an unfiltered list of all the items they have purchased from the main shopping list. The total cost of items is displayed. The interface is somewhat intuitive. There are only a few bugs (if any) in this screen.	Users can see an unfiltered list of all the items they have purchased from the main shopping list.	The shopping list application does not contain functionality to summarise expenditure. Crashes prevent the user from navigating expenditure screen.

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 – Forgiving (5%): The application should allow a user to correct accidental and incorrect entries.	Well thought-out functionality for undoing the most recent addition to the list and other parts of the app (e.g. tags) is implemented. There are only some bugs (if any) with this implementation.	Basic functionality for undoing the most recent addition to the list is implemented. There are only some bugs (if any) with this implementation.		The application only allows the user to undo incorrect entries by using the remove from list functionality.	The application does not allow the user to undo incorrect entries.
Additional Functionality – Camera (10%): Student is to implement a mobile application that allows the user to store an image with each item in their shopping list by taking a picture using the phone.	The application allows you to choose a photo from the phone’s image gallery and apply it to a product. 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 and apply it to a product. 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 and apply it to a product. The image is displayed on the screen after the user selected the image. The image is not saved to the database.	The application features no camera functionality or the camera functionality crashes the app when triggered.
Additional Functionality – Sharing (5%): Student is to implement a mobile application that allows the user to share their list via to another application (such as email, chat program).	The application allows you to use the OS’ built- in sharing functionality to share a text version of the shopping list (e.g. each item separated by a new line). The shared list includes appropriate additional information about each item (e.g. quantity). Bonus (difficult): The user can share a generated image of their shopping list.	The application allows you to use the OS’ built-in sharing functionality to share a text version of the shopping list (e.g. each item separated by a new line).		The application allows you to use the OS’ built- in sharing functionality to share a fake URL linking to the shopping list.	The application features no sharing functionality or the sharing functionality crashes the app when triggered.
Additional Functionality – Expenditure Graph (5%): Student is to implement a mobile application that displays a graph on the purchase summary screen.	The application shows a visually pleasing graph which uses data from the database and reacts to the current filter on the expenditure graph. There are only a few bugs (if any) with the graph functionality.	The application shows a simple graph which uses data from the database and reacts to the current filter on the expenditure graph. There are only some bugs (if any) with the graph functionality.	The application shows a simple graph which uses data from the database but isn’t based upon the current filter on the expenditure screen. 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 doesn’t use data from the database or current screen.	The application does not feature a graph or the graph crashes the app when displayed.

Report (40%) ILO3, ILO4, and ILO5: Student is to create a report up to 6 pages long and using the specified template and specified report sections. The report will: – Describe the functionality that has been implemented; and provide a user-walkthrough including images of the low-fi and high-fi prototypes. – Outline the usability testing that was conducted and the procedure in which it was conducted. – Report the results of the usability tests. – Provide a self-critique of the application’s performance, including strengths and weaknesses of the application. – Link to the set readings and other literature and resources as appropriate.	Report covers all of the required sections. It is very well structured, has the required length, and has a logical flow between sections. The level of detail provided is excellent (i.e. clear and concise but with detailed coverage and design decision justifications). The employed usability testing is well described and well founded; and accompanied by clear usability test tasks and success requirements. Results are complete (and in a concise table), and include also completion times; and a thorough discussion of the results also exists. Linkage to the set readings is excellent. English conventions of spelling, grammar, and punctuation are excellent.	Report covers all of the required sections. It is well structured, has the required length, and has a logical flow between sections. The level of detail provided is very good (i.e. clear and concise but with detailed coverage). The employed usability testing is well described; and accompanied by clear usability test tasks and success requirements. Results are complete (and in a concise table); and a thorough discussion of the results also exists. Linkage to the set readings is good. English conventions of spelling, grammar, and punctuation are excellent.	Report covers all of the required sections. It is well structured, has the required length, and has a logical flow between sections. The level of detail provided is good, the report reads well, and the images and their descriptions are labelled and easy to follow. The employed usability testing is described. Results are complete, and some discussion of these results also exists. English spelling, grammar, and punctuation are good.	Report covers most of the required sections. It contains an overview of the functionality and some screenshots. Some usability testing is described, and most required details of the testing procedure and results also exists.	Fails to provide a report.
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.
The superscripts used above indicate the unit ILOs that these criteria map to, i.e.: ILO2: “Apply theoretical and practical knowledge to develop applications that are mobile-device specific and that demonstrate current practice in mobile and ubiquitous computing contexts.” ILO3: “Apply standard design approaches to create user interfaces and to adapt these interfaces to the particular emerging demands of mobile and ubiquitous computing systems.” ILO4: “Evaluate mobile and ubiquitous computing applications based on discount and user-based usability techniques, and to select and to justify the most appropriate technique for a particular situation.” ILO5: “Demonstrate effective communication skills (including written and verbal) across a range of professional contexts and the ability to work independently and collaboratively with other students during the design, development, and evaluation of mobile and ubiquitous applications.”

Related Posts