grid edit new add record button

Thanks, Sam. 
I really really do like about 99.999% of the new UI. I even liked the purple!
But I don't like this. It doesn't match. And on new records where the report is empty, it really looks funny. On the other hand, oh, well. 

Yeah, we're looking at what we can do to make it a little less intrusive. Thanks for the feedback, Beth.

Sam Jones
QuickBase Product Manager
 

Thx Sam, you are right that add button was so subtle that really no one was really "seeing it". It is better this way to be exposed, imho.

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!

>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. 

So true:

Famous Ringo Quote form Yellow Submarine
https://beatles.coolcherrycream.com/assets/sounds/yellow-submarine/06-lever.wav

Alice had the same propensity: