The history of the prototyping tool. Part II

Finding the right prototyping tool (we wrote about it in some detail in the previous post ) took us quite a lot of time and ... ended in nothing. We never managed to find a tool that would fully cover all our needs. It seems that the prototyping program, which fully meets all our ideas and wishes, simply did not exist in nature ... Single candidates were close to victory, but in any of them there was some unpleasant and unacceptable "nuance" for us that did not allow and without soulfulness say: "This is exactly what we were looking for." Of course, you could close your eyes and make compromises, but this is not our way. The understatement is what we really do not like.

On this basis, we took not the easiest decision to try to personally implement all our ideas and create our prototyping tool. The analysis of the prospects for the market of prototyping tools also helped to develop our own product: there were few solutions and they did not cover all the requirements of IT companies (at least our company, well, are we not certain that they are not the only ones) . Another significant impetus was the prospect of releasing the first Russian full-fledged prototyping tool. In general, we counted more pluses than minuses.

Creating your own prototyping tool started not from scratch, but on the basis of ... however, I will describe the history of the creation of our tool below.

Story

2005 year

The main product of ALEE Software is a corporate ERM (Electronic Records Management System) class system. The system consists of two thin clients through which users work: desktop application and web. A web-based presentation of a system often requires customization of its graphical interface to customer standards, as well as other corporate information systems used by it. To accomplish this task, we had the idea to create a special tool - a designer, with which one could easily rebuild the graphical interface of the web component of the system. It was supposed to make it easy to use so that the Customer could customize the system interface on its own without writing software code and without involving third-party specialists. So, driven by this idea, we began an experimental work to create such a tool.
')
We planned to make the designer part of the system. Naturally, in this case, it should be written in the language of the main system, i.e. in java. Later, however, it became clear that the existing technologies and capabilities of Java did not allow the task to be solved. Why? First, on large projects, the speed of interpretation of Java classes into native code by the Java machine was too low; The application speed was significantly slowed down. Secondly, the standard JDK assembly lacked native components of various operating systems. This problem can be solved by attracting additional libraries, but it would be associated with additional difficulties. In addition, the quality and price did not suit us. Third, the Java language itself did not have many of the tools needed to create a new tool, which at that time was already implemented in many other programming languages. The list of problems and limitations can be continued, going into deep details and small details, but it’s not about that. In the end, we decided to postpone the planned development, as they say, until better times. As a result of the work carried out, experimental developments were created, the use of which we did not find at that time. And the problem of customization of system interfaces was solved in another way.

In the development process, we created a launching application that included: a graphical interface editing area, a minimum set of components for testing a graphic editor, a separate frame for managing layers, and a separate frame for setting components.

2006-2008

For about three years, our experimental work, as they say, “was on the shelf” and waited patiently in the wings.

2009

At a certain moment, our company faced an acute problem of choosing a prototyping tool. We are actively engaged in the search for such, which is described in detail in the first part of the cycle . It was at this time that we had the idea of ​​creating our own prototyping tool. And here we remembered our experimental work: they were the best basis for the future tool.

The active development of the prototyping tool began, which later became known as the GUI Machine.

Setting Requirements

Having understood the specifics of the tasks facing us and analyzing the products available on the market, we clearly formulated the requirements regarding the qualities that our prototyping tool should have:

• the ability to prototype both desktop and web applications; not necessarily, but desirable - the possibility of prototyping applications for mobile devices;
• a higher (in comparison with existing analogues) degree of interactivity of the prototypes being created, a large set of processed events and actions performed;
• the presence of a large set of ready-made graphic elements, both platform-dependent (that is, “adapting” to the look of the operating system and its design), and platform-independent. This set should include elements for desktop, web, and mobile applications. They should be as customizable as possible;
• high realistic prototypes;
• the ability to view prototypes by their own means, without the involvement of third-party software products;
• ease of development: the tool must be such that with its help a person who does not possess any programming skills can create prototypes;
• high speed prototyping;
• cross-platform (the tool should work at least in the main operating systems - Windows, Mac OS, Linux).

Way to develop

To develop a prototyping tool, we used the technique of extreme programming (XP). This choice was due to a number of reasons. First, it was necessary to create the tool as quickly as possible. XP is a suitable methodology for solving problems of operational development. Secondly, we did not have fixed requirements for the tool being created, everything was changed and supplemented in the development process. Thirdly, the use of XP methods ensures a minimal risk of obtaining a non-compliant tool at the output.

We tried to adapt the requirements of XP to the specifics of our work: for example, our team had only one programmer, so we did not use the techniques of pair programming and mutual verification of the code.

The development was carried out in close cooperation of the programmer, the project manager and future users of the system. Work on the program was carried out at a fast pace: changes were made to the original version every day (and sometimes even several times a day). At the initial stages of work, we deliberately did not pay much attention to design issues, which allowed us to focus as much as possible on the implementation of the functional, and also to avoid delays.

2010

We started work on creating our own prototyping tool on November 22, 2009. Already in May 2010, long before the release of the release version, the reliability and functionality of the product reached such a level that it was successfully tested on a real project of the company. This fact, by the way, was another indication that we made the right choice by turning to extreme programming.

Product operation

I note that initially we did not set ourselves the goal of releasing our own prototyping tool to the market, but planned to use it exclusively for the company's projects. So, 2010 was marked by a number of projects, the implementation of which used our tool. Below are a couple of examples.

Development of a CRM system web interface

For the first time, the tool was used to develop a prototype of a CRM system web interface (Customer Relationship Management System), a complex enterprise level system. The basis for it was the existing desktop CRM system (internal development of the company).

In order for the customer to see the interface of the future system and express his wishes even before the actual start of development, his highly accurate and interactive prototype was created. He adequately and realistically presented both the design and the functionality of the system:

Intracorporate portal development

The tool was used to create a prototype of our company's internal corporate portal. This project did not have strict time limits, design and functionality. Thus, the specialist who developed this prototype had more freedom of action. The prototype was fully interactive and had a beautiful design:



Industrial operation of the instrument showed the viability of the instrument, its ability to successfully solve the tasks assigned to it. Having received such results, it was decided to refine and release the tool on the software market.

December 1, 2010 release version of the product was released.

2011

On January 24, 2011, we held a seminar on “Problems and Solutions for Designing and Prototyping Graphical User Interfaces” at which the tool we developed was first introduced under the name GUI Machine.

What happened?

The result of our work was a product called GUI Machine. Among the undoubted advantages of the product we include:

• the ability to prototype both web and desktop applications;
• high interactivity of prototypes;
• high visual accuracy and aesthetic appeal of prototypes;
• ease of development and work in the tool: GUI Machine can be used in its work not only and not so much by programmers, but also by managers, analysts who interact with the client, and even clients themselves;
• high speed prototyping;
• cross-platform: runs on Windows, MacOS and Linux;
• complete Russian product localization (product interface, user manual in Russian) and Russian-language support (training, consulting).

It would be dishonest to point out only pluses. Of course, our product also has its disadvantages and disadvantages:

• while there is no possibility of full collaboration on the prototype;
• while there is no possibility to generate a specification based on the prototype;
• while there are no components for prototyping applications for mobile OS;
• There are no tools for drawing UML diagrams;
• The tool is quite demanding.

Why does the word "bye" appear in many paragraphs? The fact is that now we are dynamically developing, expanding the functionality of the tool and, of course, we plan to get rid of these shortcomings.

PS

We do not harbor any illusions and do not consider GUI Machine to be a panacea for solving any tasks better than anyone. However, for those who, in search of a suitable prototyping tool, have run into problems similar to those described by us, our tool will probably prove to be very, very useful.

UPD: The next article in the series will provide a detailed overview of the GUI Machine prototyping tool.