Gnotes: A Novel Solution

Gnotes: A Novel Solution Nate Leibolt: Suggested changes to website for TA07, wrote code, developed, tested and suggested ideas for prototype in TA08. Wrote and compiled Sections 1, 2 4, and 5 in TA09, acted and wrote script for TA10. Assigned the role of checking over the report for TA09, spearheaded TA09 Paige Nelson: Created and edited website for TA07, wrote code, developed, tested and suggested ideas for prototype in TA08. Wrote section 8 for report for TA09, acted in and wrote script for TA10. Spearheaded TA07 Todd Lees: Suggested changes to website for TA07, developed much of the prototype for TA08, wrote section 2 of report for TA09, wrote script for TA10. Spearheaded TA08 Kat Tomczak: Suggested changes to website for TA07, wrote code, developed, tested and suggested ideas for prototype in TA08. Wrote Section 7 of the report for TA09, acted in, wrote script, and created video for TA10. Spearheaded TA10 Section 1: Abstract Gnotes is a web-based application designed to aid users in taking notes on novels.
While the primary target audience will be students who are studying literature in school,
Gnotes can be used by anyone who wants to organize notes about novels, stories, TV
shows, movies, or even their own lives. The application will support creation of notes in
in a variety of forms (including character graphs, timelines and textual notes), searching
for notes created by other users of the site, and managing/organizing your own
collections. In evaluating our three primary tasks, we chose to test our prototype on
undergraduate students at the University of Maryland by assigning them written-out tasks
to complete using our prototype. After presenting these students with surveys, timing
them for completion of tasks and measuring the number of mistakes they made while
running through the application, we were able to deduce that users were generally
satisfied with the concept and design of the application, although there were a few
suggestions for improving organization and adding functionality (such as emphasizing
the “Create New Note” button, and adding the ability to put photos/images in the
elements of notes). As a result, because the design of Gnotes was generally well
received, the next step in the process of developing Gnotes would be to first resolve the
common criticisms and to then turn our attention to implementing new functionality.
Section 2: Prototype Implementation Our prototype was created using ActionScript3 with Flex, a software development
kit for Adobe Flash-based applications, as a UI framework. The code was developed
using a model-view-controller development strategy. Flex was chosen because a member
of our group had previous experience using it to build web applications, because other
members of the group felt comfortable learning the language, and because Flex has all
the elements necessary to implement a prototype implementing the three tasks of our
application. Flex is also fairly high level, making it easier to learn and faster to learn than
alternatives, although we do acknowledge that one drawback to learning and developing
in Flex is that fewer and fewer platforms in industry use it. No outside libraries were
used in the development of the application.
In terms of the process of building the program, additions and changes were tested
right away, first for debugging to make sure they worked, and then for design, making
sure there was good spacing and good control flow in the application. Given that much
of the first part of the semester’s lectures and assignments were dedicated to discussing
brainstorming, sketching and rapid prototyping, it was firmly ingrained in our group that
many iterations and tests during development would be crucial not only for coming up
with a working product, but with a product that had been approached in multiple ways.
One example of where rapid overhaul of the design based on testing came within our own
group during development: one of the group members had implemented part of the search
with the search button towards the left of the screen, and when the other members of the
group tried using it, each felt that the button should go in the more familiar bottom-right
position of the page.
This was just one, seemingly innocuous, design flaw of many that was corrected
by testing within the group during development.
Much of the design of the application was based on lectures from class or from
reading, especially Universal Principles of Design by Lidwell, Holden and Butler. This
text mentions alignment and similarity as two key concepts in design, which our group
took to heart in designing our application. Alignment in design refers to “the placement
of elements such that edges line up along common rows or columns” which can act as a
“powerful means of leading a person through a design” (Lidwell…). In our application,
our intention was for the navigational menu bar at the top of the application to encompass
this notion of alignment. Because the three options on the menu (Profile, Collection and
Search) are aligned to be on the same row, the user should know that it is by way of this
menu bar that they traverse through the different aspects of the application. The main
menu bar highlights the concept of similarity informing design: each of the options is part
of the same red background and each is the same size and has the same typeface.
According to Universal Principles of Design, the grouping of similar elements “reduces
complexity”, and establishes in the mind of the user that all the elements are related (in
this case, these elements are the navigation options to access different areas of the site).
For the search aspect of Gnotes, we decided to use a grid-based system based on
discussions in lecture on how modern designs are often grid-based and due to the fact that
we wanted Gnotes to have a modern feel.
Unfortunately, there were features that were left out of this version of the
application that we had previously hoped to implement. One of these, the ability for the
user to rate others’ notes, went hand-in-hand with another, the implementation of actual
user profiles, and the ability to publicly share notes over the web. Due to time
constraints, our prototype was developed to be an offline representation of what Gnotes
would look like if fully implemented, so it was impractical to support any sharing ability
between different users, or even support a user profile. One piece of functionality that we
later learned many of the user-testing subjects requested was the ability to put images in
the note elements for character graphs or timelines. This too, along with the image
search that would be required, would have required Gnotes to be online.
Section 3: Task Descriptions Our three primary tasks are creating, searching, and managing. As a note-taking
tool, the main function is creating new notes. Searching for notes publicly shared by other
users was also something we thought important, since the community aspect of GNOTES
was intended to ensure the spread of ideas and the cooperative learning that is possible
among a study group or a class of students. Lastly, the third task we focused on was the
user being able to manage and sort both their own notes, and notes that they added to
their collection that they found by searching. Being able to sort notes is key because the
user will need to be able to access notes not only according to what novel they are about,
but also what part of the novel they pertain to, and even what format of notes they are.
Creation
Creation involves producing and editing graphical notes. The user must initialize
a new note with a particular template, such as a timeline, character graph, or family tree:
They then populate the notes in the note editor by using the appropriate tools designated
for each template:
All elements stay editable during the creation phase, facilitating non-linear development:
Searching
Searching is the means by which users can acquire new notes from others. To
improve the relevance of the results, filters on note types and sources may be employed
(notice the pull-down menu for the filters in the image):
For instance, a search could be restricted to a single template type (character
graph, timeline, etc.). Results could be ordered based on ratings, or relevance to books
and groups the user is associated with. The user then browses the provided notes to find
what suits their needs. If the search fails, they may try different search criteria:
Management
Management refers to the organization and distribution of notes. As soon as notes
are complete, they can be saved from within the notes editor.
Outside the editor, notes can be accessed, organized, and modified from the
Collections page.
One method of organization is creating and moving notes to different folders,
represented by tabs. Users can create new tabs for notes based on how they want to
organize them. Public notes can be added from search results to the user’s collection for
reference. In the following images, you can the process for this involves:
Creating a new tab:
Then moving the note to the new folder:
Now the saved note is in the new folder:
Differences between the tasks in this final prototype and previous iterations
included the omission of the user to be able to rate notes (even though we still displayed
where ratings would be shown on icons in this prototype), and a change in the name of
one of the screens from “My Notes” to “Collections”. This change was made because we
wanted the user to be able to access and organize notes created by other users, not just
notes that they had created themselves.
Section 4: Usability Tests Pilot Testing Within the Group: As developing wound down, some of our group began formulating the study plan
that we would first use to test the prototype on ourselves and then use for user testing.
The study plan included completing tasks that encompassed the three tasks we
implemented in the final prototype (creating, searching for and managing notes), and as
we came up with possible instructions to complete the tasks, we discovered that the
“management” task didn’t have that many directions associated with it. We were
concerned that having the user simple create a new folder would not demonstrate the task
to its full potential, so late in the stages of development, we changed the task list include
moving the note to the newly created folder, then opening the note. The prototype had to
be changed as well to support this functionality. Another change to study plan late in the
process was adding a measurement to the analysis, namely asking the user to specify on a
scale of 1 to 10 how useful they thought the prototype was. After the study plan had been
written, a pilot test was conducted where one member of the group ran through the
instructions to complete the tasks and another user kept track of how long it took to
complete the tasks to make sure the user tests would not take too long.
Participants: Three University of Maryland students agreed to be part of the user testing for
Gnotes. We recruited these students by joining up with two other groups from CMSC
434 and exchanging member to test prototypes on. Two of our users for the testing
sessions were recruited in this way. The last student was recruited as a friend of a
member of the group who had no experience in HCI. However, because this last user
majors in Computer Science at UMCP, we hoped he could add another dimension to our
user results as someone who is experienced with computer applications, but didn’t
necessarily have the same background in lectures and readings on good UI design. The
following table shows the relevant demographic information of the users we tested,
gathered via a pre-testing survey that was given. For the “level” of computer
demographic that the users provided, the users were told that a Level One computer user
has never seen a computer, and a Level Ten user is “extremely proficient”.
Participant Age Profession 1 to 10, level of
computer user
Personally would
consider using a web
app to take notes
Participant 22
1
Student
8
Yes
Participant 22
2
Student
10
Yes
Participant 21
3
Student
9
Yes
Table 1: Participant Demographics
Study Method: To conduct the study, our group met the test users in a classroom in the CSIC
building in the University of Maryland. Each user was read an introduction, thanking
them for participating them in the test, explaining what Gnotes was and how we would
conduct the test, and finally, asking them if they would look over and sign the IRB
consent form. Because each of them agreed, each signed the form, and the testing began.
Each test was video-recorded using a smartphone, and time was taken using the time
stamps on the recorded videos. Tests began with users being asked to fill out the pre-test
survey. After the surveys were complete, users moved on to complete the tasks one by
one, with errors being noted by our group’s note taker for each session, and timed by the
video recorder. Finally, after all of the tasks were completed by the user, the user filled
out a post-test survey that included questions that provided our group with numerical
data, as well as qualitative feedback.
Analysis: The data that were analyzed in this study were: all of the pre-survey data, the
length of time it took for users to complete the tasks, the number of errors that users made
when testing the application, the satisfaction of the user with Gnotes represented as a
number between 1 and 10, and qualitative feedback from the user which gave them a
forum to reflect on how they performed and express their favorite and least favorite
aspects of the application. Any numerical data was recorded, and qualitative feedback
was read through and considered in analysis as well.
Section 5: Results from User Testing All of the users in user testing were students at the University of Maryland,
College Park, they were all either 21 or 22 years old, and each indicated that they would
consider using a web application as an aid for taking notes. The average “level” of the
user coming into testing, based on responses in pre-survey data, was nine (very close to
“extremely proficient computer user”). Thus, the results of our user testing reflect the
interaction between the Gnotes application, and young, computer proficient student users.
The following table displays numerical data collected during testing.
Participant
Time to
complete
tasks
Number
of errors
Satisfiaction with Gnotes (on a
scale from 1 to 10)
Participant 4 mins 14 secs
1
3
7
Participant 4 mins 2 secs
2
2
8.5
Participant 4 mins 42 secs
3
3
8
Table 2: Numerical Data from User Testing
An “error” was recorded when the user either attempted to do something that was
not in the instructions for the task list, forgot to attempt a task, or had to ask for help in
completing a task. All of the users completed the tasks between four and five minutes
into testing. There was an average of 2.67 errors per user, and the average satisfaction of
the user with notes at the end of testing was 7.83.
Examining the qualitative feedback that users provided in their post-testing
surveys, some criticisms that we received included that the application felt empty, that it
was unclear what the difference between circle and square elements in note creation was,
that it was difficult to find functionalities for creating notes and moving notes to new
folders, and that there was no functionality for adding images to note elements in note
creation. Our group agreed with this last point, as it was our original intention to provide
users with the ability to add images to notes, but time constraints limited us in pursuing
this. In order to clear up confusion about creating and moving notes, we later changed
the prototype to have a more explicit and visible “Create New Note” button. Users
generally agreed that the site had a good layout for each screen design and that the site
was easy to navigate.
Section 6: If We Had To Do It All Over Again… This project heavily benefitted from iterative design, and both the primary tasks
that we identified and the general direction and purpose of the application were honed
and improved after each design stage. Without multiple iterations of improvements and
changes, and then testing these changes on users, the purpose of our project might still be
vague and our implementation might be nonexistent, as we were not even sure what
functionality our application should have at the beginning. As was discussed both in
lecture and in the readings, it is crucial to consider many options in the beginning of the
design process so that it is more likely that the best idea will be found. In addition, it is a
good strategy to rapid prototype designs with quick sketches so that designers don’t
become too attached to one design that required effort and care. Our group encountered
these tenets during the process of sharing sketches, as many different designs were
brought to the table, and the variety of options allowed us to select the best design.
One thing that we would have done differently, as a group, would have been to
develop a mobile-based application instead of a web-based one. In terms of design, a
web-based application matched up well with our project, but given the constraints of this
class, it would have been more practical to narrow down our tasks and perhaps be a bit
less ambitious. While a searching tool would definitely benefit the user, it was quite
tricky to implement in the final prototype, and much of the functionality of this task had
to be simulated. What might have been a better goal during the course of the semester is
to break the creation and management tasks down further and use those as our three tasks.
Given that our plans were even more ambitious at the beginning of the design process
(we wanted to implement a system of user-sharing, privacy setting, rating systems and
public displays of “best” notes on the site), it would have been disastrous to start coding
even simple designs early on because many would have had to be scrapped.
Section 7: Video Making Process The film was edited in Windows Movie Maker. Some audio editing was done in
Audacity. The screen recordings were done using Fraps. The software choices were done
out of convenience. The software was already installed and one group member already
knew how to use them. The initial intent was to do the editing in Adobe Premier, but
learning how to use the software would've been too time consuming.
We knew we wanted to do a skit, but didn't want it to be super serious. We hoped
to make the acting look intentionally bad. We also knew that doing over-the-shoulder
shots of a screen doesn't show much detail, so we knew we'd need to zoom into a screenrecording to really show how our product works. We didn't do the screen captures while
filming since the application wasn't entirely finished. The screen recordings had to be
filmed at a later date and with a different narrator, since syncing the screen recording to
the voice-over narration was difficult.
Section 8: Project Webpage Making Process TA07 Report below: TA07 Report
Todd Lees-Contributed ideas, suggested improvements for site
Nate Leibolt- Contributed ideas, suggested improvements for site, Edited
report
Paige Nelson- Created website and wrote report
Kat Tomczak- Contributed ideas, suggested improvements for site
Section 1: Work Process The design of this website was inspired by the single scroll web pages that are
pretty common nowadays. This sort of layout is useful when the website is purely
informative and does not require much interaction.
Another substantial source of inspiration was from the Twitter Bootstrap
“jumbotron” template. This template involves a large image spanning the top of website
that take up a large amount of screen real estate with the site is first viewed. This sort of
layout is very common in modern websites and really captures the viewers attention.
Nearly every website we browsed through when searching “beautiful web design” on
Google involved a way to capture the user’s attention when the site is first viewed, and
then having all other relevent information off to the side. The combination of using
Twitter bootstrap and a single scrolling page was easy to do and provided the opportunity
to create a really beautiful webpage.
Section 2: Description/Critique of Design Layout Many of the design principles discussed in class were used in the layout of the
site. And approximate golden ratio was used to display information for the “About”
section and the “The Team” section.
Meanwhile, the rule of thirds was used in defining our three tasks, create, search, and
manage, which great aesthetic appeal.
Additionally, a grid is used to format the links to the team assignments. Using images for
the team assignments in this grid layout makes them more appealing than just listing the
links.
Font A variety of modern fonts were used for the sites. These fonts varied in weight
and appearance to provide contrast between the various headers and the paragraph text.
The fonts used for the headers included Amaranth and Signika, while the font used for
paragraph text was Rosario. Bolder, larger fonts distinguish the header text from the very
readable paragraph text.
Color We used a monochromatic color scheme for the site. The color we chose was a
bright salmon. We chose white for the main background color on the sites, which gives a
clean, simple feel. The white background also allows for nice contrast between the
salmon color and the font. The font color is a very dark grey, which isn’t as harsh as
black, but still provides great contrast.
Appendix for Section 8: Sites viewed for Inspiration:
http://webdesignledger.com/inspiration/30-fresh-and-beautiful-web-designs
http://designinstruct.com/visual-inspiration/web-design-inspiration/minimalist-websitedesigns/
Code and guidance from:
Twitter Bootstrap: http://getbootstrap.com/2.3.2/ (basic template for the page layout)
Untame.net: http://untame.net/2013/01/how-to-design-a-single-page-scrolling-site-withtwitter-bootstrap/ (Single page scrolling with the navigation bar)
Appendix Appendix A: Study Plan Study Plan
Introductory Content:
Thank you for your participation in this user test session for the Gnotes prototype.
Gnotes is a web-based application designed to aid users in taking notes about novels,
movies, stories or even real world events. With your consent, we will video-record you
interacting with the prototype in order to accomplish a set of tasks that we will provide.
If you agree to this, we will now present you an informed consent form. Do you agree?
Task Descriptions:
Create:
• Open the creation workspace
• Create a character graph with at least 2 elements and their relationships from your
favorite book (use a line to show the relationship)
• Delete one of the elements
• Save the note
• Go back to the main screen
Manage:
• Find the note you just created
• Make a new tab for recently created notes called “Recent”
• Move the note you just created to the new tab
• Open the note
• Return to the main screen
Search:
• Search for a note called “Lord of the Rings”
• Open the note
• Add the Lord of the Rings notes to your Collection
• Return to the main screen
Data we plan to collect:
• How long to complete
• Number of errors
• Satisfaction based on a 1-10 scale
• User proficiency based on a 1-10 scale
• User reactions/suggestions (qualitative data)
Instruments:
• Stopwatch
• Camera
• Paper Surveys
User Survey Questions:
Pre-­‐Testing Demographic Survey: 1. How old are you? 2. What is your profession? (“student” counts as a profession) 3. On a scale of 1 to 10, with 1 being someone who has never seen a computer, and 10 being extremely proficient user, what level of computer-­‐user are you? 4. Would you ever consider using a web application as an aid to taking notes? Post-­‐Testing Evaluation Survey 1. What are your overall impressions with the application? 2. Do you think the three tasks that were shown (creating, searching for and managing notes) were appropriate as the main tasks for this application? 3. Did you have any problems completing tasks, and if so, which ones? 4. What was your favorite thing about the application? 5. What was your least favorite thing about the application? Appendix B: Raw Notes User 1: The image cannot be displayed. Your computer may not have
enough memory to open the image, or the image may have been
corrupted. Restart your computer, and then open the file again.
If the red x still appears, you may have to delete the image and
then insert it again.
User 2: The image cannot be displayed. Your computer may not have
enough memory to open the image, or the image may have been
corrupted. Restart your computer, and then open the file again.
If the red x still appears, you may have to delete the image and
then insert it again.
User 3: The image cannot be displayed. Your computer may not have
enough memory to open the image, or the image may have been
corrupted. Restart your computer, and then open the file again.
If the red x still appears, you may have to delete the image and
then insert it again.
Appendix C: Post Survey Responses User 1: The image cannot be displayed. Your computer may not have
enough memory to open the image, or the image may have been
corrupted. Restart your computer, and then open the file again.
If the red x still appears, you may have to delete the image and
then insert it again.
User 2: The image cannot be displayed. Your computer may not have
enough memory to open the image, or the image may have been
corrupted. Restart your computer, and then open the file again.
If the red x still appears, you may have to delete the image and
then insert it again.
User 3: The image cannot be displayed. Your computer may not have
enough memory to open the image, or the image may have been
corrupted. Restart your computer, and then open the file again.
If the red x still appears, you may have to delete the image and
then insert it again.
Bibliography William Liddell et al. Universal Principles of Design : 125 Ways to Enhance Usability,
Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach
Through Design. Rockport Publishers, Beverly: 2010