Posted by j.laird on 17 June 2021 - 10:00am

Summary of pros and cons of adding a GUI to research software

By Diego Alonso Álvarez, Senior RSE, Research Computing Service-ICT, Imperial College London.

This is the second part of this blog post, see the first part here.

The dark side of implementing a GUI

Not all is plain sailing when creating a GUI. There are also plenty of drawbacks that, in the end, boil down to time and money. It might be a daunting task, so the recommendation is the same as for other aspects of software development: start small. Do not try to make the perfect, ultimate GUI for your software from the beginning. Initially implement just a few features, those used by most users most of the time, and then grow it over time as its usefulness pays of and you get feedback from the users.

1. Time

This is the most obvious one and it is unavoidable: creating a GUI takes time - a lot of time if it is the first time you are trying to do so.

• Time translates to higher costs in the form of staff/student time, and involves not just development time of the GUI but also testing time and learning time of any new tools and techniques (see below).
• The net result is that it will take longer to have a minimum viable product ready to showcase to your clients, to present to potential collaborators or at a conference, or to include in a paper or PhD. You will need to plan ahead.

2. Complexity

A GUI is a different beast to traditional research software code and comes with a lot of challenges from the software engineering perspective.

• Implementing a GUI adds extra code to the existing code base, and that is code to provide tests for, that can have bugs that need to be sorted out, and that has external dependencies with its own issues.
• GUIs come with their own specialised software architectures and programming paradigms to keep separation of concerns, support multi-threaded/processing execution and user interaction. All of them need to integrate with each other seamlessly and can fail at any time if it is not done right.

3. New skills

As developing GUIs is very different to developing the usual research software, diving into it almost always requires learning a lot of new things, already hinted in the previous two drawbacks. As well as the time it takes, it is a lot of effort and cognitive burden to learn new skills.

• You will need to gain new coding skills. At the very least, you will need to learn how to use the GUI toolkit/framework you are choosing, but you might even need to learn a different programming language altogether. Very often, GUI toolkits use a declarative language for the definition of the layout and look & feel, separating them from the more imperative business logic, like QML for Qt, Kv for kivy or CSS and HTML for web apps (using JavaScript for the rest).
• Then, you will need to learn how apply those new coding skills, and that will require for you to gain knowledge on GUI-related software architectures, testing techniques for GUIs and new development paradigms, like event-driven programming.

4. Designer

If you are in a professional context - and can afford it - a designer will be essential to make the most of your software.

• Designers do not only know about art and colours: they know the psychology of users. They can define the appropriate layout to maximise efficiency when using the GUI based on existing standards and are familiar with accessibility issues of different types of users.
• Of course, they can bring to the table also good taste for creating a pleasant look and feel. They can deal wisely with the proportions and distribution of the widgets, and choose an appropriate combination of palettes of colours and fonts. Potentially, they might even be able to create custom logos and icons!

Knowing your users

This final section is actually the most important one: graphical user interfaces are there to serve the user. The user is the central point, so if you create a GUI that users are not happy with either you did it wrong or the software did not need a GUI to start with. To tackle both problems, you need to know your software, as discussed above, and the potential users of your software.

Users come in all shapes and sizes. They might be proficient developers, very comfortable coding and navigating the file system with the terminal. They might be students who have just started their MSc or PhD and don't have much experience with coding. They could be PIs with many people and grants to manage and negative time for anything that is not about getting immediate results. Your user might be yourself in a few years time after not using the software for a long while. Or they could be a family with children at a science fair.

There are whole degrees about user research and how to find out about users’ needs and the problem they are trying to solve. A good introduction for most of these techniques is Usability.gov. Now, most of them are oriented towards the web and the potentially enormous audience that they can reach. Research software often has a more niche pool of users, which favours one particular technique: ask them.

You should aim to find out:

• What they are trying to accomplish: The same software could be used in different ways by different people. Ask users with different degrees of expertise and, if relevant for your software, ask users from different fields: it could lead to distinct use cases. Also think about those who are not users yet, but that could become one in the future if a GUI is available.
• What barriers/challenges they are facing: To the same variety of users. An expert coder will not have the same issues as someone who is learning to use the tool.
• What they expect from a GUI: Would they use it if there was one? Ask them to sketch how they imagine a potential GUI would look like, and especially what functionality should be more easily available. If the software already has a GUI ask for feedback about it, so you can improve it.

Conclusions

There are a couple of final remarks to make that will maximise the range of users you can reach while minimising the amount of effort associated with implementing a GUI:

• Having a GUI is compatible with other ways of using the software, e.g. as a CLI app or in a script.
• A GUI does not need to cover all of the existing functionality that the framework or CLI offer to be useful, only the functionality that will have the biggest impact if available in a graphical environment. Therefore, start small.
• A GUI brings plenty of benefits to the software at multiple levels, especially in terms of usability, but it is a big undertaking, requiring time, effort and new skills. Be ready to invest.
• In the end, a GUI is for the user. Know your users and work with them when designing the GUI.