Feature Requests

Searched through CHILI publisher? Went through the documentation? Didn't find what you were looking for, even after submitting a request for information? Congratulations, you may have a valid feature request!

And we absolutely welcome those. We are smart people, with a very clear idea on where our product is going. But we are also smart enough to know that we don't have ALL the answers. We very regularly get new ideas based on customer feedback. And even if it was already on our own wish list, the feature request will help us decide how to prioritize our development efforts.

What usually gets accepted?

We prioritize acceptance and development of feature requests based on a variety of criteria:

• Quick wins (low development effort but high gain in usability) tend to get in very quickly
• Requests with lower chance on additional future support (or require less debugging and/or testing in actual production environments or with large amounts of "real life" data entry) will have a higher priority
• Requests relevant to all (or a large group) of existing customers
• Requests which will even further solidify CHILI's unique market position
• Requests which have a large impact on sales. Not just our own, but a lot of focus is also placed on that of our customers
• We try to calculate the future effort in maintenance. A connection to an external system (DAM, proofing, ...) for example tends to mean that we'll also need to keep up to date with its future versions. A larger amount of requests will need to come in before we decide on that;.
• Feature requests from new customers can sometimes get a slightly higher priority. Not because they are more valued, or because we want to make them happy as soon as possible (the opposite applies, actually. We do our best not to give the impression that we'll always be able to respond to features requests too quickly, as that might lead to expectations we might not be able to fulfil in the future). But rather: every new customer uses CHILI Publisher with a (even if slightly) new perspective. In addition: older customers / early adopters might have learned to easily work around small annoyances which we stil do want to get rid of.

What doesn't?

Most importantly: anything which is out of scope for the product. We are highly focussed on the development of an Online Document Editor which is to be integrated into our customer's portals. This has many consequences.

For example: tools surrounding the document editor may be provided, but in a limited fashion. Our DAM solution is a good example of that. We offer basic file storage, preview generation, reformatting possibilities and searching on name. But that's where we draw the line. Even relatively small additional feature requests (advanced metadata capabilities, simple usergroup-based file access within the BackOffice, a "status" field for an image are unlikely to be accepted, as they could lead to the (false) impression that we are aiming to provide a full-featured Digital Asset Management. Rather, our focus there is on: giving our customers easy API and/or configuration possibilities to limit access to files from within the Editor (where it matters most!). And equally we will build in both out-of-the-box and API driven possibilities to connect to asset management solutions which are more specialized.

That same approach tends to apply to most areas where specialized solutions are in wide use by our customers. Color proofing, PDF production-output optimization, advanced visualization of 3D packaging, and much more.

It is equally very unlikely that a highly sector-specific feature request will be accepted, especially if it complicates existing interfaces or functionalities. There again: we will focus on providing API possibilities which are as easy as possible to integrate.

What do I do until it is built in?

We are very often able to provide you with temporary workarounds. They might not be enormously handy, or ergonomical, and might even require some development resources on your end. But hopefully it will be enough to keep you going for a while.

Can I pay to get my feature request built in?

Not really. Next to a strong focus on our product scope, we also keep a tight grip on our business model. And next to that: the organization resources required for development and support of a product are sometimes significantly different from those required for external projects.

At most, it might be (in some cases) possible to allocate budget which allows us to (temporarily or permanently) bring in additional resources which will be prioritized for your requests. This has only happened once at the time of writing, though.