Automated home: Applying Interaction Design on DSLs
In my previous posts I have given an impression of the current situation (how the hardware is connected, which software I use). It is very tempting to dig into hardware and software details now, but during previous experiences with designing DSLs I learned that this will be the wrong way.
During my Master’s thesis a few years ago I did an investigation at one of Netherlands major insurance companies. During this investigation, I designed a number of DSLs for the domain of medical statements. I did this in cooperation with domain experts. The methods I used were very promising.
One of the methods I was inspired by is Interaction Design. A lot of papers and articles about designing DSLs will start with an analysis of the problem solution domain by discussing complete hardware designs and software architectures (including some of my own). However, I decided to have a look at the how medical statements were defined by medical advisors, evaluated by legal advisors and implemented by software developers. This resulted in a totally different design as I primarily had in mind. I also believe that the methods I used will create more efficient DSLs that will really decrease the time needed per project phase because it covers the most relevant business logic while representing the language of the business. Thereby, the created models can even be used to validate requirements with domain experts saving valuable time on writing documentation.
For my home automation system, I will apply these successful methods as well. With the only exception, that the group of volunteers who can act as domain experts will be smaller this time. The next step will be to form a list of personas that will have an important part in the process of designing and using this system.
The personas are:
- Residents of the automated home (e.g. a family with kids or elderly people)
- Owner or maintainer of the home automation system (normally the person in house who also configures the thermostat and television set)
- The installer of the home automation system (might be a small company or the owner self)
- Equipment manufacturers who want to make their equipment compatible with my home automation system
- Hobbyists who want to create their own hardware for the system
- Hobbyists who want to add existing (not by the manufacturer supported) hardware to the system
- Manufacturers, retailers and hobbyists who want to design their own user interfaces for the system
In short (when writing an article about my project, I will give more details);
- The average residents just like to have an overview of the system, e.g. knowing where which equipment is located. They will not design their own system but at most define some simple macros.
- The installer of the system wants to be able to configure the system, e.g. how everything will be connected. They will also need the possibility to make some adjustments to the user interface and define some more complex macros.
- Equipment manufacturers and hobbyists who want to make their hardware compatible with the system need to create a software add-in. They need to be able to define what the capabilities of the hardware are, how they can be configured and implement the communication protocols. In the case of hardware that still has to be developed, the communication protocols might be even in scope for the design.
- Finally, some manufacturers, retailers and hobbyists might give their own touch and feel to the system by designing their own user interfaces.
These are a number of personas I have identified so far. For the first phase of my project I would like to limit my scope to the device side because without having them connected, other parts like customizable user interfaces will be useless. In one of my next blog posts I will show an initial design of my first DSL.
Recommendation for reading:
- Alan Cooper. The Inmates Are Running the Asylum.