Monday, 12 November 2012

Week of End

This is the last week of this semester, as well as the end of CS3216.

4 weeks' hard work and McDonald's were transformed to the current app we have now. It's just one last step from being launched as a complete app. We spent lots of time on it and sacrifised lots of biological needs, as suggested, haha.

It comes to the time when I need to summarize what I have done in CS3216 and what I can take away. Frankly speaking, the most valuable thing I learnt via CS3216 is the programming skills. I did the basic programming modules, but only CS3216 made it possible for me to use them and put them into real practice. I can feel that my programming skills have been sharpend along the way by solving problems one by one, under very tight schedules.

Besides, I also feel very glad that I made lots of friends via the projects and learnt a lot from the great CS3216 community. I was totally new to HTML, PHP, JavaScript, essentially all the basic stuff about web application development when I joined this course. But I managed to work with very experienced teammates KianZhong, Zenan and JinGuan. I learn as I work on the projects. It was really a hard time in CS3216. I had to rush for deadlines, and also coordinate with other module requirements. I should have felt very happy when all this came to the end. Yet I feel a bit sad and lost.

One last semester for me before graduating from NUS. I really want to have a good time in the last semester, instead of unreasonable workloads like what I had in the past years. CS3216 will become a good memory for me to think of, when I wake up in the morning in my hostel and notice that no need to rush to SOC and continue coding. :)

Monday, 29 October 2012

Week of McDonald's

It's been a week since we started coding together at SOC every single night, mostly after midnight. We had a lot of fun discussing how certain parts should be done, and enjoyed trouble shouting together. But we are faced with a big problem.

We are lagging behind. Far behind the proposed schedule.

We finished a fantastic UI design and wireframe two weeks ago, but the actual coding turned out to be very slow. The backend API functions are generally doen, but we are stuck with the frontend organization. Initially we decided to use the Backbone.js framework and everyone spent a few days reading on it, but later we realized there was some problem when integrating it together with jQuery Mobile and the UX on an Android platform turned out to be not that good. We quickly switched to new one called Sencha Touch and after two days, we kind of found the track and got our groove on it.

We'll face a hard time in this coming week. All blessings.

We had McDonald's as dinner for the whole past week. And that will just be the case in this week. Hope the burgers, french fries and cheese shakers will all pay off.

Monday, 22 October 2012

Design and wireframe

We finished our UI design and HTML wireframe last week and also got some positive feedback from Dr. Colin. But we were not able to continue with it as I faced some personal difficulties ( caught a cold and lost my wallet = =) and my concert was at the weekend. We are lagging behind right now, quite a lot. Camping at SOC in this week is a must.

All in all, I am very satisfied with our current UI design. A lot of features, but quite clear in terms of UX. Not too much update for this week, but soon there will be a lot, as we progress over the coming 3-day weekend.

Wednesday, 3 October 2012

Case study 2 --- team dynamics


Case study 2 --- team dynamics


Firstly, great sympathy to the biz student Jeremy, for his screwed-up teamwork. Life is full of unexpectedness and wish he had stepped out the nightmare…

My first impression of this team is that they are way too ambitious! They even dared to change the topic for a few times, my team just extended our assignment 3 topic for the ease of continuity and a better execution. Their ideas are quite large but lack a strongly bonded team to implement them well. Anyway, let’s get started with the questions.

1.      For an application to really find its niche and spread ‘virally’, idea is the ultimate decision factor. A good idea never lacks good execution as investments will be drawn, which in turn draws talented people. However, on a smaller scale like our CS3216 class, since our ability and resources are rather limited, execution matters more. To execute an idea well and make it really work becomes the priority, even though the idea might not be that engaging and have a big marketing potential. Personally as a developer, I would rather do something that is executable within my ability constraint.

2.      Facebook is a great social networking platform. The good thing about it is that it positions itself just as a platform, with good API and SDK provided to outside developers. As probably the largest human network on this globe, it holds enormous raw human network resources yet to be exploited. It can’t do much as a single company. Hence it decided to release an API to developers around world (excluding some funny countries) from which they will have access to the human network resources. But Facebook encounters problems with profiting, indicated by its stock price drop.

3.      Both of the two app ideas are too ambitious for CS3216 final project. They are game applications and won’t interest people without good graphics and animations. Especially for Another Life, if 3D computer graphics with good modeling can be implemented, with similar effects to the NUS Second Life, it’s going to be really awesome. But this is way too ambitious in the time frame of 5~6 weeks, even for professional developers. People don’t really want to live a virtual life via plain text and pictures. This also holds true for Fan Gang. They all need lots of aesthetic effects to attract people. Besides, based on the reading and the attached feature list, I found that both the two apps involved too many features for their initial version, which made the implementation hard to control.

4.      There is no yes/no answer to this question. It quite depends on the situation. If the team members really have confidence and a mature plan, and sufficient working hours, they can definitely change to a new idea mid-way. If not, sticking to the original idea might also be deadly because they don’t really know how to proceed but to linger on. So the key is to formulate the idea well from the beginning.

5.      Problems:

·         Poor team bonding

·         Untamed ambition

·         Accommodating each other

A good team should be full of discussions and arguments.

·         Poor commitment from the members

·         Role of project manager is mission

The team could have done better if firstly they had chosen an idea properly. Apparently they lack developers, yet they decided on such difficult projects. Secondly they should have been fully committed to the team with valuable discussions and arguments. They should have expressed how they felt about the team directly within the team, rather than to Dr. Colin. Besides, in such a case where the teammates are not cooperating well, it’s better to elect a project manager who overviews the whole project and gives commands.

6.      Firstly they consulted Dr. Colin, twice. Secondly, they held immediate meetings to deal with the problem after the consultation. Lastly, they carried on till the last poster presentation day and didn’t not give up and run away.

7.      Take a good sleep and write a meaningful reflection blog on the next day, with clear description on how we reached the stage and what are the lessons learnt. If can’t fall asleep, I might call my team mates and cry them a river.

8.      Again…this depends on what the personal problems are, to determine whether they can be excused for not being able to deliver on time. If it’s a guy who was unable to commit well because his girlfriend insisted him accompanying her for a beach trip, well, I guess it’s time to kick him out. In the meanwhile if he had a reasonable excuse, the team should be notified earlier and come up with a solution.  

9.      The biggest key point is to form a group with members who can fully commit themselves to the team project. In this case, idea may come in the second place. Besides, business/marketing people tend to think more out the box and the developers should have enough communication with them on what can be done. In addition, a person must play the role as a coordinator well within the team, a project manager role if necessary. Lastly, if the team really blew up with no measures to take it back, it might be the time to stop and find another way to end it, for example, by a good pitch on the idea on the final day. As a quote says, “it is difficult to hold on, but it is as difficult to let go. But strength is never measured by holding on, but by letting go”.

 

 

CS3216 Case Study 1 ---UI&UX analysis of Get Help!


CS3216 Case Study 1 ---UI&UX analysis of Get Help!


 

Usability vs. Aesthetics

The two concepts do not contradict each other, although generally developers think that preserving one means compromising the other. In fact, people would consider a product a work of art if grabs attention and is user-friendly. Simple examples include the industrial design of Apple products and the Google search main page. They are all as simple as they look like, but people get mad about them and no one doubt they would become classical designs in human history. Aesthetic appeal does not come from colors and graphics, instead it can be integrated with usability in a proper manner.

Based on this idea, the interface of the initial version of Get Help! is not well designed in terms of aesthetic appeal. The elements are scattered around which distract users’ attention and make them confused. Too many icons or graphics are used for various functions without a consistent manner. User guidance is a bit wordy and not to-the-point. Even though different functions and user actions are distributed to different pages, there is no focus on each page. Too much information cause the users to feel overloaded and bored on every page. It takes around 1~2 minutes to read the page and understand what it is doing. Users’ patience will run out very soon. A good interface design should tell the user what it is at first glance and grab his/her attention in the following second, naturally followed by user interactions.

It’s difficult to tell how the functionality is with the static screenshots. But due to poor styling, I suppose users will get confused first before using the app. A quick glance at the app main page leads me to two sections from which I can’t decide where to start. The ‘call for help!’ and ‘need quick help!’ sections are not so distinct from each other and users can’t foresee what is going to happen after their entry. Yet there’s another ‘New Project’ button at the top which complicates the picture more.

Usability and aesthetics do complement each other. The old mindset to separate them is not going to work. However, to solve the problem from a developer’s view, functionality should come first. The team should rethink what is the main thing they want to show the users to grab their attention on each page. Only after decisions on feature implementation are clearly made can they start styling that makes pages more enjoyable. On the contrary, a page with clear tasks also makes styling an easy job to do.

User freedom when posting a need

Quite a number of options are presented to the user when posting a need, like deadline, estimated time, location, people to whom the message will be directed and channels to get the message across etc. These options are not arranged in a logic manner and may bore the user even before clicking the submit button. For example, deadline, estimated time and location are not the key issues for a need and they largely depend on the agreement between the poster and the helper. It’s good to give uses more freedom to maintain their post by giving out lots of options, but it’s important to start from the core, which is the need. It’s more reasonable to direct the users to document their needs well such that more appropriate aids can be found. Instead of asking the user to fill up the information in one page, the posting can be done step by step (as few as possible, as succinct as possible) using Ajax calls. In personal opinion, the options provided to the user should be much less. Details can be left to users to resolve on their own, which is also another aspect of freedom.

Cycle of interaction and incentives

The app idea is very engaging, to uncover the talent pool on Facebook and source for more appropriate help. However, the execution is not that exciting. A poster only posts a need and waits for reply, while a helper offers help or leaves comments, and gets badges from the system. There is no much difference from the old-style forum entries. Facebook is a social networking platform where most of people have their real identity, hence it’s much better to exploit its social aspect and utilize the power of real networking.

More detailed profiles can be built up for frequent helpers so the posters can search them directly rather than just wait. @ function can be added so that if a viewer of the need happens to know another person who is capable to offer help, he/she can just @ that person in the comment as referral, with notifications sent out. Besides, awards should not come from the system, but from the users, based on their assessment of the help offered, like what people often do to the online shops. The statistics page is quite redundant as ‘number of helps offered’ can just be attached under the profile picture of the helper to impress viewers. More important information like ‘good solutions and tips’ can be loaded onto that page so the whole app becomes more informative with a database of talented answers and solutions.

Other aspects…

The app is not well worded. Most of the page elements have a name then followed with a lengthy description. More work is needed on diction.

Monday, 1 October 2012

CS3216 Recess Week --- A sense of community

The whole recess was about CS3216 assignment 3. We spent 5 days together nearly round the clock everyday. We were like a group coding gangsters lingering around in SOC for the five days.

My FB post:

if(morning) view from SOC.window: "the sky is turning bright."
if(evening) view from SOC.window: "the sky is turning dark."


Colin's reply:

SOC.window.addEventListener('morning', function(event)
{
alert('the sky is turning bright');

}

SOC.window.addEventListener('evening', function (event)
{
alert('the sky is turning dark');
}

Move with the times bro. :D


I was planning to learn some new stuff about database and the Slim Framework, and CSS styling, but eventually I ended up with a lot of .js files dealing with Ajax calls that handles various click events in out mobile cloud app, which I am more familiar with, which I had done a lot for my first assignment.

So regarding technical learning outcome, I didn't really have anything new to share, though I am really glad that my skills to implement Ajax calls were reinforced.

However, another aspect about CS3216 I found during last week is the sense of community. Four of us were strongly bonded together for a single assignment. I guess none of us would invest such a great amount of time and efforts into a 15% assignment for any other module. We did that because we chose it and we promised we would make a difference. We worked together and no one complained about anything, but a few hot discussions that made people sitting around us drop their jaws at COM1.

At the midnight of last Friday, when we finished final submission and went back to our hostels, I just felt a big loss and hoped we could work together more. Fortunately three of us will be staying together for the final project, improving the current assignment 3 app. Although Jin Guan is leaving, he made a tremendous contribution and also left lots of good suggestions behind. I hope he could be my shadow member as he said.

We have plenty of time to improve CrossView during the final, and we'll do it again, together.

Friday, 21 September 2012

Week of dilemma

Week 6 of CS3216, no coding, no meeting up, no messages, but a week of dilemma.

I even wanted to name our group 'silence' on Facebook. Such a big tension between us, some want to extend current project to final, some are leaving for their assignment 1 group members and some are wanted by many others.

But what can I do as a learner for all the web development skills? The only option might be to join a group with strong developers and learn from them, contributing a bit where applicable. It seems impossible and impractical to pitch my own idea and gather people.

But that's what I did to retain my current great teammates. To let them stay, I decided to pitch the idea. The negative feedback was actually good for me. My group was somehow reunited as they would demonstrate to the audience that things might not be different from their critical judgement. The counter-effect.

And it's also very encouraging that I got a new fantastic designer, who joined my group after the pitch, to replace the member who is leaving for his assignment 1 group.


The whole week 6 was used to resolve grouping issues. Either you compromise your idea, or you compromise your dear group members. Neither is what I wanted, but I have to choose one.

I love my assignment 1 group, where three ideas arose up for the final, and all pitched. We were split into three incomplete groups, struggling for new members, and struggling for the team bonding.

You are nicest people I met in various NUS projects.