Thoughts on Requirements and Design of User Interfaces for Proof Assistants

Norbert VölkerUniversity of Essex, England

Background

Personal dissatisfaction Happy Isabelle/HOL hacker Isabelle/Isar requires a user interface ProofGeneral is a fantastic

achievement but still far from ideal Toyed with idea of own UI project

Observations Interested in collaborations

Thanks to the anonymous referee

Overview

Towards Generic UIs A case for requirements elicitation Human-computer interface issues Architectural and system design

issues

Generic UIs

Community needs to use its sparse resources more efficiently more reuse

Generic UIs separation of UI and proof assistant find requirements by identifying

common features of proof assistant interaction

Generic components

Proof Assistant Interaction:Common Features

Projects Hierarchical sections (“theories”, …) Logical context: constants, axioms,

types, sorts; proven theorems Extra-logical context: configuration

of parsers, proof tools, display options, …

Persistence mechanism saving and loading of projects/sections

Generic Proof Interaction

Pose a formula (“main goal”) Proof steps: user issues proof

commands that change the proof state Proof commands refer to proof tools,

theorems, subgoals, subterms, … Proof state contains open goals and

local declarations and assumptions Proof ends when no open goals left or

abort Proof attempts can possibly be nested

Towards Generic UIs

Generic user interfaces for families of proof assistants are feasible ProofGeneral

Even if you are building a UI for a specific proof assistant, try and stay as generic as possible in order to aid reuse build to well documented interfaces!

Overview

Towards Generic UIs A case for requirements

elicitation Human-computer interface issues Architectural and system design

issues

A Case for Requirements Elicitation

Academic projects do seem to lack in requirements elicitation

Suggestion use case analysis object identification

Again, try to stay generic

Use Case Analysis

Each use case abstracts over a set of user-system interactions (“scenarios”) that are performed in pursuit of a certain aim.

Examples Adding a constant to a theory Backward proof (Re)Load a theory …

A Use Case Template [Larman]

Title of Use Case: … Actors: … Preconditions: … Postconditions (Successful Outcome):

… Main Success Scenario: … Alternative flows: Special Requirements: … Open Issues: …

Title of Use Case: Add a constant to a theory

Actors: Specifier

Preconditions: System in top-level or theory mode

Postconditions (Successful Outcome): constant has been added to the theory

Main Success Scenario:

1. Specifier requests “Add constant”

2. System responds with a list of theories for current project

3. Specifier selects a theory

4. System responds with a list of constants already declared in theory and a form for entering the new constants

4. Specifier enters the constant details and submits the form

5. System adds constant to theory

6. The success of the operation is indicated by a status message in the UI

Alternative flows:

1-3a. In theory mode, the specifier can also request “Add constant to current theory”. In this case steps 2 and 3 are omitted.

3b/5a. The specifier can cancel the process by selecting a “cancel” option.

4 b. If the specifier denotes the theory by string input, then the system checks …

Special Requirements: All text input forms should allow copy-and-paste and support auto-completion

Open Issues: Should there be a syntax-directed editor for input of the constant definition?

Domain Object Identification

Starting point: nouns in documentation such as use cases, manuals, etc project, theory, theory hierarchy, child

theory, parent theory logical context, logical basis, extra-logical

context axiom, theorem formula, term, constant, type, sort proof, goal, main goal, proof step, proof

command, proof state, open goal, …

A Structured Approach to Finding Use Cases

Generic operations creation of objects modification of objects inspection of the state of objects making objects persistent deletion of objects

Example “theorem” object: create, rename, edit a proof, modify

goal and rerun proof, inspect, save, delete, …

The Role of Use Case Analysis

Identify interactions that the system needs to support (efficiently, unit)

Describe key use cases in detail Good starting point for UI design,

testing and user documentation Valuable in practice despite criticism Stress user-point of view

balance prover-functionality driven development

Overview

Towards Generic UIs A case for requirements elicitation Human-computer interface

issues Architectural and system design

issues

Principle of Least Effort

Context-sensitive auto-completion Menus

only possible choices recent used/frequently used/rarely

used sections Suitable default values whenever a

choice has to be made Reuse of previous inputs

Graphical Interaction Hypertext can link information and actions

theorems to proofs or to similar theorems linking a constant in a goal to its definition clicking unknown opens instantiation

dialogue Drag-and drop for container operations

move a theorem between theories build a theorem query from constants assemble theorem sets for proof tools

Proof by Pointing

Generation of proof scripts from a “clicked proof”

Forward reasoning from goal premises via a theorem (“destruct”/ “elim”)

Backward reasoning by resolution from goal via a theorem

Apply assumption rule Possible brittleness of proofs

positional versus pattern identification

Textual Interaction

Typing a short name versus selection from long lists or via several submenus

Large proof trees can be difficult to use

Tougher interface might lead to better planning of proofs/ proof procedures

UI should support both graphical and textual interaction

Customisation by Users

Adaptation of menus, menu items, tool bars, keyboard short cuts, etc

Adaptation of formatting proof assistant outputs and UI elements fonts, font sizes, window sizes,

colouring, pretty printer settings, … mode dependent

Project level/ theory level/ proof level Recognized as a regular use case

Overview

Towards Generic UIs A case for requirements elicitation Human-computer interface issues Architectural and system

design issues

Basic Architecture

Paradigm: control centre with pluggable components similar to IDEs

Assume separate UI possibly distributed, heterogeneous

UI subsystems corresponding to roles theory specification interactive proof context (extra/logical) inspection proof tool development

UI Subsystem Ideas

Inspection: use standard web browser?! attractive: XML/XSLT, MathML, hyperlinks requires updating of XML documents

Theory specification enhanced editor similar to ProofGeneral?!

Interactive proof proof by pointing component?!

Proof tool development IDE?

Paradigm Change

Goodbye monolithic proof assistant Welcome platform

prover provides a logical deduction service

Support concurrency? concurrent access theorem databases? dependency: theory modifications? security? fault-tolerance: orphaned processes, …

Allocation of Responsibility between UI and Prover

Clear for most tasks Basic validation of user inputs in UI Parsing of user commands?

generate RPCs? XML encoding? Output formatting?

XML/XSLT transformation in UI? What does the UI need to know?

Proof assistant state replication? Simplicity versus performance gain

Component Frameworks?

Do we need facilities offered by frameworks such as .NET or CORBA? registries and dynamic binding? transaction support? persistence support?

Suggestion: keep it simple Java UI: encapsulate processes Loose coupling: (XML) messaging

XML Protocol Thoughts

Message vocabulary and sequencing Semantic rather than presentation oriented Support for coarse-grained concurrency

process a theory If possible, orthogonal to standards like

MathML Extensible Common core independent of proof

assistant and of user interfaces!

Components and Adaptability

Components only work with well-documented interfaces!

Integration of complex components will always require custom adaptation

Simpler components such as XSLT input/output filters could be pluggable

User interface should be extensively adaptable using configuration files Example: Mozilla XUL

Conclusions

Encourage generic UIs User oriented requirements elicitation Scope for HCI improvement

least effort, hyperlinks, drag-and-drop, proof by pointing, text interaction

Separate UI raises architectural issues platform architecture, components, web

browsers, concurrency, XML protocols Proof assistants need effective UIs