Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Thu, 14 Apr 2011 06:30:09 -0700 Inverted Indices http://vijaykrishna.posterous.com/inverted-indices http://vijaykrishna.posterous.com/inverted-indices The first time i came across this data structure, i was quite ashamed of the fact that i did not know of it earlier. This seemingly simple concept eases the complicated process of search by leaps and bounds. Most of what i know about this is really a whiff of the top layer of this amazing heap of brilliance. I got most of my introductory notes about this concept from its Wikipedia page. Now, in order to understand this concept of data structuring, or rather to understand it better, lets have a look at Forward Indexing. Let us assume that there are three files, t1,t2 and t3 with the following data: t1 - "an apple" t2 - "a day" t3 - "an apple a day" Now the forward index of the file would look like this: T1 = {"an", apple} T2 = {"a", "day"} T3 = {"an", "apple", "a", "day"} Thus, in order to search for a word like "a", you have to do a sequential search of all three text files for a satisfactory result. This, seemingly simple approach mind you, is a time consuming and complex process as the data set gets bigger. Here we have about 3 text files with not more than 4 words per file with a search query containing one single lettered character. Things are bound to get slow and difficult when you are looking at say about a Million files, with a minimum of 10,000 words in each file and a full phrases sentence for the search query. And imagine doing this again and again. Now, let us look at the Inverted Index: I(an) = {1,3} I(apple) = {1,3} I(a) = {2,3} I(day) = {2,3} I(a) => Index for the word "a" and its results imply the file numbers where the word can be found. So, in order to find the location of the word "a", you really have to goto I(a) which gives you 2 & 3 which are the files where the word is located. It gets better when you have to search for a string of words together, say "day apple": You take the intersection of I(day) and I(apple) for you to get this: {2,3} n {1,3} = {3} Hence 3 is the only text file where the these two word come together. This makes search fast and efficient. Something which we have always been trying to do. Let us take this a step further: What if we were to start storing the position of the words in the text files along with the text file's numbers in the inverted index. So the inverted index would then look something like this: I(an) = {(1,1), (3,1)} I(apple) = {(1,2), (3,2)} I(a) = {(2,1), (3,3)} I(day) = {(2,2), (3,4)} where (3,1) would imply file 3 and word 1. So now when u search for "an apple", you will not only be able to match the words but also the sequence in which they appear in the query string with that in the file: I(an) = {(1,1), (3,1)} I(apple) = {(1,2), (3,2)} I(a) = {(2,1), (3,3)} I(day) = {(2,2), (3,4)} So this elegant data structure is very fast and has been instrumental in all kinds of information retrieval systems, right from search engines to DNA matching algorithms. Tell me, did you know of this one before 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
Tue, 05 Apr 2011 06:46:48 -0700 Coding (vs) Logic 1 http://vijaykrishna.posterous.com/coding-vs-logic-1 http://vijaykrishna.posterous.com/coding-vs-logic-1 Yes sir!! it is a battle of clans! Today all thoughts all ideas are going to come down here. And i am holding nothing back. It is a great war this. In the world of software development there are those believe that it is the Coding that matters more than the logic! startling claims indeed. And maybe that is the reason why they have been loosing as well. Logic undeniably is ultra important when it comes to developing software. Those who somehow claim that coding skills can outshine logical abilities, obviously have issues with their logic. But then i sat down thinking all these years and more so in the past few months, thinking if there was/is any logic in what they said. Can coding truly be as important as the logic, where it is built upon that very logic? That was the question going through my head. And that is when i realise that, i was asking the wrong questions. While the theme was the same all through... code vs logic, the concept or the understanding behind their relation was wrong. The real question is this: Can coding truly be as important as the logic which are nothing but mechanical transformations of each other? And with great thought and pondering, i think yes! In fact, Logic and Code are equally important in the whole process of software dev, and this is irrefutable. You see, like i mentioned above, code is nothing but the mechanical transformation of logic. While logic addresses the solution to a problem, coding addresses the solution to the problem of rendering that logic. Logic is devoid of syntax. It is concerned with the mechanics of how a given issue or problem can be resolved. And hence, it is a more universal phenomena. Be it programmer, a manager or an army General, all use logic. They all render it in their own manners. The General does it with Battle Formations, a Manager with Resource Allocation Charts and a Programmer/Coder does it with Code. So, Code like a Battle Formation or a Resource Allocation Chart, is a tool to render the logic used to win a battle or solve a problem. If this use itself is not logical, then there will be issues. If the troops are not commanded properly by their battalion commanders then the army will loose. If the junior managers do not follow the charts properly to allocate resources, then there will be surplus at one place and scarcity at another. If the code is not used correctly then exceptions and bugs will occur. Its that simple. Now do you get the point? Let me put it in a single statement:
Logic renders the solution to a problem, while code renders that logic.
Thus, without the code, you cannot go out to kill the problem. Logic alone is not the answer. So its time that the two clans ack this and greet each other with open arms and paramount respect. Then i thought about how one should go about dealing with logic and coding. I guess that there will always be infighting between the thinkers and coders in any team. Of course the successful bunch are both: coders and thinkers. But coming back to the point, to avoid the natural conflict between logic and code, it is best to isolate the processes. Yes, there is no innovation in this age old idea, i agree. But i am talking blunt firmness. Isolate the two process completely. Do not even think about one when u are busy working on the other. My manager and mentor in my firm has been telling me this right from day 1:
When you are working on the logic/design for a problem, do not think of how it will look in code."
I guess he forgot with the second part to such an apt statement. Never think of the problem and its logic or its design when you are coding. Even though you know that something is wrong, trust it blindly. Get the bugs right. Resolve the issues. Once the code is running and is rendering the given logic then get back to the logic development and enhancement. There is no point shuttling between the code and logic design. Imagine if a General were to do that in a battle: 1. Come up with a Battle Formation. 2. Send the troops in to battle in that formation and the associated orders. 3. "OOOPS!!!" Realise that the Formation and Orders were wrong. 4. Call the troops back, which is half way through the battle. Here we are assuming that a lot of loss has already taken place. 5. Goto step 1, if you have not already lost the battle or if all your soldiers are not already dead. See the issue with the toggle approach if it were employed in a battle. Treat everyday software development as a battle. You are bound to make more profits by making and selling better software than you are making and/or selling right now.

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
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, 16 Feb 2011 17:20:52 -0800 SRS: Software Requirement Specifications http://vijaykrishna.posterous.com/srs-software-requirement-specifications http://vijaykrishna.posterous.com/srs-software-requirement-specifications I was finally able to clean up my comp today off all the trash i had accumulated over the years in college. Saved up a lot of space!! :D That is when i found this rather interesting document worth having a look at. It was a simple straight forward guideline to writing an SRS. I used it while documenting my analysis and design aspects of my final year project. It is to the point and comprehensive to say the least. I guess one such document should always be by your side while working on any project. :) I could never quite locate the true source of this document. It was a life saver for me. So here is the link to it: SRS.pdf Hope this helps you in your documentation and analysis of your projects. Cheers!!!

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
Tue, 08 Feb 2011 17:38:04 -0800 Website Team Graphic http://vijaykrishna.posterous.com/website-team-graphic http://vijaykrishna.posterous.com/website-team-graphic This is a graphic plus logo, i developed today while at office for a WebSite team in my undergraduate college. It was really supposed to be a proof of concept. It finally did not meet the purpose simply because the idea was too tangential for the ultimate group in mind. Having said that it turned out to be a pretty decent grapic. Here is it: [caption id="attachment_219" align="aligncenter" width="500" caption="Logo POC for the Website Team of my college."]
Media_httpvpalepufile_aombe
[/caption]

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, 06 Feb 2011 13:08:05 -0800 Login Issues http://vijaykrishna.posterous.com/login-issues http://vijaykrishna.posterous.com/login-issues The other day at office, there was some general talk on how people get some really retarded ideas when it comes to making a login process really secure. The particular feature that was in focus concerned the idea of temporarily deactivating a person's login after 3 unsuccessful tries. The simple issue with this method is thus: any one, can deactivate your account if he knows your user-id by making 3 unsuccessful log in attempts using incorrect passwords. This can make life hell for you. So, what are the possible work-arounds? Well, take a look at the core issue that you are trying to address by deactivating accounts after 3 unsuccessful login attempts. I think the core issue is to make it difficult for the person/bot who is trying to login, in case of 3 unsuccessful attempts. Now, try and understand this: the person or bot may not be the actual user himself. So the locality of the issue and its solution should be at the client side of the application where the login attempts are being made, not at the data level where the respective user information is being stored. In a nutshell, make it difficult for the person who is logging in by creating trouble at the UI not by completely deactivating the account itself from the DB. What are the ways to create hell at the UI? There are plenty of them. Off hand i can think of using a captcha after 3 unsuccessful attempts. See, now the entity logging in or trying to log in using a brute force attack will find it difficult to log in. Thus, you are not really creating the issue for the account holder. So, the next question in the pipeline is, how would you create more trouble? Here are a few suggestions: a) Disable the use of the keyboard while entering the credentials. Present the user with the virtual keyboard while entering the userid, password and the captcha. Why I say captcha is that you can use this method after 3 or 5 unsuccessful attempts after the captcha is initiated. This will force the use of the mouse making life miserable for the cracker, trying to crack into some account. b) Start using an audio captcha after a while. But, with this you are negating the users who might be deaf. But that is your call. c) Start asking all kinds of user related information such as the Date of Birth of the User, the Secret Question, etc. d) If all this does not work, send an Authentication code to his email id with which he has registered into the system. If none exists, then ask for a temporary one for the same, and keep asking for the email id on every failed login. This way you can actually keep a track of the kind of email ids being used and you can actually do some background check on the user himself. Mind you all these are ideas that have just bounced off my head. I am sure you can come up with more creative solutions for the same issue. Ofcourse, i would like it if the people, building software systems involving logins for my critical systems such as banks and may be online voting in the future, were not to use such methods. Deactivate the accounts or login credentials. Do so especially in the case of ATMs. That is why i guess we use them in the first place. ;)

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
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
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