Perception

As the three-month sumer break began, I was fortunate enough to be able to secure an internship with the Infocomm Development Authority of Singapore (IDA) under the ELITe programme. This process wasn’t as frantic as a year ago, but it led me to think about my opinion on internships in general.

Granted, my current internship is a requirement for this programme, but I think there’s a lot of benefits that can be derived from this ten-week internship. My department deals with digital media under the Consumer Infocomm division, and it’s insightful to know more about what the government’s plans are regarding the media industry in Singapore. Within this same division is two other equally interesting departments, one that deals with virtual worlds, social media and games, and the other that is involved in developing the startup ecosystem in Singapore.

Exposure aside, I’ve never really done any serious research before, and the job scope of my internship promises that. I don’t really see myself as a research person, hence it’s quite a good opportunity for me to see if I’ll be suitable for such a role. Of course, there’s a limit to how involved an intern will actually be in their projects, so I’m not counting my eggs before they hatch.

One week in, I realised I’d forgotten how corporate lifestyle is like, and indeed it’s a stark contrast from the lack of routine that is academia life. The fixed working hours have quickly taken a toll on me, leaving me with little time on weekday evenings before fatigue sets in. The long periods in the day can be stifling as well, but I think it’s just a matter of taking time to get used to. That said, free time is no longer a commodity, and I’d have to cherish every weeknight and weekend for the subsequent nine weeks of this internship.

There are definitely other things I hope to do in the summer, but the routine of work severely limits the possibilities. I’d never thought I’ll need better time management skills now than during the school semester.

These last few months have been tremendously busy for me, mostly with the workload of school projects and assignments, but it’s been largely enjoyable which is probably why it seems to have passed so quickly. I haven’t neglected writing, although most of my blogging juice has been spent on writing for a blog for one of my modules. This entry comes at a time that is slightly too early for reflections on the semester, but I’ll just like to write about the fair number of web development projects I’ve been involved in since the start of the year, which has made these four months pretty fulfilling.

The first one for the year was the aforementioned blog, and what I tried to do with it was an approach much like that of Dustin Curtis. There were no requirements for the platform or design of the blog, so I took in my own hands to craft out each entry manually, taking the chance to explore different styles of displaying content. Of course, the amount of effort required for each entry would ultimately render this endeavour difficult to sustain as the semester progressed, and the lack of much creativity in the later designs is quite telling of this. Nonetheless, it was fun, although each entry meant that I had to not just write but code as well. I got to learn how to set up an RSS feed and install Disqus for the site, so there was some learning too.

I covered the Facebook and Google Wave projects in the last two posts, but I would like to mention them again due to the significance of these development projects. I learnt a lot of deploying an FBML application within Facebook, and the accompanying Facebook-centric languages and APIs as well. I’m currently working on a Facebook Connect application, and it’s no doubt this interest stemmed from the earlier Facebook assignment. The Google Wave API is something I’m hoping to take another crack at soon, and this new paradigm of real-time applications is too compelling to resist. Why I find these two projects of importance is because these are two more platforms that I’ll now be able to develop for, and not to mention they make good résumé fodder as well.

I’ve built a number of sites for module-related projects as well, and these have given me the opportunity to revisit and improve my current knowledge on HTML, CSS and Javascript. I’m a firm believer of the ‘practice makes perfect’ mantra, and I think the initial mundane steps when building sites from scratch is a necessary routine I’ll have to get used to in order to be iterate sites quicker in future. I’ve been able to play around with more jQuery for these projects, which I still think is an amazing tool, but there are still a lot of possibilities I’ve yet to try. I also learnt to use gothere.sg‘s API, which is quite comprehensively documented and is something I’d like to use more in future projects.

The last site I built, which was probably the most trivial and most enjoyable one to do, was a shared gift to one of the most awesome people in the School of Computing, and what I tried to do with this was to mimic a Twistori-like display. More specifically, it got me thinking on what other cool ways could be used to display text data, and a possible implementation of this would be to visualize the updates being sent through sgBEAT. Also, the attempted humour on that site was inspired from Chuck Norris Facts.

The upside to all this is not just experience, but at the end of it I have a bunch of code that could possibly be reused in in subsequent web development endeavours. I’ve also been able to explore new styles in web design, which is also very much a passion of mine. I’ve already taken the next step and am currently working on something which I think is pretty cool, so this upcoming summer break is definitely not going to be a boring one.

Having the chance to develop and deploy a Google Wave gadget as part of a school assignment is something I’d never thought I’ll write about. I begun using Wave pretty much since it was available, but not to the extent that my daily workflow was dependent on it. It has been really convenient to discuss and collaborate on ideas within Wave, real-time or not, and somehow the interface seems more appealing to me than using Google Docs.

Regardless, Wave has at best been an easy means to certain ends, but it is probably a lack of maturity and adoption of the platform that has slightly reduced its appeal. It is useful, no doubt, but thinking of particular scenarios where one might use Wave hasn’t been all that simple a task. Brainstorming for an idea to execute upon for the assignment was painful for me, and admittedly I initially didn’t have much interest in what I’ll be able to learn from it. I had been pretty busy with sgBEAT and preparing for the pitching session, and my lack of enthusiasm was probably more apparent than I would have liked.

I was decidedly comfortable with most of the ideas that the rest of the group had come up with – as usual my concern lay more in the challenge of the execution as opposed to the idea-generating process. Nonetheless, I felt that it was a good choice for us to settle on an event organiser, as it was something that I could definitely see myself using in future. Our interface would be a simple grid reflecting the immediate week and a relevant selection of hours, and all the participants of the Wave would have to do would be to select their available timings on the timetable. The grid would reflect the selections accordingly, and the most suitable time slot would be indicated to everyone.

Coding this was not as straightforward as I had hoped, as the HTML could not be static and had to be dynamically generated depending on the current date and time. We assigned each cell the UNIX time it represented as its ID, and I used Javascript to render the layout of the timetable. We then used jQuery to facilitate the dragging nature of selecting the cells, and up to then the easier part of the execution was complete.

The challenging part was having the gadget interact with the Wave state, and the problem was the number of keys we were going to have. Eventually we decided on having one key per selected cell, and through the efforts of one of my group mates, we were able to effectively map each cell to its own key, which we then used to keep count of the number of selections by the participants.

From there, development was much easier, and we simply used CSS styling to indicate the selected cells, with the most popular time slot shown with a different colour. A consideration made was whether we wanted each user to be assigned a colour of his or her own, but the overlapping choices was a problem because the colours would have to merge to form another colour on its own. We thus chose to indicate to the user his or her own selections by marking them with a cross. Other features like adding a title, notes as well as an extra week was included to make the application more robust, and just in time for our submission as well.

It was definitely a challenging development project, and also a pretty good Javascript refresher for me. I got to dabble in HTML, CSS and Javascript this time round, not to mention the relevant Wave APIs, so there was much learning involved as well. Perhaps if there’s time during the holidays I’ll try developing another gadget, but school is pretty much the priority now.

[Note: This entry was written for the module, CS3216]

The ad-hoc lecture on ‘Grades, Scholarships and Meritocracy” was an interesting hour of discussion on the Singapore education system as well as the Civil Service. In a certain segment of the presentation, a pyramid concept was described to explain how the meritocratic system of the government is designed in order to funnel the arguably most competent and academically brilliant individuals to the top. A ruthless but nonetheless effective means of trying to hoard the brightest minds within the government sector.

Unfortunately, I think that this funneling concept extends far below the corporate world and into the education system as well. My point here will only be relevant to my experiences, but since the earliest years of our education, we are subjected to a pyramidal ladder of success which we have had to climb. With streaming exercises in the midst of our primary and secondary education, it has only served to collectively group people of relatively similar proficiencies in academia.

The purpose of these exercises make sense on paper, and as a matter of fact in practice it does produce results as well. It allows for the efficient allocation of resources within the education system in terms of managing the curriculum and syllabus to suit the average standard of each particular stream, fueling competition (and perhaps, greater academic drive) while herding the more academically inclined students together at the same time.

The unfortunate consequence of this scheme is a dire one however. Regarding the problem of allocating resources, it is not possible to present everyone in the system equal opportunities, and as a result the more attractive ones, if any at all, are skewed to the students in the better streams. These supposedly smarter students are then able to learn more from these opportunities, improving themselves in a manner that only serves to increase their chances of remaining in this stream, and hence, further opportunities.

The Matthew Effect, as coined by sociologist Robert K. Merton, is described by Malcolm Gladwell in Outliers with reference to Canadian hockey players, and I can’t help but notice the similarities in the manner we identify our academic talent. The students who perform better at an early age are rewarded with increased access to resources and opportunities, while the slow learners are condemned to a fate converse of their more accomplished peers. Although our system has allowed an easy transition process between streams, I feel that there are other less apparent challenges that students have to overcome.

A student who may have been a slow learner would have been streamed into a class with less scholastic potential, and at the risk of generalising or stereotyping, I would say that these students are usually not strong academically or are encumbered with disciplinary problems. The result is that the first student will be subject to the influence of those around him, and this negative peer pressure can definitely be harmful over time. To overcome such an environment and excel would be no trivial feat.

Of course, this reality doesn’t apply to every individual, but based on what I’ve heard, it is certainly an undeniable fact. As students progress up the education ladder, their success and achievements are largely dependent on two things – their individual character and discipline, which is an accountable factor, but more worryingly their environment. The latter is not so easily measured, and unfortunately little can be done to control the external factors.

Could there be a better designed system? I would like to think so, although the current one, however harsh, is arguably effective to quite an extent.

[Note: This entry was written for the module, CS3216]

The video conferencing session with Google Wave’s Pamela Fox truly underlined the excitement of taking this module. To have a core member of the Wave team review our applications and personally share with us the new attractive APIs sweetened the deal of being in this awesome class.

It also once again highlighted the sheer proficiency of Professor Ben’s networking skills and web of contacts, and his undeniable ability in outsourcing nearly all his lectures to external, credible professionals. Excessive reverence of this module and the professor aside, I did take away something valuable from this two-hour session, although it wasn’t what I’d initially expected.

The technical bits were fairly interesting, as Pamela described the various capabilities of the new Active Bots API. I think what has always been exciting about Wave is the protocol beneath, in which the real-time transmission and reaction to events would allow for more efficient interactions than the current implementations that use AJAX. The ability to utilise this protocol without being constrained to the Wave interface does bring about more possibilities than before.

What I felt was a greater lesson was the Human-Computer Interaction (HCI) challenges that a real-time interface would have. Pamela reiterated quite a couple of times the importance of guiding the user on how to use the application, and also the significance of showing the user the visibility of his or her current position within the gadget as well as providing visual feedback in response to the user’s action.

While one might regard this as arguably common sense, the implications of real-time interactions on interface design is indeed an interesting and challenging proposition. I think as developers, it is important to always be aware of the constraints of the platform like in terms of size (browser vs. mobile). Now with Wave, interactions not just with the system but other players within the system can be in real-time, and with that its own set of problems and possibilities are presented.

[Note: This entry was written for the module, CS3216]

The title of this entry pretty much sums up the main point illustrated by Chewy Chong in his talk titled ‘You, Others and the Business of People”, which was a really engaging and entertaining session to sit through. What I particularly enjoyed was how the seemingly obvious idea that everyone is unique was comprehensively covered by him in a fashion that provided an interesting perspective on understanding users and customers.

When developing an application, one of the greatest challenges is trying to understand how one’s target users think. A common mistake would be to generalize who the audience is, and from there try to build a product that will seamlessly integrate into their lives. Clearly, making assumptions in this case can be harmful to the way the user experiences the application, as ultimately, this approach is based on one’s gut feeling and not on empirical evidence nor feedback.

So let’s say the developer gets smarter, and removes all previous assumptions. What then? The developer goes out to collect data to support his hypothesis on what the requirements of this product are, but this is not a scalable endeavour in any way. So the developer satisfices, and after interviewing about a hundred potential users or so, comes up with a minimum viable product that suits their needs. The problem that surfaces, then, is that the market is about a thousand times the sample size, and that the amount of data isn’t sufficient to extrapolate to the larger group.

Even if the developer was able to get feedback from more than half the target market, the likely conundrum that will be present is that everyone has different ideas of what the product will be like. The expectations that arise from the users will more often than not be based on their own interpretations of how the application should work and from past experiences with similar products. As a result, not everyone will end up being a satisfied user, with some probably even being dismissive of the execution.

Could the developer have done it any better? Likely not. We know that people are not like us. We avoid making assumptions. We do research, carry out surveys and collect data. Yet, it’s likely that we still do not know exactly what our users want or how they behave. This is just because people aren’t the same as one another, and every individual has a different background with varying past experiences.

Considering cultural and geographic contexts, designing for users becomes a lot more arduous a task. When taking into account the skill curve of our users, the problem then is how we can develop a product that will serve the interests of the respective beginner, intermediate and expert groups at the same time. Attention is usually paid to the former two groups to encourage adoption, and the latter group is normally too marginal that it justifies the sacrifice.

As it turns out, there isn’t a single, right answer to this problem. Based on the premise that people are not like you, an extension of this thought implies that people are not like one another as well, and that it would be improbable if not impossible to design an application or product that caters to the needs or suits the expectations of everyone in the target market. So what’s the best way to deal with this issue?

Well, I’d simply optimise my approach from the results. But that’s just me, of course.

[Note: This entry was written for the module, CS3216]

This is the follow-up post on the pitching session, and after spending more time thinking about what I’ve heard, I don’t think there are any explicit lessons that I learnt from the speakers (bar the 6Waves seminar). Instead, what I felt was the most important theme to pick up from this event is the idea of opportunity, and I thought the pitching session showcased the three ideas that I would like to share quite fairly, albeit in a subtle manner.

The opportunity that’s there – take it.
The pitching session was a fantastic chance to do a real world project beyond the scope of academia, and whether interesting or not, each presentation represents the golden opportunity to work on something more tangible than the theoretical projects one often is encumbered with in school. It was also a reaffirmation of the rising potential of social media, and an acknowledgement of the fact that knowing the APIs of Facebook (and Twitter, perhaps) is very much a relevant skill to possess in web development.

Furthermore, the companies that described what they wanted were upfront about their needs and problems, and what this highlights is the chance of making a real difference, and right now as well. As students, there aren’t many opportunities like these that come our way, and while it may be easy to dismiss them due to a lack of interest, I can’t help but wonder just exactly how much an opportunity cost is incurred with each fleeting chance.

The opportunity that’s somewhere – find it.
Interestingly, the firms that were invited to pitch come from different industries – Microsoft (Information Technology), iSYNDiCA (digital media), RedSports (sports), Module-Review (education), Ministry of National Development (the Government) as well as Explosive Barrel and 6Waves (games). I wonder if it was a result of sheer coincidence, but what this shows through extrapolation is that there are probably opportunities that exist in almost every industry.

Also, this reiterates the importance and relevance of social media, and that many industries will be able to benefit from utilising it as a platform for marketing, information and media sharing, as well as a digital bridge between consumers and businesses. Hence, I think one way of looking for an opportunity in this context would be to see how Facebook can improve the dynamics and relationship between the players in an industry, or by comparing how this platform is currently being adopted by other industries, and applying the concepts in a parallel way.

The opportunity that’s nowhere – create it.
This is mainly with respect to RedSports and Module-Review, who identified voids that needed to be filled, and went ahead and filled it. Of course, this takes a lot of effort and time, but mostly passion. The two speakers from the respective presentations believed in their ideas, and more importantly, saw it all the way through. While these opportunities can sometimes be easy to find, I think that more often than not, they’re more challenging to execute.

I believe that when looking for an idea, it’s always important to consider the context of the opportunity as it would serve to highlight the potential of the idea. But what I found a bigger takeaway from this pitching session is that opportunities abound, and for every one that presents itself, there are many more laying subtly and waiting to be discovered. It is, of course, up to us to take them.

[Note: This entry was written for the module, CS3216]

The pitching session last Monday evening, in my mind, was prized to be one of the highlights of the module. Sans the informative seminars by the technological giants like Microsoft, Google and Amazon, the pitching session was alluring in the sense that it was an opportunity to link up with established firms and find out more about their needs, especially in the social media space. When I left the lecture theatre that night, however, I wasn’t as satisfied as I would have liked to be.

I think in all fairness, my expectations were probably skewed to an unreasonable upper bound partly because of all the wonderful things that had been put on offer in this module so far. I was under the impression that the companies would be soliciting the services of us students to execute a particular idea that they had, and its relevance would be based on the usage of Facebook as the platform. However, during the event, not all the external parties were clear about what they wanted or what they could offer, and whether I was wrong to assume so is, well, irrelevant on hindsight.

I’d like to talk more about what I particularly liked or disliked about this session. For me, it was really quite an eye-opener, and I think this warrants it a post on its own. As for the three things I learnt from all the pitches, I’ll be covering my thoughts on that in a follow-up entry of this post, so bear with me.

Let’s start with the bad stuff. Do note that my opinion is formed mostly based on the pitch that I was subjected to, along with the information provided in the Project Proposal PDF file. As I mentioned, I felt that some firms weren’t specific with their requirements, and this lack of clarity kind of left me hanging there wanting more information. I didn’t get to speak to most of them after the session as I had to rush off, but I think these companies didn’t really justify their ten minutes of fame.

In particular, Project Nimbus and 6Waves weren’t pitching specific ideas, which might have been their intention, but for the latter it seemed more of a seminar than if anything. While interesting to a certain extent, I guess it just wasn’t what I was expecting, and I suspect that ultimately a game worthy of their notice would have to be of quite a high standard.

The Microsoft evangelist, as like all of them, just did his job promoting this Dallas concept involving this API of information, which admittedly was something I felt he did not spend enough time on. Instead, he spent a great deal of effort laying condescension into Professor Ben repeatedly, which I thought was uncalled for. I definitely enjoyed the irony when Internet Explorer bailed on him.

Contrastingly, some pitches were clearer about what they wanted – Explosive Barrel’s presentation notably, but that of Ministry of National Development as well. They were also a tad more specific regarding what they could offer the students who collaborated with them, which I thought was quite an important gesture, especially from our perspective.

The company whose presentation struck a chord with me specially was RedSports, considering that the audience of the site is very similar to the users of sgBEAT. More significantly, I was quite moved (for a lack of a better word) by the honesty of Leslie Tan, the founder, in describing the problems that he faced, as I think it’s something not everyone is comfortable with sharing in public. Coupled with Yanjie’s earnest recount of his experiences regarding the site, I was even more impressed by the effect that this man’s endeavour has had.

I got to speak to Leslie after the pitching session (he was the only one I spoke to before I left), and I’m really hopeful of a collaboration with RedSports a few months down the road. While I don’t think I’ll be assisting him for my final project, I’m pretty excited about the prospect of working together in future with the established news site that he runs. His name card on my desk is quite a testament to that sentiment.

I’d like to end this entry with a random side note of something I found particularly amusing – that the Module-Review presenter had to explain his site. I thought that he’ll have the easiest time explaining what his idea is, so it was kind of funny that it took one slide and about a minute for him to do it.

Over the last four weeks, a significant amount of my time has been spent on developing Facebook applications. While it hasn’t been a stroll in the park by any means, it has been slightly easier than I had anticipated. Granted, there were occasional obstacles and roadblocks that got in the way, and the usual suspects like bugs that made development more frustrating, but my prior knowledge in PHP and MySQL did come to good use during the assignment.

Developing on the Facebook platform and utilising the Facebook API was still a virgin experience for me, and the following are probably the top five things that I wish I’d known a month ago:

Facebook passes additional parameters in the URL
This statement on its own is not really a big deal, but it mattered because the framework on which I built the application on was CodeIgniter, which is particularly sensitive with what is passed in the URL. I realised this only when I tried to deploy the application, and even after exercising my Google-fu and executing various solutions which I found on technical forums and the like, Facebook and CodeIgniter still refused to be nice to one another. I had little choice but to abandon this choice of framework and to recode the application from scratch, which was pretty much a lesson learnt.

The number 2147483647
This was a particularly careless oversight on my part, and it brought about an unnecessary inconvenience to the team. Apparently, the newer Facebook users have user IDs that are larger than what a 32-bit integer can store, and BIGINT should have been used instead of INT as the data type. The disastrous consequence of this was that one of my team members couldn’t test out nor interact with the application as he had only recently signed up for an account with Facebook.

Stylesheets are cached, or something like that
Changes made to the style sheet won’t be reflected on the Facebook application immediately, and being unaware of this led to much frustration when attempting to iterate minor design improvements. It made it seem as if the expected changes weren’t being implemented, resulting in a sense of self-doubt or confusion and ultimately more furious amendments to the style sheet, which of course were largely ineffective. A better option than waiting for the changes to take effect would be to rename the style sheet and edit the page to point to the new style sheet, but of course doing a multitude of simple adjustments can easily scale to a large hassle.

FBML when necessary
There are instances when API calls return a String instead of an Array, or vice versa, which throws up some error on PHP. I had been dependent on these API calls to pull simple user data, when FBML would have been a much easier alternative. Amending the code to use the latter not only clearly improved the user experience, but made the code much neater as well. Why the API call behaves inconsistently, I’m still not quite certain.

It’s a lot easier the second time round
Following the Facebook application development assignment, I decided to code another application for the seminar assignment, and rather unsurprisingly it wasn’t difficult at all to do. I reused most of the code from the first assignment while making changes to the functions and database queries accordingly, and after slapping on a design I pretty much had a prototype in less than a day. I guess if I had learnt to develop a Facebook application before the assignment, I wouldn’t have made the mistakes mentioned above. All this, of course, is just hindsight bias at play.

I’m really glad that I got the opportunity to develop an application on the Facebook platform, and doing so increased the relevance of my PHP and MySQL knowledge. The best is that I got to learn all this as part of school, and within such a limited period of time as well. I definitely can’t wait to build more Facebook applications soon.

[Note: This entry was written for the module, CS3216]

Teamwork is a concept that is continuously expounded, and in the Second Lecture it was touched on briefly as an elementary yet critical foundation in software engineering. Like most concepts, the idea of forging interpersonal cooperation is easily digested in theory, but in practice, every team is likely bound to have problems which need resolutions that are more convincing than a chapter from a textbook.

My team for the Facebook application development assignment was not spared from this hypothesis unfortunately, and the lesson for me is that I’ll have to learn to pay more attention to certain aspects of team dynamics in future. One specific challenge is that while it is necessary to define roles, it is more important to define tasks.

Every member has a role to play, and what one contributes is a function of his or her value to the team. One’s value, as ambiguous as the term suggests, is subjected to being measured by everyone else, and the problem here is that the scale used varies across individuals. This leads to a certain degree of fragmentation by roles held by each member, and one is likely to value one’s work more than that of others.

Programmers probably find it easier to measure their work, either by lines of code or features implemented. It seems relatively straightforward when dealing with logic. Designers may find it more difficult, for if they spend long hours without a dose of inspiration and have nothing to show for it, then it’s hard to justify these hours. Business guys, too, may have their own challenges when it comes to quantifying their marketing or branding efforts, as these are not always easily measured.

Time may seem like a fair metric, but different people have different levels of productivity, and the amount of time a particular task requires is not always definite. Furthermore, as mentioned, it’s also hard to quantify the time spent staring at a blank Photoshop canvas, let alone time that is spent interacting with users for qualitative feedback.

What can be done to alleviate this problem is if the team members are upfront with what they can contribute, and to define or quantify it in a way that is meaningful in the overall scope of the project. Goals and milestones help define the work that is to be done, and every member in the team should have a measurable goal.

The programmer could aim to develop a specific list of features by a certain deadline, while the designer could talk about the exact number of mockups and design elements like icons or buttons that need to be done. Even the business person can quantify his or her tasks, such as the number of customer surveys he or she intends to do, to give one example.

If it looks like one has little or nothing to do, then I would argue that it is that person’s responsibility to step up and take on an additional task. There will always be work to do; handling administrative matters or updating documentation comes to mind. But beyond that, every member should let the team know just exactly what he or she is doing, and taking this initiative helps everyone get on the same page with regards to the work distribution. This also prevents confusion and subsequent responsibility-shifting.

So, while it is probably not possible to measure each individual’s contribution on a common scale, having specific, quantifiable goals and communicating clearly what one is doing helps everyone see the big picture better.