Posted by: worldpressams | August 1, 2011

Log @ your help – Guest blog post by Amit Kulkarni


AK: God please save me from this app, it crash every time I am about to finish the things.

Log: Hey, hi there! Isn’t the weather outside such a beautiful?

AK: Well, I don’t care about it. And by the way who are you?

Log: Well, sorry about that, I didn’t introduce myself. I am log – I help programmers/developers quickly understand the issue, so they can fix it quickly.

AK: So WTIIFM? [What there in it for me?]

Log: Well you will not come across these issues then.

AK: But I don’t know where do you stay, or rather how I can get help from you? You see I am not comfortable with these latest gadgets.

Log: I may appear to be a stranger but certainly I am always there with you. It is jus that you never notice me.

AK: Oh! Is it? But I am just a user and not a technical person who make out from some log or so.

Log: That is not a problem. You can help others to understand the issue and rest will be taken care by them.

AK: So what info are you referring to?

Log: Sure! Can you press this key now, yes that one, and now again this one.

AK: I already said don’t expect from me – I really don’t understand these gadgets. And yes, I really don’t want to do that exercise of pressing this/that key. Damn it!

Log: But….

Logs at your help

Oh! No. Not again. Just a few minutes back I’ve experienced a system crash and it was hard time troubleshooting it. This is seriously not my day. Well, that seems to be the problem with quite a few applications out there. You know the scenario: You are up to something important and when you’re just about to finish it, something goes terribly wrong and you lose all your work! This is so frustrating. I am sure many of you have experienced similar scenarios while writing a paper, browsing a web site or even when you are just a few more steps from completing that difficult game stage you’ve been working on for the last few hours.

When something that sort of bad happens – what is the first thing we do? We cry out loud for sure. Alternatively I’d like to see users becoming friendlier with their machines/devices and look out ways or information that they can provide to the support team in order to fix the issue they experienced.

I am a big fan of logs and whenever something goes wrong I try to analyze it in order to understand what went over here. The log indeed provides the vital piece of information that is useful for developers in order to fix the issue fast. Now it appears as if I am talking like a tester and hope that every user will do so as-well. A user who’s using an application/system may not have that sort of understanding, rather let’s put it this way – a user might never feel that need.

So here is my argument – I would like to see built-in ways of submitting application/system logs directly to the support team via the application itself. This will make it simple to the regular end-user to submit application crashes or system failures with no hassle, and on the other hand will provide essential info to the support team or the develop which will enable them to fix this issue quick and make their users happy than ever. It’s a win-win situation!

Most of the applications in the market do not have this built-in feature – however if they do I am sure it will be extremely helpful for them. The support staff will not have to bother the user too much to get more information and that means a user can breathe easily and know that by reporting such issues he/she assists the developer resolving any found issues. Alternatively, if an error occurred and the user did not report it – it might not get fixed soon, or at all.

Though I understand the cost factor involved from the companies that build applications while designing such built-in feature, however I believe that they do look at it as a one time investment. Please don’t expect your users to remember what they were doing last when the crash occurred. Integrating such a built-in feature will surely assist them providing that essential info you require to fix the issue. As a company or product owner you should avoid bothering your users too much for getting your issues fixed.

I seriously enjoy an application when I see a way of sending a feedback directly via it.

So far only a small number of devices & application companies integrated such automatic crash reporting feature. For example you can see an integrated crash reporting system on Android devices such as the Galaxy S as well as on some applications running on iPhone devices, also some application for BlackBerry do have this feature. That means that the technology is already available – however application companies & device manufactures/vendors should embrace it and implement it on their devices/ applications and make this a standard etiquette of quality and reciprocation between companies and end-users.

Yours truly,
Amit Kulkarni

Image: Filomena Scalise / FreeDigitalPhotos.net

Check out my about.me profile!

Advertisements

Responses

  1. Thanks Amit for this inspiring guest blog post!
    This is just the 1st bloom of a series of blog posts covering testing related best practices, debates and hands-on tutorials (see my earlier blog post on debugging Android devices using Motorola’s MotoDev Studio environment).

    Stay-tuned and subscribe to this blog.

    Cheers,
    Bernard.

  2. I like the idea, obviously I live looking at logs to determine outcome.
    But as I said in this post – http://www.miketheman.net/2011/02/10/sit-on-this-and-logrotate/ – too many developers create a log, without properly maintaing that log file.
    Consider this even more relevant to devices like mobile phones, tablets, etc – if you (the application) starts eating up all the user’s space with a constantly-growing log file, which application are they going to trash?

    Kudos on the article, and let’s really get the BEST practices out there!

  3. Great inputs Mike!
    If we’re discussing best practicing here, then I agree that developers should properly maintain their log files, otherwise the logs turn-out to be useless or at least not informative as they SHOULD be.

    I personally can’t sit in idle when I come across non-informative log files and I give all efforts to change it by explaining the responsible developer why I believe additional data should be added to an existing log. Moreover when I believe a new log should be created for a reason.
    Education is part of the game 🙂

    A few guidelines for a good log file will be:
    1) If it’s difficult to read/understand – Log should be revised!
    2) If you end up wasting a lot pf time translating parameters to understandable data – Log should be revised!
    3) If you throw an exception, however there’s not explanation what caused it or which module was affected – Log should be revised!

    I’d love to get more inputs regarding Log maintenance best practices from you, considering your vast experience in that field.

    Cheers,
    Bernard.

  4. Good thought shared by both of you and I see the point too.

    May be as Mike said there should be BEST practice should be followed with that. As you seriously don’t want to cost you a user just to plug this feature for that matter, if it is affecting the performance of the app. Then obviously that is a bad choice.

    There should be a way in which the logs are stored so it is not that every entry or warning is stored in the log but critical errors, stoppers, exception for these of course there should be that information available. for sure.


What do YOU think about this post?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: