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.