If there's one thing that today's festivities drove home to me, it's that organization is probably the most critical part of a successful (or at least coherent) pitch.
Parts of the pitches (today as well as last Monday) seemed to lack solid organization and planning. This led to wasted time, poor format, or repeated material. For example, one team had two speakers, but there appeared to be little coordination between what each was to talk about during the pitch. Each speaker basically went over the same set of points. In another pitch, it became clear the presentation hadn't been rehearsed for time when they burned through their material in about 4-5 minutes of what was supposed to be a 7-9 minute talk. There were also instances where a group member would answer a question or state something about the project, only for another group member to chime in with a contradiction a moment later. That last blunder isn't so much an issue with presentation prep as it is an issue with the team being on different pages about the project plans.
It's kind of hard for me to tell if my team's first presentation suffered from these errors. I know we didn't have a timing problem, as our pitch ran for about 8 minutes without any filler or time-wasting. I'd like to think the pitch we gave was orderly and on point. There wasn't really a chance for our team members to contradict each other, because I did almost all of the project speaking; other team members just introduced themselves and chimed in as appropriate for questions. A couple of the teams also lacked a solid conclusion, a flaw I'm well aware our presentation exhibited. But to be honest, besides giving a conclusion that's as strong as the introduction, I'm not sure what else to work on for the next presentation. I guess that's something I should ask Ackley, Nikan, one of my team members, or someone in the class about. Cause I'm sure the last pitch wasn't perfect (as nothing is).
Monday, April 14, 2014
Friday, April 11, 2014
Meeting notes and next steps - 4/11
At our meeting today, we basically agreed that there are a few major action items we need to complete before the end of the semester. Almost all of these were part of the original project proposal (seems so far back now), and the rest have come up in client meetings or as part of a product pitch. In no particular order, these are:
1.) User accounts - to save location in a current traversal to come back to later, at the very least. Saving the set of previous diagnoses would be really nice too but has a lower return on investment for the time.
2.) Ad placement - part of the revenue stream. At the last product pitch (and in the proposal), we stated we were going to use targeted ads. We need to research an API for this to make our lives easier, and implement it.
3.) Backtracking - this is nearly done. Allows user to cancel a question answer and return to the question again.
4.) Email box - the display is present, but not functional. This constitutes the "contact us" portion of the website for when users have a comment or issue to report with our diagnostic procedures or general things.
5.) Additional diagnostic charts - this is mostly my area. As of yesterday there are full charts for two topics in the database - cooling system and starting issues. We need at least a couple more, I'm currently thinking one for brakes and maybe one for vehicle noises.
I think this is all doable in the remaining time, but we need to keep it up. If we sag in the next week or two (which is possible, as many classes have re-upped their workloads from the spring break cool-down), we could get into some trouble. Again, all of these features are really required for us to claim that we successfully completed the project described in the proposal. We would also like to do a few other UI things to enhance the UX if we can. Some of these features are directly related to UX though, such as user accounts, backtracking, and the email box.
1.) User accounts - to save location in a current traversal to come back to later, at the very least. Saving the set of previous diagnoses would be really nice too but has a lower return on investment for the time.
2.) Ad placement - part of the revenue stream. At the last product pitch (and in the proposal), we stated we were going to use targeted ads. We need to research an API for this to make our lives easier, and implement it.
3.) Backtracking - this is nearly done. Allows user to cancel a question answer and return to the question again.
4.) Email box - the display is present, but not functional. This constitutes the "contact us" portion of the website for when users have a comment or issue to report with our diagnostic procedures or general things.
5.) Additional diagnostic charts - this is mostly my area. As of yesterday there are full charts for two topics in the database - cooling system and starting issues. We need at least a couple more, I'm currently thinking one for brakes and maybe one for vehicle noises.
I think this is all doable in the remaining time, but we need to keep it up. If we sag in the next week or two (which is possible, as many classes have re-upped their workloads from the spring break cool-down), we could get into some trouble. Again, all of these features are really required for us to claim that we successfully completed the project described in the proposal. We would also like to do a few other UI things to enhance the UX if we can. Some of these features are directly related to UX though, such as user accounts, backtracking, and the email box.
Wednesday, April 9, 2014
Client meeting notes - 4/9
Both Ackley and Nikan (our clients) agree: we need to focus more on the user experience (UX).
To this end, Sonny's action item for the week is to start implementing (and hopefully get close to finishing) a user account interface for our site. There are two main features this will give to our users. The first is to allow users to save their position in a graph traversal and come back later using their login; this feature is crucial, because some QuestionStates may require the user to go away for some time as they fiddle with the car. It's very important that they can come back and pick up right where they left off. The second is to save the successful traversals (diagnoses) that a user has performed. This feature is not as critical, but would be very nice for the UX. This will give them a kind of service history for their car, showing issues that have come up with it and how they were resolved. These could form the basis of a simple set of maintenance records for a user.
Alan is going to create a sort of demonstration that shows his graph algorithm in action. This will help the UX by showing them the types of things MechanApp does in the background to help them that they don't necessarily see in the UI. I think the end result of this task should be some kind of short video explaining the intelligence behind the system that can be watched from the MechanApp.net homepage.
David is working on backtracking still (along with Sonny), but it should be finished soon. This is another critical function that will allow the user to cancel an answer they have selected and go back to the question again. This is not only important if the user accidentally selects the wrong answer to a question, but it also will make the user feel MUCH more in control of the process, rather than some kind of semi-passive actor as they are now.
My main action item for the week is also related to the UX. I am adding at least one more full graph to the database, maybe two. Content is becoming an issue. Our demos and pitch are going to quickly lose steam if we are always going over the same diagnostic, "won't start". Adding some diagnostic procedures from different systems on a car (like brakes, cooling system, etc.) will show how flexible our system is. It will help to show that our system is a general framework for auto diagnostics, and not just a 'bag of tricks' of some kind. And it will definitely make the system more usable. Alan even said his Jeep is having some cooling system issues, and I'm hoping that adding a chart related to that could allow us to make him and his car the guinea pig for a real-life usage :)
To this end, Sonny's action item for the week is to start implementing (and hopefully get close to finishing) a user account interface for our site. There are two main features this will give to our users. The first is to allow users to save their position in a graph traversal and come back later using their login; this feature is crucial, because some QuestionStates may require the user to go away for some time as they fiddle with the car. It's very important that they can come back and pick up right where they left off. The second is to save the successful traversals (diagnoses) that a user has performed. This feature is not as critical, but would be very nice for the UX. This will give them a kind of service history for their car, showing issues that have come up with it and how they were resolved. These could form the basis of a simple set of maintenance records for a user.
Alan is going to create a sort of demonstration that shows his graph algorithm in action. This will help the UX by showing them the types of things MechanApp does in the background to help them that they don't necessarily see in the UI. I think the end result of this task should be some kind of short video explaining the intelligence behind the system that can be watched from the MechanApp.net homepage.
David is working on backtracking still (along with Sonny), but it should be finished soon. This is another critical function that will allow the user to cancel an answer they have selected and go back to the question again. This is not only important if the user accidentally selects the wrong answer to a question, but it also will make the user feel MUCH more in control of the process, rather than some kind of semi-passive actor as they are now.
My main action item for the week is also related to the UX. I am adding at least one more full graph to the database, maybe two. Content is becoming an issue. Our demos and pitch are going to quickly lose steam if we are always going over the same diagnostic, "won't start". Adding some diagnostic procedures from different systems on a car (like brakes, cooling system, etc.) will show how flexible our system is. It will help to show that our system is a general framework for auto diagnostics, and not just a 'bag of tricks' of some kind. And it will definitely make the system more usable. Alan even said his Jeep is having some cooling system issues, and I'm hoping that adding a chart related to that could allow us to make him and his car the guinea pig for a real-life usage :)
Tuesday, April 8, 2014
Presentation reflection
I think that, overall, we did pretty good on Monday.
It's kind of hard to tell if you're getting your points across during a presentation sometimes. I felt like I was explaining everything the way I meant to (mostly), but there's usually that doubt anyway. A couple other students in the class said the presentation was very clear, so I hope that's true. Our website looked good, as did our one-sheet handout (thanks Sonny!). I think the team looked pro; we were well-dressed and gave good introductions. The precise description I gave to everyone of the presentation plan really, really helped. It made everything smooth and predictable on our end because everyone knew already what was going to happen (or, at least, I did :) ).
I found Ackley's criticisms to be accurate. I'm going to talk to David or Sonny about adding some kind of field in the database like a 'title' for each QuestionState, which can be displayed in a larger font. That would help with presentations and demos, and also make the program feel more cohesive, I think. That's a pretty simple addition for a good return on investment for the User eXperience. Ackley also said the presentation didn't have a clear ending, it just kind of 'fizzled out' (or something like that). He was right, and that was a result of not correctly anticipating where I wanted to end the demo and not quite knowing what I was going to say to conclude. What I really needed was a quick review and summary to wrap it up and reiterate the main points. Next time...
It's kind of hard to tell if you're getting your points across during a presentation sometimes. I felt like I was explaining everything the way I meant to (mostly), but there's usually that doubt anyway. A couple other students in the class said the presentation was very clear, so I hope that's true. Our website looked good, as did our one-sheet handout (thanks Sonny!). I think the team looked pro; we were well-dressed and gave good introductions. The precise description I gave to everyone of the presentation plan really, really helped. It made everything smooth and predictable on our end because everyone knew already what was going to happen (or, at least, I did :) ).
I found Ackley's criticisms to be accurate. I'm going to talk to David or Sonny about adding some kind of field in the database like a 'title' for each QuestionState, which can be displayed in a larger font. That would help with presentations and demos, and also make the program feel more cohesive, I think. That's a pretty simple addition for a good return on investment for the User eXperience. Ackley also said the presentation didn't have a clear ending, it just kind of 'fizzled out' (or something like that). He was right, and that was a result of not correctly anticipating where I wanted to end the demo and not quite knowing what I was going to say to conclude. What I really needed was a quick review and summary to wrap it up and reiterate the main points. Next time...
Saturday, April 5, 2014
Meeting notes and work log - 4/5
We had a pretty productive meeting today (about 3 hours).
We selected a new background image for the website. Sonny is going to do the facelift we desperately need so it will identify more with our target audience (hobbyist mechanics). I am planning to get together next week with a friend that's into photography to take a custom photo for our background. I'm thinking something with my car, hood up, some tools laying around. You know. Mechanic type stuff.
We also discussed some bugs and new features we will implemented. I showed the group my newly redesigned "no start" diagnostic tree, which they liked. It has a higher branching factor so that it can be better pruned by Alan's prioritizing search, and has a consistent node numbering scheme (increasing in left-right depth-first search). I implemented and double-checked (hell, quintuple-checked) the database record for this new tree; it is currently in a separate copy of the database though, because a bug has arisen from the new structure (the code was supposed to work with this structure, but has shown it doesn't currently).
As far as presentation materials, I filled out most of the Business Model Canvas so we could use it as a reference to make our one-sheet. Sonny is working on the one-sheet with the highlights of that BMC document. I made the short Powerpoint presentation (two slides - title/intro and technical components) and it's ready to go. I now need to rehearse my talking points (I'm the main presenter for our pitch on Monday) and talk a bit more with the group about the flow (in particular, with my 'driver' Sonny). I'm going to make note cards for this purpose; I saw a few people use them for the individual product pitches way back, and it seemed to help.
We selected a new background image for the website. Sonny is going to do the facelift we desperately need so it will identify more with our target audience (hobbyist mechanics). I am planning to get together next week with a friend that's into photography to take a custom photo for our background. I'm thinking something with my car, hood up, some tools laying around. You know. Mechanic type stuff.
We also discussed some bugs and new features we will implemented. I showed the group my newly redesigned "no start" diagnostic tree, which they liked. It has a higher branching factor so that it can be better pruned by Alan's prioritizing search, and has a consistent node numbering scheme (increasing in left-right depth-first search). I implemented and double-checked (hell, quintuple-checked) the database record for this new tree; it is currently in a separate copy of the database though, because a bug has arisen from the new structure (the code was supposed to work with this structure, but has shown it doesn't currently).
As far as presentation materials, I filled out most of the Business Model Canvas so we could use it as a reference to make our one-sheet. Sonny is working on the one-sheet with the highlights of that BMC document. I made the short Powerpoint presentation (two slides - title/intro and technical components) and it's ready to go. I now need to rehearse my talking points (I'm the main presenter for our pitch on Monday) and talk a bit more with the group about the flow (in particular, with my 'driver' Sonny). I'm going to make note cards for this purpose; I saw a few people use them for the individual product pitches way back, and it seemed to help.
Friday, April 4, 2014
Meeting and task notes - 4/4
We are taking the things discussed in our client meeting and putting them into action.
Our next feature to be implemented is graph backtracking, where people can cancel the answer that brought them to a present state and go back to the previous one. To me, this feature is just critical for the user experience. If someone makes a mistake, or doesn't like where the process is leading them, they need to be able to take a bit of control and retreat to some previous state. This feature doesn't seem like it will be too costly, and will add tremendous value to our application.
Tomorrow, the team and I will meet for a code review and clean up session. We have a list of issues and things we intend to fix during this time. Some of these are for cleanliness, others are for robustness. For example, we are looking to change the way my code casts objects from MongoDB documents to POJO's tomorrow to be less dangerous. This will also be a good opportunity for everyone to look more closely at the other components of the project so we can all better understand the other modules we may not have directly worked on.
For tonight and before the meeting tomorrow, I'm mostly working on the presentation materials for Monday. I filled out most of the Business Model Canvas and made the technical slide. Tomorrow, the team and I are going to use the BMC as a guide to making our one-sheet handout for Monday. Additionally, we need to discuss presentation planning and format and rehearse it a bit.
One day at a time I guess. Weekends are for psychology students.
Our next feature to be implemented is graph backtracking, where people can cancel the answer that brought them to a present state and go back to the previous one. To me, this feature is just critical for the user experience. If someone makes a mistake, or doesn't like where the process is leading them, they need to be able to take a bit of control and retreat to some previous state. This feature doesn't seem like it will be too costly, and will add tremendous value to our application.
Tomorrow, the team and I will meet for a code review and clean up session. We have a list of issues and things we intend to fix during this time. Some of these are for cleanliness, others are for robustness. For example, we are looking to change the way my code casts objects from MongoDB documents to POJO's tomorrow to be less dangerous. This will also be a good opportunity for everyone to look more closely at the other components of the project so we can all better understand the other modules we may not have directly worked on.
For tonight and before the meeting tomorrow, I'm mostly working on the presentation materials for Monday. I filled out most of the Business Model Canvas and made the technical slide. Tomorrow, the team and I are going to use the BMC as a guide to making our one-sheet handout for Monday. Additionally, we need to discuss presentation planning and format and rehearse it a bit.
One day at a time I guess. Weekends are for psychology students.
Wednesday, April 2, 2014
Client meeting reaction - 4/2
Whew. That got a little heated. In a good way, though.
Ackley told us some stuff we really need to hear about that state of our application. Things that are much harder to see from the 'inside' as the development team. Things like user experience and what a new user sees when they first come to our little world. It was tempting to get defensive about some of the criticisms, but I think they mostly had merit. I'm actually glad we can get honest feedback like that. Per today, we are going to change the look-and-feel of the page; it currently has a kind of soft, open-road type of theme, which we will change to a more "mechanics and garage" type style (this is, after all, a mechanic's tool, no?).
There are also some usability features we desperately need. One that came up today is the ability to backtrack manually in the graph search (i.e. cancel a selection and go back to a previous one). To me, this feature is totally critical - users need to be able to have more control over where they are going. We could also use more info at each state about why that state was selected - e.g. "Since you said the plugs are not sparking, we are going to check...". Something as simple as that additional content would greatly help our user experience.
And then there's that search box. A thorn in my side from day one. We (somewhat reluctantly) agreed to add a search box for users to enter stuff into to try and parse out the issue they wish to diagnose with their car. While it could be a good feature, it currently is unbalanced on it's return on investment (ROI) in my mind. The drop-down boxes are a good interface, one that the user should understand, and one they have to use if they, for instance, want to buy auto parts online anyway. So, I think for now we are going to scrap the search box. Ackley is correct that, at present, it's more of a 'trap' or confusion to users than a help.
Overall, it was a good meeting and I think we got some good feedback as well as bad.
Ackley told us some stuff we really need to hear about that state of our application. Things that are much harder to see from the 'inside' as the development team. Things like user experience and what a new user sees when they first come to our little world. It was tempting to get defensive about some of the criticisms, but I think they mostly had merit. I'm actually glad we can get honest feedback like that. Per today, we are going to change the look-and-feel of the page; it currently has a kind of soft, open-road type of theme, which we will change to a more "mechanics and garage" type style (this is, after all, a mechanic's tool, no?).
There are also some usability features we desperately need. One that came up today is the ability to backtrack manually in the graph search (i.e. cancel a selection and go back to a previous one). To me, this feature is totally critical - users need to be able to have more control over where they are going. We could also use more info at each state about why that state was selected - e.g. "Since you said the plugs are not sparking, we are going to check...". Something as simple as that additional content would greatly help our user experience.
And then there's that search box. A thorn in my side from day one. We (somewhat reluctantly) agreed to add a search box for users to enter stuff into to try and parse out the issue they wish to diagnose with their car. While it could be a good feature, it currently is unbalanced on it's return on investment (ROI) in my mind. The drop-down boxes are a good interface, one that the user should understand, and one they have to use if they, for instance, want to buy auto parts online anyway. So, I think for now we are going to scrap the search box. Ackley is correct that, at present, it's more of a 'trap' or confusion to users than a help.
Overall, it was a good meeting and I think we got some good feedback as well as bad.
Subscribe to:
Posts (Atom)