When creating a new web application from the SpreadsheetWEB web interface, the options you will see include Web Application, Web Service, Dashboard, Custom UI Application, and Designer. In this article, we’re going to be comparing two major methods, Web Applications and Designer Applications.

Excel workbooks can be transformed into web applications with SpreadsheetWEB primarily using either the conversion wizard, or the designer. Regardless of the UI generation method, a web application consists of a web interface and calculation logic. In both conversion and designer methods, the calculations come from the underlying Excel spreadsheet.

Web applications and designer applications both pull the data model from your Excel workbook. To give you a quick view of the process, either one of the left or middle paths, combined with the right hand side yields a web application.

Comparing Conversion and Designer Applications in SpreadsheetWEB


Accessibility and Design

Let’s begin with the accessibility and design structure of each tool. The conversion wizard is included in SpreadsheetWEB Excel add-in, while the designer is a completely web-based interface. This means that application elements are handled differently.

In the conversion method, defining the visible area, inputs, and other application elements are done via the Excel add-in, inside your spreadsheet. Each visual element on the final version will reflect whatever you see in the workbook. Once everything is defined, the conversion wizard then ‘reads’ your spreadsheet and creates the web interface directly from your Excel interface. The purpose of the add-in in the conversion method is mainly to identify the areas of the workbook to expose in the web interface and to identify input cells.

Designer was built with the idea of decoupling the construction of the user interface from the Excel model. In designer applications, the workbook only provides the calculations and data. UI build, database structure, styling, and other workbook features are controlled directly from the designer module.


Static Page vs Responsive Design

Because converted web applications and designer applications use different means to generate the web interface, the two methods yield different results. A web application created through the traditional conversion method will result in a static page. This means that, whatever you see in your workbook is going to be what your users see when it’s pushed to the web. Data models where the user interface is already built within the spreadsheet, the conversion approach will result in shorter development cycles. However, a web UI created with the conversion wizard is ‘static’ and doesn’t scale based on screen properties of the users accessing. If you need your users to be able access from mobile devices, this method can pose some limitations.

Designer applications, on the other hand, feature a responsive design. Pre-defined page breakpoints allow a web application to resize the page width and controls based on the screen properties of the user accessing it. Furthermore, web applications created with the designer module can be enhanced in look and feel using CSS stylesheets. You can either choose from built-in templates or create your own from the designer interface to customize your web application.


Workbook Versions vs Transactions

Traditional web applications and designer applications both allow versioning of your web applications to make it easier to apply and track changes. Converted applications can be updated by downloading the underlying workbook from the server, applying any changes in the spreadsheet, and then re-uploading to the server. Doing so, the server will assign a new version to your application. In other words, user interface changes and formula changes are both handled in the same workbook update

In designer applications, this behavior is handled through a transactions system. Since designer is completely web-based, changes to the user interface have to be done in the designer module. When making changes on a web application, you essentially create a new transaction on the server side. Once you publish your application, all updates will be pushed to the web. Formula and data updates in the workbook are handled and versioned independently by uploading a new version of the file.



Converted web applications and designer applications can incur different development cycles depending on workbook properties and project requirements. It’s fair to say that either method can be advantageous in certain cases.

Each input cell and save cell must be defined during the conversion process when using the Excel add-in. You then upload your workbook and everything is detected by SpreadsheetWEB to build the web application.

The designer module, however, requires all input and output cells to be defined as named ranges in the workbook, prior to uploading. This way, the software can access all data hooks and you must then map each element and database item to the corresponding named range. In some cases, this can mean a longer development period as this will incur more work before uploading a spreadsheet. On the other hand, this also means that you don’t have to build your web interface in Excel.

To summarize the advantages and disadvantages of each method,




Quick and easy user interface generation

Creates a static page – No responsive design

What you see in Excel is what you get in the web application

Fewer customization options

Doesn’t require named ranges to be defined

Requires some work in Excel, especially for updating applications

Somewhat faster deployment




Responsive design – Better access from mobile devices

Requires named ranges defined in the workbook to create inputs, outputs, and save fields

No need to use the spreadsheet for updating the UI

Takes somewhat more time to deploy

More customization options and custom styles

Check out our video tutorials to learn more about how to transform your Excel spreadsheets into web applications.