Updated Group and Individual Timelines

Graph Traversal

Graph Traversal Example:

Below is an example of a small instance of how the graph traversal will interact with the user (as currently visualized), as well as how edge weights will be updated to facilitate learning.

Example graph state where we’ve initially determined that the user drives a sedan and the symptom is that it wont start.  Our traversal begins at the “Won’t Start” node.

At each step of the traversal we define and display the probabilities of each leaf node that exists down the tree as the product of the edge weights in the shortest path to the leaf. As we are at the “Won’t Start” node, the probabilities would be for example:

Out of Gas: 36%

Spark Plugs Are Bad: 24%

Battery is Dead: 32%

Starter Motor is Bad: 8%

These values are updated at each step of traversal to give the user an updating list of probable problems.

Traversal:

We do a greedy graph search using the edge weights defined by the probabilities p. We reach the “Turn over?” mode at which point the traversal needs user input. The probabilities associated with the edges out from this node are built from past traversals, i.e. what users have expressed in the past. The application will ask the user for input at this node, specifically asking if the engine turns over when the key is turned. Lets assume that the user responds that it does indeed turn over. We then proceed to the transition state, a state that does not require user input and will proceed to the next state based on edge weights. In this simplified example we then reach the answer state “Out of Gas”.

At this point we have an answer for the user, their car may be out of gas. We would inform the user that this is probably the problem and perhaps provide a link to a video showing how to add gas to their vehicle. At this point, we will wait again for user input. Specifically we want the user to tell us if this was the problem. For this example let’s assume that the car was not out of gas, and we haven’t fixed the problem. The user informs the application of this, and traversal continues by going back to the transition state and proceeding to the next leaf node--the answer state “Spark Plugs Are Bad”.

We again recommend a DIY process or a mechanic to fix the problem and prompt the user for feedback. Let us assume that this did indeed fix the user’s vehicle. At this point we trace back the path and update the probabilities of each transition to reflect the new data.

This new graph structure represents a better informed graph and will be used for the future sedan queries and all graphs inheriting from the sedan graph.

Group Work Week 1

Here are some thoughts on how the group has been working together so far after one week.

Overall I have a very positive impression of our group dynamic. It seems that everyone is both responsive, as well as willing to work hard this semester. Additionally it seems like our personalities will fit well together to say nothing of our CS skill sets--which I believe complement each other's almost ideally.

I am happy with where I have landed in the division of labor and believe I will be able to make a significant and novel contribution to the project through my domain.

I am sure there will inevitably be rough spots in the coming semester regarding the group, but it is encouraging that these haven't cropped up in week one.

We have almost completed the logistics portion of the project set up (repositories, cloud resources, etc). I think this will make our group interactions more productive and less banal moving forward.

Generalized Division of Labor

Having had a small amount of time to speak with the other group members we have discussed our strengths and come up with a high-level and tentative division of labor:

Sonny:
Sonny has extensive experience with web design both functionally and aesthetically which is wonderful as this is probably my weakest area personally. For this reason Sonny is spearheading the front-end of the web design.

David:
David has agreed to pursue the "back-end" of the interface which as I understand it will act as a layer between the UI and the algorithmic logic of the program.

James:
James has experience through work with databases (another area of knowledge I woefully lack) and subsequently is going to be heading the database work for now.

Alan:
My particular strengths lie in the algorithmic side of CS and as such I believe I will be well suited to addressing the algorithmic logic of both the graph traversal as well as the learning portion of the application. The group has agreed to make this an area of focus for me.

Client Meeting 1

After having our first client meeting one thing has become abundantly clear. It is time to hammer out the specifics. Up to this point, through the proposal process and in the very short time we had as a group prior to the meeting, the whole project has been discussed in the abstract. At the time of the meeting we had talked about action plans to take steps to solidify the ideas but had not actually done so. I think we would've been in a better position to have a successful client meeting if we had discussed actual implementation and design.

This is encouraging though, because the details are currently being addressed, and I believe that implies our next client meeting will be much more successful. Additionally, with an attempt having been made at some amount of division of labor, we will be able to more personally contribute to the next meeting--rather than staring at each other awkwardly until James spoke.

Ranking Conundrum

We are about to rank the proposals so that we can be placed into groups. This is really exciting because after listening to all of the proposals the last three days there are a number of projects that I find extremely interesting! It will be a difficult ranking process, especially where I will rank my own project which for whatever reason has lost some of its luster.

I am torn here. On one hand I think I will perform better this semester if I am working on a project that I find very interesting. I will find it more natural to remain engaged in the face of this, the most difficult and busy semester of my educational career. On the other hand, if I rank my project first--ahead of some projects that, embarrassingly, interest me more--and it is chosen, then I will be ahead of the curve on the "impact" portion of my grade, a concept which looms as an incorporeal boogie-man in the bedroom closet that is my uncountable fears regarding my last semester as an undergraduate.

I have tough decisions ahead.

Proposal Writing, the Aftermath

The proposal writing process was an educational experience. The task of creating a formal proposal document was new to me. I've had experiencing writing technical papers about research, as well as experience writing legal documents when I was a paramedic, but never before have I had to sell an idea in a formal document. Especially difficult was the balance between the "real" portion and the "pretend" portion. The real portion of course being the parts of the proposal written with the context of a 12 week project in an undergraduate CS class, and the pretend portions being things like the budget and support sections which due to the context of the semester long class had to be fabricated.

Regardless of this difficulty I found the writing process to be very educational as well as a tool for focusing my intents and taking a much more formal look at what it was exactly that I was proposing--an experience that will change the way I view future projects.