Thoughts on Requirements and
Design of User Interfaces for
Proof Assistants
Norbert Völker
University of Essex, England
Background

Personal dissatisfaction




Toyed with idea of own UI project



Happy Isabelle/HOL hacker
Isabelle/Isar requires a user interface
ProofGeneral is a fantastic achievement but
still far from ideal
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


Generic UIs



more reuse
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 autocompletion
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?!



Theory specification


enhanced editor similar to ProofGeneral?!
Interactive proof


attractive: XML/XSLT, MathML, hyperlinks
requires updating of XML documents
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?


Output formatting?


generate RPCs? XML encoding?
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 welldocumented 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