Markus Voelter independent/itemis [email protected]www.voelter.de @markusvoelter Bernd Kolb itemis [email protected]www.itemis.de @berndkolb Language-Oriented siness Applicatio n the way to DSLs for non-programme Jos Warmer OpenModeling Jos.warmer@openmodeling. nl openmodeling.nl
Traditionally, DSLs have been targeted at "specialized programmers" or at least at people with a strong technical background such as engineers, mathematicians or scientists. However, DSLs can also be very useful for people who work in fields that are less technical, and more on the business side of the universe.
In this session we discuss our experiences in building DSLs for business people, i.e. non-IT people who know their respective domain well. These people are not necessarily experienced in structured (or even formal) representation of their expert knowledge, and might not even be experts in computer usage.
Over the last few years, Markus, Jos & Bernd have gained some valuable experience into the kinds of domains, people, languages, and notations that make this approach feasible. It turns out that the requirements for DSLs and the tools used can be quite different for business users. The goal of this session is to present this experience and start a discussion about how to move the field forward.
The experiences are taken from Bernd's and Markus's work with Intentional and Achmea Insurance, Jos's work for an insurance company in Porto, and Markus's and Bernd's work on the requirements language in mbeddr.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
What makes a business user feel like a programmer???
LOBA: IT versus BusinessStructured or Free-form
Programmers dislike structure.• Prefer plain text and a parser to tell them what
is wrong• Copy-paste: Manually try to select semantically
meaningfull pieces of text like e.g. a variable declaration, an if statement, a condition in an if, one or more method parameters, etc.
LOBA: IT versus BusinessStructured or Free-form
Business People like structure.• Structured editing can only create correct input• Copy-paste selects semantically meaningfull
pieces automatically
You would expect otherwise: IT people are formally trained compared to business people, so expectation is the other way
around.
LOBA: IT versus BusinessText versus „anything else“
Programmers prefer text over everything• Diagrams: remember UML bashing ?• „real programmers don‘t draw pictures“• Programmers like tables in HTML, XML, Wikis,
but why have them in code?
Even for tables, where text is clearly totally unsuitable !
LOBA: IT versus BusinessText versus „anything else“
Business People like many notations• Diagrams, Tables, Mathematical Formulas,
Trees, Text, etc. • ... and combine them !
Business people feel restricted if they nhave to use a notation
that is not suitable for what they want to express.
LOBA: IT versus BusinessClean Sheets vs. Scaffolding
Programmers like clean sheets• Who needs guidance anyway?• It‘s beneath a developer to need any help !
Nobody tells me what to do!It hinders my artistic freedom!
LOBA: IT versus BusinessClean Sheets vs. Scaffolding
Business People like scaffolding• Clean sheet is confusing• Prefer guidance on what can/should be done.• What am I supposed to do with an empty page?• Forms are nice, they tell me what to do and
where to put what
Why remember if the computer can tell you what to do ?
And where to do it !
LOBA: IT versus BusinessLayout
Programmers do their own layout• Even getting developers to use the same
formatter with the same configuration turns out to be really hard.
• I‘ve been told quite often to not even try that.
Why is it so important that my IF statement looks different from the IF statement of my
collegue programmer?
LOBA: IT versus BusinessLayout
Business People prefer stanardized layout• Prefer layout of similar things to be identical• Is always recognizable• Don‘t want to waste time on doing manual
layout
Do developers really like to waste time ? Why ?
LOBA: IT versus BusinessViewpoints
Programmers use one notation and view• Use folding, but still see the folded element.• Use design techniques to decompose aspects
I want to see everything that is there, cannot afford to miss anything
LOBA: IT versus BusinessViewpoints
Business People use diverse notations and views• Different viewpoints, e.g. textual and visual• Only show information needed for a task, hide
parts of the model
I only want to see what I need, no less, no more.
LOBA: IT versus BusinessSumming Up
All these differences mean that the requirements for business oriented DSL‘s are very different from what we have learned about DSL‘s for
developers
(which is most DSL‘s we have today)
LOBA: IT versus BusinessSumming Up
Combine the best of Applications/Forms/UIs
and Languages and IDEs.
LOBA: Why[Motivation] Languages!
Applications/Forms/UIs
StructureUser GuidanceTablesViews
Languages + IDEsExpressionsComplex StructuresCode CompletionType CheckingDebuggingRefactoring
vs.
6LOBA where we are
what is missing
why
LOBA: Where we are.[Notation] Math (old)
LOBA: Where we are.[Notation] Math (new) I
LOBA: Where we are.[Notation] Math (new) II
LOBA: Where we are.[Notation] Tables
LOBA: Where we are.[Notation] Tables II
LOBA: Where we are.[Notation] Graphical
LOBA: Where we are.[Notation] Mixed Content
LOBA: Where we are.[Guided Editing] Form-Like
LOBA: Where we are.[Guided Editing] Form-Like
LOBA: Where we are.[Guided Editing] Form-Like II
LOBA: Where we are.[Guided Editing] Editor Buttons
LOBA: Where we are.[Guided Editing] Code Completion
Business Apps[Context Aware] Different Projections
Business Apps[Context Aware] Different Projections
LOBA: Where we are.[Structure] Tree Views I
LOBA: Where we are.[Structure] Tree Views II
LOBA: Where we are.[Context Aware] Visualization
LOBA: Where we are.[Context Aware] Visualization II
LOBA: Where we are.[Live Code] Error Checking
LOBA: Where we are.[Live Code] Interpreted Tests
LOBA: Where we are.[Live Code] Debugging
„End User NeedData is King!
“End-Users want to essentially operate on data.
Prof. Dr. Florian MatthesSoftware Engineering for Business Information System
TU Munich
„End User NeedData is King!
“End-Users want to essentially operate on data.
Prof. Dr. Florian MatthesSoftware Engineering for Business Information System
Language WorkbenchesWhere does App Funtionality go?
DebuggingLive Tests in IDEAdvanced AnalysesExecition via Generation
LOBAWhat is the Scope?
not the mass data – this remains in
databases.
Complex structures, calculations, rules or analyses
at the heart of a business domain.
6LOBA where we are
what is missing
why
LOBA: What is missing/ChallengesApparent Tool Complexity
Too many (too big)menus and buttons
LOBA: What is missing/ChallengesNeed for Simplified Version Control
Too many options.Locking?Realtime?
LOBA: What is missing/ChallengesSome Shortcomings in MPS
Adressed by JetBrains in 2014.
Cross-model generationProjection of computed collectionsBetter Graphical EditingType System PerformanceSome Editor Usability
LOBA: What is missing/ChallengesTraining
Users may not be used to this approach.Training is important.Productivity more useful than Learnability.
LOBA: What is missing/ChallengesSE Best PracticesModularity, Reuse, Injeritance, ...Users may not know
about thesethings, but they may still be necessaryfor efficiency reasons.
7Evaluation
EvaluationUsability Guru Jakon Nielsen
10 Usability Heuristics for UI Design
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Visibility of system statusThe system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Program is always visibleRealtime Type CheckingScaffolding
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Match between system and the real worldThe system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
EvaluationJ. Nielsen: Usability Heuristics for UI Design
User control and freedomUsers often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Undo/RedoRevert in Version Control
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Consistency and standardsUsers should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Consistent IDEAll languages „work“ the sameDesign unambiguous syntax
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Error preventionEven better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
Language Structure/ConstraintsScaffolding
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Recognition rather than recallMinimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Non-ModalityCC, Intentions, Menus
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Flexibility and efficiency of useAccelerators – unseen by the novice user – may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Aesthetic and minimalist designDialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Multiple Projections/ViewsIntentions, Quick Fixes, etc.
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Help users recognize, diagnose, and recover from errorsError messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Up to the language designer.Quick Fixes
EvaluationJ. Nielsen: Usability Heuristics for UI Design
Help and documentationEven though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
Up to the language designer.
8Conclusions
Conclusions
Applications „hide“ LanguagesNo Explicit Tool Support for them