Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Tue, 08 Mar 2011 17:15:58 -0800 More Options to the User - Elements of Interface Design http://vijaykrishna.posterous.com/more-options-to-the-user-elements-of-interfac http://vijaykrishna.posterous.com/more-options-to-the-user-elements-of-interfac This was really a sub point in my earlier post which dealt with the basics of Interface Designing in general. But then a good friend of mine, who also happens to be a fantastic software test developer, asked me this and so i decided that i should elaborate on the point in a more details manner. Here is the excerpt out of that post which directly deals with this post:
Q. How much of a choice should one provide the user with? A. The answer is optimum. If you give very few choices and options, you are providing the user with a under functioning UI. If you give too many choices then the chances are that the UI is going to turn out to be very cutlery. Something you do not want. But, more than that, there is another peril lurking in the dark. Say you have provided your user with 5 buttons and only 5 chances to hit any button, then there are 5^5 ways in which he can use those buttons. Imagine what will happen in all those cases. Think of how will handle all of them and what will happen if one were to increase that number even by 1. Prioritize your functions just like your data and information. The priority of your information depends on your users, the priority of your buttons depends on your information.
Now, the question that was asked was quite simple: Is it a good idea to reduce the functionality you give to the user to make the application more User Friendly? Well I will have to say that the answer to that question is obviously no. Simply because, more the features the better is the application in terms of its feature set and hence, a happier user. Of course, it goes without saying that by increasing the feature set, you are making your application that much more unstable. You will actually require well written code and logic to substantiate it. So the issue is not really a user experience issue but a coding and software development problem. And many a times there will be situations where you cannot keep simple and straight forward UI's. The business will require you to complicate them. Sometimes, even if a simple alternative were viable with a more optimum number of features and choices, you would still be forced to come up with the same clustered UI simply because the client might be used to it, and may not want to change over to simpler and better things. Hence, at some point or the other there will be times when complicated coding, followed by a sophisticated bout of testing will have to be done. And that is the bad news. Having said that, here is the good news. The choices and features that we give to the user, need not always be interdependent. In case they are, then you have no other alternative but code and test out of your skins. But, if there is a way by which you can keep the interdependencies, at a minimum internally then life will get a lot simpler for you. In case the dependencies cannot be avoided, try minimizing them or concentrating them to a single interfacing point with in the code. For instance, most of such data dependencies can be taken up at two instance, such as the beginning, while the UI is loading, and while the user is exiting that view, i.e. at the end. So, you are creating a single data pathway, through which the data will enter and exit, at which point you will resolve all your dependencies. I will still say that it is best not to give the user too many options no matter much the usability improves, and improve it will. "Why" you ask? Simply because, once you walk down that path things will only keep getting more complicated for the coder, and more enjoyable for the user. And there will come a time when the system will get too unstable to manage and maintain and the user will be in love with such systems due to its usability but will frown when the bugs come crawling out. I have really painted an ugly picture here, by giving a worst case scenario. In most projects as far as possible, systems are made simpler and better than their predecessors. Even the end users are willing to accept new ways of doing things. It is at such moments that we should make the best efforts to simplify things.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Sun, 16 Jan 2011 18:10:00 -0800 Interface Inheritance http://vijaykrishna.posterous.com/interface-inheritance http://vijaykrishna.posterous.com/interface-inheritance

This friend of mine, pings me and asks my something about UML diagrams. Well, i answer his doubts and then i ask him what he was designing. That is when he tells me something i never thought of. What he told me, gave me a new insight to OOP and the fact that more the options you give to our friendly users for whom we are trying to build such brilliant technology, the more they will get confused by trying out and seriously using a gamut of all possible permutations of those options. In this case, the user is us, i.e Developers, Coders the whole class. Speaking of which, my friend told me about the most unique design pattern ever. He told me about a hierarchy of interfaces. "WHOOHA!!! Hold on!", i told my self, and tried to understand the concept, more like digest it, due to the conflict, then and slightly even now, raging in my head. He was talking about a hierarchy of interfaces wherein there was one IBaseInterface and its IChildInterface 1,2,3... and so on. This is was nothing but the inheritance of interfaces and there in lies the conflict of ideas. Interface as far as i am concerned was the perfect tool to overcome the issues with inheritance and embrace true code re-usability and freedom. Inheritance made the code rigid and tightly coupled to the parent classes. You could never quite do what you wanted to freely once you defined the object structure. It was painful. And then there were interfaces which only told you what to do. Not how to do them. The code became neater, it was fun. And then, some intelligent people mixed it. Now, lets take a step back. Inheritance all said and done did reduce a lot of our coding. If you had the correct design sense you could do wonders with the concept in designing powerful and flexible applications. But then, it things would get difficult with the client demands changed took the whole pendulum swing. Ahhhgrrrrrr!!! But, it did help a lot, there is no doubt about that. A lot of its issues were solved by interfaces. And as i kept using them more, i kept using inheritance lesser and lesser. But here i am wondering, as i always have been, why not have the best of both worlds. If you are a master designer and you can handle inheritance well, (and some things to be honest are better off done using that) why not use it! Interface Inheritance, gives you just that. The best of both worlds. Mind you you are still free to come up with different implementations for all those interfaces in the hierarchy. But you just have to remember that the Derived Interfaces also hold an implied contract of the Base/Master Interface. But the Beauty still lies in the fact that you can have multiple implementations, for all of them, and still keep them in a hierarchy. A common and valid argument i found against this approach was not use such hierarchies and simply implement all the required interfaces instead of inheriting one interface to another and implementing only the second one. While this is a valid argument, the prerogative of the design lies with the designers and the developers. You just need to keep one simple thing in mind while implementing such designs: there are implied contracts that need to be implemented and taken care of. Deal with that, and you have a very powerful tool in your hand.

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu