Beruflich Dokumente
Kultur Dokumente
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.
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.
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.
gets the message across since a person knows to pick which deck and continue to the quiz
page.
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.
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
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.
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.