Who says you can’t do rapid application development in Java? Part Three: Customizing the user experience

Our pet food reviews app is now working perfectly well for an admin user who knows what data is in the database, but we could improve the browsing, creating, and editing process for a regular end-user. In this part, I’ll walk you through some customizations you can do on the Angular front-end and the Spring Boot RESTful API, to make sure that our data is human-readable, and that users can navigate and submit reviews in the exact places they may expect.

If  you haven’t already, make sure to run the API with “./mvnw” and run the front end Webpack development server with “yarn start”. If all goes well, you’ll be able to visit the client-side application at localhost:9000. Because it’s using Webpack hot-module reloading under the hood, any changes you make to the front-end app will show up in your browser, without you having to hit refresh.

To edit the front-end code, open up src/main/webapp. You’ll see a full Angular 6+ web app here, with the features organized into multiple Angular modules. The front-end representation of the entities we generated in Part 2 will be in a module you can find at src/main/webapp/app/entities. Each entity has its own module within the entities module. So, for example, you’ll see the Food module at src/main/webapp/app/entities/food.module.ts, with a route file for that module at src/main/webapp/app/entities/food.route.ts. Alongside those files, you’ll see the TypeScript and HTML files for the basic CRUD components: index (food.component.ts + food.component.html), detail, edit/update, create (shared with food-update.component.ts), and delete. When starting out on a JHipster project, these files will get you a lot of bang for your buck — editing, reusing, or copying them with small tweaks will cover 90% of your CRUD use cases, so that you can spend most of your remaining time on things that are unique to your project.

But for now, let’s start with some simple changes in wording and branding. You’ll notice that the navbar has a dropdown for “entities” — let’s change that to something that’ll let end-users know that this is the place to go to interact with most of our core features. Open up src/main/webapp/app/layouts/navbar/navbar.component.html. Find the <span> element that contains the text “Entities” and change it to “Browse”. Within the “ul” with the class “dropdown-menu”, find the “span” element that says “Pet” and change it to “Pets”. Do the same for “Food”, but change it to “Food Options”, and change “Food Review” to “Food Reviews”. Once you’ve completed these small changes, you’ll see  that the navbar has a dropdown that lets you “browse pets” or “browse food options” or “browse food reviews.” Of course, the sky’s the limit for any further UX improvements you want to do, but at this stage we’ve at least made our navbar read like plain English, which means we’re further along to an MVP.

Let’s now take a look at our core feature: the Food Review. Make sure you’ve populated the database with some pets and foods before you do this step, so that the food review form actually has some options to work with. Open up the form component at src/main/webapp/app/entities/food-review/food-review-update.component.html. Inside the <option> element with the text {[foodOption.id}}, change the text to {{foodOption.name}}. Do the same for the <option> element with the text {{petOption.id}}. Then, for the <option> element with the text {{userOption.id}}, change it to {{userOption.firstName}} {{userOption.lastName}}. These small changes in display names will now allow end-users to see meaningful names for each associated field, instead of id fields that don’t mean anything outside of the database records.

You  may also notice that the “body” field for food reviews is just one line long. Let’s change it to a text area with a few rows, since it’s the core content we want users to submit. Find the <input> element with an [(ngModel)] of “foodReview.body”, and change it to a <textarea> with all the same properties. Make sure to add an ending </textarea> tag. You’ll immediately see the input expand, and you can add a rows=”(number)” attribute if you want it to be even bigger.

From there, the only remaining cosmetic change is to open up src/main/webapp/app/home/home.component.html, and change the text to match your website’s theme. With these small cosmetic changes, our app is now usable for a regular visitor. We didn’t even have to modify the backend API, but now we have a perfectly usable MVP!

Stay tuned for Part Four, where we’ll define a custom use case that allows us to define which pets line up with and can eat which foods.

Leave a Reply

Your email address will not be published. Required fields are marked *