Meeting minutes
Status of app performance issues
<Matt_King> rich: over last 3 weeks have made several iterative updates to app to improve page loads.
<Matt_King> currently averaging 15 to 22 seconds in test queue
<Matt_King> PR 441 and 448 coming next week for query per improvements
<Matt_King> Should bring some additional improvements
<Matt_King> The gains are difficult to predict because local and server environments are so different, and staging is different from prod.
<Matt_King> Seth: We are not sure why staging and prod are so different today.
Status of collaboration with screen reader developers on first 8 plans
<Matt_King> James: We created 16 issues on GitHub; 8 for Visper and 8 for Apple
<Matt_King> Vendors have acknowledged receipt of links to issues.
<Matt_King> Apple has shared some feedback on toggle button plan.
<Matt_King> That will be a futre agenda item.
Progress on preparing next 16 tests for candidate review
<Matt_King> Matt: we want to complete testing on 16 more examples before mid november
<Matt_King> James: 6 of 16 could be ready as soon as next week
<Matt_King> the next 10 are in triage now
<Matt_King> Joe: Do I still need to retest that one test I didn't finish for modal
<Matt_King> James: No, we were able to move that along
<Matt_King> Joes: I've done testing for some of these, do we need to retest them?
<Matt_King> James: Yes, we have changed some of the plans
<Matt_King> Joe: When I was testing last time, some of the version detection was not correct
<Matt_King> Seth: was it in the minor version
<Matt_King> James: was it for browser or screen reader
<Matt_King> Joe: I think screen reader:
<Matt_King> Matt: We are not auto-detecting screen reader versions; that is manually generated data for the dropdowns
<Matt_King> James: we will make sure those lists are updated to most recent and placeholder values are removed
<Matt_King> Joe: How will conflicts resolved; I was not involved in some of that resolution last time.
<Matt_King> James: We were able to resolve some of them by reproducing results that matched what you sproduced.
<Matt_King> all: discussion of how conflict resolutions should be discussed and coumented in GitHub.
App design for Candidate Review Experience
<Matt_King> Seth: Since last meeting, we updated the github issue
https://
Latest feedback from Matt: https://
<Matt_King> Matt: I commented on the issue last night
<Matt_King> Seth: On monday we posted a summary of structural changes
<Matt_King> Part is hierarchy of how plans are displayed; organizing it by AT
<Matt_King> Also revisiting the view we use for reviewing the content
<Matt_King> Was previously like report page but now more like test runner, with one page per test
<Matt_King> We proposed it would be more like the test run page with instructions and link to open test page and output presented as assertions
Matt_King: top concern was around nomenclature, e.g. saying a plan has "open issues". you're not going to know if that was an issue for your screen reader or with the plan itself, etc.
Matt_King: the other thing was clearing up "status". i think we want to use that there's a status for the entire test plan, and not use that language at all when we get to the test granularity.
Matt_King: one process change came about: if vispero asks for a change, i don't think test should move back to draft. it should simply show up in test queue to make changes / results, but still be visible in candidate view
Matt_King: on candidate test page, i saw 2 gaps in design: 1) we should have some additional information in the table about results / target date for exiting candidate test page, 2) we shoudl add an additional summary table that shows status for each AT for each test plan
All: discussion of process for when candidate test plans change and the consequences on the UX
Currently, a test plan shows up in only one place in the app; test queue or candidate review or reports
this does not necessarily match the needs of the working mode
For example, plans that are recommended need testing to be run when new versions of AT and browsers are released, that work needs to show in test queue.
Discussion of centering pages around users, e.g., tester, at dev, public
seth: We need to design this wholisticly. we should make sure we understand the implications before going too far down the path of implementation of the canditate test review UI.
Matt: I will own scheduling a workshop for this sometime in the next 2 weeks