Our primary use case is for accessing data from a database.
Our primary use case is for accessing data from a database.
It makes things more modular. We're able to get information from our data that we were not able to before. We can get the data faster and aggregate more easily ways and in more visible ways.
All the features are pretty valuable. One that stands out is the cross-platform integration, which helps us access the data we need to see.
It's pretty easy to learn. Sometimes the terminology can be a little tricky to get around, but it's just queries with no code so once you get the hang of it, it's pretty simple. It's extremely easy to use in getting into the IDE and then back down to your applications, and getting from your applications to your pages, and navigating through all your tables. That's very simple and pretty intuitive.
They have business objects which are essentially queries or tables. To learn the structure of their software is a little tricky at first. You have tables and sitting on top of them you have data objects which are required in order to use your application which sits on top of them. To understand how those flow between each other, and the terminology that's used between them, can be difficult.
It took about a month to get everything straight in my head. You could probably do it faster. What took so long was having not having an application to develop. If you don't have an application to develop and play with, you don't really know what you're playing with. If you had an app to make, that time could be cut to three weeks.
Also, when you are trying to delete certain columns or delete or drop tables, sometimes it will throw an error and it will force you to hunt down every location where those things are being referenced. You have to delete them from the very end and work your way backward. That can get frustrating. It would be easier, when you're deleting that table, if it would concatenate all the way down. I know that's almost an industry standard when you're dealing with tables, but it could be better.
At times, when you're in an application, and you use a "back" arrow, it's limited in what it can do. I know you can have certain pages sent back to other pages, but sometimes to set all that up is a little annoying. I'm not exactly sure how I would improve that, but you can get lost once you start clicking through tabs. You end up backing up through the same pages, back and forth, and it can be frustrating.
There are a lot of almost "hidden" features captured in these Edge Case settings. That's an example of the terminology being a little bit tricky. In those settings might be exactly what you need, but the terminology that they use is not very clear. If you want a scroll bar at the bottom, instead of having it select rows to show, you have to select Disable Panel Location Service, which doesn't sound at all like what it's supposed to do. It's little things like that. Naming conventions could be changed a little bit.
It's pretty stable. It just sits on top of your stuff and it does a good job of maintaining the connection between the two. I've never had an issue where it breaks or the connection is lost for some reason. When you're working between two different systems it's tricky but that's not really a VINYL issue, it's just hard to get two machines to talk to each other sometimes.
It's pretty scalable. We're using it across a lot of different departments and it's pretty easy to throw up a new app and start working. When we add data in it very easily handles that, and we have some very large tables. It does a good job of getting information from those tables and using the information. There have been a couple of times when it timed-out but that has mostly been due to the fact that there is so much data in there. I wouldn't expect any query to be able to handle it very quickly.
Zudy's technical support staff are great. I ask them questions all the time and they are very responsive and thorough. In most cases, they get back to us in a couple of hours, if that. It depends on how busy they are and on the question. Sometimes there are questions that require more research or maybe a phone call, rather than email. Those take longer to hash out, but they're very responsive.
I wasn't involved in the initial setup but to my understanding, it took a little bit to get started. Once they got the ball rolling, it was pretty quick. It was just a matter of trying to connect to our many databases and get them set up in a way that's usable, because there are a lot of edge cases on our end. But once you developed those it was super-easy to do the rest from there.
I haven't gone, but I know that Zudy offers free training in Boston for this solution, which I think is excellent. Maybe that's just part of their way of getting their name out there. I am planning to go in the future. I imagine it's a great resource as well, on top of the manuals or the tech support or the "how to's" that they provide.
There wasn't a third-party consultant involved. Someone from Zudy was directly involved in helping us set up.
There is definitely ROI. It allows us higher visibility into our data, which allows us to data-check faster, and validate data that we had not been able to validate, prior. It has definitely saved us money. On a day-to-day level, people are able to do their work more efficiently and that's going to save them time, which is going to save money.
We did not evaluate other options for the purposes we intend to use VINYL for.
Initially, make sure you have a good structure for your database. It's not necessary, but it makes the integration a little easier. Once you have that, the best way to learn is just to play with it. Build a simple app. Work on building your tables. It's good to have a goal in mind. You focus on making that app, a very simple one, but one that is also working well. Once you get that working, within a couple of weeks you'll be a pro and you can be running through apps and developing on some level.
Beyond that, it's just fine-tuning those skills and learning what other features VINYL offers.
We have five people using it. Only I am really developing on it. Perhaps there's one other person developing on it. The goal is to have the majority of people using it in some capacity to replace all of their miscellaneous spreadsheets and to replace a lot of the interfaces that they're using. We want to make everything more consistent and centralized around one application that everyone can use.
In terms of maintenance, it takes two or three people: one on their end to make sure they're okay if something happens; one on our end to make sure our systems are okay, and one person to develop. There isn't much day-to-day maintenance.
I don't really have much to compare it to. This is the first time I've used a no-code solution like this. But in my experience, I'd say it's a nine out of ten. It doesn't get a ten because there are some features that seem to be "hidden" behind the terminology. The more you play with it you learn it but sometimes those features are not very up-front. It's not until you dig through the user manual that you get to understand what those features are about.
No-Code Development - Stay Informed