Frontend : UI/UX improvements

[Franceq34]

The goal of this issue is to track the work done on UI/UX and have a better idea of what could look like the final Jhipster generator app. Feel free to submit any idea in this thread. 📝 If you feel creative don't hesitate to design some mock-ups with pencil/paper or any tools you are comfortable with. (Marvel, Miro, Adobe XD, Figma etc ...)

Functionalities needed 🛠

SpringBoot generator :

• Project configuration (path, basename, project name, package and port)
• Generator commands (cf « Generate your project » → or refer to generator swagger) (Here is the biggest challenge of the UX, as there are tens of APIs, we need to determine how to display them and filter smartly)
• Download the generated project
• Swagger access
• "About" section (JHipster, Github, Twitter, Opencollective ...)

Account management (cloud version) :

• Registration
• Forgot password

We won’t focus now on Quarkus generator or Micronaut generator, as this is a completely different context and there’s not any work began on it, but we can keep in mind that this could be added someday.

Users habits 👤

We can imagine 3 types of user needs using JHLite.

• The designer : he generates his project with the JHLite small bricks. He initialized his project and added his favorite Springboot options. His project has its lifecycle and the user can come back at any moment to add bricks (ex: adding a new database for example ...)
• The builder : this user has already his project generated with or without JHLite (maybe JHipster). He wants to add a few bricks.
• The newbie : this user could be afraid with the modular aspect of JHlite, he is a beginner or could be used to JHipster legacy. He will use an interface "Quickstart" with some API bundles -> he wants to generate his application easily with basic options.

[pascalgrimaud]

cc @assimbly as you have probably some suggestion

[pascalgrimaud]

Here the current version (v0.3.0):

[skin27]

Looks good, I will give it a try later this week to give feedback in detail.

[Franceq34]

Here is what I got using Figma.

On hover on a button :

Here's what I added :

• Language selection in navbar
• Light/Dark mode in navbar
• Description of each APIs to help new users, because clicking on a button named "Init" could be confusing
• Search in APIs as there will be a lot of them.

I updated :

• highlight download button which seems important to me
• added a mandatory Toggle selector at the top : BUILD, SERVER, CLIENT, because in the current design you have to click twice to have access to buttons (example : click on SpringBoot radio button and click on Spring Boot panel header)

• added filters in each section (Maven/Gradle in build, Angular/React/vue in client etc ...)
  I chose filters because we will be able to add subfilters -> choose springboot will add new filters : log tools, databases, databases migration etc ...)
  

Maybe we could add filters as tags below the description of each button when hovered

[pascalgrimaud]

Very good work here @Franceq34 ! A lot of good ideas here
I'll give you feedback very soon

[pascalgrimaud]

In fact, all good ideas
Maybe the filter can be changed, as + and - can be confused, but I don't know what to propose

[deepu105]

I like the proposed design theme. Some comments and suggestions

1. I'm not a fan of the proposed server/build/client thingy as it assumes static grouping. See below for alternative suggestions
2. I would suggest a wizard like (can be accordions/tabs that are activated one after other) or guided UI where you are promted for project config first followed by server stuff followed by build stuff and so on for example. But for scalability I would recommend the UI being dynamically generated based on an API that dictates what comes first, what holds what options and so on. So ideally an API should provide metadata needed for the UI
3. This can be done by introducing a type param to each configuration at the API level. So a configuration can be a string, boolean, choice or multiple choice. With this type specified, you will be able to construct a dynamic UI just using the API and show string fields for project name and so on, a list or radio button for stuff like maven or gradle and finally a checkbox for stuff like kafka, websocket and so on. On top of this the API can provide field metadata with grouping. Each group will be a step of a wizard. Within each group there will be array of fields. Each field will specify name, type, accepted values (fot options)

If you all like this approach I can help with designing the metadata API

[assimbly]

First:

• I like the theme and basic setup of Franceq34
• I agree with Deepu to give users a more guided / wizard approach and to make it dynamic to add new options.

Here my 2 cents about this process:

In my opinion the configuration/generating of an app is somewhat like the checkout experience of a webshop. Even the slightest friction in the checkout process can drive shoppers away from a site—many never to return. I believe the same applies for the UI of JHL (and why it's so important).

To have a good experience most checkouts are designed by the following 3 rules:

1. Clear flow
2. Easy form filling
3. Speed

To achieve this, the process is mostly

1. Broken up in separate steps/sections
2. Provide an outline of the configuration process
3. Show a summary of the progress
4. Option to revert/go back in the process

For JHipster the process can be

1. Configure (your project)
2. Choose (your tech)
3. Generate (your app)
4. Run (now)

The above outline in short terms and hipster terms (= short term plus text in parentheses). I favor a top-down approach to
go through every section. Where the first section is on top and the user (developers) scroll downs to go to the next step
until it reaches the next step. On the right the user can see the progress.

Just like the Amazon checkout:

Here on the various sections in detail:

1. Configure your project

• Project name (as this the name of configuration, this is what people want to add first, not the path)
• Organization name
• Base name:
• Package name:
• Path: (required) or Path:* (which is more common to required).

1. In the input fields there can be placeholders / examples.
2. Give information (infobox) what every field does (what and why is that configuration needed)
3. Let people choose path with a folder chooser. (if folder already contains a configuration file then load this configuration into the UI).
4. If possible generate the package name can be generated from the project/base/organization name.
5. In the future I would expect also here the kind of application (micoservice, microfrontend, web application etc)

2. Choose your tech

• The tech tiles (build tool/backend/frontend) below each other
• Make items in the tiles bigger and the various items (i.e. angular, react, vue) below each other
• Use not too much color (if it doesn't add something). Easier for the eye when using for example light blue.

3. Generate your app

• Make a section title "Generate"
• Make the tiles exactly the same as the "configuration" tiles/items
• Make button green when generated (succesfully)

4. Run your app

I think (at least when user run JHL locally) users also want to know

• Do I have a runnable app (in Jhipster Classic this is always the case, but with JHL not)
• When I have runable, run the app directly from the UI (and open a new tab) - if technically possible

Summary

Like at Amazon there could be a summary side panel. Is configuration complete? What did we generate? Also the download (and run) buttons can be placed here. Make the download (and run) button as separate color (yellow?)

---

The 0.3 had already some good improvements. I think with a few iterations based on the above ideas JHL UI could be the next level of easy application generation. Note that the above comments are just suggestions, nothing strict to follow.

[DamnClin]

We discuss something around that with @hdurix today (we were thinking about #1666) and, for now, we still think it's possible to have a front end depending only on an HATEOAS API that can be generated from very simple definitions.

[pascalgrimaud]

I discuss about it with @hdurix during our last JHipster Day, and indeed, I think it's good idea.
Anyway, I don't know the amount of work, specially for the frontend.

[DamnClin]

The API generation and documentation from an implicit bean graph (making it explicit with inheritance is not a good idea IMHO) afraid me more than the frontend part (but I may be wrong).

There is, indeed, some work to achieve this but I really think the current interface mechanism is too fragile and that this is worth it to ease upcoming contributions.

I think this is a good time to start this since there are enough modules to find the limitations of the designs.

If you agree with the main idea I can try to bootstrap something "soon" (I'll need help to make the full thing real)

[pascalgrimaud]

I really think the current interface mechanism is too fragile

Totally agree, and that's why this ticket was created :-)

[deepu105]

I would suggest to design the metadata API first and UX after that to save time. Once you have a solid API it would be easier to decide on UI/UX

…

On Wed, 11 May 2022, 7:07 am Pascal Grimaud, ***@***.***> wrote: I really think the current interface mechanism is too fragile Totally agree, and that's why this ticket was created :-) — Reply to this email directly, view it on GitHub <#1565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOKF6SO33FIK35DXG6HZDVJM57LANCNFSM5U6HQTVQ> . You are receiving this because you commented.Message ID: ***@***.***>

[DamnClin]

The module mechanism is making it's way \o/ we now have automatic APIs: #2036 and a very simple module list screen #2055 the next step will be to be able to apply modules using the UI.

But, I'm not sure how to do this, here are the constraints to keep in mind:

• All module needs at least 1 parameter: the project folder;
• They have specific parameters (string, integers or boolean), mandatory or not;
• We need to be able to apply multiple modules keeping the previously entered parameters (or it will be a nightmare).

I started (and trash) a module form screen working on it's own, it was looking like that:

I trashed it because having a dedicated screen to apply modules in just a nightmare!

I have some ideas like keeping the side form @Franceq34 show but the fields in this forms needs to be dynamic so that mean different actions on lines:

• When you have all properties set you can just apply the module;
• When properties are missing you first need to click to fill the form and you'll then be able to apply.

BUT this sucks because of not mandatory properties, this is where I ran out of ideas :D. Don't hesitate to tell if this is not clear (because for me it is :D)

[Gnuk]

I'll make a proposal later in the morning from discussions with @DamnClin .

[pascalgrimaud]

Good point @Gnuk
Additional idea would be an option to ignore all checks and make all 'apply' buttons available

[Franceq34]

I really like the idea of this front generated from API.
I wonder what is the best strategy to make the transition from the current design to this one.

Regarding the mockup of @Gnuk, I like the structure of the page.
I have some questions about it :
Correct me i I'm wrong, but "Category" is -> Maven Gradle, Angular, Vue ... and "Module" are the direct calls to APIs ?

• Maybe it needs Categories and Sub-categories ?
• If you fill for example lineBreak for module 1 and module has a lineBreak, will it be "auto-filled" ?
• It could also be great to know what is the default value if an optional is not filled.
• I think it needs a download button

[DamnClin]

I wonder what is the best strategy to make the transition from the current design to this one.

For me the migration strategy is the one we started: the page exists on a path (for now /modules), we update the page && the modules until we are happy with that and switch it to the main page.

Maybe it needs Categories and Sub-categories ?

I don't think so, I think we need tags and a search / filter on this page

If you fill for example lineBreak for module 1 and module has a lineBreak, will it be "auto-filled" ?

Yes, that's the whole point of that :)

[DamnClin]

#2325 was the last think we discussed with @Gnuk. I see, at least those UX tickets on that screen:

• Add download to the new module page #2251
• Mark already applied modules in modules page #2250
• Tags filters for module #2319

But what do you think for this peculiar ticket lifecycle?

PS: Yep, the current UI really is ugly, I can't make any beautiful screen no matter how hard I try :D

[assimbly]

"PS: Yep, the current UI really is ugly, I can't make any beautiful screen no matter how hard I try :D"

Ha, you made me laugh with that comment :). I am sure though that with every try things will improve over time. Keep up the great work!

[DamnClin]

I am sure though that with every try things will improve over time

I'm not even trying, I'm really bad at that, there's no use I waste time on this part

[pascalgrimaud]

Just a check point. Here the current module page:

[DamnClin]

On this patch page I see at least 2 missing buttons:

• Download
• Format & Download

That are needed for the deployed version.

Then, there will be the other page discussed here #2671

[DamnClin]

Did some update in #2751, still ugly (dunno if it's more or less...) but some new feature should make it more usable

[DamnClin]

@pascalgrimaud @Franceq34 what do you think, it is good enough, we close this one for now?

[pascalgrimaud]

Yes we can close it I think.
Let's open smaller tickets for improving the CSS and design

[pascalgrimaud]

Adding a bounty on this ticket.
As you did the main work on this, plz claim it @DamnClin

[DamnClin]

Claimed $300 on this https://opencollective.com/generator-jhipster/expenses/88312

[pascalgrimaud]

@DamnClin : approved - so I suppose the other part will be for @Gnuk !

[Gnuk]

Claimed $200 on this https://opencollective.com/generator-jhipster/expenses/88313

[pascalgrimaud]

@Gnuk : approved

Thanks for your work here !

[Franceq34]

Really nice work that have been done here congrats !