Difference between revisions of "Talk:Printerpullpages/ContextualInformation"

From Apache OpenOffice Wiki
Jump to: navigation, search
(trying to fix the indentation of my comment)
(Added comment by Éric Comments on the Contextual Information Bar)
 
Line 6: Line 6:
 
*Proposal: One click should open the options - instead of using the small drop-down box on the right side.
 
*Proposal: One click should open the options - instead of using the small drop-down box on the right side.
  
Frank (phone call, 2010-03-01):
+
Frank (phone call, 2010-03-01):  
  
 
*Proposal: Add the information at the bottom of the dialog (between dialog content and OK/Cancel/Help buttons).
 
*Proposal: Add the information at the bottom of the dialog (between dialog content and OK/Cancel/Help buttons).
Line 12: Line 12:
 
Malte (private Mail, 2010-03-03):  
 
Malte (private Mail, 2010-03-03):  
  
*Issue: People may be suprised if the message bar appears "instantly", so that the dialog elements might be moved.
+
*Issue: People may be suprised if the message bar appears "instantly", so that the dialog elements might be moved.  
 
*Accessibility Issue: If people use screen magnifiers, then they might not be aware of a (changed) message bar (if the current viewport does not cover the message bar).  
 
*Accessibility Issue: If people use screen magnifiers, then they might not be aware of a (changed) message bar (if the current viewport does not cover the message bar).  
 
*Acessibility Issue: If people use screen readers, then the reader might not be aware of a (changed) message. It is required to set the focus inside the message bar. [Comment by Christoph, 2010-03-03: There might be solutions for that.]
 
*Acessibility Issue: If people use screen readers, then the reader might not be aware of a (changed) message. It is required to set the focus inside the message bar. [Comment by Christoph, 2010-03-03: There might be solutions for that.]
Line 22: Line 22:
 
*Maybe there could be a + button or an option in the drop-down menu to expand the window and show all the messages at once...
 
*Maybe there could be a + button or an option in the drop-down menu to expand the window and show all the messages at once...
  
Alister (2010-03-06):
+
Alister (2010-03-06):  
* I don't think this will be satisfactory behaviour:
+
 
"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."<br><br>
+
*I don't think this will be satisfactory behaviour:
The user may have looked at all the messages and decided to ignore them. They need to be informed when a new message is added. If the message list will just be updated the same as in the initial request, the new message will only be displayed if it is the most critical... so the user will not be informed.<br>
+
 
I can see that replacing the displayed message with the new one would also not be ideal... when the user hasn't looked at the messages yet the proposed behaviour would be desirable.<br>
+
:"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."  
Showing the number of messages would alleviate the problem, but I can't think of a good solution
+
:The user may have looked at all the messages and decided to ignore them. They need to be informed when a new message is added. If the message list will just be updated the same as in the initial request, the new message will only be displayed if it is the most critical... so the user will not be informed.<br> I can see that replacing the displayed message with the new one would also not be ideal... when the user hasn't looked at the messages yet the proposed behaviour would be desirable.<br> Showing the number of messages would alleviate the problem, but I can't think of a good solution
 +
 
 +
Èric (private Mail, 2010-04-06):
 +
 
 +
*Issue: For large dialogs or when used for the whole application window, the text line would be extremely wide and therefore very hard to read.
 +
*Proposal: The text should be wrapped, so that reading it is as easy as possible. A possible approach might be to use other visual elements like bubbles (in comparison to the contextual information ''bar'').
  
 
== Automatic Scaling of Printed Output<br>  ==
 
== Automatic Scaling of Printed Output<br>  ==

Latest revision as of 22:32, 7 April 2010

Comments on the Contextual Information Bar

Regina (private Mail, 2010-03-01):

  • Proposal: The context menu should be available on the whole message bar area.
  • Proposal: One click should open the options - instead of using the small drop-down box on the right side.

Frank (phone call, 2010-03-01):

  • Proposal: Add the information at the bottom of the dialog (between dialog content and OK/Cancel/Help buttons).

Malte (private Mail, 2010-03-03):

  • Issue: People may be suprised if the message bar appears "instantly", so that the dialog elements might be moved.
  • Accessibility Issue: If people use screen magnifiers, then they might not be aware of a (changed) message bar (if the current viewport does not cover the message bar).
  • Acessibility Issue: If people use screen readers, then the reader might not be aware of a (changed) message. It is required to set the focus inside the message bar. [Comment by Christoph, 2010-03-03: There might be solutions for that.]

Alister on ux-discuss (2010-03-02):

  • I'm not sure that the arrows make it obvious enough that there are multiple messages - perhaps it needs to actually say so. What do other people think?
  • Maybe it would be good to display the number of messages. Like this would be good, particularly for using the <> buttons rather than the drop-down menu: (1/1) or (2/3)
  • Maybe there could be a + button or an option in the drop-down menu to expand the window and show all the messages at once...

Alister (2010-03-06):

  • I don't think this will be satisfactory behaviour:
"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."
The user may have looked at all the messages and decided to ignore them. They need to be informed when a new message is added. If the message list will just be updated the same as in the initial request, the new message will only be displayed if it is the most critical... so the user will not be informed.
I can see that replacing the displayed message with the new one would also not be ideal... when the user hasn't looked at the messages yet the proposed behaviour would be desirable.
Showing the number of messages would alleviate the problem, but I can't think of a good solution

Èric (private Mail, 2010-04-06):

  • Issue: For large dialogs or when used for the whole application window, the text line would be extremely wide and therefore very hard to read.
  • Proposal: The text should be wrapped, so that reading it is as easy as possible. A possible approach might be to use other visual elements like bubbles (in comparison to the contextual information bar).

Automatic Scaling of Printed Output

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".

Rationale: 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.

Proposed Design: 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)

Personal tools