Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

It is yet another enterprise related app dilemma.

Most professional apps use report writers that are way too complicated for the general user, even though most of them are wysiwyg. Some simple apps only have fixed templates that are not customizable.

In an effort to solve this long standing problem, we picked the middle ground solution to the problem and that is template based printing.It's kinda like how blogging engines or forum engines work, templates may contain simple logic code and contain simple settings a user can easily tweak without having to know any code. A very good sample how it works is looking at this site: www.squarespace.com

However, unlike a website, most CRUD app reports have data constraints, certain selection criteria such as groups or categories. Eg. I want a report of all chairs from the database.

The question is, should the selection criteria(s) be included in the templates? Having the criteria(s) separate will allow better control over the data that is going to be printed. This paradigm is used through out the app but without criteria selection. Eg. Invoice printing but with templates

As programmers, we tend to think that the presentation(templates) and logic(in this case the data) should be separate. What will you do in this situation?

PS:Templates generates PDF files and therefore unable to show live with the templates.

share|improve this question

1 Answer 1

Assuming we are talking about a general reporting part of the app in which all data available from the app must be "reportable": I'd keep selection criteria separate from the templates.

Let the user first select everything (s)he wants to see and then offer a print action where (s)he can select a template to use. This way the templates can be filtered as well depending on the data selected (no use presenting invoice templates when the app is showing diary items in the selection grid).

An alternative would be to start with selecting a template (and thus limiting the data selection). Your users will have to give you guidance on that. It may be more natural for them to select a template first.

In both cases I would tend to show the data selected based on the criteria entered. For example in a grid or treeview of some sort. Preferably "live" so the user can immediately see the effect of the criteria they enter. Otherwise have them enter some criteria, display data, let them refine those criteria (add/remove/edit) by going back to the criteria dialogue until they are happy with what they have selected.

Update in reponse to comment

So make sure you have a sensible default template. Even better: select a best-fit template based on the data selected by the user.

Not saying you don't have them :-), but other features that can help users in these situations :

  • Store the last used selection, criteria and template
  • Allow users to save searches with a meaningful name and preferably allow them to organize them in some kind of folder structure. Preferably with full drag and drop support so they can move saved searches around
share|improve this answer
    
What you described is currently implemented, a split screen, top half is the criteria/filtering and the bottom part is the results and they are updated live. Once happy, select a template and print. We had users who always forgets to select the correct template and had to go back to try again, although only involves two clicks. –  vener Oct 31 '10 at 11:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.