Was ist eine Mobile Website?

Was genau ist eine mobile Website? Wozu dient sie? Es gibt viele Treffer im Internet, auch hier in Wer weiss was, aber immer wird vorausgesetzt, dass man sowas schon kennt. Oft werden sie im Zusammenhang mit mobilen Kommunikationsgeräten (wie ipods) genannt. Sind das Websites für solche Geräte? Verstehe das nicht ganz, denn Websites kann man ja auch über einen Computer aufrufen. Oder gibt es eben „mobile“ Websites, die nur mobilen Geräten vorbehalten sind?

Grüße

Elmar

Hallo Elmar,

ist ein blöder und m.E. nicht zutreffender Ausdruck (die Webseiten sind ja nicht mobil). Ich vermute einfach einmal, daß es sich um Websites handelt, die auch auf mobilen Geräten halbwegs vernünfitg und kostengünstig (Traffic) dargestellt werden können.

Dies ist nicht immer ganz einfach (freundlicher Ausdruck).

Momentan sitze ich hier vor einem 27"-Monitor und arbeite an einer Webseite (Fotogalerie), die auch ggf. auf einem heruntergekommenen Smartphone oder auf dem Display einer aufgetakelten Espressomaschine korrekt dargestellt werden soll.

Isses nicht schön.

Grundsätzliche Fragen zu diesem Thema können dir sicherlich die hier vorhandenen HTLM/CSS-Spezialisten (Effchen!?) beantorten.

Bin irgendwie auch nur Opfer.

Grüße

godsm

Hallo,

in der Tat ist es oft so, dass man neben der „klassischen“ für Bildschirmgrößen von 800*600 Punkte oder höher und breitbandige Zugänge sowie Mausbedienung im klassischen Browser ausgelegten Webseite noch eine Variante bereit stellt, die auf kleine Displays, schmalbandige Verbindungen und Stift-/Finger-Bedienung optimiert sind. Weiterhin verzichten man in diesen mobilen Seiten auch auf Techniken, die in Mobilgeräten oft nicht verfügbar sind. Zudem wird hierbei auch oft der Content anders priorisiert, und damit Dinge in den Vordergrund gestellt, die in der mobilen Nutzung von besonderer Bedeutung sind, während Dinge von denen man ausgeht, dass sie niemand unterwegs auf dem Smartphone erledigt, wegfallen, um die Benutzerführung auf wenige Schritte reduzieren zu können, und Komplikationen mit Dingen zu vermeiden, die ohnehin mobil wenig Sinn machen.

Durch Tabletts und zunehmende Geschwindigkeiten im Mobilbereich durch HSDPA und LTE und Geräte deren Browser auch mit Flash und Co. keine Schwierigkeiten mehr haben, lösen sich aber bestimmte Anforderungen/Beschränkungen, auf die man mit speziellen Mobilseiten reagiert, zumindest teilweise auf.

Es gibt technische Lösungen, die es gestatten recht weit automatisiert mobile Seiten über eigene Stylesheets und vom Verwender vorgenommene Markierungen auf Basis einer klassischen Webseite zu generieren und automatisch zu aktualisieren. Oft handelt es sich hierbei aber um wirklich nahezu eigenständige Seiten, die ggf. nur noch auf einige wenige gemeinsame Contents zurückgreifen.

Gruß vom Wiz

Moin,

ist ein blöder und m.E. nicht zutreffender Ausdruck (die
Webseiten sind ja nicht mobil).

Genau :smile:

Dies ist nicht immer ganz einfach (freundlicher Ausdruck).

Prinzipiell ist das erstmal ganz einfach, wenn man bei seinen Websites strikt Inhalt und Layout trennt. Denn dann legt man einfach ein zweites Stylesheet an und bindet das mit media=„handheld“ ein.

Mit z.B. display:none kann man einfach Elemente einer Seite ausblenden, die auf Handhelds nicht angezeigt werden soll (weil z.B. der Platz nicht reicht). Das Layout kann man mit dem Extra-Stylesheet ja auch komplett anders gestalten - Trennung von Inhalt und Layout sei Dank.
Natürlich muss nicht alles immer so einfach sein, aber mit einem anspruchsvolleren Layout wird natürlich auch die Arbeit schwieriger.
Immerhin gibt es auch bei Handhelds Unterschiede im verfügbaren Platz. Man kann nicht mehr einfach nur von einer Auflösung von ca. 200x320 ausgehen, wie das früher der Fall war. Durch Drehen des Bildschirm kann außerdem das Seitenverhältnis geändert werden. Aber da Browser ja in der Lage sind, Elemente möglichst passend anzuordnen, ist das alles also nicht unbedingt Hexerei. U.U macht man halt beim Handheld-Layout einige Abstriche.

Liebe Grüße,
-Efchen

Moin,

in der Tat ist es oft so, dass man neben der „klassischen“ für
Bildschirmgrößen von 800*600 Punkte oder höher

Die Bildschirmgröße bei Nicht-Handhelds ist eigentlich irrelevant. Insbesondere bei sehr großen Auflösungen sinkt die Wahrscheinlichkeit, dass das Browserfenster maximiert geöffnet ist. Außerdem ist die Größe des Viewports selbst bei „klasischen“ Bildschirmauflösungen von meinetwegen 800x600 oder 1024x768 in fast jedem Fall deutlich kleiner durch Fensterrahmen und Tool- oder Sidebars. Selbst wenn alle Nutzer eine Auflösung von 1024x768 hätten, wären die Viewports doch alle irgendwie unterschiedlich groß.

noch eine Variante bereit stellt,

In Form eines zweiten Stylesheets.

Weiterhin verzichten
man in diesen mobilen Seiten auch auf Techniken, die in
Mobilgeräten oft nicht verfügbar sind.

Welche meinst Du?

Durch Tabletts […] und Geräte deren Browser auch
mit Flash und Co. keine Schwierigkeiten mehr haben, lösen sich
aber bestimmte Anforderungen/Beschränkungen
zumindest teilweise auf.

Was aber gefährlich ist, wenn Tablets auch auf media=handheld reagieren. Die bräuchten dann schon wieder eine eigene Kategorie.

Oft handelt es sich hierbei aber um wirklich
nahezu eigenständige Seiten, die ggf. nur noch auf einige
wenige gemeinsame Contents zurückgreifen.

Was natürlich doppelte Arbeit macht und im Normalfall gar nicht notwendig ist.

Liebe Grüße,
-Efchen

Moin,

Was genau ist eine mobile Website?

Dazu hast Du eigentlich schon gute Antworten bekommen.

Es gibt viele Treffer im Internet, auch hier in Wer weiss was, aber
immer wird vorausgesetzt, dass man sowas schon kennt.

Nicht immer. Aus den ersten 5 Suchergebnissen habe ich zwei angeklickt, die die Frage zwar nicht in einem Satz beantworten, die aber doch durchblicken lassen, dass es hier um Websites für mobile Endgeräte geht, z.B. ein Wikipedia-Eintrag über „Mobile Web“.

Aber was man nicht durch Google beantwortet bekommt, erfährt man eben hier :smile:

werden sie im Zusammenhang mit mobilen Kommunikationsgeräten
(wie ipods) genannt.

Ich dachte immer, ein iPod wäre ein MP3-Player? Kann das Ding auch ins Internet?

Sind das Websites für solche Geräte?

Die Vermutung liegt nahe, oder?

Verstehe das nicht ganz, denn Websites kann man ja auch über
einen Computer aufrufen.

Hast Du schonmal eine Website auf einem „Computer“ und auch auf einem mobilen Endgerät angesehen? Vermutlich nicht. Denn dann sieht man schnell den Unterschied.
Auf Desktops oder Notebooks oder sogar Netbooks hat man eigentlich immer ziemlich viel Platz und kann bequem mit einer Maus scrollen.
Auf Handhelds passt irgendwie keine Website komplett ins Display. Man scrollt hin und her und muss dabei entweder einen Stift zur Hilfe nehmen oder quält sich mit seinen dicken Fingern.
Websites, die auf großen Bildschirmen entwickelt wurden, haben oft kleine Schaltflächen, die ein Erwachsener auf einem mobilen Endgerät nichtmal mit dem kleinen Finger treffen würde. Eigentlich wäre hier ein alternatives Layout und Design notwendig. Das gibts aber noch immer viel zu wenig. Auch dank immer größer werdenden Handheld-Bildschirmen, die Leute mit den älteren Geräten haben das Nachsehen.

Oder gibt es eben „mobile“ Websites,
die nur mobilen Geräten vorbehalten sind?

Wenn das Layout über ein Stylesheet für Handhelds eingebunden ist, dann bekommst Du dieses Layout auch nur auf diesen Geräten angezeigt.

Sind denn noch Fragen offen?
Willst Du selber solche Seiten erstellen und findest nicht den richtigen Anfang? Dazu braucht man natürlich erstmal entsprechend gute Kenntnisse in HTML/CSS und aktuellen Entwicklungsstandards wie der Trennung von Inhalt und Layout.

Liebe Grüße,
-Efchen

Ebenfalls Moin,

in der Tat ist es oft so, dass man neben der „klassischen“ für
Bildschirmgrößen von 800*600 Punkte oder höher

Die Bildschirmgröße bei Nicht-Handhelds ist eigentlich
irrelevant.

Rein technisch gesehen ja, von der optischen Wirkung her nicht. Daher wurde in allen großen Webprojekten in denen ich mal tätig war eine heiße Diskussion (und da waren namhafte große Webagenturen im Boot) darüber geführt, was an aktueller Auflösung mit welchen Prozentzahlen auf die Seite zugreift, und wie schnell sich diese Zahlen in welche andere Auflösung über die erwartete Lebensdauer der Seite ändern werden. Durch die zunehmende Verwendung von Schirmen deutlich jenseits 1024*768 und 16:9-Format entschärft sich das Thema allerdings, weil so breit ohnehin niemand ein Layout anlegt. Aber ja, auch heute noch wird der tatsächlich für Content genutzte Bereich normalerweise an einer der klassischen Standardbreiten (und zwar echte Bildschirmbreite - maximale Standardbreite von diversen Browserrahmen unter gängigen OS, um deinen Einwand hierzu zu beantworten) orientiert, und der Rest dann einseitig oder symetrisch mit Hintergrundbild aufgefüllt. Irgendwo habe ich aus dem letzten Projekt noch eine Tabelle mit den ganzen Daten dazu liegen. Da ist dann fein säuberlich aufgeführt, was netto bei welcher Kombination übrig bleibt, und wie häufig die aktuell vorliegt, und wie sie vermutlich in den nächsten drei Jahren positioniert sein wird.

In Form eines zweiten Stylesheets.

Wenn man das alles händisch machen würde, könnte man das sicherlich zu einem guten Teil hierüber machen. Die eingesetzten Tools großer Webseiten arbeiten da schon erheblich komplexer, oder sind leider noch gar nicht so weit, damit wirklich umgehen zu können. Das scheitert ggf. schon daran, dass man keine alternativen Bildelemente verwalten kann, geschweige denn automatisch solche erzeugen könnte. Dito bei abweichenden Texten, … Und das hat bei einigen Unternehmen zu einer mehr oder weniger unabhängigen zweiten Implementierung geführt, weil man für den zunächst noch recht kleinen Mobilanteil nicht die klassische Seite über Bord werfen konnte.

Weiterhin verzichten
man in diesen mobilen Seiten auch auf Techniken, die in
Mobilgeräten oft nicht verfügbar sind.

Welche meinst Du?

Z.B. das unten genannte Flash. Aber auch Java, Scriptsprachen, … Frames sind zwar des Teufels, werden aber trotzdem selbst heute noch gerne genutzt, können aber von einigen Mobilbrowsern nicht dargestellt werden, und wenn, dann sind gerade sie eines der KO-Kriterien für eine wirklich nutzbare Mobilseite. Und mit diversen CSS-Elementen kann auch der ein oder andere Mobilbrowser nicht so richtig was anfangen. Vergiss bitte auch nicht, dass es bei den ganzen Mobilseiten nicht nur um Seiten geht, die gerade heute erst entstehen, sondern um Seiten, die schon Jahre alt sind. Und ich habe hier noch einige Geräte aus der Zeit vor dem iphone liegen, die wirklich nur einen Bruchteil von Internetseiten auch nur annähernd akzeptabel darstellen konnten, weil es in deren Browser an allen Ecken hakte.

Durch Tabletts […] und Geräte deren Browser auch
mit Flash und Co. keine Schwierigkeiten mehr haben, lösen sich
aber bestimmte Anforderungen/Beschränkungen
zumindest teilweise auf.

Was aber gefährlich ist, wenn Tablets auch auf media=handheld
reagieren. Die bräuchten dann schon wieder eine eigene
Kategorie.

Na ja, das ein oder andere Problem löst sind, dafür kommen wieder neue, das ist nun mal so.

Oft handelt es sich hierbei aber um wirklich
nahezu eigenständige Seiten, die ggf. nur noch auf einige
wenige gemeinsame Contents zurückgreifen.

Was natürlich doppelte Arbeit macht und im Normalfall gar
nicht notwendig ist.

Selbstverständlich macht das an sich unnötige Arbeit. Aber s.o. wenn ein CMS im Einsatz ist, was keine ordentliche Mobilseite bauen kann, und der vom CMS erzeugte Code auch mit entsprechender Middleware nicht zu akzeptablen Konditionen in eine brauchbare Mobilseite verwandelt werden kann, dann schmeißt man nicht mal eben Investitionen im Mio-Bereich über Bord, oder wartet noch zwei Jahre, bis der CMS-Hersteller endlich nachgeliefert hat (in einem Fall mit dem ich befasst war, war der inzwischen ohnehin Pleite, und man froh, dass es einige Ex-Mitarbeiter gab, die das Ding überhaupt noch am Leben erhalten haben, von Innovation ganz zu schweigen).

Aber die Entwicklung im Bereich der funktionalen Anteile geht ja sogar einen eigentlich noch irreren Weg mit noch mehr Aufwand. Schau Dir doch mal die ganzen Apps an, die inzwischen für zwei bis drei Plattformen parallel gepflegt werden, obwohl die Funktionalitäten alle auch auf der Webseite des jeweiligen Anbieters liegen, und da ebenfalls gepflegt werden. Das macht vom Aufwand her noch viel weniger Sinn. Trotzdem gibt es z.B. bei n-tv eine klassische und eine mobile Webseite, und noch mal den Zugriff auf den selben Content über iphone-, Android- und Blackberry-App.

Gruß vom Wiz

Moin,

Die Bildschirmgröße bei Nicht-Handhelds ist eigentlich
irrelevant.

Daher wurde in allen großen Webprojekten in denen ich
mal tätig war eine heiße Diskussion
darüber geführt, was an aktueller
Auflösung mit welchen Prozentzahlen auf die Seite zugreift,

Wen interessiert denn das? Das sind doch Zahlen, die nicht relevant sind, das sollte eine „namhafte Designagentur“ aber wissen, wenn sie von Webdesign Ahnung hat und nicht nur von Printdesign.

Solche Erhebungen sollen doch zeigen, wieviel Platz für die Website zur Verfügung steht, oder nicht?

Aber was bringt es mir zu wissen, dass jemand (oder auch Tausende) eine Auflösung von 10.000x3.000 hat, wenn er (oder alle Tausende) ihre Browserfenster nur auf 1.000x2.000px großgezogen haben und von der Größe nochmal 300px in der Höhe durch Menü- und Toolbars und 150px in der Breite durch Sidebars verloren gehen?

Die Auflösung zu loggen ist vollig sinnlos.

heute noch wird der tatsächlich für Content genutzte Bereich
normalerweise an einer der klassischen Standardbreiten (und
zwar echte Bildschirmbreite - maximale Standardbreite von
diversen Browserrahmen unter gängigen OS, um deinen Einwand
hierzu zu beantworten) orientiert

Kann ich nicht verstehen. Das ist für mich Print-Design und nicht Web-Design. Das sind für mich zwei völlig verschiedene Paar Schuhe. Aber ich bin ja auch kein Designer.

Da ist dann fein säuberlich aufgeführt, was
netto bei welcher Kombination übrig bleibt, und wie häufig die
aktuell vorliegt, und wie sie vermutlich in den nächsten drei
Jahren positioniert sein wird.

Vermutlich auch eine Möglichkeit, dem Kunden Geld aus der Tasche zu ziehen.

eingesetzten Tools großer Webseiten arbeiten da schon
erheblich komplexer, oder sind leider noch gar nicht so weit,
damit wirklich umgehen zu können.

Kann ich verstehen, dass das dann nicht mehr händisch gemacht wird, aber schade, dass die Software nicht damit umgehen kann. Da sind wir dann wieder bei meinen heißgeliebten WYSIWYG-Editoren und Baukästen.

Und das hat bei einigen
Unternehmen zu einer mehr oder weniger unabhängigen zweiten
Implementierung geführt

Verstehe ich auch. Muss ja auch jeder selber wissen, wieviel Geld er investieren kann. Wichtig wäre nur, dass sich jeder Anbieter auch klar wird, dass manch eine Website auf mobilen Geräten einfach nur ätzend benutzbar ist.

Weiterhin verzichten
man in diesen mobilen Seiten auch auf Techniken, die in
Mobilgeräten oft nicht verfügbar sind.

Z.B. das unten genannte Flash. Aber auch Java, Scriptsprachen,
… Frames sind zwar des Teufels, werden aber trotzdem selbst
heute noch gerne genutzt, können aber von einigen
Mobilbrowsern nicht dargestellt werden

Okay, so genau habe ich mich damit noch nicht beschäftigt, daher fragte ich. Aber das sind - weil optional - auch Dinge, die ich nur sehr beschränkt einsetzen würde - auch bei einer nicht-mobilen Website.

Vergiss bitte auch nicht, dass es bei den ganzen Mobilseiten
nicht nur um Seiten geht, die gerade heute erst entstehen,
sondern um Seiten, die schon Jahre alt sind.

Schon klar.

Trotzdem gibt es z.B.
bei n-tv eine klassische und eine mobile Webseite, und noch
mal den Zugriff auf den selben Content über iphone-, Android-
und Blackberry-App.

Da kann ich nur den Kopf schütteln. Aber dafür bin ich einfach nicht groß genug (im Sinne von Kunden und Umsatz). Da macht das dann vermutlich sogar Sinn, doppelt und fünffach zu entwickeln.

Danke für Deine Antwort, ich mag solche aufschlussreichen und angenehmen Diskussionen.

Liebe Grüße,
-Efchen

Hallo,

was die Auflösungen angeht macht das schon Sinn, wenn Du nicht nur an die ja auch gerade erst in den letzten Jahren aufgekommenen breiten 16:9 Schirme denkst, bei denen man jede les- und überschaubare Breite im Browser passend bekommt. Bei klassischen Schirmen sieht das anders aus. Wenn Du da nicht dynamisch arbeiten willst, um einen einheitlichen optischen Eindruck der Seite zu gewährleisten, dann ist es von erheblicher Bedeutung, wenn Du deine Seiten zu breit anlegst, und z.B. die Anzeigentower in der rechten Spalte nicht mehr ohne Scrollen in den Blick des Betrachters kommen. Die bucht dann nämlich keiner mehr, und das kostet dann Geld. Und daher arbeiten mE völlig zurecht ganz viele bekannte Seiten so, dass sie eben eine Standardbreite nutzen, die unter 800*600 oder 1024*768 bei Vollbild im ersten Aufruf von links oben aus gerechnet alles Wichtige ohne Scrollen drin haben, was es braucht, um die Seite auf den ersten Blick „zu erfassen“. Schau Dir nur mal ebay, Heise, n-tv, ADAC, Chip, … an.

Aber selbst wenn Du vollkommen dynamisch arbeitest, und in weiten Zügen akzeptierst, dass dabei das Layout der Gesamtseite sich ändert, kommst Du an Grenzen an denen es Dir nicht nur das Layout vollkommen zerhaut, sondern auch die Nutzbarkeit und Bedienbarkeit deutlich leidet. Einen mehr als dreispaltigen Aufbau möchtest Du unter 800*600 nicht mehr wirklich ansehen und lesen. Und daher sollte man auch dann durchaus auf Standardgrößen Rücksicht nehmen. Sonst passieren so Dinge wie z.B., dass man beim ersten Aufruf der Seite nur noch eine Werbefläche und Bedienelemente, aber keinerlei echten Content mehr im Blick hat, und dies sich ggf. bei jedem Seitenwechsel wiederholt. Es gibt auf einigen Seiten Bildergalerien, die dies leider ignorieren, und wo man dann für jeden Bildwechsel selbst auf meinem großen Schirm noch scrollen muss. Noch nerviger, wenn so wichtigen Bedienelemente aus dem Blick verschwinden, oder insbesondere auch bei Formularen der strukturierte Zusammenhang verloren geht.

Ich denke da an einen konkreten Fall, wo ich damals verantwortlich für die erste echte Online-Police einer Versicherung war, man also vom Webbrowser direkt in den Host des Versicherungsunternehmens geschrieben hat und von dort dann policiert worden ist. Das war an sich schon eine Heldentat, wenn man überlegt, dass dieses gute alte Großrechnersystem noch auf 5*10 Stundenbetrieb ausgelegt war, und außerhalb dieser Zeit ursprünglich nur mit sich selbst beschäftigt und von außen gar nicht ansprechbar war. Aber alleine die von einem privaten, nicht geschulten Endanwender bedienbaren Webformulare haben wir wochenlang mit Userlab, Fachleuten aus allen beteiligten Disziplinen, … designed und dann noch drei mal geändert, bis wir den Spagat zwischen logischem Ablauf, möglichst wenig Seitenwechseln, nachträglichen Editiermöglichkeiten, und Anordnung der Formularelementen auf den einzelnen Formularseiten im Griff hatten (und das nicht nur für eine sondern für ein ganzes Bündel von teilweise grundverschiedenen, teilweise nur in Details abweichenden Versicherungen). Und natürlich sollte das alles auch noch „hübsch“ aussehen. Das kann nur auf Basis angenommener fixer Bildschirmgrößen funktionieren. Wenn Du da daneben greifst, hat das gleich massive wirtschaftliche Auswirkungen, weil die Leute dann ihre Versicherung anderswo abschließen. Wir hatten damals den direkten Vergleich zu den abgelösten, nicht entsprechend optimierten Seiten (die allerdings auch noch keine Online-Police erstellen konnten), und da haben wir innerhalb kürzester Zeit mal eben 10% zugelegt. Das wird nicht alles nur an der Online-Police gelegen haben.

Und ansonsten: Ja, ich bin absolut überzeugt davon, dass Du eine enorme Menge mehr Hintergrund zu HTML, CSS und Co. als ich hast (was nicht schwer ist :wink: Aber wie Du schon selbst schreibst, Du arbeitest da einfach in Projekten ganz anderer Dimensionen, als ich es im Webbereich viele Jahre gemacht habe. Und in solchen Projekten kommt man eben mit diesen händischen Geschichten leider nicht weit, wenn es um Angebote geht, die aus tausenden von Seiten bestehen, und an denen ständig zig Leute in Vollzeit arbeiten, und die Komplexitäten haben, wie oben im Bezug auf die Kommunikation mit Großrechnern nur mal kurz an einem Einzelbeispiel ganz leicht angerissen. In dem Fall hatten wir es insgesamt mit fünf Großrechnersystemen zu tun, dazu dann noch die Reduktion des selbst zum CMS ausgebauten ursprünglichen Shopsystems zurück auf seine eigentliche Aufgabe und Übernahme der Führungsfunktion durch ein echtes CMS mit vollständiger Integration dieses Shopsystems (das war allerdings der Relaunch davor), die Integration von Partnerseiten auf abweichenden Systemen mit der Übergabe von Benutzerdaten, ständige vollautomatische Aufbereitung jeder Menge zugelieferter Daten von Dritten über nicht standardisierte Schnittstellen, … Redaktions- und Freigabeworkflows, Stagingsysteme, … Das sind eigentlich Dauerbaustellen, wo Du vorne wieder anfängst, wenn Du hinten gerade fertig bist, weil sich die Welt inzwischen wieder weiter gedreht hat. Und da haben Basistechnologien einfach ganz andere Lebenserwartungen als in kleineren Projekten, wo man nicht von 50.000 Einzelseiten spricht, die man dann umstellen muss, und da sind die Investitionsvolumina und ist die time-to-market bei technologischen Refreshs, oder aufgrund von zusätzlichen Anforderungen ebenfalls ganz anders zu sehen. Da ist es dann wirtschaftlich in der Tat oft eine Lappalie für eine neue Technologie mal eben eine kleine, bescheidene Parallelplattform aufzubauen und betreiben zu lassen, statt dafür das große Rad zu drehen, um die ganze Geschichte technologisch perfekt und stringent zu machen.

Aber vielleicht ein kleiner persönlicher Trost: Der beschriebene Umbau eines Shopsystems zum CMS war damals auch von einer jungen, engagierten und sehr pfiffigen Entwicklerin maßgeblich betrieben worden, die Zeter und Mordio rief, als ihr klar wurde, dass sie künftig nicht mehr direkten Code-Zugriff haben würde, und auch die Zeiten von JS und eigenem HTML-Code vorbei sein würden. Einige Monate später war sie weg. Sie hatte zum Lieferanten des neuen CMS gewechselt :wink: Da hat sie auch nicht mehr auf Codebasis gearbeitet, sondern Leute beraten, die genau den selben Weg vor sich hatten von perfekten Webprogrammieren sich hin zu Anwendern von fertigen Systemen zu entwickeln.

Gruß vom Wiz

Moin,

was die Auflösungen angeht macht das schon Sinn, wenn Du nicht
nur an die ja auch gerade erst in den letzten Jahren
aufgekommenen breiten 16:9 Schirme denkst

Ich denke gerade an diese, wer zieht denn seinen Browser bei 3000px auf die volle Breite auf? Texte kann man auf so einer Breite nicht lesen, daher bin ich der Ansicht, dass die Chance auf einen nicht maximierten Browser bei großen Bildschirmen größer wird.

Wenn Du da nicht dynamisch arbeiten willst

Das ist eine Frage, die sich viel weniger Leute stellen sollten, sie sollten es einfach so machen. Im Print habe ich feste Größen, bei websites nicht. Warum also auf das Dynamische verzichten? (Ist vermutlich eher eine rhetorische Frage, weil da wo es um Geld geht, lieber ein paar Freaks außen vor gelassen werden, als zusätzliches Geld in dynamisches Layout zu pumpen - was ja zugegeben nicht ganz einfach ist).

Und daher
arbeiten mE völlig zurecht ganz viele bekannte Seiten so, dass
sie eben eine Standardbreite nutzen,

Ich kann das Argument durchaus auch bis zu einem bestimmten Grad nachvollziehen, aber wenn ich dann mal weniger Platz habe und mich auf solchen Sites zurechtfinden muss, dann geht mir das immer wieder gegen den Strich.
Dann kommen meist noch so Patzer dazu wie das vertikale Zentrieren mit der Lösung mit negativem margin. Da gibt es namhafte Seiten, wo das zu zentrierende Element kleiner ist als mein Viewport. So rutscht dann der Inhalt oben aus dem Fenster raus - pfffff. Darf doch gar nicht passieren bei einem Profi!

Schau Dir nur mal ebay, Heise, n-tv, ADAC, Chip, … an.

Nur weil das viele machen muss es doch nicht gut sein.

Aber selbst wenn Du vollkommen dynamisch arbeitest, und in
weiten Zügen akzeptierst, dass dabei das Layout der
Gesamtseite sich ändert

…was eigentlich DAS Feature des WWW schlechthin ist, was klassische Designer aber nicht wahr haben wollen…

kommst Du an Grenzen an denen es Dir
nicht nur das Layout vollkommen zerhaut, sondern auch die
Nutzbarkeit und Bedienbarkeit deutlich leidet.

Auch richtig. Aber die Grenzen werden meist nicht so schnell erreicht, wie Designer das gerne hinstellen. Die meisten Sites haben durchaus Spielraum, um mit dynamischen Layouts zu arbeiten. Dass eine Website bei eingestellten 34pt Schriftgröße oder bei 200x600px Viewport auf Desktops nicht gut aussieht, das kann sich jeder Nutzer denken. Aber im Moment stimmt bei vielen Websites das Layout schon jetzt nicht bei Netbooks oder auch nur etwas kleinren Monitoren oder bei Leuten, die mehr als das Browserfenster auf ihrem Bildschirm sehen wollen/müssen. Und da erwarte ich von Profis eigentlich mehr.

Sonst passieren
so Dinge wie z.B., dass man beim ersten Aufruf der Seite nur
noch eine Werbefläche und Bedienelemente, aber keinerlei
echten Content mehr im Blick hat, und dies sich ggf. bei jedem
Seitenwechsel wiederholt.

Genau das passiert mir regelmäßig auf meinem modernen Netbook.
Wenn es sich dann noch um eine Website mit Frames handelt, die einen oberen Frame in der Hälfte meines ohnehin schon kleinen Viewports hat, dann raufe ich mir die Haare bei so viel Unwissen…

Es gibt auf einigen Seiten
Bildergalerien, die dies leider ignorieren, und wo man dann
für jeden Bildwechsel selbst auf meinem großen Schirm noch
scrollen muss.

Dazu fällt mir nur allgemein noch ein, dass die meisten Designer, die Websites erstellen, echte Print-Designer sind, die es nicht einsehen wollen, warum im WWW andere Regeln gelten sollen. Wir bräuchten einen echten Ausbildungsberuf zum Web-Designer, der auf genau diese Unterschiede eingeht. Ich weiß jetzt nicht, ob es so einen Beruf nicht sogar gibt, aber wenn ich in das Informatik-Buch meines Sohnes gucke, wo HTML so erklärt wird, dass man damit Inhalte auf den Bildschirm bringt, und mit Dingen wie i, b und font gearbeitet wird, dann würde mich auch nicht wundern, wenn ein Beruf des Webdesigners auch nicht auf die wahren Features des WWW eingeht.

Ich denke da an einen konkreten Fall, wo ich damals
verantwortlich für die erste echte Online-Police einer
Versicherung war […]
Wenn Du da
daneben greifst, hat das gleich massive wirtschaftliche
Auswirkungen, weil die Leute dann ihre Versicherung anderswo
abschließen.

Was umgekehrt natürlich auch passieren würde, wenn jemand mit einem kleinen Bildschirm ständig scrollen muss, dann geht der auch woanders hin. So ist es am Ende keine Berücksichtigung von Web-Eigenschaften, sondern nur noch die Frage, bei welcher Lösung die Firma die wenigsten Kunden verliert.

Aber wie Du schon selbst
schreibst, Du arbeitest da einfach in Projekten ganz anderer
Dimensionen

Das ist richtig. Und deswegen habe ich die Möglichkeit, meinen Optimismus und meine Webanschauung zu behalten.
Aber ich verstehe Deine Seite schon.
Ich bin eigentlich Software-Developer und entwickle derzeit zwei Zahlungsverkehrssysteme für beleghafte Zahlungen (Scannen, Verarbeiten, Archivieren). Da kann ich auch nicht immer alles so machen, wie ich das gern hätte. Viele Dinge sind in der Entwicklung einfach zu teuer, vor allem wenn es der Kunde nicht bezahlen will, andere Dinge müssen einfach schnell gehen.
Ja, so ist es leider ;-/

Liebe Grüße,
-Efchen

Moin,

was Du da zu dynamischer Anpassung an die Breite schreibst, ist mE weniger ein Problem der Entwickler. Bei den Agenturen mit denen ich zu tun hatte, waren genug Leute dabei, die von Beginn an Online gearbeitet haben, und oftmals keine klassische Designausbildung Print hinter sich hatten. Es ist eher eine Frage der Auftraggeber als auch der Erwartungshaltung der Seitenbesucher, und auch hierzu kenne ich so einige Belege aus durchgeführten Userlabs. Und mir selbst geht es auch so, dass ich bei einem vollgestalteten, mehrspaltigen Layout „befremdet“ bin, wenn das dynamisch daher kommt.

Wenn da bei Standarddarstellung die Navigationselemente in einer Zeile liegen, und ich immer auf das vorletzte rechts zugreifen muss, um weiter zu kommen, dann mag ich es gar nicht, wenn das plötzlich in der zweiten Zeile links steht. Das hemmt einfach den Bedienfluss. Und wenn in einem Formular zusammenhängende Felder logisch mal nebeneinander, mal untereinander angeordnet werden, dann möchte ich auch nicht, dass das bei einer Änderung der Fenstergröße sich ändert.

Zu guten alten Webzeiten, als Seiten noch aus einspaltigem Fließtext, für sich stehenden Bildern und in Einzelzeilen stehenden Überschriften und Teasern bestand, war das noch etwas ganz anderes. Das Web hat sich aber nun mal weiter entwickelt, und damit muss man nun mal umgehen. Ich will gar nicht bewerten, ob es besser oder schlechter geworden ist, aber dass so klassische von oben nach unten einspaltig weggeschriebene Seiten eine inzwischen nahezu ausgestorbene Species sind, ist nun mal Fakt. Und die Möglichkeiten der Dynamisierung bei komplexen Layouts sind mE wirklich so beschränkt, dass es mehr Sinn macht, sich auf die überwiegend verfügbare Seitenbreite des Durchschnittsanwenders zu begrenzen. Da das viele Seiten machen, haben die Leute auf den alten Schirmen eben dann doch den passenden Vollbildmodus, und stellen die Leute mit moderen breiten Schirmen eben mindestens diese Breite ein, und dann passt das.

BTW: Bei mir läuft der Browser normalerweise trotzdem Vollbild, und ich schalte nur schmaler, wenn wider Erwarten doch mal jemand eine dynamische Seitenbreite verwendet (solche Seiten kommen mir aber immer seltener unter), und es dann nicht mehr lesbar ist, oder wenn ich Infos aus dem Browser für die Arbeit in einem anderen Fenster brauche.

Gruß vom Wiz

Moin,

Wenn da bei Standarddarstellung die Navigationselemente in
einer Zeile liegen, und ich immer auf das vorletzte rechts
zugreifen muss, um weiter zu kommen, dann mag ich es gar
nicht, wenn das plötzlich in der zweiten Zeile links steht.

„Plötzlich“ tut es das ja nicht. Das tut es ja nur, wenn Du in vollem Bewusstsein Deiner geistigen Kräfte etwas manipulierst.

Das hemmt einfach den Bedienfluss.

Das ist logisch.

Und wenn in einem Formular
zusammenhängende Felder logisch mal nebeneinander, mal
untereinander angeordnet werden, dann möchte ich auch nicht,
dass das bei einer Änderung der Fenstergröße sich ändert.

Wie man sowas möchten kann, ist mir unverständlich. Wer seine Fenstergröße ändert, der sollte davon ausgehen, dass sich die Anzeige ändern kann. Und man ändert ja auch nicht unbewusst und auch nicht ständig die Fenstergröße. Genaugenommen scheinen ja die mesten Nutzer nichtmal von der Möglichket zu wissen, ein Fenster auf etwas anderes einzustellen als auf „maximiert“.

Und die Möglichkeiten der
Dynamisierung bei komplexen Layouts sind mE wirklich so
beschränkt

Ob sie beschränkt sind, das weiß ich nicht. Es ist auf jeden Fall um einiges schwieriger, da ein passendes Layout zu erstellen.

dass es mehr Sinn macht, sich auf die überwiegend
verfügbare Seitenbreite des Durchschnittsanwenders zu
begrenzen.

Ich finde es nur blöd in einem derart flexiblen Medium, das entwickelt wurde um ALLEN Genüge zu tun, von einem Durchschnittsanwender zu sprechen, also die Menschen in Klassen einzuteilen „ist anständig und hat einen großen Bildschirm“ und „ist nicht anständig und benutzt Netbooks“ (lässt sich natürlich beliebig erweitern).

Da das viele Seiten machen, haben die Leute auf den
alten Schirmen eben dann doch den passenden Vollbildmodus, und
stellen die Leute mit moderen breiten Schirmen eben mindestens
diese Breite ein, und dann passt das.

Wobei Du in diesem Satz davon ausgehst, dass moderne Schirme breiter sind. Netbooks sind auch modern und haben aber kleinere Bildschirme als die „alten“ Schirme.

BTW: Bei mir läuft der Browser normalerweise trotzdem
Vollbild

Auch wenn das keiner wahr haben will :wink: ist das bei mir auch so.

Schönes Wochenende,
-Efchen