home: kausikram

About

Sun, 05 Jan 2014 09:20:51 GMT

Kausikram Krishnasayee is a self taught computer hacker who graduated in Mechanical Engineering with a University Rank and a gold medalist from Loyola Institute of Business Administration's Executive Program specializing in International Business.

Kausik currently heads marketing efforts for KiSSFLOW a workflow product built for Google Apps Users.

Before this Kausik co-founded TourMyApp a user on boarding solution for Web Apps. He had also been the lead architect for ToolsForAgile, an Agile Project / Portfolio management suite for lean software development teams working in diverse environments.

Kausik was a co founder of Proto.in the startup event and until very recently was spearheading online and backend operations for the same. He currently is part of the National Leadership Council of the NEN E - Club and also Mentors the Entrepreneurship Society in his Alma Mater.

Kausik has spoken at several tech forums including PyCon India PyCon Asia Pacific and JSFoo. Kausik is also amateur Ultimate Frisbee player. While he is not coding away or playing frisbee in the beach he spends time appreciating music and practicing on the Mridangam.

His open source contributions can be found at Github

The art of engaging first time users

Fri, 22 Nov 2013 07:03:09 GMT

Have you ever shown a set of three foreign, delicious looking chocolates to a kid and said "pick one and its all yours" ?? Ever seen the way the child reacts? unsure on what to pick... Well thats exactly what goes in through your user's mind when he lands up in your apps home page the first ever time. 'Oh there are these attractive looking buttons and each does something. But where do i start, which button do i click and what should i do first?!'

The simple hard truth is this: Options are a bitch. Especially so when you have no clear idea on what each of the option would do. As a web programmer putting in three buttons on homepage and letting the user decide on what he wants to do amounts not to, giving choices to the user, but escapism in the part of the programmer.

Understanding and immersing yourself into an app is more or less like trying to do your shirt buttons with your left hand, Its not a hard task, but is definitely, tedious and time consuming and requires a lot of practice.

There is also another case. As a developer you would think it would be cool to get rid of the save button altogether, i mean all the user needs to do is edit text and close and Tada!! your text is saved. Isn't that cool?? you saved the user from having to perform a monotonous click on the save button. But guess what is actually going through your users mind : "Where is the save button? how does the save button work. Does it auto save? Oh wait this app dose not have a save button at all!! editing the text alone should do the trick. Darn."

So that ladies and gentlemen app developers, are the two ends of the problem. You either give the user a plethora of option from which he has to pick from or you do not give them an option at all when he is looking for one.

In either case you are making the user think. Every cluster of interaction in your app puts your users thought process through a decision tree, they have to think about the interface rather than the problem they are trying to solve in the first place with the app. No wonder they all complain about the app being "tedious" even though you "hacked" on usability.

A usability expert will come in and streamline your entire app and try to remove as many interface decision points as possible.But then it will just not be possible to completely remove those trick points, will it? I firmly believe that the user will eventually be put through an interface decision point, in every app possible as long as its not an online TODO list. UX fixes will plateau the peak of the app user experience, however it will never be able to bridge the gap between what is the expected usage flow according to the developers and what is going on in the users mind.

What to me is an ideal way to enhance the user experience in your app is to gently nudge your users at the various decision points to push them along the flow you want them to follow as an app developer. You should be "parenting" your users saying, "hey start off by clicking this button, we can come to the other stuff later"!!

Lets look at it this way, look at the following example, from a developers perspective its dead simple and straight, no complication what so ever, user can either post something in a forum or can read already posted options. Simple straight and clean.

As a first time user however this is what will be going through your mind. "Oh there is a lot of posts, wait what is an idea and what are informations and what should i do to get started? should i be reading up previous questions before i post or should i be posting my question and just move along, for thats why i ended up in the forum in the first place..."

Lets do an enhancement to this design, i am now going to do a dangerous thing, i am going to assume as an app developer that most of my first time users have signed up not to browse the forum, but to post something. So everything else in the page apart from the three simple buttons on the top is noise to them and their thought process. so we will go ahead and put a floaty arrow on the page for the first time users alone to point towards the three buttons on the top to post a question, idea or information.

You have managed to seek your users attention to an extent with the arrow and you have pointed him down to the place where he can get started, this is a good start. However this Â is what will be going through your users mind when he looks at the above interface cluster: "Hey i have something in my mind and i am sure its definitely not a question. but should i post it under information, because its informative or should i post it under idea, and hey is it even possible to change an idea later to information"

Designers try to simplify the user experience by providing your entire app in crystal clear shades of black and white, however, the real world especially for the first time user is neither black nor white, its a myriad shades of grey. Users constantly try to read through the interface to decipher the 'flow' of operation and if this flow is not made explicit in the first go, users get confused and frustrated. Â To the Above example we will add one more enhancement that looks as follows:

Now if you see, you will realize that we put a small float box on our app that says that, you can start trying the app by clicking on either of the three and that, it is indeed possible later on to change the category of the post. Cool, the user now knows that he can go ahead and post and that there is also contingency against any screw ups in post categorization. You successfully helped your first time users cross over the information decision point related to this particular cluster of user interface elements.

The art of engaging first time users is to be present with them across these interface decision points and get them used to the "flow" of the app. Its like walking through the jungle, and you as the app developer must leave a trail of bread crumbs for your users to follow.

This is the thought process that went into our minds when we started writing Tour My App six months back. We want to be able to help our fellow app developers with enough 'bread' to leave a trail of breadcrumbs. At Tour My App you can create tour guides to walk your users through the app's flow, so that they get engaged and productive quickly. You can save them from having to explore the vast expanses of your app and engage them in a process of guided and layered discovery. In short you can make them enjoy your app without many of the WTF moments associated with the usage of a new web app.

Weekend cleanups

Sun, 02 Jun 2013 12:31:03 GMT

Matilda needs an overhaul :/

the matilda server needs to run as a deamon. hoping i will do that by the end of the day.

Why your UI polish should match your Userbase

Fri, 26 Oct 2012 10:32:00 GMT

TL/DR: Web UX design is never a one time upfront activity.

Today we had announced a new version of our Tour Builder at Tour My App and i thought i would take some time off to chronicle what went into the process. I realized that writing this down now will be useful not just for others who are developing products, but as a reminder to ourselves for a later date.

The Beginning

Status of Tour My App: 100 lines of crude code.

Sid and I have been great believers of the Lean Startup Ideology. One of the things that we learnt from our other product ToolsForAgile is that we have to launch as early as possible and then get started on the feedback loop. We wanted to put our idea to test right from the first day. We were lucky by the fact that we managed to build a very crude prototype of it at in50Hrs around 8 months back. 'Crude' is a very gentle word to describe what we had then. What we really wanted was to see if people could relate to the problem that we thought existed, and more importantly, if people would be willing to pay for the solution. We got a brilliant response there, which answered the question we were putting to test. the answer was simple, people were ready to pay. We signed up our initial customers right there. These were the rockstars who would later help in moulding Tour My App.

The No Design Phase

Status of Tour My App: 400 lines of semi-crude code. A strong Tour runner logic. No Tour Builder.

This is the phase in a product life time where all of us tend to screw up. A lot of people have the tendency to take the positive response we get from the MVP showcase, disappear from the world for the next six months and then come forth with a very complex product at the end of the period. More often than not the "TADA" reaction that they expect ends up being an "Uh-ohh" reaction. What people dont realize is that the previous step was just a confirmation that the problem existed and people wanted it to be solved. However it did not give you a wildcard telling that what ever you develop is THE solution to the problem. This is a quicksand territory and most of the times people get neck deep into creating a complicated unusable product before they even realize it.

We wanted to avoid such a situation at Tour My App. So what we did was simple, we wrote most of the backend part which was mainly CRUD and wrote the logic engine in javascript that would run our tours. we did not bother to write our Tour Builder at this stage, even though we knew that was our USP. We would setup meetings with our alpha testers and we would manually feed the tour data into our database. It was tedious, but on hindsight it was worth it. It ensured that we did not sit in a box writing code that people will not use. It made us get out and interact with our customers. We were able to visualize the process flow that our users wanted to see in the product. And yes you guessed correct, we were wrong about some of our assumptions that went into the Tour Builder design brainstorming we had thus far.

The Crude Design Phase

Status of Tour My App: a few thousand lines of code. lots of tests. Rock solid backend. a pathetic looking Tour Builder.

People seldom talk about this phase. Some of them will not even enter this phase. People will try to hurry up to finalize their interfaces. Some will even be cocky enough to freeze all UX developments altogether and start thinking about scaling, marketing and other operations. Problem is UX ENHANCEMENTS CAN NEVER BE FROZEN. Its one of those things that requires constant work through the lifetime of the product. (even while its on maintenance mode). This is because the range, style and pattern of user interactions is constantly changing along with the enhancement in devices, and because of an ever changing design paradigm which is in vogue at that moment.

At Tour My App we knew that we would never hit the nail in its head the first time around. Yet with an ever increasing number of alpha customers we had to have a better way to create tours rather than entering things manually into a database. We also needed to start making it possible for our users to design their tours without our help. After all that was one of the promises of the product, and we better meet expectations. We built a very crude UX for the Tour Builder. Sid and I hacked it over a weekend. It was based on the flow that was envisioned based on the various customer meeting sessions we had had thus far. It was an interface that would meet expectations but that would not Wow you out. Its the "something better than nothing phase". We even have a video of what it used to look like.

it was ugly. But it solved the problem. and It was a much 'cleaner' solution that what people were used to doing.

The Redesign Phase

Status of Tour My App: a much more cleaner and field tested Tour Builder.

From the zero design phase to a 'cleaner' design phase is transformation that is mandated by logic. Your initial customers will be okay with crappy design, they are ideal torchbearers, your well wishers who would put up with a crappy interface, mainly because you have been providing priority support to them in solving their problem until then. But when you move to the beta phase you will no longer have the time or the bandwidth to communicate with your customers. Your customers will no longer be able to put a face behind the product. They will start receiving emails from support email addresses . Naturally they are going to be more critical and less forgiving. The question is however how you get to through this transformation. Is it evolutionary, or revolutionary ?

Sid and I believe in a kaizan approach to product design. We make small changes measure its effects, and adjust the changes to get better results. We knew we had to do a design change, but then we did not want to go for a TADA moment. Over the last couple of months we came up with subtle changes in the way the Tour Builder looked and functioned. After every such change we would have a usability test. We consciously chose for the usability tests people from various fields, to address all our use cases. We consciously made an effort not to end up selecting just geeks similar to us. In fact, half of our customers didnt even know that they were helping test usability. Most of the meetings will be at coffee shops. we will let the other person have a free run at the Tour Builder, and we will observer their every operation. We will meticulously note every point where they get stuck up and try develop the Tour Builder such that it solves the problem in an obvious manner. It was an iterative process and took a long time and the end result is finally here in this video.

We know for sure that this is definitely not the best design. But we also know for sure based on all our usability sessions that this is a design that will not create confusions. In fact we are proud of this design.

The Design Cycle

As you must have seen our approach to designing the perfect interface went somewhat like this:

Realize there is and will never be THE perfect design.
Realize that UX is a constant incessant process.
Realize that working is better than perfect.
Realize that less confusing is nearing perfection.

We believe in a feedback based approach to design. We make small changes tests its effect in the near future and incorporate changes, test it with users and correct if needed. We do not lock ourselves in a box come up with a design based on personas, use cases and risk missing the mark altogether. ITs a slow and meandering approach, but with time it gets much closer to the mark than any other possible way.

So i wrote Matilda!

Mon, 10 Sep 2012 05:40:19 GMT

I had announced previously that i was planning to write a new blogging engine. Well i found the time to do so this weekend. After around 40 hours of coding i would like to announce Matilda a python / flask based static blog engine with an on demand dynamic management page. In other words, your blog entries are stored and served as HTML, but we also have a copy of it in a flat file database system which can be edited through a backend.

I do plan to open source it soon, in fact there is a public repo already and i have started pushing to it. However, there are some cleanups to be made without which i will look like a n00b python coder and the project will look half baked.

But i must admit that i am really proud and happy by the way Matilda has shaped up this far. And yes you guessed it right! This Blog is now powered by Matilda !!

In App Tours are NOT band-aids for bad design

Mon, 10 Sep 2012 05:31:07 GMT

A week back while i was browsing the Internet i read this comment by some one which said that in-app tours are nothing more than band aids to bad design. It infuriated me! the part that got me worked up the most was not the band-aid bit but the two terms "nothing more". The past few years i have been observing this trend of people over-stressing on UX and usability telling that it is the solution to make your app popular. The movement has become so blind that people now-a-days assume that getting a usability expert and getting him to come and redo your app, would make the app a super success over night and would make your users love it the second they start clicking away. Because of this blind belief people have come to a more deadlier conclusion, that UX alone will make your app usable and an app without UX would become unusable. Thus to people like these, in app tours and other aides are nothing more than patches, Band-aids, that try to cover up poor UX design underneath.

I never ever could understand this logic. Coming from a background of mechanical engineering, I always try to draw parlance to Ergonomics and I am going to try explaining to these people why they are so wrong. While designing a physical product, engineers consider ergonomics of the design. Simply put it is a process to make it easy for the user to use the object based on his physical, cognitive and environmental limitations. That is why your microwave has a instant heat button, and your photo copier's instant copy button is made large. Usability in web app development is something similar, it is about making it easy for the user to "use" the app without having to put a thought into it. Usability starts and ends there, and using it as a tool for on-boarding your customers is like giving an ergonomically designed food processor to a person who has never entered the kitchen. Simple and important steps like:

Developing the desire in the person to cook
Helping him out with recipes on how to cook

etc are forgotten. Assuming that a "usable" web app will get your new user productive is like assuming that giving an ergonomically designed food processor would make a kitchen novice a chef de cordon bleu.

What we web app developers keep forgetting constantly is this tiny little booklet that comes along with the ergonomically designed food processor. The Instruction Manual. A lot of us have no documentation, and a lot more of us have crappy documentation that goes no where near helping the end user. We have a habit of giving circuit diagrams of the food processor when all the person wants to know is how to whip cream quickly.

This is exactly where in-app tours and other such aides come in. It aims to help your user quickly overcome the learning curve associated with a new app and hence get your user to become productive. If properly used, its not a superficial plastic surgery on top of your app, but a genuine effort to get your users to appreciate whatever usability you have built into your system. In short its the missing instruction manual, which is to the point and which is just a click away!

The art of engaging first time users

Mon, 10 Sep 2012 05:31:06 GMT

A usability expert will come in and streamline your entire app and try to remove as many interface decision points as possible. But then it will just not be possible to completely remove those trick points, will it? I firmly believe that the user will eventually be put through an interface decision point, in every app possible as long as its not an online TODO list. UX fixes will plateau the peak of the app user experience, however it will never be able to bridge the gap between what is the expected usage flow according to the developers and what is going on in the users mind.

Lets look at it this way, look at the following example, from a developers perspective its dead simple and strainght, no complication what so ever, user can either post something in a forum or can read already posted options. Simple straight and clean.

You have managed to seek your users attention to an extent with the arrow and you have pointed him down to the place where he can get started, this is a good start. However this is what will be going through your users mind when he looks at the above interface cluster: "Hey i have something in my mind and i am sure its definitely not a question. but should i post it under information, because its informative or should i post it under idea, and hey is it even possible to change an idea later to information"

Designers try to simplify the user experience by providing your entire app in crystal clear shades of black and white, however, the real world especially for the first time user is neither black nor white, its a myriad shades of grey. Users constantly try to read through the interface to decipher the 'flow' of operation and if this flow is not made explicit in the first go, users get confused and frustrated. To the Above example we will add one more enhancement that looks as follows:

Paver - Windows XP - Python 2.7 issues

Mon, 10 Sep 2012 05:31:05 GMT

Just realized that paver (v1.0.3) [and possibly up to 1.1] will not work normally in a WinXP machine running python 2.7.3 and up.

A bit of googling around and i found that the actual reason for this is because of this issue

Now since paver uses its own custom version of the super cool path.py module, the above link and its patch have not been merged into production.

There is a merge that was made into paver a year ago [ issue 16 0n paver] but this is not the latest version of path.py

The only work around to get your build scripts working on an XP machine on py2.7 now is to hot patch your paver's path.py with the following changes

Hope this helps other people who are breaking their head right now on the same problem.

Also, am wondering alound, how much would it take to rewrite the path.py paver so that it uses the original path.py and then a wrapper around it to make it paver specific.

I Feel an urge to write again

Mon, 10 Sep 2012 05:31:04 GMT

Well i feel an urge to write all of a sudden. i have been feeling this urge for a while now but there was a visible blocker on my way. A few months ago i got totally fed up with wordpress. A little negligence from my side and some random cracker decided to use one of wordpress' innumerable vulnerabilities to exploit my system. I swore then not to ever use wordpress and to write my own blogging engine. I ended up doing that as well, i wrote a really really simple engine that does its work pretty well. Best part was it was static and it was fool proof. only problem, the new blog uses a url schema which is super simple and completely different from my existing blogs schema. End result: i had a brilliant system but putting it will basically kill my existing perma links. What i needed now is a way to basically maintain my current schema and still serve from my new engine. I needed now a re routing engine, as a simple apache mod_rewrite / redirect solution did not sound appealing to me. so yeah i lost interest and i never got to finishing the blog. Anyway since i dont see the blogging engine coming out anytime soon i might as well start posting here. got tons to write about varying from sloppy services at restaurants to usability issues at IRCTC to music camps in ooty. Lets hope this post breaks the jinx and gets me to start typing again.

Airborne Team Discussion

Mon, 10 Sep 2012 05:31:03 GMT

This just happened a few minutes back in the airborne group. a bit of background here, Waseem hurt his toe and is worried on whether it will heal on time for the kodai tournament. =================================================== So Waseem starts off

Mohammed Waseem Toe play or not toe play, that is the question! #ShakespeareanDilemma Like · 42 minutes ago Rajdurai Rajan likes this.

Then Kaveri Replies:

Kaveri Murthy Whether 'tis nobler in the mind to suffer...? 39 minutes ago · Like

The conversation goes on:

Mohammed Waseem The discs and cleats of outrageous fortune. 38 minutes ago · Like · 1 Kaveri Murthy ‎'tis consummation devoutly to be wished. ; ) 34 minutes ago · Like Mohammed Waseem To play; perchance to dream. Ay, there's the rub. 30 minutes ago · Like

I am bored and i step in

Kausikram Krishnasayee Frailty thy name is Waseem. 26 minutes ago · Like · 1 Kaveri Murthy To grunt and sweat under a weary game, But that the dread of injury after play 25 minutes ago · Like Mohammed Waseem The fair Kaveri! Nymph, in thy orisons Be all my layouts remember'd. 23 minutes ago · Like Kausikram Krishnasayee Oscar Wilde: Are the commentators on "Hamlet" really mad, or only pretending to be? 21 minutes ago · Like Kaveri Murthy ‎Kausikram- All the world's a stage, and it's men and women only players. :) 16 minutes ago · Like Mohammed Waseem A veteran journalist has never had time to think twice before he writes (or copy/pastes). - George Bernard Shaw 14 minutes ago · Like Kausikram Krishnasayee ‎"What's in a name? That which we call a rose By any other name would smell as sweet." #ThatsAlllTheShakespearIKnow #irrelevant 10 minutes ago · Like

Finally Captain Cool gets in

Vinay Seshadri K P Karuppu

NOW THAT IS WHAT IS CALLED #WIN :D haven't laughed like this in a long long while :D