I am a hardcore DRY fan 
I donāt like adding more code than needed.
Thatās why I only have one AC browser component for all my app. I donāt want to have to add it to every single page. Even if that means I need to memorize the browser component API as it will not show up in data picker.
Anyway I understand itās a big change of paradigm but thatās the reason I am 90% of the time in code view.
Absolutely.
On the server side things feel pretty solid.
On the client side I very rarely use the data pickers. I could go on for a long time about all the issues, but Iāve just learned the respective code and get on with using it.
Sometimes I donāt think any data picker would make it easier than coding once you really know the code structure.
Other times, it is just a frustration that a GUI is there but hasnāt received so much love from the team.
I know from other posts Iāve participated in that the team understand this, and Iād love to see a reimagined Data Picker become a major enhancement for Wapppler now, as DB Manager was a year ago!
@George, turning the Data Picker from a formatter into a complex expression editor would be a fabulous start. You and I debated this in a post a year agoā¦
For me the next priority would be to make sure what code is created and options offered is always always always appropriate to the situation.
Two biggest examples are
(1) When in a loop of query.data sometimes getting code like query.data[0].id rather than id
(2) when in a flow, not being offered the input parameters by default.
Iād love to see a post from the team which basically said:
Hey users, tell us all your data picking problems. Show us examples. Let us take all your input and suggest a serious redesign and get your feedback on it. Then we will make it the core of Wapplerās GUI for the future!
That is exactly what I typed above. So feel free to offer examples.
We only established that Ken doesn't actually mean enhancing the data picker, but manipulating nested data in data store. So he posted a separate topic.
Well, not exactly. 
Ken saw that he was not able to communicate his thoughts properly on a bigger redesign, and opted to focus on a single subject, nested data in the data store. He is still very much in support of making broad changes that will address advanced users spending most of their time in code view.
Well keep on the ideas coming then
Yes the idea was to build a separate logical expressions builder that behaves like the query builder and allows you to build complex logical expressions with andās and orās
Not sure if that is what Ken means.