Extending the DDM modules in Liferay with custom field types isn’t that easy. This blog post is the result of our attempts...
Monthly Design Review #1 – Lineas POI ServiceGert Bangels
As promised in the blog post discussing our blog survey’s results and starting today, we’re doing a monthly showcase of a project which our designers are currently working on. Each month, a different team member gives a detailed explanation on their process, decision making or some insightful tips in order to share knowledge. Today, Gert kicks off this blog post series with his latest work for our client Lineas with its POI Service application.
Lineas POI Service
Lineas, a freight train operator company, needed a solution for managing their locations. As the company grew over time, more and more applications for several branches of their industry were developed to run business as smoothly as possible. Now, when we think of freight trains, we obviously need to handle a lot of location types, further explained in this post as POIs (points of interest). One application to manage and distribute these points of interest seemed like a logical next step. Lineas POI Service was born.
In this blogpost we will showcase the user interface of this application and give insights on certain design decisions for the login, overview and detail pages and interactions for crucial state changes.
Since the application would solely function to manage and distribute these POIs, we decided to design it like a CRUD (Create, Read, Update, Delete) application. It’s a common UI pattern for handling rather simple user tasks. Our proxy Peter provided a couple of mockups so the design team knows which data is crucial for our client’s application.
Based on the Lineas style guide, our design team got to work. The style guide explains and documents the required visual style well, which made it easier for us provide a fitting UI. If your brand doesn’t already have a style guide, our creative team will be more than happy to help you with that. (You can connect with them here!)
With this style guide in mind, we started with a straightforward login page, since this application is closed for non-Lineas employees. We included a feature that is often overlooked in UI design: the possibility to show or hide the contents of the password field.
We chose to put the login button on the right, as it’s a good practice to align progress actions on this side to introduce continuity. Over the years there has been a lot of debate on this matter. Either way, we think there is no wrong or right, as long as it’s consistent and fits within your application. Upcoming pages will validate this consistency.
After you sign in to the application, it loads the ‘Locations overview’ page. Here we already added an active filter for ‘Netcode’. This way our developers know what it should look like when they implement the design.
If you compare this UI design with the wireframe, you can see we added a user section. We also opened up a section to provide a title along with breadcrumbs to give more context to the user. This way, the ‘Add New Location’ button is paired with the title and it indicates where you are adding data to.
The View, Edit and Delete actions in the table got more clear by adding explanatory text over a sole icon. We had plenty of room in this table anyway.
As stated before, we already included an active filter. This modal pops up when you click on the ‘Add new filter’ button. Here you can specify values for certain columns to narrow down the results. Adding multiple filters is a possibility, since this application will handle a lot of POIs.
Deleting a POI can be delicate. It’s prone to user error since the action is directly available from the overview. We reduced the risk of unwanted deletions by introducing a validation level that states this action can’t be reversed. Since this validation level is crucial, the red color scheme and warning icon will alert the user on this.
This detail page opens when you click a row or the ‘view’ button in the overview. It gives the user extra information on the POI as more data is provided.
In a CRUD app, it’s a good practice to have the at least the same (or more) functionality in the detail screen as in the overview screen, so the ‘Edit’ and ‘Delete’ actions are available, following the same pattern as our ‘Add New Location’ button in the overview: aligned with the title on the right. We also included a visual reference of the location in the form of a map.
Editing the POI gives our user the possibility to manage the data inside. Here, we introduce the ‘Cancel’ and ‘Save Location’ buttons. If you would put this design on top of the detail screen, you’d see that the labels and input content haven’t shifted (click/tap the image to compare). The action buttons on top have vanished, as we are now focused on editing the POI.
This ‘Leave unsaved page?’ modal will show up if you change the value of one of the inputs in the edit screen and decide to cancel or navigate to another page through an action other than ‘Save Location’.
This step is, like our delete confirmation, a way to reduce the error rate with data loss as a result. Since it’s a state that’s less serious than total deletion, we chose a more neutral orange over the danger inducing red of the delete modal.
Do you have feedback on this post or suggestions for upcoming posts? Let us know in the comments below!
You can check out some of our previous work for Lineas in our CargoWeb (custom software to track trains and wagons) and Mobile Information Assistant (custom web application to manage ground operators) case studies.