Course with AI - Lesson 3: User interface (part 1)
This is the third lesson of a course where we are creating a car insurance policy management application using OpenXava and artificial intelligence.
Video
In this third lesson we start refining the default user interface generated by OpenXava, making it simpler and cleaner. We do this by giving instructions to Windsurf, in English, without using technical terms from Java or OpenXava.
Problems with the lesson? Ask in the forum
Code
If you follow the course, you don't need to write any code, the AI will write it for you. And your code doesn't have to be exactly like the one in the video. However, you can find the code generated in this video in a GitHub repository, in case you're interested in examining it.
Transcript
Introduction
Hi, I'm Mónica. In this third lesson, we're going to refine the user interface of our OpenXava application. The goal is to make it simpler and cleaner using Windsurf, our AI-powered IDE, by giving it clear instructions in plain English.
Reviewing the current user interface
We start by looking at the current state of the app. The Customer module looks fine as it is, so we leave it unchanged. In Policy, the data at the bottom looks reasonable, but the way the customer is displayed is excessive—it shows absolutely everything, even a list of policies. In Vehicle, something similar happens: the view is too complex because the Policy reference shows the entire policy, including lists of vehicles and claims that are not directly related to the vehicle. The same happens in Claim. The conclusion is clear: if we simplify how the references to Policy and Customer are displayed, the whole UI will feel much cleaner.
Asking the AI to simplify the views
We ask Windsurf to simplify the views using plain language, without OpenXava technical terms. We explain that the interface is too complex because the references to Policy and Customer display too much data, and we politely ask it to fix the issue by making those references show only the minimum data.
AI analysis and code generation
Everything happens in real time. Windsurf analyzes our Java entities and proposes a solution: use @ReferenceView to point to a simpler view than Complete. Then it edits the code: modifies Policy and adds a Simple view in Customer. It also edits Claim to use the Simple view in the reference to Policy. When it finishes, it gives us a clear summary of the changes.
First results in the application
We accept the code and go to the browser. In the Policy module, the embedded Customer now shows just the first and last name. Everything looks clean and clear. In Claim, the reference to Policy is simple and the rest of the form is also straightforward. Perhaps showing only the policy number is a bit too simple, though we can click Edit to view the complete policy in a dialog. In Vehicle, the Policy reference is simpler because the Customer inside it is now minimal, but the full Policy data is still shown—so this module did not improve as much as the others.
Fine-tuning the result
We thank the AI and ask for two adjustments: in Claim, the policy reference should also show the customer, otherwise the customer is not visible anywhere; and in Vehicle, it should not display all the policy data.
Second round of changes
Windsurf analyzes the code again and decides to create a new view in Policy that includes the customer. It edits Claim to use that new view in the reference to Policy, and then updates Vehicle for the same purpose. We accept the code and test the application again. Now, both in Vehicle and Claim, the policy is displayed with the number and the customer's basic data. The forms look better overall.
Reviewing the code with version control
We review the modified code using version control. In Claim, we see a new Simple view and that the policy reference uses WithCustomer instead of Complete. In Customer, a Simple view with just first and last names has been added. In Policy, there are two new views: Simple with just the policy number, and WithCustomer, which also includes the customer; the customer reference uses the Simple view. Finally, in Vehicle, a Simple view is present and the policy reference uses WithCustomer. Reviewing the changes helps us learn if we're new to OpenXava and keeps us in control if we already know it.
Conclusion
In a few minutes and with a bit of artificial intelligence, our OpenXava application looks much better. We've achieved it without writing code and without using OpenXava technical terms—we asked for the what, not the how. In the next part, we'll continue refining the user interface, and you'll have the chance to learn new things.
Next lesson
See you in the next video, part 2, where we'll continue improving the user interface of our OpenXava application.