Monday 29 April 2013

Lessons from Shipping

We are developers..that's not the breaking news. According to Marc Andressen :
 "Software is eating the world" ,
 and as developers we are fueling the Frankenstein's monster. Everyone develops for a different set of audience. Some people develop for developers (think API's, IDE's) . Some develop for "clients". But for once everyone should try to ship an app for those who are not like you (developers) and those who don't give you any configurations (clients). Develop for those, about whom you don't know a thing. There may be people who feel that black backgrounds look good, while there may those for whom black backgrounds suck! What are you gonna do in such a situation.

"CODE FOR YOUR GRANDMOTHER"

Yeah that's right.

Lesson No.1: Think of the user as a complete newbie to computer who has been made to sit in front of Linux terminal and asked to do a git rebase. In my experience, my app totally sucked at user experience when I gave to some people to test it. It's help commands were not good enough, my app was not responding the way they wanted them to. 

"DON'T ALTER THEIR NORMAL BEHAVIOR, ALTER YOUR CODE "


Lesson 2: User's are very lazy when they have to learn something new (after all computer make life easy!). eg.: When an action has to be completed the user is accustomed to hit enter. You should include this as a part of the code. Don't expect the user to change such normal actions.
Lets take another example,
Windows 8, what's the biggest complaint you hear about it (before continuing, This is being written on Windows 8). Most people don't like being pushed in and out of metro. Like if you open a music file on the good old desktop, you are catapulted into the metro world, Full screen with no hyphen,square & cross to do stuff with it. They are completely bedazzled.

"READ THE GUI GUIDELINES "

This is one thing that most designers may take lightly, unintentionally or intentionally to make their app stand out. But this is a huge mistake. Let's not forget that these guidelines are created after much usability testing and research. It's not that one should not be innovative. But following guidelines is required to maintain consistency which in turn will prevent the user from feeling that he has been sent to Mars.

And in the end one more thing

"Design Dumb, Code Smart"

Here are some links to help you design better



Introducing FlexMailer

If you are a web developer, chances are that you may have written a PHP mail script, either for your own site or for your client. PHP is baked in with Apache, which makes it the most widely used scripting language. The success of Wordpress as CMS is largely because of ease of setup. It's no secret that wordpress is written in PHP.

All right coming back to php. PHP has a built in mail() function that enables websites to email data through the server, instead of the traditional mailto method. This has empowered web developers to include a mail form in their websites, which leads to better UX.
A php mail script usually looks like this

As you can see that for every field you add in HTML form it has to referenced in the PHP script. This is a tedious task to do and every time you work on a new form, you have to rewrite the whole script.
As a solution I have developed a script in jQuery/PHP which automates the entire tasks by automatically retrieving the names and their values. You can find FlexMailer here .

Below is a basic code that shows how you can customize FlexMailer.

Add this script to your HTML.(Load jQuery first)

Now in the mailer.php file
Find this line
and put in your email id.
Thats it you are good to go.
BTW, I am looking for collaborators to make FlexMailer better, if you're interested drop a comment below.
A question regarding FlexMailer script on StackOverflow

Saturday 6 April 2013

Spaghetti is tempting, but it's better to stay away from it

Before you start thinking that I am going to give you some advice on health, don't worry I am not.


As tempting it may seem, it's bad when you write it. I mean writing 'Spaghetti Code' is bad for your code, and bad for your health.

So what is spaghetti code?

Imagine, that you start working on some GUI app, you write the GUI code and the controller code together.
You are banging the keyboard and hacking the code together thinking "MAN, I m GONNA FINISH IT TONIGHT'  all your methods are working , all exceptions have been handled and you are ready to ship the app by next morning...



FEELING PROUD??

Well you should be... you shipped an app by hacking the View and Controller together. You wrote a ton of  "Spaghetti Code" and completed work in a few hours time, so why the Title?
 After a few months.....

Your issue tracker has some issues and you plan to sit down on the project to ship an update, feeling 'I AM GOING TO MAKE IT AWESOME AGAIN' you open up your IDE, open up the project and ....




You are bedazzled to see the spaghetti.....yes sir fast food is not good for health
Your code has no comments, since your controller and view are binded together reusing code is not an option, and debugging is *ahem* not easy, so what you do... you approach your codebuddy. He comes over willing to help, sees the code nearly faints your WTF's/Minute soar faster than yahoo's stock price during the dot-com bubble.Abandon the project or re-write the code.

So by now you might have understood why Spaghetti is harmful