Name: Unlocking Next-level UX in Rocket® Uniface
Uploaded: 2026-05-07T15:32:05.300Z
Duration: 57 min 28 s
Description: Unlocking Next-level UX in Rocket® Uniface

Transcript for "Unlocking Next-level UX in Rocket® Uniface": Can everyone hear me? Perfect. Yes. Give everyone a few minutes to log on, and then we'll get started. Okay. I think we can get started, everyone. Thank you so much for coming to the webinar about unlocking your next level user experience with Uniface. My name is Lindsay Buchanan. I do marketing for Uniface. I'm based out of Oklahoma City. Just a few housekeeping items before we get started. We're going to be recording today's session, and the links will be posted on the forum, so keep an eye out for that. We also like our session to be as interactive as possible. So if you have any questions, just put them in the q and a or raise your hand. If you see or if you're experiencing any technical difficulties, you can post them in the q and a as well, and I will reach out. And we're going to, again, post it on the forum, the links. And if you have any questions, just let me know. And now I will hand it over to an introduction from our speakers. Thank you so much, everyone. Hi, everyone. I'm Mike Taylor. I think pretty much most of you know me by now. Well, at least I hope you do. Today is, we're talk gonna be talking about, Uniface UX. This is, the Uniface's out of the box experience, and, of of, out of box experience for creating, suddenly good looking websites. You know, and we wanna be able to do this with absolutely no requirement for HTML, JavaScript, and CSS within the interface environment. So these are are dynamic pages being generated for you. You know, for our customers, it's becoming increasingly cuss critical that, we're we're able to deliver high quality applications to our end users, and and this is is our answer to it. You know, we we are very proud of the Uniface UX. We've been going through a journey over the last few years in order to be able to bring Uniface UX, to you. And, you know, quite recently, we've released the final part, piece in that puzzle of of moving it not just from, from the field level, but to entry level and now into component level. And this this is completely removing the requirement to have, that that template being developed within Uniface. And that really does boost productivity. It gives great looking applications. It gives the ability to have, you know, built in accessibility, and and the things which are absolutely critical in today's applications all without having to create that that template. The the component level, you know, it it finishes that step. So we're we're really happy to bring this to you. I'm gonna stop talking now and hand over to to Joti. Joti is our product man product owner, for the the Uniface UX project. And, you know, we're we're looking forward to to getting your feedback on on what's being talked about today. So, Jyoti, over to you. Yeah. Thank you, Mike. Thanks, thanks, Mike, for setting the stage, and welcome everybody for Uniface UX webinar. Next sessions, I will be leading along with Anushi with me, And let's get started without any delay because our agenda is quite packed for today. So the looking at the agenda, we'll have a very quick introduction of Uniface UX. I think maybe most of us, you are already aware of why it matters and where does it fit to your business need, but still we will get everyone on the same page. So we'll have a quick introduction on that. Some key feature highlights of Uniface UX. So, uniface UX widgets out of the box constructs, UX widget interface, the component level UX release, which Mike just spoken about, and a live demo, seeing Uniface UX in action and hope that will inspire you more on what we have introduced already, with using Uniface UX. So all the above points, I will be, taking along. The next sec segment about building a custom UX widget, that's something you Anushri will lead us to, and she will be, taking us to building a custom UX widget experience using different approaches, UX interface API and UX widget framework, and then see how does it it it feels to you. So let's get cracking. So introduction to Uniface UX. I mean, in general, the core concept of Uniface UX is has been a good UX, user experience or a user centered design, which is essential. I think most of us, we agree by now. And there are more a number of benefits you can get having a good, user centered design and a good user experience. Some of us, some of those points I have listed here, but there are many more which, we all understand. I mean, improved user satisfaction. I mean, once you have an intuitive and well designed UX, then the learning curve for your users are less, and then users are likely to engage more and return to the application that are easy to use. It will have reduced maintenance and support cost because a well designed, a UX has less user errors and, less, confusions. It brings a stronger, brand reputation, because a consistent and responsible, interface builds user confidence and a positive experience that leads to higher satisfaction and retention. Accessibility, of course, now accessibility is not an option anymore. So modern UX practices, the the ensures the applications are usable across multiple devices, screen sizes, and the user capability. So all in all, in nutshell, good UX leads to higher adoption, better performance, lower costs, and stronger business impact. And that has been the core, let's say, intention of Uniface UX. So Uniface UX, it builds, it brings out of the box solution to modernize and enhance your applications, UI, and UX. It consists of reusable UX building blocks that follow modern UI and UX pattern, and then you can apply your own UX design if you want. It comes with its own UX, default UX design. And then, you can name all the, good, let's say, features, responsiveness, accessibility, all that is part of those UX, reusable UX building blocks. And all those experience by keeping the low low code and high productivity, building experience in mind because that's, again, core of Uniphase as a low code platform. So some key feature highlights. The very first key feature is out of box reusable building blocks. They are called UX widgets. UX widgets are basically they encapsulate the UX and UI logic in in in those UX widgets. And they are reusable UI constructs, and that consists of, default UX design system. In our case, we are using fluent design system, but you can also choose your own design system, for your need if you like. And using these consistent UI, building blocks will bring a consistent presentation for your entire application if you start using, the the widget, approach. Also, this widget approach will let you not distracted by UI complexity and let you focus on the business logic. So those are the benefits you would start getting when you start applying, the Uniface UX in your application building, paradigm. Where are those UX widget made available? Also, Mike introduced that they were they start now they are they are available at Uniface development object level. We started, with the free level, extended them to entity level, and now they are available at the component level in itself. So Uniface IDE has been enhanced, greatly to support the Uniface UX development. And that means if you you can browse through the resource browser or you can browse through the property inspector, you can get the list of all the UX widgets being made available and all the configuration properties made made available on the Uniface UX for for an efficient, development using Uniface UX sets. Also, the last point but very powerful that u s using Uniface UX, you do not need, any HTML layout to be specified. It does not need any, layout to be specified and layout I mean, HTML, CSS, and JavaScript, which you might have to write for a classic DSP if you have that experience. And using Uniface UX, it takes away that need. So it it it brings a great value on, having the higher productivity while you want to build, an application a web application using complex, of temp complex UI and the modern UX experience. The next key feature, key widget UX widget interface. UX widget interface is so out of the box, widgets has been created using UX widget interface, And we have also opened up and and we, and made that available for you if you want to implement your own custom UX widget entirely using, your own preferred, design system, or you can extend an existing UX widget that also you can do using this, widget interface API. And the reason to made it available because no matter the set of UX widgets, is made available, there will always be a need that you might want to tweak some existing widgets, based on your own need, or even you might want to create a widget on completely for your own design system. So you can make use of these, APIs, and then, create them. And creating, an encapsulated widget, as was also mentioned earlier has its own benefit because it decouples the UX and UI concerns from the business logic, and it lets you focus, on your business logic. And you can reuse those UX and UI assets, and that will bring the consistent presentation layer on your, application. These UX widget interface are available through API functions, and it it lets and they are they hooks to different UX widget life cycle and let you control, via different which UX widget states. So for example, to create the widget, layout, there are there is a process layout API, which can hold the, the layout logic for a widget. Then we have the data life cycle management that where we can allow the interaction between the widget and the Uniface data object, meaning that Uniface data object meaning component or entity or field. So if the field value has been updated, how would the widget be updated for that? So all those kind of, let's say, interaction between the Uniface data object and widget, those data life cycle API like data in it, data update, and data cleanup are being made available. There are some APIs on the UI control level like block UI, unblock UI, and if on the and also validation and error reporting kind of API. So if you want to add your own validation logic, HTML five validation logic, your own, error reporting logic while validation fails, so those APIs are made available, let you, enable that. Moving on. A sneak peek of the component level UX, which has been, released early this year. So we enable the component level UX support at at the, so we we enable the support of Uniface UX at the component level earlier, on top of the, field level and, entity level which existed earlier. And having the support at the component level, it basically completes the, support of Uniface UX on entire development object on Uniface. And looking at DSP, that means you can create a complete DSP using Uniface UX. If you have already experienced creating a classic DSP where you need to specify your, layout, either external layout or specify the layout in the design layout tab in IDE, and layout, I mean, HTML, CSS, and JavaScript for your application presentation UI logic. With Uniface UX, that need is gone. So you do not Uniface takes away that need, and Uniface itself generates the the layout, which has all the great UI and UX, experience for that particular widget. And the the those are those generation layout generation are being added using the layout mode property, which I will show you in my demo shortly. But these are just the highlighting bit. So layout mode property, I think, is a very is is a great great feature which has been enabled for automatic layout generation. And on top of that, if you still feel the need that you have to tweak your layout little bit here and there, we have provided a global proxy library using which you and they are being made available so you can, and there are hooks there. So you can just go into those hooks and changes, make your changes if the need be. UX interface also has been enhanced for component level, needless to say, because, they have been supported on entity and field level, and the similar set of APIs have been extended also for the component level. Along with the, other sets of UX widgets, now we have a set of UX widgets available at component level. One of them is UX header footer, and another one is UX layout. And these widgets have specific purposes. So for example, UX header footer, it creates the layout of the DSP screen, the main page, DSP in a header, main and the footer kind of construction. And it's also quite a common pattern to look at any any other main web page that it comes with that pattern. So that's why it's it's one of our first, component level, widget introduced. UX layout is another widget which, just, it it it simply creates its children in in a specific way either in in the vertical way or on, in the horizontal way. So those are the set of widgets already introduced at the component level. And last point and not least, that IDE templates and palettes have also been updated for UX development. So using those, you can have an efficient, DSP development using Uniphase UX. Moving on. Okay. So it's the demo time. Great. Now I will show a very quick demo. I will I am sharing my IDE. Hopefully, it's visible. We are looking at the project editor, of the IDE, and now we will be quickly we we will be building a DSP using Uniface UX from the scratch, and then we will be tweaking some of the properties here and there and see how easy it is to using Uniphase, first of all, build a complete DSP application. But also tweaking a configuration lets you change your, UI and UX without touching anything else and how easy it is. So, let's get started. So, the project palette here, I have a filter applied here. So let's this is your original mode. You can filter, based on the UX, and then you get the UX specific, component, templates, available here. I will make use of the header and footer template because I want to create a DSP with the header and footer, kind of layout. And then I will double click on that. That will open up my DSP. So it opens up my DSP. It's it's an empty one, and now we are going to fill it up. But before doing that, let's have a quick look at, two properties here. One is the DSP widget type, which is now UX header footer. And that means the intention of this that the layout generated by this widget will be header, main and the footer kind of, visualization. Another important property is the layout mode, and you see the value set here is generated. So these two combination, will basically let Uniface say that I want to generate the layout. So Uniface will generate layout for me, and I will not have to specify the layout by myself. There are other values of this property. So, generated is the one where Uniface takes over. Full document is the backward compatible. So, the classic DSP mode where, you have I have to specify the layout, and then Uniphase will, not take over the, the layout generation control. And the fragment is somewhere in between. So let's start, building this DSP. We also have, for example, here in the resource browser, a number of, entity and the field templates available. At the entity level, we have UX layout and the UX data grid. UX layout is is one which just lays its children out either in the it arranges its children either in the vertically and or in the horizontal way, which is also a very useful, let's say, layout arrangement you you want very frequently. And other one is UX data grid, which already existed, so it represents in the grid, grid fashion. And there are other three level templates available. So for the header, main, and footer kind of construction, I would need three entities, one to represent the header, one to represent the main, the data, and the other one, as a footer. So let's start building that. So I will just simply use one of the UX layout entity template, for my header entity. And in order to show some content in my header, I will just use one of the field. And then I will say, I will have some text in that field which will represent, in my header text. That's it. My header is complete. For the main section, then I would use a data grid entity because I want to represent, I would I want to show some data. So that's why it's a UX data grid type of entity. And in order to have the entity, I will use one of my existing model entity. It also have some data, so then we could immediately see the result. So I will simply reuse the student dot MST and then drag and drop all its fields at as the children, except for ID because ID field is not interesting here. Also, just to highlight that all the field level, even of, fields have fields are using the UX widget type. So all of them are making use of the UX constructs. So now my data entity is also ready. The content entity is also ready. Next, I would need a footer entity for that. Also, I would simply drag and drop a layout, UX layout type of entity widget, and I need some, buttons as a footer. So I would simply drag and drop some UX buttons. So the DSP widget type is UX button, and they have some logic to do clear, retrieve, update, and remove on this data. That's all. So my DSP structure is basically ready. If you have that, experience from classic DSP, the next step would be that you go to the design layout probably and add your own layout. In this case, as I mentioned that we do not need to add any layout, so our design layout tab is empty in this case, and Uniface will generate the layout for us. Before running the DSP, the only thing we need to make sure that we have a retrieve instruction in the exec operation. So that is the only thing I would need to add. And this will make sure that, whenever the page comes up, the data is being retrieved. And now my DSP is ready. So we only prepared the DSP structure using Uniface UX construct, make sure there is a retrieve instruction to retrieve the data, and that's it. So let's compile and test and see, what we get as a result of this. And this will open up a browser, and here we go. So this is the result we get. So we have this header, created. There's some header appearance. There is some footer with four buttons. Header has the text which we had added, and we have some data in the in the main section. Header is kind of fixed. It is not scrollable, and footer is also fixed, sticky, as we call them, and it is non scrollable. Header has some appearance default appearance, like, it gets some bluish background. Footer as well gets some grayish background. Also, the children of the footer, they they follow their parents. So they they even the buttons, they are also getting the same background as the footer itself. And all those behavior, it's coming from that UX header footer widget. So all those logic are part of that UX header footer widget. So that's just from the UI point of view. Also from the, let's say, the other aspects of UX like accessibility. So the header and footer, they are making use of the, right roles. So you can, as we call them, accessibility attributes, etcetera. So those have been added here so you can, use the screen reader, for example. The keyboard navigation, so tabbing and then, right, arrow key, down arrow key has been supported. So that's all part of the the widget itself. We do not need to do anything around that. And responsiveness. So for whatever reasons, if the screen size gets reduced, then it will, start to add scroll bar in itself. So if I try to adjust the screen size, you see some scroll bar starts to appear and and it disappears when the screen fits. So all those all this logic is part of this default, widget which comes up with with, which Uniphase has created. But on top of, the existing defaults, if you want to tweak their behavior, then we can make use of the widget properties, as provided at different level to tweak the behavior, and they are and and that's what we are going to do next. So on top of, this default behavior, let's see what behavior we want we can tweak and like to see. So one of the thing, for example, is in this case, we see the footer is sticky, which is, I think, in this case, is is what I would like. I can add more data, and the dough data is scrollable. However, I want the, let's say, the the footer to be there so that I can interact with my data, and they they are always be on my face. But let's for for our, let's say, testing's sake, try to make the footer, scrollable. So let's try to do that. So in this case, what we are saying that we want this footer of this header, of this component level widget to be sticky. So let's see what we would do. So for that, we need to go to the widget, the component level widget, the UX header footer widget, and we go to the DSP widget property. We will see we see that the property inspector has been enhanced with the relevant, how we call it slots. So that's how, let's say the, layout management has been handled by Uniface. There is a slot for, footer. There is a slot for header, and there is a slot for main. And each slot contains some very interesting properties. So for example, layout type is an a very interesting property. So each slot comes with a a layout type. So how does, a slot wants its children to be, let's say, organized? Usually, for example, for header and for footer. For footer in this case, we see the children are organized. The buttons, they are in horizontal way. So that's the default layout type for, for the footer slot. Then there are horizontal alignment. How do you want to see the children being aligned to each other? And all those syntax hints are there to help you knowing what each property is. And on top of that, the Uniface documentation helps you if, if the need be. So in this case, what we wanted to tweak is the footer placement that we want to make the footer, nonsticky and make it scrollable, and that's where the footer placement property comes into picture. So here it says the sticky is the default, whereas what we want to change it to is the scroll. So let's just try it and see what happens. Compile and refresh it. And we see now the footer is gone. It's not there on on the on the face anymore. We have to scroll to get to the footer. So that's that's just changing one property, and you see the the behavior is right on, right on the face. Let's try to tweak some more properties. In this case, what I do not like and I want to change is that, again, coming back to the footer, that the children, these buttons, they are equally spaced. That's the default behavior. But for this reason, I do not want them to be equally spaced, but I would rather like them to sit somewhere together at the start. So what we want is the footer entity itself, the children alignment of the children of this footer entity, to be changed. So that's my goal, in this case. So let's go to the footer entity. Before that, I would clear out this scroll because I don't like this scroll at least for my use case, so I will clear that one out. Let's go to the footer entity, and now we are looking at this entity which represents the footer there. And then we go to the DSP widget property of that entity. That also contains some very interesting properties, appearance property, which I will also show you, later. There are some label related properties. Layout property is is the one where we are going to make changes because layout type is the one which controls how the children are, whether they are placed vertically or horizontally, and there are alignment properties to control the alignment. So in this case, we want to control the horizontal alignment. So that's where we will be looking at, and there are different values for the horizontal alignment. In this case, we want them to sit at the start. So all the buttons, of the, footer entity, I want them to horizontally align and sit at the start. So that's why I select that property. I compile it and then refresh my screen, and then we will, look at the footer. And then we see that, now all the children button, they are together at the beginning of of this of the footer itself. So that's how you can change even the children alignment, in any of the slots. So this is one example I took for for the footer slot, but that can be done for the other slots as well. Now next thing, what I am going to show you is how this the slotting works or the layout indexing work. And what I mean with that is if you remember that on on the we have three entities here. And by default, Uniface takes the first entity to the header, next entity to the to the main slot, and the last entity to the footer slot. But what happens if we have more than one entities or even less than three entities, for example? So let's try to build a let's try to add one more entity and see what Uniface does after that. So I will add just one entity somewhere in between. So let's just before this, the the student entity. And the idea of, what I am trying to build is to have some filtering logic on this data. So for example, just on the subject, I want to filter, all the records. So for that, I would need, let's say, list box where I can specify all the valid subjects. And based on those subjects, I will filter the data. So I will add those, in the wall rep. And in the on change of this list box, I would say that, if something changes, then please fetch that data. That's the whole purpose. So the logic is not that important. The only thing is that if we are making change to UI, how does Uniphase behave? So if we are adding an extra UI here extra entity here, how does, Uniphase reacts in terms of its UI logic? So that's the thing which we are interest interested to see. So if I refresh it and see where does that extra entity is going. So what we see here that extra, this entity is coming here. So header stays at its place, footer stays at its place, and that extra entity is added in the main slot. So that's how the default slotting and indexing mechanism works for Uniphase that the first entity goes to the header, the last one to the footer, and anyone in between, they are added to, to the main slot. I will show some more examples around the slotting and how can you customize that. But before that, one more thing to just tweak here, that what I I want to change or and and I do not like in this case that my main slot so the entities two two entities sitting in my main slot, they are vertically one after the, one after each other. Rather, I would like them to be placed horizontally one after to each other. So that that will give me from the UI point of view for my use case, that's how I want to build. So let's try to tweak that. So in this case, what I'm trying to say that the main slot, I want to change the layout arrangement of its children. So let's do that. We again go back to the component level, widget, DSP widget property. This time, we are looking at the main slot, and then we say that layout type, which is default, is you would say vertically scroll because that's that's why they are sitting vertically next to each other. We want to change that and say horizontal scroll. And let's compile it and test it. And you see now that the entities are sitting next to each other, and this to me, it feels UI, more intuitive. They are more like the master detail construction. You select one, and then you see the the logic is reflected. So the business logic remains working. It's just that all those, using those properties, we are just playing with the UI and UX experience of that whole widget. So that that's screen so UI wise, it looks good. The next thing which I wanted to, also experiment and then, let us know that for example, in this case, what we tried just now, how the default indexing works. So if there are more than, first entities going to the header, last one to the footer, and more than, and any, any entities in between, they just go to the main slot. If there are, for example, less than three entities or two entities, so first entity goes to the header. The second one goes to the the main because main is kind of always mandatory. If you have one entity, then that goes to the main. So that's the default indexing mechanism. I mean, you do not need to memorize it. It's all documented. So when the need be, you can go and refer to the documentation. But the thing to highlight here is what if you want to not use the default indexing mechanism of Uniphase, but you rather want the entities to choose which slot I want to go to. So that is also possible, and that is something and that is possible using the area slot property so that that we will build, just now. So what what we want to do here is that, for example, here we say that, the first, except for this student entity, rest all entity can go to, let's say, header slot. So let's try to build that part. So we say that this entity, this entity, and this entity, and I want to change the property of those entities. And that property is the area slot property, which is not here not here, but it's rather in here. We see there is a area slot property, and we say that, okay. Go all these three entities and take a, and take them into the header slot. So that's how once we assign the slots to the entities, then those slotting mechanism will start, being act coming to action, and then the UniFace default, slotting and indexing mechanism will not, will be overridden. So if we refresh my screen, we see that, there is no footer because we assign those three entities to the header. So we see this is the, header text entity, then this is, the filtering entity, and this is, the button entity. All the business logic keeps working, so there's nothing to worry about that, everything is still working. It's just the UI arrangement, which has happened just now. Few things to highlight here that if you remember, the header itself has adjusted itself. So it has been expanded based on the content or content of its children. So because it has more to show, now the header is is wide in terms of its, vertical space. So it it, it has been adjusted based on the children it has to accommodate. Also, the buttons, if you remember, they were when they were part of the footer, they were, having grayish background, and now they are bluish background. So even the children adapt to the context of their parent. And all those, logic, we did not had to write anything else. All those are encapsulated in this widget in itself. So, the children are, let's say, adapting from its parent and the widget itself. It it it also adapts to the content. So although all that is part of, the widget logic. There is no footer anymore because we did not assign any footer slot, and the header and the content is basically what is being shown at this point of time. So those are, some very interesting properties which we can tweak and then see how things work. And that's also the highlight of, how how would you make things. So you just go to the widget. The widget properties are made available, and then you go at that right level, and then you change them. And then, and then then that will give you the right UI effect for, which you are looking for. The other thing, I guess, the other important property is appearance, which I think also is good to have a look at. There are number of properties, but I'm only trying to highlight the ones which are very interesting ones, and rest others you can figure out by once you are in that need and go to the documentation and you can figure them out. So let's try to have a look at the appearance property. And I think for appearance property, what I would do, I would simply reset this, component level that is not interesting anymore. So in appearance property is available at the UX layout level, entity, and also on the component. And they actually provides a very nice appearance for your layout kind of widget, and it stand it it gives some visual, indication for, for the component and on the entity level then for the collection and for the occurrences. So in this use case, I think the the one which represents data is a nice way to show the appearance property because then you could actually see the real difference. So let's change this to the UX layout. So now what we did is that earlier, the data the data was presented in a great fashion, and now we just, made data presented by UX layout. And what UX layout does that it will simply show the occurrences in a by default in a vertical fashion. So that's what we would see. And now I go I refresh my screen. That's what we get. All the data is now, not in the grid fashion anymore, but there are a number of occurrences, and number of occurrences are just vertically placed one after the other. This could be a use case where you want to build your, you know, maintenance form kind of construction, and you still want to see your data just being aligned horizontally or vertically. But for for in even in this construction, I want the occurrences at least to stood out from each other because currently, they they just they are following same visualization, and there is not much distinction among them. And that's where you could make use of the appearance where, you know, for each widget, you can give some visual, indication where they can stand out from their, you know, from their parents or from their surroundings. So that's where the appearance properties, they are made available, for example, in this case, at the collection level and all the occurrences level, what we want in this case is apply the appearance at the occurrence level. And there are a number of values available. So you can transparent is the default one, which we see now. There is nothing, so it's all transparent. You can give some outline. You can have card kind of, visual indication. You can just have section and panel. And one what does it mean? The syntax hint, should help you with that. So in this, example, let's just use card, and see how does it look like. So we are applying the card visualization at the occurrences and see how things look like now. So if I refresh the screen, you see the occurrences are coming as cards. So they are they are visually, a little bit a shadow here, and then they just stands out. So each occurrences are just standing out compared to their surroundings. So so that's another interesting property, and there are different values for those properties which you can also play. So, basically, that's what I in nutshell, I wanted to show you, in regards to UNIFS UX features. There is a lot to show, but these are really quick highlights. The documentation is updated, so feel free to explore that, and that, hopefully, it inspires you to start using it and do more things with it. So having said that, I think I will, share the presentation again because then I will hand over to Anushri, and she could take us to the next segment, and that is building a custom UX widget. Yes. Thank you, Shruti, and hello everyone. As part of this next session, we will see how we can build a custom UX widget. In this presentation, you have already seen a lot of, out of the box UX widgets. Right? Now let's take an example. K. Imagine you are creating a DSP for your application, and you notice that the same construction you have used in many of the other DSPs as well. Okay? Like, the same design, somewhat a similar layout, maybe a few changes here and there, but you feel like it would be good. Instead of writing this duplicate code over and over again, if you could create a custom widget out of this, Just plug it in, configure it, and use it. And that is possible and very easy to do. So there are two ways you can do it. First is using the UX interface API and widget life cycle. So bit of this, Jody had already explained. So if you think of the widget and it goes through different stages or states in its life cycle, and in each of these stages or states, Uniphase actually calls some APIs, which we can actually use to implement whatever functionalities we want for our widget. For example, at the very beginning, okay, before even the widget is created, UniFace will call this process layout API. And this API, we can use to define the layout or the HTML DOM structure we want and return the element. Then once the widget is created and it is connected to the DOM, the on connect API will be called. So at this point, we will have access to the actual widget element. And say we want to add some even listeners to it, this is the point where we can do it. And similarly, after this widget created widget is connected and bound to our Uniface data object, then the different data related APIs are available, like data in a data update, data cleanup. There are also more APIs, like, we can control the blocking state or unblocking state of the widget. We can validate it, and we also have APIs for error visualization. So, basically, we it's just these APIs we need to implement or to build any kind of widget. K? So that is our first approach. The second approach is using the UX widget framework. And this is actually even more easier because once we have the framework, we don't actually have to worry about these life cycles or the APIs because the framework already takes care of it. As a developer, you just have to focus on the core functionality. And how to implement this functionality? For that, we have building blocks called workers. Now you must be wondering what these workers are, which we will see in some time. It will be easier to show it and explain it. Okay? So you will see that in the demo. We will show both of these approaches. Before going to the demo, there is one more point. So all of this out of the box widgets we talked about, the framework, the workers, the source code is actually available as open source in our public GitHub repository, Uniphase UX. So please feel free to take a look. K? So that was the introduction. Now I think we can get to the actual demo, which will be hopefully more interesting. K. I think I'll start sharing my screen now. Let me know once it's visible. K. I hope it is visible. I am looking at my ID now. And so now we are going to create a custom UX widget. Okay? And we are going to do that with the help of an example. So I want to create a DSP for my newsletter page. Okay? I have the design ready over here. So this should have a title saying subscribe to a newsletter. There should be a card inside which an email field that subscribe field is here. Sorry. Subscribe button is there. And I want to have a custom widget to implement this DSP. Okay? And it would be at the component level. K? Component level, custom widget. So I have already done some initial setup. So there is my newsletter DSP. And if you look at it, I have set the layout mode as generated, and my DSP widget type is UX card. So this is the custom widget we are going to build. I just added it as an option here. It is not really available. The implementation is not there. And inside it, like we saw, there is an email field and there is a subscribe button. And I have split them into two different entities, which for this structure is not really needed, but I wanted to show an example with multiple, entities. Okay? And now if I do a compile and test, I should get an error because oh, wait. That is, I think, not available yet. Yeah. So you see, this is now an, error. It is saying that the widget class UX card is not found. Okay? So we are going to build this widget class, UX dot card, and we are going to do it together. Now let's get started. So first approach, we will be using the APIs. And, thankfully, you don't have to actually start this from the scratch. So if you go to the uni phase installation. There template already. You'll see we have a template for a widget class, and inside it so if you see the outline here, all of these APIs we talked about, it is already written. And there is also it is empty, but there you can see there is a description over here which will help you figure out how to use it, where to use it, when to use it. Okay? So we'll be using some of these APIs now to create a widget. K? Now let's get started. So we will be doing this step by step. You know? As said then, we'll be dividing the stuff, steps into different task and do it one by one. So the first of all, first task should be to get rid of that error we saw, saying that the widget class is not yet available. Right? So first, let's define the class. Since my widget is UX card, I will call this card. So I have defined the class. I also have to register it. So if you go down so this is the point. We will be registering it as a Uniface widget class. So our namespace is UX, and my widget is card. K. Here also, it should say card. Now I will refresh, and if I refresh now yeah. The error is gone. And if I check the elements, you will see we have one, which is elementary empty there for the newsletter component. Now let's go back. This the first step is complete. The next task is to define the layout. So if you remember, the layout definition is done using the process layout API. And if we go here so right now, it is just returning that skeletal widget element, which we already saw. Now let's define the actual, DOM structure we want for our widget. So for that, let's look at the design once more. So here We're having a little problem with your sound. I just wanted to let you know. I need it title. Okay. So already there is an outer div in And so let's do that. And here, I will be I'm sorry to interrupt. You're still breaking up. We can't hear you, unfortunately. I'm so sorry, everyone. We'll give it just a few seconds so she can get her sound working. Okay. Since we're having a sound problem, let's move on to the final slides and we'll close out with the q and a. Can we get the form slide and the other one that we talked about, Jody? Yeah. Sure. I can bring up the slide. Let me share my screen. Sorry about that everyone. Not sure if you would like to wrap up what, Anushi segments she was saying. She was, trying to build all the context, but I think, the main idea is to, show the widget life cycle. But maybe before jumping there, what I could show is the widget framework. Would that be an idea, Greta? What do you think? Or links there? That works for me. Yeah? Okay. Alright. So I think that's an important thing to just, quickly show us, and that's the repository which, Anushi would also planning to show, and and we could not get to that. So I will quickly, show that part, and then we can have a look. So, what we have made available is, the, all the Uniface, out of the box widgets in a public GitHub repository. And that repository has nice structure, everything, and there is a read me which explains all the things which, explains. So it has, sources and also has test, by the way. So, sources contains all the, UX widgets. Let's go through maybe one by one very quickly. With you fluent UI is something where we are making use of some, fluent, let's say, assets, so assets and icons. Web components are some of the web components which we have created, which does not come with the fluent, for example. So those are inside the web components. All the UX widgets are part of this UX tab, so the out of the box widgets. So you see all the buttons, and all the things are basically available here. And just check out one of the widget, which is there. What does it contain? Every widget has its read me that explains how does the widget, what is the purpose of the widget, how does it is it made of? So in case of button, it is made up of fluent button. Then how it is configured in uses I and I, web I and I, and new properties I and I, and the steps to customize it if you want to customize for your own need. So all these sources are made available. You can get inspired. You can download it, make changes for your own need if you like to. And if you want to create, another widget for for yourself, you can also do it. So you follow the similar structure that every widget has its own folder, etcetera. One thing to, point out, which Anushree was talking about, is the widget framework, and that's basically, this, there is a folder here. This takes away the need of all the UX interface API, that deals with the widget life cycle, etcetera. So any widget you create using the widget framework, this is the folder which describes more about it. So there are widget frameworks is is highly lets you focus just on the UI aspect of your, widget, and you do not have to worry about the UX widget life cycle. And it contains, workers, one of the, let's say, reusable modules. So you have to, figure out which worker to use. That's the only thing, and then you you can basically may, create your own widget. So maybe a very quick look where we were, in the button. You can see there are a number of imports being done at the top, and that those are coming from the, from the widget framework itself, so the necessary, workers which is needed to made up make, that widget. And other than that, the widget structure itself that, what it contains is, the main widget content is, the static structure. And let me look out for where is the static structure. These are some workers to extend. This is the structure which the, the widget needs. So it basically contains of the widget contains an, an element, and in this case, it is made up of fluent button and some necessary workers which are needed to create this button. So that's how, the using widget framework, the widgets are created, and you can get inspiration from you can download and take a look at that. Next to the sources, we also have tests, for example. So we have created, there are unit tests made available for each widget. Mainly unit tests, some a little bit of functional tests as well, and they are made available in their own folders, so that you can explore and inspire. They are based on the MoCA framework. And how to do that, those are instructions are part of the ReadMe. So, NPM modules, which we need which you need to run those tests. And if you add, you can also add and extend these test sets. So this is something, I guess, was interesting to also, have a quick look at. So please feel free to explore this, and I hope this link is, let's say, if you need this link, please feel free to reach out. We can share it, or, otherwise, it was part of the presentation as well. And I think that was it. Then we can go to the q and a slide. And if we have anything to ask, Should we have the screen shared, Lindsay, or we go back to the queue, the chat channel? I was just gonna go back to the chat and run. through these and see who could answer. The first one I have is asking, is it now possible to change the order of the columns at run time, and is it possible to group by columns? The order of columns, I may, and I think we are asking probably, is it specific to the data grid? I'm just trying to understand the question itself. So currently, it is, possible to just do it within the DSP itself. So on the run time, not, but on the definition time, that's how we need to do it. Yeah. That's the for the data grid, if this question is then, you need to change in the component structure, and that's the structure is taken to create the, the, let's say, the order. Perfect. Okay. Data grid in background. Yes. It looks like the others were answered, in the q and a chat. Do we have any other questions before we look at closing out? Okay. You can stop sharing your screen. We're all good. So there is a new one coming about why isn't the environment environment for UX widget integrated into the Uniface IEU. So this was actually a a very conscious choice. You know, what we wanna do is to make sure that, people have the best experience with the tasks that they're doing. What we find is that if you are creating, UX widgets, yeah, you tend to be, sort of more into the TypeScript, JavaScript, ecosystem. And that is, you know, that a very good place to be able to do that is Visual Studio, code or, you know, a a JavaScript editor. You know, we can bring it into Uniphase, but we wouldn't be able to do such a good job. And, you know, we it wouldn't be the tool sets which the the typical person would be using on a day to day basis. So that that is why it's not been brought into the IDA. You know, the IDA is there to develop for, sort of uniface objects and, entities and menus and and, you know, centers, etcetera, etcetera. Everyone, there's going to be a survey that's posted. Just be sure to check that out. Let us know if, you know, there's anything that you'd like to see, anything that we can work on. We'll send you a survey at the end of the session. Any other I don't see any other questions. Alright. If we have no more questions, we can close this out. Thank you all so much for coming, and be sure to check out the forum if you'd like to see the the video of this, and let us know if you have any questions. Thank you. Thank you, Thank. you.