« Back to blog

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.