Edit screen or visibility conditions on "entry" ones?

Ask for Help
1

Dear all,

I am building an app to create projects ideas (entry fields) which are then visible without modifications by any users (display fields).

I am hesitating between using the “Edit” screen in complement to the “Display” one
OR
to only use the “Display” one by combining display & entry fields with visibility conditions according to the type of user.

The reason is that I need many choice components rating from 1 to 5 for the project creation, and for UX matters, I want them to be:

  • in bar instead of dropdown menu
  • and not required, but the bar choice component is limited to 4 grades otherwise it becomes required.

=> What risks to you see if everything is in the same page (except the need to be well organised in field naming)?

Many thanks in advance

2

The main drawback, for me, when you use entry fields on a details screen is that the edits are live. It’s not in an edit environment when you can choose to “submit” your changes or “revert” back to what you had before entering that screen.

If you feel that live changes are ok then just but those entries on screen, but for me I always prefer an edit environment.

I don’t get what you’re trying to do here, can you talk more about this? What is the different in using a choice component in a details view and an edit view?

3

Hi @ThinhDinh and thanks for your answer.

In my case, I have a screen with 100 fields including dozens of choice components (5 grades, to display in bar); the user must be able to fill this screen in several times.

If choice components are with the format of “5 grades in bar”, they become required:

  • In edit view: the user cannot submit except if he selects all the choice components
  • In detail view: no submit is required, so, even if he does not select all the choice components, his modifications on other fields will be taken into account.

If you have a better workaround where I can have “5 grades choice components in bar” AND be able to submit in edit view without filling-in all of them, I take it!

Thanks

4

Would a Link To Screen → This Item work, so you get a separate screen attached to the same row. Use that screen for editing. It would still be live edits though. Completely understand that temporary USC columns are out of the question in your situation, otherwise I would have suggested that as a way to have a custom edit screen with a submit button. But I think the Link to Screen would be a reasonable option if you are OK with live edits.

5

Thank you @Jeff_Hager,

USC: yes, as you state, quite a nightmare to set it up.

Link to Screen: truth is that I already combine “edit” and “link to screen” according to the type of Choice Component: some are priority 2 and are hosted in a link to screen (so no issue here), but some must remain in the main “edit” screen… so they are subject to submit!

At this stage, I don’t see any other approach than the “Detail” screen with both edit & display fields visible according the user type…except if there is a reliable-CSS-trick enabling to display 6 choices (5 grades + empty) in a choice component.
As @ThinhDinh mentioned, the main issue is the “live modifications”, ie. no error authorized.

1 Like
6

You could make the last option on the choice component an arrow “ ->” revealing more choices.

Required CSS, none.

1 Like
7

Thank you, this is a good idea for other types of choice component in my app; unfortunately not for this one, since it is a 1 to 5 bar… it would be a little strange to have the “5” in another choice list

1 Like
8

Yeah, I don’t think there is a way to use CSS to get more options in a horizontal choice component. That’s more than just a visual trick. That’s getting into the functionality that runs the behind the scenes code. You can change how things look with CSS, but you can’t change how they function.

I can’t think of a good solution for your case. If it were me, I’d probably switch to horizontal inline lists or make a custom form, but it’s still a lot of overhead in your case. I added a note here to menu if glide does a live coding session again.

1 Like
9

I think I did have this problem before.

What I did is overwrite the conditions for the “Done” or “Submit” button with CSS so it becomes active even if the required choices haven’t been filled.

It’s something like:

<pre><span><style>
[data-test="nav-button-Done"] {
pointer-events: auto;
}

Then set that to be visible when all of your actual required fields on that screen are not empty.

2 Likes
10

Thanks @ThinhDinh, it would be great. What exactly do you mean with regards to the visibility conditions: should I make the rich text visible if each of the choice component is not empty?

Thanks

11

Let’s say:

Choice 1, Choice 2, Choice 3 is required (by your rules).

Choice 4, Choice 5, Choice 6 is not required but you need to show 5 options.

Just set them all to required to show 5 options, then use the CSS above to override the “Done” button. Set the CSS to be “visible” when Choice 1, Choice 2, Choice 3 are all not empty.

1 Like
12

You are 99% :slight_smile: a genius! Why not :100:?

Because I have to rebuild dozens of Choice components: it works with the new component (after CSS was implemented), but not on the old ones (before CSS was implemented).

→ No choice made on none component = “Done” inactive:

image
image1135×241 39.3 KB

→ Choice made on the component created before CSS was implemented (without visibility condition for the test even on the components that are actually required) = “Done” active

image
image1133×255 40.5 KB

Many thanks @ThinhDinh

1 Like