-
Notifications
You must be signed in to change notification settings - Fork 39
Development Meeting Notes March 3rd, 2017
DATE: Friday March 3rd, 2017 START TIME: 7:00 PM LOCATION: CAW
- Dr. Stephanos
- Dr. Blandine
- Josh
- Bruce
- Chris
- Rumana
- Kim
- Areeba (author)
- We will get a booth, do a research component of interface for various types of users with JMCC as our industry component. We’ve submitted logo.
- Digifest days: April 27th to 29th. Total of 4 days are needed as we need to go a day earlier to set up. Volunteers in the team can rotate to attend 2 days at the time.
- Video needed for Digifest constituting of perhaps interviews of people involved in the inception and development of the app. Issue #240 has been created for it. Some discussion on perhaps asking an external film related individual to capture video in HD.
- Volunteers in the team to participate in the project to contact Dr. Stephanos.
- Dr. Blandine to contact JMCC to see if Luke is available to participate in the video.
- Need a student lead coordinator on the project to work closely with Dr. Stephanos. Who is interested?
- Criteria may seem tedious but one must look at it from the user’s point of view.
- Each criteria will be a dynamic link which will display more information upon clicking it such as a description and/or images as opposed to the (i) information button. Clicking on the criteria will lead to another page as that would be more screen reader friendly over i-button.
- Big discussion on wording the following criteria (and other similar criteria): “Access button or automatic doors” versus “a working access button or automatic doors”. Options discussed:
- Option 1: Leave it as is because in the duration that it’s not functioning, users will rate as ‘no’ and length of the duration would fairly reflect in the average. Criteria information page will describe ‘in the case it’s not working, mark ‘no’’.
- Option 2: Have two separate criteria’s, one saying ‘"ccess button/automatic door", next one ‘working access button/ automatic door’.
- Option 3: "WORKING access button/ automatic door" with clear explanation in the description of the criteria perhaps with pictures as well. Users will mark ‘no’ in the case it’s not there and/or it’s not working.
- Future scope: We will have a “training guide” pop up at the beginning of application use/ in the middle which will hint that you can click on the criteria to read further if the criteria is unclear.
- Discovery discussion continued; rest of the criteria were discussed.
- Discussed how to rate complex buildings like CAW
- Decided just because some criteria are met doesn’t mean the building as whole is accessible. Eg. Ramp may exist but not accessible washrooms.
- “Every OTHER entrance is accessible”. Essex may have one entrance that is accessible, not every entrance of a building is accessible.
- Criteria page on the web application: Next, next, next… Submit for each category page and last one a submit button instead of Next. An additional submit button on the side under the side menu.
- User can submit each category page one at a time with the submit button on the side.
- Future release: Reminder feature for an incomplete review prior to signing out.
- User should be able to save the review if it’s incomplete. (Josh is working on it)
- Future release: under the app “training” guide we can clarify how to to submit with the 2 buttons.
- Criteria VIEW page should also have a ‘Rate’ button in place of the side ‘submit’ button for users who want to jump to leaving a rating while viewing reviews.
- There should be 4 buttons for the testing, i.e., including the ‘I didn’t notice’ button.
- In the VIEW page: We want he criteria to be a link which leads to a new page that has the criteria pie chart with the 4 divisions (y, n, na, didn’t notice) as well as the number of ratings for each division.
- Josh will write the release notes.
- Write test cases for #205 (Assigned to Areeba) and test
- Write test cases for #209 (Assigned to Kim) and test
- After starting an issue, change label from ‘New’ to ‘Working on it’
- UX design sketch for Issue #236
- Design has been put on hold as Josh did a quick fix by darkening the selected tile color and zooming in the text when hovering.
- If JMCC approves it, no need for UX sketch.
- UX design layout for Issue #122 (Assigned to Rumana)
- Suggested idea for the tooltip text enlargement: have a floating section at the bottom of screen which stays fixed and will display what each tiled location category constitutes upon hovering / on phone upon single tap.
- Track your hours
- Time it took to solve various issues + travel + time spent at meetings = total hours
- Dr. Blandine will be leading a Project Management group meeting at Hackforge on Wednesday, March 22 at 7:00 PM - 8:00 PM which will discuss sharing strategies in the following areas:
- Project Management
- Process/Continuous Improvement
- Agile project development
- Scrum
-
Rating feature will not be complete for demo 0.0.2 because the criteria and category list is incomplete.
-
Josh needs to create a new issue for the map pop up. The navy blue list should not appear by default. It should only appear after clicking on the location icon as its covering too much of the map.
-
Demo 0.0.2 will be released on Monday evening after review and validation. In the release notes, we will write future scope for the Rating feature. Something like... “Available soon”.
-
(Assigned to Kim) Jaccede website’s data needs to be extracted. For usable data, Kim will create columns for it.
-
Other websites to could be potential sources for scraping data:
- AbleRoad
- AccessNow
- Planat
- Wheelmap
- Toiletfinder.org/.com (Australian)
- Axs Map
- Bathroom map
- Open Street Maps
-
We want to grab other websites data and roughly convert their ratings to Access locator ratings via migration scripts. * That would be one way to populate our database other than crowdsourcing.
-
Open street maps also has some accessibility criteria data, various categories like restaurant, longitude, latitude… “is wheel’ or “is toilet” wheel.
-
The output for data extraction through importer is in csv format. Python scripts can be used or general purpose scripts to create the csv files. Then we will convert the .csv to json data to seed data built by Josh.
-
Imported data will be used as a simulated user, i.e. robot on AccessLocator. Each source will be a simulated user such as AbleRoadUser, WheelmapUser, OpenStreetMapUser to populate our database.
-
Simulated users separated by source will mitigate problems that may arise in the future for data scraping.