4 simple guidelines for whatsapp groups

Since March of this year i.e. 2013, I have been in India, and I have realized how intense text’ing via phone can be. Most significant player is the whatsapp application on smartphones.

One can very easily form a community group using this app.  It’s an exciting idea to stay connected and virtually be social. I am part of multiple such groups. As time passed by, I learned what people in a group like most and dislike most. There’s commonality of these likes and dislikes across groups. Based on that experience, I have draft’ed 4 simple guidelines for the whatsapp group members, to help make the group more fun and enjoyable experience for all it’s members. Guidelines to make the group more like’able then dislike’able.

4 simple guidelines for whatsapp groups

  1. Express yourself in your own words
    We, as a society are being constantly bombarded by stuff that someone else thought and worked upon – TV, Movies, Ads, Hoardings etc. It’s lot of in-take. Lets not make our dear group an addition to the list. There should be something going out. Make your brain put in that small effort to express yourself. It simply boils down to – avoid forwards and express yourself in your own words!
    (This may turn out to be quite hard for those who absolutely have nothing else to kill their time other than forwarding messages around, across different groups)
  2. Only 1 forward on a given topic at a given time
    I totally get it. We get lots n lots of good forwards. Some of those forwards are so good, you might be convinced, sending those out to your friends would not just change the way they would spend their day, but change their life altogether for good! But please limit such forwards, to only 1! Multiple forwards on same topic, sequentially, not just pollutes the topic but in fact kills the interest of the reader and she/he won’t even bother to read ’em. And then you would miss out the noble opportunity to make a difference in your group members lives! That would be absolutely sad.
  3. Upto 3 forwards maximum, in a given day
    There are so many of us in a given group. For each member, lets limit ourselves to maximum of 3 forwards in a given day. For social well-being and to promote overall happiness in the group, it is important that one curbs the intense urge to forward 100s of messages. Instead one may only forward upto maximum 3, in a day.
  4. Punish offenders
    This guideline is for offenders. Each group should decide for itself, what would be the repercussions for those who offend the above 3 guidelines. It may turn out to be simple form of punishment like – every other group member curses the offender or maybe something milder like – the offender is banned from the group for a week (note: she/he may attain nirvana by then and never join back!)

Please Note
All above guidelines are *just* guidelines that my brain i.e. explicitly and personally mine, could come up with. I dedicate these guidelines for a good social cause. For a potential awakening, an enlightenment for, maybe a few. There is absolutely no intention of any kind of harm to anyone and no responsibility shall be taken in any case, if by following these guidelines some of your group members are unhappy and come after you for proposing it!

Enjoy whatsapp’ing…

Advertisements
4 simple guidelines for whatsapp groups

Numbers @ Krossover

Data as of 14th Jan 2013 (since Oct 2010)

Data Point

Total

Basketball

(Oct 2010+)

Lacrosse

(March 2011+)

Football

(July 2012+)

Tagged Events  16.8 million 15 million 1.1 million  0.7 million
Game Play video clips  4 million 3.7 million  0.2 million  0.1 million
Video uploads
per day
 1.5+ TB
Video transcoded per month  1.1+ million minutes raw,
4.4+ million minutes considering HD and other flavors
Numbers @ Krossover

Matrix: Krossover – Amazon AWS Services

 


Services

Krossover Products

Intelligence

iTag

KVS

1

RDS

X

X

X

2

EC2

X

X

X

3

Elastic Load Balancer

X

4

Security Groups (Firewall)

X

X

X

5

EBS

X

X

X

6

Ephemeral Storage

X

7

SQS

X

8

Cloud Formation

X

X

9

IAM

X

10

S3 Standard Storage

X

11

S3 RRS Storage

X

12

ElastiCache

X

13

Cloud Watch

X

X

Intelligence

Krossover’s flagship product that provides game-film break-down, analytics, field-charts, stats as service for various sports

iTag

Indexing platform used to break down the game film into plays and tag each play with various events

KVS

Abbreviation for Krossover Video Services – the core video encoding, storage and streaming service

Matrix: Krossover – Amazon AWS Services

Elusive Simplicity

Ideally, one should always adhere to the KISS principle. But determining whether one is on the right path may not be that simple.

Simplicity can be elusive. Especially more at the on-set of any new undertaking. After working for a while on something, eventually the ‘real simple’ path may appear and seem obvious. Only the realization experience of spending time and efforts on not the ‘real simple’ is always bitter.

How to determine ‘real simple’ ?

Lets try a very broad classification into 3 categories to help us get handle on elusive simplicity:

  • Seemingly Simple– Seems very simple at first glance but isn’t really so. Proves itself as bad choice after a while, after some time and efforts have been spent
  • Real Simple– Not very obvious hence ‘seems complex’ but simplicity becomes very evident after some discussion. Might need little bit of more time and efforts than the ‘Seemingly Simple’ solution
  • Real Complex– Not obvious at all, even after considerable discussion

 

Elusive Simplicity Table
Seemingly Simple Real Simple Real Complex
Usually quick turn-around implementation Little more turn-around time Lot more (never ending) turn-around time
Too obvious Not very obvious but evident after some discussion Not evident even after lots of discussions
Rigid Flexible Extremely rigid, single purpose
Not scalable Scalable Not scalable. May become nightmare to just keep it up and running
Has tendency to become complicated soon enough like a simple string that gets tangled very fast Has tendency to continue to remain relatively simple as the system grows Has tendency to break, collapse, crash
Some expense of gray matter Considerable expense of gray matter Extreme wastage of gray matter
Most opted Most sought after Most feared
Short-term happiness, long-term pain Short-term pain, long-term happniess Always painful
Too practical Practical Less practical, more theoretical

POINTER: So, given a problem, think for at least more than 1 solution. ‘Seemingly Simple’, the most obvious, quick to implement, maybe easy to determine. ‘Real Complex’ solution, if any, may also be easy to weed out. Out of the remaining ones, ‘Real Simple’ would usually be the one that takes less than 20% of more efforts than the most obvious ‘Seemingly Simple’ solution. One may safely opt for it!

Elusive Simplicity

Resumable Uploader

Upload is such fundamental aspect of any web service. And still, there’s no, simple, easy solution out there… Well, it might seem I am exaggerating it but for such basic functionality, if you add the ‘resume’ upload expectation, you should see the problem I am referring here…

So, for us @ krossover.com upload process has been a challenge. It’s been so for number of reasons:

  1. The uploaded content is videos. Raw, uncompressed, videos are uploaded usually from the video-cam directly or from DVD. On an average, upload content size is around 4 to 5 GB
  2. We have always focussed on providing the service as web application (no installations, just browser, as our users are Coaches who use school devices where they may not have administrative privileges to install applications) and do not have any desktop application, that can help out with upload and resume upload process. Though desirable and maybe at some point, we might end up having one but we got none for now
  3. We cannot really control the upload speeds at user’s end. And most of the Internet Service Providers out there, provide an extremely low upload bandwidth
  4. So uploads take hours. And the laptops, desktops or any other kinds of machines used for uploads, may go into sleep / hibernate (especially if you are on windows) or may just be out of battery power (in case of laptops). For umpteen number of reasons, the upload process might break!
  5. Hence we needed some ‘resume’ upload functionality. We did have it. Or did we? Well, if it were an upload of 5 files and upload broke on 3rd, next time, you would need to upload only the 3 remaining files. Though, 3rd had to be started again. And you had to notify the user about failed upload and user needed to select the remaining files and re-initiate the upload for those remaining files
  6. So after spending an hour or more at uploading, if it broke for any reason, it’s quite frustrating for the end user to bother about broken upload and figuring things out to be able to resume
  7. while upload happens, user cannot go to any other page. we tried to solve this problem by using a small pop-up, that gets triggered when user starts the upload process. Who doesn’t hate pop-ups?

All above, is quite complicated! You would hate it that your end users have to put up with it all. Browser / HTML, does not help you out to be able to come up with some solutions. Well, HTML5 now supports Web-sockets that might help, but it’s still not yet supported by all browsers.

Hmm. So what can be done? Use embedded, run-time components implemented in – Java or Flash or Silverlight, and implement resumable upload functionality! That now adds lot of complexity to this fundamental upload process. We’ll see how. I am just going to go ahead and describe how we did it at Krossover.com.

For some good reasons, one being wide use and acceptance, we chose Silverlight. In fact, we had started with an open-source library – Plupload during our first roll out. But since then, we have revisited the upload code-base so many times and tweaked it so much, that now, it’s turned out to be totally different and independent from it. So, we started by using the Silverlight upload solution provided by Plupload. It’s a great, ready to use library out there. It has many great features, you can checkout their site. But it did not have ‘resume’ upload functionality, which was so very crucial for us.

Well, for an upload to be resumable, few things need to happen:

  1. Save the start-state of your upload, that has all information about the upload, even before upload starts
  2. Start the upload and constantly update the upload-state information, when a part of the upload is complete
  3. In case upload broke and upload has to be resumed, implement a mechanism at the server-side that:
    1. detects automatically, that there is a broken upload for a particular user, when that user revisits (be user-friendly)
    2. provide server-side service (api) that can be called to provide information about the upload-state of a particular upload
    3. trigger the resume upload process
  4. Once the resume-upload process is triggered, it needs access to the content, that did not get uploaded completely. Browser does NOT allow that, for obvious security reasons. So you need to tackle that problem
  5. Finally, after having access to the content locally on user’s machine and getting the upload-state from server-side api, resume the upload process

How did we do it? We ended up rewriting and adding lot more to the default Plupload’s Silverlight component and javascript code base. It has been customized so much that for now, it’s use-able only by us. If we are able to spend time and resources, it would be desirable to tweak it such that it can be used by others, who are facing the same problem like us. But it’s little harder, as there are 3 places where the code needs to be in sync – Javascript land, Silverlight land and your server-side land. Here’s how:

  1. There’s javascript ajax call, that sends all the upload information, before the upload actually starts
  2. In return, the server-side api provides a GUID i.e. the upload identifier, for this particular upload. The upload-state information gets saved and identified by the guid henceforth
  3. Javascript triggers the upload process via Silverlight component
  4. The Silverlight component actually spawn 2 Silverlight worker threads – 1st to upload the content to the remote server chunk by chunk and 2nd copy the content locally into the user’s ‘Isolated Storage’, where Silverlight has access permissions (use of Silverlight’s Isolated Storage has been our answer to overcome the limitation that browser puts forth against direct access to the user’s system)
  5. The local, isolated storage copy is done wisely. It involves copying in the reverse order (i.e. last parts are copied first) and it constantly checks if it has reached the part that been already uploaded. If so, simply stop, cause there’s already enough content copied locally on the isolated storage to be able to resume the upload
  6. On every page, there’s a light-weight service, that checks if there is any upload to be resumed for the user. If there is, trigger it
  7. This gives user ability to be able to not just resume upload but browse to any page and upload still continues under the hood. Of course, it is assumed that local copy has already finished (for most practical purposes, local copy takes less than 5 minutes, hence we simply tell user that ‘upload is being prepared’ during this time…and then actually start showing the upload progress)
  8. There’s also a javascript monitor thread, that constantly monitors upload and calculates the upload speed and provides information about how-much time it might take for the complete upload
  9. For the resume-upload, there’s server-side API that pulls upload-state information from database, as well as, retrieve uploaded files information from the local filesystem. That helps the Silverlight at the client end to be able to exactly determine, which byte, it should resume the upload at.
  10. To add more to the mix, to make the uploads scalable, the uploads need to happen on different machines, so that many users uploading at the same time (burst traffic loads) don’t bottleneck on one machine’s upload bandwidth. This complicates resume upload, as the upload needs to be resumed only on that particular server, where it was started
  11. For video content, most likely you might want to transcode and compress the uploaded files. In our case, we even ‘stitch’ those videos into a single file, that corresponds to a game. To be able to do all that, you definitely would want a given upload to completely end up on the same machine, to keep things relatively simple for transcoding and stitching

I agree. It’s NOT simple, for something so fundamental to any web service. Implementing this solution, has been tough, I would say bit crazy. But we finally managed to do it all. It has been worth it though! Upload has been simpler, less taxing part of our service to the user. I’ve heard few compliments that made me feel happy and proud!

Resumable Uploader

What newbie start-ups don’t want to learn from successful startups

It does sound surprising but it’s mostly true

Most of the successful startups are giants today. So whatever cool and crazy stuff they do, is attributed to their giant-ness, capacity i.e. they being very big can do all that funky stuff. Really? Is that definitely true? Maybe, they’ve always been doing funky stuff, pushing the boundaries, hence they are successful? Is it about ability or is it about capability?

 

Ability versus Capability
Ability versus Capability ?

 

The above image and the one below, I’ve linked are from a very interesting article. Yes, it takes efforts, to get out of comfort-zone, go that extra mile and achieve it. Who says success comes easy? Unless you are extremely lucky, in which case, it might be short-lived!

 

Comfort Zone
Comfort Zone

 

Startups should be nimble. It’s inherent and natural for them to be super flexible, re-define the norms, walk on that never before walked on path. In a way, I guess it means, newbie start-ups should not just be doing the best that’s already been done by other successful ones, but surpass them.

 

Well, based on above 2 graphs, that does mean:

successful start-up = [ ever changing, discomfortable, ever pushing can do and how-to boundaries ]

I do believe, if you – as an individual of a start-up or a start-up itself does fit in the above definition, chances of success are huge!

What newbie start-ups don’t want to learn from successful startups