Week 10: Scalability

Today's talk covered so much breadth, it was quite a lot to take in. For the topics that I have some background knowledge in, they were easy to understand, but for those that I have never heard of, I felt quite lost.

I like how the speaker linked back to his real life experiences from his presentation. And it was also very entertaining because we as NUS students are the users and have used CORS. Finally I get to see someone in real life who is behind all the magic that goes behind the scenes of CORS. Also there was plenty of discussions about fire in NUS.

Just a short summary of what I've picked up from the lecture (purely from memory!)

1. no data, no talk
2. random tuning
When there's problems happening, the last thing we want is to be accused of something that we are not responsible for. We also shouldn't be quick to point fingers at other parties before examining the evidence (data) We know that there are tools which will objectively produce data that can determine which component is underperforming.

3. ajax requests overloading the server
at the application side, we need to think about how we can optimize some operations to prevent unnecessary loading of servers.

4. to use commercial cloud services or to host on your own server
some restrictions like privacy will render no choice. but for other cases, this is a decision that requires a lot of careful planning. However, i feel that using commercial cloud services will outsource the expertise very well.

Week 9: security

On this day itself, I was at the public service career fair and talking to a representative from Internal Security Department. Later on, the talk given at our lecture is also about security.

The speaker's profile is very cool, he works in IBM and graduated from MIT. He gave us some idea of how IBM is structured. I also remembered how he mentioned that when choosing between a new feature and enhanced security, security should always be picked first. I realise that many developers may be pressured to outperform competitors and choose to focus on features rather than security. I guess this is very good advice. Many people don't realise the importance of security until something really bad hits.

Also, there was some discussion on privacy. Sometimes, having more security will compromise privacy, and the analogy given is that of airport baggage checks. Also, like using phone numbers and emails to verify identity.Yet something I never thought of is that people have different perspectives of what information is considered private to them. In some countries, age could be a private information, while in Korea, it is often one of the first information requested from one person to another while meeting for the first time. (This is because they would like to know how polite they need to be while conversing.) They are very open about revealing their own age.

Week 8: a visit to wonderland

My group is working together with Between 2 Trees preschool! We exchanged lots of emails and also sent our proposal to them. Today, we went to visit them at their location!

The place looks really nice and I really love the concept of their company.

Meeting:

We had much things to discuss. As we exchanged emails beforehand, I could sense that they had a different understanding from us. Before the meeting, we had a whole set of questions to discuss. Our clients have quite a clear idea of what they wanted.

In the meeting, there was a teacher present so that she could feedback on user experience. We were also assured that they would invite at least a parent and teacher to try out our app to give more feedback when we complete the minimal working version. I could sense their excitement throughout because this idea is something that they would really want to use and also even push out to other organisations with similar needs.

We discussed issues like privacy of children's photos. There is a trade-off between the social media sharing and privacy. The question is - do we want to allow parents to share picture updates of their children on Facebook which might compromise the privacy of the child?

We also took time to explain some technical aspects of the project during the meeting. Actually, its not very important for those details to be discussed. However, our clients were quite happy to gain some extra technical knowledge. They even (cheekily) asked us what API stands for - like a test!

Overall, I feel that the meeting was effective. There were a few points that they needed to discuss among themselves before they revert back to us. We need to re-arrange our wireframe now so that the interface will fit into a mobile interface.

Lesson yesterday:

The Facebook guy came and gave us a talk which covered many things at one go. He dropped a few names of apps which became very successful and also elaborated on what were the ingredients of their success. One of which, is timing. The more I think about it, I think windows 8 development should be seriously considered as the timing is right. The Facebook guy encouraged us to "move fast", and he also cited his previous company a few times to illustrate the consequences of being slow to react to new technology. If we keep "moving fast", then we will always be learning new things and throwing away the old. Just like how i feel like throwing my current phone away and buying a new one.

The second talk is by Sharifah from K2 Associates. She gave a few examples and snapshots of how we can organize information in a constructive way. During elections, information posted by the general public will help politicians to get a feel of the public's response to their campaigns. In anticipation of the future talks which will continue to lead into this topic.

-Pei Yi

Week 7: case study

Case study I: GetHelp!

Usability vs Aesthetics
I understand how the developers were pleased with their initial design. It had plenty of colors, thumbnails and clear headings. The font is readable too.
However, a home page cannot be too cluttered. If the user's view is focused, he will have a clear understanding of what is going on. Users enjoy clicking quickly (to see some magic) and rarely read through every word they see in a webpage (unless they are really looking for some information). Once they catch a keyword or a picture that interests them, then they will slow down to explore that.

Aesthetics-wise, the red buttons are really glaring in contrast with the blue-green theme. Perhaps it would be better to choose complementary colors for the button. Also, there is too much words (Post to all friends, no, i want to pick & choose reliable people ...) It might sound fun to have such informal sentences, but it is not user friendly. Short and concise is better.

Number of options
I think its great to have options to specify more details. Its also good if it is optional to fill in as well, so that users who are too lazy to fill in more than one text field can still submit their help request. I also like user interfaces that hide additional settings unless it is clicked. Clean interfaces are nice to look at and use. I believe in maximum freedom for users.

Cycle of interaction & incentives
Every interaction gives an opportunity to reach out to more potential users. Using badges can be a incentive for users to continue using the app. Mousehunt uses badges to show the ranks of the players. Their profile pages show the rank. Users got hooked onto that game because they wanted their profile to show a high ranking badge. Perhaps using badges might be a good idea to try out. Helping 10 needs is quite difficult though, unless the needs are generally trivial. Perhaps there can be a gentler slope of earning badges. Eg. 1,3,7,15, 30, 50 and so on. The first few badges will be the 'hook' for users to get the momentum going. This 'reward' can be accompanied by instant rewards too! Something like giving virtual items (accompanied by good graphics) still gives a great feeling on top of doing the deed itself.
Give a kitty smile, or bear hug, or manly punch.

Others
I think that for apps that require real life interaction as part of the process (the act of helping), there should be a follow up and a nice closing. Perhaps it would be nice to upload pictures, write testimonials and broadcast this to everyone.
This app cannot work well if there are many people asking for help and no one with the expertise to help. Eg. all the students asking for help and no one knows the solution. Also, it might be potentially misused if users start sending help requests that make other users feel uncomfortable. Some regulation is needed to prevent this.
I think this app idea works great for a mobile app as well. Like discussed in class, the feature list needs to be cut down to only the necessary features for a mobile version. I think that asking for help and viewing other people's help would be the two most crucial things to be accessible on the mobile app.

Case Study II: Team Dynamics

I believe that the execution is the most important. Any simple idea, if executed well, would outshine other similar ideas. We need to have reality checks so that the idea would not turn into a half baked product. No one would want to eat it. Can it be done, given the time period, manpower and resources? If the execution is good, at least there is a foundation where new ideas can be built onto the original basic idea. These new ideas can be generated during the development process, or while talking to users.

I've learnt how to use Facebook's Javascript SDK and picked up a few of its APIs. I also learnt that the Facebook platform is very dynamic and subject to frequent changes.
I've also noticed after developing Facebook applications that users' reaction to Facebook integrated apps is not very good. I think that nowadays, people are very conscious of what applications they use because of recent spams. Many users have been using Facebook for years and have accumulated loads of information that they would not like to share openly. Hence, some people would be put off if the app requires Facebook authentication login.

I'm not too sure if I fully understand the game Another Life. Maybe it is because I have never played any game with this concept, that is why I cannot imagine the gameplay. I have never played the Sims, Second life or IMVU before. Based on my little understanding, Another Life seems like a outlet for people to build their 'ideal' life. Its very obvious that users need goals in the game. I have played Fashion Story (by Storm8) and it is not fun playing without the goals. Fashion Story on the Apple Store had goals while the one in Google Play store did not. I, along with many other disappointed players, complained on the forums that we felt left out because we had no goals.
Fan Gang would not be relevant today in 2012 because Facebook implemented a feature for anyone to be subscribed to. This means that people do not add fans 'as a friend' but allow fans to 'subscribe' to them. This feature is implemented well and hence a third party Facebook app would not be able to compare with an integrated Facebook feature.
Perhaps during Jeremy's time, there could be a need for this idea. However, I still cannot picture myself using such an app at that time. Maybe this is because I'm not a fanatic for anything.
I took a look at the basic feature list, and it is really ambitious for a team of 2 coders with 2 weeks to implement.

Major problems

The one thing that bugged me most is: are the team members on friendly terms with each other?
I think that to produce good project work, the team members must feel happy doing work together. It saddened me to read that one member did not reply smses and then finally moved to another team.
If the team took time to understand each other's concerns and communicate effectively (listen well and speak clearly), the team would not have been so shocked if they hear that one member wants to leave. If the team members are on friendly terms, they would not mind covering for one another temporarily in case of special situations (personal problems?)

Work allocation: front end and back end
I think that it is ok to split between front end and back end. But both parties must also keep updated with each other's code and know what each other is doing. I think everyone should read other members' code everyday and have a basic understanding of how things work. There is a need to do mini-integrations and test regularly so that unfortunate situations like having restrictions on cross domain AJAX calls can be noted early and alternative action be taken.

Over ambitious implementation
It is normal to have many ambitious features proposed at the start. But at the end, one must learn to let go of those features that cannot be implemented due to constraints. The priority of each feature should be clearly stated from the start, and everyone should start working on the most important features first.

Pre-mature optimization
I think that there is a difference between having good coding practices and pre-mature optimization. Both have the future in mind so that further improvements can be made cleanly. Pre-mature optimization however, takes up too much time unnecessarily. I agree that scaling issue should have been the next thing to consider only when they have gained a substantial
user base and could not handle the load with some caching methods they can use.

What the team did right:
I think that the non-coders did put in effort to contribute to the project throughout the entire span of time. Non-coders can make a big difference too. They have a less biased view and have a solid big picture of everything. It is not easy to have coders who are managing on the micro scale to also have a good general sense of what is happening.

If I were in his shoes...
I would gather everyone together for a overnight camp. I would get the whole team to pressure the coders to communicate with each other and come up with the minimal working version. I would also encourage everyone not to give up.

A member's personal problems
I think that the work would have to be assigned to the next person who can deliver the work well. It is unfair, I know. But this is really to save the team. Perhaps this member with a personal problem would owe the team a lifetime of free coffee after the project.

Learning points
1. Communicate everything. Blurt out all fears, confusions, misunderstandings too.
2. Manage expectations. There is no superman in the team.
3. Don't give up on the project. Someone lived to tell the story.
4. Change the idea if it really doesn't work at all
5. Have a solid plan that can be followed