HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2016T2 Team Sirius Midterm Wiki"

From IS480
Jump to navigation Jump to search
Line 181: Line 181:
  
 
[https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_Team_Sirius_Risks#Potential_Risks View our list of potential risks here]
 
[https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_Team_Sirius_Risks#Potential_Risks View our list of potential risks here]
 +
<br>
 +
===Unaccepted Stories of Each Sprint===
 +
[[Image:sirius_midterm_scrum.png|667px]]<br/>
 +
<b>Explanation:</b> <span style="color: #1d4c5d; font-size:14px; font-family:Arial; font-transform:uppercase;">The team does not have a bug metric or issue tracking. If there are any bugs found at any point in time during the sprint, the bug is logged as a story with 0 points.If the bug impedes progress or prevents the team from delivering a shippable product, it will be prioritised and fixed immediately. If it does not impede progress, it will be prioritised together with the product backlog at the start of the next sprint.</span>([https://wiki.smu.edu.sg/is480/IS480_Team_wiki%3A_2016T2_Team_Sirius_Stories  Stories can be found here.])<br>
  
 
===Technical Complexity===
 
===Technical Complexity===

Revision as of 17:45, 17 February 2016

Sirius logo.png


Sirius home icon.png   HOME

 

Sirius aboutus icon.png   ABOUT US

 

Sirius projectoverview icon.png   PROJECT OVERVIEW

 

Sirius projectmgmt icon.png   PROJECT MANAGEMENT

 

Sirius doc icon.png   DOCUMENTATION

 


Project Progress Summary

Sirius presentation icon.png Midterm Slides

View presentation slides: [| Team Sirius Midterm Slides]

Sirius deployment icon.png Deployment site

Visit this link: | Sirius AB site

Deployment Progress

  • Current sprint: Sprint 10
  • Sprint period: 18 February 2016 to 3 March 2016
  • Major milestone: Midterm Presentation
  • Features involved: Visual Variation Editor & Mobile Device Experiments

Project Highlights

  • Highlight 1: Added Admin Module and Mobile Device Experiments and dropped 2 modules (Multipage experiments and Multivariable experiments)
  • Highlight 2: Implemented new user interface of Sirius AB
  • Highlight 3: Implemented visual goal selection
  • Highlight 4: Conducted user test 2 on 4 February at IDA Sandcrawler with 4 developers

Project Management

Sirius dashboard.png

Project Status

Team Sirius is confident in delivering the project to our sponsor.
Sirius project progress.png

Planned vs Actual Scope

Planned Actual
Sirius scope v5.png

Sirius scope v8.png

Major changes made

Sprint Module Action Category Feature Description Value to Client
7 Mobile Device Experiments Module Added Secondary
  • Device type targeting
  • Mobile variation preview
  • Mobile goals
This module allows users to view a preview of their mobile sites when creating/editing experiments. It also ensures that existing goals work on mobile sites. Some organisations have mobile sites that they would like to test. With this module, we ensure that users can not only run experiments on desktop sites, but also mobile sites.
6 Admin Module Added Secondary
  • View all experiments
  • Edit all experiments
  • Archive/restore experiments
  • Create accounts
  • Activate/deactivate accounts
  • Grant/revoke admin rights
  • Edit all account details
  • Send password reset
Team met up and re-prioritised the remaining modules as of Sprint 6. The team agreed to bring multivariable experiments and multipage experiments to good-to-have and visual variation editor to secondary scope since our sponsor mentioned that it has higher priority as compared to the other two modules. Sponsor also mentioned that they want to have an admin module that allow admin to manage users accounts. Shifting visual variation editor to the secondary scope means that this is of a higher priority, and our platform can be used by non-developers. We only risk dropping modules that are of a lower priority to our client. The addition of the Admin Modules allows greater control for the client – especially the fact that now only admins can create new user accounts.

Click here for more on changes made to scope

Planned vs Actual Project Schedule


Sirius planned schedule.png
Sirius actual schedule.png

Project Metrics

Team Velocity

Formula: Average of accepted stories points of 3 sprints
Sirius team velocity.png
Explanation: The team has improved velocity over time, as shown from the red line above. One thing to note about sprint 4 is that there were no stories put up for acceptance since there were no stories completed in that sprint.

Sprint Burndown

Formula:

  • Planned: Total planned story points over number of days in a sprint
  • Actual: Actual story points completed each day in a sprint

Sirius sprint 4.png
Explanation: The team did not complete any story points for this sprint as this sprint falls in the exam period. More importantly, the stories that we took up were more complex and required more research to be done. Although no story points were completed, the team did work on some of the stories in terms of research and experimentation.

Sirius sprint 7.png
Explanation: The team did not manage to complete two stories – a 1-point story and a 3-point story. There were unforeseen complexities in some stories that caused us to take longer to complete, one example was the Visual Goal Selection story, where it expanded from an estimated 5 points to 8 points.

Sirius sprint 8.png
Explanation: One of the best performing sprints. All planned bug fixes and stories were completed before User Testing 2. In this sprint, the team also deployed the revamped UI.

Risks Management

Risk Type Risk Event Likelihood Impact Mitigation
Resource Risk Unable to find users to test our application Medium Medium Start sourcing for users early by sharing it via social media or emailing companies
Technical Risk Unable to develop WYSIWYG editor due to its high complexity High Medium Active feasibility checks and notify sponsor if there is a need to rescope the function

View our list of potential risks here

Unaccepted Stories of Each Sprint

Sirius midterm scrum.png
Explanation: The team does not have a bug metric or issue tracking. If there are any bugs found at any point in time during the sprint, the bug is logged as a story with 0 points.If the bug impedes progress or prevents the team from delivering a shippable product, it will be prioritised and fixed immediately. If it does not impede progress, it will be prioritised together with the product backlog at the start of the next sprint.(Stories can be found here.)

Technical Complexity

Architectural Diagram

Sirius architect diagram.png

Snippet Flow

caption Snippet part

Sirius sinppet flow.png

Snippet code: <script src="http://sirius.lol/accounts/snippet?id=2"/>
Explanation:
1. Retrieve/generate Unique ID (UID) from browser cookie 1455269119724_0.276202306849882
2. Retrieve/assign Variations for running Experiments {"16": 32}
3. Check Experiment target URL http://www.centralclinic.com.sg
4. Apply Variations to page:

  $(".nivo-imageLink > img")
   .attr("src", "img/open24hours-red.jpg");

5. Attach Goal handlers

 {"id":34, "name":"Health Screening banner", 
   "selector":".nivo-imageLink", 
   "category":"click"}

1. Experiments Preview

Sirius complexity experiment preview iframe.pngSirius complexity experiment preview iframe 2.png Explanation:As part of the create/edit experiment flow, we needed to let users have a ‘live’ preview of what effect their variation jQuery code has on the target page, so that they can confirm that their code is making the correct changes to the page.

The variation preview is created by embedding iframes to load the target page, and then running the user’s jQuery code on the iframe to make the changes. What actually happens is that the target page can be displayed, but because they are from different origins (where origin is defined as the combination of scheme + domain name + port), the experiment page’s JavaScript code is not allowed to read or update what’s inside the IFrame, so the preview doesn’t work!

Sirius complexity experiment preview iframe 3.pngSirius complexity experiment preview iframe 4.png
This is known as the Same-Origin Policy that browsers enforce for security reasons. Imagine if you are visiting some compromised or malicious website, which has a hidden iframe that loads GMail, which you happen to be logged into – if the website’s JavaScript code is able to interact with the iframe, it will be able to read off all your emails, delete everything, or even send emails to the bank on your behalf, instructing them to wire all your money to the Bahamas!

Sirius complexity experiment preview iframe 6.pngSirius complexity experiment preview iframe 7.png
In order to make the parent page as well as the iframe have the same origin, we proxied the target URL through a special route in our application. However, this breaks all relative URLs on the page, so things like images, CSS, and JavaScript files can’t be loaded. To fix this, we had to inspect the proxied HTML and insert a <base> tag with the target page URL at the appropriate place within the page, which instructs the browser to resolve all the relative URLs against the target site directly.

Sirius complexity experiment preview iframe 9.pngSirius complexity experiment preview iframe 10.png
Even despite all this work to deal with the Same-Origin Policy, there still are lingering issues with webfonts referenced in CSS stylesheets not being loaded. While the <base> tag is correctly rewriting the webfonts’ URLs, browsers require the webfont’s server to explicitly permit this cross-origin access. While the webfont services like Typekit or Google Fonts are setup to instruct the browser to permit all origins, websites that self-host their webfonts typically do not have this setup.

2. Visual Goal Selection

Sirius complexity visual goal selection.pngSirius complexity visual goal selection 2.png

Explanation:Another feature in the create/edit experiment flow is the ability to allow users to interactively select the elements they wish to be included in their click goals, as opposed to having to come up with the CSS selectors themselves.

We found the open-source tool SelectorGadget that does something similar to this, but as it is a bookmarklet, it was entirely written on the assumption that it was operating on the main window/document context. However, we needed it to operate on the particular iframe that contains the preview. We had to take the whole library apart to understand how it worked, and then rewrite significant parts of it to allow injecting the desired window/document context in at runtime. We also had to make changes to it to allow deeper integration into our UI, instead of using the default overlay bar.

Quality of Project

Immediate Deliverables

Stage Specification Modules
Project Management Meeting Minutes Internal, Supervisor & Sponsor Meeting Minutes
Project Schedule Project Schedule
Metrics Project Metrics
Risk Management Risk Management
Requirements Project Scope Project Scope
User Stories User Stories
Analysis Persona and Scenario Persona & Scenario
Market Research Market Research
Architectural Design Architectural Design
Design Prototypes Mid & High Fidelity Prototypes
Testing User Test Plan & Results User Test Plan & Results

Deployment

Deployment site: sirius.lol (Instruction are here)

  • Username:
  • Password:

Testing

User Testing 1

Venue: IDA
Date: 30 Oct 2015, Friday
Time: 3.00pm
Duration: ~25 minutes
Number of Participant(s): 2
User Test: Instuction here
User Test Results: Click here to view

User Testing 2

Venue: IDA
Date: 4 Feb 2016, Thursday
Time: 9.30am
Duration: ~45 minutes
Number of Participant(s): 4
User Test: Instuction here
User Test Results: Click here to view

UI Fixes based on User Testing 2

Sirius ut2 login fixes.png Sirius ut2 weightages fixes.png
Sirius ut2 results fixes.png Sirius ut2 edit exp fixes.png

Reflection

Team Reflection

  • What have we done so far?
  • What can be improved?
  • How can we do better?

Product Owner's Testimonial

Jean:
Team Sirius produces good quality of work, and provides regular updates on the progress on the product development. The team is strong in technical, and is willing to explore ways on improving the user experience design on the product.

Individual Reflection

Alex:
Chiang Fong:
Kathy:
Kenny:
Lai Ho: