Interaction Design between user and the operating system - Part 2

Taking our discussion further, in this blog we would explore options for programming the user interaction with operating system.

User action programming

In part 1 of this series we focused on the direct user interaction with the operating system. But fact of the matter is that most of the user interaction on a computer or a device happens through a custom software or app. So it is very important to focus on the programmability of the operating system functions.

"Any programmed interaction must make use of most of the operating system supplied functions."

The above statement is the essence of this discussion. Let us establish one thing here before we go any further.

The best (in terms of ease of use and reliability and probably others) interaction experience is through operation system supplied functions.

For example: If I want to open folder and view its contents, the operating system has a command for it. It would have a user interface and set protocols (steps) to invoke that command and the experience that user gets would be standard and consistent. A programmer can write a custom software that would accomplish exactly the same thing but using different user experience and different protocols (steps). Another programmer can write another software that accomplishes exactly the same thing but using another set of different user experience an different protocols (steps) and so and so forth.
The thing to note here is the impact on the user. Since custom software uses its own user interaction and protocols, it is responsible for the acceptability and reliability of its functions. What is meant here is that the programmer would have to consider so many things to create such a software. The user is totally dependent on the knowledge and the interface engineering provided by the programmer through the custom software. This is where we start loosing the battle. This is where we as engineers or programmers have to ask ourselves, are we taking the user out of misery or putting them in misery? If we use the operating system supplied functions in our code, then we would not have to worry about so many other things.

As a reader you must be thinking that this would end  all the programming and programmers especially the application programmers. Well that is true, in a perfect world. We as technologists are not as developed yet. We have a long way to go. But this is what should we strive for.

Let us get back to our current era and talk about the points againts the above statements.

1. What about those interactions that operating system does not provide?
That is a very valid point. Let us take an example to elaborate more on it.  The application that user is using requires a certain interaction of moving the position of the window from right to left with in the time span of 2 seconds as a result of a user action. This user action would always yield the same result of moving the position of the window. The operating system that user is using does not define it a function. Means there is not a similar interaction provided by operation system as a function. In the case the obvious solution would be to write a custom code that does such interaction. A programer writes a such a code. Same task is given to another programmer and another programmer. We would have a result using different solutions that accomplishes the same thing. Since the solutions or the written custom code is different, we have to assume that one of them is better then all the others. What if we just had one programmer and he/she was the one who tasked and the solution the he/she wrote was not the one that was the best. It means we have a software code is not best code. This is the point that mentioned earlier as the point that we as technologists start loosing.

So what should be the solution. The solution should be that the operating system should be augmented with the best solution (code) for the moving the window from right to left within a set time. This would become an augmented function of the operating system and should be made available publicly to other progammers.

2. So we keep adding functions to OS but for how long?
This is another valid argument. We cannot keep adding any new interaction that anyone's mind can think of. This is where we have to make a distinction between valid and invalid interactions. We have to draw a line in the sand and define these two types of interactions. We should design software using such that user would not need to make use of an invalid interaction. This is another high point in this discussion. The interaction design should be so smooth and natural that user does need to think of an interaction that in fact is an invalid interaction.

Conclusion

The point of this part was not that we do have software that do not make use of operating system defined functions. But to point out the places where we cannot. The two main points are: A) that operating system should be rich in respect that all its functions should be valid and available. B) the second point is that we should design the interaction so smooth and natural that use would not need to make use of interaction that is not defined as a valid interaction.



 

Interaction Design between user and the operating system - Part 1

Designing any kind of interaction between two entities is always an imperfect science. It gets easier if the two entities are predictable systems. If we set out to define the design interaction between two highly predictable systems then it will not take very long to do so. The complexity increases with the increase in the unpredictably of entities. This can be express in following equation:

Design Complexity ∞ 1/Predictability of entities

As we get more and more predictable entities, we get better framework to define design interactions.

In light of aforementioned theory, it is obvious to assume that designing interaction between user and operating system will be highly difficult feat. Why is that? The answer is pretty simple. Unpredictability of the user. There is a limit to how unpredictable the operating system can be but there is no limit to user unpredictability. This proves the very first statement i.e "Designing any kind of interaction between two entities is always an imperfect science".

So what are our options?

This blog and subsequent parts of this blog will try to address options, design patterns and thoughts that will help us create a better interaction design between a user and operating system.

User action dependability
Most of the operating systems that I know of are reaction in nature when it comes to user interaction. They react to each user action interdependently. For example, user opens window, closes a window, deletes a file, creates a file, etc. These all are independent actions. This is fine to some extent. We as users are used to this design of interaction. In this case the operating system is fulfilling the role of server of user actions. This is one way to look at the interaction. This works for most of us. Why this works is that we have developed a mindset that is accustomed to this pattern.

There is another way to look at it. The other way is where the operating system understands each action and tries to understand what user is thinking and trying to achieve. With each action the operating system adapts and defines the interaction framework. The operating system also adds its smartness along the way.

To better understand this let us take an example. I am writing this blog in some software. At the same time my mail client application is open. The mail client application is usually kept open all day. I keep receiving emails and the mail client keep notifying me as emails arrive. During writing this blog, I click the close button on my mail client. The mail client closes. Why the operating system closed it? Because the operating system is servicing my action. The operating system did not process the correct intention of my action. The operating system just fulfilled my action. What if the operating system does not closes the mail application right away. Instead it just minimizes it or notifies me that this is middle of the day and am I sure to close this application. Think about this for a minute. What we are looking at? Are we looking at highly adaptive and intelligent operating system? Yes, from objectively thinking it probably is. But my point here is not to have highly intelligent operating system. My point here is that operating system defines interaction framework based on some logic.

Unity 2.0 Design pattern in simple words

As part of my search for perfection in technology, I come accross many different technologies. Some of them are worth delving into. One of them is Unity 2.0 design pattern. In this article I will try to explain the basic premise of Unity 2.0 design pattern, where it should be used, where it should not be used and simple steps to implement Unity 2.0 Design pattern.

Unity 2.0 design pattern in simple words:

• Unity 2.0 is a type of design pattern that can be used to implement composite application library.
• Unity 2.0 design pattern lets us to view different modules of our composite application to appear as signal entity.
• It allows objects belonging to different modules to implement dependency on each other.

From the above mentioned points, the most important word here is dependency. So in more simpler words

"Unity 2.0 design pattern is used to implement dependency injection"

How to implement Unity 2.0 design pattern?

Step 1: Download Unity 2.0 library. This can be found here.

Step 2: Create composite application using Composite Application Guidance. You can find the details about this here.

Step 3: Override the boot strapping class in composite application to use Unity bootstrapper.

Step 4: Identify classes in your composite application that are dependent.

Step 5: Create a dependency injection (DI) container using the Unity 2.0 library.

Step 6: Implement dependency injection using one of the following techniques:

1. Using build up to wire up objects not created by the container
2. Using injection attributes

Happy coding!

Silverlight 4.0 - Best practices

Any technology company that pursues excellence, bases their work on some patterns and practices. For some these practices are part of their vault of company secrets and for some their practices are not so secret. I am big fan of sharing knowledge in order to acquire more knowledge.

Following are some best practices that I came across during my search for perfection in Silverlight 4.0 technology.

1. Head first design pattern: If you look at the evolution that Silverlight been thorough since its inception, you will realize that now it has evolved in a complete development platform. Due to this fact, I think anyone who wants to create a solution in Silverlight 4.0 has to think about the architecture first. Also, the technologies that complement Silverlight 4.0 can fully be appreciated if we have good architecture. Specially if we implement the separation of concerns design pattern.

2. Harness the power of WCF: One of the great things about Microsoft is the fact that they come up with a great technology that makes you excited. Although most of the times it takes Microsoft three releases to produce such a technology but still I think it is a great feat. Similar is the story of WCF. I have been working on services development since 2002 and had a close tab on all web services technologies. I think in regards of WCF, Microsoft has got it right. One of the amazing things in WCF is its support for Silverlight. Especially the advent of WCF RIA services. If you are implementing any line of business application for web, you should definitely look into this as development platform.

I welcome all comments.