 Hi everyone, this is Ashima. Today I'll be giving a talk on WIS-CLJ, which is a data visualization library for beginners. Before we start a little bit about myself, I work as a software engineer and have been dabbling with closure since the last one and a half year. I've contributed to some of the libraries and closures data science ecosystem, mainly node space and tablecloths. In today's talk, I'll be covering the following. We'll start with a brief overview of Weggalite and Hanami. These are the underlying libraries that sort of form the foundation upon which WIS is built. We'll then cover the basics of WIS and see some example plots. Following this, we look at some of the documentation and error handling that we have in the WIS library. We'll also take a look at some of the problems that he faced and the lessons that we learned along the way while building this library. Before we begin on a side note, I'm using a tool called NodeSpace to render my namespace into this notebook format. It's a wonderful tool and you should definitely check it out. I've added a link here in case anyone's interested. So let's begin with some setup. Here I'm importing the libraries which I'll be using during my presentation. Along with NodeSpace, I'll also be using this tiny library called Kindly to specify how I want the different elements to get rendered on the page. I'll also be using tablecloth for generating some data sets. Apart from this, I've imported Hanami so that we can compare its syntax with that of WIS. Our focus while creating this library was to build something which would be easy to use, have a consistent syntax, have excellent error handling capability to help users debug their code and have extensive documentation. The reason why we chose to focus on these issues was because upon discussion with beginners, we found that these were the top problems faced by them while trying to learn a new library enclosure. I want to make it very clear here that WIS is not a replacement for Hanami. It's just a starting point for people looking to get their feedback and explore closure's data science ecosystem. Once they feel like they've developed a basic understanding, we encourage them to move to Hanami in order to be able to create more customized and complex plots. Let us now look at how WIS works under the hood. It basically generates a map with all the values that we pass within each function. This map is then converted to the Vega light spec by Hanami within the Swiss function. One thing to note here is that we can change the order in which we call the different functions without having any impact on the final result. For example, I could call type after specifying x and y and it should still work perfectly fine. Since all we are doing is essentially creating a map, we are free to change the order in any way we like. Let's jump right in to see some examples. Here we are using different data sources to generate the visualizations. These include from a local file or from a file on the web. We can also use a tablecloth data set as well as a sequence of maps. You'll notice that in case our data has columns named x and y, it picks those up by default without us having to specify anything. We also have the ability to specify color. Another thing that I would like to mention here is that you can use key words instead of strings while passing parameters into the function. This syntax might feel more familiar and comfortable to season closureings. For those of you familiar with Hanami, you might be aware of the usage of substitution keys. These are the default values which are used to generate templates. They may be replaced with values of our choice depending on the customization that we desire. While using this, we have provided the ability to tweak and play around with Hanami substitutions. This is key to allowing the user to start exploring and learning about Hanami and its features while using this. In this case, we are using the key background to change the background color of the chart from the default floral white to this grayish color. You'll have to make sure to do any substitutions before passing your map into the final miss function. Another option that has been provided is the ability to tweak the Vega light specifications will get generated upon calling the miss function. As you can see in this example, we are changing the background color within the Vega light specification. Apart from being a great way to learn the underlying libraries, this way of tweaking Hanami and Vega light can be leveraged by advanced users who are using this but would like to have the ability to generate charts with features which are currently not available. We also have the ability to transform the data within the miss pipeline. Consider this example where we have data having numbers with different orders of magnitude. The scale seems to be off in this case. We can transform the data using log to linearize the situation. Let us now look at an example of a histogram. One point of note here is that even though Vega light offers us the ability to perform statistical computations on its end, we are choosing to instead calculate the billing data at our backend and then send that computed data for generating the plot. We look into this choice of performing the computations in the backend in more detail when we discuss the design decisions. Another interesting API that we have is for generating multiple layers of charts. In this example, we are passing a map with all the required key value pairs and the layers API is generating a single layer using the data. We also have the ability to pass Hanami substitutions within the map as seen in this case where we are changing the color of the mark. We can create multiple layers using the same data set like in this example where we are creating a point chart and a line chart using the same data. Another feature of this is the ability to pass Hanami templates as the type of the plot. We can also create different layers using different data sets as seen in this case. Another interesting functionality that we have is the ability to generate regression lines. In this case, similar to histograms, we are choosing to do the calculations at our backend before using the data to generate the Vega light spec. In future, we hope to add the ability to generate regression curves as well. Let us now look at error handling in the WIS library. Currently, we have a very rudimentary setup for catching errors, which covers only the most basic types of errors which may come up. This is an area we are planning to expand on in future. As you can see here, we have created a macro which removes all the stack trees and confusing error logs and instead prints out a concise error message which serves to highlight the exact issue. For example, if the user has typed an incorrect file path, we are throwing an error informing them that the file does not exist. Another example that we have here is of the user trying to plot a column which does not exist in their data set. In this case, we notified the user that the column which they are trying to visualize seems to be missing. Another example that I have here is of creating a plot without specifying the type like maybe point chart or line chart or bar chart. You can see the appropriate error which gets thrown in this case. Moving on to the documentation part, we are currently working on providing users with mainly two types of documentation. The first is API docs generated using a tool called codex, which automatically creates documentation from closure source code. This is helpful for people wanting to understand the use of each API or looking to explore the different parameters that can be passed to each function. The second type of documentation is tutorials which involve a little more hand holding. We are targeted at new users explaining the entire setup process and giving a walkthrough of some examples. We have found that a combination of both of these produce the maximum results when it comes to adoption of libraries. Easy to follow tutorials are an attractive option for beginners. And once they become familiar with the tool, they can begin exploring the API docs to understand the nuances and possibilities of achieving more complex results. A key part of our development process was continuous interaction with the users. This helped us get feedback from them right from the get go. We would showcase our progress during the routine study groups with Cyclops with Cyclops organized and would then hold an open discussion to hear users thoughts. This helped us make key decisions and made sure that we were staying true to our goal of improving users experience with closures data science tools. Another advantage of having people experience our libraries at such early stage was that as developers, it helped us make decisions regarding the priorities to focus on and also made it easy for us to pivot in case of a misstep. This would have been a lot harder for a much more established library where a lot of effort has already been put in. While creating this we spent a lot of time exploring libraries in various other languages, which use Vega under the hood. These include Altair and Python, Vega-like API and JavaScript and ggvis in art. One of the ideas that was picked up from these explorations was to use a pipeline instead of a map. This would definitely mean losing some of the flexibility that a map provides as seen in Hanami, but would make our syntax much more simpler. More number of functions, as in the case of a pipeline, would also give us the ability to add checks and error handling at each point. The challenge that we face continuously throughout the development process is regarding the trade off between simplicity and customizability. This is a challenge that almost all libraries face at some point or another, and depending on their goals will make a decision that best satisfies their target audience. In our case, since this is being designed specifically for beginners, we chose to focus on simplicity, but we did not completely ignore giving the users the ability to add their customizations. Wherever possible, we have given the option to tweak Hanami substitutions or the Vega-like spec. This we feel is enough to cover most of our use cases. Another major decision that we made was to have various computations happen at our backend instead of leveraging Vega-like features. This was inspired by our ecosystem where all the statistical tools can be freely used in transforming data while creating plots. We are trying to achieve something similar to that by using Clojure's own statistical libraries to perform the computations. This provides us more flexibility by transforming the data and also makes our code much more efficient since less data is needed to be sent to Vega-like to generate the spec. Going forward, these are the areas that we are planning to focus on, staying flexible and evolving to support more use cases, adding backend site transformations similar to what we saw in case of histograms and regression layers. We hope that this will give users the ability to enjoy the whole of Clojure's statistical computing ecosystem. Then continue to hold experimental user sessions to learn more about the user's experience and have the results from these shape the future path. More statistical error handling using some schemas like maybe Mali. We might consider adding video tutorials for people preferring to watch rather than follow a document's instructions. We might also consider integrating with specific libraries for domain specific visualization grammars, for example, grammar for visualizing machine learning models or for visualizing time series. That's all from my folks, but before we end, I would like to take some time to thank the following people without whom this talk wouldn't have been possible. Thanks to the reclosure organizers for providing me with this platform to showcase my work. I would also like to thank Daniel, who is the co-author of the BIS library and whose help was integral in planning and creating today's talk. I wouldn't have been able to do any of this without his constant help support and guidance. I would also like to thank everyone who attended the Cyclot study groups and gave valuable feedback, which helped shape the direction of this library. Lastly, I would like to thank all the maintainers of the libraries, which served as the foundation upon which this could be built. And finally, thank you to you all for listening to my talk. Hope you found it useful. Have a great day. Bye.