gnome-devel-docs 3.14.1-1 / usr / share / help / el / hig / dialogs.page

<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" type="topic" id="dialogs" xml:lang="el">

  <info>
    <link type="guide" xref="patterns" group="dialogs"/>   
    <credit type="author">
      <name>Allan Day</name>
      <email>aday@gnome.org</email>
    </credit>
    <credit>
      <name>Calum Benson</name>
    </credit>
    <credit>
      <name>Adam Elman</name>
    </credit>
    <credit>
      <name>Seth Nickell</name>
    </credit>
    <credit>
      <name>Colin Robertson</name>
    </credit>
    <include xmlns="http://www.w3.org/2001/XInclude" href="legal.xml"/>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Ελληνική μεταφραστική ομάδα GNOME</mal:name>
      <mal:email>team@gnome.gr</mal:email>
      <mal:years>2014</mal:years>
    </mal:credit>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Θάνος Τρυφωνίδης</mal:name>
      <mal:email>tomtryf@gmail.com</mal:email>
      <mal:years>2014</mal:years>
    </mal:credit>
  </info>

<title>Διάλογοι</title>

<p>Dialogs are secondary windows that appear over a primary, parent window. They are used to present additional information or controls, including preferences and properties, or to present messages or questions.</p>

<p>Το GTK+ παρέχει διαλόγους όπου μπορούν να χρησιμοποιηθούν, όπως για εκτύπωση ή για επιλογή χρώματος.</p>

<p>Υπάρχουν τρεις βασικοί τύποι διαλόγων.</p>

<section id="when-to-use">
<title>Πότε χρησιμοποιούνται</title>

<p>Dialogs are a commonly recognized design pattern, and there are established conventions for the different types of dialogs that you might want to use. The guidelines on each type of dialog provides further information on this.</p>

<p>While dialogs can be an effective way to disclose additional controls or information, they can also be a source of interruption for the user. For this reason, always question whether a dialog is necessary, and work to avoid the situations in which they are required.</p>

<p>Υπάρχουν αρκετοί τρόποι για να αποφύγετε τη χρήση διαλόγων:</p>

<list>
<item><p>Use inline composition for new messages, records or contacts.</p></item>
<item><p>Οι ειδοποιήσεις στη διεπαφή μιας εφαρμογής είναι μια εναλλακτική λύση των διαλόγων μηνυμάτων.</p></item>
<item><p><link xref="popovers">Popovers</link> can be a way to display additional controls or options in a less disruptive manner.</p></item>
</list>

</section>

<section id="message-dialogs">
<title>Διάλογοι μηνυμάτων</title>

<media type="image" mime="image/svg" src="figures/patterns/message-dialog.svg"/>

<p>Message dialogs are the simplest type of dialog. They present a message or question, along with 1-3 buttons with which to respond. They are always modal, meaning that they prevent access to their parent window. Message dialogs are an appropriate choice when it is essential that the user sees and responds to a message.</p>

<section id="message-dialog-examples">
<title>Παραδείγματα</title>

<p>Οι διάλογοι επιβεβαίωσης χρησιμοποιούν ένα μήνυμα διαλόγου για να ελέγξουν - ή να επιβεβαιώσουν - την ενέργεια που θέλει να κάνει ο χρήστης. Έχουν δύο κουμπιά: ένα για επιβεβαίωση της ενέργειας και ένα για ακύρωση της.</p>

<note style="tip"><p>Confirmation dialogs will often be accidentally or automatically acknowledged, and will not always prevent mistakes from happening. It is often better to provide undo functionality instead.</p></note>

<p>Οι διάλογοι σφάλματος εμφανίζουν ένα μήνυμα λάθους στον χρήστη. Συνήθως έχουν ένα κουμπί που επιτρέπει στον χρήστη να αναγνωρίσουν και να κλείσουν τον διάλογο.</p>

<note style="tip"><p>Οι διάλογοι σφάλματος πρέπει να είναι η έσχατη λύση. Πρέπει να σχεδιάσετε την εφαρμογή σας έτσι ώστε να μην δημιουργούνται λάθη, και αυτόματα να ανακάμπτουν αν κάτι πάει στραβά.</p></note>

</section>
</section>

<section id="action-dialogs">
<title>Διάλογοι ενεργειών</title>

<media type="image" mime="image/svg" src="figures/patterns/action-dialog.svg"/>

<p>Action dialogs present options and information about a specific action before it is carried out. They have a heading (which typically describes the action) and two primary buttons - one which allows the action to be carried out and one which cancels it.</p>

<p>Sometimes, the user may be required to choose options before an action can be carried out. In these cases, the affirmative dialog button should be insensitive until the required options have been selected.</p>

<section id="action-dialog-examples">
<title>Παραδείγματα</title>

<p>Many of the stock GTK+ dialogs are action dialogs. The print dialog is a good example: it is displayed in response to the user using the print action, and presents information and options for that print action. The two header bar buttons allow the print action to either be cancelled or carried out.</p>

</section>
</section>

<section id="presentation-dialogs">
<title>Διάλογοι παρουσίασης</title>

<media type="image" mime="image/svg" src="figures/patterns/presentation-dialog.svg"/>

<p>Presentation dialogs present information or controls. Like action dialogs, they have a header bar and a subject. However, instead of prefixing an action, their content relates to an application or content item.</p>

<section id="presentation-dialog-examples">
<title>Παραδείγματα</title>

<p>Preferences and properties are both examples of presentation dialogs, and both present information and settings in relation to a specific entity (either an application or a content item). Properties dialogs are a good example of how dialogs can be used to disclose additional information which is not always needed in the main application window.</p>

<note style="tip"><p>Resist the temptation to provide a preference window for your application. Always question whether additional settings are really necessary. Most people will not bother to investigate the preferences that you provide, and configuration options will contribute to the complexity of your application. Make an effort to ensure that your application design works for everybody without the need to change its settings.</p></note>

</section>

<section id="instant-and-explicit-apply">
<title>Instant and Explicit Apply</title>

<p>Presentation dialogs are either instant or explicit apply. In instant apply dialogs, changes to settings or values are immediately updated. In contrast, explicit apply dialogs include a button for applying changes.</p>

<p>Instant apply should be used wherever possible. Instant apply presentation dialogs have a close button in their header bar, like a <link xref="primary-windows">primary window</link>.</p>

<p>Explicit apply is only necessary if changes in the dialog have to be applied simultaneously in order to have the desired behaviour. Explicit apply dialogs include a <gui>Done</gui> and <gui>Cancel</gui> button (<gui>Cancel</gui> resets all values in the dialog to the state before it was opened and Done applies all changes and closes the window).</p>

</section>
</section>

<section id="primary-buttons">
<title>Primary buttons</title>

<p>Message and action dialogs include primary buttons which affect the whole window. The order of these buttons, as well as the labels used, are a key part of the dialog.</p>

<section id="order">
<title>Σειρά</title>

<p>When a dialog includes an affirmative and a cancel button, always ensure that the cancel button appears first, before the affirmative button. In left-to-right locales, this is on the left.</p>

<p>This button order ensures that users become aware of, and are reminded of, the ability to cancel prior to encountering the affirmative button.</p>

</section>

<section id="labels">
<title>Labels</title>

<p>Label the affirmative primary button with a specific imperative verb, for example: <gui>Save</gui>, <gui>Print</gui>, <gui>Remove</gui>. This is clearer than a generic label like <gui>OK</gui> or <gui>Done</gui>.</p>

<p>Error dialogs typically include a single button which dismisses the dialog. In this case, a specific action does not need to be referenced, and this can be a good opportunity to use humor. <gui>Apology Accepted</gui> or <gui>Got It</gui> are both examples of good labels.</p>

</section>

<section id="default-action-and-escape">
<title>Default action and escape</title>

<p>Assign the return key to activate the primary affirmative button in a dialog (for example <gui>Print</gui> in a print dialog). This is called the default action, and is indicated by a different visual style. Do not make a button the default if its action is irreversible, destructive or otherwise inconvenient to the user. If there is no appropriate button to designate as the default button, do not set one.</p>

<p>You should also ensure that the escape key activates the cancel or close button, should either of them be present. Message dialogs with a single button can have both escape and return bound to the button.</p>

<p>Binding return and escape in this way provides a predictable and convenient way to continue through a dialog, or to go back.</p>

</section>

</section>

<section id="general-guidelines">
<title>Γενικές οδηγίες</title>

<list>
<item><p>Dialog windows should never pop up unexpectedly, and should only ever be displayed in immediate response to a deliberate user action.</p></item>
<item><p>Dialogs should always have a parent window.</p></item>
<item><p>Follow the <link xref="visual-layout">layout guidelines</link> when designing the content of windows.</p></item>
<item><p>Use <link xref="view-switchers">view switchers</link> or <link xref="tabs">tabs</link> to break up controls and information.</p></item>
<item><p>Avoid stacking dialog windows on top of one another. Only one dialog window should be displayed at a time.</p></item>
<item><p>When opening a dialog, provide initial keyboard focus to the component that you expect users to operate first. This focus is especially important for users who must use a keyboard to navigate your application.</p></item>
</list>

</section>

</page>