Week Eight - So it begins

So we started actual work on the design and set-up of our final project this week. A little bit of a slow start, but I think we have the general idea of what we need to make, now we just need to figure out how to build them using Meteor and React.

Trying to understand them is somehow taking longer than expected though. I had expected to be able to pick them up faster, given that I have already had experience in one framework (AngularJS). Perhaps it is the fact that both Meteor and React affect the front end, and React in particular seems to eliminate normal HTML files almost entirely - which makes things feel really unfamiliar.

The talks this week were a little different.

For Lawrence Putra's talk (Paypal + suggestions for project monetisation), I felt that while there was value in hearing about Paypal's products and getting feedback, there were very few "aha" or inspirational moments, as compared to the other talks. That said, I felt that the example he gave of SparkAsia was particularly interesting though; allowing free printing of photos but placing advertisements on the back.

For Hugh Anderson's talk, it was somehow really enjoyable even though I was supposed to have learnt these things before. His fun demeanor makes me really wish he taught CS2107 last semester (someone else took it last sem). For the content he covered, I think it's really good to know how passwords are stored -- and that hashes can be guessed and broken quite easily using rainbow tables.

Week Seven - A Breather

Our final project group took a sort of break for this week, to focus on mid-terms. Quite thankful for it; I had time to catch up to the two modules I had neglected for pretty much the whole semester (I literally caught up to the lectures half a day before their midterm papers).

The talk this week was by GrabTaxi, Arul the VP of engineering, and Hooi Ling, one of the co-founders. Both were interesting and insightful talks. From Arul we learnt about the problems they faced when scaling, while Hooi Ling talked about her startup experience, how they started and grew.

One particularly interesting thing Arul mentioned was their mentality that each component or micro service had to be small enough to be written or re-written within two to four weeks. I think this gives a good gauge of what to expect in startups - or at least what it takes to succeed in them. Two weeks sounds a little like CS3216...only that they don't have 4-5 other modules at the same time.

Hooi Ling's talk was enlightening in a few ways: their focus on testing and iteration, as well as their relentless approach/commitment to their idea were very inspirational. My key takeaway was actually her opener though: "pick something you care about". Although it did seem obvious, it somehow hit me like some ray of enlightenment -- your life will revolve around your startup. It will become a part of your identity, a big part of your life - or at least several years. I have had a few friends suggest startup ideas to me, and although I was willing to help, this made me think twice. Committing to any one project could mean dedicating a big part of my life to it. They might suggest it as a "side project", less-time-commitment kind of thing, but if so, can it really succeed?

Week Six - Feeling the Heat

Things could be better. Although we are making progress now, Assignment three is still behind time, and we're already spending almost all our time on it.

We received quite a harsh critique during Monday's (21/9) review, which was a bit frustrating because as a "handicapped team" I felt that we were trying our best. We were down by a member from the start, and the team mate we put in charge of backend has responsiveness problems, among other issues.

For the remaining two of us, we could only try harder. The feedback we received placed a lot of focus on UX, and our lack of clarity of purpose. Our app was initially focused on building the basic functionality, in part because I was in charge of front-end, and I hadn't managed to do much because of the number of deliverables I had the past weekend. My focus from Monday to today was to improve on these, and it seems from today's review that it paid off.

Some things to learn from this experience:

1. The importance of a designer:
   I realise that in assignment 1, we did not make use of our designer well. In this assignment, having a designer to manage the graphic assets, workflows and layouts could have helped us a lot. In a sense I had to do both design and code while building the front-end, and while it could seem more efficient, I felt that it made things slower, because we had to frequently debate the alternative UI/UX options. Having someone to focus on running through the user experience and come up with what to build would have helped form a solid direction for the team, and allow the developers to focus solely on how to build the features. To this end, I'd think that having a designer who can actually run the development code (i.e. knows Git and can follow instructions to run a localhost) would be a big plus point.
2. The benefits of having a code-savvy designer:
   While some may say that "designers should just design, and coders should just code," I would say that it helps to understand how things work when designing for them. At times, I felt that I had to make design calls that balance between difficulty and overall UX. The perfect layout or animation could be much harder and more time-consuming to build, and from my experience most designers would not know how to make such a decision.
3. The importance of being explicit:
   Make things as clear as possible. Colin questioned a lot of features, especially when they did not match his mental image of it. In particular he questioned the purpose of our app, because our landing page (and app in general) had no explanations. Our clean UI and short labels meant nothing, because he did not know what they were for. We have since added a tutorial introduction, and used guiding verbs instead. An example of this is our input page, which is one long sentence broken down into each individual input ("We want to share a cab from ___ to ___ using the ___ route").

Week Five - Next Up

Sorry for the long post; it's to make up for my absence of a normal post in Week 4.

These past two weeks were the start of Assignment 3, and the grouping/project choosing process for the final project. I tell my non-3216 friends to get feedback about my assignment 3 idea, and they're all like "what you have 3 assignments already?". Yes, and I'm really starting to feel the heat.

My Assignment 3 group was truly random this time. I had honestly resigned myself to the randoming, but somehow managed to get trolled by my luck again. At the end of week 4, Sun sent out an email telling about 10 of us that there would be some randoming to do if we did not form groups by that weekend. Not long after that email, a friend-of-friend asked me to join her group, and I accepted, thinking that maybe it was a good choice to make. And on the next day, I found out that the remaining two groups would have some overlaps with Assignments 1 and 2, so I had to get transferred to another group. So much for trying to decide my own fate.

In any case, with the slight caveat of an unresponsive team member, our group of 3 programmers seemed quite okay. I think these two are quite good in what they do, especially the full-stack developer who seems to have a wealth of experience. I can't say the same for myself, though. Trying to learn AngularJS and Ionic without any experience with frontend frameworks is somewhat difficult, and the haze is not helping at all. All day everyday I just feel sickly and unfocused; I feel bad not being able to contribute to the code, and even worse that as the project manager I'm not sure how to push my team forward. I mean, how can I tell the team what to do when I'm not making any visible changes myself?

The idea we are working on is one that I suggested, from a problem that I faced myself. A taxi route planner/recommendation for multiple stops - in my experience with GrabCar (uses a fixed rate for the in-app route), our driver was really unhappy with us when we asked to get off at different places. When I first thought of it, I felt it had potential to be useful, and expandable. Adding in features like estimated fare and collaborative functions help it as a taxi-sharing app, but in general it could work as a car-pooling app, or even for a person who wants to make multiple stops with one car. That said, I still can't figure out whether we should focus on the taxi use case or make it more general - on one hand, we may restrict usage, and on the other we may make users' mental image of our app unclear.

On to the final project: my final project group is...NOT random. Thankfully. I think we have a strong team this time, selected from past teams.

The external pitches were interesting, and I was particularly surprised to learn that there were perks (bribes!) for working with certain companies. They were really tempting, but after a bit of rational thought I realise the project ideas did not appeal to me as much. I was particularly interested in Thankyou.to, which I felt had a lot of potential, both in terms of learning as well as market value. Through Gerald's pitch, I could already visualise how the interface would look like, and its impact on a customer of the users' websites. I also want to try building the widget and social media crawling as I think these are useful skills to have for future web development. I'm a little biased towards this project now, and I feel a little unfair to my teammates cause I probably seem quite set on this.

The internal pitches were okay, with a few ideas that really stood out. I felt that it took a little too long, though. There were a few ideas that were debated over for quite a while without going anywhere. That said, I particularly liked EventSpark - those guys are geniuses. Seeing upcoming projects like 6degrees and QuickDesk also helped to remind me that a successful app is possible, and refuel my motivation. And on that note, it's time to get back to work.

Got to work harder, and stop letting my teammates down.

App Seminar Critique: Slack

The main idea I took away from the group's presentation was that Slack revolves around team communication, and succeeds because of this focus.

Slack's main functionalities include real-time messaging, cross-platform syncing, and integration with other team-related tools. The developers focused on building team-related features on top of these core functions, adding useful features such as a powerful search (that can even search within files), functionality for different channels ("chat groups") within a team, and 90 integrated tools excluding user-made ones.

The success of Slack, as described by the presenting group, is largely attributed to the product targeting a specific need of teams everywhere - a need for good communication. In fact, the group's main message was to tell us to "build a good product, one that serves needs". This was emphasized by the quick growth of Slack's user base, which has hit over 500,000 regular users in 2 years.

As for commercial potential, the presenting group suggested Slack's main commercial potential lies within its freemium model and large user base, with the premium features being targeted at enterprises looking to add value to their organization. It may be worth noting that (from a little research) about 135,000 of the 500,000 users are paying users, adding up to $12 million in annual revenue.

These three factors put together effectively bring across the presenting group's message, that we should build a good product that serves people's needs. The features showed the ways in which Slack is focused, the point on success led in to the group's message, while the commercial potential showed the selling point and target audience of Slack. In other words, Slack's features were built for teams, it became popular because it fulfilled a need of teams, and it earns money by targeting professional teams.

To add on to the points the presenting group has mentioned, here are a few things that crossed my mind when thinking/reading up on Slack:

First, it is not perfect: it is slow (I share that particular pain point about the notifications with Joel) and we need to create new 'accounts' for each team we join - points mentioned by the team. To add my own opinion in, in general it feels like everything has more set-up and is more complicated. For example, compare WhatsApp to Slack - creating a new team chat? In Whatsapp, a tap, a scroll, another few taps and you're done. In Slack, you need to enter emails for a new team (by typing - not tapping!), wait until the people open the email and set up new accounts before you can actually get started. This feeling of complexity, in my opinion, permeates the entire app, making it unlikely for me to use it for prolonged periods. Although it seems useful for teams, going by my current usage I think I can still survive with just WhatsApp. That said, it is interesting and nice to know that an imperfect app like Slack can and is earning significant amounts - I suppose point 1 on this list really applies.

Second, they have some very interesting business philosophies. They boast "fair pricing", where a company purchasing 1000 users' worth of premium will only be charge based on the number of active users. Also, they allow non-profit organizations and educational institutions to enjoy significant discounts. Is it part of their marketing tactic, to make users feel more comfortable in purchasing, or maybe more trusting and loyal?

Lastly, since this is getting lengthy, I thought about the freemium model - does it really make sense for Slack to be freemium? Going by the statistics, about 3/4 of their user base are free users. Doesn't the free user base drain resources? Perhaps they are hoping the free users will eventually convert to paying users. However, the features offered by premium - which include improved security, greater retention of data (e.g. unlimited message history), and more responsive support - do not apply to casual (or less 'professional') people like us. Or maybe they just couldn't charge for the app itself like Things did, because after releasing it the base app for free, the freemium model has become a part of the users' mindsets, and charging for the app now would just create an uproar. I'm no expert, so here's a link on a more expert source for debate.

Well, just some thoughts of mine. Hope they piqued your interest!

TL:DR: Slack is built for teams, filled a need, succeeded with freemium model. Slack may not be perfect but is still succeeding, the company has interesting business philosophies, and perhaps they could earn more without the freemium model.

Week Three - A Long Way to Go

During this week's class, we had a talk about Growth Hacking, and a little sharing/Q&A with Bjorn and WenXiang from Zopim (Zendesk). They were Awesome. With a capital A, because lowercase isn't enough to describe their awesomeness. The stories they shared were every aspect of inspirational: they dared to try to start something new, struggled through financial and technical difficulties, and even succeeded in getting acquired. The fact that they succeeded make the option of doing/joining a startup seem much more realistic, and I am extremely thankful that I took down notes during the class. I'm sure I will refer to them for the years to come, be it for motivation or direction.

While the class was awesome, the rest of the week was much less so. Right now, my group 1 is lagging behind in many areas, and I'm not even sure if the slide deck for my second group has been sent out. For both groups we had something like a lack of direction, albeit in different ways. In the first assignment we wanted to do stuff, but we just weren't clear on how to go about it. We have a clearer impression now, after the feedback and seeing other groups' pages. The second group was more of a lack of leadership, initiative and responsiveness. We almost never had any idea on who would do what, what to prepare before meetings, and we didn't even start on actual work until Wednesday, 2.5 days before slide deck submission. We have some pretty legit (imo) pecha-kucha slides now, but I'll wait until Monday before saying anything about whether "it all worked out fine".

Regarding the assignments, I'll admit that everyone was probably busy, because it was very much so for me. Yet, I can't help but feel that we could have done better -- I should have done better. Every now and then I feel this sense of regret, in myself and in the choices I made. Did my group focus too much on building features for assignment 1? Could I have been more proactive in interacting with classmates and forming groups? Can I really manage the workload? Should I have just tried out web development on my own, instead of taking a graded module where my freedom is somewhat restricted by groups and grades? Is it even possible for someone like me to become like Bjorn or WenXiang?

I don't mean to be depressive (really!); I'm just an honest typist. I'd like to think that honestly reflecting on my sub-par performance here will imprint in my mind the need to step up and try harder.

I still have a long way to go, and I suppose the only way to get there in time is to step it up.

Week Two - Getting Started

At this point, my Facebook app group is still starting on coding. I'm not sure if we are lagging behind, although I get the feeling that we are. We spent quite a bit of time this week finalising our idea, figuring out the requirements, as well as setting up the frameworks we were going to use. We had more than a few discussions on whether to include a given feature, and on my part I struggled a bit with installing Laravel. Because it had less support for Windows. D:

Features-wise, I'm not sure if we are on the right track. At times, we try to keep to our "purpose" of the app, and at others we think of whether it would be desirable to the user (UI/UX or otherwise). I personally believe that even if we make a product for a given purpose, the users are free to use them for whatever they want - even if it was not our original intention (as long as they don't break anything in the process). I feel that we should not purposely restrict the functionality of our app just to fit our desired use case, and try to steer the discussion that direction at times, but being a "non-designer" I can't be sure if my perspective is right, so most of the time I just hold my tongue and hope it works out.

The lesson this week was about software engineering principles as well as the SCRUM methodology, while the workshop was about presentation skills, HTML/CSS/Javascript and UI/UX.

For the lesson, it was a helpful refresher of what I learnt in CS2103 two semesters ago, It reminded our group to use user stories to list our (most important) features, and helped us identify our roles more clearly. Although we did not adopt the full SCRUM methodology, we now have a semblance of a project owner and a scrum master, who help identify features and push the team to get things done.

For the workshop, I only attended the session for presentation skills, but I daresay that was an excellent use of time. Prof. Damith spoke extremely well on his 6 tips for making impactful presentations, and I really admire how he has actually read (or at least owns) so many books on giving presentations. My main takeaways from his presentation are (1) think of what you want the audience to know, believe and do after your speech, (2) don't speak about topics - make points, and (3) introductions aren't important, an impactful punch is. I am personally not good at presentations, because I tend to lose track of what I "need" to say. I hope to learn from his method of thinking and speaking, which I found is very clear and focused, especially with regards to defining the desired impact. He identifies the condition for success (the desired impact or takeaways for the speech), and works towards it. I think keeping this desired impact in mind will help me to focus on what I want to tell my audience, instead of the script that I need to say.