Discuss:Computation, Software, Systems:Purpose and meaning in software design
From da Vinci Concept
Contents |
Purpose and meaning in software design
These are some quick thoughts concerning software systems, particularly user interfaces. I would enjoy commentary and discussion concerning the usefulness of modern software systems and possible paths that would increase their value for humanity.
Concerning the user interface
The modern software user interface comonly forecloses on the human mind by forcing the user to interact in non-essential ways with the software system. The machine has control over the processes used, the critical decisions concerning data, and the interface-implemented features and therefore discriminates against users who desire more control and functionality not implemented within the UI (support for batch processes and scripting calls is a common fault of pureley graphical interfaces). It is necessarily the case that our software require us as decision makers. It is the choice of which decisions to allow the user to make that is the failing of modern software systems. Human control over software processes is and always will be necessary. In order for computers to retain their usefullness for humanity, humans must remain within the critical decision loops. This does not mean that huge and cumbersome UI's be designed that implement every possible feature. This creates gargantuan software systems requiring more intellectual resources to understand and use than any single individual every has at their immediate disposal. Large database systems such as Oracle immediately come to mind as examples of this fatal flaw in interface and architecture design.
Software escapism, the non-essential users
Many software systems are attempts at human escapism. By making important decisions without the users cognitive participation such systems often prevent rather an enable useful work from being done. Machines should primarily make the trivial decisions and provide assistance in the human decision making process for more important decisions. This opposes what is commonly attempted in software design. It is thought that important and critical decisions should only be made by the software, thereby eliminating human error and preventing the human thought process from affecting pre-programmed machine made decisions. It is perhaps the prevalence of this user-interface escapism [from critical decision making] that prevents machines from becoming more useful. Software escapism is the current paradigm; machines programmed to prevent human intervention in critical and important decisions made by software thus creating a software environment where the human mind is stultified by the trivial and banal decisions left over from the software process. This is not to say that there are computer systems and interface designs that work to help the computer user make important decisions and make human methods more productive by freeing us from the trivial and non-essential. The question of what is essential can be objectively evaluated in regard to the software's purpose and the methods employed to achieve that end. Comonly ALL of the possible decisions allowed for the user to make are non-essential and therefore WHICH of the non-essential decisions is considered essential by users that choose to use software based upon this model is also non-essential and characteristically subjective.
The purpose of software
The purpose of software is to provide a useful product for the consumption and purposes of the human mind. Insofar as much as the programmer is able to foresee the purpose of this useful work software is designed to provide an abstract product that is generated without human intervention. In order to provide software that is sufficiently abstracted from its many possible applications it is necessary that only the non-essential decisions are delegated to the machine and that the software provide assistance to the human decision making process for essential decisions. Of critical importance then is the ability of software providing essential intellectual products to differentiate between the essential and non-essential. The very structure of simple software systems provides this differentiation. More complex software, however must necessarily be more and more adept in differentiating the essential from the non-essential. In the same way that humans form concepts from the combined differentiation and integration of perceptual and conceptual (concrete and abstract) existents, complex software systems must also be sufficiently capable [for their purposes] to achieve the integration and differentiation of known existents. In order for the essential and non-essential to be determined, complex software systems must be capable of the formation of limited sets conceptual knowledge.
Smart software and limited concept formation
A primary technical challenge within this area is the formation of percepts by machines. It is a common task for a machine to collect data in the form of sensations; isolated and instantaneous sensory data. There are many competing and isolated theories concerning artificial intelligence. Many of these are likely using a valid method of forming concepts from precepts and precepts from sensor data. It is however, also likely that there is not a consistent and corrective evaluative method for these systems. Many likely have some useful application, but not necessarily useful capability within the scope of their intended applications. They are theories without a consistent basis for evaluation. Because of a flawed theory and thus implementation of concept formation many of the theories of artificial intelligence will likely prove invalid. It will be those theories that implement a valid theory of concepts that will succeed.
--sunny Sat Jan 17 21:16:54 2004
macrocosm Thu Dec 16 9:15:03 2004
Transparency: Exposing Objects and Algorithms to the User
I find utility in a UI which exposes the decisions intrinsic to the algorithms driving the user experience (those of the OS and the software which sits atop it). In other words, where user experience X is comprised of algorithms A and B, with A i.e. being composed of steps 1-3, then each of these steps (1-3) would be exposed to the user, the user would be fully capable of manipulating and/or removing these steps, adding new steps as necessary, and so forth. Which steps will be initially apparent to the user, or the objects whose properties and children are being altered via these steps, will be up to the software developer. But the underlying framework under which the software exists, performs its functions, and was initially formed, will allow for full transparency.
Rights of the Software Developer
This of course is not to say that the software developer may not protect his/her work. It is instead that the software architecture will be constructed so as software is merely a bundle of objects and the algorithms which manipulate these objects (via their many aspects)--- each being well distinguished from the other, and each being plug-and-play (capable of integration and removal in virtually a single step). Note that objects coupled with and/or containing algorithms qualify as components in my definition.
Selective Protection and Consumption of Components
In this way, the software developer can decide which objects and/or algorithms (or subsets thereof) to protect and the user can decide which objects and algorithms he/she wants.
Framework Should be Integrated with the Operating Environment
This framework should be intrinsic to the OS, so as one can interact and manipulate one's OS in this same manner as afore-described. The entire software level computer system will then be composed of multiple layers of objects and algorithms with the OS layer acting as the launching pad.
Resultant Market Expansion
The partial expectation is that this will result in new markets arising: markets in the sale and purchase of objects and algorithms (which may be distributed in pre-bundled yet _open_ configurations), versus enclosed applications which pollute the user's system with the applications' required (and not-required) respective opaque parts.
In this way, applications will be initially created and distributed with specific parts of this bundle being closed, but it will be well exposed what composes the application, what its respective parts are and which are open (with all of them being capable of removal and replacement).
Partially Addressing the Problems of Current Systems
However, I am aware that many contemporary applications have open architectures which allow for "plug-ins" or "extensions", some being restrictive in that they specify which development tools (languages, etc.) one can use, and others merely requiring dlls. But what differientiates the system I envision from these others is that firstly the plug-and-play openness starts with the operating system, secondly the initial application is exposed in respect to its constituent parts, and thirdly its constituent parts are themselves "plug-ins" hence swappable with alternatives.
Dynamic and Adaptable Composition of Applications:
Encouraging Continuous Improvement via Competition
So in that way, the initial system is not etched in stone, and if say... another company or software development entity can create a "plug-in" which is better than the original, it can be integrated seemlessly, transparently, and easily (for both user and developer) into the whole system. Thus, the user experience is enhanced, and the original developer is given continuous incentive to improve its offerings.
Appropriate Licensing Framework
Crucial to this is a legal framework which is suitable to this form of software system. It must be that only _individually_ may the components/objects and algorithms be legally protected. In such a manner, the entire application can not be protected as a whole and thus if another developer comes to provide better components for that application (whether initial components or add-ons), the original developer can not pull the whole application, can not kill it. Instead, the developer must align itself with or elevate itself above the competition or otherwise sever itself from that application all together.
It also becomes necessary for the origninal developer not to have the right to seize distribution of the original components. If the original developer chooses to abandon them, chooses to cease self-distribution, other entities should be able to distribute these components with the condition that they must compensate the original developer appropriately.
Also, a protection scheme will need to be implemented to disallow unauthorized distribution of components.
Nevetheless, all components should be distributable by anyone, as long as the original developer is sufficiently compensated. (Moreover, the code which binds all the components together as a single app should be necessarily open source.)
Beyond Transparency: Accessibility
Note that in this framework, all components and algorithms will be, quite importantly, _visually_ exposed to the user--- via a GUI, one will be able to see all the objects and algorithms which compose the application they acquired, they will be able to see all the methods and properties of these objects, see flowcharts of each unprotected algorithm, etc.; and the user will be able to manipulate the application through this graphical interface(s).
The facilities for this will be built into the application development framework so as no extra effort in regards to the developer will be required to make this possible. (Users of course will benefit nevertheless from clearly defined (labeled) properties and methods, and for the user who is interested in actually modifying algorithms etc. well commented code becomes extremely helpful, if not necessary (and this would also thus add greater value to the product in many cases).
Further, in this sense and as intended, the environments of the user and the developer will have been integrated, the barriers between them reduced to nil. As a bonus result, we would likely see an increase in users becoming developers and therefore likely an increase in contributions of components (objects and algorithms), thus benefiting the user-developer community as a whole.
---------------------------------------------------
Note that I typed this up fair quickly, so excuse any grammatical or other errors, areas lacking clarity, and so forth.
P.S. Where do filesystems fit into this model?
Regarding the latest edit: Multiplicity of meaning has been reduced to a minimum at Sunny's (and Truc_Ha's?) request.
[ Edited Mon Feb 07 2005, 11:26AM ]
--macrocosm Thu Dec 16 9:15:03 2004
sunny Mon Dec 20 14:44:29 2004
I agree that both modularity and portability of individual algorithm components are important for software systems. Accessibility of the internal states and capabilities of individual subsystems is also important.
Simplicity in design
Within software design, a complex trade is made between the time and resources needed to develop, algorithm abstraction for portability, system simplicity, and ease of use. It takes time and human resources to design well-abstracted code and functional user interfaces. A more abstracted software system has a greater the number of potential applications, but is much more difficult to design, understand, and use. The underlying software may have powerful applications, but are often virtually innaccessible to anyone but specialists.
Humanity has developed an atrocious habit of undervalueing simplicity in design. Instead of designing modular and simple software that accomplishes very specific tasks using the best available methods, we design convoluted systems that attempt to solve all problems and confront all potential uses. These are monolithic solutions that are intrinsicly flawed, the drive to apply to the greatest number of problems directly conflicting with ease of use, stability, and most importantly, self-consistency.
I agree that modularizing the unique and specific algorithmic tasks that a software component accomplishes is the right approach. By creating extremely simple, fast, and efficient subcomponents as algorithmic modules that can be re-used within other systems, we accomplishe the requirement of re-useability and versatility. We also enable the type of accessibility that you are discussing. By keeping the simple components simple and discrete, we eliminate bloat and enable the creation of simple software interconnects, and simple, intuitive user interfaces.
The remarkable complexity of most modern software systems is mostly bloat due to a lack of modular design and the application of the wrong philosophies of design.
The opaque enigma of proprietary software
The opaqueness that you mention is one of the most enigmatic problems facing modern software. Because software is unavailable for examination, software corporations do not create secure code. This is known as security through obscurity. In the 'Microsoft Windows' world this is a very common practice and the end-users suffer the consequences of opaque system design.
The question that opaqueness is often answering is: How do you keep your software secure from being reverse engineered? The seemingly simple answer is to make it opaque, but this ends up being the most convoluted solution, requiring methods of obscuring the compiled code from reverse compilation, authentication and authorization schemes that create bloat, stability, and interoperability issues, and always end in systems that are not well-maintained and eventually expire.
Just compare Windows and any GPL Unix. One is out of date within just a few years. The other is still useful decades later.
The better answer is to make it open-source and to rely on developing 'glue' systems, slick user interfaces, and client customizations as a product. Provide services instead of obscurity. The security of a system can be directly examined instead of tested via exhaustive testing techniques.
Open architecture and open-source
I think that we do have an architecture that is modularly exposed in this way on a component-by-component basis in the world of proprietary and GPL Unix, and Linux. This includes any modern operating system that is POSIX compliant. The individual software subsystems that can process data are all individually accessible, or can be scripted to form larger, more complex programs. User interfaces are built on top of the individual subsystems. Each individual component has a specific task or tasks that it accomplishes in a close to optimally efficient manner.
--sunny Mon Dec 20 14:44:29 2004
macrocosm Mon Dec 20 20:24:37 2004
"The better answer is to make it open-source and to rely on developing 'glue' systems"Open-Skeleton & Selectively Closed Component Base
What was quoted above is sort of the opposite of what I am proposing, but I find agreement with it just the same.
What I was proposing entailed the application skeleton ("glue code") being necessarily open-source. This would allow the user community (and developers) to always have control over the application structure so as to insure the application's adaptability to user needs and desires. In this way, it will be select components (say, those which do not form the basic foundation of the app) which will be protected by the developer.
Encouraging Adaptation to User Needs via Increased Competition
If these components do not adapt to user needs and desires, these components will give way to the alternatives provided by their competitors. This acts in theory to insure continuous user satisfactory development of software.
Why Open-Skeleton?
The reason the app structure need be open-source is to prevent the original developer from killing the app by pulling it from the market: thus leaving the components provided by competitors useless, and the user with soon-to-be dinosaur software. The original developer may do this to attack its competitors who may have produced better components tailored to the app structure (foundation of basic components and their 'glue' [unifying] code)--- "better" in this case being determined or indicated by users transitioning over to these alternative components versus buying the original developer's components and various component updates etc...
Extend and Adapt
Instead of other developers wasting energy and efforts reinventing the wheel, they merely extend and adapt current applications to user needs/desires. Developers can provide additional components that operate atop the opensource skeletons, and can even alter this skeleton through the opensource community or via custom tailored and distributed modifications (stand-alone 'patch' components).
Whether this method is more efficient than a closed-skeleton and open-component design must be subjected to debate (preferably via this forum).
Quality and Quantity via Specialization
This system allows for more specialization: groups or individuals with particular talents can focus on that aspect of an application which suits such talents, versus having to deal themselves with all aspects of application design and so forth. This will likely bring people to participate in and establish software design processes, people who do not want to bother with the entirety of the processes and thus would otherwise not participate at all. This will likely lead to an increase in contributions regarding computer software and will also likely increase overall quality of software (thereby user experiences)--- this increase in quality will occur not only via the increase in quantity of contributions, but also the context under which such contributions take place and are encouraged (the configuration of the community that is).
Expirable States of Proprietariness
Under this framework, any component which is proprietary can remain so only as long as its proprietary life span, a life span to be determined by an assessment of how long before the respective component will become outdated--- relative to competing components and applications, preferably those existing outside of the community. (The problem here lies in specifying how such an assessment should take place [what variables should be examined etc.].) After the right of proprietary status (RPS) has expired (the life span having run out), the original developer (OD) has the option of either releasing the code to the community or, if perhaps the OD feels it has not been sufficiently compensated for its labor through the period in which its product was sold in proprietary form, the OD may withhold release of the code in conjunction with the transfer of rights of the product's binary form to the community. With latter option, such rights include those which pertain to royalties. The community then receives the royalties and can do whatever it see fit with the binary product as long as it does not tamper with, or in any way attempt to reveal the internal logic of the component (no reverse-engineering allowed!). Thus, if the OD finds it in its strategic business interests not to release its code despite losing rights to royalties pertaining to the distribution of its code in binary form, it may make this choice, observe the consequences, and move on. Moving on may entail modifying the code and releasing a new version of the component. It can do this, but of course, the new component will too have a proprietary life span, and thus the cycle starts over again. Again, the OD may choose not to release its code after the expiration of the RSP; but also yet again, the OD will lose its rights to the royalties. This can be done ad infinitum.
It is highly unlikely that ODs would repeatedly do this however, as such is hardly an effective or stable business strategy. Also, particular measures will have been put in place to encourage alternative behaviors.
For example, released code can be made subject to an initial fee, but of course the code can be distributed free of charge (or with charge) by he/she whom purchased the code from the OD (this is identical to the GPL in this respect).
. . .
Profit via Services
"slick user interfaces, and client customizations as a product. Provide services instead of obscurity."
I agree most thoroughly. I envision a software architecture where it is _very_ easy (hence hassle-free) for the user to customize their applications themselves, but I recognize that there will be many instances where the user has a "problem" which requires a programmatic solution. Companies can provide such solutions for a fee, these solutions being custom talored to the specific user but in some cases perhaps having more general uses. These general uses can be realized through the aid of open-source communities, and the company will benefit further through the fee-based provision of related services and so forth.
Fostering Solution Formulation : Solution Markets
I would also like to devise a scheme for the handling and encouragement of solution formulation and distribution. My currently conceived scheme involves the combination of a solution development forum in combination with a web-based market of solution exchange. The former would be a collaboration medium such as a wiki whereby solutions in nascent form can be posted for further development via feedback from the community and also as a medium whereby users can post problems and then developers can post potential solutions and interact with the user(s) etc...
Bringing Together Users and Developers
The community would be composed of users and developers working toward successful solution formulation and implementation:
1. Users post problems and accept solutions which they deem adequate to addressing the problem posted; users can provide feedback on the various aspects of solutions (not necessarily to a problem they posted). and aid the developers in determining what the solutions should do for users.
2.
--- Developers aid in the how process. They provide feedback on feasability, efficiency, and so forth regarding the solutions provided. Any singular developer (or group thereof) can be aided by the others in figuring out how to make their partial solution into complete solutions fully capable of implementation.
--- Developers implement solutions. Solutions are sold in the web-based marketplace via a flexible array of potential agreements: the solutions can be sold for a lump sum and/or a royalty arrangement with any configurations of the two options entailing compensation to not only the primary solution developer(s) but also to the contributors of the community. The latter specification will be implemented by defining a maximum total % of profits to be distributed to contributors followed by this total sum being split evenly among them. (The problem here lies in determining who contributed and who did not.)
Solutions Need Not Be Sold
However, solutions need not be sold and can be implemented freely by the developers themselves or freely by the community or subsets thereof with the developer's permission.
Solution Need Not Be Implemented by Creator
A very important feature of the system will be that solutions need not be implemented by the creator of the solution. This opens new doors to people who may understand software design methodology and concepts, as well as have particular talents in empathizing with users and their needs/wants, but whom do not have the skills/time/desire to actually create software. They can still contribute to the software design process, and will still receive compensation for their work. This applies in the reverse were a programmer may be highly talented when it comes to the nuts and bolts of programming but may not be very skilled and/or interested in regards to developing programmatic solutions to user problems. In this way, the programmer already has a blueprint to follow and can worry merely about the micro-algorithmic details and so forth.
Community Support
The community will foster projects which have gone through the solution feedback and amelioration process(es). The community will provide such projects facilities for successful completion and continued success. These facilities should include (not reducibly) the following services:
1.
--- For starters, project hosting entails dedicated pages for further user-developer and developer-developer interaction for any community derived project regardless of its proprietary or opensource, commercial or non-commercial nature(s) as long as it conforms to community rules and standards (i.e. that the app core must be opensource). The community will also host open-source projects developing wings (additional components) for various community supported (hence derived) application(s).
--- The community will provide services beyond those of Sourceforge or others in that is will provide a medium for purchasing (or receiving freely) software marketing solutions, including web development.
2. Legal aid: a wide array of licenses conforming to a community standard, each being well documented (in regards to what the license allows the original developer and the end-user etc.); clear-cut guidelines and site integrated procedures to maintain the rights of original solution developers (post your idea without worry of it being stolen) with the site itself serving to prove in a clear-cut manner which individual(s) were the original solution developers.
3. The community will have pre-existing arrangements with major software distributors (both retail and online) and will thus automatically open new markets to the developer(s).
4. FILL HERE <-- Feel free to contribute additional ideas of what facilities should be provided by the community.
The Opensource Impact Upon Security
"The security of a system can be directly examined instead of tested via exhaustive testing techniques."
Indeed, yet many would argue that opening up the source code of such systems makes it all the easier for virus writers and the like to produce malicious code which exploits the system for purposes damaging to the user, and hence to the developer.
------------------------------------------------------
TTFN, perhaps this discussion deserves a thread of its own, yes?
[ Edited Mon Feb 07 2005, 11:39AM ]
--macrocosm Mon Dec 20 20:24:37 2004
macrocosm Tue Dec 21 10:47:11 2004
| "Instead of designing modular and simple software that accomplishes very specific tasks using the best available methods, we design convoluted systems that attempt to solve all problems and confront all potential uses. These are monolithic solutions that are intrinsicly flawed, the drive to apply to the greatest number of problems directly conflicting with ease of use, stability, and most importantly, self-consistency." |
| -- Sunny |
I believe it is possible for an application to address a wide array of possible user situations/problems without entering the realm of bloat. I conceive of applications which are cleanly unified collections of highly quality, straightforward components.
I believe my conceived framework addresses this via encouraging and facilitating adherance to the principle of:
To each according to his/her abilities.
In this manner, we can _attempt_ "to solve all problems and confront all potential uses", only that each aspect thereof is only confronted by the appropriate individuals and groups (those whom have the respective specialization and thus the needed talents). Then, each component of a greater structure being developed by the respective specialists, all the components are brought together into the super-structure with ease due to the enforcement of consistency via universally recognized standards. Standards act to unsure that only materials which can be glued together (which bond with each other) are used by all developers/specialists, and it is thereby easy to unify a collection of high quality components into a high quality whole which addresses a number of user problems, and is applicable to a number of user situations (provides a multitude of user experiences).
We can achieve via this method the best of both worlds (quantity and quality). Quantity is not a necessary evil, but instead often a necessary good (only) when accompanied by quality--- such is a macro-level perspective.
--macrocosm Tue Dec 21 10:47:11 2004
