38,39 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
- Veröffentlichungsjahr: 2019
Discover Golang's GUI libraries such as Go-GTK (GIMP Toolkit) and Go-Qt and build beautiful, performant, and responsive graphical applications
Key Features
- Conceptualize and build state-of-art GUI applications with Golang (Go)
- Tackle the complexity of varying GUI application sizes with a structured and scalable approach
- Get hands-on experience of GUI development with Shiny, and labs/ui, Fyne, and Walk
Book Description
Go is often compared to C++ when it comes to low-level programming and implementations that require faster processing, such as Graphical User Interfaces (GUIs). In fact, many claim that Go is superior to C++ in terms of its concurrency and ease of use. Most graphical application toolkits, though, are still written using C or C++, and so they don't enjoy the benefits of using a modern programming language such as Go.
This guide to programming GUIs with Go 1.11 explores the various toolkits available, including UI, Walk, Shiny, and Fyne. The book compares the vision behind each project to help you pick the right approach for your project. Each framework is described in detail, outlining how you can build performant applications that users will love. To aid you further in creating applications using these emerging technologies, you'll be able to easily refer to code samples and screenshots featured in the book. In addition to toolkit-specific discussions, you'll cover more complex topics, such as how to structure growing graphical applications, and how cross-platform applications can integrate with each desktop operating system to create a seamless user experience. By delving into techniques and best practices for organizing and scaling Go-based graphical applications, you'll also glimpse Go's impressive concurrency system. In the concluding chapters, you'll discover how to distribute to the main desktop marketplaces and distribution channels.
By the end of this book, you'll be a confident GUI developer who can use the Go language to boost the performance of your applications.
What you will learn
- Understand the benefits and complexities of building native graphical applications
- Gain insights into how Go makes cross-platform graphical application development simple
- Build platform-native GUI applications using andlabs/ui
- Develop graphical Windows applications using Walk
- Create multiplatform GUI applications using Shiny, Nuklear, and Fyne
- Use Go wrappers for GTK and Qt for GUI application development
- Streamline your requirements to pick the correct toolkit strategy
Who this book is for
This book is designed for Go developers who are interested in building native graphical applications for desktop computers and beyond. Some knowledge of building applications using Go is useful, but not essential. Experience in developing GUIs is not required as the book explores the benefits and challenges they pose. This book will also be beneficial for GUI application developers who are interested in trying Go.
Andrew Williams has over 15 years of commercial software development experience across a variety of programming languages, including Java, C, Objective-C, and Go. He has been a core developer in large open source projects such as Enlightenment, EFL, and Maven, as well as maintaining various community websites and tutorials. Since 2007, Andrew has been working as CTO with many early-stage and growing software start-ups. After 6 years spent expanding an award-winning mobile app development company, he is now applying the lessons he has learned to cross-platform desktop applications using Go. Andrew is passionate about building tools and services that make software development simpler and improve productivity, as well as making it easier to become a great software engineer.Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 503
Ähnliche
Hands-On GUI Application Development in Go
Copyright © 2019 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Aaron LazarAcquisition Editor: Shahnish KhanContent Development Editor: Anugraha ArunagiriTechnical Editor: Divya VadhyarCopy Editor: Safis EditingProject Coordinator: Ulhas KambaliProofreader: Safis EditingIndexer: Rekha NairGraphics: Tom ScariaProduction Coordinator: Pratik Shirodkar
First published: February 2019
Production reference: 1220219
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78913-841-2
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
Packt.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the author
Andrew Williams has over 15 years of commercial software development experience across a variety of programming languages, including Java, C, Objective-C, and Go. He has been a core developer in large open source projects such as Enlightenment, EFL, and Maven, as well as maintaining various community websites and tutorials. Since 2007, Andrew has been working as CTO with many early-stage and growing software start-ups. After 6 years spent expanding an award-winning mobile app development company, he is now applying the lessons he has learned to cross-platform desktop applications using Go. Andrew is passionate about building tools and services that make software development simpler and improve productivity, as well as making it easier to become a great software engineer.
About the reviewer
Alastair Roy Poole is a programmer and writer from Aberdeen, Scotland. He has a passion for writing low-level implementations of popular technologies, as well as creating simple solutions to complicated problems.
He has been working with free and open source software since the mid-1990s, and many of his projects have been distributed worldwide as an author of both applications and libraries. He specializes in C, Perl, and, increasingly, in Go (among other technologies).
Alastair has a strong aversion to reliance on cloud-based technologies and severe reservations about the corporate-led direction of most open source technologies today. He has great admiration for projects with strong leadership, especially the OpenBSD project.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Hands-On GUI Application Development in Go
About Packt
Why subscribe?
Packt.com
Contributors
About the author
About the reviewer
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the example code files
Conventions used
Get in touch
Reviews
Section 1: Graphical User Interface Development
The Benefits of Native Graphical Applications
Return of the graphical application
Personal computers
From desktop to internet
Smart phones, apps, and customer retention
Native performance
Integrated user experience
Reliability and offline functionality
Maintainability and testing
Summary
Graphical User Interface Challenges
Standard look and feel or app theme
GUIs and visual hierarchy
Multiple documents
Accessory windows
Visual hierarchy
Mobile standards
Concurrency and multi-threading
Switching threads
Avoiding complexity
Web services and cloud integration
Communications
Data parsing
Standard components
Developing for multiple platforms
Cross-platform APIs
Icons and design
Testing
Packaging and distribution
Summary
Go to the Rescue!
Introduction
Cross-platform for any application
Cross-compiling
Standard library
Concurrency in language design
Goroutines
Channels
The sync package
Web services included as standard
Choosing your look and feel
Summary
Section 2: Toolkits Using Existing Widgets
Walk - Building Graphical Windows Applications
Background and aims
Get started with walk
Setup
Code
Build
Run
Benefits of a declarative API
Compared with the native API
Using both APIs for flexibility
Building a user interface
Style
Layout
Toolbar and menu
Communicating with the GUI
View model
Detail view
List view
Background processing
Walk in a cross-platform application
Summary
andlabs UI - Cross-platform Native UIs
Background and history
Getting started with andlabs UI
Prerequisites
Microsoft windows
macOS
Linux
Setup
Rebuilding the UI library (workaround)
Code
Build
Run
Generic API for multiple platforms
Controls
Box
Containers
Widgets
Menu
Area and drawing
Building a user interface
Style
Layout
Main email window
Email compose dialog
Toolbar and menu
Communicating with the GUI
Background processing
Example
Challenges with multiple native GUIs
Consistent style
Brand styles
User experience
Testing
Cross-compilation
Building for Linux on macOS or windows
macOS
Windows
Building for windows on Linux or macOS
Building for macOS on Linux or Windows
A better solution
Summary
Go-GTK - Multiple Platforms with GTK
GTK+ background
Getting started with Go-GTK
Prerequisites
Installing GTK+
macOS
Windows
Linux
Install Go-GTK
Build
Run
Signals and namespaces
Signals
Passing data
Namespaces
Sample application
Layout
Compose layout
Signaling
Thread handling
Cross compilation
Theming
Summary
Go-Qt - Multiple Platforms with Qt
Qt background
Getting started with therecipe/qt
Prerequisites
Preparing CGo
Installing Qt
macOS
Windows
Linux
License / Qt account
Installing qt (the bindings)
Build
Run
Object model and event handling
Inheritance
Memory management
Signals and slots
Sample application
Layout
The compose layout
Signalling
Thread handling
Cross-compilation
Theming
Summary
Section 3: Modern Graphical Toolkits
Shiny - Experimental Go GUI API
Background and the vision for Shiny
Design and supported platforms
Architecture
Lower layer
Higher layer
Supported platforms
Drivers currently included
Getting started with Shiny
Setup
Example
Cross-compiling
Cross-compiling for macOS
Widgets and material design
Design
Icons
Themes
Widgets
Getting started continued
Code
Supporting code
Build and Run
Building a user interface
Design
Layout
Navigation
File list
Image view
Communicating with the GUI
Background processing
Summary
nk - Nuklear for Go
Background and design of Nuklear
Rendering and platform support
Rendering modules
Supported platforms
Getting started with nk
Prerequisites
Linux
macOS and Windows
Android
Setup
Example
Code
Build and run
Cross-compiling
Widgets, layout, and skinning
Widgets
Layout
NkLayoutRow
NkLayoutRowTemplate
NkLayoutSpace
Drawing
Command queue
Draw functions
Skinning
Building a user interface
Layout
Main email window
Email compose dialog
Toolbar and menu
Communicating with the GUI
Background processing
Summary
Fyne - Material Design-Based GUI
Background and vision for Fyne
Getting started with Fyne
Prerequisites
Linux
macOS
Setup
Example
Code
Build and run
Cross compiling
Rendering and vector graphics
Vector graphics
Drivers
Supported platforms
Canvas, widgets, and layouts
Canvas (drawing)
Layout
Widgets
Themes
Packaged themes
Building a user interface
Layout
Main email window
Compose dialog
Toolbar and menu
Communicating with the GUI
Loading emails
Sending email
Background processing
Building an image viewer
Layout
Navigation
File listing
Image view
Communicating with the GUI
Background processing
Summary
Section 4: Growing and Distributing Your Application
Navigation and Multiple Windows
Planning application layout
Standard layouts
Device form factors
Responsive or adaptive design
Custom layouts
Navigating your application
Progressive disclosure
Example 1 – Microsoft Edge
Example 2 – Skyscanner flight search
Menus and toolbars
Toolbar
Menu 
Multiple windows
Window types and keeping things clean
Standard dialogs
Modal windows
Window hints
Sizes
Other hints
Notifications and task status
Minor alerts
Background progress
Platform-specific considerations
Window grouping
Application instances
Extra features
Summary
Concurrency, Networking, and Cloud Services
Concurrency, threads, and GUI updates
Managing long-running processes
Signaling shutdown
Checking completion
Communicating through channels
Graphical updates from goroutines
Network resources and caching
Loading remote resources
Images
JSON
Caching resource data
Connecting to cloud services
Encoding
JSON
XML
Authentication – OAuth 2.0
First request
Storing tokens
Posting data
GUI integration
Incoming messages
Activity notifications
Spinner
Status panel
Consistent user experience when offline
Caching responses
Queuing actions
Starting offline
Summary
Best Practices in Go GUI Development
Separation of concerns
Suggested application structure
Test-driving UI development
Designed to be testable
Example application test
Continuous integration for GUIs
Approaches to GUI test automation
Avoiding external dependencies
Managing platform specifics
Summary
Distributing Your Application
Metadata and icons
Application icon
Describing your app
Bundling assets
go-bindata
packr
rsrc
fyne bundle
Building a release
Preparing
Compiler installation
Building
Packaging
Linux
Create metadata files
Packaging release
macOS
Creating metadata files
Packaging release
Windows
Creating metadata files
Packaging release
Cross-platform packaging tools
fyne package
Distributing to platform marketplaces
Mac App Store
Packaging
Uploading
Reviewing
Microsoft Store
Packaging
Uploading
Reviewing
Linux package manager
Debian (.deb)
Packaging
Distribution
Red Hat (.rpm)
Packaging
Distribution
Tarball (.tar.gz)
Arch Linux
Gentoo Linux
Others
Containers
Summary
Installation Details
Installing Go
Microsoft Windows
Git
Go
Environment
Apple macOS
Linux
Setting up Cgo
Microsoft Windows
Apple macOS
Linux
Cross Compiler Setup
Cross compiling for macOS with CGo
To macOS from Linux or Windows
Cross compiling for Windows with CGo
To Windows from macOS
To Windows from Linux
Cross compiling for Linux with CGo
To Linux from macOS
To Linux from Windows
Comparison of GUI Toolkits
Connecting GoMail to a Real Email Server
Download Gmail credentials
Creating a server provider
Downloading inbox messages
Sending messages
Listening for new messages
Updating an example to use Gmail
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
Since the 1.0 release of the Go programming language in 2012, developers have enjoyed the increased productivity brought by the easy-to-read, quick-to-learn, cross-platform design of Go. Web apps and system utilities around the world are being built with Go to rapidly deliver reliable performance. Learning the language is easy, due to its centralized documentation and great programming environment support. Creating Graphical User Interfaces (GUIs) with Go, however, is still very new and there is not yet a standardized UI toolkit.
This definitive guide to programming GUIs with Go explores the most popular GUI packages available. It compares the vision behind each toolkit to help you pick the right approach for your project. Each toolkit is described in detail, outlining how to build beautiful, performant applications that users will love. Code samples and screenshots will aid any level of Go developer to create applications using these emerging technologies.
Who this book is for
This book is written for Go developers who are interested in building native graphical applications for desktop computers and beyond. Some knowledge of building Go applications (command line based or web apps) is assumed, but not essential. The first section of this book looks at the history of the GUI, its importance to the evolution of modern personal computers, and how it can pose additional challenges to software developers.
Developers of GUI applications that are interested in trying Go may also find this book useful. Section 2, Toolkits Using Existing Widgets and Section 3, Modern Graphical Toolkits, explore the various frameworks available to the Go language and demonstrate how applications can be rapidly developed from basic principles.
Additionally, an experienced Go developer may find the final section useful. The chapters of section 4, Growing and Distributing Your Application covers how to design and build complex graphical interfaces that fit user expectations. It looks at the different approaches possible to support multiple operating system standards and how to integrate the GUI well with network resources and cloud services. The final chapters cover best practices in GUI applications with Go, and look at how to package and distribute your software through the various distribution channels available.
What this book covers
Section 1: Graphical User Interface Development
Chapter 1, The Benefits of Native Graphical Applications, contains a re-introduction to the GUI and its role in the modern software ecosystem. It discusses the benefits of coding a native GUI for a responsive user experience and platform integration. By the end of the chapter, you will be comfortable deciding which of your projects would benefit from a native graphical interface.
Chapter 2, Graphical User Interface Challenges, shows how GUIs present various challenges to the designer and developer beyond that of a web app or systems application. This chapter will explore the details of the most common challenges, including look and feel, performance, platform integration, and distribution. On completion of this chapter, you will be familiar with the additional complications of building a graphical desktop application, and know what to consider when designing a GUI.
Chapter 3, Go to the Rescue!, shows how the design of the Go language is well suited to solving the challenges described in the previous chapter. It will demonstrate how the Go language, despite not having a standard user interface API, has all the required constructs to ease development of graphical applications. At the end of this chapter, you will be ready to progress to the detailed toolkit API descriptions that follow in Section 2, Toolkits Using Existing GUIs.
Section 2: Toolkits Using Existing GUIs
Chapter 4, Walk - Building Graphical Windows Applications, discusses Walk, which is a Windows Application Library Kit for the Go programming language. This chapter covers API design, common usage patterns, and how to use the library as part of a multi-platform strategy. You will learn how to build a simple Windows application using the Walk toolkit through examples and illustrations.
Chapter 5, andlabs UI – Cross-Platform Native UIs, explores Andlabs UI, which is a popular GUI toolkit that uses the existing graphical technologies on each of the platforms it supports. This chapter discusses the benefits of such an approach and shows how the API is designed. You will learn how to build a simple application using the andlabs UI toolkit through examples and illustrations.
Chapter 6, Go-GTK – Multiple Platforms with GTK, here, Go-GTK examines the Go language bindings for GTK+, a multi-platform toolkit for creating GUIs. GTK+ supports many platforms and comes preinstalled on many environments. In this chapter, we look at the details of the GTK+ toolkit, the platforms it supports, and how to make use of it in your application. You will learn how to build a simple application using the Go-GTK API through examples and illustrations.
Chapter 7, Go-Qt – Multiple Platforms with QT,explains that Go-Qt allows you to write Qt-based graphical applications in Go. Qt is a cross-platform application framework that is used for developing applications that can be run on various software and hardware platforms. In this chapter, we look at the details of the Qt framework, the platforms it supports, and how to make use of it in your application. You will learn how to build a simple application using the Go-Qt API through examples and illustrations.
Section 3: Modern Graphical Toolkits
Chapter 8, Shiny – Go's Experimental API, looks at the Shiny project, an experimental GUI library written in pure Go, and is designed to create portable apps that have a consistent look across multiple platforms. This chapter explores how to write portable cross-platform applications with Shiny. You will learn how to build a simple cross-platform graphical application using the Shiny APIs through examples and illustrations.
Chapter 9, nk – Nuklear for Go, explains that Nuklear is a lightweight widget library that focuses purely on the graphical interface (rather than window management and platform integration) to create an easy-to-use API. The graphical interface, originally designed for embedded applications, renders identically across all supported platforms. Its implementation has no dependencies and achieves this by avoiding a standard render context and operating system drivers. You will learn how to set up a render context and use this toolkit to create an example application.
Chapter 10, Fyne – Material Design-Based GUI, explores the Fyne project, designed to be an easy to use UI toolkit and app API written in Go that follows the Material Design principles. It uses OpenGL backend to provide cross-platform graphics that look identical on any supported platform. This chapter explores how to write beautiful applications for multiple platforms with Fyne. You will learn how to build a simple multi-platform graphical application using the Fyne toolkit through examples and illustrations.
Section 4: Growing and Distributing your Application
Chapter 11, Navigation and Multiple Windows, covers the workflows and growing complexity of expanding a graphical application. As well as planning and presenting a clear navigation and workflow, it also covers how to manage multiple windows, dialogs, and application instances. It also explores the differences between how desktop operating systems consider application life cycles, and how this may impact your application design. After completing this chapter, you will be confident in how to adapt your application design as you expand its functionality.
Chapter 12, Concurrency, Networking, and Cloud Services, explains how more advanced aspects of large application programming fit within a graphical Go application. We cover concurrency and networking, looking at how to work with goroutines and long-running threads, remote resources, and how to handle the user impact of unreliable network conditions. Additionally, you will learn how to connect with and utilize cloud services to provide a rich user experience, both online and offline.
Chapter 13, Best Practices in Go GUI Development, illustrates that the Go language comes with a well-understood set of best practices, covering features such as style, documentation, and code structure. In this chapter, you will learn how to apply these to the development of graphical applications, and which additional practices are recommended. You will learn how the toolkits described in the previous chapters agree on topics such as binary packaging and managing platform specific code.
Chapter 14, Distributing your Application, shows how distribution of applications for multiple platforms is a challenge, but it's important that your users have a seamless experience. In this final chapter, you will learn how to package your application and its assets for consistent distribution across the operating systems you target. We will explore the various options for app-store or marketplace deployment, along with how to deliver direct downloads. At the end of this chapter, you should have the knowledge to design, build, and distribute your graphical application using the Go language.
To get the most out of this book
A basic knowledge of the Go language is assumed throughout this book. If you are not yet familiar with its basic concepts, consider running through the online tutorial before you begin reading (tour.golang.org).
To benefit the most from later chapters, it would be ideal if you have in mind a particular application you are working on or would like to build. Applying the frameworks and tools used in this book to a particular project will aid your understanding of the various concepts. Additionally, this will deliver the benefit of you completing your project and preparing it for distribution.
Download the example code files
You can download the example code files for this book from your account at www.packt.com. If you purchased this book elsewhere, you can visit www.packt.com/support and register to have the files emailed directly to you.
You can download the code files by following these steps:
Log in or register at
www.packt.com
.
Select the
SUPPORT
tab.
Click on
Code Downloads & Errata
.
Enter the name of the book in the
Search
box and follow the onscreen instructions.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
WinRAR/7-Zip for Windows
Zipeg/iZip/UnRarX for Mac
7-Zip/PeaZip for Linux
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Hands-On-GUI-Application-Development-in-Go/. In case there's an update to the code, it will be updated on the existing GitHub repository.
We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Conventions used
There are a number of text conventions used throughout this book.
CodeInText: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system."
A block of code is set as follows:
html, body, #map { height: 100%; margin: 0; padding: 0}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
[default]exten => s,1,Dial(Zap/1|30)exten => s,2,Voicemail(u100)
exten => s,102,Voicemail(b100)
exten => i,1,Voicemail(s0)
Any command-line input or output is written as follows:
$ mkdir css
$ cd css
Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: "Select System info from the Administration panel."
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packt.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packt.com.
Section 1: Graphical User Interface Development
For many years, graphical user interfaces (GUIs) have been the standard way for the average computer user to engage with a software product. They provide an intuitive user experience for potentially complex workflows within the familiar context of a desktop environment. Having evolved over more than 40 years, the traditional graphical application is being challenged by the ubiquity of web-based software and the emergence of mobile applications on modern smartphones and handheld computers. Despite these new trends, there are still many reasons why building a native graphical application for desktop (and laptop) computers could be the right strategy for your product.
In this introductory section, we will look at the history of the desktop GUI and how it has developed alongside technological innovation. We will discuss why, despite new alternative approaches, native graphical applications are still a great way to provide an intuitive user experience and a reliable software product. Building anything of quality takes effort, and software is no exception. We will explore the challenges that teams are likely to face when designing and building a native graphical application that aims to support multiple operating systems. Having reviewed the importance of the GUI and the challenges it can pose, we examine the Go programming language and demonstrate that its design fits very well with the creation of modern native graphical applications for multiple platforms.
The following chapters will be covered in this section:
Chapter 1
,
The Benefits of Native Graphical Applications
Chapter 2
,
Graphical User Interface Challenges
Chapter 3
,
Go to the Rescue!
The Benefits of Native Graphical Applications
Since they first appeared in the 1970s, it has been clear that graphical interfaces make it easier to work with software applications. In the early days, they were typically presented through Windows, Icons, Menus and Pointer (WIMP) interfaces. While these varied in design across platforms and over time, the interactions have been relatively consistent.
Recent changes in software development have increased the understanding of user experience, which focuses on creating applications that are intuitive for even the least experienced computer user. This, combined with the mobile-driven move towards a post-WIMP approach to computer interaction, prompts the question: what's next for desktop computer software?
This chapter will cover the following topics:
The history of
Graphical User Interfaces
(
GUIs
) through desktop, web, and mobile
The importance of a well-integrated and responsive application interface
User expectations of both online and offline
native
applications
The developer benefits of building native graphical applications
Return of the graphical application
It was 1973 and Palo Alto Research Center (Xerox PARC) had just completed the Alto computer, the first commercial example of a computer GUI. While the screen orientation and lack of colors make it a little peculiar to the modern eye, it's clearly recognizable as a graphical interface, with a mouse and keyboard for interaction. While it took another seven years to be generally available to the public, in 1981, as the Xerox Star, it was clear that this was the beginning of something big:
This was a huge leap forward for the usability of computers—a welcome change from the standard interaction of text-mode computer screens. Not only does a graphical interface allow for more advanced functionality, it's also much easier to learn for a novice looking to get started. While the command-line interface remains popular with programmers and other experts, it's fair to say that, without the GUI, personal computers wouldn't have reached the popularity we all know:
Personal computers
Over the 10 years that followed the Xerox Star public release, many graphical platforms emerged, including Microsoft Windows, Apple Macintosh, X11 (started at MIT for UNIX computers), and DRI's GEM (primarily for Atari ST). Though the background of each of these is different, they shared a common ambition to provide a desktop environment that enabled a computer user to interact with multiple graphical applications at the same time.
This was one of the defining characteristics of the emerging Personal Computer (PC) market and it led to a whole new world of computer software:
As PCs became more powerful, advancements in hardware supported more sophisticated software applications. Higher resolution screens allowed the display of more information and removable storage devices (such as floppy disks, CDs, and then USB sticks) enabled transferring larger datasets between applications. What used to commonly be simple interfaces with a few options became more sophisticated and more complicated.
The default graphical interface elements and layouts needed to be extended to keep up. Menus got larger, toolbars were introduced to highlight common tasks, and built-in help systems became necessary to help users achieve their tasks. We also see platforms start to take on their own identity, leading to additional hurdles when learning new software. It was common for an average off-the-shelf software product to come with an instruction manual longer than this book, explaining how to interact with its various features.
From desktop to internet
In the mid-1990s, the World Wide Web (which would come to be our global communications platform) was getting started and the PC market started to see various web browsers arrive. These were initially distributed as software packages (on floppy disks) and then later as part of the desktop environment (pre-installed on new computers). Mosaic, Netscape Navigator, and Internet Explorer arrived in quick succession to give early adopters access to the emerging information channel. In those days, it was largely academic texts and reference materials; you needed to know where to look to find things and, similarly to early computer use, it wasn't particularly intuitive.
What became clear, however, was that this new medium was starting to facilitate the future of communications and information exchange. People began to see that being the main technology within that space would be critical; and so began the browser wars. As web browsers vied for the top spot, the technology became embedded in the desktop platforms as a way to quickly deliver well-presented content. Initially, those bulky user manuals were moved to HTML (the language of web pages) and bundled with the software download, and then more functionality of each application moved online. As an internet connection became commonplace in most homes, we saw the rise of full web-based applications.
A web application is one that requires no software installation beyond the internet browser already on your computer. They always deliver up-to-date information direct from the source. This is usually customized based on your location, preferences, or even browsing history on the web application or those of partner companies. Additionally, a web application can be improved at any time by the company providing it; often, following experiments where the company sees which version of an application has a better user experience. The following illustration shows a possible architecture for an application delivered over the web.
As the technologies behind web-based applications developed, they became viable alternatives to desktop software. Software companies began to realize that it is a lot easier to deliver your product directly through a website rather than the traditional download model. Not only that, but it also meant that one product would work on almost any computer. Attempts in the past to make a write-once-run-anywhere platform (such as Python and Java) had great success at the time, but after the web technologies reached a certain level of complexity, it became clear that the performance penalties and distribution overheads required by the cross-platform interpreters made web applications far more attractive where possible.
Smart phones, apps, and customer retention
For a long while, it looked like websites were the future for delivering software products, which was until the entry of smart phones. Once mobile phone technology developed to the point that you could access websites in the palm of your hand, the requirements for web-based applications changed once again. Now, developers needed to consider how smaller screens could present meaningful content. How could a touchscreen-based user interface operate where a mouse and keyboard used to be assumed? And how could people engage in a meaningful way when they had only five minutes while waiting for their coffee order?
Delivering a single application, available through desktop browsers and mobile phones, across a plethora of different operating systems and devices, has clear advantages for developers, but there are also challenges. The internet is a very large place and your product can easily get lost in the noise; how do you attract new users and how do you ensure that your existing customers keep coming back? One major response to this was the introduction of native apps (applications designed and built for specific platforms) for mobile devices. The iPhone launched with web-based applications only, but within eight months, Apple delivered the capability for developers to build native applications. These applications provided a more meaningful engagement with users; they were designed for the device they ran on, they could be found easily through a marketplace or app store, and once installed, remained a constant reminder on the device's home screen.
And so we enter a time where our target audience has become accustomed to software designed specifically for their device. A polished user experience is a must-have if companies expect to engage and retain their customers. Waiting for pages to load or dealing with intermittent errors are niggles that users are no longer willing to put up with. This higher bar for software delivery is now a well understood phenomenon, but the improvement in quality for software delivered through mobile devices hasn't yet been reflected on the desktop. Until recently, the browser was still king; long lists of website bookmarks are used in place of expecting applications delivered through a store and installed onto the computer. This, however, is changing and we're going to explore how to deliver a quality user experience through beautiful desktop applications.
Native performance
One of the main reasons that businesses often opt for a website-based approach is to avoid having to build many products for the platforms they wish to support. We're seeing a similar approach to mobile application development: as more platforms enter the market, developing native apps becomes an overhead that many businesses can't afford. They opt for the web-based approach or hybrid app, where the user believes they're installing a native app that's really just a website packaged into a download. While this can be good enough for simple applications with basic data processing, it is often not going to meet user expectations. Additionally, the interaction paradigms for a web browser are usually different to that of the system applications around it. If the user expects an application to behave in a certain way, then an embedded web browser could prove to be a confusing experience.
The biggest challenge in delivering a large application through web technologies (through a browser or downloaded application) is achieving good performance. As a browser is designed primarily for information exchange, it isn't well suited to large data processing or complicated graphical representations. When delivered through a web browser, much of this can be performed by a remote server that has the capacity to run complex calculations and return the summary to the user. Unfortunately, when you're running a local application, this cannot be relied upon and users expect immediate results in their application (remember, this is not a browser window with lots of open tabs to browse while waiting). Additionally, recall one of the benefits of web-based delivery—the chance to update the software continually without distribution issues? While that may be great for development, it's possible that your customers don't want the interface to be changing all of the time; they want to be in control of when (and if) to update their systems.
In applications where there's a lot of computation to run or complicated graphics to display, most web apps will struggle to run as fast as a user expects. Native applications, which are compiled for the computer they're used on (and will have been downloaded in advance, so no waiting), are currently the best way to get high performance. There are various virtualization technologies that aim to provide near-native performance with a single application (for example, Java), but this is not always appropriate or sufficient, and often suffers side effects such as long start up times or huge downloads. As you've chosen to read this book, you'll probably already be aware of another approach: a language that allows you to write a single application but have it compile to a high performance native application for any platforms you wish to support.
Integrated user experience
A consistent user experience is of paramount importance if users are expected to pick up software and be able to use it quickly. When programmed to match system design and layout, as well as use standard components, it is easier for a new user to understand how the application will likely work without the need for one of those weighty user manuals. The graphical user interfaces for most popular operating systems have been very carefully designed so that applications written for them will feel natural. The user should inherently recognize the design language and know how to accomplish most of the main tasks right away. Carefully designed platforms such as macOS or Windows 10 provide a toolkit that ensures applications built using it will be immediately familiar to users. This includes peripheral items such as how you choose a file to open, what should happen if you copy and paste a complex file type, and how the application should respond if an item is dragged onto its window. Very few of these features are available to, or correctly utilized by, web-based or command-line applications.
An additional consideration for professional application producers would be assistive technologies. GUIs built using the platform standard toolkits work with provided (or complementary) accessibility enhancers such as screen readers or braille devices. Both web pages and text-based applications typically have to work much harder to support these technologies. Remember that each platform your web page or hybrid application will load on could have very different standard behaviors for assistive technologies. Building a graphical application using the tools of your target platform typically benefits your users, whether they use the interface you designed directly or through accessibility options.
Reliability and offline functionality
One benefit of great applications is their ability to work online and offline, even to deal with an internet connection that's unreliable. For example, blog applications that allow authoring but don't need the internet until you publish, or document editors that download all of your work and share any changes you make with a central location any time you're online, have significant benefits over any web app with an always-online approach. Desktop computers and even newer smart phones have significant processing power and storage, and as application developers, we should make the most of the resources available. User experience is not limited to design and system integration, but also the responsiveness and workflow of an application. If we can hide the complexities of a process or technology from end users, we may find them coming back to the application frequently—even if their internet connection is currently unavailable.
While caching (keeping downloaded content around for offline work) is a relatively easy problem to solve, synchronization (combining all changes made from various locations) is not. Thankfully, native applications have tools available to assist with this complicated task, whether through a platform toolkit (such as Apple's CloudKit for iCloud) or by use of third-party technology (such as Dropbox's API or Firebase's offline capabilities for iOS and Android). Due to the incredible rise in popularity of mobile apps most development is focused there, but many of these technologies apply just as well to native applications on the desktop.
Web technologies continue to make strides in providing increased reliability and offline capabilities, but they are a long way from meeting the standards expected of native graphical applications.
Maintainability and testing
To support the fast pace of software development, evolution in technology, and user demand for more features, it is imperative that our software be well-organized and highly maintainable. Any one on your team, or yourself at some point in the future, should be able to easily understand how the code works and quickly make the required change or addition. Supporting this sort of future development requires a well-organized project and an investment of time to maintain standards.
Native applications are typically written using a single language: that of the platform they are built for. This constraint means that an entire application can follow standard layout, naming, and semantic conventions, making it easier to work on any portion of the software. Modularity and code reuse are far easier to accomplish, and so duplication or incomplete changes are less likely to be a problem within the project. Test Driven Development, by now a well-utilized methodology, doesn't require a single language within the code base to work well, but the tooling required to make it possible does vary by language and having only one setup to support per project is beneficial.
One of the reasons that the other forms of graphical applications (mainly web-based) use multiple languages is also why they are harder to test: their interface is presented using a web browser (or embedded HTML renderer), which can vary hugely from one platform to another. Irrespective of the age of the hardware or the type of device it's being used on, people will expect your application to load fast and look right. This means a lot of variation to deal with and a lot of testing for each change. Compare this to a native graphical application, where the target devices are known and fully supported by the toolkit used for developing. Testing is easier and faster, and so changes can be made rapidly and with confidence. Native graphical applications truly are the best way to make beautiful, responsive applications that will spark joy in your target audience.
Summary
With the first graphical user interfaces in the early 1970s, computers became more accessible, and ever since developers and designers have been finding ways to improve user experience. As technologies evolved, the focus moved from desktop applications to web-based software and mobile apps. Through each change in development, we see the need to make applications responsive, reliable, and engaging. In this chapter, we explored the history of the GUI and how native applications continue to provide the best user experience.
By creating quality graphical applications using native technologies, developers are able to provide better reliability and a more responsive user interface. Ensuring that applications integrate seamlessly with the operating system, as well as working well online and offline, will provide a consistent workflow that will keep your users happy. We also saw that the structure and format of a native application can benefit software developers and support processes that ensure a higher quality product.
In the next chapter, we'll discover how some of these benefits are created within graphical applications and the challenges they can pose. We'll compare various approaches to these complexities and outline some of the decisions that will need to be made when designing a modern, native graphical user interface.
Graphical User Interface Challenges
In the previous chapter, we explored the history of graphical user interfaces, looking at how they evolved and why they can provide a better user experience than contemporary alternatives. Unfortunately, despite all the benefits of graphical applications for end users, they can pose many challenges to the team designing and building them. In this chapter, we look at the sorts of issues that a team may face at various stages of creating an average-complexity graphical application.
This chapter will cover the following topics:
Choosing a look and feel to match the operating system or product brand
Different approaches to application layout and multiple windows
The challenges of concurrency and cloud service integration
Overheads introduced when developing a graphical application for multiple platforms
Standard look and feel or app theme
When designing your graphical application, it's likely that an early question will be around the visual identity; should the application fit within the operating system's look and feel or should it have a brand of its own? Do you want to work on a complete theme for the user interface that the user will identify with, or do you wish to make use of the well-crafted and commonly understood interface elements of the user's operating system?
As with most questions that we will encounter throughout this chapter, there is no right or wrong answer, and whichever path you choose will have positive and negative side effects. Going with completely standard components will likely result in faster development and be easier for users to understand, but how do you differentiate your app from others? If you design the complete application interface from scratch, then you will develop a good brand identity for the software that users will recognize, but it may take them longer to learn and it could look out of place on the platform you are targeting.
Different design approaches typically suit different types of applications. Games clearly rely on heavily customized graphical interfaces and rarely use standard components but their users, the gamer community, understand the standard interactions of the genre so don't need the common visual cues that using the operating system's default elements provides. Utility apps (those that you load to do a quick task alongside your current work) will benefit from blending in so that very little thought is needed to operate them and no identity needs to be associated with the experience:
Assuming that you have decided whether your visual design will fit with a standardized look or require a more bespoke approach, you need to consider the platforms you will deploy to. Is this an application designed for a single operating system or for many? If your software will only work on Windows, then using the standard look and feel could clearly be the way to go, but what if you are looking for a cross-platform distribution? macOS looks very different to Windows, which in turn is not the same as an average Linux desktop. Which do you target? Or, do you opt for the same interface design on all platforms?
The complexity of cross-platform GUI design is not a new problem, but it is one that requires some thought as you design the application experience. If you have a standardized interface design that works for your brand or application, will it apply equally well across different operating systems? Alternatively, if you aim to use standard components on each platform, how will you ensure a consistent user experience and how much more time will be put into support materials or your help desk?
When Java Swing was the standard for cross-platform graphical applications, their approach was unique: allow the developer to code against a standard API for building the GUI, but provide the ability for it to have different presentation modes, to look consistent across platforms, or to blend in with the system it is running on. This meant that the same application could be configured to look the same across all operating systems or to fit within the current desktop environment. Unfortunately, this method has its limitations, due to the way that it ends up providing a lowest-common-denominator set of functionality. Advanced integrations in one area would not be usable in a cross-platform app unless it were a feature of all supported operating systems.
Additionally, the user interface design can age badly on an operating system that changes look drastically from one release to another (such as Microsoft Windows moving from Vista to 7 to 10, each of which had quite distinctive looks):
Over time, the number of ways to build graphical applications has increased, with many options available for most programming languages. Some are designed to use the system style, some prefer their own graphical style, and others leave that to developer or user preference. And so you must choose: do you want your app to blend in to a standard operating system look, or are you aiming for a brand identity or design that looks the same on each system you will deliver to? We will explore both options in Section 2, Toolkits Using Existing Widgets and Section 3, Modern Graphical Toolkits of this book.
GUIs and visual hierarchy
The graphical language and common visual layouts of software have evolved a lot over the recent history of consumer software products and continues to evolve. Each operating system and graphical toolkit focuses on usability while attempting to have a unique look. These principles have driven each platform in slightly different directions, which impacts the software we write and the content we present.
Multiple documents
Let's first look at the ways that applications can handle multiple concurrent documents. These interfaces all aim to present a way to work with many documents at the same time. Whether it's a word processor, an image editor, or a web browser, there are many ways to approach this. An operating system typically has a default behavior that application developers are encouraged to use (sometimes by promoting enhanced usability with the latest changes, and other times by adding or removing APIs within their respective toolkits). These interface preferences can change over time, but can also become standardized around certain categories of application. For example, earlier in their history, Microsoft promoted the Windows multiple document interface (MDI) layout, which remains popular with text editors and integrated development environments (IDEs):
Developers of native macOS applications are encouraged to use a new window for each document, but to group them under the same application, so the user only sees one icon that groups them:
The Chrome web browser decided to integrate their tabbed display into the window header bar, a space that normally shows just the title of the application or loaded document:
With all these possible approaches, which is right for your application? If you have to deal with multiple documents, it's worth looking at applications that manage similar file types, or comparing how various applications in the same environment handle window management.
Accessory windows
There is also a notable variance in the positioning of toolboxes and the grouping of features that relate to common areas of functionality. Over the years, there have been many iterations such as drawers (which slide out from the window) and pop-out dialog windows (still used where context is important but the tools are used less often), but the always-visible toolbar or accessory window remains the most popular.
For example, applications designed for Linux and Unix desktops are typically presented using separate windows for each of the supporting tool panels:
Compare this with Windows software, which commonly uses a combined layout where controls are positioned around the borders of the document window:
Both of these approaches, within a single platform, provide a consistent user experience, but for a graphical application that targets multiple operating systems, it is important to consider which approach suits best. Does your software particularly suit one approach or the other? Maybe it will be easier for people to use your application if its graphical design adapts the layout to match the conventions of the platform it is running on.
Visual hierarchy
The evolution of web-based applications followed a different path. Historically, this medium has been used for presenting large amounts of textual information and academic documents. This was usually formatted as hyperlinked content and often included a list of popular links in a navigation area that would help people to find important content. While it was common for each site to have a very individual look (distinct colors and typesetting have had their trends along the way), this grouping of content was largely consistent across the internet. It was a big shift from the desktop software at that time, but once a user had learned the way to interact with one website, they could relatively easily find their way around most of them.
In terms of applications that were delivered through a website, this had a large benefit: the standardized layout or visual hierarchy meant that a new, distinct design would still be usable by most internet-savvy computer users. This was in addition to the fact that they would look the same on any operating system or web browser. This consistency for the user made it easier for designers to apply rich visuals or branding to a web application without reducing the user experience. As the evolving Cascading Style Sheets (CSS) open standard gained popularity, it became easier to share subsets of these designs and to separate the layout details from the visual styling and brand. As a result, there emerged common code for structuring websites and applications, similar to the desktop toolkits that developers were familiar with. But combined with consistency across any internet-connected computer, this standard approach started to make desktop applications seem confusing to learn in comparison:
Mobile standards
Mobile applications pose a different design challenge: how to make a great user experience on a far smaller screen when the main input device is a touch screen where your fingers may obscure content. The companies behind the major mobile operating systems (Apple, Google, and Microsoft) spent many years developing a visual language and standard interactions that provided a smooth flow through increasingly complicated applications. As previously with web applications, it was important that native mobile applications behave in a consistent manner for users to quickly learn and feel comfortable with these new platforms. iOS, Android, and Windows Phone provide standard APIs that developers can use to create applications that fit with the platform standards. Within each platform, there are enough customization options to support brand identity through use of color, icons, or the content of each screen within the app. While the specific design aesthetic of mobile platforms has changed over the years, it is clear that the carefully designed layout and workflow aspects remain consistent throughout. Users can comfortably pick up the latest iPhone, appreciate its new design, and still be completely familiar with how the applications will work:
There is clearly a lot more to designing an application GUI than designing a workflow and picking a color scheme. Will your application take inspiration from modern application UX, or is it aimed at users who are more familiar with the classic look of desktop applications established over many years? Will you be sticking to a single platform and its standard look and feel, or are you interested in launching your software across multiple operating systems? Before we look at the different toolkits available, take some time to consider these options and identify which is likely the right strategy for your application.
