Case Studies

To everyone, good job for surviving half the course! Now to survive (and have fun) for the rest of the course! In addition, Happy Children's Day, Happy Midautumn Festival, and as my professor puts it, Happy Midterm Festival! (>.<)

Meanwhile, for the case studies...

UI/UX

I think the new UI looks much better than the old one, where everything was quite confusing (too many choices, confusing colour scheme etc.) However, I felt very unnerved by the slanted header in the old UI - 

Did anyone else feel the need to turn your head to read the words too, or is it just me? They did refine it in the new UI, so that's okay. I like the idea of using images to represent the header, but I'm okay with the new UI not having it, because these images seem to end up capturing the audience's attention in the old UI, which should not be the case (because the content in the main box below is more important.)

I also liked the incentives drawings, because once people get used to it, they'll recognise the images faster than they can read the words, so with one look, they can see who "kissed" who :p

However, I feel that the images don't seem to have a consistent style of drawing, but I think that's me being nitpicky. On one hand, you have basic smiley faces, and on the other, you have cartoon people (the big hug) and the kiss looks really uncartoon-y. (Not sure if you get what I'm trying to say. >.<) I think it was just mildly disconcerting. But I find the images to be quite appropriately chosen (one look at it and you should be able to tell what it's supposed to be, so that's a plus point.) 

Besides what Su Yuen said about converting websites into mobile apps, here are my additional opinions for Get Help.

I'm in mixed opinions about the number of images used, since for each feed, we have three images - the incentive, the smiley, and the speech bubble, and that could end up looking very cluttered if the application was turned into a mobile application. If the images are long, users may end up spending a lot of time scrolling down the feeds list, which is not good for their wrists. xD The images definitely need to be resized to fit the space constraints of mobile devices, and personally, I think the speech bubble or smiley aren't that important (since I think what they need help with + the incentive is more important) and hence, the speech bubble and smiley can either be removed or resized for the mobile app. 

The clickable area for the header for the mobile application definitely can't be just the text alone as people can't usually click well on text on a mobile device. (Either the text is too small to click on, as compared to a button, or mobile doesn't work with cursor changes, so users don't really feel that the link is clickable.) I think that they can always change the header to a navigation bar (see jQuery Mobile) or tabs (Twitter Bootstrap). (Tabs-wise, I think we also have to consider whether to load everything at one shot or if the network is slow, to just load tab by tab when clicked.)

Contents-wise, I think it's okay to include all the stuff within the new UI, in the mobile application. It is five pages only and judging by the header, all of them (i.e. Home, My needs, My rewards, Bugs/Suggestions) are important. (I'm going to guess the last one can serve as a "contact us" sort of page.) 

With regards to the giving help by comments/sending messages, I think it's good to do that at the start to make the application more viral, but I think one worry is that the application might turn into a spam type of app. But I'm also unsure of how to market it properly such that people will keep using it for long-term purposes. >.<

Team Dynamics

1. Lanh said, “It would be really bad if we have a great idea but are unable to execute it successfully”. What are your views? Which is more important - the idea or the execution? Why?

I think while ideas are important, it seems that execution is more important, at least in the current trend. Even a very simple idea, when executed well, would make people want to use the application, and if lots of people use your application, no one can say that your application is not successful.

I concur with Lanh - For every project that I do, I find that I always visualise how the application would be like when it's completed. In that sense, if I cannot have a good idea of how the application is like, I would find it very hard to work on it. But rather than just leaving the group, I think perhaps Lanh could have talked more with the rest of the group on whether they could execute the idea well. If the rest of the group cannot convince him, then I find that maybe Lanh will actually end up convincing them to change the idea instead (which they ended up doing in the end anyway.)

2. What have you learnt about Facebook so far?

Facebook is annoying. Seriously. After making my Facebook application, I realised that I actually spend a lot of time on Facebook, but I have no idea why. >.< It takes up too much of my time, and is not useful at all. Umm, unless you're sharing things. 

In more serious matters, Facebook keeps changing. An application done five years ago (look at the first case study) will not necessarily work now, due to the changing API. But there are fun stuff to do (I really like the actions & objects thing). But Facebook is done in a very agile manner, so permission controls were not really built in properly, so it creates problems, like in FQL, you don't really get the full list of 5000/4999 rows even if you specify LIMIT 5000. Relying on Facebook also makes it hard to work sometimes, since we can end up encountering problems like timeout due to the somewhat slow speed of connecting using Facebook API. Facebook JS API also has a problem because sometimes the script file may not be loaded, but I encountered this problem less during the course and more during my internship.

Facebook can be very intrusive also, e.g. when the CS3216 team stalks our Facebook. (Not as well as this guy though, complete with ninjas! To be honest, I was more amused that he spoke French (I heard oui and bien~) and English, but I'm sidetracking.) It's useful in some cases, but people should be more careful. *nods sagely*

3. Comment on the ideas for Another Life and Fan Gang.

I think Another Life had the potential to be interesting if it was executed well. Unfortunately, I felt that the idea was too big - it could have been scoped down a lot, e.g. for the sake of fulfilling the requirements, only one or two storylines need to be published. I think the goal of the game was quite unclear - do the people play because they want to achieve certain achievements, unlock new areas? Even if they fulfill the storylines, is there a reward? I realise there has to be a tangible reward for the users at the end for game applications, and it seems like there wasn't one for Another Life.

For Fan Gang, I don't find the idea to be good because as Colin puts it, Facebook already has a fan page, and I know that people use it, even for amateur musicians. It could be viral, but that would depend a lot on the execution, and as it seems, the group does not really seem ready and prepared to do the execution. 

4. Should the team have changed their idea for the Final Project mid-way or stuck to their original idea? Why, or why not?

The idea for Another Life was not feasible - it was obvious that they were not going to finish coding the project. In that case, a switch may have been the best solution. But I feel that they could have considered throwing out features in Another Life first, before switching over. 

Moreover, I felt that they were not ready to switch over to Fan Gang, as seen by the technical problems they had faced when implementing Fan Gang (e.g. the Log/Feed component causing bugs in other components). 

I think ultimately, the group has to look at the new idea and check whether it is feasible and do a comparison between the current idea. In addition, if Fan Gang and Another Life were both not feasible, it's always possible to do another application that's easy, compact, quite bimbo-tic, but executed really well. (Because Facebook users are quite bimbo-tic apparently, I quote Su Yuen on this.)

5. List the major problems (obvious and non-obvious ones) in faced by the team? How could they have done differently and better?

One of the more obvious problems was technical abilities. It's easy to see that the coders had a lot of problems implementing all the application ideas (Fan Gang had problems, and they were unable to do up Another Life properly.) The solution would be to consult other people for technical advice. 

Another problem was not communicating with each other when they felt that something was wrong. While Jeremy was confident about Another Life, we could see that Serene was quietly frustrated with the meetings and Arun felt that the team was too accommodating.These problems should have been voiced, and I felt that Another Life would have been scoped better if they had done so.

A not-so-obvious problem would be the increasing unhappy emotions in the group. It probably started when Lanh left, but continued worsening throughout the entire project. The team had to make many changes to their project, and as such, I felt that they were quite tired of the entire project, perhaps even fed up. A lot of time was also wasted on their first few ideas, and this could have caused them to feel very anxious. The group also failed to make most of their milestones and as such, their morale would have been quite low during the end of the semester. All these bad emotions would have made it very hard for them to continue coding and finishing the project.

6. What did the team do right/well?

The team did well in planning the application. In Another Life, they made modules designs, prototypes, wireframes etc. They also did well in reconsidering their application, and taking decisive actions if things could not be accomplished (like dropping Simple Life when the companies could not get back to them).  Also, they worked right from the start, which is VERY important. 

I think another important point was that they actually communicated their ideas about the application (e.g. in Another Life, they brought up issues like viralising the application), but I think it was a pity that Arun only mentioned his Fan Gang idea pretty late in the semester.

7. What would you do if you were Jeremy on the evening of 24th April (and the deadline for the final project submission was the next day)?

Panic. 

After the initial panic (and when you have calmed down enough), try and figure out what's important and what's not, and finish the important parts. In this case, I'm not sure I can empathise much because I'm a coder. I think the least that Jeremy could do would be to document the problems well, so that if the two coders have free time the next day, they can debug faster. 

Jeremy could consult his room-mate (desperate times call for desperate measures), but I think one important thing to note is that adding a programmer into the project is not always beneficial to the project, because the person will take time to learn (yes, I lifted this from our CS3217 text). But if his room-mate is busy studying for his/her finals, then yeah, that's not very useful also. But I think the big question would be, if you had such a big asset (experienced person in programming Facebook applications and using Code Igniter), why did you not ask him earlier for help? I think it may have actually been good if the coders (Arun + Kien) could have consulted the room-mate for help regarding the architecture of the system perhaps. (And if you have a good architecture, most of the time, coding would be smooth-sailing.)

8. How would you handle a situation where one of your team members is unable to deliver on the work he/she promised because of personal problems?

I am going to quote Prof Ben here and say "it depends". It depends on:

• The team member (if you're close to the team member and you know that he/she is not the type to shirk responsibility, then there's no need to scold the person, because he/she may be blaming themselves for it already)
• Work style (some people may be slow to start their work, but can finish their work fast (so maybe there's no need to really hurry the person, because you know the person can deliver in the end))
• The personal problems involved (some personal problems can really stagger people down, and what is not important to one person may be very important to another; in this case, you really have to step into the person's shoes to evaluate the seriousness of the problems)
• The work involved (some work is not meant to be finished that quickly - you really need to evaluate whether that team member has been given too much work that is too complicated), and 
• How much the person has failed to deliver (is it successive times, or just one time?)

After processing through that, there are various things you can do. The first obvious one would be to scold the person (*ahem* think CVWO). The second would be to remind the team member gently (especially if it's a first-time offence.) Another method could be to sit down with the person and do pair programming - sometimes it's easier to solve a problem if two eyeballs are around, or offer the person help in coding some components of his/her work.

To be honest, I don't think anyone likes to fail in delivering. In some sense, there's always a root cause in preventing them from being productive. In such a situation, your best hope may be to pray that your team member will sort through his personal problems. You can also try to help out (with the problems, or with his/her part of the project).  As a side note, If you're not good friends with the person, it's hard to help your team-mate with their personal problems, but I feel that encouraging the person when he/she is going through a difficult time is also important. 

9. What, in your opinion, are the key learning points from this case study?

Team dynamics! 

I think as you read the case study, you don't really have this feeling that it's going to turn out that bad. (Oops, Div's style is rubbing off me.) But everything feels like a logical progression, and then oops, we're-going-to-die-for-final-project-because-we-have-nothing-to-show. I don't think at any point in time (except when they were doing Fan Gang), the team felt that they would end up in that situation, which makes it even worse when they reached it in the end. I think we always have to be concerned about whether we can reach our goal. If not, maybe we need help, e.g. expertise from other people or need to put in extra time or cut out features.

It's probably important to voice out any slight unhappiness that you have also. In the case study, Serene was being quietly frustrated that the meetings were unproductive. I think Jeremy probably did not notice it, so Serene should have mentioned it. In any case, any slight unhappiness that a team member bottles up is only going to make the team member more and more unhappy, leading to the team member being less and less motivated to finish up work.

To be honest, there are some parts of the case study that I can relate to - we changed our idea and rewrote our entire CS2103 game after V0.1. I am also guilty for saying that Serene shouldn't have bottled up her unhappiness, since I did do so for projects, such as CS5237 and probably some parts of Assignment 3. Fortunately, I never had any single project that made me undergo the same experience, so in a way, I realised that my team-mates so far have been quite good. *

I think being friends is important in a team. Because if you are friends, it's easier to speak up and be honest about certain stuff. Jin Guan felt that the our final project was missing something, and I gchatted with him about it. (More like thrash things out actually.) In the end, we came up with an idea that we discussed with the group, and they seemed quite accepting towards the idea. I think sometimes, during group meetings, it can get quite intimidating to speak up, but if you have friends in the group, you can always gchat one of them to discuss about the idea and then if it sounds good, it's possible to bring it up during the meeting. 

It's also much easier to scold people if they're friends. When I mean scold, I don't mean a full blown-out scolding, but in the usual twins-style, "What is this Baa Baa Black Sheep doing??" It tends to be more lighthearted, but progressive for the project. The bottling up doesn't occur, so bad emotions don't accumulate. 

So yes, the important points are team dynamics - being able to discuss and thrash things out rather than keeping quiet. Also, there's a need to keep your project in focus (why would people use this app?) and be aware of whether we can actually finish the project. Execution also matters.

* Perhaps with the exception of CVWO. That was a totally different experience since I really felt like dying then. (Gastric pain is VERY painful)