Datagrip Table/Field Editor: Seriously... what in the hell were you thinking?
I just completed a survey as part of my evaluation of Datagrip. My chief complaint about the software is the new table/field editor. It is NOT easy or quick to use. I shouldn't have to type a field name twice to set it as a primary key. It's a HORRIBLE interface, and that feature alone is pretty much ensuring that I will not be purchasing Datagrip. This is a shame, because I do like the other features. But I've found that it takes me a lot longer to get things done with Datagrip than it does with Heidi SQL (my current tool). It's difficult to beat a free tool that performs better. The whole reason I was considering leaving Heidi is because of the occasional crash that Heidi is well-known for. But I feel like I can deal with that over the painfully slow and un-intuitive table/field editor in DG.
Now, I am fully aware of the table/field editor options labeled "(Old UI)" and I do like working with that old UI. It works great and I am struggling to understand why it was "up"graded. As a developer, seeing any feature labeled "Old UI" tells me three things:
1. The company KNOWS the new UI is terrible, but they implemented it anyway, probably for political reasons... some senior developer wanted to flex his or her muscle and show the company just how fragile their ego really is, and got it pushed through. But, because they don't want to lose customers, they left the old one in anyway while they figure out how to clean up their mess (and not upset the programmer with the fragile ego).
2. It means the old UI will eventually be phased out in a future version. In my 22+ years of development, I have NEVER seen a legacy feature last too long. I am afraid that one day I will open DG and the old ui will be gone, and I'll be forced to use the "improved" UI. I'm not going to gamble my money on that.
3. This company makes very poor UI decisions; who on EARTH thought it would be a good idea to remove the "Make primary key" checkbox and replace it with forcing the user to click the create button, click "Key", type the field name out AGAIN, and finally check the "Primary" box? Who approved that? Who thought replacing 1 mouse click and zero keystrokes with 4 mouse clicks and several keystrokes was an improvement?
This is more than just a step backwards, it's about 10 steps backwards. And it made it all the way through the QA process and was pushed to the live version? Really? I can't help but look to the future: What else works great right now that they're planning to take away and make significantly more difficult in the future? And when they do, will they provide an "Old UI" option? And if so, how long before that is taken away? If I'm buying your software, it means I'm happy with how it works. That should translate to "Don't take it away" to normal people with brain function.
That alone is what will prevent me from making this purchase. I refuse to pay money for software that is counterintuitive, slower, and more difficult to use, and live in fear of working features being ripped out and replaced with garbage. I would rather just continue to use the free competitor that occasionally crashes.
I'm not sure I trust you at this point. I'd need a good deal of assurance from JB that this problem is a one-off, will be immediately rectified, and won't happen again before I even THINK about laying down good money for this. No trust = no money.
Please sign in to leave a comment.
We've released the new version with lots of improvements, please check it out:
https://blog.jetbrains.com/datagrip/2022/08/23/datagrip-2022-2-2-improves-the-modify-object-ui/
New UI is junk. Tables now take 3x as long to make and is only likely to get worse. I used to like using Datagrip for database creation now hate it. I don't like having to create the table a single column only, then going back and adding primary key and unique states as separately things when the old interface streamlined the process. Foreign Key creation no longer auto names the key appropriately (nor does primary key creation). Nearly all UI functions are now useless and over complicated. It is now much much easier to just write it in SQL which defeats the purpose of the tool entirely.
All the problems with old design (on your code side and engineer side are your problems not your users). We as developers write software for users NOT our product manager, team lead, UI designer and the developer. If you lose site of that your product will suffer. Please evaluate your priorities.
I am fixing the issue by reverting back to 2022.1.5 as this is a better version for the customer.
Thanks
Disabling the 'new UI' does not give us the ability to use the old ui table/field editor as there is no longer menu options for 'Modify table (old UI)'. With the new UI disabled, clicking Modify Table still takes us to the new table editor which was the topic of this discussion.
Old UI is much more better and efficient to use. New UI is still very confusing and difficult to use.
The new UI is an unusable piece of garbage. The "old UI" was removed from 2023.2 and now the whole product became unusable. Great job, thanks Jetbrains!
No checkmark for AutoIncrement, Unique, PrimaryKey,
No overview of all columns' params at one screen.
Table UI with adding columns row by row is much more convenient: all the data is visible. Now I should look at the code section, at the treeview section, at the section with selected column params to understand what's going on. Frankly, I've never seen so inefficient against-the-user UI
I agree with what Amberon said here as far as what is worse in the new UI. I 100% rely on the "Old UI" in my day to day .
Any chances to enable again the old ui? Maxim Sobolevskiy
Maxim, the "old" tabs looked much cleaner while the "new" tree made everything look cluttered and cumbersome. The new UI requires a bigger screen to fit the tree. The tree is not intuitive in terms of navigation. The tree-related toolbar is confusing. I'm sorry for the harsh words in my original post, but while the new UI works it's unclear why do we need it? Does it bring something new to the table? Something that was missing in the old/classic UI? I don't think so. Does it bring confusion to the existing user base? It sure does. Thousands of people are got used to the classic UI which was nice and intuitive. Yes, it's not a helluva learning curve to switch from tabs to tree, but I think it's completely unnecessary, since there are no benefits. It is just my opinion, and I'd love to hear from you guys what am I missing.
Hello, Brian! Thank you for your detailed feedback, we appreciate your time spending to write all this.
First, I will comment on general assumptions you made: the desicion to write the completely new UI was made with the involvement of the product manager, team lead, UI designer and the developer. The old UI had LOTS of problems, and one of the major ones was the inconsistency when speaking about different databases. It was super hard-coded and therefore was very difficult to support. The new UI has a generated nature and hence is much more powerful.
So, yes, of course you are right: one day it will be dropped. But ONLY when all the usability and technical regressions will be addressed. And that's why we left it there: we don't want anybody to be stuck in them. You faced the regression, yes, but there is an old UI to help you. And our job is to make the new one better for everybody. The old one will live until we reach this goal, no matter when it happens.
Your concerns are 100% valid and here is what will be released in one of our minor updates:
1. Ability to create PK from the context menu of the column.
2. Ability to create PK from the column details.
Of course, in both cases the column name will be already in the corresponding field.
So it will be also rather simple, but also more powerful: there will be a possibility to create composite PKs. It was impossible with the checkbox from the old UI.
I hope to have all this on 2022.2.2.
Again, thank your for your feedback and helping us getting better. I wish it was a lil bit less aggressive, because we're all humans.
Max.
If anybody prefer the Old UI, like I do (and apparently everybody else on this thread), you'll be glad to know it's still there in IntelliJ. Seems really kludgy to use a development IDE to create tables, but it's comforting to know it's there (for now).
Thanks for the feedback, Jbuffington!
First and foremost, we admit that the new UI has usability issues. Of course we tested it, but anyway, when you test the product you are aware of, some things can be missed. That's why now we pay much attention to posts like this to cover all use-cases. And that's why the old UI is still there not to make everybody use the new one if they don't like it.
The old UI will be dropped ONLY when the new one will provide zero usability regressions. Our goal is to make it better for everyone including you.
Your points are valid of course, we are going to release the improved version on the closest minor update.
1. The primary key with all the generated names will be possible to create with two clicks from the column editor.
2. The FK will also have the pre-generated name.
The problems with the old UI were not only technical. It lacked lots of functionality and couldn't be customized according to the DB engine. Also, the approach with expandable fields was not convenient for many users.
We are sorry that your experience was not perfect, but we do hope that the new version will finally be handy for you as well. We are listening to users, we are working on it and we DO care about how it is used in real life.
Thanks!
Please give us particular examples of what is worse in new UI, that is the only way to improve it.
The main reasons was described in this post: https://blog.jetbrains.com/datagrip/2022/08/23/datagrip-2022-2-2-improves-the-modify-object-ui/
The new UI is auto-generated. The main reason was that with so many supported database engines, DataGrip just could not provide a powerful UI for objects in each of them. We could manually build the dialog for 3 or maybe 5 databases, but not for 25 of them.
The new design was required to deal with the unexpected number of object properties. As the result, the new UI contains MUCH MORE properties of objects you want to modify.
Also, there was a big amount of nesting there, the majority of which is now moved to the tree on the left. Anyway, having the tree makes everything unified which makes it easier to maintain and decrease the number of bugs.
Another thing: in the old UI it was hard to observe al properties of the column at once (like not null), also it was impossible to see, say, both primary and foreign keys. Now it's possible.
Another feature which UI will bring: multiple edit. You will be select several objects and edit them in bulk. We'll fix the bugs and release it soon.
>Thousands of people are got used to the classic UI
Based on the feedback we get, there are not many users of that kind and not thousands.
We still understand that for some cases the old UI was more handy, for example, renaming columns one by one. We will address that. In general, you can still use the old UI with the help of registry, but in reality it's impossible to support both. I think the good solution here is to make a call and precisely discuss what parts of the new UI can be improved so that you'll love it also. I believe that is possible.
@Oleg Old UI wasn't removed from 2023.2. It can be restored by disabling the following option in the settings:
CJ You're right, thanks. I confused Oleg's comment with feedback on the IDE's new UI in general.
Hopefully, all of the issues with the new dialogs will be addressed sooner rather than later.
If any of you guys have problems with particular bits of functionality in the new dialogs, you are welcome to submit a new bug report to our issue tracker: https://youtrack.jetbrains.com/newIssue?project=DBE We'll look into each case separately.