Systems Support Specialist at a construction company with 5,001-10,000 employees
Real User
2019-12-23T17:22:00Z
Dec 23, 2019
I do coding, so I often think that it would be nice to have subroutines, in separate templates, that could be shared among other templates. However, I understand the limitations of Word Field codes. I have to deal with VERY long lists of properties contained in our XMLs and it would be nice if Windward offered a way to alphabetize this property list. I understand that we could alphabetize our XML and this would happen automatically, but I think this would be a useful tweak for many users. At least if they have to deal with a lot of data like we do.
Vice President of Product Management at Baker Hill Corporation
Real User
2019-08-28T05:33:00Z
Aug 28, 2019
Any time that we have wanted something, Windward has been right there to build it. I would have a hard time saying what they need to improve on. What I would say is that the industry is going to be looking for continued flexibility in terms of filtering, nesting, and building more complex, almost business-intelligence-type rules and reports. What we're going to need to see is that narrowing of the gap between the analytics and management in terms of what they're going to want to see and view. The more sophisticated customer is going to want some of that information shared back with them. That's going to be an area where there'll be some potential improvement. But the Windward team is constantly monitoring that. They've got this under control. We feel we're in really good shape with them. One of the things we've continued to hear is that our users talk specifically about AutoTag and more concepts around filtering, nesting, and sorting; more flexibility around that. Windward is pushing that envelope and they're doing a great job with it. So we're happy with it.
One of the things that we want is the ability to tag documents more easily. The reason it took us so long to get the system up and running is that the APIs could be improved a bit. It could be a little bit more interoperable with software, without having to do a lot of the heavy lifting that we had do to get it in. Once you get it, it's fine. But it did take a little bit of time, and that's due to the fact that the APIs weren't really there and we didn't have a lot of documentation. There was a lot of going back and forth. They could improve that.
Solutions Architect at a financial services firm with 501-1,000 employees
Real User
2019-02-07T12:28:00Z
Feb 7, 2019
One thing that frustrated us a little bit is that we have to use the Office PDF generation, because the native PDF generation is always slightly different compared to the one in Office. The formatting is just a little bit off here and there. Sometimes a page-break will not appear. There are always some little differences between the native PDF and the Office PDF. This means that we need to have Office installed on the server to be able to generate these documents via API. That's been a bit of a frustrating limitation for us. They do continue to improve that, but because we want to maintain documents exactly as we see them in Word, we have to use the Office PDF generation, instead of the native PDF generation. And that takes a little bit longer to generate as well, whereas if it was the native generation, it would take less than half-a-second. The Office PDF generation takes a bit longer, it can take up to two to three seconds to generate a single document. So there is a bit of a performance hit there. This is the one negative aspect that we fought through. It didn't stop us from using the solution. But it is something that we hope, over time, will improve. If they could get the native PDF generation to be one-to-one with the Office generation, that would make it an exceptionally good product for us.
Technical Manager at a tech services company with 201-500 employees
Real User
2019-01-21T09:10:00Z
Jan 21, 2019
A few years back, we suggested they make it work for JSON because we were using XML format. They've already done that JSON formatting. From our perspective, it's meeting our requirements so we had not asked for any improvements in recent times. I don't see any major change which could benefit us. One thing I could say, as is always the case, is that they could make the document creation performance faster. I'm not saying it's slow but it takes time to create the PDFs. If they could make it faster, that would be one area for improvement. It's not a negative at this point, but the world is moving to ultra-fast performance, so that area is something they can look at. I'd like to see improvement from microsecond to nanosecond performance because that's the kind of demand in the market, to be faster and faster.
About six months ago, we raised the possibility of improving the way they manage HTML 5. Sometimes, when you insert a lot of data in the data source, you get an error because it is not managing HTML 5 features well. I believe they have addressed this in later versions of their product.
Their PDF needs improvement. We've run into some issues when we tried to generate a Word document. If we try to generate the same document in PDF, sometimes it doesn't look exactly the same. We have gone back to Windward support a couple of times on a few issues, e.g., we had some issues with reports that had barcodes on them. The barcode wasn't displaying properly. It was displaying as a skewed image as opposed to an actual barcode. Therefore, we worked with Windward support, having some daily calls with them. Then, within the next release, they were able to resolve the issue. They even gave us a pre-release, so we could implement it into our code before the actual official release on the website. It would be nice to have some sort of workflow capability within the product. Anytime you generate a document, nine out of ten times there is something which precedes that document, whether it's entering parameters in, e.g., if I'm requesting the status report for a project. The first thing that I usually want from a status perspective is which project is the status report for and which week is it for, as those are some of the things that I have to supply before I can generate a document. From a workflow perspective, it would be nice to say, "This project belongs to this person, and this person is okay with me pulling information out of this document for whatever need I have." From a workflow perspective, I would like a wizard interface that goes step-by-step, like a questionnaire, where there are a bunch of things that you have to answer, "Yes or no," before it knows what to do or how to produce the document. Right now, we write our own custom UI for this.
Regarding AutoTag, we do notice that when you want to refactor a little bit of your template design or when you want to implement changes, sometimes you need a lot of clicks to get the change done. For instance, if only one identifier's name is changed and you need to change that identifier throughout your documents, it would be helpful to be able to do a find-and-replace, find all the identifiers with the old name and replace them with the new name. We haven't found a way to do that with a find-replace tool. Throughout the Windward user interface, you need a lot of clicks to get that done. That can be a somewhat tedious task. If you want to do somewhat more technical tasks, the front end can be a little bit slow or inefficient because you need to perform a lot of clicks to get the technical change done. Also, there's always a little bit of a struggle for our customers to get the licensing done. That is because we develop on a platform that would prefer a Java Engine. The platform will communicate better with a Java Engine. The platform also does install with many instances, and the problem is that for every instance you have to pay for a license which will then increase the cost enormously. Instead of using the integrated Java Engine we are now using th RESTful engine, which is kind of like a standalone Windward instance that we can call as a service. It generates documents for any of the instances that we want. So instead of having ten Java instances, we only need one RESTful instance for the same functionality, and for one-tenth of the cost. So even though the preferred technical implementation is Java, we are using RESTful, simply because the licensing costs are a lot less. I find it a bit of a shame that the business model doesn't allow us to use the preferred technical implementation.
* It needs the ability to drill down in a single report (i.e., interactive) into data. * The next release could benefit from a cloud-based environment.
It is a very good product. It does everything we need it to do. The only thing I can think of, that we'd like it to do, would be the ability to "burst out" reports, meaning one section of a report could be sent out as an email to a manager of a department, say, without having to run multiple reports to do it. As it sits now, we have to do multiple reports to do it.
It would be nice to have a black-and-white, ideal setup for servers, to maximize capabilities. We went through a lot of scenarios to get something that is scalable. An ideal AWS-package server setup could have saved us a lot of time. But I understand this is very company specific.
What is Windward Studios?
For over a decade, Windward has been a leader in the software development industry by creating the most innovative and advanced document automation and reporting software on the planet.
Data-Driven Document Automation
Generate stunning documents that incorporate relevant data easily and seamlessly.
Visually Striking Designs
Our software provides innovative tools and features to build beautiful designs and stunning layouts, all within the familiar Microsoft...
I do coding, so I often think that it would be nice to have subroutines, in separate templates, that could be shared among other templates. However, I understand the limitations of Word Field codes. I have to deal with VERY long lists of properties contained in our XMLs and it would be nice if Windward offered a way to alphabetize this property list. I understand that we could alphabetize our XML and this would happen automatically, but I think this would be a useful tweak for many users. At least if they have to deal with a lot of data like we do.
Any time that we have wanted something, Windward has been right there to build it. I would have a hard time saying what they need to improve on. What I would say is that the industry is going to be looking for continued flexibility in terms of filtering, nesting, and building more complex, almost business-intelligence-type rules and reports. What we're going to need to see is that narrowing of the gap between the analytics and management in terms of what they're going to want to see and view. The more sophisticated customer is going to want some of that information shared back with them. That's going to be an area where there'll be some potential improvement. But the Windward team is constantly monitoring that. They've got this under control. We feel we're in really good shape with them. One of the things we've continued to hear is that our users talk specifically about AutoTag and more concepts around filtering, nesting, and sorting; more flexibility around that. Windward is pushing that envelope and they're doing a great job with it. So we're happy with it.
I would like to see examples included within the Wiki information to show how each function option could be used.
One of the things that we want is the ability to tag documents more easily. The reason it took us so long to get the system up and running is that the APIs could be improved a bit. It could be a little bit more interoperable with software, without having to do a lot of the heavy lifting that we had do to get it in. Once you get it, it's fine. But it did take a little bit of time, and that's due to the fact that the APIs weren't really there and we didn't have a lot of documentation. There was a lot of going back and forth. They could improve that.
One thing that frustrated us a little bit is that we have to use the Office PDF generation, because the native PDF generation is always slightly different compared to the one in Office. The formatting is just a little bit off here and there. Sometimes a page-break will not appear. There are always some little differences between the native PDF and the Office PDF. This means that we need to have Office installed on the server to be able to generate these documents via API. That's been a bit of a frustrating limitation for us. They do continue to improve that, but because we want to maintain documents exactly as we see them in Word, we have to use the Office PDF generation, instead of the native PDF generation. And that takes a little bit longer to generate as well, whereas if it was the native generation, it would take less than half-a-second. The Office PDF generation takes a bit longer, it can take up to two to three seconds to generate a single document. So there is a bit of a performance hit there. This is the one negative aspect that we fought through. It didn't stop us from using the solution. But it is something that we hope, over time, will improve. If they could get the native PDF generation to be one-to-one with the Office generation, that would make it an exceptionally good product for us.
A few years back, we suggested they make it work for JSON because we were using XML format. They've already done that JSON formatting. From our perspective, it's meeting our requirements so we had not asked for any improvements in recent times. I don't see any major change which could benefit us. One thing I could say, as is always the case, is that they could make the document creation performance faster. I'm not saying it's slow but it takes time to create the PDFs. If they could make it faster, that would be one area for improvement. It's not a negative at this point, but the world is moving to ultra-fast performance, so that area is something they can look at. I'd like to see improvement from microsecond to nanosecond performance because that's the kind of demand in the market, to be faster and faster.
About six months ago, we raised the possibility of improving the way they manage HTML 5. Sometimes, when you insert a lot of data in the data source, you get an error because it is not managing HTML 5 features well. I believe they have addressed this in later versions of their product.
Their PDF needs improvement. We've run into some issues when we tried to generate a Word document. If we try to generate the same document in PDF, sometimes it doesn't look exactly the same. We have gone back to Windward support a couple of times on a few issues, e.g., we had some issues with reports that had barcodes on them. The barcode wasn't displaying properly. It was displaying as a skewed image as opposed to an actual barcode. Therefore, we worked with Windward support, having some daily calls with them. Then, within the next release, they were able to resolve the issue. They even gave us a pre-release, so we could implement it into our code before the actual official release on the website. It would be nice to have some sort of workflow capability within the product. Anytime you generate a document, nine out of ten times there is something which precedes that document, whether it's entering parameters in, e.g., if I'm requesting the status report for a project. The first thing that I usually want from a status perspective is which project is the status report for and which week is it for, as those are some of the things that I have to supply before I can generate a document. From a workflow perspective, it would be nice to say, "This project belongs to this person, and this person is okay with me pulling information out of this document for whatever need I have." From a workflow perspective, I would like a wizard interface that goes step-by-step, like a questionnaire, where there are a bunch of things that you have to answer, "Yes or no," before it knows what to do or how to produce the document. Right now, we write our own custom UI for this.
Regarding AutoTag, we do notice that when you want to refactor a little bit of your template design or when you want to implement changes, sometimes you need a lot of clicks to get the change done. For instance, if only one identifier's name is changed and you need to change that identifier throughout your documents, it would be helpful to be able to do a find-and-replace, find all the identifiers with the old name and replace them with the new name. We haven't found a way to do that with a find-replace tool. Throughout the Windward user interface, you need a lot of clicks to get that done. That can be a somewhat tedious task. If you want to do somewhat more technical tasks, the front end can be a little bit slow or inefficient because you need to perform a lot of clicks to get the technical change done. Also, there's always a little bit of a struggle for our customers to get the licensing done. That is because we develop on a platform that would prefer a Java Engine. The platform will communicate better with a Java Engine. The platform also does install with many instances, and the problem is that for every instance you have to pay for a license which will then increase the cost enormously. Instead of using the integrated Java Engine we are now using th RESTful engine, which is kind of like a standalone Windward instance that we can call as a service. It generates documents for any of the instances that we want. So instead of having ten Java instances, we only need one RESTful instance for the same functionality, and for one-tenth of the cost. So even though the preferred technical implementation is Java, we are using RESTful, simply because the licensing costs are a lot less. I find it a bit of a shame that the business model doesn't allow us to use the preferred technical implementation.
* It needs the ability to drill down in a single report (i.e., interactive) into data. * The next release could benefit from a cloud-based environment.
It is a very good product. It does everything we need it to do. The only thing I can think of, that we'd like it to do, would be the ability to "burst out" reports, meaning one section of a report could be sent out as an email to a manager of a department, say, without having to run multiple reports to do it. As it sits now, we have to do multiple reports to do it.
It would be nice to have a black-and-white, ideal setup for servers, to maximize capabilities. We went through a lot of scenarios to get something that is scalable. An ideal AWS-package server setup could have saved us a lot of time. But I understand this is very company specific.