3

Consider a scenario, where a dashboard sort of UI screen having multiple graphs is present. The design, as it should be, has functionality such that, when one hovers on multiple data points in a particular graph, the precise data associated is given as a pop-up/tool-tip.

Now the client says that he will want to print the UI screen regularly, and would need all the data points explicitly detailed in the graph. So say, a point in the graph will show what data is associated with it in the printed medium.

To cater this scenario, and have a balance b/w web vs print - there could be some options to think on -

1) Create a different print.css? (Issue here is that we do not know how the graph with all the data might look, and also that it will generally apply to all the elements in the page.)

2) Give control the user, by having some sort of print switch element wise, or section wise?

3) Or create a print dialogue interface, and allow preview and some settings there?

Thoughts?

  • In addition to what others have suggested, you might consider some design alternatives (if you haven't already) that don't require the user to click/hover in order to see the data. Not only would that make it easier to solve this problem, but it might make the screen more usable in general, if reading the specific data is common. – Nate Green May 11 '16 at 12:19
1

If printing is an important part of your users workflow then having a print specific stylesheet is essential, so you should do this regardless of any other options.

Regarding the other options - it depends.

Do your users need this customisation? Are you adding any worth by giving users the option to print certain sections and not others or modifying the display of certain elements or whatever other options you want to give? If any of these options aren't essential or don't add any value, don't give the user the option. It interrupts the workflow and that is bad UX. Usually when people want to print, thats all they want - they want to press a button and whatever they are currently looking at on the screen to come out of the printer on a piece of paper.

If printing specific sections of data is important - move the print action to those sections - so each section has its own print action, rather than a global print where you then choose the section. This keeps the action tied to the context in which it is happening.

If custom print options are something you need, there are 2 main option.

  1. Have a custom print dialog that shows on every print action.

  2. Have global print options which are accessible only through an option or settings view.

The first option suffers from my earlier point of interrupting the users workflow if it isn't needed - every time the user prints. The second option makes the settings inaccessible and will interrupt the users workflow only when the user needs to change the settings.

The best option completely depends on your users needs and expectations.

0

I think the most common way is scenario 3. Because you can compare this interaction with printing a website with your browser's ui. When you print a website you also get a print dialogue with some settings, a link to advanced settings and on the right a preview of what's being printed.

  • If I understand correctly the print dialog you are talking about is part of the browser or OS but @Amit is talking about a dialog specifically built as part of his app/site. – Cai Mar 9 '16 at 8:32
  • Yes Marijke, as @CAI put it correctly, I was talking about a custom dialogue. – Amit Jain Mar 9 '16 at 10:59
  • I try to say that option 3 would be the most similar to a browser print dialog, therefore people are used to this kind of dialog to print something. For this reason I would chose option 3. – Marijke Dekker Mar 15 '16 at 19:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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