firedancer: "unerwünschte" Elemente eines Popups

Beitrag lesen

Ist das wirklich so? Unter http://molily.de/javascript-popups#alternativen habe ich mit der Frage auseinandergesetzt anhand einer Webanwendung, die das Popup zum Prinzip erhoben hat.

Man KANN alles machen. Aber damit verabschiedet man sich bewußt von bestimmter Usability. Und das ist in manchen Fällen eben nicht sinnvoll.

Und was deinen Link angeht: Es spricht nichts, aber auch gar nichts gegen eine Koexistenz von Tabbed-Browsing und Popups.

Der Punkt ist, dass sie nicht bei ein und derselben Webanwendung koexistieren sollten. Eine Webanwendung sollte eine Bedienweise vorgeben und ein ausgereiftes Interface haben. Entweder ich habe definierte Punkte, wo ich mich gerade befinde. Wenn ein Fenster/Dialog mit einer Untermaske offen ist, dann sollte ich auf das Fenster darüber nicht zugreifen können (modal windows). Wenn eine Webanwendung hingegen gleichzeitig über mehrere unabhängige Fenster - und so funktioniert das Tab-Konzept eben - bedienbar ist, so verabschiedet sich die Webanwendung von den Bedienkonzepten einer klassischen Dialog-basierten Anwendung. Gut, beides ist möglich, aber die Webanwendung sollte muss sich für eines entscheiden.

Jein. Es gibt dutzende von Anwendungen, die mehrere koexistierende Fenster benutzen/benötigen, um ihren Zweck zu erfüllen. Daran ist auch nichts verwerfliches. Aber soweit will ich gar nicht gehen. Ich benötige EIN Popupfenster (sprich: Dialog-Fenster), mehr nicht.

Dies ist nicht sinnvoll, daher ist es nicht möglich, in bestimmten Fällen auf Popups zu verzichten.

Das Problem ist doch: Wenn man nicht wie in einer Intranet-Umgebung eine homogene Browserlandschaft ohne Tab-Funktion hat, dann kann man gar nicht verhindern, dass klassische Popups, die man als Dialoge verwendet, als Tabs oder sonstwie geöffnet werden.

*seufz*

Erstens handelt es sich um eine Intranetumgebung, in der das laufen soll. Zweitens KANN der User das Popup nicht in einem Tab öffnen.

Es sei denn, man bettet die Browserfunktion wieder in ein eigenes Fenster ein und beschneidet alle möglichen Funktionen, was ja üblich ist. Aber wie deine Ursprungsfrage zeigt, hat man damit auch nicht alle Eventualitäten im Griff.

Man hat *fast* alle Eventualitäten im Griff. Wenn Mikroweich nicht wieder irgendwelche Sonderwege beschreiten würde.

Wichtig ist ein überschaubares und gut navigierbares Interface.

Nichts anderes versuche ich zu erreichen.

Entweder du setzt konsequent auf »modale« Fenster oder baust dir mit Ajax eine Oberfläche, bei der du dokumentinterne »Fenster« hast.

So ähnlich sieht es aus - Nur daß ich keine Lust habe, mir einen Abzubrechen um "Dokumentinterne Fenster" zu schaffen, wenn das einzige Hindernis ein microsoftspezifische URL-Einblendung ist, die man mit einm 20-zeichenlangen Text abstellen kann - wenn man weiß, wie dieser Text lautet. Und genau darauf bezog sich eben meine Frage.

Einfache Popups sind die schlechteste Lösung, eben weil sie mit Tabbed Browsing in die Quere kommen können,

Können sie nicht. Das kann man technisch in den Griff bekommen.

weil du keine zuverlässige Kontrolle über die Fenstereigenschaften hast et cetera, wie aufgeführt.

Ich brauche keine "zuverlässige" Kontrolle. Ich brauche keine pixelexakte Breite. Ich brauche nur einen Dialog, der sich öffnet. Mehr nicht. (Und der dann keine URL Anzeige enthält.)