# Visualization as a Decision Making Tool

We explore the idea of using visualization as a decision making tool. We use Kiva.org As a use case and implement it in Protoviz. Every day more than 600 loans are posted on the Kiva website. As a result it makes it difficult for a lender to select a requester and make a loan wisely. We focus on solving this problem by using visualization as a core concept in our tool. We use a number of ideas that we have learned in class to solve this problem

• Parallel coordinates are used as the main visualization element
• Brushing is used to highlight the desirable subset of loans
• Link backs to the Kiva website are provided to users to make final payments through kiva (ideas from common space)

## Kiva.org and Microlending

Kiva is a nonprofit organization focused on providing microloans to entrepreneurs in developing countries. Kiva works with field partners and each field partner works with individuals or groups to post their loan requests on Kiva website. People in developing countries can request a loan individually or as part of a group. A lenders fulfill the loan request by giving many \$25 loans (\$25 is the minimum payment one can make). The field partner collects the money from Kiva and give it to the requester (Recently most of the times the field partner gives the loan to the requester first then posts a request on Kiva and uses the money from lenders to backfill the loan that he has given to the requester. When the requester pays back the money the field partner collects them and sends them to Kiva in 5 or 6 repayments.

## Challenge

Every day there are about 600 new loans posted on Kiva. An average Kiva lender laons about 6 loans per year (about \$150 worth of loans) so each lender is exposed to a large set of possible lending opportunity. The image below shows the current user interface for Kiva. Loans are presented as a linear list and the user can go through them one by one to find the loan that she is interested in

We wanted to experiment to see if we can build a quick decision making tool for lenders so they won't need to read each loan's details one by one. Our tool provides an interface to Kiva. Lenders can quickly brows trough the quantitative data for more than 600 loans and select the ones that they are wishing to see. They can click on the selected loan and they will be directed to the Kiva website to make their payment to the requester. We believe our tool makes the lending procedure more convenient for lenders and will hopefully increase the cash flow for Kiva.

## From prototype to the working draft

We thought about many different UI possibilities but we finally decided that parallel coordinates are the most intuitive interface for what we wanted to do. We added a click able image and other bells and whistles but the whole idea stayed the same and did not change much from the original prototype that we had in mind. Significant amount of our time was spent on the back-end and writing python codes to consume the Kiva-API. Protoviz was straightforward as long as we wanted to stay within the framework. We had to hack it a little bit to communicate with our data and our other HTML elements on the page.

While implementing this project, we had several new ideas about how such a visualization might work. For example, we wanted to show other features that were not directly associated with that loan, but was associated with the loan servicer (which is typically an organization). We would like to implement a 'secondary' view for such features, using a Pie Chart to indicate the % breakup of a loan servicer's loans corresponded to what sector.

## Online Demo

The system is implemented in Python and Javascript(protoviz) and runs as an HTML page. A working copy is available here KivaViz

Each loan is presented as a line. There are a number of dimensions for each loan

• The amount requested
• The amount raised so far
• Number of borrowers
• Rating for the field partner that has prepared the documents for the loan
• The number of loans that the field partner has posted
• Delinquency rate for the field partner (what percentage of loans are behind)
• Default rate for the partner
• Total amount of loans posted by the partner

The user selects a range for each dimension and the desirable loans are then highlighted. Each line is also clickable and will take the user to the loan page to make a purchase. Alternatively a user can click on the image and go to the page. As users hover over lines the image on the left gets updated to show the photo of the loan requester, giving the user a more personal feeling.

## Data Backend

Kiva provides a REST API for developers. The API exposes a number of Kiva functionalities to the developer. A developer can see the loans that are recently posted on the website, see the information for the field partner that has posted the loan or get details about loan repayments.

Surprisingly we spend most of our time on getting the Kiva API to work with our visualization tool. We wrote a Python script that calls the API and curates a data set that can be consumed in our protoviz tool. The following parameters are selected to be stored in the data set

• Borrower Name
• Number of borrowers
• Loan amount
• Amount funded
• URL to the image for the borrower
• Delinquency rate for the associated field partner
• Default rate for the field partner

Our code essentially treats two different streams of JSON objects as two database tables and inner joins them (the json stream for individual loans are inner joined with the data for the field partner). This is a heavy operation and results in a relatively heavy dataset from the web (300kb) we are planning to run the Python code as a cron job every 2 minutes but for demonstration a static snapshot of the output is used to prevent a large request load on Kiva server.

## Protovis

We used Protovis and Javascript for the front end. There were several nice interactions built in with Protovis, and we were able to quickly get to "a" visualization. Although we liked the new paradigm of functional programming modicum and the primitives provided, we believe this makes the toolkit less approachable for most programmers who have been trained in the procedural/OO programming paradigms.

Another thing we noticed is that the examples, although rendered in beautiful format, would often use very ornate and terse code. While that was useful in terms of 'beautiful' code, it was hard to understand for a beginner and generally hard to read to the third person. Another thing we noticed was that there were several ways of doing the same thing (for example pv.Scale can be used in many different ways) and these makes the examples inconsistent (and hard to follow). Many of data manipulation methods are missing too. Protoviz has implemented pv.sum and pv.max but surprisingly there is no pv.count and we had to implement it ourselves.

Using protovis also made us wonder about what kind of tools we should use for our final project, and at what level in the visualization toolkit should we be, if we were to write one. Having to fit in a new model (such as protovis) is difficult as opposed to a standard Java 2D/OpenGL like API which provide flexibility at the cost of lesser high level primitives.

In order to be able to talk to other html elements on the page we used javascript to avoid protovis's rigid framework.

## Use of Images as Anchors

We wanted to use images as anchors for users to click on, and to serve as a visual icon for a particular loaning opportunity. clicking on an image takes a user directly to the Kiva web page.

## Ideas and Questions to think about

• How should many vertical axis be placed for parallel co-ordinates within a single screenshot. Is there a lot of value associated with showing all the co-ordinates together (giving the user such context).
• How should we place 'anchors' or identifiers for a particular scenario in context of such parallel-co-ordinates. For example, when we put in images, where should these be places so that its not disruptive.

### About Tools such a Protovis

• What Tool, What Purpose, What Audience - The expressiveness <--> ease of use tradeoffs became clear to us.
• Readability of code - Can we build a toolkit where users always just tweak and make things "by example". Could we build a authoring UI on top of (say) Javascript which spews out javascript code. One idea, for example, would be to allow users to export Tableau graphics, and import in such a visualization tool and autogenerate the code that would be needed to realize such a graphic. Users can then vary the Tableau graphic and easily learn by tweaking.

### Turing Completeness for Visualization

Protovis to visualization is like SQL to databases. It is easy to work with the data as long as you want to do traditional visual manipulation but it makes it extremely difficult to make a more flexible tool. It made us wondering what would a turing complete visualization look like and how can one define and develop such a library.