Join Sam Alexander ( @Sam Alexander ) in our first Ask the Expert session of 2020 (3rd - 14th Feb) on Cosmos UI
Meet Sam: Sam is a Senior Product Manager for Cosmos UI and UI-Kit at Pega. His extensive career background includes web and mobile software engineering and consulting, specializing in low-code application development.
I like the cosmos design. I assume that the cosmos design focusing more like a single web page application. So, there are no tab structure available to switch between work objects. User has to use either recently viewed items tab or browser back button to go back and forth. Is this understanding correct ?
When migrating the application to cosmos design, there are some requirements to update the cosmos theme in the application level, Is there a specific guidelines or standards you can point to follow when customizing the theme.
Indeed, Cosmos is built in a Single Page Application (SPA) architecture. Under the covers, we're using the platform's AJAX container, which allows you to load case data in portions of the screen. In addition to refreshing only portions of the page, this architecture allowed us to do powerful things like load case data in the "Preview panel" without losing your current context. And, this architecture significantly improves performance: the underlying JS and CSS is loaded and parsed only once (as opposed to tabbed multi doc dynamic container, which relies on underlying iframes and reloads/parses the JS every time).
Regarding working with case data in tabs: Yes, you can do that. In Cosmos, this is supported by opening case data in browser tabs (as opposed to in-app tabs using multi-doc DC). For any Link that calls "Open work", you can right click the link and select "Open in new browser tab." A new browser tab will render just your case (without the overall application navigation ribbon, which remains in the main tab).
Here's an animated gif demonstrating it:
As you mention, you can also use the browser back and forward buttons to navigate. (There were improvements in upcoming 8.4 release for this)
Regarding customizing the theme in Cosmos and guidelines: You should create a new skin and inherit from CosmosSkin (located Theme-Cosmos ruleset). I recommend a new skin because it's much easier to start fresh rather than fix up an existing skin with many custom formats, overrides, etc. Then, use App Studio to do basic branding, such as changing application logo, application title, and mixin colors.
Cosmos is a turnkey experience for case management applications, which means it's opinionated and prescriptive. We have an entire design organization that specializes in case management, and the idea is to provide you a ready-to-use, top-notch experience and allow you faster time to market, and to make upgrades to future versions of Cosmos seamless (as opposed to UI-Kit, where you Save-as rules and have to reconcile changes to those rules for every UI-Kit upgrade) Thus, stick as closely as possible to the Cosmos look and feel and functionality.
Avoid overriding skin formats specified in Cosmos.
Don't change the Theme-Cosmos sections to point to other design templates. For example, CaseHeader (the header in a case) is based on a design template called "Case header UI template". Don't point it somewhere else. This will break away from the Cosmos design system and it will break you when you upgrade to future versions of Cosmos. Use Cosmos as-is, mapping your data into the regions we provide, and upgrades should be seamless.
Thanks. I was thinking more in the terms of creating a basic wireframe. How to set up the main layout and play around with different components and actions through Sketch
My issue was after I set up Cosmos on Sketch I wasn't sure what to choose to start with the layout... I noticed in the Pega Design Studio there are several layout templates however in Sketch Libraries I could only find 3 or 4 examples of pre-populated screens
We are currently compiling the most common page templates for people to use in their app builds, as well as rules around when to design with what. I am interested, what are you trying to design specifically, so I can take it back to the team?
Actual uses cases help us make a more complete out-of-the-box package for you.
The below are my assumptions from the various conversation I have had:
1.) Sections should be made on design templates to make it make them React Components
2.) Each section will be a React Component
1.) If we build custom design templates, do we have to write our own React component generation code for the template. If yes, how complex / easy will it be to write for someone who already knows React?
2.) Will the actions like Run Activity, Refresh Section work in Cosmos UI? Is there any specific list of actions that will / will not work?
3.) Is there plan to support Grid Repeat, Repeating Dynamic layout, Layout groups in Design templates.
Also one suggestion:
Generally screens gets complex creating sections inside section or layouts inside layouts when we have to display questionnaire.
The main reason for creating section inside section being that the client side required condition check cannot be applied to inner section whereas the visibility condition translates to inner section. If Pega provides a way to couple visibility condition with Required Condition it will solve most of the issues and unnecessary complications. I am talking about a feature like the required condition will be checked only if the field is visible.
1) Correct, section rules should be based on design templates. For our OOTB design templates (1 column, "List item" templates, and others), the React component will already exist. For any custom design templates, a front-end developer will need to write a React component. For a developer knowledgeable in React, this should be straightforward. We have a strong front-end organization of React developers who will provide more guidance as we build out this architecture, so stay tuned.
2) Assuming you mean Cosmos UI that runs on our exiting UI architecture, yes, those work. If you're talking about the React-based UI engine, there will be further guidance as this architecture is built.
3) If I understand your question correctly, you're asking about the ability to add table (grid), RDL, and layout group directly from App Studio. Currently, developers must first create another non-templatized section that includes items, then use App Studio to do a section include to that section. There are no current plans to address that. This is a gap where you must use Designer Studio.
For your last question/comment, let me see if I can get a colleagues in the Core UI components group to respond.
Cosmos in Pega 8.3 did not yet have the mobile experience.
I'm happy to announce that Cosmos in Pega 8.4 includes a mobile experience for both the Pega Mobile Client (PMC) and mobile browser. Similar to desktop, many of the mobile aspects can be customized using App Studio.
Also, you can take advantage of new PMC features, such as native lists. There's a preconfigured mobile channel with the native features enabled, so you can just click to build for iOS or Android.
You should be fine with the accessibility framework. Generally, we test for accessibility while developing Cosmos. Though we strive to follow accessibility best practices, if you find something we missed, let us know.
Regarding UI-Kit and Cosmos: For a while now, we've spent considerable time evolving and improving UI-Kit, especially during my tenure. It is still supported. But we believe Cosmos is the strategic direction and that is where we're devoting our front-end resources. Cosmos will most definitely continue to improve, and it's a significant part of Project fnx, the "ongoing evolution of the underlying architecture of Pega Infinity."
UI-Kit 15 in upcoming 8.4 will only contain bug fixes reported by customers.
does this mean in the future Cosmos will be the "happy path"?
I'm trying to figure out if we should use Cosmos or UI Kit in my new project which has some back office and customer facing elements. Is there any comparison grid with pros & cons?
Yes, the front-end organization is investing in Cosmos and the new front-end architecture portion of Project fnx. While UI-Kit is still supported, we're not actively investing in it.
While I don't currently have a comparison grid with pros & cons, generally, Cosmos is a far more superior experience than UI-Kit. Besides the new visual treatment and interaction patterns for working with case data, the improved single page architecture Cosmos offers (where only small portions of the screen are refreshed) is a basic feature for all modern web apps these days. (Case Worker portal in UI-Kit was SPA, but Cosmos uses this architecture in more ways).
1. Our internal app teams will adopt Cosmos, as it is our strategic direction, but I cannot offer dates on when a framework will offer Cosmos.
2. Cosmos is prescriptive and opinionated about not only placement of items but also styling of items. This is to help teams build apps with an OOTB great experience as quickly as possible (faster time to market), improve consistency, and reduce code maintenance (I've seen apps with inconsistent styling and skin rules with so many skin formats that developers are not sure what a format does or if anyone is using it). The CosmoSkin skin offers opinionated styling for dropdowns. It is discouraged to override the styling.
You should definitely have your own app skin that inherits from CosmosSkin, which allows you to use App Studio "Settings" to do basic branding, like changing the mixin colors, modifying the app name, and modifying the app icon. But teams should not override skin formats in the Cosmos skin.