FinalReport

12/11/2015

By:FarahAlshammari,KateHutchinson,MahaAlkhairy,TiffanyChao

Problem
As a student, people always use Flashcards to helpthemlearninformationformany
different types of classes. Flashcards are a universal tool that descends through all form of
schooling as students prepare to take exams, learn the material before class, etc. Often a
person creates cards and has the choice of asking someone they know to meet up to quiz
each other with the set of intended decks or just to quiz themselves with the shared decks.
Though sometimes meeting up can be difficultnorshouldstudyingrequireapersontohave
to move somewhere else if they do not wish to. The main problem we saw that although
there existed flashcard applications it there was never a feature where two people can test
each other and share decks with one another. We decided to try and tackle the problem of
noninteractivity of flashcard applications and allow two people to connect intwodifferent
placesandquizeachotherandsharedeckswithouthavingtogetphysicallytogether.

Our target audience, though it could be easily used by the general public, are
students ranging from middle school to universitylevel.Allstudentscanbenefitfromusing
such an application. They already use flashcards a lot to study but may lose cards, or ruin
them due to environmental damage. Thier tasks are simple, create flashcards for a certain
topic,whichentailstheideaofa deckforeachtopic.Oncetheycreatealltheflashcardsthey
want to make for a deck they could eithermakemoredeckofflashcardsorquizthemselves
with the finished set of cards. They can also quiz with someone else while acting as either
thetesterortestee.

Design
Our design for our project is simplewithas
littleinformationaspossibletominimize apersons
distraction from the task at hand. We wanted to
have a way for a person to use our application the
samewaytheywouldusereallifeflashcards.

The applications homepage had threemain

tabs that a person can access from the homepage.
Thefirst,thedecktab,isthetabwhereapersoncan
create, remove and edit a deck and their respective
cards. The second, the quiz tab,allowsanoptionof
selftesting or testing with someone else.Thethird,
the friends tab,showsausertheirlistof friendsand
allows you to both delete and add new friends to
the list. The minimal choices given on the
homepage allows a usertogetwhattheywanttobe
done without being confused on where to go to
accomplisheachtaskthattheapplicationoffers.

This page changed the most since our initial design due to comments on our paper
prototype told us that they were confused what to do and howtheapplicationworkedsince
they did not notice the sidebar of options they can
take. Thus, we made the choice to simplify the
homepage just to have the options while moving the
decksintotheirtabthatwasnotonthehomepage.

The decks tab is anewdesignsincethepaper

prototypes but followed a similar design as the
original homepage, as seen above, with options on
how to manipulate the deck(s) on one side while
having the list of decks on another. We made sure
that there we placed the two sides in a natural order
like having the decks on the left since people read
fromrighttoleft.

Moving onto editing deck tabwherea person

can view and edit a deck of their choice. We mainly
kept the same design of the paper prototype. With
The title of the deck sittingonthetopwiththelistof
cards in the center with options on what you can do
to a deck on the bottom. We thought thatthisdesign
made sense it allows you to see the whole deck
before deciding how to manipulate it. Many people understood this design and liked that
they could see all thecardsbeforeseeingtheoptionsonwhattodowiththedeckasawhole
like addanewcard,save,orcanceloperationsonthe
chosendeck.

If a person wants to add or edit a card, they

are shown the sametab.Theonlydifferenceisthatif
they want to editapersoncanseethealreadywritten
text and edit it while a new card they are just blank
textfields.

This page also changed from the paper

prototypes. We had that one side would grow
smaller, andonesidewouldfitthescreen,butnoone
seemed to notice the fact that they could press the
smaller box to go to the other side and enlarge it for
themtoedittheotherside.Wehadtopromptthemto
press the smaller box to edit the second side of the
card. We also took out the options to manipulate the
different text within the text fields since we did not
want to complicate the simple design of the
application.

Next we move to the quiz tab. It is a simple design that has not changed in all three
evaluations since we kept the options the same self and friends for the user to decide
either to quiz themselves or with others. The Designissimplewithnothingtheretodistract
theusertogettotheirdestination.

There are two options fornexttab.Ifapersonpicksselfquiz,theyaretakentoalist

of decks that theymustchooseandthen pressconfirm.Itisagainanothersimpledesignthat

gets the message across since a person knows to pick which deck and continue to the quiz
page.

The selfquiz page only changed in the

aspect that it used to have a complete page that
tells a user that they completed a quiz. A lot of
people thought that the word Try Again made
them think they failed and had to rerun throughit
so we decided that we would just have it loop
through without having the completed quiz page.
Other than that we did not changemuchthoughif
we were to change something, we would add an
option to right orwrongforapersontokeeptrack
of the cards they got right and wrong and
displayedthemattheend. Peopleduringthepaper
prototype did notlikethatitended,andthosewho
tested our softwaredidnotlikethatthequiznever
didor,atleast,knowwhenwe reachedbacktothe
beginning card again. Thus, we decided to would
bring back the complete quiz page with ascoreat
theend.

For the quizzing with others,wekeptwith

the same designs as the paper prototypes since
that was the design that made sense without
making it confusing for the user. Overall we had
the user be able to either continue a quizorcreate
a new one. We set up the page in such a manner
that they saw ongoing quizzesfirstthentheoption
of startinganewone.Wekeptthattabthesameas
the original design since we wanted people to see
ongoing quizzes first before they take notice of
starting a new one in case they already have one
theywanttocontinueoverstartingover.

Even the two person quizzing page, while

a person is active in a quiz either as a tester or
testee, has not changed from the original design.
The change we made was changing the text over
the top of the text fields suchthatitmadesenseto
people. We had it at first as question answer but
realized that some of the decks we had them test
did not fit that convention. It confused them, and
they were kind of stuck on what each siderepresented.SothetextwentfromQuestionto
Shown Side and Answer to What is on the
OtherSide?.

It was important to have the cards they

were testing sitdeadcenterintheviewsincemost
of the time people are most comfortable looking
atthemiddlethananywhereelse.

Finally, we have the friends tab. It is the one of

the only tabs that have not been touched design
wise since the beginning. It has been the same

since we made it. We thought it would be intuitive and consistent if we kept the list of
friendstotheleftandtheoptionstotherightjustlikehowthedeck(s)editortablookedlike.

Implementation
Our group decided to write our application, AskNote, using the Java Swing
framework while using Github as a collaboration tool. Our implementation, at the highest
level, attempts to follow a model view controller (MVC) pattern in order to separate the
visible user interface the view from internal data, which includes the number of decks
and friends associated with a users account, etc and forms the model of our application.
This was an important design decision as we didnt want to end up storing information
about the number of decks in a class designed to display these decks and later run into
problems suchasneedingtoretrievetheinformationfromthisclassbutnothavingaccessto
the data from our current class. From this, we madeourmodelandourviewberepresented
by one class each and used the singleton pattern with each so that we could make them
accessibletoanyotherclassesintheproject.

We also decided, around the same time,tohaveeachofourpagesberepresentedby

its own class that extends JPanel that we would then switch between in the view thus
making which page the user is currently on part of the model. Each of these pages would
include its own event handling and access the model class to update any relevant
information, including the current page if the user action resulted in switching to a new
page, and then tell the view classto updatewhatisshowntotheuser,Wedecidedtohandle
keeping track of the current page in the model bycreating anenumwhereeachpagehasan
associated value that is then recorded in the model the only otherchoicewecouldthinkof
was to store the panel itself, which, aside from being majorly data intensive, would have
causedcomplicationswhenweneededtohideonepageandswitchtoanother.

Many of the problems with implementing our application had more to do with our
lack of familiarity with the Java Swing framework thananymoreseriousissue.Thelackof
familiarity with directly implementing Swing, another decision made that was necessitated
by our decision to use an MVC pattern and tohaveseparateclassesfordifferentpanelsand
switch between them, made it so that it tookusmuchlongertocodeasinglepagetoevena
semblance of what it looked like on our paper prototype if we even managed that. This
meant that we were less likely to have time to focus on smaller detailsthataffectusability,
like getting the ordering of the words in a dialog box to be externally consistent by saying
yes or continue before no or cancel, since the default setup in Swing has them in the
opposite order. The time it took to complete this portion oftheapplicationalsoreducedthe
time we hadtoimplementchangesthattestingsuggestedbeinplace,whichcertainlyhadan
impactonusability.

Evaluation

In order to improve our product in its various stages, we conductedtwousertesting

and got heuristic evaluations from our classmates. During thefirstroundofusertesting,we
were able to test the paper prototype on6participants.All6participantscompletedthetask
we gave them successfully in less than 5 minutes. In this round of testing, we learned that
the home page of our software was confusing because we had the decks panel and the
buttons on it in particular, the users were confusedwhethertheyshouldclickonthe deck
or the quiz button to start a quiz from the home page [visibility]. The last problem wasthe
some of the wording/icons on our buttons were confusing to the users in particular, they
noted that they did not understandwhattheiconforflippingtheflashcardstoodforandthat

saying try again on thebuttonaftercompletingaquizconfusedthemandmadethemthink

that they did poorly in the quiz, which was not the case [speaking the users language]. In
order to fix those problems, we decided to eliminate the decks view in the home page to
avoid the user confusion at the start of the application. In order to improve our button text
and icons to let the users better understand thefunctionality,wechangetheiconfortheflip
buttontotextflipandchangethebuttontryagaintoredo.

The second round of testing was on our first software prototype through heuristic
evaluations from our peers in the class. The heuristic categories that we had problems in
were internal and external consistency, feedback, speaking the users language, error
prevention, feedthrough, and help and documentation. The main problems such as error
prevention and speaking the users language were improved upon by adding confirmation
dialog boxes intheappropriateplacesandadjustingthewordingtomatchthepurposeofthe
message/text. Furthermore, we were abletoimprovesomeexternalconsistencyissueswhen
we added icons to the software prototype, in particular, the single letters on the buttons in
thehomepanelwhichindicated tosomeusersthattheycouldaccessthebuttonfunctionality
by pressing the corresponding letter on the keyboard, which was not the case. Another
aspect that was improved when adding the icons was internal consistency since the text on
some buttons were capitalized and other were not. We were not able to address feedback,
feedthrough, and help and documentation. To address the feedback and feedthrough, we
needtoimplementthebackendwhichwehavenotdoneduetotimeconstraints.

The final round of testing was user testing on the updated version of our software
prototype based onthehelpfulcommentswegot fromtheheuristicsevaluations.Inthisuser
testing, we were able to get 5 users, who arestudentswiththeaverageageof21,totestour
software prototype and all 5 userscompletedthethreetaskswegavethemsuccessfully.The
main problems that the users pointed out were feedback, feedthrough, efficiency of use,
minimizingusermemoryload,speakingtheuserslanguage,andhelp&documentation.

The particular issues in terms of efficiencyofuse arenotbeingable tosimply press

the tab key when editing the flash card to move from one text field to the other, not being
able to create new flashcards without going back to the deckviewerpage,notbeingableto
double click the deck to view it without needing to editit,notbeingabletodoubleclickon
the deck and cards to view it without having to edit it, not having a shortcut to the quiz
page the decks viewer page, not being able to begin a quiz with the already selected deck,
not being able to quiz ones selfwithoutbeingabletoflipthecardtoavoidcuriouslooksto
the hidden side. The particularissuesinfeedbackandfeedthroughweresimilartotheissues
that were indicated in the heuristic evaluations which are not being able to view the cards
created after saving them in the deck for the first time. For minimizing user memory load,
the users wanted to be able to to keep track of right or wrong answers when conducting a
selfquiz and to know if they quizzed themselves on all the cards that wereinthedeck(the
reason behind that is thatthe cardsareloopingwhenquizzingonesselfandwenever reach
an ending panel) . In terms of help & documentation, some thought that the application
dependedonapersonhavingusedasimilarprogrambefore,another saidsomehelppointers
should come up if a user has not done anything for a certain amount of time, icons require
previous knowledge of computer run applications. We are not speakingtheusers language
whenwehavesavedprogressdialogboxespopupwhentheydidnotchangeanything.

In order to improve efficiency and feedback, we would fix the edit deck viewer by
autosaving a deck once a card has been saved into the deck, as well as showing the most
updated and recent version of the deck and cards without having to exit and reenter, and
add a key event handler that would enable the users to use keyboard shortcuts.Toimprove
help & documentation, we would add tooltips to buttons for the user to know what the
button does exactly. To improve upon minimizing the usersmemoryload,wewouldadda

quiz completion page that allows a user to restart the quiz or go back to the homepage,
whichshouldalsogiveascoreofthenumberofcardstheusergotright.

Reflection
We wouldhavelikedtouseaGUIbuilder,suchastheoneprovidedbyNetBeans,to
quickly draft the look of our application without getting bogged down in specifying exact
parameters with code.However,sincetheNetBeansGUIbuilderdoesnotallowadeveloper
to edit parts of the generated code, we chose to create thepages ofourapplicationfromthe
ground up to exercise freedom over editing our source code, and to better enforce the
modelviewcontroller architectural patternthatwedecidedtofollow.Thisdecisiondidcost
us time that could have been spent working on additionalfeatures,aswespentalotoftime
wrangling with Swing layout managers to display components as intended, writing
initialization code simply to instantiate components, and more. If we could tackle this
project again, we should ideally select another GUI builder, perhaps in another
programming language, that would allow ustoeditgeneratedcode(thisGUIbuildershould
give out warnings if an edit would break the code) to enforce architectural patternsthatwe
want to follow. Then, we could quickly draft the look of individual pages with the GUI
builder, then move on to implementing event listeners and additional features earlier on in
thedevelopmentprocess.

At the start of this project, we wanted to add more features such as notifications to
alert a user that he/she has received a request from a friend to start a quiz, etc. and an
achievement system suchasadding additionalcolorsandborderdecorationstoflashcards to
motivate a user to continue using our application. We decided that the achievementsystem
was nonessential for our initial prototype, and so did not attempt to incorporatethisfeature
into our prototype for this course. We planned to include the notifications feature since we
decided that this feature was integral to maintaining clear communication between users,
providing system feedback, and providing information about the current status of the
application. Unfortunately, we ran out of time and did not incorporate the notifications
feature into our application. Again, if we could tackle this project again we should budget
our time accordingly, and set aside a week or so to decide how to implement notifications
andthenwritethecodeitself.