- 1 Summary
- 2 Rationale
- 3 Assumptions
- 4 Proposed Designs
- 5 Proposed Messages
- 6 Code Changes
- 7 Outstanding Issues
As discussed in Workflow Analysis, there are currently a number of modal dialogs which might interrupt the user. These information are given with regard to e.g. wrong paper sizes, transparency or even color gradients. There is a need for a solution which explains the user potential issues without disturbing the print work flow (too much).
Proposed Design "Multiple Print Messages"
This design proposal is based on the Idea Collection, "Contextual Information Bar". It combines the basic ideas of the already realized Writer Comments (see Notes2) and the brainstorming idea Direct Manipulation Snippets for Documents.
The basic idea is to present contextual and non-disruptive messages to the user when the print dialog is opened. An information bar inside the print dialog provides help for common issues - according to the severity of the information.
- There are two types of messages: "Information" for tips, "Warning" for potential issues which may cause undesired printing output.
- A message usually consists of (1) a symbol (representing the message type), (2) a message title (summary which is also used to refer to the message) (3) a message text (explaining the issue and - if possible - provide help to overcome the issue) and (4) an action link (referring to an option or further help).
- The message is contained in an information bar at the top of the print dialog. The dialog is expanded, accordingly. Rationale: This position is used in other programs too and ensures that the user will be aware of the message. And, a minimum of space is required and therefore the full width of the dialog is used.
- The element (5), the colored background, does also indicate the message type. The element (8), a small shadow, "hovers" the information bar over the rest of the print dialog.
- The print dialog shows only one message at a time. Rationale: Keep the additional size for the dialog at a minimum. We still have to consider small notebook screens.
- If multiple messages are present, then these messages can be switched with (6) the previous/next buttons. Rationale: The elements are rather small and
- Element (7) refers to the drop-down menu to provide access to further options (e.g. closing the message bar). Rationale: This kind of interaction element is (hopefully) already known due to the Writer comments and the toolbar options.
The following mockup shows the information bar in context:
The user opens the print dialog:
- If the user opens the print dialog, then the print settings and the document are checked for common print issues.
- If there are print issues, then the print dialog already shows the information bar (the first message) when the dialog is finally presented to the user.
The user requires further help: Clicking on the action link (4) usually either jumps to the selected setting in the print dialog or opens a new window.
Multiple messages are available, then ...
- ... they are sorted according to their severity. The most critical message is shown first.
- ... the user can browse them with the previous/next buttons (6).
- ... the drop-down menu (via (7)) provides direct access to them.
If the user changes any print(er) setting, then...
- ... it is checked for print issues and the message list is updated (similar to the initial request to open the dialog). This is always done, even if no message bar is shown at the moment.
- ... if there are no more messages, then the "message placeholder" will be shown instead. Rationale: Simply removing any message will lead to unwanted "jumping"/resizing of the dialog. Unless explicitely requested by the user, the size of the dialog should stay the same if he alters print options.
The user wants to close one/multiple messages:
- Usually the user does not require to explicitly close the messages. In very special cases, the place on the screen might be limited, so that the user may require to close the information bar.
- The drop-down menu (via (7)) provides options to either close the current message or all messages at once.
- If either all messages closed or the last message is closed manually, then the complete message bar will be removed.
If the user prints directly (e.g. via shortcut or toolbar icon), then ...
- (Draft Proposal): Default message boxes are used for warning messages. It would be desirable to replace the current "variety" of message boxes. It should be possible to directly connect e.g. Message Type (message dialog type), Message Title (dialog title) etc.
- (Draft Proposal): No information is given for information only messages.
- For LTR, the whole message bar is mirrored vertically.
- For Accessibility reasons, at least the drop-down menu (7) should be accessible. This is not yet implemented for the Writer Comments, since the default context menu inside the comments does already consider all these options.
- For Accessibility reasons, a high contrast version of the information bar should be available. Proposal: If this cannot be achieved, then the default message dialogs may be used.
The graphical design is still open. The current mockups are examples that ... as the name implies ... serve as examples :-) But of course there are some recommendations:
- Message symbols should consider the OpenOffice.org Icon Style, e.g. "Galaxy". See Galaxy Style.
- The colors of the Writer Comments should be used to represent the severity of the messages. See Colors for the Notes.
- If no message bar is shown and the user changes an option which requires to inform him via a message, then the message bar is added to the print dialog. The issue: This may cause unwanted "jumping/resizing" of the dialog. Is it possible to provide a smooth transition / animation? If yes, then this should also apply for removing the message bar from the print dialog.
- There should be a connection between the former printer warning settings and the currently proposed warnings.
Proposed Design "Single Print Message"
To be done. The single message handling is based on the proposed design "Multiple Print Messages" ... but far easier, since only one message is handled at once.
(At least one to serve as an example. More to come soon)
| Message Type
| Message Title
|| Paper Size|
| Message Text
|| The document specified paper size <documentsize_name> (<???size> mm x <???size> mm) is unavailable. The printer paper size <printersize_name> (<???size> mm x <???size> mm) will be used instead.|
| Action Link Text
|| Go to setting...|
| Action Link Action
|| Clicking on the action link opens the "printer preferences".|
|| This warning is based on a proposal by PL, see the discussion below.|
(At least one to serve as an example. More to come soon...)
| Message Type
| Message Title
|| Blank Pages|
| Message Text
|| Blank pages have been automatically added to enable page breaks for duplex printing.|
| Action Link Text
|| Go to setting...|
| Action Link Action
|| Clicking on the action link changes the tab page to "%PRODUCTNAME Writer".|
|| This information is based on a common misunderstanding by users why empty pages are present in the document. Most people do not own a duplex printer, but (currently) the setting cannot be determined automatically. So here it might be better to just inform the user.|
Inform About Automatic Scaling of Printed Output (This section is currently invalid ... please skip it.)
This information proposal is based on the Idea Collection, "Inform the user about the actual paper sheet size and maybe about document page or selection size".
The automatically chosen paper sheet size might be surprising. Sometimes the user cannot even guess the size, because an automatic scaling happens (Issue 107331 ) and the printer page size is somehow hidden in the separate printer preferences dialog. Therefore the user might be interested in either what will happen or what kind of paper will be used for printing.
Early design proposals are already shown on the Idea Collection page.
Discussion with PL (January 2010):
- The printer driver are not always reliable with regard to the paper sizes. In many situations, all supported paper sizes are reported but not the available ones. Therefore it is impossible to tell whether the desired paper size (set in the document) is available.
- In contrast, if the printer driver does not provide the correct paper size, then the next "most similar" paper size will be used (most similar = least difference in dimensions)
Feedback by PL (February 2010) (PPP Ideas):
- The above proposals look nice, however the text "will be scaled to" is factually incorrect; some of our applications (impress, calc) will layout to the printer specified paper anyway, so the problem does not occur there.
- Others (writer, draw) will request paper sizes according to what is specified in the document. The contents will then not be scaled in any way. Instead the contents will be printed centered.
- Perhaps we could find a compromise here, something of the form Crhistoph proposed, but saying "The document specified paper size B5 (<x> cm * <y> cm) is unavailable, instead the current printer paper size A4 (<x> cm * <y> cm) will be used". This would appear over the preview if a mismatch between requested paper size and printer paper size occurs (as far as the driver will let us determine).
Comment by Regina (February 2010) (PPP Ideas): I like using the Message Area too, but propose another string.
- Situation: I print a DINA5 brochure. OOo prints the correct two document pages together, but uses DINA5 paper size instead of DINA4. Because my printer is able to use DINA5, I get no warning, but a print of 2xDINA5 downscaled to DINA5 printed on DINA4. Unless I open the printer properties, I cannot know which paper size OOo assumes, because the preview looks the same for DINA5 and DINA4.
- I propose: Assumed size of sheet of paper (height x width) <newline> 210 mm x 297 mm = DIN A4
- The first line will be translated, the second line uses the units from the page format setting. The part = DIN A4 is added, if it is a named size known to OOo. So the second line needs no translation and positions are therefore independent of local string length.
- Regina 20:56, 25 February 2010 (UTC)
Answer by Christoph (February 2010): Regina, the situation you described is based on a similar issue, but should be handled differently. Personally, I want to keep the print dialog as clean as possible - your information requires to be available anytime. Maybe something like a extended tooltipp might serve better, here. --ChristophNoack 20:15, 28 February 2010 (UTC)
- If people print via shortcut, then the print dialog is omitted. What to do?
- If native dialogs are used, then we miss the flexibility to add this kind of warning.