Skip to content

Sprint 3

Jump to bottom
Kenny Clark edited this page Apr 18, 2016 · 16 revisions

#Sprint 3# ##Meeting 1: Location/Time##

  • Location: Student Center Study Room 2200B
  • Saturday, Apr 16th, 2016
  • 3:30pm to 5:30pm

##Attendees##

  1. Kenny Clark
  2. Gaofei Zhao
  3. Xiang Li

##Meeting 2: Location/Time##

  • Location: Student Center 1st Floor
  • Sunday, Apr 17th, 2016
  • 7:15pm to 10:00pm

##Attendees##

  1. Dale Brauer
  2. Kenny Clark
  3. Robert Fink

#Sprint 3 - Milestone Targets# ##General## ###Sprint Documentation###

  • Created GitHub wiki documentation on Sprint 3: Kenny
  • Links to previous documentation:
  • Link to working application: http://linkedin.td9175.com/
  • Instructions for walk through:
    1. You may go to top right corner of the Navbar to login.
    2. Login using: username: dale@td9175.com password: over9000
    3. You'll be shown the profile page of this user.
    4. You may explore the drop down under the username: currently messages is not implemented, and My Network page isn't fully functional.
    5. You may then logout from the same drop down menu in the top right corner.
    6. You may click on register in the top right corner.
    7. Create your own account with the system. (Currently organization's registration is not implemented)
    8. You'll be then redirected to your profile page; however, we're currently running into trouble with the bit that is meant to put the registered data into SWE.Person. Your account will still be created, and the password will be hashed.
    9. You may logout of the system.

##User Interface## ###Cleaning and Refining Design###

  • Segregated UI Skeletons to a folder out of the root directory.
  • My Network Page redone in more of the finalized style: Kenny
  • Landing Page remade utilizing Bootstrap: Gaofei, Li
  • Profile Page redone in more of a finalized style: Dale

###UI Mock-Ups ###

  • Already created as digital layouts since Sprint 1.

###Building the UI###

##Other## ###Backend support###

  • Continued work on back end support: Robert, Dale

###Update Change Log###

  • Change log of the RAD + Sprint documentation can be found under the Table of Contents of the main PDF.
  • Change log of "who is doing what and when" can be found through out the Sprint documentations usually past each section.
    • In the case that a point does not have a developer after it means either:
      • It was such a minor addition/change that giving credit seemed arbitrary.
      • Or it was to complicated to figure out which developers exclusively worked on it, since everyone contributed in some form or way to an element.

###Data Visualization###

  • What would we like to visualize: How many users have registered over time.
    • Some organization like to present their users or maybe some of their more "advanced users" with data on daily usage of their application. For example, Steam, an entertainment platform geared more towards video games, provides data visualization on: users on Steam over time, users on a certain game over time, users active in a game's market, users active on the forums, etc. In their case this helps the application prove to its users (and possibly investors) that it's a valued system by showing just how many users are on the platform.
    • For our system we can't really imagine showing usage data since there just wont be much, and instead we'd like to present a graph of the number of new registered users over time. This can be shown in two ways:
      • 1st: We can present the total amount of registered users; hence, showing a constant growing chart. (Something a PR team could show just how well our application is doing, without getting into much detail.) We would most likely pursue this one.
      • 2nd: We can present the amount of users who are registering per day; hence, showing a more "teeth" like pattern for registrations, and while this could show growth, it would also show dips on certain days when no new users would sign up.
  • Tools we would like to use to visualize the data:
    • D3.js
      • We've had some experience using these in past assignments.
      • We believe, that Justin is a fan of D3.js; thus, if he is, then his office hours will be a great resource to get any help if we can't find a solution to a problem on the web.
  • Method on getting the data:
    • Our system keeps a timestamp attached to user when they register. We hope to easily just pull those timestamps from all of the users, and simply count and organize them into days on the visualization.
      • We don't how scalable this is, if the system has to run through all of our users constantly, maybe we can figure out some way to store these values somewhere, and then simply add the new data to them as users continue to register; however, that is not a priority.

##Testing## ###Revisit Testing: Edge Cases###

  • Examples of Edge Cases for our application:

    • **Bootstrap - Screen Resolution Functionality: **

      • Our system uses the Bootstrap framework, which means we'll be utilizing the re-sizability features of the framework; therefor, allowing our webpages to re-size to different screen sizes. Our edge case for this applies to the "breaking point" between the different resolutions, and how they look on displays smaller then the "xs" size or larger than the "lg" size. It's important for us to test out how the screen looks past the "lg" - 1200px size, and how it fairs below the "xs" - 767px size.
        • This is important to test, since it's such a large part of usability. For example: on a screen larger than the "lg" - 1200px, would the page become too small to properly read, or on a screen too small a certain functionality may be off-screen if it's not properly re-sized.
        • While developing the ui, we have already been simply re-sizing their browser windows while creating pages, in order to make sure the page elements re-size properly; however, we should probably begin to use an application like ScreenFly to test our webpages on established screen sizes.
          • However, from prior experience with ScreenFly, certain devices such as the iPhone4S still have quirks when switching the screen from landscape to portrait, which were not picked up by ScreenFly; however this may have been patched.

    • Registration - Email:

      • As discussed in class, an issue may arise with email address length during registration. The edge cases would be the maximum possible length for an email, which we believe is 256 characters (this includes both name, @ symbol, and domain. Our reference for this is: Wikipedia - Email. We would also test the shortest possible email address, which would be 3 characters: "a@b;" however, we don't believe there are any top-level-domains which are only 1 character.
        • This is an important test, as we have learned some individuals do own emails which are extremely short: for example only containing 1 letter for the name. We wouldn't want any individuals to not be able to join the website because of an error in our processing.

    • Registration - First / Last name length

      • Our system call for the first or last name to only be 30 characters long each.
        • Our edge case for this would be what would happen if a user registers with 31 characters, and how would the system handle this (ie. give out an error message).

CS4320 Final Group Project - Group 11: University of Missouri - Columbia

Clone this wiki locally