Frontend UI revised

[joebudi]

https://xd.adobe.com/view/87b65f0a-81c8-4284-b153-82d0ea64d55b-d2e5/?fullscreen

Point 1:
We've had feedback around beta users not finding the 'add' tab in the frontend. I find it a little annoying clicking between add and navigate.

Point 2:
When I was taking the beta calls, no-one clicked the public vs private tabs - no one! And once I told them, I had to explain it.

I feel the design within the above mockup, solves these problems and provides a better, quicker solution. I also don't think it will take that much to implement.

This is just a quick mockup, design suggestions welcomed, but what's important, is the concept. Please let me know if you feel this is a step in the right direction :-)

[mike12345567]

I think its definitely a step in the right direction, its a lot cleaner and everything you care about is sitting right in front of you when you open the page.

A few comments I have from just immediate observations, things that took me a little bit of looking to work out:

1. The public vs private, if it is the padlock, initially I didn't notice they were there at all, after reading your comments about the changes I had to go looking to work out how private vs public was denoted - might just be they are very small in the render or perhaps some highlighting might help to improve the visibility and understandability of it?

2. The top bar for adding components makes sense and is very clean, the first thing that came into my head was this:
   
   So its a lot more inline with the experience a lot of our users are going to be coming from. My one thought on this is perhaps some iconography could help a little here, just so it is not simply a bunch of text dropdown menus.

[joebudi]

Icons will help, for sure 👍

Regarding your first point, I have removed public vs private - there are now just screens. The little locks simple means that the screen cannot be removed or deleted.

[mike12345567]

Padlock makes a lot more sense now! Yeap that all makes sense !

[shogunpurple]

I really like this - everything you need is just a click away and you don't have nested menus.

Totally agree on the iconography point and the fact a lot of people will be used to this kind of setup in spreadsheet software.

My concern is that this could become massive - especially if we introduce several component libraries in future and let people plug in their own. One thing that might be nice is the ability to select "Favourites" that appear in the top bar, and you can go and select the other ones or add them to your favourites from a modal or something by clicking "Other". This way, if you are only making use of a few components for your app, it gives you a hyper focused building experience and cuts away a lot of the bloat

[joebudi]

The 'Other' is a catchall haha. Your concern is correct, and I did think about this. But, I feel for immediate usage, this makes the most sense. Once we get more components, we could look at better ways of displaying them.

[mjashanks]

Interesting - I like the menus at the top for components

RE Public/Private - You're right ... I have big ideas about this going forward, based off beta, which I am going to put into another discussion. In short - I think we need the concept of "pages" (currently we have 2 pages "public" and "private") - but i think we need the ability to add multiple. Will link to this when i've written it up.

RE Desktop, Mobile, Hover, Active, Selected .... not sold on this, as I'm not sure how it works in practice - seem like we are mixing different concepts there.

[joebudi]

The desktop, mobile stuff is old - don't look at it. I am mainly focusing on the components and nav.

[aptkingston]

Merging of pages into a single list is definitely good, although on first impression I actually perceived the padlock to mean like authenticated vs unauthenticated - and I kind of like the idea of maybe using it to represent that and we could just grey out delete options for fixed pages. Just a thought. But definitely prefer a single pages list.

The component bar on the top is nice and familiar. It will definitely need to be sticky as the user scrolls down their page, so it might need some more prominent styling to look like it's sitting "above" the page. What sort of component do you reckon would be good to show when hovering / clicking on a component section? I quite like the idea of dropping down a decent sized full width panel containing the items and brief descriptions of what they are - something along those lines.

[joebudi]

We are certainly on the same page Andrew. I like how Slides have did it:

[aptkingston]

100% - exactly the sort of thing I had in mind.

[joebudi]

Icons added

[mjashanks]

I just wanted to add my thoughts about this before we think that it's agreed upon...

1. If we remove Public/Private - how do we do the login screen ? I.e. when someone arrives at your app and they are NOT authenticated, they need to be sent to a login screen - how do we represent this in the builder?

2. The login screen should not have a master screen layout - i.e. it rarely should have the same navigation as the rest of the app.

This is what Public/Private is solving at the moment. 2 seperate front ends for 2 seperate scenarios

Also, I believe that we should solve the "Multiple Front Ends" issue, that many people request: #636

Suggestions

If we are to flatten everything in to screens as above, we could choose a user access level for each screen

1. e.g. Unauthenticated / Authenticated as Admin / Authenticated as Customer
2. Choose a "Layout Screen" as a base (allows shared masters screens)

Could we also somehow group screens by URL...
e.g. the home url - / - could have a screens for

• Unauthenticated - the login screen
• Authenticated as Admin - the business user home screen
• Authenticated as Customer - the customer portal home screen

then /dashboard may only have screens...

• Authenticated as Admin - the business user dashboard
• Authenticated as Customer - the custome portal dashboard

then /new_deal might just have a single screen...

• Authenticated as Admin or Customer - Create new deal, for these 2 levels

Technical Output

Currently, we have 2 seperate front end builds - main and unauthenticated. The above then suggests that we have on build per user level - each containing only the screens that it as access to

[joebudi]

Maybe we should split these points up:

1. Adding components UI
2. Private vs Public

I feel the first point was answered within this discussion. The second point should be its own discussion.

[osamaros]

I am curious to see examples of the final app from the user end. I tried to find videos or pictures but couldn't find. I want to see what the builder is capable of producing before investing time in it.

[joebudi]

Hey @osamaros . Thanks for joining the conversation. We are hoping to create 1/2 templates within the next 2 weeks 🤫. These templates will give you an idea of what Budibase is capable of producing.