grid edit new add record button
Since new UI update i see a new green button above my grid edit reports on my records. How can i hide this button? It is an unneeded function, since i am already just typing into the grid, and it is...
Forum Discussion
Hey folks,
Check out this screenshot from the version of Quick Base we released in december:
If you look in the light blue bar, across the top of the grid edit, you'll notice there's some mostly unstyled text which says "New Record". We just restyled that link into a button to make it more prominent.
We didn't want to make changes to functionality in this release, so we didn't add further customization options about this link (now button). If it's still an issue over time, we'll look into making some adjustments.
There've been a few changes we made to try and make functions more prominent, and this seems to be the most common one.
The button will be hidden if the user doesn't have permission to add a new record to the child table.
Sam Jones
QuickBase Product Manager
Check out this screenshot from the version of Quick Base we released in december:
If you look in the light blue bar, across the top of the grid edit, you'll notice there's some mostly unstyled text which says "New Record". We just restyled that link into a button to make it more prominent.
We didn't want to make changes to functionality in this release, so we didn't add further customization options about this link (now button). If it's still an issue over time, we'll look into making some adjustments.
There've been a few changes we made to try and make functions more prominent, and this seems to be the most common one.
The button will be hidden if the user doesn't have permission to add a new record to the child table.
Sam Jones
QuickBase Product Manager
Sam,
I wanted to comment to highly encourage that QB quickly re-consider this design change or find a way to make it optional (as you suggest you will look into in a reply to another comment below). In order to support this feedback/request, I wanted to give you some additional perspectives and a use case example why this change is more than a minor problem.
Since it has always been possible to include an Add Detail Record Button (from the customize form page), I can't see why there was any need to now include a non-optional button that is just calling out to be pushed. In my experience, if you give users a box, they will type in it and if you give them a button, they feel the need to push it, even when you have given clear instructions not to do so. I believe people are psychologically more likely to push to a button than click on a link, which it sounds like was precisely the thought behind the button. However, by doing that and not making it optional for end-user developers, QB has, as a practical matter, made a design choice for us as developers that impacts how our users interact with our apps and in some cases, like mine, in a very unwelcome way. However, I was encouraged to find this thread and your responses and I am taking a shot that you seem to be someone willing to accept feedback and likely have the connections to get that feedback to the right decision-makers and UI designers at QB.
In fact this has already created problematic usage and resulted in unwanted records and record errors in multiple apps we have designed. Specifically, now users can add records in a way they are not supposed to and previously could not. In our case, we can't deny permission to add a detail record, because we, in fact, need them to be able to add detail records. However, we need the records to be added in a controlled manner with certain critical admin information about the situation in which the record was created. We had done this nicely through API-controlled buttons, which added the detail record AND also auto-populate other criticial admin info fields. Moreover, the buttons only appear when certain conditions exist, as there are situations where we don't want the user to add records. Since there was not an option to have an editable embedded grid without the ability to add a new record directly on the grid, we accomplished this by making certain critical admin info fields required and showing them on the grid only through formual fields (since there is also unfortunately no option to make a field-read only on a grid like you can do on a form). This worked great for the last couple years. We completely eliminated issues where users had added records that did not have the critical admin info we needed. That is, until this past week, when we started to see records that were manually added (i.e. not using the API buttons we created and that the users have been instructed to use) that did not have the critical admin info that the API buttons added.
Since I don't use the app daily and have not needed to update any forms since the new UI change, I had no idea there was now a new active button on my forms. After testing, I now realize that they were able to do this by using the new button. When a user clicks on the newly added New Detail Record button and try to fill out the grid and then Save the record, they get an error saying the record cannot be saved because 2 required fields are blank. That is what previously happened if they just tried to add a record to the bottom of the grid. At that point the user would realize that if they wanted to add the record they needed to do so in another way or they would realize they need to as a team lead what to do. Now, after they get the error, the UI adds 2 columns at the end of the grid to allow the user to populate the fields!!!! This is a huge problem!! While I don't think that ever happened previously even if you clicked on the old Add Detail Record link in the grid blue header, I honestly can't say that for certain and I obviously can't go back and check. However, I am pretty sure I tested it because it was critical that they not be able to add records that way. Moreover, as I mentioned, in more then 2 years no one ever added new records this way once the functionality was adjusted. Regardless whether the functionality existed before, why in the world would QB hard-code the UI to add fields to a grid that the end-user developer made a choice to NOT add to the grid (very likely for an important reason)? Whether this is a new feature or not, I would respectfully like to suggest QB seriously consider removing such a feature - the end-user developer, not QB should be the only one who is able to choose what fields their users see and can edit.
Please forgive the frustrated tone, but these issues are now requiring a fairly significant cost expenditure to deal with apps that worked properly before and now have a significant design loopholes that appear to have been created solely by arguably unnecessary QB UI changes. First, we need to incur the time and expense to clean up the erroneous records that users created by using the UI loopholes. Moreover, without a fairly prompt UI change to fix these loopholes, we will also have to incur time and expense to figure out a way to re-engineer our apps and processes to avoid these loopholes, which will result in further time and expense to re-train users. As you might imagine it is very frustrating and hard to explain to business stakehohlders who control budgets why we need to incur these costs, particularly since they seem to have resulted from UI changes that had no real purpose - i.e. in this case the UI already allowed end-user devleopers to include an Add New Record button and now the UI removed our option to NOT include such a button (plus users were already able to add lines to the grid, so there seems to be no purpose to a button that simply directs the user's cursor to a new line vs the user putting the cursor there).
I hope this additional information arms you with sufficient information to make a case to support this request that QB address these UI design issues.
Thank you for participating in this thread and providing additional information about the changes and thank you, in advance, for considering this feedback!
I wanted to comment to highly encourage that QB quickly re-consider this design change or find a way to make it optional (as you suggest you will look into in a reply to another comment below). In order to support this feedback/request, I wanted to give you some additional perspectives and a use case example why this change is more than a minor problem.
Since it has always been possible to include an Add Detail Record Button (from the customize form page), I can't see why there was any need to now include a non-optional button that is just calling out to be pushed. In my experience, if you give users a box, they will type in it and if you give them a button, they feel the need to push it, even when you have given clear instructions not to do so. I believe people are psychologically more likely to push to a button than click on a link, which it sounds like was precisely the thought behind the button. However, by doing that and not making it optional for end-user developers, QB has, as a practical matter, made a design choice for us as developers that impacts how our users interact with our apps and in some cases, like mine, in a very unwelcome way. However, I was encouraged to find this thread and your responses and I am taking a shot that you seem to be someone willing to accept feedback and likely have the connections to get that feedback to the right decision-makers and UI designers at QB.
In fact this has already created problematic usage and resulted in unwanted records and record errors in multiple apps we have designed. Specifically, now users can add records in a way they are not supposed to and previously could not. In our case, we can't deny permission to add a detail record, because we, in fact, need them to be able to add detail records. However, we need the records to be added in a controlled manner with certain critical admin information about the situation in which the record was created. We had done this nicely through API-controlled buttons, which added the detail record AND also auto-populate other criticial admin info fields. Moreover, the buttons only appear when certain conditions exist, as there are situations where we don't want the user to add records. Since there was not an option to have an editable embedded grid without the ability to add a new record directly on the grid, we accomplished this by making certain critical admin info fields required and showing them on the grid only through formual fields (since there is also unfortunately no option to make a field-read only on a grid like you can do on a form). This worked great for the last couple years. We completely eliminated issues where users had added records that did not have the critical admin info we needed. That is, until this past week, when we started to see records that were manually added (i.e. not using the API buttons we created and that the users have been instructed to use) that did not have the critical admin info that the API buttons added.
Since I don't use the app daily and have not needed to update any forms since the new UI change, I had no idea there was now a new active button on my forms. After testing, I now realize that they were able to do this by using the new button. When a user clicks on the newly added New Detail Record button and try to fill out the grid and then Save the record, they get an error saying the record cannot be saved because 2 required fields are blank. That is what previously happened if they just tried to add a record to the bottom of the grid. At that point the user would realize that if they wanted to add the record they needed to do so in another way or they would realize they need to as a team lead what to do. Now, after they get the error, the UI adds 2 columns at the end of the grid to allow the user to populate the fields!!!! This is a huge problem!! While I don't think that ever happened previously even if you clicked on the old Add Detail Record link in the grid blue header, I honestly can't say that for certain and I obviously can't go back and check. However, I am pretty sure I tested it because it was critical that they not be able to add records that way. Moreover, as I mentioned, in more then 2 years no one ever added new records this way once the functionality was adjusted. Regardless whether the functionality existed before, why in the world would QB hard-code the UI to add fields to a grid that the end-user developer made a choice to NOT add to the grid (very likely for an important reason)? Whether this is a new feature or not, I would respectfully like to suggest QB seriously consider removing such a feature - the end-user developer, not QB should be the only one who is able to choose what fields their users see and can edit.
Please forgive the frustrated tone, but these issues are now requiring a fairly significant cost expenditure to deal with apps that worked properly before and now have a significant design loopholes that appear to have been created solely by arguably unnecessary QB UI changes. First, we need to incur the time and expense to clean up the erroneous records that users created by using the UI loopholes. Moreover, without a fairly prompt UI change to fix these loopholes, we will also have to incur time and expense to figure out a way to re-engineer our apps and processes to avoid these loopholes, which will result in further time and expense to re-train users. As you might imagine it is very frustrating and hard to explain to business stakehohlders who control budgets why we need to incur these costs, particularly since they seem to have resulted from UI changes that had no real purpose - i.e. in this case the UI already allowed end-user devleopers to include an Add New Record button and now the UI removed our option to NOT include such a button (plus users were already able to add lines to the grid, so there seems to be no purpose to a button that simply directs the user's cursor to a new line vs the user putting the cursor there).
I hope this additional information arms you with sufficient information to make a case to support this request that QB address these UI design issues.
Thank you for participating in this thread and providing additional information about the changes and thank you, in advance, for considering this feedback!
