|
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 the Java 11 JDK
or 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 an
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.
- 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 three related sub-phases, and represents the building of a
medium-fidelity prototype and then presenting about your work.
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
or the use of things like localStorage.setItem in Javscript)
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.
We have
posted task scenarios
that your prototype needs to support in addition/complement
to other tasks. This can perhaps be seen as a bare minimum to not get an F,
but you need to develop a prototype with more to get to the C or B or A level,
and the quality of what you create will also play a large role in grading.a
With everything, I strongly recommend against aiming for the minimums.
When approached well, your work in this phase can provide things to
talk about during interviews, add to a showcase portfolio, and give you
a sense of pride in your work.
There are five bullets to consider in this sub-phase:
(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 or JAR file, 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 the runnable JAR file
or use the apk in the Android Project folder.
You must make the apk for Android or JAR for Java,
but we also want the full
source code project folder just in case.
To make a runnable JAR, I go to
File - Export - Java/Runnable JAR file
and the resulting JAR can double run by double-clicking it.
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.
For sub-phase 2.3
your team will
create a voice-over-slides video, and PDF of the slides with the
narration transcribed below each.
The individual slides will be a mixture of text and screenshots
from your prototype.
To show the flow through tasks, you can either
have several slides in a row with screenshots as you
undertake the task,
or you can put a screen capture video onto a slide
as well.
The video presentation should be between 8 and 15 minutes.
-
Tools that I recommend using to make the video:
PowerPoint,
Audacity,
a microphone.
-
The process that I recommend for making your 8-15 minute video:
- Prepare your slide set as a team, using Google Slides
as a shared working space. This might include slides with
a screenshot of something or a photo of something or just text.
- Decide who on the team will present each slide.
Then each person goes through their slides as if they were presenting
each slide during a team presentation in class,
transcribing what they would say in the "slide notes"
space below each slide.
- Everyone on the team should review the full transcript when everyone
feels done to lock it in. Then, each student will record the audio for
their slide and one student will collect the audio file for each slide
to create the full video in PowerPoint.
- For each slide a student is narrating, have Audacity open in a small
window so you can see the notes area of slides behind it, and narrate
the slide using that script. Then save the track out as an MP3
or WAV named for the slide number in which it will go.
- For the student combining everything, go through each slide and
insert the corresponding audio clip on that slide, and move the
icon off to the slide so it doesn't actually appear on the slide.
- After having the whole slideset done and saved, go through and
make a video
by going to File - Save&Send or Export (depends on PowerPoint
version), and choosing the option to Create a Video at Internet
resolution.
- Finally, go through and update your narration script
in the notes section to match the recorded dialog, and then
print the slide set with the notes as a PDF handout to post,
as I have been doing with my video lessons.
-
It can be good to add "pause" points in your video where you ask the
viewer to pause if they want to study the slide more before the video
moves onto the next one.
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 18 of the 35
percentage points that the team project makes of the
semester grade.
Backups Advice
If you are not using some sort of version control system
for your code base, I would strongly suggest making backup
copiesof your work on at least a daily basis, or even after
each major successful modification within a day.
What I tend to do is to make a zip file of my entire project
folder, name it with the date, and then copy it over to a USB
drive or my Google Drive.
This provides a safety net in case something happens on the version
on which you are working.
This includes if you make changes that you realize made things worse
or if something gets deleted.
It's not as easy as reverting in a version control history, but is far
better than redo-ing things.
For non-coding elements such as reports and write-ups,
if you are not creating those using something like Google Docs,
I strongly suggest the same approach.
Updates
If any updates to the description are required, they will
be announced on places like Slack.
|