Monday, May 09, 2011

Reusability and user experience

Reusability

Are you finding a phenomenon like use and throw with software applications?

Do you have anything about one time usability of applications? Often I get trickled about usability and reusability. An year back I was advised to emphasize more and more on usability and if at all I could build something reusable in it, it is just out of luck.

With rapid development frameworks and high fidelity needs designing anything for reuse is nothing but being stereotyped. There were times when reusability was discussed at every stage of development life cycle. Tools and technologies of those times asked for it. But we built runtime frameworks like Java, .Net etc. They are offering well tested reusable code for every possible computational need. Now what we are building is, nothing but application specific functional codebase. And there could only be a marginal scope  in it for reusable design. There is still scope but it is significantly low. That raises a question on what should be the strategy with respect to reusability in design. 

Another aspect is rapid prototyping,  dynamic languages, shorter delivery cycles, built-in user accepted mechanisms for application upgrades, well informed user, UX demanding networked systems. 

We are not building isolated apps like calculator and paint anymore. Even configuration, profiling and diagnostic tools are networked. 

And it is UX that matters at the end of the day. Now UX is a subject of taste for same need like hunger. It can't be same dish for breakfast, lunch and dinner. Then where is reusability in application development. Just like food need to be consumed while it remains fresh, app remains fresh for sometime only. 

With this background we need to adopt new strategies. It goes like software offers solutions for several problems surrounding human livelihood; but at the same it solves its own problems by looking at patterns of real world.

How does fabric design industry solve this problem. How does chefs solve and what entertainment industry does. And now the gadgets. 

Apps markets solved one side of this problem. Gone are the days where Microsoft builts one app to suit needs of whole world. Now there are several options for same need like calendar in markets. There is no one size fit for all. Yes there are some mostly downloaded apps. But there are several others too. Each one suits for someones taste. 

With markets gadget builders shielded themselves to great extent. Now they can concentrate on building just the platform. 

Now that leaves other side of the story up for discussion. What is in it for app developer with respect to reuasability.

1) Nurture multiple design options. Don't throw away anything just because it is not the best. More the time you spend time with need of the app the more you would meet expectations of broader userbase. 
Nurture multiple designs thinking that you are rich enough to build against each design. This is what fabric industry do.

Here you reuse understanding about characteristics of product for building against multiple designs rather reusing design.

2) Integrate services not userbase. Calendar app for world cup season is different from calendar app for competitive exams. Now you can build multiple views in same app. But building two distinct apps solves the problem in better way because the intended users are different even though program constructional aspects are same. Same story is told as book, documentary, movie etc..

3) Build reusable software just for multiple versions of same application than new application. Cost of building and maintaining reusable components is not economical anymore. As mentioned earlier there shouldn't be any hour spent specially to build a reusable component for next project. Moreover app development on different design is cheaper than maintenance. Most of the reusable stuff is used in enhancements than new development.  

4) Let users know the makers signature rather than technology. There is nothing called reusability of UX. It's called copyright violation. Tree controls are not looking like traditional tree controls, combo boxes are presented in so many ways where it's difficult to make it out as CB. So spend time to give facelist to your primitive controls for application specific look and feel. Your app should look like what it is meant for rather than Java app or winforms or wpf or PHP. You are not selling app to procurement manager or dealer. So there no one to  market your app. It should market for itself.

No comments: