In this discussion I introduce a new OR/MS concept which I believe will play a major role in OR/MS early in the 21st Century. I call it OR/MS User Interfaces. This concept is intimately related to a number of established OR/MS fields, in particular, Decision Support Systems (DSS), Management Information Systems (MIS), Expert Systems (ES) and Mathematical Modelling Languages (MML). It is supposed to deal with issues involved with the implementation of OR/MS methods, techniques, tools, ideas, etc on computers, more specifically, it is concerned with the User Interface of such implementations. Broadly speaking then, it deals with computer systems designed to support the traditional "input/modelling/analysis/solution/output/input..." cycle that is often used to describe the basic structure of OR/MS investigations. As is usually the case in such circumstances, because this field resides on the border between a number of existing OR/MS fields, it has been neglected by all.
In this discussion I propose that this concept should be recognised for what it is, and be treated as a sovereign entity. Furthermore, I submit that in the beginning of the 21st Century it will play a key role in all aspects of OR/MS, namely in education, training, research, practice, as well as interaction with other disciplines.
What I wish to discuss here are some of my thoughts on this new concept as well as what kind of things I think should be done to promote it. But first, I have to explain what I mean by an OR/MS User Interfaces. And the best thing to do in this regard is to begin by saying what I do not want it to mean or to become. So read my lips: I do not want it to become a new buzz word that abstractly refers to all sort of items that you find on one's wish list, which together will somehow miraculously provide a friendly user interface for OR/MS software. I heard too many lectures on such ideas to know better. What I have in mind is something much simpler, namely the study, analysis, evaluation and usage of existing OR/MS User Interfaces. You will undoubtedly blame me for playing with words, and I shall not blame you for this. So let me explain.
In order to guarantee that the new OR/MS field that we call OR/MS User Interfaces will never become a buzz field, we shall anchor its constitution on three fundamental principles which will be strictly adhered to. The first is the good old Practice What You Preach Principle. So you see, we shall not deal with what types of user interfaces one could build in the future, but rather with what user interfaces are already available. The second principle is also old, perhaps even older than the first, and is much more philosophical in nature. It has many variations, but I prefer the one whose free English translation from the Hebrew origin reads as follows: Thou shall not do to others what you yourself hate. In other words, we shall not accept user interfaces just because they exist. We shall not even suggest that other people should use interfaces that we ourselves hate, just because these interfaces are available. We shall simply not tolerate interfaces that do not comply with the basic requirements that we shall eventually establish.
In contrast to these two old and proven principles, the third one is new and controversial: I phrase it like this: Do not abuse your indices! I shall have more to say about it shortly, for the time being just leave it alone. Now, pedagogically speaking, it would have been nice if at this point in the discussion I could have presented a number of illustrative examples, that is examples of typical OR/MS User Interfaces. The trouble is that there ain't none, or to be more specific, I am not familiar with any product in the market that claims to offer an OR/MS User Interfaces. This, by the way, is precisely why I decided to initiate this crusade in the first place! In other words folks, we start our journey towards the 21st Century with an empty knapsack. Hopefully, by the time we reach December 31, 1999, we shall have a couple of products in our bag. As I shall argue, though, the job of collecting these products will not be easy. But do not despair, yet!
2. What are we talking about ?!
The best way to explain what an OR/MS User Interfaces is, or rather will be, is
to tell you what kind of things prompted me to invent this concept in the first place. So
listen carefully to a true story. For obvious reasons I shall not provide all the details
concerning names of individuals, organisations and products.
It all started late in 1991 when I was happily married and minding my own business doing all sort of OR/MS things primarily in dynamic programming and composite concave programming. Then one morning I decided to develop a prototype computer package for a new optimization method that I had developed in the middle 1980's. What I needed for this particular project was a simple interface to an LP package, an interface that will give me easy access to certain features of the simplex method, features that are discussed in many undergraduate LP textbooks. At the time I had access to four commercial LP packages but none provided the facilities that I needed! I therefore decided to purchase another leading LP solver which had all the required features. But then I was advised by a number of colleagues that this solver did not have a good user interface. I was also advised that soon this leading LP solver would be linked to a famous user friendly front end.
In short, I happily purchased an integrated system consisting of the famous front end and the leading LP solver. But I soon discovered that the famous front end did not support the very features of the leading LP solver that I needed!! It took me just a bit longer to realise that the famous front end was not as friendly as I expected it to be in my project.
At this stage it was beginning to be late, so I had no choice but develop the package from scratch, including the LP solver and the user's front end, using a 4th generation interactive language which is known to be very good for prototyping. Luckily, I had two dedicated graduate students and a research grant to support this adventure. So the b-version of the package is now running, the user manual is ready, and despite the trauma, I am still happily married!!
Needless to say, during this period I had the opportunity to share my experience and frustration with colleagues who use LP packages for all sort of projects, and I was surprised to hear that they had experienced similar nightmares. This is the end of the story.
When I try to reconstruct the chain of events that ultimately led me to initiate OR/MS User Interface crusade I can clearly identify two milestones. The first goes back to the middle nineteen eighties, when DSS experts told us about all the nice things that they planned to do. I observed that it could be very useful if they could develop decision support systems not only for non-OR/MS analysts, but also for OR/MS specialists. But I soon realised that this will never happen. This is when I first introduced the Practice What You Preach Principle and I have used it ever since. The second event took place sometime in 1990 when I conducted my first experiments with MATHEMATICA. Although I concluded at the time that MATHEMATICA was not suitable for my type of OR/MS work, I asked myself the following naive question: why don't we have a similar system, call it something like ORMSATICA, designed specifically for OR/MS analysts? I raised this possibility at several occasions and discovered that some of my colleagues were very interested in using such a product. This is when I started thinking seriously about OR/MS User interfaces.
With regard to the Stop Abusing Your Indices! Principle, it was imposed on me in 1978 when I started experimenting with APL. I soon discovered that many of the difficulties that we experience in OR/MS modelling on computers are caused by the tendency to use conventional computer programming concepts rather than mathematical concepts.
Having said this, I still have to explain what actually triggered me to write this very article and initiate the OR/MS User Interface Crusade. This is a simple task for I have merely to mention the fact that I decided sometime ago to develop a number of OR/MS computer packages. But you see, I am not a professional programmer and I do not have the resources to employ professional programmers to do the job. I must add in this regard that I know for a fact that many of my colleagues have similar problems transforming "theories" and "ideas" into useful computer products. So as far as I am concerned, the best solution to this dilemma is simple and straight forward: encourage professional software developers to design and develop, in cooperation with OR/MS specialists, OR/MS User Interfaces of the type outlined in this discussion.
When I decided to do something about the dilemma described above, I discovered that the closest things that OR/MS provides at present to OR/MS User Interfaces are a number of mathematical programming/modelling languages designed primarily for LP problems. Upon examining some of these languages a bit closer I realised that they alone will never provide the type of environment that I had in mind. This conclusion soon suggested the introduction of a new concept, namely OR/MS User Interfaces.
Obviously, a typical OR/MS User interfaces will include a mathematical programming language of some sort, but not of the type currently available in OR/MS. What we need is something much more powerful and much more user friendly. This remark immediately raises the following question:
3. What is wrong with OR/MS mathematical programming
languages?
There is nothing fundamentally wrong with the leading OR/MS mathematical
programming /modelling languages in that they are doing more or less what they were
designed to do. The trouble is that they were not designed to do much, and in this
respect the facilities that they provide for OR/MS analysts are extremely limited. As
this is neither the time nor the place for a critical evaluation of these languages I shall
say only few words on this sensitive topic, focusing on three important aspects
namely data structures, operations, and default values.
So consider again the traditional input-modelling-analysis-solution-output-input cycle and think about the data structures that we use in this framework when we do our work on paper, or in our minds. We typically think about multi-dimensional arrays, sets, tableaux, trees, graphs, networks, queues, etc. Therefore, any computer programming environment designed to support us in our daily OR/MS work should, in principle, support data structures of these types. For the purposes of this discussion suffice it to ask the rhetorical question: what kind of support do our mathematical/modelling languages provide in this framework?
The situation is not better, in fact much worse, with regard to operations. Think about what kinds of operations we use in our daily OR/MS work when we deal with the data structures mentioned above. Then ask yourself the inevitable question: How many of these generic operations are supported by our mathematical programming/modelling languages? I ask this question because there are no technological reasons why a computing programming environment designed for OR/MS specialists should not support operations such as pivoting, ratio-test, simplex etc for the treatment of linear programming problems as "primitive" operations, namely as operations provided by the system. Similarly, there is no reason why such a language should not offer "primitive" operations for dealing with networks, graphs, and trees. Needless to say such a language will also offer user friendly facilities for creating and editing such data structures, and constructing user-defined operations on these structures.
With regard to default values, suffice it to say that a lot of progress have been made in recent years with regard to what is known as pre- processing and classification of OR/MS problems. It is only natural to incorporate this technology in computing environment designed for OR/MS specialists. Such an environment will have the capabilities to determine "reasonable" default values for certain objects of the OR/MS model/algorithm, thus making the analyst life much simpler. Needless to say, facilities should also be available to override these default values. For example, a user may instruct the system to solve a LP problem without specifying what algorithm/method should be use for this purpose. The choice of algorithm/method will be made by the system itself. Alternatively, a user may instruct the system to solve a LP problem by a given algorithm/method. There are other important issues that will have to be dealt with by OR/MS programming/ modelling languages. For example, such languages will have to provide special facilities for prototyping, namely facilities to support a "quick and dirty" approach to problem solving on computers.
In short, a typical OR/MS User Interfaces will provide an integrated computer system where all kinds of general purpose utilities such as word processing, graphics, data bases, problem libraries, bibliography, and so on, will happily reside together with a powerful OR/MS programming/modelling language. This is what I mean by OR/MS User Interfaces. The key observation here is that existing OR/MS oriented mathematical modelling/programming languages do not address the basic issues involved with the development and design of such systems.
Now, I know that it will not be possible to develop such systems overnight. But I also know that we already have all the technologies needed to develop something like this. It is just a matter of doing it.
And on this happy note let us return to our three foundational principles. The two good old ones, and the new controversial one.
4. The Principles
For obvious reasons we shall say little about the first two principles. They are so
obvious and intuitive that only few words are necessary. We shall therefore focus
on the third.
4.1 Practice what you preach! This is an excellent principle. I wish we had used it in other areas of OR/MS as well. As far as the new field OR/MS User Interfaces is concerned, this principle should be strictly observed, practiced, and enforced. Needless to say, we shall be delighted to hear about what people plan to do in this area, about proposals that people have for other people working in this are, and so on. But these will only be of secondary importance. The main aim and purpose of this new field is the study, analysis, evaluation and usage of existing products, namely existing OR/MS User Interfaces. In other words, the emphasis is going to be on actual products, not on what kind of wonderful products one could design in the future based on suggestions, promises, hypotheses, propositions, and lemmas. Even theorems will not be accepted on their own merit! On the other hand, we shall encourage the study, examination, and even development of non-orthodox experimental OR/MS User Interfaces.
And here is where the challenge lies: For many years we have heard our DSS and ES colleagues talk about all the beautiful things that their theories, theorems and technologies can do for other people, namely for non-OR/MS specialists, who wish to use OR/MS methods. So how about developing OR/MS User Interfaces based on DSS and ES principles and ideas? But please, this time no promises, no lemmas, no hypotheses, etc - we want to see real products, products that we can touch, smell, hear, see and use (and infrequently abuse). We want to see products that will provide - for OR/MS specialists - user friendly computer systems for experimentation with OR/MS methods, development of OR/MS algorithms, solving OR/MS problems, teaching OR/MS subjects, etc.
I am not familiar with one single existing product of this nature, and as things go now, I don't think that such a product will be available in the near future, namely before December 31, 1999. In fact, I am not even sure that OR/MS is ready at present to begin seriously thinking about developing such products. Each of us seems to be too busy trying to cope with her/his favourite domain(s), thus leaving the job of taking care of the "whole picture" to other people. The trouble is that there ain't no other people!! What we shall not do in this area will not be done by others for us. So in short, we shall have to practice what we preach.
4.2 Thou Shall Not Do To Others What You Yourself Hate! This is the principle that we shall attempt to impose on designers and developers of OR/MS User Interfaces. The point is this: there are today many general purpose facilities that can be used very effectively in the construction of OR/MS User interfaces. They were not designed by OR/MS specialists, and they are currently used by other professionals and even non-professionals. Perhaps the best example is the beloved Spreadsheet. This tool is widely available and it is up to us to utilise it to our advantage in the development of OR/MS User Interfaces. I cannot imagine an OR/MS user interfaces without some sort of spreadsheet-like facilities. Similarly, I cannot imagine an OR/MS user interfaces without some sort of word processing facilities. Needless to say, we shall need some graphics facilities as well.
Observe that these facilities do not have to be part of the OR/MS software itself, rather they can, perhaps should, be part of the host environment. For example, in the case of word processing, one could use say Word for Windows as a report generator, simply by using a number of macros developed for specific OR/MS applications, eg. linear programming. But perhaps most importantly, we shall need a powerful, mathematically oriented, OR/MS programming/ modelling language.
So given that out there spreadsheets, word processors, graphics facilities, databases, and so on are used routinely by practically everyone, we shall insist that they be offered as standard features in OR/MS User Interfaces. We shall insist that designers and developers of OR/MS User Interfaces will sign declarations confirming that they actually like the features provided by their products and that they do not like features that they do not provided in their products. It would be very interesting to see, for example, a designer of a LP User Interface declaring in public that she does not like a spreadsheet-type input facility for small LP problems, but rather prefers to edit a MPS file instead.
Similarly, it would be most amusing to hear an OR/MS software developer declaring in public that such concepts as inner products, outer products, matrix multiplication, scalar functions, nested arrays, and so on, are not useful in linear programming modelling and therefore it is better and more efficient to use low level index notation to describe standard array operations associated with LP modelling. Likewise, it would be most entertaining to hear an OR/MS software developer arguing that it is not a good idea to incorporate functional programming features in a a general purpose mathematical modelling/programming language for OR/MS.
In short, this principle will be used to put pressure on developers of MS/OR software to make sure that their products are as good and friendly as products that they themselves like using.
4.3 Do Not Abuse Your Indices! This is an interesting principle. It is the result of a long and in-depth analysis of a number of OR/MS software packages. I suggest that designers and developers of OR/MS User Interfaces should give it serious considerations in their future work.
It is intended to point at an apparently very common phenomenon where certain small and relatively minor components of a large system are abused because of basic design flaws. A similar and well familiar situation is where we use a simple tool to do all sort of things that the tool was really not designed for. Most of us are well aware of what kinds of terrible abuses are routinely inflicted all over the world on medium size screw drivers by persons who do not have the right tools in their garages.
Of course, it is absolutely essential that we appreciate the time factor here. Namely, it is essential that we keep pace with the technology surrounding us. Certain tools that were invented say, 25 years ago, to do a certain job and have done the job happily ever since, may complain that they are now abused because much younger, better tools are available at present for this purpose. We should let such tools retire with dignity! Conversely, this principle will guard us against the introduction of new tools just because they are new and fashionable in certain quarters. We shall resist the temptation to replace old tools that are still functioning well by new tools that are not functioning as well.
In short, the mission of this principle is to guarantee that our OR/MS User Interfaces will use the proper technology for the job, be they old or young.
With regard to the choice of indices as representatives of the community of abused OR/MS tools, the reasons are personal in nature. I should stress that although I appreciate the important role that these tiny loyal creatures play not only in OR/MS but in mathematics in general, I do not particularly like them. In fact, I am inclined to user other tools whenever possible. Nevertheless, on many occasions I have witnessed how these little darlings have been abused by OR/MS specialists because of lack of proper modelling tools. Being the sensitive person I am, I have decided that enough is enough! I am now fully committed to their cause. So as long as I am actively involved in the new field OR/MS User Interfaces, I shall try to enforce this principle. We shall simple not allow the torture to continue.
5. What's Next?
As I already indicated at the outset, unfortunately our bag of OR/MS User
Interfaces is basically empty at present and will remain so for some time. So it is
only natural under the circumstances to lower our expectations a bit and consider
something not as impressive, not as glamorous, yet something significant, important
and challenging, and most importantly, something that we can accomplish. What I
have in mind is user interfaces for specific domains of OR/MS.
But what specific domain(s) of OR/MS should be chosen for this purpose?
Fortunately, the following well known result indicates in no uncertain terms what one
of these domains should be:
The choice of a second domain is a bit more difficult, but just a tiny bit. In any case, my personal choice is branch and bound. I shall attempt to justify this choice.
5.1 Towards LP User Interfaces
There has been tremendous progress over the last thirty years in the manner in
which we use computers to solve LP problems. Indeed, this progress has
contributed a lot to spreading the gospel of not only LP but OR/MS as well. So much
so that in many respects the Fundamental Theorem owes its validity to this aspect of
LP.
Indeed, if we examine the LP technology that is available at present and compare it to the technology that was available, say 30 years ago, we should be quite impressed with the progress made in the user interface. But impressed as we are with this progress, we should not lose sight of what is happening all around us. Future generations of OR/MS persons, say in the year 2050, will not assess us so much in terms of what has been happening in our own small OR/MS Universe, but rather will take a more global view of the situation.
For example, when assessing mathematical modelling/processing packages that we use at present in LP they may use packages such as MATHEMATICA and MATLAB and such languages as APL and J as benchmarks in deciding to what extent OR/MS specialists in the 1990's made full use the mathematical modelling/programming technologies that were available at the time. And if this is what they will do, I regret to say that they will not be impressed, but rather puzzled by some of the basic concepts underlying these mathematical modelling/programming languages and their implementations.
From our own perspective, these packages cannot be regarded as genuine LP User Interfaces and I do not think that anyone will argue, even the developers themselves, that they are. These then are mathematical modelling/programming languages not LP User Interfaces. This, needless to say, should not detract one iota from their important contribution to LP and OR/MS, no more than that by saying that Placido Domingo is not a genuine soprano we detract from Mr Domingo's stature as a world class tenor (baritone ?).
On the other hand, we have to appreciate the fact that at present these are the closest things that we have to genuine LP User Interfaces. And for this reason it will be instructive to examine how they fare against our principles. So let us apply these principles on these languages.
Obviously, all these products comply with our first principle by their mere existence. As far as the second principle is concerned, we detect numerous violations. The interface that existing LP oriented mathematical modelling/ programming languages provide for handling small LP problems is not user friendly at all; usually there is no spreadsheet-like editor on board; no graphical facilities are available, the on-line editing facilities are minimal; there are rarely any GUI facilities; they even do not support all the important features of the SIMPLEX method eg. parametric analysis; and so on. I should stress again, that this is not a criticism of them as mathematical modelling/programming systems, but rather an explanation of why they do not constitute LP User Interfaces of the type required by the second principle.
As far as the third principle is concerned, the situation is even worse. To explain why, let us suppose that we evaluate the existing LP mathematical modelling /programming languages not as LP User Interfaces, but as mathematical modelling/ programming languages provided by an LP User Interfaces. Unfortunately, even in this case they will fail the test because of their serious violations of the third principle, namely because they abuse indices. For example, they do not support such useful and important operations as inner products, outer products, matrix multiplication, rotation, etc. The user is forced to torture the poor indices in order to perform such common tasks.
5.2 Towards BB User Interfaces
I am much more optimistic about the availability of this type of interfaces still in the
20th
century than the LP ones. Unfortunately, the reasons for my optimism is not very
complementary to the OR/MS community. The simple fact of life is that a number of
experimental as well as commercial systems with substantial branch and bound
content are already available. However, they are not advertised as such, rather they
are marketed as Constraint Logic Programming systems. And in a
very subtle way they explicitly challenge OR/MS techniques. I must admit that they
really do an excellent job in this respect.
I do not want to elaborate on this sensitive issue in this discussion. Suffice it to say that the developers of packages based on Constraint Logic Programming methodologies give credit to the important role that branch and bound techniques play in the development of this relatively new field. Furthermore, it is clear that the next step in this field will be the incorporation of optimization techniques in the search process. Linear programming is of course a prime target. I understand that this process has already begun. Soon these packages will be capable of solving large scale, complex, integer programming problems.
This, I believe, is a most exciting development, for in many respects it challenges OR/MS specialists to come up with similar products. It would be interesting to see how the OR/MS community will respond to this challenge. In any case, as far as the field OR/MS User Interfaces is concerned, there are already a number of commercial and experimental products that we can examine. They are far from being perfect, but they indicate in a very clear manner what sort of OR/MS User Interfaces will be available in this area early in the 21st Century. What is left is to incorporate them in a friendly BB User Interface.
6. The Plans
The question is then: What can be done to insure that before December 31 1999 we
shall have a couple of genuine User Interfaces for specific domains of OR/MS?
I have a number of ideas with regard to this difficult task, but here I shall briefly
mention only three.
Plan #1: Attract non-OR/MS software developers to develop LP, BB and possibly other OR/MS User Interfaces .This plan merely suggests the obvious, namely it points out that because LP and BB have many potential users out there, some non-OR software developers may be interested in developing LP and BB User Interfaces. In fact, the potential market is so large, especially in education, that perhaps one could attract Mr. Bill Gates of Microsoft to develop a Windows based LP User Interfaces. In any case, I am confident that many software houses world-wide would be interested in cooperating with developers of LP solvers and mathematical modelling/programming languages in the development of LP and BB User Interfaces. I believe that OR/MS societies, eg. ORSA, TIMS and IFORS, should play an active part in facilitating and coordinating such a cooperation.
The situation is more difficult with regard to BB User Interfaces because BB does not have the glamour of LP. This is a pity because, as shown by Constraint Logic Programming, in many practical situations BB based software can offer a quick and elegant approach to problem solving by means of a simple-to-use modelling language. It is somewhat regrettable that the initiative in this important area was not originated in the OR/MS community. We have a lot to catch up with in this domain.
Plan #2: The International 20th Century OR/MS User Interface Award. I propose that OR/MS societies world-wide should establish a joint Award with the view to promote and facilitate the development of OR/MS User Interfaces before the end of the century. It should not be difficult to collect, say $US100,000 and more, from commercial organisations for such an award, nor should it be difficult to promote it as a significant milestone in the history of OR/MS. Consequently, I am confident that such an award will provide sufficient incentives to numerous individuals, groups, and organisations to participate in the competition. The thing is that to meet the December 31, 1999 deadline we have to begin immediately with the planning of all the logistics involved. As I indicated above, I believe that we have all the needed technologies for the development of LP and BB User Interfaces. But who knows, perhaps along the way we could also come up with something for DP, queueing theory, etc!
Plan #3. ISPIC
This plan is well under way. On November 17, 1993 I will officially announce the
establishment of a new society called ISPIC for Internatiomal Society for the
Prevention of Cruelty to Indices. Persons accepted as members will undertake to
immediately refrain from abusing indices in their OR/MS work, and to do the best they
can to promote the use of proper tools in OR/MS user interfaces. I shall be delighted
to send you more information about ISPIC, including membership application
forms.
7. Epilogue As computers are becoming standard tools for professionals and nonprofessionals alike, it is clear that the extent to which OR/MS technologies will be used by the "general public" would depend very much on the way these technologies will be packaged. Namely, the user interface will be a dominating factor in determining the level of usage of OR/MS technologies.
In the past, OR/MS software, eg. LP solvers, all but ignored this aspect of the over all system. Emphasis was given almost exclusively to speed and efficiency of the OR/MS algorithms. But as we know only too well, when we develop a user friendly OR/MS system, most of the effort is spent not on the OR/MS algorithms, but rather on the input/output interface. So while it is perhaps natural for OR/MS specialists to try to avoid dealing with these time consuming "non-OR/MS" issues, it must be understood that in fact they are as important as, perhaps even more important than, issues involved in making an OR/MS algorithm say, 5% faster. This is precisely why the solution to the OR/MS modelling issue is not likely to be resolved completely by this or that mathematical modelling/programming language. A complete modelling environment is required, an environment that we now call OR/MS User Interface.
Thus, the traditional attitude towards user interfaces in the OR/MS community must change. We must accept the fact that users of OR/MS technologies expect a complete product, a product that is as user friendly as other products available to them on the job. Consequently, we have to accept the fact that the task of developing user interfaces to OR/MS software packages is an integral part of OR/MS projects. And if for whatever reasons we cannot accomplish this job ourselves, it will be our professional responsibility to subcontract it to other professionals who can deliver the goods.
It must be appreciated that users out there take certain facilities for granted and therefore expect OR/MS products to use technologies that are elsewhere provided as standard equipment. For example, when I load a word processor, I expect to see on the screen tool bars with icons representiong familiar tools for word processing. When I load a graphics package, I expect to see a screen with a a tool bar full with familiar tools for drawing graphs. And when I load a spreadsheet, I expect to see a screen with a tool bar full with icons representing tools I often need when I work with spreadsheets.
It is clear therefore that OR/MS software designed for "naive users" must provide all the familiar features of "standard" user interfaces. We should not expect the general public to be satisfied with less than that. In this discussion I tried to draw attention to another type of users, namely OR/MS analysts, and the type of user interfaces that they expect to find while experimenting with OR/MS software.
So first let us create such a user. Suppose than that you give a crash introductory OR/MS course to an intelligent individual who never heard about OR/MS before, and then ask her: What do you expect to see on the screen of an OR/MS User Interface? Obviously, the answer would depend very much on the material covered in the course. So assume that the crash course covered most of the topics included in our undergraduate OR/MS textbooks. In this case the answer could be something like this:
I expect to see a screen with three tool bars showing all sort of OR/MS icons. One tool bar will contain icons related to modelling, namely problem formulation, one tool bar will show icons related to OR/MS algorithms, and one tool bar will include icons related to input/output activities. Of course, the Main Menu will have the familiar fields, ie. Help, Edit, File, Tools, etc.
What I have been trying to argue in this discussion is that when we evaluate the existing OR/MS software designed for OR/MS analysts, we have to examine it against expectations of this type. In any case, it is not very likely that our imaginary intelligent individual will be very pleased with the screens that she will see while experimenting with existing MS/OR software. For instance, in Figures 1-2 you can see screen dumps of two typical leading OR/MS front ends, where XXXX and ZZZZ replace the names of the products.
In short, if we want to see progress in this area we must adhere to our three foundational principles:
Comment:
Not much has changed in this area since Nov 17, 1993.