Understanding Customer's Canvas
- 5 minutes to read
Over the years Customer's Canvas has grown from a single ASP.NET application (known as the Design Editor) into a set of components that can be put into several arrangements, so it both can be considered a platform and a toolkit, depending on what components you choose. On the higher level we can distinguish a Presentation Layer, Functional Modules, and Admin Panels. Two of these components cannot be used together: BackOffice is a replacement for Control Panel and Packaging Generator cannot be used with BackOffice.
On the presentation level, we find the UI Framework at our service. It's a library for development of uncomplicated front-end application using JSON-formatted manifests. These manifests are interpreted and converted into an application made of widgets. There are widgets for input fields, galleries, and Functional Module components. For the Design Editor, the UI Framework is an optional level of abstraction (because DE has its own graphical user interface (GUI) with Iframe.JS) but for the Dynamic Image and Preflight it's a sole provider of GUI (unless you want to create your own front end).
These four functional modules serve different purposes:
- The Design Editor is the oldest and most versatile component. It's an ASP.NET application with built-in GUI (for end-users), C# REST API, and Iframe.JS for programmatic access to the front-end GUI. It mostly used as a WYSIWYG editor with a rich object model that can create documents based on PSD and IDML imports.
- The Dynamic Image is a GUI-free component that only has a REST API for interacting with PSD templates. You can think of it as a web service that can parse PSD files and generate images, based on your HTTP requests. It supports blend-modes, transforms (including warp), layer groups and can modify the content of layers. You can use the UI Framework to display results or handle it by your front-end code.
- Preflight is another web service that has no GUI on its own (you need to use the UI Framework or create it yourself). This component is an on-steroid image uploader that can inspect uploaded documents (mostly PDFs) and validate them against a set of rules.
- The Packaging Generator is a component that has the narrowest application – it can render die-cuts and interactive 3D previews of models (mostly packaging). It lacks GUI and REST API and can only be used in conjunction with the Design Editor; it's also incompatible with BackOffice.
- Control Panel is a down-to-Earth simplistic file manager with basic user-management features and built-in Shopify integration. The built-in file manager is suitable for small-to-medium sized projects but has troubles handling huge amounts of data and doesn't offer a built-in editor for templates (content managers must re-upload them and set behaviors using markers).
- BackOffice is a next-gen admin panel offers a more robust file manager, built-in editor for templates (unsurprisingly titled the Template Editor), better user management (with SSO and built-in integrations with Shopify, nopCommerce, and WooCommerce), and most importantly a new cloud-ready architecture can accommodate all Functional Modules (excluding the Packaging Generator) and serve a cohesive platform thanks to a set of REST APIs that make integration of Functional Modules more abstract and straightforward.
As mentioned above, you can be creative in integrating different components into your system. However, there are several nuances that you need to be aware of, including compatibility, hosting requirements, and trade-offs. There are two default arrangements with admin panels (cloud-ready with BackOffice and VM-ready with Control Panel) as well as less typical solitary installations of the Design Editor and/or the Dynamic Image.
BackOffice requires Azure as a hosting platform because of many Azure-specific services (like Azure Functions) and time-consuming to deploy and costly to upkeep, thus it almost exclusively available under a SaaS subscription, only the biggest and most demanding project requires a dedicated instance of BackOffice. This complexity is justified considering a rich set of APIs serving as gateways to Functional Modules extending their functionality. For instance,
RenderingService provides with a robust queue manager for handling Design Editor-produced PDFs and serving them over FTP to your hot folder; or
Storefront APIs gives projects, that are designed for keeping track of user-created personalizations in the context of an order. This arrangement provides you with the latest-and-greatest features and can be considered as a starting point in your development process (unless you have your own admin panel that handles graphic assets – in this case you might consider a solitude installation of the Design Editor and/or the Dynamic Image).
When neither Azure hosting nor cloud-subscription is an option, you might consider VM-ready arrangement with Control Panel. In this case, all components must be deployed to a Windows server (VPS or a dedicated server) and can utilize a shared storage. It's a viable solution, but Control Panel is a mature component that is no longer actively developed, so this option cannot be considered future-proof and should be chosen due to hosting requirements.
When your requirements are focused only on the functionality that is provided by the Design Editor, Dynamic Image, or Preflight, you can drop an admin from your list and use these components directly. In this case, the UI Framework is an optional layer abstraction on the front end. This option is justified when you are sure that BackOffice APIs doesn't add value to your project. Because Design Editor is supplied with its own GUI, REST and JS APIs, you can integrate it with or without the UI Framework. In this case, you get a powerful WYSIWYG graphic editor with basic backend APIs and versatile front end. The Dynamic Image is typically integrated via custom front-end integration due to simplicity of the undertaking (you just need to send a POST request and display an image that was served back to you). Preflight has a REST API that can tell you useful information about the uploaded document and GUI that is provided by the UI Framework (as one of the widgets); you can develop your own front end but it's uncommon. The Packaging Generator can be used only with the Design Editor due to its limited API.