I'll just give my general thoughts on each group, some of which I may have already said in class. This is mostly just from my memory, but serves as a set of impressions.
Automaton:
Good:
Game looks freakin sweet. Animations and color scheme on it are vivid and engaging. Presentation was better organized this time around.
Not so good:
I think they really, really need to take the intro to the game to a more basic level. They kind of just jump in and say "there's all kinds of buttons and stuff here" and describe a small subset of them. I think it leaves the audience confused about the game, even though we're computer scientists (the subject the game is supposed to teach). I think it would be wise to leave out the more complicated puzzles and instead do a very thorough puzzle that explains each piece of the solution and it's function. I guess it's late for this, but I also think it would be a lot less overwhelming to new players if many/most of the buttons are disabled or made invisible in the early puzzles.
Visual Scheduler:
Good:
Once again, their product is looking mighty fine. This group is on track to win "project of the year", in my opinion. Their tool is clearly useful, has an easy interface, and has a clear market. Hell, the people in the class would probably use this thing if it were to stick around. It definitely seems to beat the existing MyUNM facilities. The idea raised about asking the audience for classes to add is very worthwhile.
Not so good:
Their presentation improved, but they could still use more rehearsal; sometimes it seemed like they weren't clear on where to go next. Overall, I found the presentation to be pretty strong though.
G.E.R.A:
Good:
Ben gave a stronger speech this time. He was pretty organized and to the point, without really looking back at his slides for reference (something I personally need to work on). One thing I really liked is how Justin was following along with Ben's talk and updating the powerpoint presentation in the background without being asked. I'd like to implement something similar for our next presentation. Their demo went pretty well overall and the site looks good.
Not so good:
The fumble by Ben, of course, but it wasn't such a huge deal. I do agree with Ackley that another member of the group (probably Justin) should have tried to provide an assist there. I also agree with one of the class members that the demo should involve completion of some kind of mission, as it's the core unit of work for the application.
Monday, April 28, 2014
Wednesday, April 23, 2014
Reaction to 'leaders only' client meeting
It wasn't so much as a meeting as it was an interview.
I had thought that I was going to be seeing both Nikan and Ackley at the same time; not sure why I thought that, since the time slots were unchanged (and thus they could only schedule one at a time). There were a set of questions asked of me, which I expected. Some were about the project timeline and how closely it was followed; having looked at the original team timeline recently, I was pleased to see we actually were in sync with it pretty well. Others were about the team dynamics; overall, I've been quite happy with my team and the work they do. And yet other questions were about my experience as a leader and what I would do differently. I think my main thought on the last one was that I should have kept better tabs on my team members' assigned tasks and how they were being implemented to avoid ambiguity, confusion, or stalling. I do think that overall I've been a pretty good team leader and I'd like to think my group is happy with my performance.
I'm now wondering what the last two class sessions will look like (Monday after next and the one following). Are we going to do more group presentations? I would hope not. Are we going to have lectures like when the class began? My best guess is that were going to have lectures/discussions about the experience of the class or something like that, but who knows (except Ackley, I guess).
I had thought that I was going to be seeing both Nikan and Ackley at the same time; not sure why I thought that, since the time slots were unchanged (and thus they could only schedule one at a time). There were a set of questions asked of me, which I expected. Some were about the project timeline and how closely it was followed; having looked at the original team timeline recently, I was pleased to see we actually were in sync with it pretty well. Others were about the team dynamics; overall, I've been quite happy with my team and the work they do. And yet other questions were about my experience as a leader and what I would do differently. I think my main thought on the last one was that I should have kept better tabs on my team members' assigned tasks and how they were being implemented to avoid ambiguity, confusion, or stalling. I do think that overall I've been a pretty good team leader and I'd like to think my group is happy with my performance.
I'm now wondering what the last two class sessions will look like (Monday after next and the one following). Are we going to do more group presentations? I would hope not. Are we going to have lectures like when the class began? My best guess is that were going to have lectures/discussions about the experience of the class or something like that, but who knows (except Ackley, I guess).
Monday, April 21, 2014
Reflection on the presentations today
I think we did really well today. When it was first announced a week ago that we would be doing the presentations again next week, I wasn't quite sure what we should change for the next one. Overall, we received pretty good feedback from both the students and Ackley. But clearly, as shown by today, there was room for improvement.
One thing that I think made today's a lot better was our use of Prezi rather than PowerPoint. This made the presentation more visually appealing, and having a few more slides really helped me to stay on track, I think. It was only a few days ago that I decided both me and Alan should have speaking roles in the presentation. I wanted to change the demo so that there was kind of a "user-version" (the one I gave), which just showed how the application functions in normal use. Alan then gave the "backend-version", which gave more in-depth info and demonstration of some of the behind-the-scenes intelligent choices the application makes. I think this kind of two demo approach really improved how we got our message across. When done this way, the audience gets to see both of whats above and under the covers. Alan did a great job explaining the graph search we use and it's purpose, I thought. There were some questions about other stuff we could have added to the presentation; I would like to add more stuff, but don't think we can really afford to do so with a 9 minute hard limit. I kind of wish that limit would get extended to something like 13-15 minutes. Perhaps it will be a little more forgiving for the final presentation since we have like 2 hours (rather than 100 minutes for 6 groups).
I think the other groups I saw today also improved. I really liked PowderAde's presentation. Kishore did a super good job at explaining similar apps, what they do, and what they don't do that PowderAde does. The style of his presentation was spot-on, I thought; kind of snarky, but in a good, business-shark kind of way. David Strawn was suggesting that we could do something similar by showing what your average car repair online forum looks like (they're pretty hideous), as it's about the only thing we could compare our application to. After all, part of the inspiration for this project was the belief that car forums are very useful for all of the communal car history knowledge they collect (common causes of certain problems on specific cars), but that their knowledge base is vague and hard to quantify.
One thing that I think made today's a lot better was our use of Prezi rather than PowerPoint. This made the presentation more visually appealing, and having a few more slides really helped me to stay on track, I think. It was only a few days ago that I decided both me and Alan should have speaking roles in the presentation. I wanted to change the demo so that there was kind of a "user-version" (the one I gave), which just showed how the application functions in normal use. Alan then gave the "backend-version", which gave more in-depth info and demonstration of some of the behind-the-scenes intelligent choices the application makes. I think this kind of two demo approach really improved how we got our message across. When done this way, the audience gets to see both of whats above and under the covers. Alan did a great job explaining the graph search we use and it's purpose, I thought. There were some questions about other stuff we could have added to the presentation; I would like to add more stuff, but don't think we can really afford to do so with a 9 minute hard limit. I kind of wish that limit would get extended to something like 13-15 minutes. Perhaps it will be a little more forgiving for the final presentation since we have like 2 hours (rather than 100 minutes for 6 groups).
I think the other groups I saw today also improved. I really liked PowderAde's presentation. Kishore did a super good job at explaining similar apps, what they do, and what they don't do that PowderAde does. The style of his presentation was spot-on, I thought; kind of snarky, but in a good, business-shark kind of way. David Strawn was suggesting that we could do something similar by showing what your average car repair online forum looks like (they're pretty hideous), as it's about the only thing we could compare our application to. After all, part of the inspiration for this project was the belief that car forums are very useful for all of the communal car history knowledge they collect (common causes of certain problems on specific cars), but that their knowledge base is vague and hard to quantify.
Saturday, April 19, 2014
Presentation plans, project next steps
I'm hoping the next project pitch will be noticeably better than the first. To this end, we are going to use Prezi (which is pretty freakin sweet) rather than plain 'ol PowerPoint. Our demo is now a 2-man operation: I will run through a diagnostic as a user (no graph display or anything on the side, just answering questions like normal), then Alan is going to use a combination of the program and a Prezi show to show how his greedy graph search makes intelligent choices. Overall, I think our presentation is going to be more smooth and interesting with the use of Prezi as a guide in the background. I also think it's going to help me stay on point and get all of my points across.
On the project side, we're chugging along, but I'm growing more concerned about the amount of stuff we're slated to do before projects' end. We have user logins, but need to add security to them; also the actual functionality of user accounts (such as saving the location of a user in a traversal) is not implemented. We also said we are going to add a mechanism for users to add comments to QuestionStates; I have written the storage backend for that, but the UI has not been written (it has been started). We still do our development and demos running locally, and I'm getting worried that a deployed version of the site will have unforeseen issues. We have deployed and ran it before, but not steadily. I think these things are all going to work out, but I guess this is one of those parts of the process where the pressure and stress builds.
On the project side, we're chugging along, but I'm growing more concerned about the amount of stuff we're slated to do before projects' end. We have user logins, but need to add security to them; also the actual functionality of user accounts (such as saving the location of a user in a traversal) is not implemented. We also said we are going to add a mechanism for users to add comments to QuestionStates; I have written the storage backend for that, but the UI has not been written (it has been started). We still do our development and demos running locally, and I'm getting worried that a deployed version of the site will have unforeseen issues. We have deployed and ran it before, but not steadily. I think these things are all going to work out, but I guess this is one of those parts of the process where the pressure and stress builds.
Monday, April 14, 2014
Reaction to 2nd set of product pitches
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).
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).
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)