Carpool app - which path?

Which path: iOS or HTML5?

Interesting team discussion today.  At times heated - guess that's how the strength of team-mettle is forged!

Given the time constraints, reached an uneasy choice - decided on a parallel 7 days developments run. Objective, learn the pros and cons of iOS vs HTML5, report and share the differences with each approach.

Count down starts today. Must chiong already. 

Final Project - carpool

Missed the CS3216 class on the 15th Oct, due to my mid-term exam time table clash.

Instead, I shall share how our team had pitched our idea on  carpool, to Colin and Su Yuen during the consultation slot. Our team members: Peggy, Hieu, and myself. Murali and Christopher Cai came along as advisors/ mentors to our team.

Unlike most carpool apps, which works on stranger picking up stranger, we have re-positioned the carpool apps for those who already knew each other. Instead, our intended app would leverage on the mobile geo-location feature, a driver can keep in touch with passengers with communication automatically notification routed to passenger when nearing the destination for pick up event - an productivity tool that help keeps driver safe as he /she does not have to make phone call enroute to inform passengers of his impending arrival. Another interesting 'credit' feature would be to clock the pickup mileage travelled.

Which of the two development approaches works better: iOS or HTML5?

Chris has kindly offered his help via iOS.

Colin and Su Yean has shared with us how HTML5 might have worked better in our context.

Both methods are great opportunities to learn. And internally, we are still divided on this.

Let's be creative, and explore if the IMPOSSIBLE could be made Possible? Like they say, IMPOSSIBLE CAN BE READ AS I'M POSSIBLE. Concurrently develop using both iOS and HTML5? Crazy!

hmmm...... I shall take on the role of coding the front end using  HTML5. After all, Su Yean and Colin say it's possible to pick up the HTML5 baton and cover a good distance. I am motivated by their optimism and faith! Hooray!

Power to our friends, with the music that never ends....

CS3216: CASE STUDY II: Team Dynamics, Rise of the Phoenix from its ashes.

Creative Chaos! Rise of the Phoenix from its ashes.

During our this week's workshop session, Vincent shared how their team had initiated three application products during their CS3216 tour of duty, some years back.

First there were two apps, no life detected at birth, stillborn: Simple Life and Another Life. Makes listening students realised living Life is hardly Simple, not even in Another Life. I would have thought the sequel app is called After Life.

Luckily, for the team, a less ominous apps name helped reversed the siblings’chained fateful fate: Fan Gang, the only one survived through the duration of the then CS3216 module. Pretty short lived though, could be the duress during birth transition.

Long story, cut short:

Members’ disagreements on vision, on ideas and ideals. One eventually quit, quite dramatically (must had been). Tears, anger, disappointment, lost-ness ensued during the difficult journey of implementation, exam, unequal (unfair) workload distributions.  

Finally baby Fan Gang apps born, the one and only fan building club app (every baby is special, unique, there is really no equal!), thru’ sweat, pain, and tears. Apps must had been launched without fanfare then, with lingering memory of one bolted member.

SO THE STORY GOES, AFTER A BAD EPISODE, A GOOD ENDING….. graduates from CS3216 have made good with better products, better teamwork and better ability to implement new apps and even success stories later on in their careers.

And CS3216 graduates came back, lived to share the stories (horror), a tradition – “you will die”, so they screamed, one after another, especially, during Talent Night, repeated by Vincent. Every hard-core coder worth his salt remained unshaken, steadfast to die thru the process, they hanged on to the optimistic belief.  Rise of the Phoenix from its ashes - Apps Died, Then Rise, Again.  

Lessons learned:

1.      Idea or Execution?

Both are important, it depends on the context, circumstances. However, in the context of CS3216, with stingy time and resources, the odds of succeeding with great good product is very miniscule. I go for team work, team joy, team shop, team fun, great pals, anytime! If it’s a social enterprise, then members with similar traits and belief would take priority.

2.    What have I learned about Facebook, so far.

Leverage viral network expansion very well.  Great tool to remind of important dates: birth dates of important people in our circles. Great product is always evolving, UX too. Despite the odds of late entry into social media market, they sustained and beat all earlier to market competitors.

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

Idea for Another Life is like what the speaker had shared - it was difficult to implement with the limited resources. Besides, it’s not like that the team was domain experts that stands a fighting chance in the sea of game apps.

Hence the switch to Fan Gang, is workable, more practical. Even if the apps failed eventually, well, a few users would have tasted being hoisted by fans. Yeah!  An important feel good experience especially at the adolescent phase (students)!

Remind me of the story of “Save one starfish at a time, this is what matters” – kind of like if you have uplifted one poorer soul, one person with inferior complex, the app’s short life would have mattered. A good Samaritan app, a job well done, even if it has redeemed only one person’s self-worth, and who has gone on to live a better life.

4.    Should the team have changed their idea mid-way…?

Generally, no!  Adopt Lean Startup process.  If scope is too much, cut down the frills to essentials (keeping cutting down) =  Minimum Viable Product.  Only after market tested negatively,, pivot is a must. You don’t jump ship out of fear. Captains don’t jump ship. IMVU (Avatar game app) won’t be what it’s today if the team had bolted.  Apply Lean Start up!

5.    List the major problems faced by the team. How could they have done it differently and better?

Well…. relatively easy to say on hindsight wisdom.  Many things could have been done and said. However, that’s not the point.

Persevere despite the uncertainties, hallmark of startup entrepreneur, however, an important caveat: Adopt a structured, learning process such as proposed by Lean Startup. Even having failed, get some learned lessons out of the process/journey.  I recalled a quote that went something like this: “Pick up some sand as you rise from the fall.”

6.    What did the team do right/well?

They persevered, they delivered the apps. What matters is that they honored the obligation, the promise made to deliver an app, despite  the odds.

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)?

Ideate on options given the circumstances; consider each decision and understand the trade-off with the associated pain.

Example, one option is to seek Professor’s permission for postponed app delivery, explain the birth complication, try philosophical and creative reasons, which may earn some sympathy points, though unlikely.  Other option may include roping coder-friends help.

However, it’s so easy to take this or that path during a tight timeline, in desperation.

Hence, most importantly, it is to recognise to ideate options as the foremost action. Any decision to be made should be made on understanding the painful trade-off of each option. Decision cannot be done in a hasty manner. And the ability to handle this moment of painful decision becomes the opportunity to test the strength of an intellectual person.

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?

Understand the fact first hand, find out about his/her circumstances. Evaluate what are the other options, once it is established that he/she is really in a troubled state. No point crying over spilled milk. Move on: opportunity to be test one’s or team’s ability to adapt, be resourceful or creative and also find out who truly are you friends in need (the strength of your network of people who can lend a helping hand).

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

So many of our CS3216 predecessors went thru’ the growing pain.

Part of life’s creative chaos, the creative destruction to recreate new paradigm, to let go of old belief that is no more valid.

If the pain has produced tough graduates, who go on to create other successful apps thereafter; then it becomes a reward to future CS3216 generations with more fascinating account of how the CS3216 graduates of yesteryears braved the brutal outside world and lived to shared their success stories.

Then all the growing pain has not been in vain!

Kudos, seniors!

CS3216 Case Study I on UI/UX of "Get Help!"

Looking at Get Help! Screen shots, I have these to comment.
1. Useability vs Aesthetics

Asthetics factors: To match the theme of “help wanted!”, consider using logo and aesthetics that shows or convey the  Geneva Red Cross or equivalent. First impression counts, especially elements of urgency to complete the feel (timer!) 

Scream slogan like “Help me!!! By nnn date, time or else I die!” Be cheekiness does help get attention and users!

Useability:  Let elements of creative difference from the average Joe’s help wanted site. Novel functionality such as activating a time countdown and while value reward  diminishes is one example (inversely proportional) to the help wanted.

2. Number of options/ freedom given to user when posting a need.

It depends on product positioning of website Get Help! Now it is “free for all”, no catogerisation, that is too broad. If site is designed for IT project related urgency  or emergency, then option is really having tools to assist help needed user to filter out unnecessary info. Value add to users, helping them to keep it short and sweet.

3. Cycle of interaction & incentives ( Are the elements of the app engaging?)

Cycle of interaction is probably already minimalist, and thought through. With regards to incentives, what is important is before incentive. Could site have been more engaging if app owners /moderators are seen to be expert in one domain, when setting out this Get Help – Credibility of site is important to attract users and helpers, the draw of networking of like minded ones. Of course incentives are nice, but many who seek to help gained in intangible terms, that is an important lure – seen as experts or become better (knowledge, pedadogy) by helping others.

During the workshop, it was interesting to learn from Su Yuen that Kisses reward makes helpers happier than points!  Talking about emotional draw, what an insight!

 4. Other problems the team might have faced.

Likely problem: Gaining traction. Helping everyone or every situation is kind of ambiguous. It's like two ways of reading this word NOWHERE.

Consider these.

- Clear product differentiation, positioning.
- Tools and aesthetics that amplify Help Needed URGENTLY!
- Be in the domain of expert of Help so that articles can be written by site owners while helping others and roping other into helper.
- Product differentiation options: Tech Startup,
- Incorporate a web personality: example, Light and hearty and/or cheecky? "Help for Programming Guru and Goondoo!" Slogan: Hey, the world won't collapsed even if no hero comes to your rescue.

I am running out of ideas and I have still another case study to write - writer's BLOCK! OH...... HELP!!!!!

Psst, anybody reading, anyone out there?! Can help finish writing my other Case Study II (not difficult one......good rewards assured. don't let prof knows; psst, Su Yuen, can re-activate your site, may be able to get some help?  pleezzzzeeee.... : (