This week started with me completing the view pages url state integrating D3 with url state and moved to me fully testing the application. This was my first time using GitHub Issues to maintain the issues list and performing a release.
D3 and Url State
One of the core functionality of the Single Page Web Application (SPA) was the ability to store the page state within the URL. The seventh week at Digital Labs I explained how to store the search page state within the URL and the common mistakes made, following this tutorial I attempted to maintain the state of the view page. The largest difference between the search page and view page was the view page graph used D3, a whole different eco-system which wasn’t built to store its state within the Url. Never the less, after 2 days of solid work I finally stored the: runs being viewed, trends visibility, active trend, zoom level, and pan and offset co-ordinates within the URL. Below I will explain how to integrate D3 to work with URL state.
Within the function, D3 calls when the user zooms, for me, it is called zoomed, the URL state needs to be updated with the new zoom vector if the user is zooming. Simply stringify the transformation object, encodeURI to be safer than use the $state object and go method to invoke a new transition.
functionzoomed(){ //detect if user is zooming or panning. if(zooming){ //transformation object vart=d3.event.transform; //convert object to string t=JSON.stringfy(t); //url encode string t=encodeURI(t) //invoke transition, the '.' indicates same location $state.go('.',{ transitionVector: t }) } }
Note that the parameter transitionVector is dynamic, the state does not reload.
Check out Seventh Week at Digital Labs State Page Stored in URL section to see how to set dynamic parameters. Check out Eighth Week At Digital Labs Zooming and Panning section to see how to check if a user is zooming not panning.
After a zoom has been detected and the URL updated, the URL parameters needed to be extracted to transition the graph. To extract the URL parameters the $stateParams object was used, simply parsing the $stateParams transition property.
//check if there is a transitionVector param in the url if($stateParams.transitionVector!=undefined){ //parse JSON string vartransitionVector=JSON.parse($stateParams.transitionVector); //transition graph }
To transition the graph D3 provides us with a handy zoom.transform method which invokes a zoom event with a specfic transition vector. The example below details how to use the zoom.transform.
function(transitionVector){ svg.call(zoom).transition() .call(zoom.transform,d3.zoomIdentity) .translate(transitionVector.x, transitionVector.y) .scale(transitionVector.k); }
The same process can be used when the user offsets the graph, except you will notice that calling a second transition will interupt the first. Luckily a transition invokes an ‘end’ event when a transition ends. The example below peforms the transitionVector transition then the offsetVector transition only when the tranitionVector is complete.
function(transitionVector, offsetVector){ svg.call(zoom).transition() .call(zoom.transform,d3.zoomIdentity) .translate(transitionVector.x, transitionVector.y) .scale(transitionVector.k) .on('end',function(){ //perform offset transition }) }
First Time Testing
Version 0.1 of the system was released this week, both the Search Page and the View Page could be fully tested by the clients and I. When testing if an issue was found with the release, the issue could be marked down using Github Issues, each issue is tagged appropriately either as a bug or a wanted enhancement, marking it closed when I fixed the issue. Using Github issues is a common standard for recording issues, allowing developers and users to track certain issues as well as their priority. Furthermore, via Github Issues the client and I could communicate in the form of comments for a specific issue, for example when testing annotations.
The client discovered the annotation re-position and description edit buttons were not working thus the client registered a new issue. To resolve the annotation button issue I first attempted to reproduce the error, in all 3 attempts both buttons worked, vai Github issues I communicated back to the client asking for the exact steps taken including which browser and the version number is being used whilst describing the exact steps I took to test both buttons. The client responded with the exact steps and the browser in use, I quickly relised the client used Firefox rather than Safari, my chosen browser. Using Firefox I finally reproduced the error, once the error was fixed I closed the issue describing the new annotation behaviour.
In addition to the client testing, Dave and I for a couple of hours performed our own tests. We explicitly tested each features functionality, for the whole system, reporting an issue, when found, to GitHub Issues detailing how to reproduce it. Some of the issues found ranged between UI bugs,”Odd sidewards excess scrolling“, to more serious “Offset line verticalises“. In addition to reporting bugs, Dave and I reported if any enhancements were needed, enhancements could be as simple as UI changes, “Lock Icon can be Ambiguous” to new whole features ‘Toggling Runs and Trendlines‘.
Furthermore, for each feature, we discussed the UI design and the expected functionality, we realized that many elements of the UI were cumbersome and unintuitive. When a Ui change was needed, before reporting onto GitHub Issues, we first debated what would be a better alternative. One example where the UI was cumbersome was with annotations, first, each annotation button functionality was ambiguous, second to edit an annotation it took too many clicks than needed. To improve the annotation buttons UI each button would include a tooltip describing the functionality and to reduce the click count we redesigned how editing an annotation would work.
Going through the application in this manner taught me a great deal about the app’s functionality plus I learned a totally new way to look at UI design. In the end, the application was completely torn apart exposing each individual flaw resulting in a long list of bugs and enhancements reporting each one onto GitHub Issues, totaling 22 individual issues. Take a look at the issues list, each issue is tagged with a version number.
Communicating With Clients
Throughout my internship, we maintained a constant relationship with the clients meeting nearly every day discussing changes made and if any, issues. Maintaining constant communication with the client has been vitally important to the development of the system, allowing us not only to catch changes early on but to ensure the client understands the limits and functionality of the application. I learnt that if the client does not remain in the loop while development is happening the client can easily lose any understanding of the application a common mistake when working with clients.
Mentioned earlier this week version 0.1 of the system was released allowing the client to test the application, since we were in constant communication with the client, the client easily picked the application up and started testing. Allowing the client to test the application substantially aids in the development, increasing the likelihood a bug will be found and if an enhancement is needed.
Coinciding with version 0.1 release, release notes were written up. For every release of the system there will be an associated release note. A release note describes the functionality of the application, changes made and bugs fixed. Each release note is shared between clients and developers. For version 0.1 the release note described that only the search and view page are functional and how to test each specific feature, this extra communication channel with the client helps the client to develop a better understanding of the application. Take a look at the version 0.1 release notes especially the Example Tests section.
Conclusion
I learned a great deal this week how to test an application thoroughly. Testing was scary but enjoyable, tearing the application apart focusing on each features functionality and UI. Next week is the second week of testing, dealing with the most crucial bugs first and enhancements.