Create vs. Edit Methodology

I am interested in hearing from folks who have created apps that have ‘Thing’ Create and Update interfaces and what experiences you have had with using a single interface vs. two.

As an example, say you have a Thing called a ‘widget’ and widgets had a Name field and Price field. To create a widget you would have a page called ‘Create Widget’ and you would put an input element for Name and an input element for Price on the page and a create button, and probably title the page ‘Create Widget’.

If you now want to allow someone to Edit/Modify a widget you have two options.

  1. You can create a new page call ‘Edit Widget’ that has the same input element types (Name and Price) but you would set them to have Initial contents equal to the value of the Thing in the database you were editing. You would maybe have a ‘Save’ button instead of ‘Create’ and you would title the page ‘Edit Widget’.
  2. You use the same page and add conditional formatting for the Input elements to set the Initial content only when you are in edit mode. You use conditional formatting on the button to change the text of the button to be ‘Save’ when you are in edit mode. And you do the same thing for the page title. You also need to put conditions on your workflows to differentiate between creating a thing and updating a thing.

In the first option, you have the extra work of maintaining two pages that are mostly the same and the risk of having inconsistency. The second option would seem to be the best, except, with Bubble’s all client-side design there is a lag between the loading of a page and when conditional formatting kicks in. This means, for instance, that the button will first load with the ‘Create’ text and then switch to the ‘Edit’ text and it is possible your end user will see this. While you can work around that by hiding the button, you can’t do the same thing for the page title. It will start out as one title and switch to the other. Now, you could try to work around that by naming pages something more generic like ‘Manage Widget’ whether you are creating OR editing, but again, that is a work around from the optimal.

I have done both options in the app I am working on now and am trying to decide which I prefer.

In the meantime, my question to you all is, what have you found the easiest/best/most efficient way to go about this, keeping your end user in mind? Two pages? One page with conditional formatting? Some other way entirely?

Let me hear your stories.

Thanks,

Marc

2 Likes

I tend to use the same pattern with most of my apps when I need to add something.

The “Add” is very simple, it will usually just add the name of something.

That will then take you into the Edit function, so you can add in the other details.

Add New Widget > Enter Name Of Widget > “Scrudawdle2000” > Create > Edit “Scudawdle2000” > repeat edit/save until you make widget “Live”.

1 Like

Hi Marc,

I run into this all the time. Use case dictates which route to take, but typically I prefer one screen for both creating/editing.

The way I do it though is by leveraging a group’s data source. The group is set to the Thing type and the source is left blank. All inputs are inside of this group, and they all have initial contents/defaults set to the “Parent Group’s [field]”

To create, simply display the group without loading any data in it (no “display data” action). Since the parent group’s Thing is empty, then those initial/defaults are blank anyway.

To create, you’d display the group AND use “display data” action to update the data source and give the group a Thing. Now, the initial/defaults will have values.

You can still use conditionals for things like the title of the group: "When parent group’s Thing is empty: text = ‘Create Thing’ " or "When parent group’s Thing is not empty: text = ‘Edit Thing’ "

A save button can also use the same conditions: When parent group’s Thing is empty: Save click > Create Thing OR When parent group’s Thing is not empty: Save click > Make Change to Thing.

This has worked pretty well for me, and it doesn’t take too much extra effort to take care of how this group looks upon page load so that it’s not in a halfway/blank/confusing state. I don’t even see it as a workaround, just a setup step in order for this single group to work.with dual purpose.

I try to avoid managing two (or more) of anything that’s nearly 100% identical because of the same reasons you listed (less room for inconsistencies, etc.)

Hope this helps.


Gaby | Coaching Bubble
Private coaching, courses, and tons of free resources

2 Likes

Gaby,

I have some of my pages working the way you describe. The one thing that bothers me, but is probably just my self inflicted OCD, but when you have a page that has a default “thing” assigned, so ‘Widget’ in this example, when you are Adding a widget, there is no existing widget to pass to the page from the previous page (where you clicked the ‘Add Widget’ button). This is fine, but it causes the Bubble editor to complain via the ‘Issues to fix’ warnings.

  1. Is there any risk to not fixing this aside from just being annoying?

  2. Is there anyway to tell Bubble, ‘yeah, I don’t care about that issue, stop telling me’?

Thanks,

Marc

1 Like

I totally agree :slight_smile: very annoying

1 Like