Responsive Website in Arbeit - bitte diskutieren

faglork · 08. August 2014 14:06

Moin!

Ich arbeite grad an eine neuen Seite, und da habe ich einiges eingebaut was mir so als Lösung für responsive/mobile-friendly eingefallen oder über den Weg gelaufen ist.

Ich würde das gerne mal ein bisschen mit euch diskutieren - vielleicht fällt ja ein "CMSMS - best practises for mobile websites"-Beitrag dabei ab.

http://tinyurl.com/pw9c6h5
(möchte nicht dass der Thread in Suchmaschinen auftaucht, daher tinyurl und keine Verlinkung)

Ein paar Erläuterungen:

- Das Menü ist ein reines CSS-Menü, kein Javascript

- Das große Hintergrundbild wird nur bei Tablets und PCs geladen

- Telefonnummern werden nur bei Smartphones und Tablets mit einem korrekt formatierten tel: link versehen

- Derzeit funzt es bis runter auf ca. 300px Breite, in allen Devices die ich testen konnte. Sogar auf Nokia N95 mini mit Symbian OS und Opera mini.

Schauts euch mal bitte an. Es gibt viiieeele Lösungen für eine mobil-freundliche Website, aber was ist sinnvoll, was unsinnig?

Auf Anhieb kann ich sagen, dass diese Lösung nur für kleine Websites geeignet ist (ne "große" Version ist aber schon in Arbeit).

Ansonsten bitte ich um konstruktive Kritik.

BTW: Die auf der Website eingesetzten Lösungen sind natürlich für jeden frei verwendbar. Falls jemand das Telefon-Plugin haben will, werde ich es gerne veröffentlichen. Es ist vor allem deshalb interessant, weil es den MobileDetect vom TOOLBOX-Modul für ein PLUGIN bereitstellt. Damit kann man sicher interessante Sachen bauen.

Ach ja. Google Pagespeed. Schlägt sich IMO ganz gut, aber Pagespeed ist schon sehr eigen. Es moniert viele Sachen, die an blanken Unsinn grenzen (0,27 Sek. Antwortzeit des Servers - "UNBDINGT BEHEBEN". Jaja, schon klar.). Daher bitte keine Diskussionen über Pagespeed. Können wir gerne in einem anderen Tread machen. Mir ist klar dass man da noch etwas mehr rausholen kann (smarty-gesteuertes css in den media-queries zb.) , aber irgendwo ist auch das Budget am Ende. Ich habe mich bemüht mit einfachen Mitteln soweit zu kommen wie halt möglich. Ich habe bestimmt einiges übersehen, und es gibt sicher andere/bessere Lösungen.

Interessant wäre halt, wo da jetzt die großen Probleme liegen und ob es dafür Lösungen gibt.

Es gibt zb. keine Lösung für @font-face bei Opera mini. Opera mini hat aber ca. 240 Mio. User - 70 Millionen mehr als iPad ... ich hab derzeit auf ein Image-Fallback für Opera mini verzichtet, weil, wenn ich anfange einzelne Devices zu bedienen dann mach ich ein Fass ohne Boden auf. Da kann man aber auch anderer Meinung sein ...

Wie auch immer. Schauts euch halt mal an.

Servus,
Alex

Beitrag geändert von faglork (08. August 2014 14:12)

nockenfell · 08. August 2014 20:42

SocialSharePrivacy sieht auf dem Handy nicht optimal aus. Hier solltest du die Abstände zwischen den Buttons noch optimieren (auch nach unten zum Footer).

Ansonsten, gut umgesetzt aus meiner Sicht. Ich hätte es gleich gemacht.

Klenkes · 09. August 2014 08:13

Mit meinem Tablet habe ich auf der Seite ein paar Probleme.

1. Ich kann nicht auf die Unterseiten navigieren, das das Menü kurz aufklappt, dann aber schon der Toplevelmenüpunkt geladen wird.
Ich würde bei Einsatz von Aufklappmenüs trotzdem immer ein zweites Untermenü einbauen.

2. Das fixierte Hintergrundbild bremst mein Tablet dermaßen aus, dass ein nach unten Wischen kaum möglich ist. Opera Mobile zerhackt mir dann das Hintergrundbild.

3. Dazu finde ich auf meinem 10 Zoll Tablet die Navigationspunkte viel zu klein zum Tappen.

Erfahrungsgemäß funktionieren fixierte Hintergründe auf iPads flüssiger als auf Android Geräten.
Meins ist ein Acer 10" Android 3.2 mit Androidbrowser und Opera Mobile.

Telefonnummern werden nur bei Smartphones und Tablets mit einem korrekt formatierten tel: link versehen

Warum braucht man bei Tablets einen Telefonlink?

jeff1980 · 09. August 2014 09:03

Hi,
auf dem iPad Mini mit Retina-Display läuft die Seite in der Tat sehr flüssig. Hier funktionieren auch die Dropdowns wie erwartet. Insgesamt lässt sich die Seite gut bedienen. Einzig beim nach-oben-Link würde ich erwarten, dass ich wieder nach ganz oben zum Menü komme - leider springt die Seite aber nur zur Überschrift und ich muss noch ein Stück scrollen.

Einen Telefonlink auf dem Tablet finde aus zwei Gründen interessant:
Man kann die Nummer direkt als Kontakt speichern und ab Herbst sogar vom iPad aus anrufen wenn man auch ein iPhone besitzt. Ersteres habe ich schon öfter genutzt, ich finds gut. Ob das Telefonieren vom iPad praktikabel ist, wird sich zeigen.

faglork · 12. August 2014 12:05

nockenfell schrieb:

SocialSharePrivacy sieht auf dem Handy nicht optimal aus. Hier solltest du die Abstände zwischen den Buttons noch optimieren (auch nach unten zum Footer).

Da hast du recht ...

jeff1980 schrieb:

Hi,
Einzig beim nach-oben-Link würde ich erwarten, dass ich wieder nach ganz oben zum Menü komme - leider springt die Seite aber nur zur Überschrift und ich muss noch ein Stück scrollen.

Das leuchtet ein. Wird geändert.

Klenkes schrieb:

Warum braucht man bei Tablets einen Telefonlink?

jeff1980 schrieb:

Einen Telefonlink auf dem Tablet finde aus zwei Gründen interessant:
Man kann die Nummer direkt als Kontakt speichern und ab Herbst sogar vom iPad aus anrufen wenn man auch ein iPhone besitzt. Ersteres habe ich schon öfter genutzt, ich finds gut. Ob das Telefonieren vom iPad praktikabel ist, wird sich zeigen.

Ich habe halt die Erfahrung gemacht dass meine Kunden die Nummern im Zweifelsfall so eingeben dass ein Smartphone sie nicht erkennt ... so schreiben Sie die Telefonnummer wie sie wollen, markieren die Nummer und klicken auf "Benutzerdefiniertes Auswahlfeld" - "Telefonnummer". Fertsch. Über Sinn und Unsinn kann man echt streiten, aber "Nutzererziehung" funktioniert meist auch nicht ...

Klenkes schrieb:

Mit meinem Tablet habe ich auf der Seite ein paar Probleme.
1. Ich kann nicht auf die Unterseiten navigieren, das das Menü kurz aufklappt, dann aber schon der Toplevelmenüpunkt geladen wird.

Ist das jetzt beim Ausklappmenü oder bei der Mobilnavi?

Klenkes schrieb:

Ich würde bei Einsatz von Aufklappmenüs trotzdem immer ein zweites Untermenü einbauen.

Ja, das mache ich bei großen Sites auf jeden Fall. Aber bei den paar Seiten? Er hat ja teilweise nur 2-3 Unterseiten.

Klenkes schrieb:

2. Das fixierte Hintergrundbild bremst mein Tablet dermaßen aus, dass ein nach unten Wischen kaum möglich ist. Opera Mobile zerhackt mir dann das Hintergrundbild.

Hmmm. Das ist gar kein Hintergrundbild. Das ist ein Bild, das in den Hintergrund gelegt wird. Die Methode stammt von
http://css-tricks.com/perfect-full-page … und-image/
es ist "CSS-Only Technique #1".

Ich habe diese Methode gewählt weil
- weitgehend kompatibel
- das image auf einfache Weise nur für nicht-Smartphones ausgeliefert werden kann (via toolbox/mobiledetect)

Für alles was smartphone ist wird ein Hintergrundbild per media-query ausgeliefert.
Ja, keine wirklich schöne Lösung bis jetzt, da in gewissemm Sinne die Kriterien sich überschneiden.

Darf ich fragen wie hoch deine Bildschirmauflösung ist?

Hat jemand ne bessere Lösung?

Klenkes schrieb:

3. Dazu finde ich auf meinem 10 Zoll Tablet die Navigationspunkte viel zu klein zum Tappen.

Klenkes schrieb:

Erfahrungsgemäß funktionieren fixierte Hintergründe auf iPads flüssiger als auf Android Geräten.
Meins ist ein Acer 10" Android 3.2 mit Androidbrowser und Opera Mobile.

Hmm, ich hatte das auf nem Samsung Android-Teil getestet und es lief flüssig.

Servus,
Alex

Beitrag geändert von faglork (12. August 2014 12:35)

NaN · 12. August 2014 13:37

faglork schrieb:

klenkes schrieb:
2. Das fixierte Hintergrundbild bremst mein Tablet dermaßen aus, dass ein nach unten Wischen kaum möglich ist. Opera Mobile zerhackt mir dann das Hintergrundbild.
[...]
"CSS-Only Technique #1"

Um was für ein Tablet/Browser handelt es sich?
Meines Wissens gab es da auf Android Geräten mit WebKit Browsern ein Problem mit CSS und position:fixed.
Helfen soll zusätzlich eine dieser Eigenschaften (auf das fixe Bild angewendet):

Hier klicken, um den Code zum Kopieren zu markieren

-webkit-transform: translateZ(0);
-webkit-overflow-scrolling: touch;

faglork · 12. August 2014 14:31

faglork schrieb:

Klenkes schrieb:
2. Das fixierte Hintergrundbild bremst mein Tablet dermaßen aus, dass ein nach unten Wischen kaum möglich ist. Opera Mobile zerhackt mir dann das Hintergrundbild.
Hmmm. Das ist gar kein Hintergrundbild. Das ist ein Bild, das in den Hintergrund gelegt wird. Die Methode stammt von
http://css-tricks.com/perfect-full-page … und-image/
es ist "CSS-Only Technique #1".
Ich habe diese Methode gewählt weil
- weitgehend kompatibel
- das image auf einfache Weise nur für nicht-Smartphones ausgeliefert werden kann (via toolbox/mobiledetect)
Für alles was smartphone ist wird ein Hintergrundbild per media-query ausgeliefert.
Ja, keine wirklich schöne Lösung bis jetzt, da in gewissem Sinne die Kriterien sich überschneiden.

Ich habs mal mit background cover versucht aber das ist ungünstig:
http://tinyurl.com/q8eg5od

Bei der bisherigen Lösung bleibt der Hintergrund zentriert, und ab 2000px erscheint ein weiterer Hintergrund.
Wenn ich das mit background cover versuche, dann kann ich das container-div zwar auf 2000px begrenzen, aber das COVER bezieht sich offenbar auf den viewport (?????) und es zieht das Bild immer weiter auf. Ist das normal??

Geht mal auf http://tinyurl.com/q8eg5od und zieht - falls der Monitor das hergibt - auf > 2000 Pixel auf.
Wechselt dann mal auf ne andere Seite um den Unterschied zu sehen. background-size cover scheint sich beim Scaling auf den viewport zu beziehen. Sieht man auch schön wenn man die Seite immer weiter aufzieht. Könnt ihr das nachvollziehen? Kann man das abstellen? Das Bild sollte halt auf max. 2000px begrenzt werden.

Servus,
Alex

Beitrag geändert von faglork (12. August 2014 14:57)

Klenkes · 12. August 2014 16:14

NaN schrieb:

Um was für ein Tablet/Browser handelt es sich?
Meines Wissens gab es da auf Android Geräten mit WebKit Browsern ein Problem mit CSS und position:fixed.

Genau. Android 3.2 und der WebKit Browser.

faglork schrieb:

Klenkes schrieb:
1. Ich kann nicht auf die Unterseiten navigieren, das das Menü kurz aufklappt, dann aber schon der Toplevelmenüpunkt geladen wird.
Ist das jetzt beim Ausklappmenü oder bei der Mobilnavi?

Eine Mobilnavigation kann ich nicht sehen...
Meine Auflösung ist 1280x800px und sieht aus wie die volle Desktopvariante der Website.

Da die Toplevelmenüpunkte Inhaltsseiten sind, werden sie beim Antippen auch geladen.
Wenn denn das Menü kurz ausklappt, so verschwindet es beim Laden der Seite ja wieder.
So komme ich z.B. nie zur Seite AKTUELLES / TERMINE
... es sei denn ich bin schnell genug lol

faglork · 12. August 2014 16:40

Klenkes schrieb:

Eine Mobilnavigation kann ich nicht sehen...
Meine Auflösung ist 1280x800px und sieht aus wie die volle Desktopvariante der Website.
Da die Toplevelmenüpunkte Inhaltsseiten sind, werden sie beim Antippen auch geladen.
Wenn denn das Menü kurz ausklappt, so verschwindet es beim Laden der Seite ja wieder.
So komme ich z.B. nie zur Seite AKTUELLES / TERMINE
... es sei denn ich bin schnell genug

I see ... die Lösung dafür wären Submenüs auf den Unterseiten, aber nur für Tablets und Desktops.

Zumindest wäre das ne *einfache* Lösung ohne grße Klimmzüge.

Andererseits:
Kannst du mal bitte schauen ob das bei dieser Lösung funktioniert:
http://www.cssplay.co.uk/menus/cssplay- … l-two.html
"On touch screens the the first tap will open the sub menu and a second tap will activate the link."

Das Teil implementiere ich grade als Lösung für große Sites. Spricht aber nix dagegen es auch für kleine Sites zu verwenden ...

Servus,
Alex

Klenkes · 12. August 2014 17:03

faglork schrieb:

Andererseits:
Kannst du mal bitte schauen ob das bei dieser Lösung funktioniert:
http://www.cssplay.co.uk/menus/cssplay- … l-two.html
"On touch screens the the first tap will open the sub menu and a second tap will activate the link."

Hey! Das funktioniert ja prima!

...aber wie macht man dem Besucher klar 2x zu tippen um den obersten Menüpunkt aufzurufen?
mhh...

NaN · 13. August 2014 08:09

Wenn ich das mit background cover versuche, dann kann ich das container-div zwar auf 2000px begrenzen, aber das COVER bezieht sich offenbar auf den viewport (?????) und es zieht das Bild immer weiter auf. Ist das normal??

Passiert nur bei background-attachment: fixed.
Siehe Mozilla Developer Docs:

The background positioning area is, by default, the area containing the content of the box and its padding; the area may also be changed to just the content or to the area containing borders, padding, and content. If the background's attachment is fixed, the background positioning area is instead the entire area of the browser window

cover und contain verhalten sich in dem Falle genauso wie prozentuale Angaben.

Siehe dazu auch die Empfehlungen des W3C zum Thema "containing block":

3. If the element has 'position: fixed', the containing block is established by the viewport in the case of continuous media or the page area in the case of paged media.

D.h. sobald irgendetwas "fixed" ist, muss es - logischerweise - relativ zum Viewport sein. (sonst kann es nicht als "fixed" dargestellt werden)

faglork · 13. August 2014 14:01

Ahh .... danke für die ausführliche Antwort. Dann scheidet das natürlich aus. Das macht aber das ganze Konstrukt ein bisschen sinnlos, finde ich ... wenn ich ein relativ kleines DIV habe welches einen background mit cover bekommen soll, und es zieht mir den Hintergrund jedesmal auf die volle Bildschirmgröße auf ... das ist doch sch...

NaN schrieb:

D.h. sobald irgendetwas "fixed" ist, muss es - logischerweise - relativ zum Viewport sein. (sonst kann es nicht als "fixed" dargestellt werden)

Naja, position:fixed bezieht sich auf das Eltern-Element, falls dieses position:relative hat. Ich dachte halt das wäre hier genauso. Falsch gedacht ...

Servus,
Alex

NaN · 13. August 2014 14:41

Naja, position:fixed bezieht sich auf das Eltern-Element, falls dieses position:relative hat.

Nee, eben nicht.
Meines Wissens gilt das bei position:absolute.
Aber nicht bei fixed.
Siehe auch: http://www.w3.org/wiki/CSS_absolute_and … ositioning

An element with position:fixed is fixed with respect to the viewport.

Und genauso verhält es sich mit background-attachment:fixed.

Wenn man darüber nachdenkt, und sich ein Element oder ein Hintergrundbild vorstellt, welches nicht mit dem beinhaltenden Element mitscrollen sondern "stehen bleiben" soll, wird's eigentlich eindeutig, dass sich fixed immer auf den Viewport beziehen muss.

faglork · 13. August 2014 15:02

NaN schrieb:

Wenn man darüber nachdenkt, und sich ein Element oder ein Hintergrundbild vorstellt, welches nicht mit dem beinhaltenden Element mitscrollen sondern "stehen bleiben" soll, wird's eigentlich eindeutig, dass sich fixed immer auf den Viewport beziehen muss.

Hast recht ...

Hab das menü jetzt "gefixed" und es bezieht sich auf das Elternelement.

Aber egal ...

Alex

Beitrag geändert von faglork (22. August 2014 13:11)

faglork · 22. August 2014 13:26

Klenkes schrieb:

1. Ich kann nicht auf die Unterseiten navigieren, das das Menü kurz aufklappt, dann aber schon der Toplevelmenüpunkt geladen wird.
........
Eine Mobilnavigation kann ich nicht sehen...
Meine Auflösung ist 1280x800px und sieht aus wie die volle Desktopvariante der Website.
Da die Toplevelmenüpunkte Inhaltsseiten sind, werden sie beim Antippen auch geladen.
Wenn denn das Menü kurz ausklappt, so verschwindet es beim Laden der Seite ja wieder.
So komme ich z.B. nie zur Seite AKTUELLES / TERMINE
... es sei denn ich bin schnell genug

Ich habe jetzt mal superfish.js / hoverIntend.js eingebunden für alles über 660 Pixel Breite, mit resize-abhängigen destroy/init ...

Sieht auf den ersten Blick gut aus:

- über 660px zusätzliche Binnen-Navigation in der rechten Spalte
- Untermenüs erscheinen leicht verzögert
- Untermenüs schließen deutlich verzögert -> bessere Usability
- erster Touch öffnet Menü, zweiter aktiviert den Link (funzt das bei euch?)
- unter 660 Px unverändert das voll aufgeklappte Menü

EDIT: Ich habe auch normalizer.js eingebunden - jetzt funzt das auch auf Opera mini / mobile.

IE7 ist noch ein Problem, das display:none wohl unter bestimmten Bedingungen (die hier offenbar gegeben sind) nicht berücksichtigt wird. Damit zeigt IE7 das komplette Menü an. Ich versuch das mal mit conditional HTML für den IE7 zu beheben.

Berücksichtigt Ihr noch IE7?

BTW: http://developers.google.com/speed/pagespeed/insights/ sieht gut aus für die Site.

Kommentare?

Servus,
Alex

PS: Die Variante für große Websites (paar -zig Seiten) geht nächste Woche online. Ich mach dann noch nen diesbezüglichen Thread auf. Muss nur noch das Menütemplate um ein paar Sachen ergänzen.

Beitrag geändert von faglork (24. August 2014 09:59)

NaN · 22. August 2014 13:26

Hab das menü jetzt "gefixed" und es bezieht sich auf das Elternelement.

Gib dem Menü mal "left:0" und Du wirst sehen dass es das bezüglich der Position eben nicht tut wink
Obwohl das Elternelement "position:relative" hat.

Allerdings gilt das offenbar nur bei Positionierungen.
Bei "width:100%" richtet es sich komischerweise wieder nach dem Elternelement ... roll

Warum es sich dann bei background-size nicht auch nach dem Elternelement richten kann, erschließt sich mir nicht.

So richtig konsequent sind die da offenbar auch nicht unbedingt.

Ah... max-width übersehen.

faglork · 22. August 2014 13:38

NaN schrieb:

Hab das menü jetzt "gefixed" und es bezieht sich auf das Elternelement.
Gib dem Menü mal "left:0" und Du wirst sehen dass es das bezüglich der Position eben nicht tut
Obwohl das Elternelent "position:relative" hat.

OkOkOkOk ... du.hast.recht. ;-)

NaN schrieb:

Allerdings gilt das offenbar nur bei Positionierungen.
Bei "width:100%" richtet es sich komischerweise wieder nach dem Elternelement ...
Warum es sich dann bei background-size nicht auch nach dem Elternelement richten kann, erschließt sich mir nicht.
So richtig konsequent sind die da offenbar auch nicht unbedingt.

Es treibt einen manchmal in den Wahnsinn.
Speziell die Breite des .nav Elements hat mich graue Haare gekostet. 100% bezieht sich - daran hätte ich ja gleich sehen können dass du recht hast - auf den Viewport. Also muss man "auto" nehmen, das bezieht sich - offenbar - auf das Eltern-Element. Allerdings habe ich einen ca. 40-Pixel-Bereich, in dem es das auch nicht macht ... aber das fixe ich als Kür, noch gehts um die blanken Basics.

Servus,
Alex

faglork · 24. August 2014 09:58

faglork schrieb:

Ich habe jetzt mal superfish.js / hoverIntend.js eingebunden für alles über 660 Pixel Breite, mit resize-abhängigen destroy/init ...

... und vergessen auch das Laden der .js nur auf desktops und tablets zu beschränken. Ist korrigiert, weil mit Opera mini / mobile nix mehr ging. Nebenbei spart es natürlich auch ein paar sinnlose kb.

Servus,
Alex

Beitrag geändert von faglork (24. August 2014 11:05)

faglork · 12. März 2015 12:17

Mittlerweile ist die Seite live:

www.genussbotschafter.ws

Klappt eigentlich ganz gut.

Kommentare? Anregungen? Funzt was nicht?

Falls gewünscht, stelle ich die nav-template / .css zum Download zur Verfügung.

Servus,
Alex

mike-r · 12. März 2015 15:18

Sieht sehr gut aus und funktioniert prima (ok, ich geh mir gleich mal den Mund mit Seife auswaschen).

So, fertig. Paar Probleme und Problemchen:

die social-box bzw. die sidebar cleart (auf der Startseite) nicht richtig und läuft unten aus dem main raus.
Dafür is sie auf Folgeseiten viel zu kurz. (border-left hört mitten im Nichts auf)
"Weitersagen" sollte per js geschrieben werden. (wenn JS deaktiviert ist, steht das grad allein da)
times new roman für die Überschriften is imho nicht schön
aktuelle News ist im Sidebar-Menü nicht hervorgehoben
#newslist würde ich den border-top entsorgen
div.hr fehlt clear:both Hier bei vor/zurück zu sehen: http://www.genussbotschafter.ws/news/19 … hlung.html

nockenfell · 12. März 2015 21:47

Auf den ersten Eindruck gefällt mir die Seite gut.

Ein paar Details würde ich anders machen

SocialSharePrivacy passt nicht auf die Seite. Ein Abschluss ähnlich der Navigation mit den Social-Buttons wäre besser (Startseite). Auf den Unterseiten ist es besser gelöst. Auf dem Handy wirkt es gar nicht mehr. Da würde ich das allenfalls sogar ausblenden.
New Times Romans ist für mich im Kontext nicht immer glücklich gewählt. Mir gefällt die Hauptüberschrift sehr gut. Jede weitere Überschrift, auch in der Sidebar sollte eher in Verdana sein
Vorherige / Nächste Seite ist bei schmalen Bildschirmen (Handys / Tablets) irgendwie am falschen Ort. Am Ende der Seite wäre das Besser

faglork · 13. März 2015 15:45

Erstmal Danke für die Hinweise!

mike-r schrieb:

Sieht sehr gut aus und funktioniert prima (ok, ich geh mir gleich mal den Mund mit Seife auswaschen).

lol ...

mike-r schrieb:

So, fertig. Paar Probleme und Problemchen:
[*]die social-box bzw. die sidebar cleart (auf der Startseite) nicht richtig und läuft unten aus dem main raus.
Dafür is sie auf Folgeseiten viel zu kurz. (border-left hört mitten im Nichts auf)[/*]

Da is nix mit clearen wg. position:absolute ...
Ich bin auch nie auf den Gedanken gekommen dass er als News Summary ein Riesenbild reinsetzt ...
Muss ich drüber nachdenken ...

mike-r schrieb:

[*]"Weitersagen" sollte per js geschrieben werden. (wenn JS deaktiviert ist, steht das grad allein da)[/*]

fixed

mike-r schrieb:

[*]times new roman für die Überschriften is imho nicht schön[/*]

Findet Ihr?

mike-r schrieb:

[*]aktuelle News ist im Sidebar-Menü nicht hervorgehoben[/*]

Versteh ich jetzt nicht

mike-r schrieb:

[*]#newslist würde ich den border-top entsorgen[/*]

Hast recht. Entsorgt.

mike-r schrieb:

[*]div.hr fehlt clear:both Hier bei vor/zurück zu sehen: http://www.genussbotschafter.ws/news/19 … hlung.html[/*]

fixed

Dankeschön!
Alex

faglork · 13. März 2015 15:49

nockenfell schrieb:

Auf den ersten Eindruck gefällt mir die Seite gut.
Ein paar Details würde ich anders machen

[*]SocialSharePrivacy passt nicht auf die Seite. Ein Abschluss ähnlich der Navigation mit den Social-Buttons wäre besser (Startseite). Auf den Unterseiten ist es besser gelöst. Auf dem Handy wirkt es gar nicht mehr. Da würde ich das allenfalls sogar ausblenden.[/*]

Ja, selbes Problem wie mike-r schon bemängelt hat. Wie gesagt, clearen ist da nicht. Muss ich drüber nachdenken.

nockenfell schrieb:

[*]New Times Romans ist für mich im Kontext nicht immer glücklich gewählt. Mir gefällt die Hauptüberschrift sehr gut. Jede weitere Überschrift, auch in der Sidebar sollte eher in Verdana sein[/*]

Verdana finde ich nun wieder total ausgelutscht.

nockenfell schrieb:

[*]Vorherige / Nächste Seite ist bei schmalen Bildschirmen (Handys / Tablets) irgendwie am falschen Ort. Am Ende der Seite wäre das Besser[/*]

Aber es gehört zum content und nicht zur sidebar, die in diesem Fall nach unten rutscht. Dann wäre es IMO besser die sidebar ganz wegzulassen.

Danke für die konstruktive Kritik!

Servus,
Alex

Forum für CMS/made simple

#1 08. August 2014 14:06

Responsive Website in Arbeit - bitte diskutieren

#2 08. August 2014 20:42

Re: Responsive Website in Arbeit - bitte diskutieren

#3 09. August 2014 08:13

Re: Responsive Website in Arbeit - bitte diskutieren

#4 09. August 2014 09:03

Re: Responsive Website in Arbeit - bitte diskutieren

#5 12. August 2014 12:05

Re: Responsive Website in Arbeit - bitte diskutieren

#6 12. August 2014 13:37

Re: Responsive Website in Arbeit - bitte diskutieren

#7 12. August 2014 14:31

Re: Responsive Website in Arbeit - bitte diskutieren

#8 12. August 2014 16:14

Re: Responsive Website in Arbeit - bitte diskutieren

#9 12. August 2014 16:40

Re: Responsive Website in Arbeit - bitte diskutieren

#10 12. August 2014 17:03

Re: Responsive Website in Arbeit - bitte diskutieren

#11 13. August 2014 08:09

Re: Responsive Website in Arbeit - bitte diskutieren

#12 13. August 2014 14:01

Re: Responsive Website in Arbeit - bitte diskutieren

#13 13. August 2014 14:41

Re: Responsive Website in Arbeit - bitte diskutieren

#14 13. August 2014 15:02

Re: Responsive Website in Arbeit - bitte diskutieren

#15 22. August 2014 13:26

Re: Responsive Website in Arbeit - bitte diskutieren

#16 22. August 2014 13:26

Re: Responsive Website in Arbeit - bitte diskutieren

#17 22. August 2014 13:38

Re: Responsive Website in Arbeit - bitte diskutieren

#18 24. August 2014 09:58

Re: Responsive Website in Arbeit - bitte diskutieren

#19 12. März 2015 12:17

Re: Responsive Website in Arbeit - bitte diskutieren

#20 12. März 2015 15:18

Re: Responsive Website in Arbeit - bitte diskutieren

#21 12. März 2015 21:47

Re: Responsive Website in Arbeit - bitte diskutieren

#22 13. März 2015 15:45

Re: Responsive Website in Arbeit - bitte diskutieren

#23 13. März 2015 15:49

Re: Responsive Website in Arbeit - bitte diskutieren

Fußzeile des Forums