B4J Library [Web][SithasoDaisy5] Low Code Compact UI Design using Preference Dialog

Hi Fam

A look at this third iteration..


Check the Demo Here


1758186804575.png


Preference Dialog nicely hosted on the right...

1758186840683.png


Building user-friendly applications often means balancing screen real estate with data entry efficiency. In the third iteration of the Low Code Address Book, we’ve taken a major step toward creating a compact, elegant design — powered by preference dialogs and IndexedDB.

This release focuses on improving usability for developers and end users who need quick data access without leaving the context of their work.




From Modals to Preference Dialogs​


In the first version of this project, we used a modal dialog. In the second version, we moved toward full-screen forms for large data entry scenarios. Now, in version three, we’re introducing a preference dialog approach — ideal for applications where space is limited, but data input must remain efficient.

What Is a Preference Dialog?​


A preference dialog is a lightweight, column-based panel that appears alongside your main table. Rather than blocking the entire UI, it slides in from the right, allowing users to keep their data table visible while they add or edit records.

This pattern is perfect for:
  • Quick edits without losing context.
  • Compact layouts where the user can keep an eye on existing data while entering new information.
  • Applications like help desks, where agents need to switch between lists and forms rapidly.



Key Features in Version 3​


Here’s what’s new and improved:

🔄 Column-Aware Layouts​


When you click Add, the table automatically resizes to show only the first column and make space for the preference dialog. This keeps the layout compact while giving enough room for data entry.

🧭 Enhanced Navigation & Search on Main Page​

  • Dynamic Search Bar: The search field now adapts based on the active table (Contacts, Categories, Provinces).
  • Key Event Handling: We can trap key-up events, backspace, and clear events to provide a responsive search experience.
  • Right-Side Components: We’ve added the ability to place buttons, text, or select boxes on the right side of the navigation bar for extra functionality.

🖼 Visual & UX Enhancements​

  • Drawer Improvements: Items now have icons and a matching activation color based on the navigation bar background.
  • Rounded Drawer Items: Cleaner, modern look with soft corner radius.
  • Responsive Drawer Behavior: Opens automatically on medium and large screens; toggleable on small devices with a hamburger button.

♻️ Refresh Column Visibility for Tables​


A new RefreshColumnVisibility method restores column visibility to its default state after modifications — helpful when users hide or show columns manually and then refreshes.

📋 Data Entry Enhancements - Add functionality on Preference Dialog.​

  • Inline Category/Province Creation: Adding a new category or province automatically updates both the table and the dropdowns.
  • Validation Improvements: Required fields are clearly marked, and validation ensures all mandatory data is captured.
  • Cloning Support: Records can be cloned with a single click, then modified as needed.



Developer Experience Updates - updates on the Low Code Generator​


We’ve also made improvements for developers working with the Low Code Generator:
  • UsePreferences Option: Developers can now choose between modal-based, full-screen, or preference-dialog layouts when generating code.
  • Consistent Naming: Methods are written in human-readable, descriptive names (buildPreferencesDialog, refreshColumnVisibility, computeCategoryName), making the code self-explanatory.
  • Generated Code as a Starting Point: While the tool provides working source code, developers are encouraged to enhance and customize it to suit their project’s needs (e.g., adding data integrity checks or unique constraints).



Why This Matters​


This iteration is all about compact design and developer flexibility. By keeping the table visible while editing, users can:

  • Work faster with less context switching.
  • View reference data while entering new records.
  • Use smaller devices more effectively thanks to responsive resizing.

Meanwhile, developers get a consistent, low-code-friendly codebase with clear extensibility points.




What’s Next​


Our next step will be to:


  • Add data integrity rules to prevent duplicates.
  • Improve responsiveness for small devices (ensuring the drawer toggles cleanly).
  • Provide additional layout presets so developers can pick the best UX pattern for their use case.

The ultimate goal remains the same: enable developers to focus on business logic, not boilerplate code, while delivering a polished, professional user experience.

Enjoy and have fun!
 

alwaysbusy

Expert
Licensed User
Longtime User
Looks nice! But indeed, as A.I. suggests in your text, responsiveness should be one of the first things to tackle as most users nowadays do such data entry on tablets and phones. Data entry next to the table works on desktops, but are a nightmare on small screens without responsive design:

1758188821873.png


Instead of 'next to', the data entry part is often much better placed in a drawer and we've experienced with our WebApps (from feedback from our users), a drawer from the bottom is prefered by most. It has the advantages of seeing the context while entering data, and works on many more devices. e.g. one of our apps in ABMaterial:

1758189753602.png


I know your articles are about low-code programming, but just wanted to mention it as a good selling WebApp does most of the time requires quite some 'hand-work' 😉

Alwaysbusy
 

Mashiane

Expert
Licensed User
Longtime User
Looks nice! But indeed, as A.I. suggests in your text, responsiveness should be one of the first things to tackle as most users nowadays do such data entry on tablets and phones. Data entry next to the table works on desktops, but are a nightmare on small screens without responsive design:

View attachment 167014

Instead of 'next to', the data entry part is often much better placed in a drawer and we've experienced with our WebApps (from feedback from our users), a drawer from the bottom is prefered by most. It has the advantages of seeing the context while entering data, and works on many more devices. e.g. one of our apps in ABMaterial:

View attachment 167017

I know your articles are about low-code programming, but just wanted to mention it as a good selling WebApp does most of the time requires quite some 'hand-work' 😉

Alwaysbusy
Thanks for the feedback @alwaysbusy , appreciated. I have noted your points and will consider for the next iterations. Fortunately I already have a bottom drawer component on SD5, will add this to my todo list. Thank you so much!
 
Top