|
In addition to the individual assignments, activities, and exams,
we will have a semester-long team project with multiple phases
and sub-phases.
Teams will need to
consist of four students from the same section of class
(some teams of three might be approved based on enrollment,
but the default expectation is four).
Each team will be assigned a member of the course instructional team
(the instructor and the teaching assistants) as a "senior manager" who
will interact with the team throughout the semester in various ways.
Please note that with these assignments, the breadth and depth of useful features,
realism, and the quality of the user interface and the overall user experience
are all important parts of the grading criteria.
In addition to assessment, grading, and feedback
of each phase and sub-phase by members of the instructional team,
there will be peer assessment submitted for some of the four
phases of the project.
In these situations,
you will each be asked to describe what each of your teammates did
on the phase as part of this assessment.
All students in a team are expected to participate in each phase
and understand their own role,
but are also expected to understand the contributions of their fellow
team members.
One "goal" of the peer assessment is to help all members of the team
think about the contribution they are making and hopefully decrease
the likelihood that someone will "coast"
(see social loafing).
These assessments will be used as part of the grading criteria, but
the intent is that thinking about these peer assessments
will motivate the team to come see me to help them
work things out if they face issues,
and have a better team experience.
If a serious team issue does occur, you should contact me
via e-mail or Slack
to try to help
the team resolve the issue in a timely manner.
It is likely that for certain aspects there will be "lead"
students working on different deliverables at times, but all
students on the team should be discussing and reviewing each
other's work as well and all voices should be heard during
team meetings.
You will be able to use our class'
Slack team page for team
coordination, and will be required to use it for interacting
with the instructor and your TA.
Note that if this were being done "for real" the best team would have
people from diverse backgrounds, which would give the team different
perspectives on the problem.
For example, a real team could comprise a project manager, a marketing
person, a programmer, a representative end user, and/or a help desk
person who regularly deals with end users.
I would encourage you to think about this as we form groups.
A more detailed description will be posted for each phase, but
it will be useful to present an overview here to get us started.
Phase 1 will have
two "threads" to it.
Phase 1.1 will have three related sub-phases.
The parallel Phase 1.2 will be an exercise in coding and team cohesion.
In Phase 1.1.1 you will form your teams around a posted project option
and submit an initial "pitch-back"
where each team will describe (in two pages or less) their project
as they see it, including
its overall audience
and overall goals,
and any possible ethical considerations,
all presented in the team's own words.
You should read the phase description for full details, but
for the goals you should be able to describe at least three
to five
primary goals (ie: significant, high impact, robust features),
and you will identify some secondary goals
(ie: possibly lower impact or lower priority, or whose features
would have less depth)
as well.
You will also decide on the implementation platform from the
provided options of Java or Android Studio or HTML+CSS+Javascript.
This sub-phase's anticipated due date will be by 11:59pm on
February 5th
You will then begin work (right away) on
Phase 1.1.2 where you continue to think about your project option,
potentially updating the pitch, but most importantly writing up
2 to 3 user personas and
4 to 6 full task scenarios that you envision represent some of
the situations in which people will use your system.
In doing this phase, you will be expected to communicate with some
example potential users and/or stakeholders of your system.
This 2nd sub-phase's anticipated due date will be by 11:59pm on
February 12th
In Phase 1.1.3, with this more complete view of your project, each team will work
to create a set of paper prototypes reflecting several rapid iterations
on their ideas, the team's brainstorming on how to support the users,
as well as ideas from some of the example potential users you show
these prototypes.
Teams may choose to request a meeting with their "senior manager"
during this process as well.
This 3rd sub-phase's anticipated due date will be by 11:59pm on
February 26th
In the parallel Phase 1.2, you will
undertake a programming task
which is designed to have the team collaboratively develop something
fairly straight-forward using your team's planned platform.
Please note that each student needs to create part of the full submission
for this, but that you are allowed
to consult with your teammates for help on any technical aspects
of the development platform.
One of the goals is to establish team communication skills
on technical issues and integration of multiple pieces into
a single application submission,
and both will potentially be very important in Phase 2.
This sub-phase's anticipated due date will be by 11:59pm on
February 19th
Phase 2 will have
two related sub-phases.
Phase 2 will be the medium-fidelity prototype implementation,
and should be considered a more coding-centric phase in terms
of time and effort, but still needs to be very user and task centric
and needs to look and feel authentic and visually pleasing.
The end result will be an interactive application
built using Java or Android Studio or HTML+CSS+Javascript
that allows
you to demonstrate the overall look and layout of your system
as well as the successful completion of several important
interactive tasks.
If there are certain features that would require real-time decisions
based on certain contextual information, you can (and should)
still demonstrate these in your prototype via hard-coded sequences
based on a specific scenario. This will allow us to experience the
interaction and flow, and therefore be able to better assess that
feature.
At some point, we might ask for an updated "game plan" detailing
what vertical and horizontal prototype elements you will complete
by the end of Phase 2, how you are sharing the workload, what
your internal timeline checkpoints are, etc.
as well as confirmation of your development platform.
Having such a game plan, even if it evolves during Phase 2, can help
with time management.
As you work on this, you might find your team updating the ideas
in the paper prototypes. This is perfectly fine.
Your team might identify 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). This is also likely to be acceptable
since the goals for this phase are focused on the user interface
and their tasks rather than addressing issues of backend
scalability (which is a valued software engineering issue of course).
Phase 2.1 is best described as the "now go build" part of the
overall project.
The result of this phase needs to be a solid and significant prototype
in both quantity and quality.
While this prototype will continue to be used in the later phases,
this phase is the only opportunity to design and implement the
functional prototype that will be assessed based on the quantity
of interactive features and the quality through the lens of HCI of
those features.
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.
Realistic data and scenarios are an important foundation for a good prototype.
It is important to realize that one of the goals is addressing things like
user-entry challenges. Within the project options, certain restrictions will
exist to remind you that you will need to design and prototype interactions,
and cannot "hand those off" to other systems.
There will be places where teams will "pre-populate" their prototype
with certain information to create the feel of a live system
(for example, based on current and past project options:
current food inventory in the home's refrigerator for a kitchen app,
example recipes for a kitchen app ,
upcoming events for a kiosk,
a weekly office hours table for a kiosk,
the past week or month's worth of exercise data and caloric intake for a health app,
a list of available courses for an advising app
)
and places where certain interaction options might be limited in
the prototype
(for example, again based on current and past project options:
only certain example recipes with "live" data,
only directions to certain example offices,
only certain visualizations based on pre-populated data,
only doing graduation audits on some example profiles
).
Your team will also submit a written report with this prototype.
This report will contain things such as any re-design rationale that
is needed, screenshots showing the "look" of certain aspects of your
project, as well as a list of 5 to 10 solid tasks that can be
accomplished with your prototype (we will use this list as we perform
our grading assessment and it will also be used in Phase 3).
The medium-fidelity prototype and write-up anticipated due date
will be by 11:59pm on
April 9th
However, there will also be at least one time during this
phase where each team will be required to virtually meet with
their project TA to present a progress report and demo of what
has been built up to that point.
Phase 2.2
will be a team presentation video submission about their own prototype
with an anticipated due date of 11:59pm on
April 16th
Phase 3 will
effectively have a single internal phase.
This will be a heuristic evaluation (undertaking one and writing up
the associated report) of another team's Phase 2.2 prototype, as
well as the design of a user study around that prototype
with some form of
pilot run of that study (specifics will depend upon health safety
logistics and rules) with post-study reflection.
This will
have a "suggested" due date of
April 28th
and the actual due date being by 11:59pm on
April 30th
Please note that the report you write as part of this will also
need to be delivered to the team whose prototype you use.
Phase 4 will have
three elements that are due in a single PDF.
You can consider this final phase a set of
"biggest bang for the buck" updates to your prototype
presented via screenshots rather than interactive code,
the formulation of a long-term plan for full development,
and
an "assumptions inventory" related to your app's user
community in terms of what assumptions
you are making about those users in terms of experience, knowledge,
and abilities and which categories of potential users would not be
well-served by this app.
Each team will have gotten much feedback (from both the 434
instructional team as well as your peers) and the goal here
is to demonstrate some "fast but meaningful" changes to your prototype
through a combination of screenshots (potentially generated via
updated front-end code)
showing that you understood the feedback you have received.
Similarly, based on what you have learned from others and from
class material, you will write up a theoretical plan for the next
several months for how you would continue development
towards a real product.
This PDF with your updated prototype's screenshots and write-ups will be due by 11:59pm on
May 11th
|