Ever since we started developing Elvis DAM, we knew that a great performance needed to be one of our strong points. Especially since a lack of search performance in most legacy DAM systems was one of the most frequently heard complaints when we were discussing our original ideas for Elvis with customers.
In the last 4 years, we increased the Elvis performance with every major release. But the asset repositories of our customers did increase as well.. So we recently decided to test Elvis DAM to see how it performs with large numbers of users and large repositories.
In my previous blog I promised to discuss a scripting sample. Well, here it is.
A common problem in production systems is the following: there are many template layouts, all having the same style definitions. Once you need to update a style definition, you need to make the change in every single template layout, which is a lot of work.
(BTW Instead of creating many different template layouts having the same styles, you could also create a single template layout with multiple masters in it. This prevents the duplication of style definitions and you would not have the problem above).
The manual method of updating all templates would be:
- designate one of the template documents as the master in which you have made the required style changes
- query all template documents
- open the first template document
- update the style definitions by importing all (text) styles from the designated master document
- save and close the template document
- repeat this for all other templates
The last quarter of the year was an interesting time for observers of the German newspaper market. Mid November, the publisher of the highly respected daily Frankfurter Rundschau filed for insolvency. Four weeks later, the publishing house Axel Springer launched the paywall for Die Welt – with a reach of 862,000 readers one of the leading daily newspapers in Europe.
Working for a technology company, and being surrounded by a marketplace that is full of technology developers and vendors asking for ones attention, it’s easy to to forget that technology is not the ultimate goal, it’s there to help you reach a goal - the creation of quality publications.
As a consultant for WoodWing I am involved in judging incoming feature requests before they are actually added to our feature database for implementation by development.
We always look for the actual business case behind the request. Did the sender overlook an existing feature? Is there a different way of using the system to support the business case? Could the system be configured differently to realize the requirement? Or is the business case so specific that it cannot be turned into a generic feature request?
Valid feature requests will be scheduled for a roadmap release by product management. But, as you’ll understand, it can take a while before the feature ends up in the product, and often customers need it today.
So, why wait for a next release? Why not do it yourself? WoodWing’s products are well-known for their flexibility and extensibility.