Pega now offers extensive user experience (UX) capabilities and enhancements, including Cosmos React – the latest version of the Pega Cosmos design system, and Pega Constellation – a new UI architecture that shifts the way low code and experienced developers build Pega applications.
On February 22 and 24 we hosted the cLSA Community event where Sam Alexander (Sr Product Manager User Experience) covered the key design constructs and workings of Cosmos React, its design philosophy, and the latest capabilities, as well as how you can select the right front-end solution for your applications. In this event he also discussed the Constellation UI architecture for advanced use cases, including extension of DX components, a breakdown of new web self-service capabilities, and API integration. The presentation concluded with reviewing the phased approach for migrating applications to Cosmos React on Constellation.
In this post you will find the Q&A of the sessions; ordered by topic. This contains the questions that were asked in the Q&A chat window with the answers to the questions.
What skillset and Pega training does a Citizen Developer need to build in the three UI options on top?
UI-Kit and Theme Cosmos, both based on our existing UI architecture (Section rules, Skin rules, etc) require sklls in Pega UI, and front-end skills are also recommended. Improving the UI authoring experinence for citizen and professional developers alike, building Cosmos React UI with Views in the new front-end architecture (Constellation) does not require heavy skils in Pega UI, such as dynamic layouts, container formats, etc.
Should Pega developers enhance React and JS skills?
The goal of Cosmos React UX library is to offer the majority of components needed to produce an outcome, configurable in App Studio. For advanced use cases, professional front-end developers knowledgable in ReactJS and the web technologies can, in code, put together the Cosmos components in a different way to create something new.
When to use what
Do we still have the ability to choose UI-Kit or Cosmos based UI for new pega apps from v 8.3 and above?
UI-Kit and Theme Cosmos, both based on our existing UI architecture (Section rules, Skin rules, etc) are available and will be used for years to come. Starting in 8.7, the new application wizard does not offer UI-Kit as a choice, but you can stil reconfigure your application definition rule to use it.
When would we actually choose UIKit over cosmos and other way around? Is there any best practice around choosing one over the other?
While Cosmos is designed to improve the case worker experience, uniformity across the application stack, seamless upgrades, and quicker time to value, UI-Kit is an option when heavy customization is prioritized. Clients should review the needed capabilities and choose the UI architecture that provides them. For example, as of 8.7, offline support for native mobile still require s Section-based UI architecture with either UI-Kit or Theme-Cosmos.
Is SDK/DX API V2 the way to go when implementing a portal that is focussed on a non-technical user or user that is using the application only a single time? The Cosmos React approach focusses on a portal that applies to a user of the business that is working with the application as part of his/her core work so that isn't really suited for this purpose.
When you say "non-technical" user, I’m assuming this can also be intrepretted to mean a user who needs a simpler experience to complete a simplistic task, without the extra features Cosmos provides for case workers working on a more complex case flow. What you describe is a "Web Self Service" use case. (See slides starting from slide 53). The SDKs is suitable when you need stricture control over the markup. Offering a quicker time to value, web embed allows you to inject workflow (Pega-generated UI) into an external application. Possibly in a release to come, a Self Service Portal capability will allow app developers to configure/create a full portal and prescribed overall experience for simplified B2B and/or B2C use cases.
is there a benefit of moving to Theme cosmos from UI-Kit before moving to Cosmos React?
For most existing applications built with UI-Kit, we recommend a phased, planned approach to migrate directly to Cosmos React.
As Theme Cosmos is rule based with sections, we are able to create some complex layouts like a Repeating Grid layout. But for Cosmos React, is Pega looking for some upgrades on the layout part in later future as we are using the view based approach?
To provide quicker time to value, pixel-perfect UI, and consistency across the application (which can reduce training time, as the overall experience is simliar), the View construct in the new architecutre, based on an underlying "template" is our strategic direction. Based on feedback from you, we may decide to offer additional OOTB templates. When there's a repeatable pattern needed for your organization, the new architecture provides "Custom DX components", an extension point for creating a new template (that can then be used by low code developers) or widgets. Keep in mind that in most cases, devleloping a new template is not needed; most layout designs can be achieved using the composition pattern nest embedded views, all of which are themselves based on OOTB layout templates. Using OOTB templates and other contructs offers the quickest time to value and lowest total cost of ownership.
Do you recommend to build new applications on new cosmos UI not using sections?
As of Pega 8.7, the recommendation is to use Cosmos React **for new apps** ... stick with what you are on for existing apps
Angular-sdk was released on August 6th 2021. When can we expect new Angular-SDK release?
The 8.7 compatibility release for Angular and React are in final phase release preparation. Expect new releases in March. We've adopted a new versioning. Angular and React releases are SP-A.87.0 and SP-R.87.1. SDKs for Cosmos React V2 follow the same version accept SP is replaced with SDK.
Is there any plan to upgrade DX starter packs to support DX API version 2?
Alternate technology stack for Cosmos React/DX API V2 are called SDKs. SDK is used given use of ConstellationJS engine APIs instead of direct DX API implementation. SDKs are available for React, Angular and web components on Marketplace. Corresponding code repos are on Pega GitHub. 8.7 versions are SDKs are in progress and will be released in March.
Cosmos DX Components
How to develop custom DX components for Cosmos React? Any docs on it?
Is there an easy straight-forward way to migrate from Theme-Cosmos to Cosmos-React? (with little to no need to build/rebuild rules)
For existing Theme Cosmos applications that are built within guardrails; that leverage the OOTB design templates from the Theme-Cosmos ruleset for pyCaseMainInner and embedded Sections (CaseHeader, CaseDetails, etc); and that leverage OTTB design templates (1 column, two column, etc) for screens in the flow where possible, migration should be easier, as those same template constructs exist in both architectures. Migrating an app still requires reconfiguring the application by a professional Pega developer. Right now, developers would neet to reconfigure tabular data and other lists UI. Developers may need to reconfigure portions of the data model to use Data Pages. As re-architecting the front-end architectrue is a major project, Pega has primarily focused build-from-scratch applications for production. Now that we're confident with teh capabilities in 8.7, Pega can begin providing migration guidance in the 8.8 timeframe.
Will a migration wizard be made available for move from UI-Kit to Theme Cosmos/ React?
In 8.6 and 8.7, Pega's priority was re-architecting the front-end architecture (a massive effort) with a focus on ensuring production-ready build-from-scratch (new) applications. Now that we're confident in its capabilites and quality for new applications for 8.7, we can begin focusing some of our efforts on providing migration guidance. The UI-Kit experience and the Cosmos experience are considerably different, analagous to moving an application from one design system such as Bootstrap to another design system such as Google Material Design, thus a wizard that would automate all of it is near impossible. However, there's enormous potential to help clients with guidance, and perhaps tooling to inspect the existing application to identify migration tasks to do, and perhaps tools to automate certain migration tasks. As an example, a "readiness" app could detect a data source not sourced by a data page. (In Cosmos React, data must be sourced by data pages). Watch for migration guidance in the forthcoming relese.
As cosmos react is a single document application, how can applications that primarily rely on Multi-Thread UI design can migrate to Cosmos. Will cosmos push businesses to rethink their business design and move to single thread design?
Cosmos React is built on DX API V2 which employs a stateless Rest Connector. The concept of threading isn't relavent given clipboard data isn't maintained between Rest calls. New pattern for SOR update is "all data mutations occur withing the case" which is transactionally managed and commited by Pega infrastructure. Combining Savable data pages with auto-populate property on the case are the primary pattern for moving to and from the case for user update from customer SOR.
Will ABAC work on Customer UI service. For example: Masking some property values based on ABAC.
DXAPI supports ABAC rules and dxapi response will hold that information
Can we have a button on Cosmos React? For example I wanted to have a filter fields and a search button. and on click of that button some action needs to be performed?
You don't configure buttons. You have data patterns and vew definitions. Based upon that you will get the search functionality.
Cosmos React is Data Model driven interface. But how to add something that isn't really related to the data? Like Modal Windows or Buttons?
You can run local actions there, so it is data driven or process driven. But you need to design it to view it. Modals are not yet supported.
Cosmos favours the employee experience . I also heard that there will be focus on web self service. Is there anything comming that focuses more on the B2C aspects of a design system?
Yes, as mentioned during the presentation, WSS offerings include 1) Web Embed, a way to inject Pega workflow and generated UI (not the full portal) into another web application 2) SDK's, which offer more control over the markup, and 3) we're exploring offering a way to configure, through App Studio, a full web self service portal with a prescribed overall experience that is targeted for B2C (or B2B) users.
In Cosmos can we have multiple cases opened at same time in tabs like older UI Kit based design?
Modern browers are extremly efficient at managing browser tabs. In Cosmos, we leverage that: end-users can open and work on multiple cases in separate browser tabs. At this time, we do not plan to offer in-application tabs.
Will there be an impact the Pega's Offline capability - positive or negative - when moving to React?
Pega offline supprt in the new architecture is being planned. For further details, reach out to your Account Executive who can connect you with Product Managers resonsible for our mobility solutions
Will you at some point allow to change the whole portal not just case flow actions on React app inside Pega ? May be when the full self service portal will be available ? I understand now it would require to design using Pega SDK an equivalent of your provided constellation interface if we want to change header or menu of the user portal.
In the SDK there is an example app with a stand alone flow (embed) and a full case view version. So it is possible with the SDK and example is provided.
Will there be change in authentication architecture?
No change, all types are supported.
What is the alternative for action sets?
To achieve faster time to value, our goal is to capture typical "patterns" and allow you to easily configure those patterns via App Studio, without complex work or maintainence (low-code). To recap an example from the deck: an example of a pattern is "Search & select anothe case or data reference as part of my assignment." In the past, developers must build a form; build up the logic in activities/service calls/etc; configure the Action Set; configure the table; etc. Added, this expeirence might not be consistent across the app stack. In Cosmos React, leveraging a Data Reference or Case Reference field in a View allows you to simply enable this behavior, and all of the UI and connectivity is configured for you -- and it's consistent across the application stack. This is enormously powerful.
Another use case we're considering is a pattern of "Search and populate", basically a way to type in a value, make a service call, and automatically populate fields below based on the results. An example might be entering a vehicle VIN number, calling a third party service, and populating the rest of the form fields below with the values. In the past, this would need to be configured via Action Sets, but this is certainly a pattern we can capture.
The challenge with offering the abilty to drop a Button and configure an Action Set to do whatever you want is that it can lead to inconsistent experiences, code maintainence, upgrade friction, and other challenges. We want to offer you the outcome you need, OOTB, that is upgrade-proof. Keep in mind that, for advanced use cases, professional developers can extend Cosmos via a custom DX component.
I am quite sure we need to capture more patterns. Please respond below if you have patterns that need to be captured. As mentioned during the presentation, we need YOU, and we genuinely want to help you build stellar apps quicker.
Is the Skin Rule used for Cosmos React?
No, it does not leverage an appliation Skin rule. One of my favorite powerful features about Cosmos React is that it is super-easy to configure applicaton branding and styling via App Studio. In fact, to improve accessibility, App Studio will warn you if color combinations would result in Accessibility failures.
While most styling can be achived via App Studio's branding and themeing, we may plan to offer access to certain "design tokens" for the core Cosmos components. Unlike styling with CSS which can lead to inconsistency, "design tokens" are supported points of variability on a component, basially a schema-driven way to target and modify certain styling attrbutes. As an example: for a Channel, you can enable the "Application header", which will render an applciation header across the entire application. The App Header is a core cosmos component in the Cosmos design system. With App Studio, you currently cannot change the background color of the App Header component. However, the App Header exposes a design token for the background color.
We are considering when and how to expose this additional level of styling granularity.
Will we be able to open Views in Dev Studio?
You can open a view rule but you can not edit or modify the view from Dev Studio
About semantic URLS; on React is it using URL Mappings? I created a React application on 8.7 and there doesn't seem to be a default configuration of URL Mapping, where do we define the URLs?
The semantic URLS in a Cosmos React application are automatically generated in a consistent way.
How does the new DOM looks like. Will it still have a table?
The new markup leverages the latest HTML capabilities to produce efficient and semantic markup with huge gains in accessibility. There are various ways to configure tabluar data in Cosmos React. The markup for a table is div-based.
Can we render view based UI created for Cosmos React through Theme Cosmos instead of Cosmos React?
Yes this is possible using web self service
If we start with cosmos react and later some requirement comes which is not achievable, is it possible to switch to theme cosmos without the need to start over?
No its not possible to revert back
Does constellation system conversion process from view to react js leads to slowness? In general view has to be independent right?
The View itself is not React specific, it is a lighter-weight collection of fields that placed in regions of a template. It drives the content of a DX API JSON response which Constellation correlates to React components in the browser. Smaller network footprint, and UI construction happens on the client.
Is it possible to set up an action on select/change of a field using Cosmos UI?
This is not possible in Cosmos React app; all refresh intelligence is being handled implicitly.
With respect to accessibility we have roles but for ARIA Properties/States will be done through JS . Can we configure this in pega?
When will the pega applications be available on cosmos react?
The strategic apps from Pega have their own roadmap for Cosmos React adoption. I recommend contacting your Account Executive who can connect you with my colleagues in Product Management who are responsible for that app.
Our application builds on the strategic application (CS) which is not yet on Cosmos, so is it a good idea to change our application to cosmos, or should we continue to use UI-Kit?
Recommended to wait till CS comes with Cosmos React
Is there any plan to rollout Cosmos React for Pega Personal Edition?
Cosmos React is part of Pega Platform. It has a dependency on a Static Content Service which is available as a Docker image
How do i setup a constellation server?
Assuming the question is referring to the Static Content server which his require for Cosmos React/Constellation enviornments. For environments in the Pega cloud, no configuration is necessary, the static content server is already configured. For on-prem environments, the static content server is offered as an image. See https://docs.pega.com/user-experience/85/implementing-cosmos-react-ui-pega-platform for more details