Uncheck that Box...
and step away very slowly, sir...
I mean that figuratively, of course. 'Checking the box' implies a user interacting with a system UI, making a selection that will influence the outcome. However, the user is also a component of the same system, and subject to the same kind of constraints as the rest of the system.
The human in the system (user) can be regarded as an autonomous component, and although subject to business, social and legal conditions, potentially has more freedom of action than the other non-human, non-autonomus components of the system which are controlled by very strict application logic.
That "box", then, can also figuratively represent the system, bundled with the obvious choices, those that have been made for you by the System Designer. We shall consider the system as a box within which all the components are interacting towards some goal.
All systems exist for some purpose, and the goal of a system is to accept inputs and produce outputs to fulfill the purpose of it's creator. This "purpose" could be the fulfillment of a business or personal need, or anything else, it does not matter. What matters is that it is a complete system in itself, and it encloses other systems, and is in turn enclosed by larger systems.
What happens if the box is not checked? is the user, who is a system component rejecting the will of the Designer? Is the Design supposed to suppress and control the components of the system, or simply just show the most efficient and productive way to achieve the system's (and thus, the Designer's) goals?
After all, the user is supposed to have a choice, does he not? A good designer does NOT design a black box, but rather creates a design that allows for the user within the system to rip off the "casing" of the interface, and allowing them to bypass the normal channels, as long as they are still working towards the system goals.
In reality, athe appearance of having a selection to choose from, we are providing the illusion of free choice, but they are already limited by the Design... and the User Interface as the "casing" for the design, displays only the parameters, controls and input choices that the UI designer feels is suitable for the user.
So, even if the System Designer has designed a system that is robust enough to accept inputs that are not strictly controlled, the nature of the casing designed by the UI designer based on his/her understanding and interpretation of the User Needs has the ability to restrict the users actions.
Let us assume that each possible choice made by the user represents a potential path through the system, each arriving at a predetermined goal. Then, what happens if a user within a system chooses to follow a path that is NOT represented? Should they be able to? Should he or she be able to create their own path through the system? What would happen if they chose not to follow any of the choices laid out before them? Are they to be accommodated or denied?
Lets see - logic states that if an user is not willing to pick from one of the "available" choices, he or she should be informed that the system cannot continue to process whatever they were processing/requesting and gracefully terminate the process by presenting the user with the option to quit or to try again.
If the user was able to manipulate the controls and enter their own values, chances are that the system would either freeze and die, or return a ugly error message mumbling something about values being outside of acceptable parameters. OK so far...
Now let's consider for the moment that it were possible for an user to choose his or her own path through the system, completely unrestrained - or to reject the system even, by choosing not to make ANY choice, even that of creating a new path through the system... and suppose we allowed the system to permit the "uncontrolled" values. It would try parsing the information out and trying to make sense of it, and if the values were within range, would return something that may make sense to the user. Or perhaps not.
A qualifier here - rejection of the system by the user only implies that they will look for other ways to accomplish the systems goal, since it is the user's goal as well. All that "rejection" implies here is the availability of OTHER paths possible through the system in question, that are viable alternatives to the Designer provided paths.
If a system component were to be truly without constraints, then its behaviour would be unpredictable, and thus irrational. The system's integrity would be rapidly degraded, and it would tend to destroy itself, if there were no interventions by the system itself, or an external agency to isolate and neutralize the rogue component.
But.. what if the system was robust enough to accept the user's rejection of "acceptable values" and accept whatever value was input? What would happen? Would the user be more effective? Chances are that most users would not know what to do next, but perhaps there is one more intrepid then the rest who is willing to play around and experiment.
What would this user need in order to utilize this system ability effectively? I submit that no matter what information the user were provided with by the Designer from WITHIN the system, it would be of limited use, since the User's knowledge of the universe outside the system is constrained by their frame of reference being the the system they exist in.
Thus, even if users have NO constraints within the system they are in, they are limited by the fact that they are a component of the same system, and have little or no knowledge of the outside world. What is needed is a framework of reference external to the current system.
There we have it then - each system with all its component systems and users is the proverbial box - every thing within is constrained by the fact that it exists within the same set of constraining (operational) parameters, and try as hard as we might, there is not much we can do to force a system to operate outside of its operating parameters - at least not without rebuilding it or breaking it in the attempt.
What of the external frame of reference then? Who provides it? By my reasoning so far, The only way to permit complete autonomy is to operate in a "boxless" environment - this implies complete freedom from constraints - which is not possible in the physical world. That is because all systems tend to be nested within each other, if we equate each system with a box, we can make the case for boxes within boxes ad infinitum.
However, we can approximate such an unconstrained system, by hypothesizing that the "next box" ie the external environment is much bigger than the previous one - big enough that the constraints are not obvious. However, the larger system chosen as the external reference framework should not be so big that the user cannot understand or navigate it.
Thus, "thinking outside of the box" is not just desirable - it is essential to the understanding of any system. To truly understand a system, a user has to be outside of it. No system can be completely understood by its components - if the user is WITHIN the system, then no matter what we do from the point of UI design, workflow streamlining, information architecture, training etc., can change the situation if all the information we provide comes from within the system the user is immersed in.
As Designers - here, I don't differentiate between the UI Designer, System Designer or any other kind, we have the unique ability to "step" in and out of the various systems we are designing, ie, we constantly step in and out of boxes we are designing.
It's true that we ourselves are subject to the constraints of our own "boxes" (the systems that we belong to). But we CAN provide the Users of the systems we are designing with the "external framework of reference" that is so necessary for them to have a better understanding of their system. They do not see what we see, and conversely, they may be able to see events and interactions within their system from a perspective that we cannot.
Our Design efforts can give the user within the system an improved framework of reference, albeit skewed by the refracting lens of their constrained perspective. A user within a system may be able to grasp all the interactions beween all the components within his own system, but he or she will never be able to perfectly grasp the context of their system's relations to other systems, both bigger and smaller.
If a Designers were to completely immerse themselves within the user's system, at the user's level, then they too, become trapped within the same framework of reference as the users, and thus will be doing them a disservice by providing a design that keeps them from exploring the full potential of their system.
Thus, it behooves the Designer to explore the system he or she is designing from the perspective of all the constituent components at multiple levels - and balance it with information from outside of the system they are in. Only then will they be able to provide the user with the framework of reference and knowledge that they need to understand their system completely, and thus find ways to make it most efficient in realizing their goals.
_____________________________________
copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright/trademark of their respective owners.
I mean that figuratively, of course. 'Checking the box' implies a user interacting with a system UI, making a selection that will influence the outcome. However, the user is also a component of the same system, and subject to the same kind of constraints as the rest of the system.
The human in the system (user) can be regarded as an autonomous component, and although subject to business, social and legal conditions, potentially has more freedom of action than the other non-human, non-autonomus components of the system which are controlled by very strict application logic.
That "box", then, can also figuratively represent the system, bundled with the obvious choices, those that have been made for you by the System Designer. We shall consider the system as a box within which all the components are interacting towards some goal.
All systems exist for some purpose, and the goal of a system is to accept inputs and produce outputs to fulfill the purpose of it's creator. This "purpose" could be the fulfillment of a business or personal need, or anything else, it does not matter. What matters is that it is a complete system in itself, and it encloses other systems, and is in turn enclosed by larger systems.
What happens if the box is not checked? is the user, who is a system component rejecting the will of the Designer? Is the Design supposed to suppress and control the components of the system, or simply just show the most efficient and productive way to achieve the system's (and thus, the Designer's) goals?
After all, the user is supposed to have a choice, does he not? A good designer does NOT design a black box, but rather creates a design that allows for the user within the system to rip off the "casing" of the interface, and allowing them to bypass the normal channels, as long as they are still working towards the system goals.
In reality, athe appearance of having a selection to choose from, we are providing the illusion of free choice, but they are already limited by the Design... and the User Interface as the "casing" for the design, displays only the parameters, controls and input choices that the UI designer feels is suitable for the user.
So, even if the System Designer has designed a system that is robust enough to accept inputs that are not strictly controlled, the nature of the casing designed by the UI designer based on his/her understanding and interpretation of the User Needs has the ability to restrict the users actions.
Let us assume that each possible choice made by the user represents a potential path through the system, each arriving at a predetermined goal. Then, what happens if a user within a system chooses to follow a path that is NOT represented? Should they be able to? Should he or she be able to create their own path through the system? What would happen if they chose not to follow any of the choices laid out before them? Are they to be accommodated or denied?
Lets see - logic states that if an user is not willing to pick from one of the "available" choices, he or she should be informed that the system cannot continue to process whatever they were processing/requesting and gracefully terminate the process by presenting the user with the option to quit or to try again.
If the user was able to manipulate the controls and enter their own values, chances are that the system would either freeze and die, or return a ugly error message mumbling something about values being outside of acceptable parameters. OK so far...
Now let's consider for the moment that it were possible for an user to choose his or her own path through the system, completely unrestrained - or to reject the system even, by choosing not to make ANY choice, even that of creating a new path through the system... and suppose we allowed the system to permit the "uncontrolled" values. It would try parsing the information out and trying to make sense of it, and if the values were within range, would return something that may make sense to the user. Or perhaps not.
A qualifier here - rejection of the system by the user only implies that they will look for other ways to accomplish the systems goal, since it is the user's goal as well. All that "rejection" implies here is the availability of OTHER paths possible through the system in question, that are viable alternatives to the Designer provided paths.
If a system component were to be truly without constraints, then its behaviour would be unpredictable, and thus irrational. The system's integrity would be rapidly degraded, and it would tend to destroy itself, if there were no interventions by the system itself, or an external agency to isolate and neutralize the rogue component.
But.. what if the system was robust enough to accept the user's rejection of "acceptable values" and accept whatever value was input? What would happen? Would the user be more effective? Chances are that most users would not know what to do next, but perhaps there is one more intrepid then the rest who is willing to play around and experiment.
What would this user need in order to utilize this system ability effectively? I submit that no matter what information the user were provided with by the Designer from WITHIN the system, it would be of limited use, since the User's knowledge of the universe outside the system is constrained by their frame of reference being the the system they exist in.
Thus, even if users have NO constraints within the system they are in, they are limited by the fact that they are a component of the same system, and have little or no knowledge of the outside world. What is needed is a framework of reference external to the current system.
There we have it then - each system with all its component systems and users is the proverbial box - every thing within is constrained by the fact that it exists within the same set of constraining (operational) parameters, and try as hard as we might, there is not much we can do to force a system to operate outside of its operating parameters - at least not without rebuilding it or breaking it in the attempt.
What of the external frame of reference then? Who provides it? By my reasoning so far, The only way to permit complete autonomy is to operate in a "boxless" environment - this implies complete freedom from constraints - which is not possible in the physical world. That is because all systems tend to be nested within each other, if we equate each system with a box, we can make the case for boxes within boxes ad infinitum.
However, we can approximate such an unconstrained system, by hypothesizing that the "next box" ie the external environment is much bigger than the previous one - big enough that the constraints are not obvious. However, the larger system chosen as the external reference framework should not be so big that the user cannot understand or navigate it.
Thus, "thinking outside of the box" is not just desirable - it is essential to the understanding of any system. To truly understand a system, a user has to be outside of it. No system can be completely understood by its components - if the user is WITHIN the system, then no matter what we do from the point of UI design, workflow streamlining, information architecture, training etc., can change the situation if all the information we provide comes from within the system the user is immersed in.
As Designers - here, I don't differentiate between the UI Designer, System Designer or any other kind, we have the unique ability to "step" in and out of the various systems we are designing, ie, we constantly step in and out of boxes we are designing.
It's true that we ourselves are subject to the constraints of our own "boxes" (the systems that we belong to). But we CAN provide the Users of the systems we are designing with the "external framework of reference" that is so necessary for them to have a better understanding of their system. They do not see what we see, and conversely, they may be able to see events and interactions within their system from a perspective that we cannot.
Our Design efforts can give the user within the system an improved framework of reference, albeit skewed by the refracting lens of their constrained perspective. A user within a system may be able to grasp all the interactions beween all the components within his own system, but he or she will never be able to perfectly grasp the context of their system's relations to other systems, both bigger and smaller.
If a Designers were to completely immerse themselves within the user's system, at the user's level, then they too, become trapped within the same framework of reference as the users, and thus will be doing them a disservice by providing a design that keeps them from exploring the full potential of their system.
Thus, it behooves the Designer to explore the system he or she is designing from the perspective of all the constituent components at multiple levels - and balance it with information from outside of the system they are in. Only then will they be able to provide the user with the framework of reference and knowledge that they need to understand their system completely, and thus find ways to make it most efficient in realizing their goals.
_____________________________________
copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright/trademark of their respective owners.
posted by gentlepoet @ 9/01/2004 04:42:00 PM
0 Comments:
Post a Comment
<< Home