As of April 12th, you must go to Progress SupportLink to create new support cases or to access existing cases. Please, bookmark the SupportLink URL and use the new portal to contact the support team.
Its cool that you guys see a need for a new console. I love that. However in it's current state the console does not seem to be addressing the major concern I have with it. I also believe some others have this as well. So I would like to bring this to light in order to facilitate a change in the beta console.
The issue is fairly straight forward: The entity display when you click a collection is just plain ugly. It has not changed at all from the original display, though I do admit not having to scroll through 100million pages to find one this is great. I know that this is the traditional way that you see information in a database, but it could be so much clearer and/or readable. I am not sure how much discussion you guys have done internally with this issue, but I would not show a problem without suggesting a solution. Screenshots will be below.
Entity display is the disease. Meet the cure!….okay…not the cure but more like the topical ointment that reduces swelling and itch. I was thinking why not have a two paned window, and then on the right or left side of this window one pane would display all the entities with a single column as the display name and the second pane would display the details of that entity. This column would be user chosen, but would default to the entity id, aka I have a place in my database so I want businessName to be my display name. You could even make it so you can display more then one. So the second pane of this window would be the details of the item you clicked on. But it would not display it like someone just throw up on the screen. The idea is to make it readable with the idea of spacing, margins, and clear variable names. I would not do a table style like there is, but more like a key value pair with separate sections for each. See screen shot below.
So below is some screenshots I took of the database manager I build for my company. The idea here is similar to what i was talking about, but it is far from perfect. It should give you a general idea of how to use it though.
If you guys want to have a chat about how I designed this I would be happy to talk. Might be able to give some ideas on how to do this in a browser, but this design is fully automated. Meaning I can add an entity to this program and it will then allow me to save, create, delete, update, or display that entity with no major coding involved. All I have to do is add the class for the entity I need.
I have no idea if this is a welcome change or not, but I know it has been a sore point from the very start for me: hence why I created the Database Manager. It just seems like in the new beta console it would not to hard to make a much better way to display information, that is easier to modify, easier to look at, but still has the search and functionality of the classic table driven format.
Let me know what you think! Carline you have my email/skype so if you want to get into more discussion about it feel free to call me or post here.
Sean - Thanks for the detailed feedback! I'm the lead UI developer for the console, and this kind of feedback is a tremendous help for our team.
I like your unconventional approach to displaying data. You're right - while the traditional way to view data in a database might be the table style approach we've taken, it's definitely worth considering other options.
I'm curious to understand your use case a bit better. Can you describe what you typically use your Database Manager for? In other words - when you first open the Database Manager, what is your goal? What are you there to accomplish?
Also, you mentioned you built this Database Manager for your company. Are you the sole user, or do other people use it as well? If others use it - do they have the same goals, or are they usually trying to accomplish other tasks, and do those tasks look like?
I know you've probably spent a good chunk of time on this post already, but understanding your use case is key to helping us deliver a great UI. Let me know what you think!
S
Sean Hoffman
said
almost 9 years ago
Thanks for the quick reply.
So the short answer is to manage data. Currently it is a in house product (that me and a couple of others use) that will eventually make it into the hands of our customer. They will be getting a more controlled version, aka they can only access there data.
The long answer, well it is much more then database manager. currently I built a platform to launch apps with a turn around time of about a month. With this approach to app development I opted to store all the settings for the app in a config file. Some settings include themes, colors, image names, database options, debug modes, social account database options, and even some configuration for app screens. With this approach we can upload the settings file on a per app basis and then just cache and load this file from the database when the app starts. So with the same code base I can make multiple different apps all with the change of a file. This is great not only from a debug standpoint, but also from a turn around stand point. If the database dies tonight or we have a fetal error that messes up the app I can then change in the settings file which database to use or which collection to use. We can also use this to change colors, themes, even images and the best part is we never have to recompile code and re-release to the app store avoiding that 2 week turn around time. Well this design presented a issue though. Namely, we need a way to modify the file that is a bit..... ummmm prettier then the console for Kinvey. Since the file can get pretty large a table going to the right for ever just was not going to cut it. Currently we would have over 55 items that would be considered columns for Kinvey, and these items could be numbers, strings, arrays, dictionaries, or booleans. This would make for a fairly large table that would make the data unreadable and/or hard to change. Among other reasons, like not giving login info to customer, and the somewhat programmer oriented UI (Not that it is a bad thing), we opted to build the database manager tool to use.
We also use it for database scrubbing and to configure some app settings that is separate from the settings file. Like what our home screen looks like for each app.
So when we start the database manager it asks what database to connect to. Then we can select which app to use if there is more then one. Then we can choose which collection to look in. It will then pull the data out for us to change. So if a place was added to the database and it still needs a geo location we could use this tool to find it and then geo locate it. If there was a misspelling in a place name or there are duplicate places this tool would help manage those. If we wanted to have a featured item on the home screen I would pull it up in the database tool to add it to the home screen.
As I said, short answer is to manage data. Long answer well you get the idea. Hopefully i made a bit of since. I can articulate better using voice, but if you need clarification or something let me know.
So in conclusion back the original point. What does the beta Kinvey Console have anything to do with all this? Well glad you asked. I know that the Kinvey console will probably not be able to solve all of the problems I have presented, like having logins for customers, and maybe not the best UI, but what it could do though is make the data accessible in less direct more focused way. And I will say that not everyone would want this, some programmers love "super filled table of throw up in your face data," but this does not bode well for the not so programmer types who are used to pretty interfaces with data laid out in a more ergonomic fashion, aka iPhones/Androids/WIndows Phone. And to be honest it does not see like it would be that hard to maybe keep the table if you had to. My suggest above is probably not the best option but I think it can organize the data to be a bit better. Some other ideas might include allowing us to define what order the column data is displayed in. Aka 100% of the time I could care less about the object id, the data created, and the person that created it yet when ever I am in the console those columns take up 75% of my screen when I am searching for something. What I might be more interested in seeing more often might be variables that I have set.
Well I feel like I am ranting now so hahahaha. As you can see I have put a ton of thought into this, seeing as I built a program to solve this issue. Let me know if you need any more info on the subject.
Thanks,
Sean
P.S if you guys want a demo or something to maybe stimulate ideas or just check out a different approach. Let me know I am sure something can be worked out. Got to start somewhere.
Sean Hoffman
The issue is fairly straight forward: The entity display when you click a collection is just plain ugly. It has not changed at all from the original display, though I do admit not having to scroll through 100million pages to find one this is great. I know that this is the traditional way that you see information in a database, but it could be so much clearer and/or readable. I am not sure how much discussion you guys have done internally with this issue, but I would not show a problem without suggesting a solution. Screenshots will be below.
Entity display is the disease. Meet the cure!….okay…not the cure but more like the topical ointment that reduces swelling and itch. I was thinking why not have a two paned window, and then on the right or left side of this window one pane would display all the entities with a single column as the display name and the second pane would display the details of that entity. This column would be user chosen, but would default to the entity id, aka I have a place in my database so I want businessName to be my display name. You could even make it so you can display more then one. So the second pane of this window would be the details of the item you clicked on. But it would not display it like someone just throw up on the screen. The idea is to make it readable with the idea of spacing, margins, and clear variable names. I would not do a table style like there is, but more like a key value pair with separate sections for each. See screen shot below.
So below is some screenshots I took of the database manager I build for my company. The idea here is similar to what i was talking about, but it is far from perfect. It should give you a general idea of how to use it though.

If you guys want to have a chat about how I designed this I would be happy to talk. Might be able to give some ideas on how to do this in a browser, but this design is fully automated. Meaning I can add an entity to this program and it will then allow me to save, create, delete, update, or display that entity with no major coding involved. All I have to do is add the class for the entity I need.
I have no idea if this is a welcome change or not, but I know it has been a sore point from the very start for me: hence why I created the Database Manager. It just seems like in the new beta console it would not to hard to make a much better way to display information, that is easier to modify, easier to look at, but still has the search and functionality of the classic table driven format.
Let me know what you think! Carline you have my email/skype so if you want to get into more discussion about it feel free to call me or post here.
Thanks,
Sean