So my manager, Martin, emailed me asking why the delayed startup application wasn't a bit more selective on what it opened.  I know why I excluded the .ini file but other than that, do I really care what a user puts in that folder?  Nope.  The startup folder doesn't.  If someone wants a word document to boot up or a batch script, who am I to say that is a bad idea?

But this question got me reflecting on a higher level of exactly why do I design applications like I do?  I think this is a result of a few things that have shifted from the past to where I am now.  Back in the day, I'd do whatever was cool, neat, or interesting and really didn't think about reusability.  I really don't think back then there was an instance when I needed to reuse code actually.

Move forward a bit, I entered the wonderful world of the internet.  This was my first venture into real user interaction.  HTML could only do so much and I could only do so much with graphics.  When I first started everything looked like it was either a terminal prompt or massive font-sizes and still butt-ugly.  Coding wise however, stuff started to become more refined.  I have two projects I have to deal with on code that is over 5 to 7 years old that I wrote.  Now the old folks that read this blog may go, pfff, that is nothing.  For me that puts me back in diapers.  Plus half the time I can't remember what I ate for dinner much less coded a few days ago.  The stuff I could do 3 years ago and now is night and day.  But the nice things is I can read that code and follow the logic a lot easier.  I know why I did certain things.  I named stuff properly.  You can also start seeing things go from 800 options to 30 options.  Easier to use for everyone, including me to code / update.

Crack the dial up even further, now I adopt a "Can my mom use it" philosophy.  I first used this with my Senior Capstone at DePaul University.  I've used it for a lot of other projects too.  People look at me weird when I said "this is total crap, my mom can't figure this out, who the hell knows what this icon means, where is the help text?"  Yes, the swearing was edited out but this is a real conversation I had.  But when designing an interface, does the user need 800 options or is that just a power user thing?  Go simple, make life easy.  My mom gets overloaded from too many opinions.  She expects a power button in the middle of a computer.    With that said, you must know your target audience for the application.  Too simple and stripped down and you'll have a revolt on your hands. 

API's in my opinion are the same way.  Giving me all the power in the world is really nice but at times can be harmful.  I'm just as guilty for doing 400 different params on my arguments or having them SO powerful and flexible that without a book, you can't figure out what is going on.  My solution to this is normally to actually write a wrapper object that is super simplistic and does the bare minimum of what is needed for this super complex object.

I think both User Interface designing and API designing have to follow a trait.  Know your audience, listen to them, and do what needs to be done.  This doesn't mean that you have to do everything they want unless it actually suits a purpose.  Person A's request may counter exactly what Person B wanted.  Who cares?  Well, Person A and B, but to be honest, not me.  I'll take both requests and listen to them but then I'm going to do my own thing and develop the product I want to do.  I got this bit of advice from a project manager (doesn't work at Microsoft) and I've taken it to heart more and more.

To recap

• Can my mom use it?
• Listen but you don't have to do everything someone asks
• If you need to have a complex object / interface, make an simple wrapper for it too