|
General Notes:
- Remote installer programs or websites on remote servers or the
need to install new things on our machines will not be
acceptable and will be considered non-submissions.
- You are required to test your program on a
PC running Windows (7 or 10) without installing anything
other than a standard web browser like Chrome, or
without installing anything other than Android Studio.
If there is something you'd like to use other than that
your team needs to contact me directly at
egolub@umd.edu
to ask before you
start using it on your project, and be prepared for a possible
answer of "no" on the request.
The TAs and I need to be able to run this as will the team using your Phase 2
prototype for their Phase 3 evaluations.
If you are using Android
Studio, please try to use Android 8.1 or below as the target to allow
for a wider range of physical devices to be used for testing,
or have your team submit a request for a higher version with a
specific set of reasons.
It's OK (and probably easier in many ways) if you plan to have people
try it on a regular computer inside an Android emulator since when we
do Phase 3, that's how the other team might have to do it if you do
develop for Android.
I'm told that Mac owners that don't dualboot might find
VMware Fusion
useful for running Windows programs if needed, but I haven't tried it yet.
- Part of Phase 3 will have you creating a short video presentation
about your Phase 2.
- Phase 3 will also involve doing a user study with another team's
project as well as performing a heuristic evaluation of that group's
project. Details of this will be posted closer to the due date.
Overview:
Phase 2 has two related sub-phases, and represents the building of a
medium-fidelity prototype.
The end result needs to be an interactive system that allows you to
demonstrate the overall look and layout of your system as well as the
successful completion of several important tasks. It should contain
the full (or nearly full) "horizontal" level of prototyping, and
several non-trivial "vertical" paths that are realistic.
The overall purpose of this Phase is to give you
experience at things such as:
- maneuvering the shift from low to medium fidelity prototyping
- continuing with the idea of designing using an iterative process
- outlining a plan of action for a team project that covers an
extended period of time
- continuing a task-centered and user-centered design process
- documenting your work and providing structure for others to
use to assess the usability of an interactive system
For sub-phase 2.1 you will need to provide a "game plan" for sub-phase 2.2
detailing several things, submitted as a PDF.
- what you will use to create your prototype
(Java, Android Studio, HTML5/CSS/Javascript, etc)
and (briefly) why you selected that tool
- a preliminary list of the vertical prototype elements you fully expect
to complete by the end of Phase 2
- a preliminary list of the vertical prototype elements you hope to
complete by the end of Phase 2, but that might be left in partial
form if other aspects of Phase 2 are more complex than they appear
- a list of weekly benchmarks towards completion that discusses
when the various horizontal and vertical elements are anticipated
to be done as work progresses
- a brief description of each team member's role/responsibility in
sub-phase 2.2 of the project
Note that there might be some project elements for which you plan to
have hard-coded data examples, or very simple backends (like a text file)
even though a real system might have something more scalable (like a DBMS),
and that is fine to have mixed in with more interactive project elements.
In fact, SQL databases, remote API calls, etc. are examples of things your
Phase 2 is not to have.
For sub-phase 2.2
your team will
implement significant horizontal and vertical elements of
your project in an interactive prototype so that
potential users and stakeholders will be able to interact with it and
assess how the full version will address their needs and impact their
lives
and submit a written report with this prototype. There are six elements
to consider:
(1) Implement a horizontal prototype, plus re-design rationale.
- Redesign your interface as needed based on feedback on Phase 1.3
and your own evolving ideas.
You should also apply the design knowledge you are gaining in class to
your design.
You might develop a few more paper prototypes here and do further
walkthroughs to check your ideas out, but that part is up to you
(and if you do, don't delay implementation too long).
- Implement your design as a medium fidelity horizontal prototype. Using
Java, Android Studio, or HTML/CSS/Javascript
to implement your primary screen(s).
- The "starting" screen is a must (and it should be more than a splash
screen since users generally want "content" from the start)
and for most projects each feature's "home" screen will also be needed.
From this part, include the following in your PDF portfolio:
- a one to two page redesign rationale that describes your main reasons behind
the changes made
- illustrations of your screens, which you can generate by a screen
snapshot tool of your choice
(2) Implement a vertical prototype of parts of the system.
- Again, you will redesign your interface as needed as you work on this.
- Implement a substantial part of the vertical functionality of your
interface. 'Substantial part' means that examples of the more interesting
features (screens, error messages, handling of unexpected input, defaults,
robustness, ...) should be demonstrable.
- An approach that uses task-scenarios will be very useful here, and we
will expect a list of
(a minimum of) 5 up to (and preferably closer to) 10 solid task scenarios
that can be "satisfied" with your prototype (see #4 below).
You can (and should) think about at least one task scenario where the user
might not fully succeed due to an "error" of some sort (ie: think about a
place where help might be desired).
- You may program in 'stubs' for
sub-tasks you are not implementing at this time (eg: certain actions may
return some kind of 'Under development' message but should not cause the
program to crash and should allow you to return to the rest of the system).
- As much as possible (ideally totally) avoid having your system "link"
to an existing live system in any way.
From this, include the following in your portfolio:
- Another one to two page redesign rationale (some of this redesign will
happen as you are building and testing and discovering new issues).
- Illustrations of your final implementation, using new screen snapshots.
- A final discussion (two to three pages), of the state of your design where
you discuss the quality of your system design, what parts of the design you feel
works well and what still needs improvement.
(3) TA meetings and "who did what" report.
At least one meeting with your team TA (if not two),
another detailed who-did-what report.
- Each team will meet with their team TA at least once during Phase 2,
close to the midway point. Teams will be given an opportunity to meet
with their team TA a second time, closer to the phase deadline. These
will be similar in goal as the meetings you had during phase 1, with the
primary difference being that at the midway meeting, the TAs will expect
to see a demo of what you've implemented so far.
- There will be a public "who did what" one page summary of who in the
group did what.
For each person, explain what portions of the project
they worked on, what they wrote, portions of code, documents, etc. This
is a public document that you must all agree upon.
- There will also be a "private" rubric-based assessment where we will
ask you to fill out a form where you "score" your fellow team members on
metrics such as group participation, communication skills, meeting goals,
etc. While there will be points attached to these, the goal is that all
students on a team will work towards deserving equal scores on the project
phase, and that thinking about being a good team member will be encouraged
by this assessment being done.
Any member of a team who does not upload their assessments
will (of course) lose points on their part of the project grade, so
everybody please remember to do this!
(4) Task examples for walk-through/usability study use.
- You will hopefully do some walk-throughs of example tasks within
your project as part of your own testing.
- You must provide between five and ten solid task scenarios that a
user could "perform" during a usability test of your project.
These tasks should be as diverse as possible and performing these tasks
should lead to good feedback about your system.
- A copy of these tasks also needs to be given to the team that will
be doing the usability study of your project. They will be free to choose
other tasks based on the components that you have designed, but they need
to have five good examples from you as well.
(5) The executable!
- You need to get me a copy of your apk or web pages, data files,
etc. that are needed to run and test your project and source code.
Directions about where to place things are important - if we can't
run it when we try, then we're assuming it can't be run.
A zip file that we can simply unzip to its own folder is highly recommended,
where we'll either double-click index.html or use the apk in the Android
Project folder.
You must make the apk for Android but we also want the full
source code project folder just in case.
To make the apk file in my version of Android Studio, I go to
Build - Build Bundles / APKs - Build APK(s)
and the resulting
app-debug.apk
file then ends up inside the
app\build\outputs\apk\debug
subpath of my project folder.
I will set up an entry on ELMS to allow you to upload a zip file there.
- You need to get the team that is using your project for their
study in Phase 3 a copy of the executable and the data files that
are needed to run and test your project. Directions
about where to place things are important - if they can't run it,
then you will lose major points on your project grade.
Note: Presentations and Demonstration.
- As part of Phase 3, you will present on your project and provide a
short demonstration of elements of your running system to the class.
A timetable will be created and you will be assigned slots.
Important Mindset Note
The look and feel and realism are very important in this project,
as is the ability to walk through multiple representative tasks start
to finish. If you are using data, make it realistic!
Grading Note
Grading will be based upon things such as the
sophistication and maturity of the work,
the elegance of the designs and how they reflect
real users and tasks,
the logic of the written presentations,
and the completeness of the work.
The elements of this phase will be worth 16 of the 40
percentage points that the team project makes of the
semester grade.
Updates
If any updates to the description are required, they will
be announced on places like Slack.
|