Sunday, April 27, 2014

Striking a Balance

One thing that has been coming up quit frequently recently is the need to strike a balance between treating this project as a school project and treating it as a production piece of software as if from a software engineering company.

This has come up mostly as we realize that some things that make for good production level software actually cost money. Like real american dollars.

We really want to produce the best product possible and if we could maintain the illusion that we were a software engineering firm making a real life piece of software this would be ideal. But the fact is that we are not being paid for this (the opposite is actually the case), there is no company to fund development costs (all expenses come out of our pocket), and in all likely hood, the differences will not be missed by many (if any).

As poor college students this is turning out to be a difficult balance to strike. Do we pay a lot of money for a nice tls cert, or can we go the free self signed route? We have already invested money into things like presentation supplies and domain names. We keep having to address this issue and it is difficult.

I think that we are producing a professional quality product in the ways that we reasonably can--the coding. We have gone out of our way to use industry standard code practices in web applications. In this area the balance is clear, be as professional as possible. In the financial domain, it is less clear.

Server side Google+ and Facebook Authentication

David Strawn and I have been spending a lot of time recently beginning the implementation process of server side Google+ and Facebook authentication. We have decided to go with a Play plug-in called SecureSocial.

This has been a very educational experience for me, as I have gotten my hands dirty with the web application coding that up to this point had been done mainly by David alone. Having to edit the routes file, the .conf files, troubleshooting play specific annotations; these have all been new to me but very enjoyable.

This has also made me appreciate the work he has put in up to this point to fully immerse himself and understand the framework we have chosen, as it is not intuitive but once understood is very powerful.

We are hoping to have this functionality complete this week (and then I am really hoping we stop adding features and do a comprehensive testing and consolidation prior to the final product debut).

Presentation Reflections First Three

This last week the first three groups gave the second practice presentation. For me this marked the first time I had been a part of the presentation with about half of our groups presentation falling to me. I thought this went very well and people seemed to respond well to the portion I presented specifically.

The other two groups that presented have seemed to improve their presentations as well. The talks seemed much more focused and polished. I am looking forward to seeing the other three this coming week.

I am very optimistic that my participation in the presentation will help to improve my impact score in the grading scheme. With the release of the interim grades this last week it is apparent that impact is the area I should focus on in the remaining three weeks. Since a lot of focus was put on the group project proposals in the first part of the semester I am guessing the same will be true for the group presentations at the end.

Sunday, April 20, 2014

Presentation

I am very excited to be a part of the presentation tomorrow in a larger capacity than last time. I am being asked to present some specific functionality of the graph traversal's learning. I very much enjoy presenting and am glad for the opportunity.

I am slightly concerned that the transitions between James and myself will not be smooth but am confident that we will be able to do a sufficiently good job.

I also believe it will be very enlightening to see how the other groups have improved their presentations/applications in this round of presentation as compared to the last round. I think that our group had one of the stronger presentations the first time around. For the most part the groups did well but it was sometimes apparent that there was not much practice time spent on the presentation itself.

To assure this was not a problem that we were going to have Sonny, James, and I met for a few hours this afternoon constructing the specifics and practicing the presentation. Tomorrow the value of this work will be revealed I suppose.

Sunday, April 13, 2014

Learning Demonstration

My action item for this week is to create a demonstration of the learning functionality of our graph traversal algorithm. This is important, I believe, because it is one of the best features of our application and really sets it apart.

I am worried though, because it is not directly related to the user experience(UX), the user benefits from the learning but not instantaneously, a user really benefits from past user's experience. I am trying to balance the need to focus on the UX while still maintaining some amount of focus on the other stuff as well. The UX is very important, but there are things that are important as well but only relate to the UX in a tertiary fashion.

I am going to need to be sure to sufficiently emphasize the relation the demonstration has to the overall goal of the project as it relates to the user. There are other parties at play here, and this demonstration is the most important for potential investors, as well as for advertising. It should be interesting to go from here.

Need for User Logins

We have decided that it will be very important in the near future for the user to have the capability to log in and save progress during a traversal.

This realization came after our presentation when it was astutely pointed out that some of these diagnostic procedures may require a long time to complete, and if the progress is not saved it would be very unpleasant.

We are currently investigating ways to make this happen. I believe this will be part of upcoming action items.

Presentation Thoughts

After having presented this week I believe our project is doing very well. Being able to see the state of two other groups was very helpful and I am excited to see the rest of them tomorrow. It seems like every group so far is pretty much on the same track, functioning prototype with a need to complete the implementation of a few features. I thought that aesthetically our application is looking exceedingly good, and we have begun to seriously consider the user experience. I am very content with where this application is for the amount of time remaining, a pleasant surprise since I anticipated being in full blown panic mode by this time.

Sunday, April 6, 2014

Group Dynamics III

I think the group dynamics are getting better as we learn to work together. Some of the initial tension is gone as people have learned to trust one another to be good at what they do. There are still some communication issues, particularly on my end (it may be the case that I'm bad at explaining algorithms, which does not bode well for my intended future career in academia). Additionally, I have difficulty letting go of control. James is turning out to be an adroit and capable leader, I am just not used to being led. Spending a few years as the paramedic in charge of patient treatment in a 911 system will do that to you turns out. As I come to grips with not being in full control, other people have improved in their dynamics as well. This is a capable and pleasant group, and I am very happy with how this is playing out.

Aesthetics in design

I've begun to examine our specific user experience (UX) and after our last client meeting I realized there is an entire portion of the UX that I have neglected to even consider--the aesthetics.

This shouldn't come as a surprise, the best designs in the world come from people who are notoriously good at taking aesthetics into account. This is what makes companies like Apple and Starbucks so successful.

What is our aesthetic goal? Prof. Ackley described a choice of background image to specifically address our target audience. This is a very interesting idea. How can we through our aesthetic design choices create the "feel" that our targeted customer will be comfortable and happy with? It has to come from a concerted evaluation of who that is, and what they like. A Feng Shui for our application if you will.

Useful Features, a Reflection

In our last client meeting it was pointed out to us that the search box we had implemented was fraught with danger, a trap, a feature that had the potential to make the user experience (UX) worse rather than better. I must admit this took me by surprise. How can additional features be bad? Isn't increased functionality always a good thing? These are the questions I found myself asking and the answers changed how I look at application development.

How do I look at application development? Well first of all, I look at it with the dow eyes of a developer on his first project. Never before have I had to implement ANYTHING with a user in mind that wasn't a CS professor, TA, or fellow researcher. This is a totally new concept to me so perhaps my viewpoint isn't as refined, practiced, or good as other developers. I've always operated under the assumption that more features are better, and in my work it holds true for me. A tool that includes more motion planning algorithms is just better than one that doesn't--says the Alan of last week.

I've been forced to reflect on this though. As I cycle through the stages of grief for my dead search bar feature, I must analyze and eventually accept the premises that lead to it's death. This is my responsibility as a student.

What made it a bad feature? I am standing by the fact that it was a feature, I don't think that word should be defined to only include the good ones. If you start with the assumption that it was indeed a bad feature, then why?

It was bad because it was distracting. It provided a place for a user to do something unexpected and become distracted by the outcome. We are targeting a set of people that maybe don't want bells, whistles, or string edit distance assisted symptom definitions. It's too much. The UX needs to be simple and intuitive.

Overall, this has led me to view features different. I should no longer only ask is this feature functional, does it add capability to the application, but rather other questions. Is this feature right for my targeted user. Is this feature intuitive for them or align with my understanding of their expected technical skills. In the case of the search box of Mechanapp, it is not right, it is not intuitive, it is bad.

Is this acceptance Dr. Kübler-Ross?