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
Fri, 04 Mar 2011 18:25:54 -0800 Featured People - Facebook http://vijaykrishna.posterous.com/featured-people-facebook http://vijaykrishna.posterous.com/featured-people-facebook In the current UI of Facebook if you want to add a relationship you really have to do a little bit of a treasure hunt. That is unless you know exactly where it is. You have to go to Profile>Edit Profile (a grey colored button right below the Home-Profile-Account tab strip)>Featured People. There are issues with this whole mechanism. And this is just one of those things that does not make Facebook's UI "idiot proof". For starters let me point out that the section Featured People does not strike, to most people, as the place where you would manage relationships. Then the whole ordeal of getting there in the first place is difficult. Now for an important feature, such as relationships, this should have been given top access. Now i understand what Facebook has done. It has tried to give the best access and usability to its most used features such as the wall and the News Feeds. It is brilliantly done. And for most people, setting relationships is not on a high priority in their TODO list when they are on Facebook. While all this is done and done well, the team at FB seems to have lost the bigger picture. It has never been able to make the UI very idiot proof. A new user will be lost and the Featured People example was one of the more basic ones. Taking a more sensitive approach, the designers at FB should have come up with a different name rather than, Featured People. Most of my friends on FB, like to keep such information, namely their relationships and family members, away from the public eye, while wanting to establish it in a private manner. Which i think is fair. So, in a very basic sense of the word, "Feature" is not the right way to put it. You never want to feature your lovers or family members. Would you? Today a colleague literally yelled at me for the same thing, while we were debating about it. I could not get his point at first. But the more i thought about it, the more i realized that all my family was under this section called Featured People. I did not particularly enjoy the feeling  i got after that realization. Apart from the name, why is all this in a different tab/section all together, at least the relationship and family bit? Should it not be a part of your basic information? Even if you think that it should not be so (and i will agree with you there), can it not be under a different tab called Family? Why can it not be that simple? As a defense FB will say that you can not only add your Relationship status and Family Members under the tab of Featured People, but you can also add a custom list of friends or groups. This i found after a thorough combing of the whole UI. So when you look at it like that, "YES", it makes sense. But then again, why can't there be a different section for such lists and groups. At a very fundamental level, i would not like to put such groups and my family together, period. Now all that was the sentimental part of the debate. Let me get down to the usability of something as important as relationships. If you go along the same bandwagon as FB has today with featured people, you realize that your friend's list should have the family list as well. Whats more, it should also have a separate link which shows your relationship, in case you have filled it up. While it does not do the relationship bit (thats the first deficiency), it does give you a list of your family. But to get to the whole list of your friends you need at the least two clicks, the first one is required to take you to your profile page. That is very strange. It is a social networking site. To not give a single click access to your entire friend's list is gross foolishness. FB is a fantastic networking tool with its feeds, updates and likes. But it can never be a true social networking site until it gives people and relationships a higher priority. Right now, it is just giving their latest doings that extra importance.

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
Mon, 28 Feb 2011 17:54:33 -0800 Pages, Views and Popups - Data Flows http://vijaykrishna.posterous.com/pages-views-and-popups-data-flows http://vijaykrishna.posterous.com/pages-views-and-popups-data-flows I think i have written a few posts on popups and the issues with layer development before. Today, I was encountered with another classical situation involving Pages, views and pop-ups. And for a change i was invited to be a part of the debate. The scenario was as follows: We had a page, which was in all essence a master page dealing with the background service. This page fundamentally had a tab control with every tab's container having its own control. Now each of these controls led out to one or more popups (again effectively more controls). The issue was to treat the controls as controls and try to relinquish them of all Svc calls. Mind you at this stage no calls were being made from any of the controls but we just wanted to come up with a solution where in we could once and for all decide a standard protocol by which we could completely avert situations involving svc calls being made from the controls. After a good length of discussion we got to the following structure: Svc <> Page <> View Mode control <> Edit Mode Popup The idea was to manage data flows in this simple scheme of things. After some more nut cracking we came down to the following 2 alternatives: A) Svc <> Page <> View Mode control <> Edit Mode Popup This basically suggests that the data coming in to the page from the Svc should be passed on to the page as it is, the page to the View Mode, and the View Mode to the Edit mode and similarly all the way back. Fundamentally, each entity will interact only with the one in front of it and the one behind it. That is, the page will never interact with the Edit pop up directly, the View mode will never interact with the Svc, ie make Svc calls. B) Svc <> Page <> {View Mode control, Edit Mode Popup} In this arrangement, the Page can now interact directly with the View and Edit controls. That is the only difference between this and the previous arrangement. Now for anyone to understand the implications of either arrangements, i need to highlight the interactions between a control and the page. The control will have all the buttons to actually perform operations by the user. But they will not be any Svc calls emerging directly from the control itself. On a button click, the control will raise a Button_click event which will be handled in the page by the required Svc call. It may seem complex, but if you have read my previous posts, which i mentioned earlier in this post, then you will realise that with such an arrangement you have actually decoupled a UI fragment from the data processing unit (the page) and data supplier (the svc). With that, you can actually use the same control in a similar context with a different svc and processing unit, giving similar data. Similar interactions will exist between any two controls as well. Now with that out of our way, let me get to the point. In arrangement A, the work is distributed across the entities. There isn't a lot of control resting in one place. A fair amount of modularity will be introduced with that approach. And hence the over all code will be neat and clean. But if a change is required it will have to be done at multiple locations. While in arrangement B, with the page interacting with both the View and Edit controls, the Page will end up managing a lot of Events that will get raised by double the number of controls as compared to that in A (assuming that each View Control has an Edit control). This will localize the code, resulting in the reciprocal of arrangement A. The code will be difficult to manage with so much happening in one place, and hence the code can get ugly. Mind you with effective code management this can be resolved. But at the same time, if there is an error or change in the way the data is processed, there will only be one place where all the changes will have to be made. Which will anyone pick is a matter of great debate and discussion. The correct answer depends entirely on the situation at hand. I picked one of them based on the existing code structure, so that is an important parameter while making such decisions. And for those who will suggest that should merge the View and Edit modes: solve the problem, don't change the requirements.

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
Wed, 26 Jan 2011 17:48:10 -0800 Developing in Layers http://vijaykrishna.posterous.com/developing-in-layers http://vijaykrishna.posterous.com/developing-in-layers For a long time i have been using a scheme of things in developing UIs which has started to bug me, literally in every sense of the word. What i do is this: For any page/view, i create the control, which in essence is a form or a configuration controller. Now, this control is independent from everything else, and i can use it as i deem fit. It has its own set of hooks using which i can feed and retrieve information from it. Mind you, these controls are very specific to the application itself and do not form a very integral part of a generic sdk. So, the freedom i get with these controls is absolute flexibility. I can place them in a page, a view, a pop up or a sidebar. But the only issue is that i have to play with some ground rules. Just one ground rule actually: I cannot make service calls from any of these controls. Like i discussed this in a previous post of mine in detail, doing so makes the control tightly bound with the service or the backend, hence limiting its usability in another part of the application. While this gives me a lot of freedom of where and how i want my UI to appear and look it gives me hell when i sit down to develop most of my app. The scenario is thus: I have a page which acts as an empty shell. It has nothing in it at the beginning, barring a label which designates its purpose in the near future. Hence i create an empty shell. Then i make my control which i can fit/embed anywhere in the page. Its like playing with building blocks after a point. While i have that flexibility i cannot deal with the hell of maintaining the code base when i have to handle a Pop up inside a Page which is arrived at from another Page and all these Pages and Pop-ups are tightly coupled with each other in terms of the information they show right down to the last Label, and mind you all these Pops and Pages have their own controls. Hence assuming every view has an empty shell (read popup/page), and each of these shells has a minimum of one control, i have to manage around 2xN modules of code for N views, with each Module having a Markup File and a Code Behind making it 2x2xN. FOUR TIMES the number of Views i have in my application. Why would i do it you ask? I would do it simply because the shell itself seems to change. One day the control looks better in a page. Another day God comes down to earth and advices to place it in a Pop up. And then all of a sudden tooth fairy throws a tantrum saying that she wants it in the bloody Side Bar. I curse each and every day when i lost a tooth. Earlier it was due to the pain of it. Today it is because of tooth fairy's tantrums. And the contents of the last few lines are a blunt and candid indicator of how deranged i have become with the code and its maintainability. The Solution: Call me if you have one. The Lesson: I can not reiterate this enough in my blog posts, but for heavens' and sanity's sakes, plan and think through the UI before developing it.

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
Mon, 24 Jan 2011 17:25:02 -0800 Overlaying UI Controls/Elements http://vijaykrishna.posterous.com/overlaying-ui-controlselements http://vijaykrishna.posterous.com/overlaying-ui-controlselements The overlaying of UI Elements or controls is something all UI Developers and Designers do. While it may be pretty useful, it can bring a lot of questions on efficiency, ease of code and logic. So, lets get down to basics: Why have overlaying or overlapping controls? Well, for one, i have been using it a lot for variable functionality. It basically means making your UI possess a different set of UI elements or controls altogether, offering radically different functionalities in varying scenarios. One in specific is having a ComboBox (drop down menu) on top of a Read-only Textbox. This can be used in a form to great effects. While the user is entering a new Form, there might be a predefined selected set of values which he might have to select from for a given field in the form. But, after saving it once, the selection should no longer be accessible and the value of the field should be permanent for the entire lifetime of the form. To do something as simple as this, we firstly create two different UI elements. Then to manage which appears when, we set up flags or conditions and toggle their visibility. And finally, we manage the communication between these two controls. So let us see the pros and cons of this approach. Pros: 1. It is an obvious logic. 2. With care can be implemented flawlessly, so to say. Cons: 1. Since, quite often you only manage the visibility of the controls, you end up loading two controls where one should suffice, making the UI more bulky. However, this can be negated if the controls are dynamically created. But, this increases back end code and the conditional logic, which decides which control should appear, has to be all the more fail-proof. As, if the logic goes wrong at any point, you have not created that control and the code that is dependent on that control will then start throwing errors, and you will probably take time to track down the root of the issue. 2. If the logic behind the visibility conditions is complex, then there is every chance that the code will fail, time and over again. 3. You have to write more code come what may. You either have to write extra code in the UI markup where you have to define the control. Or like i pointed out in Con 1, you have to make the code behind bulky. 4. The data communication between the two controls, which i refer to as synchronization has to be good at all times. It simply must not fail. The chances of which are very high. So the big and small of all this is that, you have to write more code, which is definitely not localized, which increase of the probability of bugs and make their (read bugs) detection slightly tedious, all this subject to the complexity of the conditional logic and the data to be synchronized. Why go through all this. And mind you this was a very specific and simple case, where you are dealing with two very basic controls: the ComboBox and the TextBox and two very basic data structures: the List of Strings and String. Imagine if things were to get complicated, like they normally do. So what are the possible solutions you ask? Let me draw out a few and let me try and generalize them to a set of similar scenarios. 1. Simple Solution: Keep both controls visible, do not overlap them. This way at least you do not have to manage their visibilities or dynamic creations and that is one thing less to be managed in your conditional logic. 2. Simpler Solution: Redesign the ComboBox so that it acts as a TextBox as per your control logic. One way of doing this is disabling its drop-down after the 1st save. Another method is to populate the combobox's drop down with only one item, i.e. the one that was selected in the form's 1st iteration. This way, you have eliminated the  need for an extra control. There is no need to carry out data sync as there is only one control. The amount of things depending on the control logic has reduced drastically. Overall you are looking at a drastic code reduction and refactor. 3. Difficult and Context-based Solution: Design your UI in a manner which does not invite such situations. Now, that you know such cases can drop up in a UI, spend some time in designing the UI well, before hand. And this is what needs to go into core UI designing. Not the looks necessarily. The usability, the implementation, the functionality. Hence, the big and small is to either keep both the control which eliminate the tough and critical task of managing their visibility or creation+destruction. And to eliminated Data Sync which is another critical task. You should in essence try and make the Data and till an extent Control Visibility, independent of the conditional logic. If not that, keep the dependency to a minimum as they are critical for the UI, simple. There are other cases as well. Such as, toggling between icons, one says List View and the other says Tile View. Keep both icons, what is the harm? Another case is to overlap a password box on top of a regular text box with a check-box which say "show". One stores the password in plain-text and is invisible if the check box is not checked, while the other keeps in the star or dotted fashion and is visible by default. This enables the user to see what he is typing, by simply checking the check-box. Why have it? Make him retype the password. Hiding context menus items, when they are not required on a page for a particular context. Disable them. There are 5 other simpler methods of doing things for a given task. Pick one, they do not look that bad. Simplicity is a virtue.

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
Wed, 05 Jan 2011 17:53:31 -0800 Silverlight Grid for Dummies http://vijaykrishna.posterous.com/silverlight-grid-for-dummies http://vijaykrishna.posterous.com/silverlight-grid-for-dummies Being a UI designer is not enough. You should be able to render those designs somewhere. Well, i have started my journey as a UI developer and designer in the world of Silverlight. It is a fantastic framework of tools and technology. The best part being that it uses common languages like XML and C#. Well anyhow, i have been working with it for a little over two months now and i have finally recognized its most important control, the <Grid />.So i am going to give a bit of a Silverlight <Grid/> for Dummies. Introduction: To start with lets look at what the Grid has to offer. The Grid is a basic control which is used everywhere to set up the layout of your UI page, window, space, etc. You can define the rows and columns, thus forming cells, whose heights and widths are very customizable and flexible to adjust. It is within these cells that we place all our controls. Hence it is like a Sectional Map to a UI. Now, most of this can be done in the Extensible Application Markup Language or XAML, although i love to get dirty with the code behind and take the pain of defining everything there. This approach might be painstaking and you might even consider me crazy for doing after you realize how difficult it is with C# and how blissful it is with XAML. By the way, stick to the XAML, i use C# to irritate my friends at times ;) . Basics: 0. <Grid/> or <Grid></Grid> This is the Empty Grid or a Single Cell Grid with nothing in it. 1. <Grid.RowDefinitions/> and <Grid.ColumnDefinitions/> These are probably the first things you will write within a Grid element. These tags are used to define the Row and Columns of a Grid. However, note that these are not entirely important. They can be omitted, as every grid by default has one cell. So if you were to add anything within that cell it would just act like a container for the controls or UI elements. Using the Row and Column definitions can be useful as it gives you complete control over your UI Map. You can actually dedicate one cell for each UI element and then all the margin adjustments for that UI control will be based with respect to the boundaries of that grid. 2. <RowDefinition/> and <ColumnDefinition/> These are used inside the <Grid.RowDefinitions/> and <Grid.ColumnDefinitions/> Tags respectively. They are used to define individual Rows and Columns. To get a better understanding of the whole thing have a look at the following code:
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="50"></RowDefinition>
<RowDefinition Height="50"></RowDefinition>
<RowDefinition Height="*"></RowDefinition>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100"></ColumnDefinition>
<ColumnDefinition Width="100"></ColumnDefinition>
<ColumnDefinition Width="*"></ColumnDefinition>
<ColumnDefinition Width="50"></ColumnDefinition>
</Grid.ColumnDefinitions>
</Grid>
Notice how the Widths are set in the ColumnDefinition's and Height is set inside the RowDefinition's. You cannot do things the other way round, simply because it does not make sense.
3. Gird.Row, Gird.RowSpan, Gird.Column, Gird.ColumnSpan

Now that you have defined the Row and Column Definitions its time to use it. All the Row and Column definitions inside the <Grid.RowDefinitions/> and <Grid.ColumnDefinitions/> Tags are maintained as zero indexed Collections or Lists. Thus the 1st Row can be referenced by saying Grid.Row = "0" and so on (similarly for Columns).
So lets fill it up:
<Grid x:Name="grdLayoutRoot" Background="White" Width="400" Height="300" ShowGridLines="True">
<Grid.RowDefinitions>
<RowDefinition Height="50"></RowDefinition>
<RowDefinition Height="50"></RowDefinition>
<RowDefinition Height="*"></RowDefinition>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100"></ColumnDefinition>
<ColumnDefinition Width="100"></ColumnDefinition>
<ColumnDefinition Width="*"></ColumnDefinition>
<ColumnDefinition Width="50"></ColumnDefinition>
</Grid.ColumnDefinitions>
<Button x:Name="btnTest" Width="50" Height="30" Content="Text"Grid.Row="0" Grid.Column="0"></Button>
<Rectangle x:Name="rectBlue" Width="50" Height="30" Fill="Blue"Grid.Row="2" Grid.Column="1"></Rectangle>
</Grid>
In this example, i have given the Grid a name or a unique identifier using which you can access its inner controls, in this case the Button and the Rectangle, which have their own names. I have also given the Grid a background (you can do better than white though), a static height and width. An interesting property happens to be the ShowGridLines which you can set to true or false. Setting it to true will mark the Grid lines for better understandability only. Simply because they do not look pretty, unless ofcourse you want to use Grid lines such as those. Here is an example:
[caption id="attachment_58" align="aligncenter" width="404" caption="Grid with the Grid Lines"]
Media_httpvpalepufile_shcfz
[/caption]
Apart from setting the Grid.Row and Grid.Column, you can also set the Grid.RowSpan and Grid.ColumnSpan Properties. Setting these values allows any control to go beyond its established grid boundary.
4. The Auto and *
Now, most of the lengths that you let for Heights and Widths of a Grid Row and Column is in pixels, always. And to the best of my knowledge you cannot not use any other unit of measurement. Apart from that you can use the Auto and * which behave in the following manner:
a. Setting the Height to Auto will adjust the Grid Row to the height of a control with the maximum height in that Row.
b. Setting the Height to * will make the Grid Row take up the Remaining height within the Grid apart from that taken up by the fixed & auto sized rows.
c. Setting all the Heights to * for a set of rew definitions will ensure that the rows are given equal Heights from that which is remaining after the fixed and auto sized grids have be assigned spaces or heights.
Same is the case for a Column and its Width.

Conclusion:

These were just the basics of the Grid control but the most important and elementary chunks when it comes to developing UI in Silverlight. Do remind me if i have missed any points which can be added here, that you come across. I have only covered the basics and will deal with the other features and uses in another post. I do hope that this helped you a little.

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
Mon, 03 Jan 2011 17:42:41 -0800 A UI FAQ http://vijaykrishna.posterous.com/a-ui-faq http://vijaykrishna.posterous.com/a-ui-faq At the very outset of this post i would like to state something explicitly: I am a newbie in the world of User Interfaces and User Experience. However, i have been playing around with colours and graphics for the past 6 years now. And i have designed graphics and pondered over user experience when it has come to print media. So, if you think that i even qualify to write something like this, go ahead give it a shot, i will try not to disappoint you. The reason i have decided to put this down in simple word is because many of my friends have asked me these questions before. While i will not give you the ultimate answers, i will try and give you a direction, based on my own experiences and opinion. So here it goes - Q. What are the Rules or Axioms to be followed while designing a good User Interface? A. There is only one simple rule or axiom i can think of when it comes to designing a good interface: UNIFORMITY. Any user will like things to be constant and consistent with each other. The moment you do something out of the ordinary the user's attention is drawn to that one thing. He simply gets disturbed. Its easy to spot flaws, simply because they are out of place. So, keep things simple and uniform. Get those distances between your Labels and Textboxes to be constant across the application. If it is 10px between the labels and textboxes on one page, ensure that it is 10px on every page in the application. The user can spot these things with surprising effortlessness. This causes him to think about, such seemingly minor glitches, and not on the functionality of the application. Think of it like a page in a book, jutting out slightly, just by a millimeter. Its very easy to spot it right? And no matter how hard you try, you aimlessly think of it for a few nano seconds before you get back to the reality of studying the whole thing. Maintain consistent alignments of text. If the numbers are right aligned at one place they should be so in most pages. You can make exceptions when you are designing forms or pop ups. Labels is another area where you should take care of alignment. Its a good idea to have right aligned  labels, allowing you to have constant distance between the labels and the text/data fields that they are representing. It is also to have a Justified alignment against when it comes to blocks of text, it gives you a clean look. Stick to a Maximum of 5 primary colours and 2 simple readable fonts. Now the colours throughout your application can actually be shades of those 5 colours. But, do not push it. You are not designing a poster. You are trying to convey information. Keep that in mind. Here the more important thing is to convey information not make you UI look really vibrant (unless, that is the purpose of your UI). In my opinion, two fonts are more than enough. The bold text brings more magic to user experience, than do animated text or ever changing fonts. They are simply irritating. Q. What is that "Perfect Design"? A. Truth is that even i am searching for that very thing. But, in my opinion, a design is truly perfect when it can be used in any scenario, with any given context. Something that is very adaptable to changing need and requirements. Now, i say this from the code point of view. The code written to develop a good UI should be such that it can be used again, in any other development process. Having said that, i think that when thinking of a good design, one should think of how and where that design can be used apart from its original place or purpose. This in my opinion is the best way to maintain uniformity as well. A simple example of this happens to be the auto-complete box. Now, whosoever thought of this simple design was a person with a vision. It has just replaced the textbox completely. You see it everywhere. In your Web Browsers, Search Engines, Forms, Facebook, Operating Systems, the list is endless. Now, that is a perfect design. Q. Eye Catching or Subtle? A. This is something that the theme of your application should decide. But remember, that it is the information that you are trying to present which has to catch the eye. Try avoiding contrasts like, white text on black backgrounds. While some themes may demand something like that, it is best to avoid them. You would be surprised how much better Black or Gray looks on White. It is really a matter of personal taste and choice. Stick with what you think is the best. But, i would add this: Any good interface has something subtle or mild about about it. No matter how flamboyant, your UI may look, try keeping certain subtlety in it, unless it goes against the nature of your theme or application. 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. Q. How do we get a 3rd opinion, while designing a UI? Especially from someone who knows nothing about the system. A. Now if you can find such a person, who can intelligently answer all your doubts and queries, give you an honest opinion and not spill your beens about your project to another soul in this world, then you are a luck guy and you should use such a person with no hassle. Usually, i ask my mom and dad to give me an honest opinion. They being from a generation which has not used the computer all that much present a true picture of what my UI lacks to offer a lay person. However, the best thing to do is to put your self in that persons shoes, your users shoes and try and analyze what  he would want. The best writer is he who does not like to read, for he knows the amount of effort his reader will have to put in to read his words. So, he will make a good attempt at reaching out to his audience in the best possible manner. Designing a UI is no different. Be critical about your work. Reduce the number of clicks. Increase the amount of information not data. So that was a basic FAQ. In case any one has more troubles and issues, comment here or mail, IM, FB  or Tweet me, i will be more than bappy to help out.

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
Sat, 01 Jan 2011 16:58:41 -0800 Elements of Interface Design 2 http://vijaykrishna.posterous.com/elements-of-interface-design-2 http://vijaykrishna.posterous.com/elements-of-interface-design-2 The prequel of this post was termed Elements of Design. It was really a feeble attempt at trying to explore the various factors of Usability in any User Interface.  I am going to continue in those lines. I am going to talk about the relation between the back-end or the service layer of any system and the system's final User Interface. In particular i am going to explore the the interdependencies between the two. It is a common notion to design the architecture/databases of your system according to what you feel you want to show. This is often taken to the point where developers develop the architecture from the UI perspective. It is a sad misconception that many young, budding software engineers have, i know i did. It is sadder still that many go about building systems the other way round. That is, building UIs from the service perspective. "Everything in the Service or the database will be shown in the UI" Now, i think that it is a wrong way of doing things. Frankly, both the UI and the service should be independent of each other, with a very minimal and flexible points of interfacing. While, it is a natural notion to show all the data being supplied to you, you really do not have to. Good, interfaces are those which do not allow its users to search for results. Remember, Information above Data. Blind dumping of data, that being received from a service or database, implies one of the two things: a) Your service architecture is so good that it only returns all the relevant results, thereby automatically doing half the job for you in terms of making a good interface. b) Or, makes your UI designing job all the more difficult and tedious for a plethora of reasons i can think of right now: Too much data; Too little data; Irrelevant Data being returned by the service. Hence, by following the above stated approach (the line in quotes and italics), we have the following results: Good Service/Back-end, returning relevant data => Good UI, Service/Back-end, returning less data => UI with less information hence less value, Service/Back-end, returning more than required data => Cluttered UI, etc. All in all, the development, maintaining and purpose of the UI is too dependent on the Service/Back-end. This also leads to one other major problem: The UI will have to be changed as and when the service changes. And if that happens too often, then a ever changing UI might not be the best thing for a user, who will have to keep figuring out where the "Save" button is which was there till tomorrow. I am not suggesting an absolute decoupling. That is being crazy. I am however hinting at maintaining freedom at both levels. Let me ask you something: Does any Google API ask  you before hand the kind of tool/widget you want to develop? It just gives this brilliant set of calls and methods which can generate a whole gamut ideas in your head about the kind of tools you want to make the features that they will have. An artist comes out with the best piece of art, given a greater choice of colours and equipment. He may not use all the colours and equipment. At times he will use all the seven colors of a rainbow with an array of brushes to create a masterpiece. And at times he will just use a simple pencil to create a greater work of art in the form of a beautiful sketch. The point is that the artist needs the freedom of thought to play with things and to make his own choice. Similarly, the UI designer needs an architecture and a data pool, which he can play with. He needs that freedom. In essence, the system and architecture designer should not keep in mind the UI or how the data can be shown to the world. No! His job is to provide all the data and functionality in the world, which he can possibly think of, in a very distributed and atomic manner. His job in short is to think of everything in that domain of business or work, for which the software is being built. He has to go beyond the myopia of what is required upfront. He has to preempt and build a system that will last a decade's worth of requirements from the moment he declares it complete. When the service or back-end has such depth and power, the UI developer/designer will have all the freedom in the world to work. He will then be in a position to create something seemingly simple and brilliant.

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
Sat, 18 Dec 2010 10:14:19 -0800 Elements of Design http://vijaykrishna.posterous.com/elements-of-design http://vijaykrishna.posterous.com/elements-of-design Well, now i know what it means to be busy at work. It has been a tormenting two week period to say the least. And, thankfully, (touch wood!!) I have been enjoying it. It has been a period of great exposure and learning to put it in a sentence. I have been picking up on Silverlight well, so far and look to doing so in the future. But, as usual, the real challenge has not been the technology, but the ideas, the innovations and the concepts that i have had to develop. Working as a part of an Interface Design team in a software firm is challenging. While a lot of credit goes to the platform team or dev team working on the engine, I have come to realize that it is the User Interface that people get to see and use at the end of the day. It is the logical conclusion to any platform or logic engine in the world, Period! As a part of the UI team we have to take care of a few things or aspects of design and development of a product:
  1. Usability
  2. Looks
  3. Speed/Performance
They are equally important and none can be ignored for another. Having said that, Usability of an interface can influence, or at least direct, its Looks and Performance. Now, I have identified two very basic parameters in evaluating Usability: Clicks and Data. Clicks basically refers to the amount of Mouse/Keyboard clicks a user has to make in order to get a task done using an interface. Data refers to the amount of content the user has access to at any given point of time. Now, it is quite evident that for great usability the Clicks and Data have to be at a minimum while representing the maximum amount of Information relevant to the user. The challenge lies in precisely this act of striking the perfect balance between the Information and the Clicks. Keep in mind that the volume of on screen Data is never proportional to the volume of Information. It is a misconception that, a lot of data in a given space, implies supplying the user with a world of information. Noble as the thought may be, it is wrong to make such baseless assumptions. Too much data might actually hinder the user from retrieving the Information which he is looking for. There is another word: Retrieve. Why should the use have to retrieve/drive Information from the given Data. To put it simply, any UI should give the user the required Information and nothing else. No other associated data around it, thank you very much. Give the user with the basics first. Let him not have an opportunity to think. That is the final purpose of any software/machine, right? However, this does not imply that you do not give him the rest of the Data as well. Everyone likes to validate results and why should our target users be any different? What I am getting at is, that the elements of Data being provided to the users should be prioritized. The most informative should come upfront in BIG BOLD LETTERS! The supporting/associated data should (and i stress on the word should) be presented to him via more subtle one-click approaches. Having such priorities on data requires you to have a great understanding of the target user. A task which is no less than an ordeal. Sorting this issue alone will not only help you in better representing data on-screen but also give you a good way ahead in terms of the number of Clicks the user has to make to access the data he wants. Think about it. If the most important, viewed and useful information is presented to him upfront, then he will never have to click at all. If he has to look at the associated data, it will be a click away. Great isn't?!? But, trust me, this is a Utopian scenario, one which is almost too difficult to get at, not impossible though. Well, I have talked about the Usability of an interface till a substantial point, from where on you can make a judgement depending on your application and its user. Keep in mind, whatever works for you, is the best solution. There is no right answer in domain, and i guess that is what makes it so very challenging. I shall revisit this topic along with the Looks and Performance issues of a good UI in my subsequent posts. Until then, take care.
Media_httpicreativeco_chaee

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

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