Saturday, November 29, 2014

Week 13 Update

This Week

This week, we completed the testing analysis, which describes the results that our team got from last week's activity. We split the analysis up into sections for each team member to do on a Google Drive file. The analysis contains the data gathered from the testing (such as the participant information and the testing metrics), as well as correlations, analysis, and conclusions based off of the data.

Overall

Task: Testing Analysis
People Involved: All team members
Hours: 1-2 hours per member

Next Week

Next week, we will be updating and making changes to our program based on the results of the testing analysis and then releasing it. We will also create a presentation of our project as well as the testing results and analysis, to be presented in front of the class.

Challenges, Risks, and Issues

Challenges

Because of the extreme difficulty of the level five problems (which only one participant not giving up), our test results were heavily skewed. This made it challenging to write an accurate analysis.

Saturday, November 15, 2014

Week 12 Update

This Week:

This week our team has worked on user testing. We split into two teams of two and conducted user testing on various test subjects, according to the format outlined in our test plan. Each team initially welcomed and briefed the participant and had them sign a consent form. The participant then filled out a pre-test survey. Following that was the actual testing of the product using our four previously defined HTAs (Hierarchical Task Analysis). Finally, the participant completed a post-test survey and was thanked for their participation. During the core testing, our two team members kept detailed notes including time to complete each task and number of positive or negative statements. Through all of this testing we gathered a lot of interesting information which we look forward to analyzing next week.

Overall:
Task: User Testing
People involved: All team members
Hours: 2-3 hrs per team member

Task: Start User Testing Analysis Document
People involved: Conor and Danielle
Hours: 0.5 hr each

Next Week:

In the next week we are going to be analyzing our user testing results and refining our design based on that analysis. We expect the analysis to take approximately 2 to 3 hours per team member, with all team members participating. We expect design refinement to take an additional 2 to 3 hours per member.

Challenges, Risks, and Issues:

Challenges: 

A challenge recently has been to gather a diverse group of users for the user testing. Our team ended up with participants of less diversity than desired, which may impact results.

Risks: 

As mentioned in the challenges section, one risk recently is that our user testing base is not diverse enough and will skew results. Another risk related to testing involved one of our tests being too difficult, resulting in many participants skipping through that particular test. This has a very obvious affect on our data. Our team is debating whether to remove the test, redo testing, or leave the data as is and include detailed write up analysis on the results.

Issues: 

The only notable issue recently is the faulty test, as mentioned in the risks section.

Sunday, November 2, 2014

Week 10 Update

This Week:

This week a lot of the usability errors that were found during the heuristic evaluation. Thanks to our use of the functional prototype we got really good feedback and all comments were made on a product that could be the final user interface with some polishing.

We have been focusing on getting ready for the actual testing and team members have been trying to get more users to include in our testing plan.

Overall:

Task: Readme/Product prototype release
People involved: All team members
Hours: .5 hrs per team member

Task: Product
People involved: All team members
Hours: 0.2 hr per team member

Next Week:

Next week we will need to focus on finalizing the users, and making sure that everything is ready before we test. Also, it will be important to get the login system done before we test so we can get feedback on it.

Challenges, Risks, and Issues:

Challenges: 

Our team has been finding it extremely difficult to find users. Due to our app being applicable to anyone from the ages of 5-18 we have a large range of both computer and math competence. We realize that we will only be able to test on a limited subset of our users, but still worry about complete user demographic coverage. Unfortunately due to the current situation (being in college) of all the members on the team, we don't really know anyone from the area that is in our user demographic.


Risks: 

We are still encountering the same risk as last week, where as the semester is speeding up team members may re-prioritize classes/other activities ahead of this project. This is still being mitigated by getting early starts on deliverables and continuing to have weekly team meetings regardless if the deliverable is due that week.
An additional risk arises because of two main factors - team members are becoming busier and more focused on other classes and projects, and we are completing work for this project more and more on an individual basis. We run into a risk that a section of some document may reference a new or updated feature or design that the rest of the team is unaware about. We are attempting to mitigate this by finding time to read or glance over each others sections and putting personal responsibility on updating others if an issue arises.

Saturday, October 18, 2014

Week 8 Update

This Week:

For the past few weeks we have dedicated our time to starting the development of our product and the creation and design of our test plan. The product's development has come off to a good start and has a great deal of functionality that was laid out in our design. A lot of this is due to our functional prototype being the base of our implementation.

The initial test plan draft has been finished this week. We don't believe that there will be much change needed before our testing begins. For test subjects we hope to have at least one subject from each user type we have laid out in the testing plan. Our initial task scenarios were not designed correctly and needed refactoring, but that has since been resolved.

Overall:

Task: Test Plan
People involved: All team members
Hours: 2-3 hrs per team member

Task: Product
People involved: All team members
Hours: 0.2 hr per team member

Next Week:

In the next weeks we will be preparing for actual testing of our product and use of our test plan. We will bring the test plan draft to a completed state and finish development on the product into a beta version. As part of our preparation for the testing of our product, we will be seeking test subjects, particularly those of our defined user types.

Challenges, Risks, and Issues:

Challenges: 

Our team has found it challenging to continue to refine the prototype and keep ahead of deliverables for this project. We have not had issues with it yet, but there has been significant effort to keep driving forward on the project as the semester progresses. With limited time in each of our busy schedules, we have each had to increase our attention to time management. We also believe that there will be issues with finding test subjects that fall into our user types, but we are hopeful and at worst we can get them for an online test. Unfortunately we won't be able to monitor them from within the same room, but this can be remedied thanks to video chat via Google hangouts.


Risks: 

We are still encountering the same risk as last week, where as the semester is speeding up team members may re-prioritize classes/other activities ahead of this project. This is still being mitigated by getting early starts on deliverables and continuing to have weekly team meetings regardless if the deliverable is due that week.
An additional risk arises because of two main factors - team members are becoming busier and more focused on other classes and projects, and we are completing work for this project more and more on an individual basis. We run into a risk that a section of some document may reference a new or updated feature or design that the rest of the team is unaware about. We are attempting to mitigate this by finding time to read or glance over each others sections and putting personal responsibility on updating others if an issue arises.

Issues: 

[still no significant issues encountered thus far]

Saturday, October 4, 2014

Week 6 Update

This Week:

In the past weeks, our team has continued to refine our prototype and have been working the the design document for the product. The functional prototype has come along very nicely and has an estimated 75% of the functionality we've outlined. A user is able to select difficulty levels and topics and have them updated in the questions, as well as answer questions and receive feedback on their answers (whether they were correct or not). Other functionality/features our team had discussed but are not implemented yet include a help section, as well as statistics for users. 

The design document has been completed this week and includes information on the program structure, design rationale, a detailed description of the user interface as well as design principles followed, interface design rationale, and screenshots of the current prototype. All team members took sections and completed them for this effort. Work on the design document accounted for the majority of the work our team members did this and last week.

Overall:
Task: Design Document
People involved: All team members
Hours: 2-3 hrs per team member

Task: Functional Prototype
People involved: All team members
Hours: 0.2 hr per team member

Next Week:

In the next weeks we will be preparing for heuristic evaluations on our prototype by our classmates, as well as looking forward to user testing afterwards. We will also be developing a beta version of our application. In total we estimate developing a beta application will take 4 hrs per team member with all team members involved. Doing heuristic evaluations for other teams and incorporating the feedback we receive into our application will take an estimated 1-2 hours per team member with all members involved.

Challenges, Risks, and Issues:

Challenges: 

Our team has found it challenging to continue to refine the prototype and keep ahead of deliverables for this project. We have not had issues with it yet, but there has been significant effort to keep driving forward on the project as the semester progresses. With limited time in each of our busy schedules, we have each had to increase our attention to time management.

Risks: 

We are still encountering the same risk as last week, where as the semester is speeding up team members may re-prioritize classes/other activities ahead of this project. This is still being mitigated by getting early starts on deliverables and continuing to have weekly team meetings regardless if the deliverable is due that week.
An additional risk arises because of two main factors - team members are becoming busier and more focused on other classes and projects, and we are completing work for this project more and more on an individual basis. We run into a risk that a section of some document may reference a new or updated feature or design that the rest of the team is unaware about. We are attempting to mitigate this by finding time to read or glance over each others sections and putting personal responsibility on updating others if an issue arises.

Issues: 

[still no significant issues encountered thus far]

Friday, September 19, 2014

Week 4 Updates

This Week:

These past two weeks, our team has made a lot of progress on the project. Besides having our weekly team meeting as necessary, our team has completed a Software Requirements Specification, done Hierarchical Task Analysis, created prototypes, and started programming the application.

The Software Requirements Specification (SRS) contains a variety of project-relation information, including but not limited to an analysis of the domain problem and stakeholders, features, task analysis, and functional/nonfunctional requirements. The team divided the document for work, and completing the sections took a total of around 4 or 5 hours per person. 
In addition, a hierarchical task analysis (HTA) for system features was completed to be included in the SRS. These took around a half hour per person. 

As a final portion of the SRS, our team created a prototype during one of our weekly meetings. The wireframe shows the primary view, displayed when a user navigates to the site. You can see the prototype below contains a left panel for the user to select subjects and difficulty, a large upper-middle panel to display the current flash card problem, and a place to answer then submit the answer for validation. If we were afforded a chance to expand upon this concept in the future, we could consider a new design model that would allow users to modify difficulty for each selected subject. As of right now, however, that functionality would be out of scope and could be added as an extra feature later as time permits.
Finally, Zach has made the time to start up writing the application, and has made very significant progress on it.

Overall:
Task: SRS
People involved: All team members
Hours: 4-5 hrs per team member


Task: HTAs
People involved: All team members
Hours: 0.5 hr per team member

Task: Prototype
People involved: All team members
Hours: 1 hr per team member (working together during meeting)

Task: Start of Code Base
People involved: Zach
Hours: 4

Next Week:

In the coming week, we will be starting work on the Design Document and Conceptual Prototype for the project. We estimate very roughly that the design document will take 3 hours per team member, and the conceptual prototype will take 2 hours per member. We expect all members will be involved working on the two deliverables.

Challenges, Risks, and Issues:

Challenges: 

Our team had the challenge early in the project to coordinate a weekly team meeting time. Although we had to resort to meeting virtually on weekends and talking in person during/after classes, our team has adjusted very well to the unusual meeting schedule. Team members have been effective in efficiently completing deliverables.

Risks: 

There is a risk that as the semester progresses, team members may be unable to attend meetings or may fall behind on deliverables. To mitigate this, we have been attempting to start deliverables as soon as possible to allow for maximum time for completion.

Issues: 

[no significant issues encountered thus far]

Wednesday, September 3, 2014

Flash Math: A mathematical flash card quiz game

Target: K through 12 students who need extra academic help
Domain: Web Application

Users can either navigate to the web app and use the application as is, or create an account (with parental approval) and sign in for additional features. Without an account, students will be able to create their own flash cards by providing a question and answer, or choose from a series of age-appropriate randomized flash card decks. (We may ping wolfram-alpha for randomized questions/answers. This implementation decision among others will get fleshed out later.)

With an account, users will be able to download their flash card decks and share them with other users within this application or using other social platforms.

The flash cards will be animated to flip and will work as any normal physical flash card does. Cards will start with question side showing first. Users can flip the card as many times as they like to repeatedly study a question.