5 out of 5.0, Reviewed Nov 30, 2016
The company worked well with the 3rd party and was very attentive to our needs. They continue to adress issues in a timely basis.
It's not an inexpensive product, but a lot of value comes with it. Consider add-ons while pricing the product and make sure you're clear on any development costs with the company.
My end users are able to update their areas with ease.
We run the product on an appliance, but It's not always easy to deal with since OU Campus is managed solely by them and it's difficult at times to see where an issue lies. Issues are rare, but it's hard to be clear on whether it's OS based or OU Campus based
Include some of the add-ons in the base product.
Make sure there were clearer lines of communication between 3rd parties and OmniUpdate.
5 out of 5.0, Reviewed Aug 18, 2016
The product did exactly what they said it could. When reviewing the technical design of the product, we determined some creative ways of implementing it that worked almost exactly as we envisioned.
Learn the power of the OUCampus XML transformation engine and don't be afraid to customize the XSL to do helpful things. We added error-checking to our XSL so that a page cannot be published to the website server without a (metadata field) author or (metadata field) expiration date. We also added logic to produce an HTML redirect from one rendered page (the one that should look like the old website) to the other rendered page (new, temporary UI/UX) when the page was marked as "Employees Only". The new UI/UX pages forced login before being displayed, so content editors could get the benefit of a single content management heirarchy, and the result of an INTERNET/INTRANET with diverse layout and functionality.
The near-infinite power of the XML/XSL rendering design.
This release requires that the two web page products go to the same webserver diretory OR that the user perform two separate publish operations, one to each target server. If you don't have to do hokey dial-site trickery, this will never affect you.
Better error messages when someone (not me :-]) makes a typo in the XSL stylesheet.
Lock down the goals and strategies of the project as a whole before beginning implementation. We (I.T.) had formed a joint team with our Communications department, and tried to lay down a set of web content governance categories, complete with suggested strategies, before we began. The committee was intended to be cooperative, but weak leadership and self-serving grabs for control resulted in long-standing inaction. Finally, three years after product purchase, an I.T.-team-driven short-term implementation, with no UI or layout changes, was initated to migrate content from the aging legacy website before it's service contract expired. Decisions were made based on the proposed governance strategies and the content move was completed less that 30 days before the service contract expired. Now, the "real" implementation has begun, and I.T. is being left out of the decision-making process and informed after the fact of what decisions have been made about the initial governance submissions. The "real" website, with a complete UI/UX redesign, is now 3 months behind schedule and many governance issues have still not been solidified. The OUCampus product has been flexible enough to allow us to make the changes needed, but they have to be made in the 3000+ files/pages converted instead of once on the original template before conversion. Most importantly, OUCampus has allowed us to produce two copies of each webpage, with different UI/UX and layout, from a single source file. Ths allowed us to move forward with the no-change content migration and saved the day.
Occasional lapse from support team, due to our customizations, but they were consulted on all customizations that were made to their delivered code. Occasional hand-off issues between different techs.
Simple install of Tomcat, performed by the vendor in a remote-desktop-connection session. 11 months of in-house content cut-and-paste.