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.
Relearning
Wednesday, 17 October 2012
Tuesday, 16 October 2012
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....
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....
Wednesday, 3 October 2012
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.
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.
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.
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.”
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.
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!
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
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).
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!
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
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.
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!
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.
- 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.... : (
Tuesday, 18 September 2012
Lean startup - luv it ^ ^
From the start flare, it was as if Assignment 3 Team 6 (members: Yuan Kai, Tuan, Qiao Liang, Chris Cai, myself) have made multiple 100-metre sprints, based on the the fast and furious to-and-from messages of listed ToDo tasks and the Tasks Done list that were accomplished - impressive team coordination under the leadership of Chris.
Over the one week or more, I was on a mission, to see if I can contribute from another perspective to the team of three coders & one designer who have labored hard and fast.
Hence, I devoured articles on the project related businesses and attended presentations (at last Sat's Tech Launch). A few words kept surfacing - Lean startup (Eric Ries), UX, Minimum Viable Product, Minimum Viable Business (Pollenizer) and Progressive User Adoption Strategy.
Last evening, I was pleasantly surprised when AWS speaker spoke about Lean Startup and even gave copies of Eric Ries' books - fabulous, I got hold of one of Eric Ries book too! And last night, I can't wait to read at least one section of Lean Startup book by Eric Ries - it provided insights on why many startups failed. For me, it's a reflection of my own failed entrepreneurial journey, and the insights glimsed were nothing short of amazing.
More importantly, it points to the direction that the startup processs could be managed objectively using Minimum Viable "--" , Lean UX, and the iterations of 3 interacting forces throughout the startup before sustainable growth is attainable: coding, users, and business sense/cents.
Much thanks to Colin, I was allowed to share my understanding of how the lean startup concept is relevant in our CS3216 context - tho' my proposed model would have looked rudimentary and the slides over wordy (apologies, attribute it to first cut fumbling lah : p).
At long last I have found the answers that I seeked: how is it that I failed my entrepreneurial pursuits time and again, and I could never seems to fathom what have I done (gone) wrong.
For once, I see the light at the end of a long journey - a new hope, a new beginning!
Luv life, luv it ^ ^
Over the one week or more, I was on a mission, to see if I can contribute from another perspective to the team of three coders & one designer who have labored hard and fast.
Hence, I devoured articles on the project related businesses and attended presentations (at last Sat's Tech Launch). A few words kept surfacing - Lean startup (Eric Ries), UX, Minimum Viable Product, Minimum Viable Business (Pollenizer) and Progressive User Adoption Strategy.
Last evening, I was pleasantly surprised when AWS speaker spoke about Lean Startup and even gave copies of Eric Ries' books - fabulous, I got hold of one of Eric Ries book too! And last night, I can't wait to read at least one section of Lean Startup book by Eric Ries - it provided insights on why many startups failed. For me, it's a reflection of my own failed entrepreneurial journey, and the insights glimsed were nothing short of amazing.
More importantly, it points to the direction that the startup processs could be managed objectively using Minimum Viable "--" , Lean UX, and the iterations of 3 interacting forces throughout the startup before sustainable growth is attainable: coding, users, and business sense/cents.
Much thanks to Colin, I was allowed to share my understanding of how the lean startup concept is relevant in our CS3216 context - tho' my proposed model would have looked rudimentary and the slides over wordy (apologies, attribute it to first cut fumbling lah : p).
At long last I have found the answers that I seeked: how is it that I failed my entrepreneurial pursuits time and again, and I could never seems to fathom what have I done (gone) wrong.
For once, I see the light at the end of a long journey - a new hope, a new beginning!
Luv life, luv it ^ ^
Tuesday, 4 September 2012
Review: Pocket App - real cool stuff
Pocket apps is great for busy people who need to accumulate
a reading list of articles from the internet, own multiple platform devices (smartphone, tablets).
This app supports iOS, Android, and BlackBerry OS operating systems and for multiple computer browsers and operating systems.
Pocket is really cool stuff! Why didn’t I think of this
idea?!! Damn.
This app supports iOS, Android, and BlackBerry OS operating systems and for multiple computer browsers and operating systems.
Pocket holds a comfortable lead in the genre of bookmark /organiser
apps – the market share numbers is
telling –Pocket has 5 million users while the next nearest competitor, Instapaper, has 1 million users.
Judging from users’ number alone, there is great demand for personal
organiser for internet readers who are flooded by the deluge of web articles. I am certainly one of the lost sheep in the ocean of information over the internet.
Key functional features that made Pocket app a must-have
include:
1.
Tag it, Read it later, and Retrieval ease
a.
For time starved knowledge workers and students,
who spend hours on the internet stumbling across interesting articles, there is
no risk of lost urls or articles, with it’s simple tagging function
b.
Retrieval of articles and video is simple, it
has video support too.
c.
Handy pop up of articles, easy read to read as
users can customise reading (nite read vs day read).
i.
However, one missing feature is the lack of
pagination feature which would be great when reading lengthy article.
The ‘read it later’ and ease of
retrieval makes this apps great for increasing personal productivity - no more
lost urls or articles. Memorable slogan: Space Shifting, Time Shifting!
2.
Easy access: Categorised, organised
a.
Store and sort by categories using labels that
users can understand
b.
Store and sort by media mode: text articles,
videos, images
c.
Can sort by tag, article length, url
As a leading personal organiser
app developer, the intuitive manner of classifying and tagging makes it a
natural choice for the busy people with little time for learning user
interface (short learning curve).
3.
Social sharing options
a.
As plug-in, Pocket allows app user to share copy
via Twitter, Google Reader, Facebook, etc.
b.
Now, like-minded readers (or students) can form
user groups to swop and share each other’s articles, videos, tags and urls.
The fact that Pocket has leverage social media users, such
as Twitters and Facebook, means that we can swop and share articles, videos and
while promoting communication and productive bonding.
Friday, 24 August 2012
Vroom, Vroom, let's rev up, yipee!!!
Wow, before Assignment 1 on Facebook App is done, another gets started; Assignment 2 on Facebook/iPad Application Seminar team formation! Another round of musical chair playing, members go changing as each has to form another new team.
Interesting learning points this week:
1. Collin's story on 3 stone pushers: one sees it as a mundane task, another look forward to see the completion of a wall (seeing the tree but not the forest), and the last visioned the great wall!
2. Justin's Scrum Backlog Planner, a simplified form of Gantt chart - wow, the beauty of simplicity!
3. Like's Jonathan pointer on team work: Non coder can play useful role, that is buy Supper!
Peggy and I did that, and our two top coders, Kian Zhong's and Rui Feng's were at an emotional high upon receiving pizza at midnight in their respective rooms. Joy to the world (jingle)
Vroom, vroom (Harley Davidson's patented bike sound) let's rev up, yipee!!!!
Subscribe to:
Posts (Atom)