Monday, November 14, 2011

CS3216...

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 :-)

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!

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...

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...