Attached is a proposal for a consistent user interface for command line programs. I'm sending this out to find out if the ARCs want to take this on. If you do, I want to schedule a review by a set of senior UI people before scheduling the SAC review. Please let me know ASAP whether the ARCs see this as something you are interested in. Robin J User Experience Office ---------- 1. Introduction 1.1. Project/Component Working Name: Standard Command Line Scheme 1.2. Name of Document Author/Supplier: David-John B 1.3. Date of This Document: 09/16/99 1.4. Name of Major Document Customer(s)/Consumer(s): SAC The Java Embedded Server(tm) product group. 2. Project Summary 2.1. Project Description Description of deliverable (or issue) and customer. Command line syntax and semantics differ significantly between command line utilities from Sun. This project is to define a command line interface standard that defines basic syntax and semantics to be used on all command line utilities. Though there are existing command line standards, none have support across all of Sun, and some offer only the most minimal levels of definition. The customer for this project would be potentially all designers, developers, and users of command line utilities at Sun. 2.2. Risks and Assumptions Note any risks, issues, or assumptions that must be considered along with the proposal. 1) There are existing products with command line interface schemes. Adopting this as a "standard" within sun would implicitly make them "non-standard". 2a) This project fundamentally assumes that it is desirable to have a consistent command line interface across utilities much as it is desirable to have a consistent graphical interface across applications (e.g. Microsoft Windows, CDE, etc). 2b) The assumption in 2a will introduce the risk that some utilities that conform to this proposal may contain less-than-optimal designs in order to conform to the consistency dictated by this proposal. This is an acceptable risk. 3. Business Summary 3.1. Problem Area What problem or customer need does this project solve? This solves the need of all command line users, both within and without Sun, to have easily learned and used command line utilities. 3.2. Market/Requester Who is the customer or client that needs the project? Include names or description of companies or groups outside Sun that want the project. The Sun HCI community, who often work on command line utilities and are looking for ways to make them more consistent. The Java Embedded Server product group is currently a customer of this proposal. Sun projects developing new command line utilities. 3.3. Business Justification Why is it important or valuable to do this project? Include monetary estimate and precision. Command line interfaces have a reputation for being opaque and difficult to use. While this is unavoidable to some degree, the situation is made far worse by allowing each command line utility define its own unique interface. There are existing standards to try to address this problem. however, they are often not as complete as this project's proposal, and none are clearly supported throughout Sun. Providing a cross-company standardized command line interface standard would make it less onerous for customers to learn and use our products. It would also make the efforts of documentation and testing groups within Sun easier, since it would significantly reduce the effort they must expend on documenting and testing the interfaces of new utilities. This, in turn, would benefit Sun in a manner similar to the way standardized GUI's have benefited Sun. Monetary estimates: - no significant incremental costs to new projects to adopt this. - unknown cost for existing project to retrofit (cost is probably small per project, but it's unclear how many projects should/will retrofit) - cost to create a library to support this: two person months for each implementation (assuming, for example, that there would be a library for Java developers which would be distinct from a library for C developers). 3.4. Competitive Analysis Who are the current and anticipated players in this market? How/why will we succeed when competing with them? Current and anticipated players are all manufacturers of command line utilities. By virtue of the problem that this is addressing, however, there are few players with a strong position. That is, since every utility is generally treated as a world-unto-itself, there are few organized bodies with competing 'standards'. This proposal "embraces and extends" one of the more common standards, which is expected to reduce the "competition" in that area. Within Sun, the former DevPro organization has a standard which applies to all their compilers. Other organizations may have their own internal standards (e.g. All DOS utilities from Microsoft perhaps work the same, all MPW utilities from Apple perhaps work the same). Rarely, however, are the rules involved in even these schemes well defined. As far as I know, none of the existing standards provide the level of automated processing that this proposal offers. That is, this proposal can be implemented once in each relevant programming language environment, and then re-used in all utilities. 3.5. Opportunity Window/Exposure Time-to-market window, if any, and precision. The sooner this adopted, the fewer non-compliant utilities there will be. 4. Technical Description This project is to define a specification. All the relevant resources exist within Sun, and an initial proposal for the standard already exists. Though not currently an inherent part of this project, providing implementations of this proposal is highly desirable. One such implementation exists in the Java programming language (Currently, it lives in the following package: com.jes.apps.cliutils) 5. Reference Documents Other written standards include: PSARC 1991/031 Sun Compiler Tools Group: docs/interfaces/flag-std/std.txt 6. Resources and Schedule 6.1. Projected Availability This will be available as soon as it has been reviewed by the HCI review board and the ARC. 6.2. Cost of Effort Order of magnitude people and time for the *whole* project. 2 person months. 6.3. Cost of Capital Resources Order of magnitude. None 7. Prototype Availability 7.1. Prototype Availability A draft exists now. 7.2. Prototype Cost The only cost involved is the costs of revisions after review by the HCI and SAC bodies. The number of such revisions is not known.