Back to blogging

So it seems I've been hit by the muse once again. Unlike the posts of the last semester, however, this will be really short ^^.

Turns out Comp. Sci. majors in NUS have to take this module now known as IS2101: Business and Technical Communication. Sounds interesting? Maybe. My opinion of this module, however, is decreasing with each day, lecture and page i endure of it.

Three lectures so far have done much to convince me most of this module will be the usage of obscure terms and acronyms to explain the obvious, and then waving these acronyms around in all further lectures, assignments and tutorials, expecting us to memorize them like the contents of some life manual. Case in point: The first appearance of the STARS acronym was "Ensure appropriate tone (STARS)". Thinking I missed something, I searched through all the previous (unnumbered) lecture slides, trying to find this acronym. I finally found it 4 pages after it was first mentioned. Bad style, anyone? While I wouldn't claim to have the most wonderful of writing styles by a long shot, these are the people tasked to teach us good writing skills. Go figure.

We have a draft of an email I'm supposed to be writing for discussion tomorrow. So why am I here, typing? Because I grew too irritated with the module, simply put ^^. The background story is that the Ministry of Community Development, Youth and Sports has released a Request For Proposals for games meant to "help individuals with disabilities develop life skills and obtain increased autonomy". Now, I've no problem with the background story. It's the marking scheme with which I've a bone to pick. Disregarding the fact that it, too, was littered with acronyms, it requires the email to be wrapped in diplomacy, filtered and rephrased in roundabout ways to avoid "jargon", and, to summarize, dumbed down far enough so that it can be understood by the lowest denominator of the audience.

Over the course of the summer break, I've been part of the Computing for Voluntary Welfare Organisations team, and our goal was to build the voluntary welfare organisations systems to aid in their (mostly administrative) work, based on their specifications, so that they would be better equipped to help their beneficiaries. The team I was on was working with MINDS, and we met the staff quite often during that period, to keep our clients involved in the project, and accept and work on their feedback on our progress.

All our collaboration was simple, direct, and without needing to avoid "jargon", as this module terms it. It is these "jargon" that convey our ideas and intentions with greatest clarity; to beat around the bush simply to avoid "confusing" the client is pointless, patronizing and insulting to both our intellects. If the clients wish to understand the product they are receiving at the end of the process, they should make an effort to be familiar with and immersed in all steps of its development, and not let themselves be swayed by flowery language that adds nothing to the project in the end. I'm definitely not advocating drowning the client in a pointless shower of technical terms, but those key to understanding the situation should not be avoided just to "improve" comprehension.

To be honest, I hope that I've made too hasty a judgement, and that this module is as bad as I've prematurely concluded. But it sure looks that way. A lot.

Ironically, writing this much for the first time in such a long while has gotten me a little more warmed up, and I shall now return to the assignment and attempt to write something wrapped in diplomacy.

P.S. And it looks like I underestimated the post length ^^

3216: To 7f80 0000 and beyond

Wow it's already Saturday. I've spent the most restful three days of... while maybe not my life, at least my NUS life. After the first assignment for 3216 was due, I couldn't recall ever sleeping that much for a really long while, but three 12-hour long naps in the same number of days really takes the cake.

Excluding a certain field of mathematics, this has been a very fruitful year. At the risk (and with no intention) of sounding elitist, a lot of us would have probably picked up in this time what might take more than a year to teach. Everyone probably had a different way of learning; some started flame wars, some contributed many (, many, many) articles and videos that served as interesting learning points, some grit their teeth and jumped into the deep, cold waters of the unknown.

Personally, I learnt most not from the experiences themselves, but the people that contributed to them. And that is one of my greatest takeaways: People matter. One example is being, and having, teammates. Certain people get disliked in a team. Sometimes it's their conflict resolution (or lack thereof), for others their (perceived) arrogance, and yet others, while rare in 3216, do (close to) nothing, and continue in that state unless acted upon by a net external force. Others bring value to whichever team they're in, learning on the job if need be. Why is there such a difference? I believe the source of the difference originates not from one's skill set or your background, but rather one's willingness to learn and participate.

Of course, teammates are not the only people in the world. People you meet and talk to in your life can share experiences and thoughts so astute, yet so simple that you wonder why you never realised them before. I like Prof's account of how he took a canteen stall operator to lunch to find out, among other things, why he was still serving customers personally. Also, as the repeatedly-quoted Chewy from Microsoft stressed, people are not like you. Everyone has their own story, their own worldview. If we could just ask the right questions, listen in the right way, we can learn something new from practically everyone.

Secondly, communication is *very* important. Fortunately for me, all three of my project groups were made out of people who were willing to sit down and discuss our differences in opinion and direction. Some groups had members who kept their disagreements to themselves, or in a probably worse move, aired their grievances for all to hear. Maybe it works for them, maybe it didn't, but I think it's not generally a good idea to publicly attack your own teammates, indirectly or directly, regardless of how right you may be.

Finally, and perhaps most importantly, is the famous quote from a short, agile, and originally puppet powered Jedi Master in The Empire Strikes Back: "Do or do not, there is no try". A few months before matriculating last year, I attended the Special Semester briefing by SoC's Undergraduate Dean, A/P Khoo Siau Cheng. Towards the end, he mentioned that a group called CVWO lets students apply their technical knowledge to benefit voluntary welfare organisations by making programs for them. I thought, "Hey, that's really cool! I want to be part of it!" Almost immediately, I began wondering if I was up to the task, having (close to) zero proper training in programming. So I shelved that idea. During CS1101S last year, we had prof's ex-students and CVWO members presenting CVWO to us again. And again I wondered if I was capable. Now, thanks in large to 3216, I'm more confident, if not in my technical abilities, but in my ability to learn the ropes quickly and effectively enough to be of use to the team.

Thus, our 3216 journey comes to some sort of an end. Many projects are still continuing on, ours included. This end is really more like a new chapter, rather than the conclusion of the book. My thanks to all the people I've worked with, and not just as teammates. One of my most vivid memories, interestingly, is of me and Angad playing Wii Sports at 4am while Wang Chen looked on, presumably amused at our antics. As this module draws to a close, it's now time for me to begin studying, as opposed to revising, for *gasp* other modules. Time to start working on that certain field of mathematics...

The *REAL* world: What you don't often hear at entrepreneurship talks

Chin Leng: "Perseverance; We only live once. No regrets"
We started off hearing from Chin Leng, founder of (and currently 1/3 the force behind) SingaporeBrides.com, and later SingaporeMotherhood.com. Now ranked #1 by Hitwise in their respective categories, the idea for SingaporeBrides.com was conceived during the hassle in his own marriage preparations.

He started off with no business plan, and no intention to seek funding, just wanting to try and see if it'd work. To summarise, he experienced many years of scrimping, saving, and trying to persuade wedding service providers to list their services on his site, with little success. Finally realising it'd be better to create opportunities rather than find them, he began to offer these providers free websites and tech support, effectively building the market for his own services.

Hoong An: "Don't start a business"
Hoong An from Hungry Go Where was up next, and his was a rather different view. To him, a lot of business was about being at the right place at the right time. He mentioned that a lot of media coverage is needed for a fledgling business, but that such coverage cannot be secured through outright promotion, but rather by presenting something that the reporter is finding at that moment.

He brought up 7 (rather interesting) reasons why one should not be an entrepreneur:

1. You give up too easily
• Success is about being at the right place at the right time
2. You have no business plan
• Not a matter of writing one, rather to have in mind what you plan to do
3. You plan too much
4. You hang around people just like you
5. You cannot make decisions
• Wrong decision better than no decision
6. You have no working experience, and no capital
• Working = Paid to learn
7. You have no faith and do not believe in God
• Limit to how much grumbling parents / you can take
• Starts playing with your mind

Tong Yee: "Serving people is the best form of business"
Next was Tong Yee, a teacher formerly with MOE, but left to develop School of Thought, and the Thought Collective. The School of Thought was started in 2002, teaching civic education through GP. Their students came out transformed in their perspective of the world, and this translated into clearer and more concise arguments. Students actually told their teachers that they needed tuition in School of Thought, and soon the School of Thought had teachers in their enrollment. Tong Yee left NYJC on the recommendation of his HOD, who, when about half of NYJC had enrolled in the School of Thought, suggested that more change could probably be done outside the system.

In 2006, the Thought Collective started Thinktank Publishing, aiming to create a current affairs magazine more relevant to students here. They tried not to include advertisements, as they restricted, whether explicitly or implicitly, the content that could be published. Now, they include advertisements for embassies, NGOs, and government agencies, all of which add to their content by providing different worldviews.

Currently, they are in discussion with EDB to revamp the CCA system. Their concern, which I agree with, is that the CCAs that impart skills relevant in industries, like photography and computing, are not as popular as, say, band and choir. Not including the students who will become professional performing artists in their future, most people join these CCAs with their points in mind, leaving the less popular CCAs with no members, and thus less leverage and manpower to conduct their own events. I look forward to see the outcomes of these discussions, as I feel it is a vital issue in schools now.

Leslie: "Do something you believe in"
We met Leslie from Red Sports again. He mentioned two factors that helped when starting off. Deciding early who the target audience is and going after it, and starting off with no debt. These, and the quote, were my greatest takeaways from his presentation

(if it seems a little short, Leslie had actually presented before ^^)

Ash Singh: "Sales fixes everything"
Interesting point: Search "Young Chinese Millionaire" on YouTube and you'll probably find this link in the first page... ^^
As the final presenter, Ash came with 50 keys to startup success, but decided to cut it short due to time constraints. Among the interesting points were

• Hire generalists early
• Invest in culture
• Start charging early
• Use your product
• Make decisions swiftly
• Keep it fun
• Ship then test

and of course,

• Sales fixes everything

We're almost at the end of the semester. I probably should get some work done on my other modules... So I'm off to do an assignment that's due in less than 48 hours.

Testing; where's the problem?

So, we went live last Tuesday morning, with a sparkly new tutorial suggested in part by prof and gang. We didn't fully publicise it, but released it to a select group of testers.We edited the interface a little based on their comments, and modified /added a few features~

And then... we hit an interesting issue. Users (and one designer) started complaining of lag that ranged from mildly acceptable to extremely long. While neither Eldwin nor I are really experienced in optimization, we didn't think our code would scale *that* horribly, especially when there are, as of date, 24 users, 3 of which seem not to have explored anything beyond our tutorial, and 2 who we can't even make that claim.

So, the logical explanation might be... geography. Most (all?) of our testers are based locally, and AWS is... not. And considering how often our app makes http requests to our AWS instance, it's not surprising that some manner of lag seeps in...

Last Monday, a day before we went live, we had a presentation by SoC's own Lai Zit Seng. Zit Seng is a very skilled... probably to pigeonhole him as a network administrator might be an understatement. I met him before during a training session for network helpers held in SoC, but this time I was really really impressed. Listening to him, optimization is more of an art than a science. You can't fully learn it from texts or lessons. You will have to try it, play with it, having it blow in your face (with backups, hopefully) for it to work and you to learn. He has a lot of experience in his field, and I am very impressed with it. His presentation slides are on my to-read list half a year from now, when our app takes off and we actually have hundreds of users (at least) playing it =P Like prof said, to have a problem in optimization is a good thing ^^ So, back to creating more features that the users (and 2 crazy designers) have requested for~

GWave

Well, the Wave project is over. Got back our results for it, and the marks for the aspirations are significantly higher than that of the first assignment (not really surprised there ^^) One gripe i have, however, isn't about the assignment, but the initiative (or lack thereof) of one of our teammates. His role could probably be described as the least technical, yet when he encountered some difficulty, did not opt for an ask-for-help approach, and instead told us only on the last day that it wasn't done as it referenced our work, which he was not familiar with. Put that together with the rush on the last day (unexpected synchronisation problems), our expectation that he had done (at least most of) it, and the fact that coding while writing the report takes two rather different mindsets... Let's just say the final few hours were rather harried ones. And despite claims to the contrary, I don't really think writing the report is extremely difficult... even points for us to elaborate on would have been nice.
(end gripe)

We had a video conference with Pamela from GWave on Monday. She described some very interesting new features of GWave that might actually have changed our projects significantly. Some were more developer-centric, like the Blip Contexts and Event Filters, but what intrigued me more were the new abilities granted to the extensions. The Active Robot API would enable access to a wave without needing to wait for an event triggered by a user, allowing the robot to read an update the wave on its own; essentially, becoming more like a participant in the wave. The SVN bot that Pamela showed as a demo was an interesting application of this feature. She also mentioned Proxying for Users, which allows robots to adopt a persona that it created, adopted or imported, which would greatly improve readability of a Wave conversation.

A few things stuck with me from her critique of our applications. Firstly, UI is very important. No matter how cool your application may be, if the user can't understand what he / she is supposed to do, you've lost one user. Secondly, give clear instructions. Suyuen made a similar comment on our first / final project. Show / tell the users what they need to do, and what each action will give them. Thirdly, give them a choice. While not explicitly mentioned by Pamela, it is what i took from her example of the application Cartoony that removed cleartext and replaced it with a drawn version. This hindered replying, copying, and integration with other extensions. Thus, when making an application design decision, make sure it does not remove any freedom the users expect to have.

And as our application rolls into launch mode soon, here's hoping that we get most of these... somewhat right ^^

People are not like you

Everybody sees things differently. What goes through your head is related to who you are; your experiences, your memories, your situation.


We had Chewy Chong over from Bing on February 22. Before the session, I'll have to admit i was expecting some marketing session, with some Microsoft dude selling us this Google competitor, and wasn't really looking forward to it.

That was so far from the truth.

The world is so different from what any one person can perceive. In showing us the CBS News video of a blind man's family, he showed us what a normal life is like to a very different part of society. 4 generations sharing a house and bank account, even when different members are doing very different jobs, and somehow always having someone watching after the patriarch of the family. How many families in Singapore have a remotely similar lifestyle? With that lingering in our minds, he said something that stuck with us for the rest of the session.

People are not like you. Step back and take a look at the system without wearing your usual lens.

That is, I feel, the greatest takeaway from this session.

On a separate note, perhaps he did succeed at selling Bing after all, for I find myself less adverse to switching from Google. Bing, according to Chewy, is more targeted towards aiding decision making, for most searching done is a precursor to a decision of some sort. Thus, Bing would attempt to determine what decision you were trying to make, and related information in a more relevant and helpful manner

Get Help

So, the blog post today is on the application Get Help. So what IS Get Help? It's an interesting use of Facebook's inter-connectivity: using it to ask for help from those on your friends list. While the idea is a really good one, there are some inconsistencies with the design that may detract users from its main purpose.

Initial / Main Page

First of, the initial page one sees on launching the application. The profile tab is highlighted, when this is clearly not the profile. It may seem minor, but a consistent design is often key to reducing the learning curve of a new application.

Also, beginning the request with "I need help with" could actually hinder the users somewhat. Not every request can be phrased as an "I need help with ..." statement, leaving the user puzzled as to how to phrase the request.

On the available alternative channels for posting a request, I'm a little puzzled as to how an SMS option would work. Who would the application be sending SMS-es to? Would it be somewhat a breach of privacy if the application were to start SMS-ing a group of the user's friends?

I feel that the choices of who to send the request to could be greatly improved. More specifically, I believe there is a need to allow users to prevent certain users from sending their requests, even if said request has been forwarded from the original sender. Imagine, for example, a request for help to build a gift for a close friend. Most probably, the user would not want this request to be seen by the intended recipient of the gift, as it would spoil the surprise.

Overview Page

Now, onto the Overview Page. I don't exactly think a Project being likened to a Fire is a very healthy comparison... Also, perhaps adding Overview and Recommendations to the group of tabs might be a better idea, for it can be a little hard to find these two links otherwise.

Project Page

The Project Page. How do you get here? Perhaps the flow of the site would be more apparent were I actually using it... And as a somewhat sidenote, "Wish her luck!" seems somewhat redundant as such well-wishes could be offered in the comments section, and with more detail at that. The 4 tabs being covered by the Project details also affects the design negatively.

Statistics Page

Finally, the Statistics Page. I disagree somewhat with the assignment of rankings and rewards to an otherwise altruistic application. Such rewards detract from the purpose of helping, which is simply to help, without expectation of any gains. Instead of encouraging people to help, such rewards actually change the motivation of helping, and soon the users would be helping simply for these rewards.

So, while I feel the idea was a really good one, I think the implementation could do with quite a few improvements~ That being said, they have already changed their design, and I'll be checking it out soon to see whether any of my suggestions have already been implemented ^^