Technicolor again

Its been a while, was caught up again with life’s little surprises, got to make bouncing back a habit. Duh!

Well… talking about my latest crush ‘Expression Blend‘, I am so awed with the possibilities it presents. Just completed my first Silverlight prototype today. Boss is happy so am I. Back in my technicolor life Rainbow digging on design I found this article Why Design matters? happy reading!

Back from Office museum!

‘Simply amazing’ is what happened… I did not understand anything at first except that it was about Microsoft Office, but its OMG!, only when I zoomed out did I understand a little of what Office is all about, and how it evolved. Does it require to be clever or is it just being simple straightforward? User Experience is my passion…’users are emotional about software’ I do not doubt a bit. ‘Human Interface design is one part art and one part science’…well said Jensen. Did someone just say ‘design’?

The Story of the Ribbon

And now what? Office 2010 is here!…

umm…yeah…I will have a few sleepless nights over this…


Why the world is the way it is?

These pathways/slices are separated by millons of years of human evolution, they deserve some attention… don’t they?
Okay, so here is the (s)tool ..
  1. Whoever best describes the problem…is the one most likely to solve it.
  2. We can’t solve a problem that overwhelms us. We need to break it down into bite-sized pieces.Pizza
  3. The more “human” your picture, the more human the response.
Thanks Dan for this wonderful presentation
That’s my lesson for today…


Today’s lesson…
Microformats are “Designed for humans first and machines second, they are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns”
Microformats follow few basic principles
  • Solve a specific problem
  • Start as simple as possible
  • Design for humans first, machines second
  • Reuse building blocks from widely adopted standards
  • Modularity / embeddability
  • Enable and encourage decentralized development, content, services
Reduce, Reuse & Recycle!
Oomph – The new playground for Microformats . Oomph is a Microformats toolkit for web designers, developers and users. Its is an amalgamation of applications: an Internet Explorer Add-in built in C++ that finds Microformats on a page; a cross-browser HTML overlay built using JQuery that aggregates Microformats; a set of beautiful CSS styles for Microformats; and a Windows Live Writer plug-in written in WinForms for inserting hCards.
Oomph can be downloaded from Codeplex . So, ready to Oomph?



Like love, great design requires no explanation

For any software, design is crucial to its existence. In this changing era where we find more people tied to desktop computer screen & PDAs than in the park, its time to re-design the experience. The location of visual elements in the UI has a huge impact on how the user interprets information. The closer it is to the user’s thought process, the better experience the user will have. The interface should be intutive. It is always good to expose or display only what is required, and refrain from showing all of the software literature on the user interface. A good design communicates by itself. That’s how its related to human nature, it communicates.
Those who design software are people and those who use software are people; let’s explore the homosapien mind.
I don’t need to know the laws of thermodynamics to use a toaster, or do I?
So next time you design a software, swim in the homosapien mind for a while!

The 209 Becauses

Back again, I just can’t budge… it all depends on how well we understand the requirements. Do not slip into an analysis paralysis mode but make sure you know what you are doing. Nick has provided an exhaustive list which I call ‘The 209 Becauses’. I still need to ram them down my concious, they are worth ramming after all. To start with they are arranged into 5 levels; I figured out there are 3 Level 1’s ->for the Business Stakeholders, Business Analysts & Software developers respectively, 14 Level 2’s, 51 Level 3’s, 93 Level 4’s and 48 Level 5’s.
Did I hear what’s the Problem?
Problem: The requirements for software, as delivered by typical business analysts, is not sufficiently clear, insightful, or well understood to develop software systems that meet the needs of business users.
got to get over it!

Think Aloud Protocol

Think Aloud Protocol (TAP) – Developed by Clayton Lewis, is a Software testing protocol where the user is allowed to talk or express his/her experience while performing a set of specified tasks. They are asked to say whatever they are looking at, thinking, doing, and feeling as they go about their task. Appears interesting to me, food for thought!  After all usability is what drives software success.
TAP @ wikipedia
Task-Centered User Interface Design (pdf) is a book with a ‘cool’ crucial warning …
“We’ve designed this book to be most useful for people who are actually developing user interfaces. That’s in contrast to the full-time interface professionals who do research and evaluation in large corporations. We strongly believe that effective interactive systems require a commitment and an understanding throughout the entire development process. It just won’t work to build a complete system and then, in the final stages of development, spread the interface over it like peanut butter.”
That was my lesson of the day!

A Metaphor a day, keeps me on my toes

Metaphors or visuals to describe the application is a very powerful technique to avoid catastrophes in software development life cycle. Use as many metaphors as possible so that everyone on the project is aware of the concept, the main intent, the ‘ask’. I myself have used images where I was not able to explain in words or where there was less clarity on the requirement, so I drew it, and asked the customer “Is this what you are looking for? the answer was “yeah, but slight changes here and there”, and there you go. You now know the expectations and better clarity on requirements; you know the entities, rules, interactions, interfaces and flows. Probe the customer, and you’ll realize it was so easy and the soon you will be taking snaps smiling with your customer.
Its surpising to know how easy and efficient the process becomes when the intent is clear, so lets first figure out what is the ‘ask’, and provide a solution for that ‘ask’ and just not provide any solution that we know of.
I love metaphors
a==b==c implies a==c, though a bit of logic needs to be in there.

Trying to change something? Its fun, its a challenge.

I face challenges at workplace trying to bring change, but I realized the trick is communication – communicate, communicate, communicate. If your idea for change is not feasible or just impossible, you’ll instantly know from your feedback mechanism. I get an idea and I feel as if sitting on a pin; they click, I yak it – feasible? accepeted, now lets work on it  – naah?  move on … there comes another idea! Thomas A. Edison said “To have a great idea, have a lot of them”. I wonder why we hold ourselves back when there are so many opportunities out there to-improve to-innovate to-demonstrate to-renovate. Don’t worry about people stealing your ideas. If your ideas are any good, you’ll have to ram them down people’s throats.
So, communicate its better being a fool for five minutes instead of being a fool forever.
That was a communication lesson for a change.
Change is hard and the rewards are worthwhile. What better way do we have to spend our lives?  —Ken Schwaber

Requirements are the Software

What does it really take to convert requirements into working software? I think the trick is getting the requirements right; if you do not understand the requirements, no matter what skill/technology you master, your effort goes to trash. The best way is asking for clarifications and getting a clear picture of what the user or customer really wants the software to do!, do not say ‘yes/ok’ to everything without really understanding. Sometimes this can test your patience but you should at all costs know what the requirements are. The customer asks for apple and you give him oranges, do you still expect him to come back to you?
Always make sure you:-
  • Get the requirements right (not the right requirements!) thats called customer facing.
  • Design for ‘the given’ requirements. Create a Model.
  • Code for ‘the’ design.
  • Test the code ‘within the’ system.
  • And take responsibility for your code!
Remember that quality has to be caused not controlled!
Here are 3 golden questions in software development that should tinkle in our heads all the time, it does in my head for sure :-
  1. Why are we buiding this software?
  2. What should this software do?
  3. How do we develop it?