Seiteninhalt drucken, aber ohne Buttons ..?

[Olaf Rabbachin]

Hi *,

wie kann ich eigentlich die Druckansicht einer Seite (ASP.Net 2005)
realisieren? Ich erzeuge für eine gegebene Seite eine zusätzliche, die für
den Ausdruck optimiert ist. Allerdings brauche ich ja Logo, Navigation und
das ganze Drumherum, das wiederum *nicht* gedruckt werden soll. Da kommt
mir natürlich gleich wieder das Wörtchen "Frames", aber das würde dem
Gesamtkonzept der Anwendung vollkommen widersprechen.

Welche Alternative(n) gibt's ..?

TIA & Gruß,
Olaf

[Stefan Falz]

Hallo Olaf,

Post by Olaf Rabbachin
wie kann ich eigentlich die Druckansicht einer Seite (ASP.Net 2005)
realisieren? Ich erzeuge für eine gegebene Seite eine zusätzliche, die für
den Ausdruck optimiert ist. Allerdings brauche ich ja Logo, Navigation und
das ganze Drumherum, das wiederum *nicht* gedruckt werden soll. Da kommt
mir natürlich gleich wieder das Wörtchen "Frames", aber das würde dem
Gesamtkonzept der Anwendung vollkommen widersprechen.
Welche Alternative(n) gibt's ..?

Nimm für die Druckseite eine eigene MasterPage, die zum einen die nicht
benötigten Elemente wie Navigation, ... ausblendet. Für die Controls, die
im Contentbereich stehen und nicht gedruckt werden sollen, kannst du mit
einer entsprechenden CSS Datei arbeiten, die dann dafür sorgt, dass diese
Elemente nicht angezeigt werden.

[Olaf Rabbachin]

Hallo Stefan,

schätze, ich bin dir inzwischen das eine oder andere Bier schuldig, gell?
:-)

Post by Stefan Falz
Nimm für die Druckseite eine eigene MasterPage, die zum einen die nicht
benötigten Elemente wie Navigation, ... ausblendet. Für die Controls, die
im Contentbereich stehen und nicht gedruckt werden sollen, kannst du mit
einer entsprechenden CSS Datei arbeiten, die dann dafür sorgt, dass diese
Elemente nicht angezeigt werden.

Wie blendet man denn ein Control per CSS nur dann aus, wenn gedruckt
wird ..? Wie man per CSS grundsätzlich ein-/ausblenden kann, findet sich
z.B. in SelfHtml:
http://de.selfhtml.org/css/eigenschaften/positionierung.htm#visibility
Aber der Benutzer wählt ja im Browser ganz einfach File/Print und druckt
das Ding. Sprich, es gibt keinen (neuerlichen) postback. Oder solltest du
etwa meinen, ich erzeuge einen Button mit ein wenig client-seitigigem
JS-script, das per self.print arbeitet und zuvor die Sichtbarkeit entspr.
setzt ..?

Gruß & danke,
Olaf

[Stefan Falz]

Hallo Olaf,

Post by Olaf Rabbachin
schätze, ich bin dir inzwischen das eine oder andere Bier schuldig, gell?
:-)

Mal schauen :))

Post by Olaf Rabbachin
Wie blendet man denn ein Control per CSS nur dann aus, wenn gedruckt
wird ..?

Indem du (bspw. in der entsprechenden MasterPage) ein anderes Stylesheet
einbindest, welches die die Elemente ausblendet. Alternativ könntest du
auch wie hier angegeben vorgehen:

http://de.selfhtml.org/css/formate/einbinden.htm#link_media

Ich persönlich würde die Stylesheets laden, die ich brauche, insbesondere,
wenn Druck und Anzeige im Client möglichst gleich aussehen sollen (relativ
gesehen :))

Post by Olaf Rabbachin
Aber der Benutzer wählt ja im Browser ganz einfach File/Print und druckt
das Ding. Sprich, es gibt keinen (neuerlichen) postback. Oder solltest du
etwa meinen, ich erzeuge einen Button mit ein wenig client-seitigigem
JS-script, das per self.print arbeitet und zuvor die Sichtbarkeit entspr.
setzt ..?

Nein. Du hast doch bspw. folgendes:

meineseite.aspx

Dort hast du einen Link/Button/... "Druck mich :)"

Du könntest hier dieselbe Seite nochmals aufrufen, allerdings mit einer
anderen MasterPage. Diese blendet zum einen die nicht benötigten Controls
aus (serverseitig) und gibt als Stylesheetdatei bspw. "print.css" an.
In print.css werden die Elemente, die nicht per serverseitigem Code aus-
geblendet werden (können) über die Stylesheetzuordnung ausgeblendet.

Klar kannst du das auch über JavaScript machen, würde ich hier aber nicht
empfehlen. Macht zuviel Arbeit und ohne JavaScript gehts auch nicht.

[Olaf Rabbachin]

Hi,

Post by Stefan Falz

Post by Olaf Rabbachin
Wie blendet man denn ein Control per CSS nur dann aus, wenn gedruckt
wird ..?

Indem du (bspw. in der entsprechenden MasterPage) ein anderes Stylesheet
einbindest, welches die die Elemente ausblendet. Alternativ könntest du
http://de.selfhtml.org/css/formate/einbinden.htm#link_media
Ich persönlich würde die Stylesheets laden, die ich brauche, insbesondere,
wenn Druck und Anzeige im Client möglichst gleich aussehen sollen (relativ
gesehen :))

Einen Master verwende ich nicht. Ich habe u.a. Folgendes ausprobiert:
- im Header der ASPX:
...
<style type="text/css">
@media print { HideOnPrint { visibility:hidden; } }
@media screen { HideOnPrint { visibility:visible; } }
</style>
...
- am Ende der Page dann:
...
<input id="cmd1" type="button" value="button"
class="HideOnPrint"/>
<asp:Button runat="server" ID="cmd2"
Text="Test: asp" CssClass="HideOnPrint" />
</form>
</body>
</html>

Effekt: keiner.
Gebe ich dem HTML-button ein style="visibility:hidden" mit, wird er nicht
angezeigt. Unterschiedliche Formate je nach Ansicht kann ich direkt jedoch
nicht mitgeben.

Post by Stefan Falz

Post by Olaf Rabbachin
Aber der Benutzer wählt ja im Browser ganz einfach File/Print und druckt
das Ding. Sprich, es gibt keinen (neuerlichen) postback. Oder solltest du
etwa meinen, ich erzeuge einen Button mit ein wenig client-seitigigem
JS-script, das per self.print arbeitet und zuvor die Sichtbarkeit entspr.
setzt ..?

meineseite.aspx
Dort hast du einen Link/Button/... "Druck mich :)"

Ich habe eine Seite "meineseite.aspx" und eine "druckausgabe.aspx" - diese
Seiten zeigen nicht das Gleiche!
Nachdem der Benutzer in "meineseite.aspx" Eingaben getätigt hat und einen
submit-button geklickt hat, wird er zu "druckausgabe.aspx" umgeleitet.
Diese Seite wird latürnich im Browser angezeigt, soll aber auch ausdruckbar
sein, es ist aber in erster Linie eine simple Bestätigung und
Ergebnisübersicht. Weiterhin soll es einen Button/Link/etc. geben, über den
der Benutzer nach dem Drucken wieder zurück zur Eingabemaske kommt.

Post by Stefan Falz
Du könntest hier dieselbe Seite nochmals aufrufen, allerdings mit einer
anderen MasterPage. Diese blendet zum einen die nicht benötigten Controls
aus (serverseitig) und gibt als Stylesheetdatei bspw. "print.css" an.
In print.css werden die Elemente, die nicht per serverseitigem Code aus-
geblendet werden (können) über die Stylesheetzuordnung ausgeblendet.

Wenn ich das machen würde, könnte ich doch wiederum (z.B.) keinen
"zurück"-button in "druckausgabe.aspx" realisieren, ohne dass dieser beim
Drucken ebenfalls angezeigt würde.
Oder verstehe ich etwas falsch ..? Vielleicht mißverstehen wir uns? :-)

Gruß,
Olaf

[Harald M. Genauck]

Hallo Olaf,

Post by Olaf Rabbachin
Wenn ich das machen würde, könnte ich doch wiederum (z.B.) keinen
"zurück"-button in "druckausgabe.aspx" realisieren, ohne dass dieser beim
Drucken ebenfalls angezeigt würde.
Oder verstehe ich etwas falsch ..? Vielleicht mißverstehen wir uns? :-)

Warum eigentlich nicht eine einfach beliebig anders gestaltete Seite für
die Druckansicht?

Und wozu auf dieser einen Zurück-Button/-Link? Die Druckansicht per Link in
einem neuen Browserfenster öffnen wäre einfacher (target="_blank").


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de

[Olaf Rabbachin]

Hallo Harald,

Post by Harald M. Genauck

Post by Olaf Rabbachin
Wenn ich das machen würde, könnte ich doch wiederum (z.B.) keinen
"zurück"-button in "druckausgabe.aspx" realisieren, ohne dass dieser beim
Drucken ebenfalls angezeigt würde.
Oder verstehe ich etwas falsch ..? Vielleicht mißverstehen wir uns? :-)

Warum eigentlich nicht eine einfach beliebig anders gestaltete Seite für
die Druckansicht?

der Benutzer gibt in der Anwendung eine Bewertung eines Lieferanten ein.
Nachdem er seine Eingaben gemacht hat, klickt er den Submit-button.
Daraufhin wird eine Ergebnisseite angezeigt, die zus. Informationen
beinhaltet. Die Bewertungsseite soll danach höchstens neu/leer zur
Verfügung stehen, damit der Submit-button nicht mehrmals gedrückt wird.

Post by Harald M. Genauck
Und wozu auf dieser einen Zurück-Button/-Link? Die Druckansicht per Link in
einem neuen Browserfenster öffnen wäre einfacher (target="_blank").

Dann hätte ich die Eingabeseite noch immer geöffnet ...
Der "zurück"-button soll auch genaugenommen keiner sein, er würde die
vorherige Seite allenfalls neu laden.
Ist mein Konzept daneben? :-)
Ich könnte natürlich auch in einem neuen Fenster öffnen und gleichzeitig
das ursprüngliche neu laden ... Vielleicht wäre das tatsächlich einfacher?

Gruß,
Olaf

[Harald M. Genauck]

Hallo Olaf,

Post by Olaf Rabbachin

Post by Harald M. Genauck

Post by Olaf Rabbachin
Wenn ich das machen würde, könnte ich doch wiederum (z.B.) keinen
"zurück"-button in "druckausgabe.aspx" realisieren, ohne dass dieser beim
Drucken ebenfalls angezeigt würde.
Oder verstehe ich etwas falsch ..? Vielleicht mißverstehen wir uns? :-)

Warum eigentlich nicht eine einfach beliebig anders gestaltete Seite für
die Druckansicht?

der Benutzer gibt in der Anwendung eine Bewertung eines Lieferanten ein.
Nachdem er seine Eingaben gemacht hat, klickt er den Submit-button.
Daraufhin wird eine Ergebnisseite angezeigt, die zus. Informationen
beinhaltet. Die Bewertungsseite soll danach höchstens neu/leer zur
Verfügung stehen, damit der Submit-button nicht mehrmals gedrückt wird.

Post by Harald M. Genauck
Und wozu auf dieser einen Zurück-Button/-Link? Die Druckansicht per Link in
einem neuen Browserfenster öffnen wäre einfacher (target="_blank").

Dann hätte ich die Eingabeseite noch immer geöffnet ...
Der "zurück"-button soll auch genaugenommen keiner sein, er würde die
vorherige Seite allenfalls neu laden.
Ist mein Konzept daneben? :-)
Ich könnte natürlich auch in einem neuen Fenster öffnen und gleichzeitig
das ursprüngliche neu laden ... Vielleicht wäre das tatsächlich einfacher?

Welche Seite soll denn gedruckt werden? Die Eingabeseite oder die
Ergebnisseite? Ist aber eigentlich egal, denn:

Wenn die Ergebnisseite oder eine von dort per Link in einem neuen Fenster
geöffnete Ergebnisdruckansichtseite gedruckt werden soll, dann kann der
Anwender ja nicht nochmal submitten.

Wenn die Eingabeseite gedruckt werden soll, dann macht es ja nichts, wenn
er die Eingabedaten von einem Link auf der Eingabeseite aus in einer
separat geöfffneten speziellen Druckansichtseite gezeigt bekommt - den
Submit hat er ja dann noch nicht abgeschickt. Die Druckansichtseite kann er
dann bis Weihnachten im eigenen Browserfenster angezeigt stehen lassen -
ein Problem sollte das ja nicht sein...

Irgendwie verstehe ich das Problem wohl nicht...


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de

[Olaf Rabbachin]

Hi,

Post by Harald M. Genauck
Welche Seite soll denn gedruckt werden? Die Eingabeseite oder die
Wenn die Ergebnisseite oder eine von dort per Link in einem neuen Fenster
geöffnete Ergebnisdruckansichtseite gedruckt werden soll, dann kann der
Anwender ja nicht nochmal submitten.

nope, aber er bräuchte einen link, button, o.Ä., um zum vorherigen oder
nächsten Bereich zu kommen, wenn auf der Druckseite keine
Navigationscontrols vorhanden wären.

Post by Harald M. Genauck
Wenn die Eingabeseite gedruckt werden soll, dann macht es ja nichts, wenn
er die Eingabedaten von einem Link auf der Eingabeseite aus in einer
separat geöfffneten speziellen Druckansichtseite gezeigt bekommt - den
Submit hat er ja dann noch nicht abgeschickt. Die Druckansichtseite kann er
dann bis Weihnachten im eigenen Browserfenster angezeigt stehen lassen -
ein Problem sollte das ja nicht sein...

so läuft's auch derzeit, allerdings hat Daniel mir die Lösung des Problems
weiter unten ja präsentiert, damit weiss ich jetzt wenigstens, wie's geht.
:-)

Gruß,
Olaf

[Harald M. Genauck]

Hallo Olaf,

Post by Olaf Rabbachin

Post by Harald M. Genauck
Welche Seite soll denn gedruckt werden? Die Eingabeseite oder die
Wenn die Ergebnisseite oder eine von dort per Link in einem neuen Fenster
geöffnete Ergebnisdruckansichtseite gedruckt werden soll, dann kann der
Anwender ja nicht nochmal submitten.

nope, aber er bräuchte einen link, button, o.Ä., um zum vorherigen oder
nächsten Bereich zu kommen, wenn auf der Druckseite keine
Navigationscontrols vorhanden wären.

Verstehe ich nicht. Zu welcher Seite soll er denn von der separat
geöffneten Druckseite hinnavigieren (wollen)?


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de

[Olaf Rabbachin]

Hi,

Post by Harald M. Genauck

Post by Olaf Rabbachin

Post by Harald M. Genauck
Wenn die Ergebnisseite oder eine von dort per Link in einem neuen Fenster
geöffnete Ergebnisdruckansichtseite gedruckt werden soll, dann kann der
Anwender ja nicht nochmal submitten.

nope, aber er bräuchte einen link, button, o.Ä., um zum vorherigen oder
nächsten Bereich zu kommen, wenn auf der Druckseite keine
Navigationscontrols vorhanden wären.

Verstehe ich nicht. Zu welcher Seite soll er denn von der separat
geöffneten Druckseite hinnavigieren (wollen)?

wir reden aneinander vorbei, scheint's, bzw. ich habe nicht genau genug
gelesen. :-)
Mein statement bezog sich natürlich darauf, dass *kein* neues Fenster
geöffnet wird.

Gruß,
Olaf

[Harald M. Genauck]

Hallo Olaf,

Post by Olaf Rabbachin

Post by Harald M. Genauck

Post by Olaf Rabbachin

Post by Harald M. Genauck
Wenn die Ergebnisseite oder eine von dort per Link in einem neuen Fenster
geöffnete Ergebnisdruckansichtseite gedruckt werden soll, dann kann der
Anwender ja nicht nochmal submitten.

nope, aber er bräuchte einen link, button, o.Ä., um zum vorherigen oder
nächsten Bereich zu kommen, wenn auf der Druckseite keine
Navigationscontrols vorhanden wären.

Verstehe ich nicht. Zu welcher Seite soll er denn von der separat
geöffneten Druckseite hinnavigieren (wollen)?

wir reden aneinander vorbei, scheint's, bzw. ich habe nicht genau genug
gelesen. :-)
Mein statement bezog sich natürlich darauf, dass *kein* neues Fenster
geöffnet wird.

Na, Du fragtest ja mal nach dem besten Ansatz... Und der ist m.E. einfach
der, ein neues Fenster für die Druckansicht zu öffnen. Dann kommt nix
durcheinander beim Submitten und Navigieren, dann brauchst Du nix
client-seitig und ggfs. auch noch browserspezifisch zu basteln, und kannst
die Gestaltung samt Inhalt server-seitig voll und ganz kontrollieren. Und
den Anwender freut es auch, dass er die Druckseite unabhängig hat, drucken
kann wann er will und er trotzdem in der Browser-Anwendung weiterarbeiten
kann (es soll ja gelegentlich vorkommen, dass etwa der Drucker grad nicht
verfügbar ist...)


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de

[Daniel Kuppitz]

Hallo Harald,

Post by Harald M. Genauck
Na, Du fragtest ja mal nach dem besten Ansatz... Und der ist m.E. einfach
der, ein neues Fenster für die Druckansicht zu öffnen. Dann kommt nix
durcheinander beim Submitten und Navigieren, dann brauchst Du nix
client-seitig und ggfs. auch noch browserspezifisch zu basteln, und kannst
die Gestaltung samt Inhalt server-seitig voll und ganz kontrollieren. Und
den Anwender freut es auch, dass er die Druckseite unabhängig hat, drucken
kann wann er will und er trotzdem in der Browser-Anwendung weiterarbeiten
kann (es soll ja gelegentlich vorkommen, dass etwa der Drucker grad nicht
verfügbar ist...)

target=_blank hat lange ausgedient:
http://www.useit.com/alertbox/9605.html (Punkt 9)

Die einfachste Lösung ist nicht immer die beste Lösung. Gerade im Web
gibt es viele Dinge die einen allzu oft unterschätzen Anteil an Usern
einfach ausschließen. Und beim target=_blank muss nicht mal die
Barrierefreiheit das ausschlaggebende Argument sein. Wenn ich
persönlich eine Seite in einem neuen Fenster haben will, dann mach ich
das über's Kontextmenü. Seit es Tabbed Browsing gibt, kommt aber
selbst das nicht mehr vor, jetzt ist's nur noch das neue Tab.

--
MfG,
Daniel Kuppitz

[Harald M. Genauck]

Hallo Daniel,

Post by Daniel Kuppitz

Post by Harald M. Genauck
Na, Du fragtest ja mal nach dem besten Ansatz... Und der ist m.E. einfach
der, ein neues Fenster für die Druckansicht zu öffnen. Dann kommt nix
durcheinander beim Submitten und Navigieren, dann brauchst Du nix
client-seitig und ggfs. auch noch browserspezifisch zu basteln, und kannst
die Gestaltung samt Inhalt server-seitig voll und ganz kontrollieren. Und
den Anwender freut es auch, dass er die Druckseite unabhängig hat, drucken
kann wann er will und er trotzdem in der Browser-Anwendung
weiterarbeiten
kann (es soll ja gelegentlich vorkommen, dass etwa der Drucker grad nicht
verfügbar ist...)

http://www.useit.com/alertbox/9605.html (Punkt 9)

Nun ja... das sagt ein Jakob Nielsen - und ich sage halt etwas anderes...
;-)

Pauschale Argumentationen finde ich immer etwas schwach. Zwischen
irgendwelchen (Werbe-)Popups und sinnvollen Anwendungsfenstern sollte man
schon noch unterscheiden.

Post by Daniel Kuppitz
Die einfachste Lösung ist nicht immer die beste Lösung. Gerade im Web
gibt es viele Dinge die einen allzu oft unterschätzen Anteil an Usern
einfach ausschließen. Und beim target=_blank muss nicht mal die
Barrierefreiheit das ausschlaggebende Argument sein.

Die ich auch gar nicht mal als Argument sehe. Denn dann dürften auch
Desktop-Anwendungen keine Dialoge oder Druckvorschauen öffnen (die ja trotz
alledem auch beim Browser, zumindest beim IE noch ein eigenes Fenster ist).
Die Abstufung, ab wann was und wo ein eigenes Fesnter ist, ist eh
philosophisch. Mehrere Hauptfenster auf dem Desktop, mehrere
Dokumentfenster in einer MDI-Anwendung bzw. Tabfenster in einem Tabbed
Browser, oder mehrere Tabs auf einem MDI-Kindfenster bzw. auf einer
Webseite - dazwischen besteht kein wirklicher Unterschied. Ein Behinderter
Mensch muss so oder so den Überblick darüber behalten. Eine andere Frage
ist, wie man es vereinfachter und konsequenter gestalten könnte, den
Überblick zu behalten und den Zugriff auf verschiedene parallell geöffnete
Fenster barrierefrei(er) zu gestalten.

Post by Daniel Kuppitz
Wenn ich
persönlich eine Seite in einem neuen Fenster haben will, dann mach ich
das über's Kontextmenü. Seit es Tabbed Browsing gibt, kommt aber
selbst das nicht mehr vor, jetzt ist's nur noch das neue Tab.

Als Multiscreen-User habe ich aber lieber separate Fenster, die ich nach
Belieben über die Screens verteilen kann...
;-)

Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de

[Daniel Kuppitz]

Hallo Harald,

Post by Harald M. Genauck

Post by Daniel Kuppitz

Post by Harald M. Genauck
Na, Du fragtest ja mal nach dem besten Ansatz... Und der ist m.E. einfach
der, ein neues Fenster für die Druckansicht zu öffnen. Dann kommt nix
durcheinander beim Submitten und Navigieren, dann brauchst Du nix
client-seitig und ggfs. auch noch browserspezifisch zu basteln, und kannst
die Gestaltung samt Inhalt server-seitig voll und ganz kontrollieren. Und
den Anwender freut es auch, dass er die Druckseite unabhängig hat, drucken
kann wann er will und er trotzdem in der Browser-Anwendung
weiterarbeiten
kann (es soll ja gelegentlich vorkommen, dass etwa der Drucker grad nicht
verfügbar ist...)

http://www.useit.com/alertbox/9605.html (Punkt 9)

Nun ja... das sagt ein Jakob Nielsen - und ich sage halt etwas anderes...
;-)

Ach, da gibt es hunderte Seiten, die sich mit Usability und
Barrierefreiheit auseinandersetzen und einstimmig gegen _blank
argumentieren, das war nur ein kleines Beispiel, weil's schön kurz
gefasst ist.

Post by Harald M. Genauck

Post by Daniel Kuppitz
Die einfachste Lösung ist nicht immer die beste Lösung. Gerade im Web
gibt es viele Dinge die einen allzu oft unterschätzen Anteil an Usern
einfach ausschließen. Und beim target=_blank muss nicht mal die
Barrierefreiheit das ausschlaggebende Argument sein.

Die ich auch gar nicht mal als Argument sehe. Denn dann dürften auch
Desktop-Anwendungen keine Dialoge oder Druckvorschauen öffnen (die ja trotz
alledem auch beim Browser, zumindest beim IE noch ein eigenes Fenster ist).
Die Abstufung, ab wann was und wo ein eigenes Fesnter ist, ist eh
philosophisch. Mehrere Hauptfenster auf dem Desktop, mehrere
Dokumentfenster in einer MDI-Anwendung bzw. Tabfenster in einem Tabbed
Browser, oder mehrere Tabs auf einem MDI-Kindfenster bzw. auf einer
Webseite - dazwischen besteht kein wirklicher Unterschied. Ein Behinderter
Mensch muss so oder so den Überblick darüber behalten. Eine andere Frage
ist, wie man es vereinfachter und konsequenter gestalten könnte, den
Überblick zu behalten und den Zugriff auf verschiedene parallell geöffnete
Fenster barrierefrei(er) zu gestalten.

Ich habe das Glück, so ziemlich jede Barriere im Web überwinden zu
können. Auf Seiten wie alistapart.com gibt es allerdings auch Artikel
wo beschrieben wird wie sich nicht behinderte Menschen die
Funktionalität in irgendeiner Art und Weise einschränken um eine
Behinderung quasi zu simulieren und dann versuchen sich durch diverse
Seiten zu navigieren. Da wird dann spätestens klar, warum _blank so
schlecht ist. Es gibt einfach (noch) keine vernünftigen Tools, die man
Behinderten an die Hand geben kann um damit klar zu kommen. Die meisten
Screenreader verlieren, wenn ich das richtig in Erinnerung hab, den
Kontext. Sie bleiben auf dem Hauptfenster und ignorieren das neue.

Post by Harald M. Genauck

Post by Daniel Kuppitz
Wenn ich
persönlich eine Seite in einem neuen Fenster haben will, dann mach ich
das über's Kontextmenü. Seit es Tabbed Browsing gibt, kommt aber
selbst das nicht mehr vor, jetzt ist's nur noch das neue Tab.

Als Multiscreen-User habe ich aber lieber separate Fenster, die ich nach
Belieben über die Screens verteilen kann...
;-)

Und glücklicher Weise hast sicher auch Du noch 2 gesunde Hände, 10
gesunde Finger etc. und kannst die Seite auch über das Kontextmenü im
neuen Fenster öffnen ;-).

Ohne selber die Erfahrung gemacht zu haben, lässt sich wohl schwer
entscheiden, was in Sachen Usability gut und was schlecht ist. Aber ich
denke man da schon etwas drauf geben, was von alistapart.com oder auch
einfach-fuer-alle.de kommt.

--
MfG,
Daniel Kuppitz

[Harald M. Genauck]

Hallo Daniel,

Post by Daniel Kuppitz

Post by Harald M. Genauck

Post by Daniel Kuppitz
Die einfachste Lösung ist nicht immer die beste Lösung. Gerade im Web
gibt es viele Dinge die einen allzu oft unterschätzen Anteil an Usern
einfach ausschließen. Und beim target=_blank muss nicht mal die
Barrierefreiheit das ausschlaggebende Argument sein.

Die ich auch gar nicht mal als Argument sehe. Denn dann dürften auch
Desktop-Anwendungen keine Dialoge oder Druckvorschauen öffnen (die ja trotz
alledem auch beim Browser, zumindest beim IE noch ein eigenes Fenster ist).
Die Abstufung, ab wann was und wo ein eigenes Fesnter ist, ist eh
philosophisch. Mehrere Hauptfenster auf dem Desktop, mehrere
Dokumentfenster in einer MDI-Anwendung bzw. Tabfenster in einem Tabbed
Browser, oder mehrere Tabs auf einem MDI-Kindfenster bzw. auf einer
Webseite - dazwischen besteht kein wirklicher Unterschied. Ein Behinderter
Mensch muss so oder so den Überblick darüber behalten. Eine andere Frage
ist, wie man es vereinfachter und konsequenter gestalten könnte, den
Überblick zu behalten und den Zugriff auf verschiedene parallell geöffnete
Fenster barrierefrei(er) zu gestalten.

Ich habe das Glück, so ziemlich jede Barriere im Web überwinden zu
können. Auf Seiten wie alistapart.com gibt es allerdings auch Artikel
wo beschrieben wird wie sich nicht behinderte Menschen die
Funktionalität in irgendeiner Art und Weise einschränken um eine
Behinderung quasi zu simulieren und dann versuchen sich durch diverse
Seiten zu navigieren. Da wird dann spätestens klar, warum _blank so
schlecht ist. Es gibt einfach (noch) keine vernünftigen Tools, die man
Behinderten an die Hand geben kann um damit klar zu kommen. Die meisten
Screenreader verlieren, wenn ich das richtig in Erinnerung hab, den
Kontext. Sie bleiben auf dem Hauptfenster und ignorieren das neue.

Und wie verhalten die sich bei Tabbed-Browsern?

Man könnte natürlich auch den Link, der eine Druckansicht öffnet,
ausführlicher beschriften - etwa: "Druckansicht in neuem Fenster öffnen".
Das sollte auch einem Screenreader zu verarbeiten sein.

Abgesehen davon... zumindest im IE kann derjenige, den per "_blank"
geöffnete Fenster stören, auch in den erweiterten Optionen ausdrücklich
wählen, dass alle Seiten im gleichen Fenster geöffnet werden. Beim FireFox
(1.5.x) kann man das entsprechend für Tabs wählen. Außerdem könnte man als
Site-Anbieter sogar noch zusätzlich dem regelmäßigen/angemeldeten oder dem
Cookie- bzw. Session-akzeptierenden Besucher eine Option anbieten, wie die
Targets behandelt werden sollen. Gemessen am Gesamtaufwand für eine
ernsthaft barrierefrei gestaltete Site ist der Aufwand dafür minimal.

Es muss ja schließlich nicht sein, dass Barrierefreiheit einerseits zu
einer Art Barriere für andere wird...
;-)

Post by Daniel Kuppitz

Post by Harald M. Genauck

Post by Daniel Kuppitz
Wenn ich
persönlich eine Seite in einem neuen Fenster haben will, dann mach ich
das über's Kontextmenü. Seit es Tabbed Browsing gibt, kommt aber
selbst das nicht mehr vor, jetzt ist's nur noch das neue Tab.

Als Multiscreen-User habe ich aber lieber separate Fenster, die ich nach
Belieben über die Screens verteilen kann...
;-)

Und glücklicher Weise hast sicher auch Du noch 2 gesunde Hände, 10
gesunde Finger etc. und kannst die Seite auch über das Kontextmenü im
neuen Fenster öffnen ;-).
Ohne selber die Erfahrung gemacht zu haben, lässt sich wohl schwer
entscheiden, was in Sachen Usability gut und was schlecht ist. Aber ich
denke man da schon etwas drauf geben, was von alistapart.com oder auch
einfach-fuer-alle.de kommt.

Am meisten halte ich von freier Anpassbarkeit, am wenigsten von pauschalen
Zwangsmaßnahmen.


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de

[Daniel Kuppitz]

Hallo Harald,

Post by Harald M. Genauck

... Die meisten
Screenreader verlieren, wenn ich das richtig in Erinnerung hab, den
Kontext. Sie bleiben auf dem Hauptfenster und ignorieren das neue.

Und wie verhalten die sich bei Tabbed-Browsern?

Hab nicht die leiseste Ahnung, aber "In neuem Tab" öffnen ist (per
Default) sowieso nur über's Kontextmenü möglich. IE7 und Firefox
beispielsweise wechseln per Default nicht zum neuen Tab, Opera lässt
einem die Wahl.

Post by Harald M. Genauck
Man könnte natürlich auch den Link, der eine Druckansicht öffnet,
ausführlicher beschriften - etwa: "Druckansicht in neuem Fenster öffnen".
Das sollte auch einem Screenreader zu verarbeiten sein.

Ja, das ist eine Möglichkeit, die auch bei der Verleihung des Biene
Award zulässig ist, also schon zu den best practices gezählt werden
kann.

Post by Harald M. Genauck
Abgesehen davon... zumindest im IE kann derjenige, den per "_blank"
geöffnete Fenster stören, auch in den erweiterten Optionen ausdrücklich
wählen, dass alle Seiten im gleichen Fenster geöffnet werden. Beim FireFox
(1.5.x) kann man das entsprechend für Tabs wählen.

Auch das ist korrekt, seitens der Browser gibt es mittlerweile immer
mehr Unterstützung in Sachen Barrierefreiheit.

Post by Harald M. Genauck
Außerdem könnte man als
Site-Anbieter sogar noch zusätzlich dem regelmäßigen/angemeldeten oder dem
Cookie- bzw. Session-akzeptierenden Besucher eine Option anbieten, wie die
Targets behandelt werden sollen. Gemessen am Gesamtaufwand für eine
ernsthaft barrierefrei gestaltete Site ist der Aufwand dafür minimal.

Hmm, das fänd' ich ehrlich gesagt zu übertrieben. Wenn man das für
alles Mögliche macht, artet das aus in eine Masse von Einstellungen
die keiner mehr überblickt.

Post by Harald M. Genauck
Es muss ja schließlich nicht sein, dass Barrierefreiheit einerseits zu
einer Art Barriere für andere wird...
;-)

Ja, passiert sehr oft, vor allem wenn man sich das erste Mal dran
versucht (Erfahrungswerte :-)).

Post by Harald M. Genauck
Am meisten halte ich von freier Anpassbarkeit, am wenigsten von pauschalen
Zwangsmaßnahmen.

Wie gesagt, zu viel Anpassbarkeit wird schnell unübersichtlich. Also
übertreiben sollte man's damit auch nicht.

--
MfG,
Daniel Kuppitz

[Harald M. Genauck]

Hallo Daniel,

Post by Daniel Kuppitz

Post by Harald M. Genauck
Man könnte natürlich auch den Link, der eine Druckansicht öffnet,
ausführlicher beschriften - etwa: "Druckansicht in neuem Fenster öffnen".
Das sollte auch einem Screenreader zu verarbeiten sein.

Ja, das ist eine Möglichkeit, die auch bei der Verleihung des Biene
Award zulässig ist, also schon zu den best practices gezählt werden
kann.

Tatsächlich... eben einer meiner Gründe, etwas gegen pauschale Aussagen à
la Nielsen zu haben...

Post by Daniel Kuppitz

Post by Harald M. Genauck
Außerdem könnte man als
Site-Anbieter sogar noch zusätzlich dem regelmäßigen/angemeldeten oder dem
Cookie- bzw. Session-akzeptierenden Besucher eine Option anbieten, wie die
Targets behandelt werden sollen. Gemessen am Gesamtaufwand für eine
ernsthaft barrierefrei gestaltete Site ist der Aufwand dafür minimal.

Hmm, das fänd' ich ehrlich gesagt zu übertrieben. Wenn man das für
alles Mögliche macht, artet das aus in eine Masse von Einstellungen
die keiner mehr überblickt.

Vernünftige Standardeinstellungen, und wer davon abweichen will, soll sich
halt ein wenig Kopfzerbrechen bereiten - das halte ich durchaus für
zumutbar.


Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin - http://www.aboutvb.de
"visual studio one" - http://www.visualstudio1.de

[Daniel Kuppitz]

Hallo Olaf,

Post by Olaf Rabbachin

Post by Stefan Falz
Nimm für die Druckseite eine eigene MasterPage, die zum einen die nicht
benötigten Elemente wie Navigation, ... ausblendet. Für die Controls, die
im Contentbereich stehen und nicht gedruckt werden sollen, kannst du mit
einer entsprechenden CSS Datei arbeiten, die dann dafür sorgt, dass diese
Elemente nicht angezeigt werden.

Wie blendet man denn ein Control per CSS nur dann aus, wenn gedruckt
wird ..?

Schau Dir das einfach mal an (einmal im Browser, einmal in der
Druckvorschau oder auf Papier):

<html>
<head>
<style type="text/css" media="all">
p { color: red; }
.footer { display: none; }
</style>
<style type="text/css" media="print">
p { color: green; }
input { display: none; }
.footer { display: block; }
</style>
</head>
<body>
<h1>
Lorem ipsum</h1>
<p>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Proin
cursus, orci mollis
pretium interdum, nibh dolor ultrices mauris, sit amet.</p>
<input type="submit" value="Submit" />
<p class="footer">
&copy; 2006, Lorem ipsum</p>
</body>
</html>

--
MfG,
Daniel Kuppitz

[Olaf Rabbachin]

Hi,

Post by Daniel Kuppitz

Post by Olaf Rabbachin
Wie blendet man denn ein Control per CSS nur dann aus, wenn gedruckt
wird ..?

Schau Dir das einfach mal an (einmal im Browser, einmal in der
[html ...]

na bingo - das ist's doch! :-)

Merci!

Gruß,
Olaf

[Klaus Oberdalhoff]

Hi,

Post by Olaf Rabbachin
wie kann ich eigentlich die Druckansicht einer Seite (ASP.Net 2005)
realisieren? Ich erzeuge für eine gegebene Seite eine zusätzliche,
die für den Ausdruck optimiert ist. Allerdings brauche ich ja Logo,
Navigation und das ganze Drumherum, das wiederum *nicht* gedruckt
werden soll. Da kommt mir natürlich gleich wieder das Wörtchen
"Frames", aber das würde dem Gesamtkonzept der Anwendung vollkommen
widersprechen.

und was ist mit den Reporting Viewer Controls aus VS 2005 (nein ich meine
NICHT die Reporting Services des SQL Server 2005, obwohl auch diese dank der
SQL Server 2005 Express Advanced Edition kostenfrei nutzbar sind) die sind
doch genau dafür da ?

MSDN Webcast: Intelligent Reporting: Using the Visual Studio 2005 Report
Viewer Controls (Level 200)
Event ID: 1032284445

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032284445&EventCategory=5&culture=en-US&CountryCode=US

2 * MSDN TV von Brian Welcker zum Download
(Brian Welcker = Reporting bei MS)

http://www.microsoft.com/downloads/details.aspx?familyid=0894fc0c-1e00-4cd0-8e9f-cecec8aead74

http://www.microsoft.com/downloads/details.aspx?FamilyID=cadd3da5-aa6b-4c99-adba-c2865a92f999


Using Reporting Services with SQL Server 2005 Express Edition (Level 100)

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032295016&EventCategory=5&culture=en-US&CountryCode=US

[Olaf Rabbachin]

Hi,

Post by Klaus Oberdalhoff
und was ist mit den Reporting Viewer Controls aus VS 2005 (nein ich meine
NICHT die Reporting Services des SQL Server 2005, obwohl auch diese dank der
SQL Server 2005 Express Advanced Edition kostenfrei nutzbar sind) die sind
doch genau dafür da ?

danke für die Tips, aber das ist für diesen Zweck absolut oversized. Es
geht lediglich darum, dass eine Seite (resp. die Druckansicht einer Seite)
ausgedruckt werden kann und der Benutzer ein paar Buttons für die weitere
Navigation sieht, die wiederum nicht gedruckt werden.

Gruß,
Olaf

[Gerold Mittelstädt]

Hallo Olaf,

Post by Olaf Rabbachin
Hi *,
wie kann ich eigentlich die Druckansicht einer Seite (ASP.Net 2005)
realisieren? Ich erzeuge für eine gegebene Seite eine zusätzliche,
die für den Ausdruck optimiert ist. Allerdings brauche ich ja Logo,
Navigation und das ganze Drumherum, das wiederum *nicht* gedruckt
werden soll. Da kommt mir natürlich gleich wieder das Wörtchen
"Frames", aber das würde dem Gesamtkonzept der Anwendung vollkommen
widersprechen.
Welche Alternative(n) gibt's ..?

<link rel="stylesheet" type="text/css" href="screen.css" media="screen" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

screen.css wird zur Anzeige, print.css fürs Drucken angewendet.

In print.css kannst Du alles, was Du nicht drucken willst dann ausblenden:
#navigation, #suche, .werbung { display: none; }
So könntest Du auch das komplette Layout ändern.
Schönes Beispiel hierfür ist Wikipedia.

Viele Grüße!

Gerold

[Gerold Mittelstädt]

Post by Gerold Mittelstädt
Schönes Beispiel hierfür ist Wikipedia.

Lässt sich dort z.B. mit ?printable=yes auch am Bildschrim anzeigen.

[Olaf Rabbachin]

Hi,

Post by Gerold Mittelstädt

Post by Gerold Mittelstädt
Schönes Beispiel hierfür ist Wikipedia.

Lässt sich dort z.B. mit ?printable=yes auch am Bildschrim anzeigen.

danke dir - gut zu wissen!

Gruß,
Olaf