There it is, the final blog of my CS3216 journey. This is rather a short one because I've mentioned all the things I've learned from the previous blogs...
I mentioned in my first blog that "I want to learn how to follow my heart and soul". Frankly I didn't have a clear idea of what I expected to learn at that time, so I just put that vague statement :-P. But now after CS3216 is finished, I realize that the statement is actually kinda true. It's what I want to learn and what I have learned from CS3216. I've learned a lot of technical (HTML5, Facebook...) and non-technical (business, entrepreneurship, project management) stuff. But the most important thing for me is I've learned to do what I really want to do.
CS3216 made me skip a lot of classes. I went to 2-hour mid-term exams with the knowledge acquired from 30-minute studying (and of course my grades suffered!). But I'm fine with it. I'm happy with spending the rest of my time doing things that really matter to me. I used to the guy who tried to cover too much ground without exploring anything in depth. CS3216 has changed me...
But it doesn't mean I've done the right thing. The greatest thing about CS3216 for me is the feeling that I could've done better. I could've managed my time more effectively to achieve a much better balance. My bad grades this semester is the tuition fee for all the lessons I've learned (quite cheap I think :-P). CS3216 has helped me realized that I still have A LOT more to improve. I'm very thankful for that :-)
Thanks Prof Ben and all my CS3216 classmates. I've had an amazing semester :-)
Monday, November 14, 2011
Sunday, November 13, 2011
Final Project #3: Technology or business?
This is the 3rd and the final part of this blog series about my final project journey. Among the experiences I've had with CabSG, this one is probably the best of all.
As I already mentioned in the second part of the series, CabSG originally started quite differently from what we have now. The original idea was taxi sharing, which is quite an engineering challenge. It requires an efficient algorithm to match passengers base on their boarding time, location, and direction. The system has to be able to deal with the constant-changing data and able to deliver the best user experience. Being engineering-oriented, I was really keen on implementing that idea. But it is not practical. It's challenging but not suitable to be used in real life. So we changed to something less technical but a lot more useful: taxi booking, fare calculator, and taxi stand finder. But then we had to think about how to make our app really stand out without the hard-core stuff...
And then it came to us. We asked ourselves "since we're doing a taxi booking app, why not partner with a taxi company to do a booking system for them?". Currently only Comfort and SMRT have mobile booking apps. The rest (Premier, Transcab, Prime...) don't have the resources required to implement such a system. So why not work with them? So we decided to talk to the taxi companies to see what they think about our app. And among them, Premier cab is the most interested after listening to our initial pitch. They scheduled a meeting with us to discuss more about the partnership. To my surprise, Premier took us very seriously regardless the fact that we're students. We had a meeting (yes, it's a real business meeting) with their senior managers. The meeting went quite well. We got a good lead and made a good impression. We're gonna discuss this further after exams.
The meeting is the best experience I've had with CS3216, and this experience has changed my mindset significantly. I used to think that a good idea is something unique and hard to do. But now I realize that a good idea is an idea that can sell. Implementing an idea (the technology part) is not hard, but selling it (the business part) is really difficult. That's why pure engineers can't do good businesses even though they can get all the technology right. Technology and business always go together and are equally important. One cannot only focus on one and ignore the other.
I'm very grateful for this wonderful journey with CabSG. It has taught me a lot of things that I can never learn from normal school projects. We're still not done yet. There are a lot of things left to do to make CabSG a successful app. But overall, we've done a great job!
As I already mentioned in the second part of the series, CabSG originally started quite differently from what we have now. The original idea was taxi sharing, which is quite an engineering challenge. It requires an efficient algorithm to match passengers base on their boarding time, location, and direction. The system has to be able to deal with the constant-changing data and able to deliver the best user experience. Being engineering-oriented, I was really keen on implementing that idea. But it is not practical. It's challenging but not suitable to be used in real life. So we changed to something less technical but a lot more useful: taxi booking, fare calculator, and taxi stand finder. But then we had to think about how to make our app really stand out without the hard-core stuff...
And then it came to us. We asked ourselves "since we're doing a taxi booking app, why not partner with a taxi company to do a booking system for them?". Currently only Comfort and SMRT have mobile booking apps. The rest (Premier, Transcab, Prime...) don't have the resources required to implement such a system. So why not work with them? So we decided to talk to the taxi companies to see what they think about our app. And among them, Premier cab is the most interested after listening to our initial pitch. They scheduled a meeting with us to discuss more about the partnership. To my surprise, Premier took us very seriously regardless the fact that we're students. We had a meeting (yes, it's a real business meeting) with their senior managers. The meeting went quite well. We got a good lead and made a good impression. We're gonna discuss this further after exams.
The meeting is the best experience I've had with CS3216, and this experience has changed my mindset significantly. I used to think that a good idea is something unique and hard to do. But now I realize that a good idea is an idea that can sell. Implementing an idea (the technology part) is not hard, but selling it (the business part) is really difficult. That's why pure engineers can't do good businesses even though they can get all the technology right. Technology and business always go together and are equally important. One cannot only focus on one and ignore the other.
I'm very grateful for this wonderful journey with CabSG. It has taught me a lot of things that I can never learn from normal school projects. We're still not done yet. There are a lot of things left to do to make CabSG a successful app. But overall, we've done a great job!
Thursday, November 10, 2011
Final Project #2: Idea and team
In the second part of this blog series, I'd like to revisit the discussion we had in the case study: "Idea first or team first?". I'm gonna share what my team has gone through and my thoughts on the topic based on my experience.
Our project idea started from our HTML5 assignment - Carpool. After Carpool, Deepan, Jason and I realized that it made more sense having a taxi sharing app rather than a carpooling app, simply because taxi sharing could give users greater financial benefits that could motivate them to use the app. We pitched the idea to the class during the Pitching Party and got our 4th member, Joey. At that time we were all very excited. The idea was really promising and interesting to us.
But then turned out we were wrong. After spending a whole week discussing and consulting Prof Ben, Kok Wee, and some other people, we found out that it was not worth it to implement the idea due to these reasons:
- Taxi fare in Singapore is not that expensive. The maximum amount one has to pay for a ride may be up to $30 only, much more tolerable than, say, in NYC or other big cities.
- Singaporeans don't like sharing stuff, especially with strangers. The culture here is not really suitable for a taxi sharing app to succeed. Most of the people we talked to said they'd prefer taking a cab alone rather than asking strangers to share the ride. And since the taxi fare is not that high, sharing to them is not necessary.
- The possibility to get a match is very low. The prerequisite for our app to work is a large user base, but even if we could get like 10,000 users, the chance for some of them to be at the same place, at the same time and going to the same direction is extremely low. And if they can't find a match after a few times trying the app, they'll possibly never use it again.
So that idea was pretty much over for us. After 2 weeks we went back to where we started. It was too late for us to switch idea entirely, and also we couldn't come up with anything else. So we decided to stick to the idea of a taxi app, but this time focus more on the features that users would actually use: 1-click cab booking, fare calculator, and taxi stand finder. We wanted to build something simple and yet could benefit many people. We focused on making a nice, easy-to-use UI to provide users with the best UX possible. After 4 weeks, Cab.SG was born, available on both web, Android, and iPhone. At this moment we already have 100+ downloads (and counting) on Android app store after 1 week.
So what's the morale of this story? How is this related to the discussion topic I mentioned earlier? It turns out that in a project with a very tight deadline, idea does matter a lot. It is much easier and less painful if the team can get the idea right at the first place. When the idea is right, the team can focus all their energy on implementing the idea and make the best out of that short period of time. But it's normally not the case for most teams including us. It's very hard to get everything right at the very beginning. We have to try out things first in order to know if they're good or not. And that costs time. What if we try and fail? We will have to do everything all over again. And the only thing that can salvage the project at this point is the ability of a good team. I have a belief that good teams can always finish strong regardless of the difficulties and obstacles that get into their ways. In our case, even though we faced a lot of hard time, we still manged to work it out as long as we worked together.
So to sum up, in my own opinion, idea matters, but good team is the most important element of a successful project. A good team can always figure out a good idea and implement it nicely.
...And I'm moving closer to the final blog...
Our project idea started from our HTML5 assignment - Carpool. After Carpool, Deepan, Jason and I realized that it made more sense having a taxi sharing app rather than a carpooling app, simply because taxi sharing could give users greater financial benefits that could motivate them to use the app. We pitched the idea to the class during the Pitching Party and got our 4th member, Joey. At that time we were all very excited. The idea was really promising and interesting to us.
But then turned out we were wrong. After spending a whole week discussing and consulting Prof Ben, Kok Wee, and some other people, we found out that it was not worth it to implement the idea due to these reasons:
- Taxi fare in Singapore is not that expensive. The maximum amount one has to pay for a ride may be up to $30 only, much more tolerable than, say, in NYC or other big cities.
- Singaporeans don't like sharing stuff, especially with strangers. The culture here is not really suitable for a taxi sharing app to succeed. Most of the people we talked to said they'd prefer taking a cab alone rather than asking strangers to share the ride. And since the taxi fare is not that high, sharing to them is not necessary.
- The possibility to get a match is very low. The prerequisite for our app to work is a large user base, but even if we could get like 10,000 users, the chance for some of them to be at the same place, at the same time and going to the same direction is extremely low. And if they can't find a match after a few times trying the app, they'll possibly never use it again.
So that idea was pretty much over for us. After 2 weeks we went back to where we started. It was too late for us to switch idea entirely, and also we couldn't come up with anything else. So we decided to stick to the idea of a taxi app, but this time focus more on the features that users would actually use: 1-click cab booking, fare calculator, and taxi stand finder. We wanted to build something simple and yet could benefit many people. We focused on making a nice, easy-to-use UI to provide users with the best UX possible. After 4 weeks, Cab.SG was born, available on both web, Android, and iPhone. At this moment we already have 100+ downloads (and counting) on Android app store after 1 week.
So what's the morale of this story? How is this related to the discussion topic I mentioned earlier? It turns out that in a project with a very tight deadline, idea does matter a lot. It is much easier and less painful if the team can get the idea right at the first place. When the idea is right, the team can focus all their energy on implementing the idea and make the best out of that short period of time. But it's normally not the case for most teams including us. It's very hard to get everything right at the very beginning. We have to try out things first in order to know if they're good or not. And that costs time. What if we try and fail? We will have to do everything all over again. And the only thing that can salvage the project at this point is the ability of a good team. I have a belief that good teams can always finish strong regardless of the difficulties and obstacles that get into their ways. In our case, even though we faced a lot of hard time, we still manged to work it out as long as we worked together.
So to sum up, in my own opinion, idea matters, but good team is the most important element of a successful project. A good team can always figure out a good idea and implement it nicely.
...And I'm moving closer to the final blog...
Saturday, November 5, 2011
Final Project #1: Application framework
I'm going to start this blog series about the final project. I have to write multiple posts because there are so many things to talk about (and also it's a nice trick to increase the number of posts haha :P). This one is all about the lessons I've learned from developing an app with Sencha Touch.
Our team were quite confused at the first place about whether or not to do a native app. We obviously wanted to develop a mobile app, but we were afraid that the learning curve of native app development would slow down our progress. Also we wanted our app to run on multiple platforms in order to get a large user base. So we chose HTML5 and PhoneGap, which seemed like a perfect solution: learning curve would be significantly reduced since we were all familiar with HTML and Javascript, and also PhoneGap supported both iOS and Android. That sounded like the best approach for us. But reality has proven the opposite...
The first PhoneGap test was fine. PhoneGap worked well with both iOS and Android as advertised. But we didn't realize that the real problem lied in the application itself, not PhoneGap. As suggested by experienced PhoneGap developers, we chose Sencha as the framework for our app. Sencha is a good framework based on ExtJS, which has a really strong community. But the more we used Sencha, the more we became less confident in our choice. Here are the reasons:
- Poor documentation: Like all other frameworks, Sencha requires time to learn. But the learning curve is much worse than JQuery or Prototype because of poor documentation. For example, the API Docs for Ext.Form.Search says "Wraps an HTML5 search field. See FormPanel for example usage." When I went over to the Ext.FormPanel docs, there's absolutely nothing...It took us too much time to learn things like Panel, Component, Extension, which could be picked up very easily with good tutorials and examples.
- Bugs, bugs, and bugs: Sencha is super BUGGY! We spent hours or even days trying to make something work the way we wanted to just to find out in the end that it was a permanent Sencha bug that was not yet resolved. There are things that can be done with JQuery in 15 minutes but took us 3 hours with Sencha with most of the time being spent on wondering why the heck it didn't work.
- Ugly codes and poor structure: Javascript is a loosely typed language. Sencha is meant to make it more
structure with OOP and MVC. But our attempts to create a well structured javascript application didn't end really well. Most of the time we ended up using tricks and hacks to get around the weird behaviors of Sencha. As a programmer, I'm very frustrated about ugly codes, but there's not much I can do about it...
Sencha has slowed down our progress quite a lot. Our initial aim to release the beta version 2 weeks ago was completely backfired. Now thinking back it's all clear to us that we should have chosen to go native at the first place. The learning curve wouldn't be much different from Sencha, and yet we could enjoy the native look and feel. But as people normally say "Good judgement comes from experience, and experience comes from bad judgement", I'm glad that I've gained such a valuable experience. Sencha did pose a lot of difficulty to us, but we have a great team who can overcome all obstacles and challenges. We'll keep developing with Sencha and creating the best app possible. Only a few days to go...
Our team were quite confused at the first place about whether or not to do a native app. We obviously wanted to develop a mobile app, but we were afraid that the learning curve of native app development would slow down our progress. Also we wanted our app to run on multiple platforms in order to get a large user base. So we chose HTML5 and PhoneGap, which seemed like a perfect solution: learning curve would be significantly reduced since we were all familiar with HTML and Javascript, and also PhoneGap supported both iOS and Android. That sounded like the best approach for us. But reality has proven the opposite...
The first PhoneGap test was fine. PhoneGap worked well with both iOS and Android as advertised. But we didn't realize that the real problem lied in the application itself, not PhoneGap. As suggested by experienced PhoneGap developers, we chose Sencha as the framework for our app. Sencha is a good framework based on ExtJS, which has a really strong community. But the more we used Sencha, the more we became less confident in our choice. Here are the reasons:
- Poor documentation: Like all other frameworks, Sencha requires time to learn. But the learning curve is much worse than JQuery or Prototype because of poor documentation. For example, the API Docs for Ext.Form.Search says "Wraps an HTML5 search field. See FormPanel for example usage." When I went over to the Ext.FormPanel docs, there's absolutely nothing...It took us too much time to learn things like Panel, Component, Extension, which could be picked up very easily with good tutorials and examples.
- Bugs, bugs, and bugs: Sencha is super BUGGY! We spent hours or even days trying to make something work the way we wanted to just to find out in the end that it was a permanent Sencha bug that was not yet resolved. There are things that can be done with JQuery in 15 minutes but took us 3 hours with Sencha with most of the time being spent on wondering why the heck it didn't work.
- Ugly codes and poor structure: Javascript is a loosely typed language. Sencha is meant to make it more
structure with OOP and MVC. But our attempts to create a well structured javascript application didn't end really well. Most of the time we ended up using tricks and hacks to get around the weird behaviors of Sencha. As a programmer, I'm very frustrated about ugly codes, but there's not much I can do about it...
Sencha has slowed down our progress quite a lot. Our initial aim to release the beta version 2 weeks ago was completely backfired. Now thinking back it's all clear to us that we should have chosen to go native at the first place. The learning curve wouldn't be much different from Sencha, and yet we could enjoy the native look and feel. But as people normally say "Good judgement comes from experience, and experience comes from bad judgement", I'm glad that I've gained such a valuable experience. Sencha did pose a lot of difficulty to us, but we have a great team who can overcome all obstacles and challenges. We'll keep developing with Sencha and creating the best app possible. Only a few days to go...
Friday, October 14, 2011
What went wrong in Assignment 2 and the lessons I've learned for Final Project
Assignment 2 is way over, but there're still a lot of things to think about. Honestly saying, our assignment 2 was not close to my expectation. We faced a lot of non-technical problems that in the end made it so difficult for us to finish the assignment nicely. Here are what went wrong for us:
1. Miscommunication:
I admit that our team members didn't communicate well with each other, and most of the time we didn't know what the others were doing. We were too focused on working on our own tasks. And in the end, integration was a real pain. It's very difficult (if not say almost impossible) to join different pieces of a puzzle if they don't perfectly fit together.
2. Pre-planning is important, but we overlooked:
We spent too little time on meeting and discussion. We never analyzed the potential problems and difficulties the assignment might face. Also UI mockups, project timeline, and development process were not given enough attention. We only focused on feature list and individual tasks. Because of the lack of pre-planning, we underestimated the difficulty of the assignment, which led us to the next fault:
3. Procrastination:
We didn't start working until week 2 (assignment 2 was given only 3 weeks to complete). Because we overlooked the difficulties and challenges, we felt no rush to start doing things early. And the result is obvious: Camping in Com1 with last minute panic. It's so ironic that only at the end of the assignment did we recognize the need to start things early. That made the deadline day the most painful days I've had in my NUS life so far...
4. Teamwork and leadership:
As I mentioned before, we encountered miscommunication when working together. Our team structure was so much different from my first assignment team. In the first assignment, my teammates and I were able to work well with each other. Miscommunication happened a little bit here and there, but overall our teamwork was good. It wasn't necessary to have a leader. But in the second assignment where teamwork and team communication were not as good, there was a clear need for a good leader who had strong team building skills to connect all team members. But none of us was skillful and courageous enough to step up and take that lead. Prof Ben raised an interesting topic in the case study discussion 3 weeks ago about whether or not to have a team leader. My thought about this is that if the team by nature is strongly connected, a leader may not be needed, but for a less connected team, the team definitely should promote a clear leader.
Ironically, despite a great deal of pain I got from the assignment, I'm very glad and grateful. I've learned a lot from those faults and mistakes. The assignment is way over now, and the grade we got reflects correctly our product quality. But as Prof Ben said, the purpose of the 2 assignments is to help us learn and prepare for the final project. I can't imagine if we didn't make those mistakes in assignment 2 but in the final project (or further in life/business) instead. That would be a disaster...
My teammates and I are in the midst of the final project (I'm working with 2 teammates from assignment 2 and 1 from assignment 1). The team is moving in the right direction. We've spent valuable time analyzing all aspects of the project before getting dirty with codes. We're doing things very early to avoid last minute panic. The team is connected and all of us are working very well together. I'm very excited to see how our final product will turn out. Aim for the best!
"Mistakes are a part of being human. Appreciate your mistakes for what they are: precious life lessons that can only be learned the hard way. " - Al Franken
"It's always helpful to learn from your mistakes because then your mistakes seem worthwhile." - Garry Marshall
"A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing." - George Bernard Shaw
1. Miscommunication:
I admit that our team members didn't communicate well with each other, and most of the time we didn't know what the others were doing. We were too focused on working on our own tasks. And in the end, integration was a real pain. It's very difficult (if not say almost impossible) to join different pieces of a puzzle if they don't perfectly fit together.
2. Pre-planning is important, but we overlooked:
We spent too little time on meeting and discussion. We never analyzed the potential problems and difficulties the assignment might face. Also UI mockups, project timeline, and development process were not given enough attention. We only focused on feature list and individual tasks. Because of the lack of pre-planning, we underestimated the difficulty of the assignment, which led us to the next fault:
3. Procrastination:
We didn't start working until week 2 (assignment 2 was given only 3 weeks to complete). Because we overlooked the difficulties and challenges, we felt no rush to start doing things early. And the result is obvious: Camping in Com1 with last minute panic. It's so ironic that only at the end of the assignment did we recognize the need to start things early. That made the deadline day the most painful days I've had in my NUS life so far...
4. Teamwork and leadership:
As I mentioned before, we encountered miscommunication when working together. Our team structure was so much different from my first assignment team. In the first assignment, my teammates and I were able to work well with each other. Miscommunication happened a little bit here and there, but overall our teamwork was good. It wasn't necessary to have a leader. But in the second assignment where teamwork and team communication were not as good, there was a clear need for a good leader who had strong team building skills to connect all team members. But none of us was skillful and courageous enough to step up and take that lead. Prof Ben raised an interesting topic in the case study discussion 3 weeks ago about whether or not to have a team leader. My thought about this is that if the team by nature is strongly connected, a leader may not be needed, but for a less connected team, the team definitely should promote a clear leader.
Ironically, despite a great deal of pain I got from the assignment, I'm very glad and grateful. I've learned a lot from those faults and mistakes. The assignment is way over now, and the grade we got reflects correctly our product quality. But as Prof Ben said, the purpose of the 2 assignments is to help us learn and prepare for the final project. I can't imagine if we didn't make those mistakes in assignment 2 but in the final project (or further in life/business) instead. That would be a disaster...
My teammates and I are in the midst of the final project (I'm working with 2 teammates from assignment 2 and 1 from assignment 1). The team is moving in the right direction. We've spent valuable time analyzing all aspects of the project before getting dirty with codes. We're doing things very early to avoid last minute panic. The team is connected and all of us are working very well together. I'm very excited to see how our final product will turn out. Aim for the best!
"Mistakes are a part of being human. Appreciate your mistakes for what they are: precious life lessons that can only be learned the hard way. " - Al Franken
"It's always helpful to learn from your mistakes because then your mistakes seem worthwhile." - Garry Marshall
"A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing." - George Bernard Shaw
Monday, September 26, 2011
Case Study: Help me!
User Interface design:
Navigation:
The navigation bar is quite confusing. "New project" is a big red button, "Overview", and "Recommendations" are hyper links, while "Badges", "Profile", "Stats", "Invite" are tabs. I think to avoid confusion, all of them should be in the same format. I prefer the slanted tabs because they make the app look cooler. Also, the tabs could change color or something to indicate which page the user is on.
Home page (also the New Project page):
I think it's good to show users the 'New Project' page when they visit the app. But having the posting options below the input bar is quite misleading. Users may not be able to understand what the options are for, are they global settings or only applicable to the current posting. Also the first things users may want to see when visiting the app are the progress of their past projects and calls for help from other users. So I suggest that the posting options should only be shown after they click on "call for help!". The rest of the home page should be dedicated to showing other useful information.
Statistics page:
This page should be called "Leaderboard" instead. The nicknames shown next to the users' profile pics in this page are quite confusing. At first I thought "Mr. Good Samaritan", "The Great Guru"... are real Facebook names. Perhaps the real names could be put next to the profile pics instead to avoid such confusion.
Question/Project page:
This is the individual page of a need posted by a user. I think it's quite nicely done. It shows all the related information and functionality. The only thing I don't like about this page is the red buttons. They seem to draw all my attention while the thing I really need to see when visiting this page is the user's need.
Functionality and User Experience:
First, I want to comment a little bit about the idea. From what I understand, the developers were trying to create a combination of Yahoo Answers and Facebook News Feed. But for me, if I want to get help from my friends, I'll just post a big status message and tag some of the friends I know who might be able to help. If I want to get help from a bigger community, I'll just use Yahoo Answer or even Google. The problem with this app is that users don't have much incentive to use. The game mechanics can't help much. "Not everything can be gamified", said Prof Ben. If users don't have the incentive to use the app at the first place, there's no point for them to use it to gain levels and badges.
Next, the statistic page is quite "out of place". I don't think users care about who's the best helper. It would be more relevant to show statistics related to the user himself or his friends. Or if the developers want to show the leaderboard, I think they should include some options like "Ask the champion" to engage users.
Users will continue using the app if they receive useful answers for their questions. If not, they'll forget about the app after a while. Therefore, a mechanism to help users get fast and useful answers would be a good way to make the app more engaging. I would suggest some features like sending mass messages to all helpers about a user's need, or match the user with some potential helpers who have knowledge about what the user's asking.
Overall I think the biggest problem with "Get Help!" is getting a large number of users. After all, the app is all about crowdsourcing, and crowdsourcing without a crowd cannot work.
Navigation:
The navigation bar is quite confusing. "New project" is a big red button, "Overview", and "Recommendations" are hyper links, while "Badges", "Profile", "Stats", "Invite" are tabs. I think to avoid confusion, all of them should be in the same format. I prefer the slanted tabs because they make the app look cooler. Also, the tabs could change color or something to indicate which page the user is on.
Home page (also the New Project page):
I think it's good to show users the 'New Project' page when they visit the app. But having the posting options below the input bar is quite misleading. Users may not be able to understand what the options are for, are they global settings or only applicable to the current posting. Also the first things users may want to see when visiting the app are the progress of their past projects and calls for help from other users. So I suggest that the posting options should only be shown after they click on "call for help!". The rest of the home page should be dedicated to showing other useful information.
Statistics page:
This page should be called "Leaderboard" instead. The nicknames shown next to the users' profile pics in this page are quite confusing. At first I thought "Mr. Good Samaritan", "The Great Guru"... are real Facebook names. Perhaps the real names could be put next to the profile pics instead to avoid such confusion.
Question/Project page:
This is the individual page of a need posted by a user. I think it's quite nicely done. It shows all the related information and functionality. The only thing I don't like about this page is the red buttons. They seem to draw all my attention while the thing I really need to see when visiting this page is the user's need.
Functionality and User Experience:
First, I want to comment a little bit about the idea. From what I understand, the developers were trying to create a combination of Yahoo Answers and Facebook News Feed. But for me, if I want to get help from my friends, I'll just post a big status message and tag some of the friends I know who might be able to help. If I want to get help from a bigger community, I'll just use Yahoo Answer or even Google. The problem with this app is that users don't have much incentive to use. The game mechanics can't help much. "Not everything can be gamified", said Prof Ben. If users don't have the incentive to use the app at the first place, there's no point for them to use it to gain levels and badges.
Next, the statistic page is quite "out of place". I don't think users care about who's the best helper. It would be more relevant to show statistics related to the user himself or his friends. Or if the developers want to show the leaderboard, I think they should include some options like "Ask the champion" to engage users.
Users will continue using the app if they receive useful answers for their questions. If not, they'll forget about the app after a while. Therefore, a mechanism to help users get fast and useful answers would be a good way to make the app more engaging. I would suggest some features like sending mass messages to all helpers about a user's need, or match the user with some potential helpers who have knowledge about what the user's asking.
Overall I think the biggest problem with "Get Help!" is getting a large number of users. After all, the app is all about crowdsourcing, and crowdsourcing without a crowd cannot work.
Monday, September 12, 2011
VSee's sharing:
Today the CEO of VSee, Milton Chen, came down and gave a talk. I didn't know about VSee before (even though I vaguely heard about the company from the NOC seniors). But it doesn't matter. Mr Milton's talk just fascinated me.
VSee's video conferencing technology is amazing. It's able to deliver videos at high speed and high resolution. Not only that, VSee allows users to share files and work on the files in real time. It raises significant interest in me. Recently I've been particularly interested in XMPP (Extensible Messaging and Presence Protocol). I've been trying to create stable web-based XMPP applications but failed many times. Making it work is not difficult, but keeping it stable and scalable is a huge technical challenge for a 2nd year student like me. That's why to me what's VSee has done is so magnificent. I really want to learn more about the technology the company's using as well as the XMPP video standard Mr Milton created.
Ok let's move away from the geeky stuff. The message that Mr Milton delivered to us today is actually about life, leadership, and relationship. I want to write everything here, but I'm quite sleepy already. So let's just summarize what I find the most interesting and meaningful:
- Breaking patterns: I've been doing it for many years already. Basically breaking patterns is about changing habits of doing normal, daily stuff. For example, sometimes I write with my left hand (I'm right-handed btw), open my room's door with my mouth, walk to school instead of taking bus, etc. I feel great everytime I do it. It makes my brain alive. I become much more aware of things around me. And it makes me feel even better knowing that Mr Milton, a successful entrepreneur, also does the same thing.
- The "Sandwich" method: It's a great human management technique that Mr Milton is applying. When you want to criticize someone, start with a compliment, then give the negative feedback, and end with a compliment again. I agree that the method works all the time even when the other party is aware of it. It helps the other party receive the negative message less painfully and prevent his defense mechanism from triggering. I'm gonna apply this technique extensively from now on.
- Being soft on people: I really respect the way Mr Milton treats his employees. He doesn't want them to call him boss. He listens to their criticisms, lets them work from home, applies the "Sandwich" method so that he doesn't heart their feelings. Most importantly, he makes them feel comfortable when working at VSee. His soft approach to people management promotes his employees' loyalty toward the company, as proved by the fact that his NOC interns are still working for VSee after their internships.
- Marrying the right person: Prof Ben's out-of-nowhere relationship lesson is super interesting. If you want to be workaholic, you have to marry the right person who can let you work on your own stuff. Also, you should get married first before being workaholic. If you do the opposite, you may not have time for dating and probably may end up alone. Well CS3216 is such a unusual course. I never know what I'm gonna learn :-P
One more thing I like about Mr Milton is his passion and affection for what he's doing. He can work 7 days a week simply because he loves his company. VSee has become a significant part of his life that he cannot live without.
And for me, I don't know if I'm a workaholic (yet), but I certainly love what I'm doing.
VSee's video conferencing technology is amazing. It's able to deliver videos at high speed and high resolution. Not only that, VSee allows users to share files and work on the files in real time. It raises significant interest in me. Recently I've been particularly interested in XMPP (Extensible Messaging and Presence Protocol). I've been trying to create stable web-based XMPP applications but failed many times. Making it work is not difficult, but keeping it stable and scalable is a huge technical challenge for a 2nd year student like me. That's why to me what's VSee has done is so magnificent. I really want to learn more about the technology the company's using as well as the XMPP video standard Mr Milton created.
Ok let's move away from the geeky stuff. The message that Mr Milton delivered to us today is actually about life, leadership, and relationship. I want to write everything here, but I'm quite sleepy already. So let's just summarize what I find the most interesting and meaningful:
- Breaking patterns: I've been doing it for many years already. Basically breaking patterns is about changing habits of doing normal, daily stuff. For example, sometimes I write with my left hand (I'm right-handed btw), open my room's door with my mouth, walk to school instead of taking bus, etc. I feel great everytime I do it. It makes my brain alive. I become much more aware of things around me. And it makes me feel even better knowing that Mr Milton, a successful entrepreneur, also does the same thing.
- The "Sandwich" method: It's a great human management technique that Mr Milton is applying. When you want to criticize someone, start with a compliment, then give the negative feedback, and end with a compliment again. I agree that the method works all the time even when the other party is aware of it. It helps the other party receive the negative message less painfully and prevent his defense mechanism from triggering. I'm gonna apply this technique extensively from now on.
- Being soft on people: I really respect the way Mr Milton treats his employees. He doesn't want them to call him boss. He listens to their criticisms, lets them work from home, applies the "Sandwich" method so that he doesn't heart their feelings. Most importantly, he makes them feel comfortable when working at VSee. His soft approach to people management promotes his employees' loyalty toward the company, as proved by the fact that his NOC interns are still working for VSee after their internships.
- Marrying the right person: Prof Ben's out-of-nowhere relationship lesson is super interesting. If you want to be workaholic, you have to marry the right person who can let you work on your own stuff. Also, you should get married first before being workaholic. If you do the opposite, you may not have time for dating and probably may end up alone. Well CS3216 is such a unusual course. I never know what I'm gonna learn :-P
One more thing I like about Mr Milton is his passion and affection for what he's doing. He can work 7 days a week simply because he loves his company. VSee has become a significant part of his life that he cannot live without.
And for me, I don't know if I'm a workaholic (yet), but I certainly love what I'm doing.
Subscribe to:
Posts (Atom)