Hallo BeRo,

das Bild liegt als "Wiederholte Gruppe -> Rechteck" auf jeder Seite in der Ebene "Pasteboard background.

Hier mal die Projekt Datei -> http://filehorst.de/d/bDsEtkIb

Die tatsächliche Lösung ist zwar eine andere, aber sie ist genauso simpel.

Wenn Du dafür sorgst, dass das Hintergrundbild tatsächlich an letzter Stelle im Pasteboard background liegt, dann klappt's.
Natürlich darf dann auch kein seitenfüllendes Objekt darüber liegen, z. B. das weiße Rechteck...

Lade Dir mal hier die funktionierende Projektdatei herunter.

Viel Spaß beim weiteren Website Design.

Ahja, hab das auch gerade gesehen, daß die Indexseite in der "Pasteboard background"-Ebene mit den HG-Bild endet und auf den anderen Seiten in der Ebene ein Wiederholtes Objekt doppelt existiert (hellgraues Rechteck neben den Logo). Wie das weiße Rechteck darein gekommen ist weiß ich nun auch nicht. Bestimmt versehentlich was falsch geklickt. Nachdem ich die beiden Objekte entfernt habe (das eine war ja doppelt und das weiße Rechteck unnötig) klappts nun - der HG steht fest auf jeder Seite.

Danke für den Tipp, BeRo! :)

ps: Ich habe das zwar schon einmal in einen anderen Thread gefragt aber weißt du zufällig warum der WD10 komprimierte Fotos IMMER so künstlich aufbläht? Egal welches Foto, die Quelldatei ist meist fast nur halb so groß in KB als die Datei welche der WD10 dann nach einbetten in das Projekt in den index_html_files exportiert.

Aktuelles Beispiel ist zb. das hier schon erwähnte HG-Foto. Als Quelldatei ist das 44,5KB bei 80% JPEG-Komprimierung groß. WD10 "zaubert" mir daraus nach exportieren eine Größe von 74,5KB, daß sind mal ebend 30KB mehr und das, obwohl ich schon in den Bildeigenschaften im WD10 JPEG-Format mit 85% Komprimierung eingestellt habe.

Ok, daß liest sich jetzt wenig aber summiert man das mal auf das fertige Projekt wo noch einige Fotos, Logos im PNG Format (da ist es dann besonders bei den Logos mit hohen Gelb & Rot Anteilen besonders schlimm was der WD 10 da an KB drauf sattelt) usw. zu kommt, dann sind das mehrere 100KB was definitiv auf die Ladezeiten geht, besonders bei Kunden mit eher dürftiger Internet Anbindung. Bei mir ist es ja egal, hab eine 150MBit via Kabel aber unsere Firma zb. nutzt "nur" 6Mbit und viele Kunden dümpeln mit weit weniger im Netz herum.

Kann man das im WD10 nicht irgendwo einstellen, daß der Editor die Größen generell 1:1 übernimmt und weiter verarbeitet? Ziel so eines Editor sollte es doch eigentlich sein die Fotos smarter zu verarbeiten und nicht da noch drauf zu legen.

..weil jetzt alle Fotos, Logos usw. nachher mühselig auszutauschen durch die Quelldateien und diese dann noch entsprechend den Dateien in der Index_file umzubennen, daß ist ja Mumpitz und spätestens wenn man dann an den Projekt was nacharbeitet  und dieses wieder exportiert war die ganze Arbeit dann für die Katz!

Das muss doch auch anders gehen.

--------------------------------

2te sache die mir auch noch aufgefallen ist und was ich hier im Forum auch mal an den Problem anderer User nachlesen konnte: Die Textqualität des WD10. Mir ist zb. aufgefallen, daß der Text  in der Navigationsleiste mit der Zeit verwischt. Ganz schlimm ist das wenn man eine Navigationsleisten Vorlage aus den Content Katalog verwendet. Da greife ich mittlerweile gar nicht mehr drauf zu, weil das habe ich immer wieder und baue mir die Navi lieber selber. Ok, weiße Schrift auf roten HG ist nie so konturenscharf wie zb. auf mittelgrauen HG und daher wähle ich generell PNG-Format aber dennoch, je öfter ich die Seite bearbeite und demzufolge WD10 die Änderungen abspeichert, desto verwaschener wirkt nach der Zeit die Navileiste. Das darf nicht sein.

[...] summiert man das mal auf das fertige Projekt [...] dann sind das mehrere 100KB was definitiv auf die Ladezeiten geht [...]

Das ist offenbar nicht jedem klar (klick)

[...] jetzt alle Fotos, Logos usw. nachher mühselig auszutauschen durch die Quelldateien [...] ist ja Mumpitz und spätestens wenn man dann an den Projekt was nacharbeitet  und dieses wieder exportiert war die ganze Arbeit dann für die Katz! [...]

Nicht ganz. Richtig ist nur, dass der Austausch eine Menge Arbeit macht. Wenn Du aber die Bilder nicht per drag & drop importierst sondern per Link auf Datei mit der Option "Platzhalter - Mit Grafik ersetzen", wird alles gut.

Vorteil der o. a. Methode ist, dass die Bilder in der Größe tatsächlich 1:1 übernommen- und verarbeitet werden und obendrein behalten sie auch ihren Originalnamen, was alle SEO Perfektionisten freuen wird.

[...] Mir ist zb. aufgefallen, daß der Text  in der Navigationsleiste mit der Zeit verwischt [...] das habe ich immer wieder und baue mir die Navi lieber selber [...]

Das "selber bauen" ist die einzige mir bekannte Methode, mit der Du unscharfe Schrift auf Linkbuttons dauerhaft vermeiden kannst.(klick).

Viel Spaß beim weiteren Website Design

-----------------
Edit 3.4. 17:11

Falsche Info zum Einfügen von Bildern korrigiert

[...]Wenn Du aber die Bilder nicht per drag & drop importierst sondern per Link auf Datei, wird alles gut.[...]

Wie meinst du das? Per drag & Drop füge ich nie Fotos in das Projekt, sondern immer über "Einfügen -> Bild -> Aus Datei". Über die Webeigenschaften -> Reiter Bild -> Bildunterschrift (Alt Tag) vergebe ich dann den Namen zum Bild oder jeweiligen Objekt bzgl. SEO.

Dennoch exportiert WD10 die Datei dann aber im Index Folder mit einer Zahlenfolge und der gewählten Dateiendung (jpg, png) und ändert die Dateigröße meist negativ nach oben.

Zu den "Verwischen": Als du meinst ich soll unter den Button-Text ein transparentes Rechteck schieben und das dann verlinken? Aber wenn ich jetzt das Buttonfeld (Mouseoff: grau / Mouseover: rot) zusammen mit den transparenten verlinkten Rechteck darüber und den dann darüber liegenden Text gruppiere - ist dann nicht wieder die ganze Gruppe verlinkt und das verwischen weiterhin vorhanden?

Gruppieren muß ich das ja, weil die Gruppe wird ja dann in die MouseOver Ebene kopiert, Farbe des Buttonfeldes in rot geändert und dann mit der MouseOff Gruppe als Weiche Gruppe gruppiert. Sonst gibts ja kein MouseOver Effekt.

ps: Nochmal was zu den HG-Bild: Ausgehend von der Auflösung 1920x1080. Ist es optimal das HG Bild für jede Website Variante immer 16:9 Format anzupassen? Also Laptop Variante dann zb. 1024x576, Tablet 768x432 usw. und dabei dann den Arbeitsbereichhintergrund lieber Broserfensterfüllend statt fest zu wählen?

pps: So schaut das im Moment aus (Projektdatei), die Buttonschrift ist wieder leicht verwischt und das HG-Foto hab ich mal 16:9 Größe in den beiden Varianten PC/Laptop eingebettet  -> http://filehorst.de/d/bzgwmCiI

[...] Per drag & Drop füge ich nie Fotos in das Projekt, [...]

Das solltest Du aber, denn das geht sehr viel schneller als mit der Menü Option "Einfügen"

[...] Dennoch exportiert WD10 die Datei dann aber im Index Folder mit einer Zahlenfolge [...] und ändert die Dateigröße meist negativ nach oben.[...]

Genau diese beiden Nachteile kannst du vermeiden, wenn Du Bilder mit der Option "Platzhalter" - "Mit Grafik ersetzen" einfügst. Das Verfahren ist vom Aufwand her in etwa mit der von Dir bisher praktizierten Methode zu vergleichen.

So geht's:
Einen beliebigen Platzhalter da anlegen, wo später das Bild erscheinen soll und dann die Option "Mit Grafik ersetzen" wählen.

Wenn Du die Checkbox "Platzhalter Bild automatisch neu erstellen" aktiviert hast, siehst Du das importierte Bild schon im Editor und es lässt sich da beliebig bearbeiten.

Ein (Datei) Größenvergleich von Bildern, die mit Deiner bisherigen- und alternativ mit der Platzhalter Methode importiert wurden, zeigt den dabei auftretenden, positiven Effekt:

1. zeigt die Dateigröße (24 KB) des Originals, das auf dem Desktop liegt
2. zeigt die Dateigröße (24 KB) nach Import mit der Platzhalter Methode
3. zeigt die Dateigröße (28 KB) nach Import mit Menü Option "Einfügen"

Die Einfüge Methode über die Menü Option "kostet" also ca. 15% Speicher Mehrverbrauch...

Ein weiterer, angenehmer Begleiteffekt der Platzhalter Methode ist, dass der Originalname der Bilddatei beibehalten wird:

Und natürlich musst Du bei Änderungen an der Site keine der o. a. Arbeitsschritte wiederholen. Es bleibt alles so gespeichert, wie Du es angelegt hast.

[...] Zu den "Verwischen": Als du meinst ich soll unter den Button-Text ein transparentes Rechteck schieben und das dann verlinken? [...]

Ja, in etwa so...

Das transparente Rechteck mit dem Link muss auf dem Button der NavBar liegen, nicht darunter.

wenn ich jetzt das Buttonfeld [...] zusammen mit den transparenten verlinkten Rechteck darüber und den dann darüber liegenden Text gruppiere - ist dann nicht wieder [...] das verwischen weiterhin vorhanden?

Ja, das wäre dann genau so.
Der Trick beim Nachbau einer NavBar mit scharfer Schrift besteht aber darin, diese Gruppierung zu vermeiden. Die Funktion ist ja nicht von der Gruppierung abhängig und der Link wird vom transparenten Rechteck "getragen".

[...] Gruppieren muß ich das ja, weil die Gruppe wird ja dann in die MouseOver Ebene kopiert [...]

Auch dafür ist das Gruppieren nicht erforderlich. Du kannst die MouseOff- und die MouseOver Objekte aber in einer weichen Gruppe zusammenfassen, damit sie sich später besser händeln (positionieren) lassen.

Hier hatte ich schon eine detaillierte Info zur Vorgehensweise gepostet. Wirf da nochmal einen Blick drauf...

[...] Ist es optimal das HG Bild für jede Website Variante immer 16:9 Format anzupassen? [...]

In Deinem Fall würde ich das nicht empfehlen. Da das Bild wirklich nur einen Hintergrund darstellt, kommt es wohl nicht so sehr auf die detaillierte Darstellung an.
Die einfachste Lösung wäre also eine Universalgröße (z. B. 1024 x 768) und eine Browserfüllende Einstellung für die Pasteboard background Ebene.

Viel Erfolg und ein paar schöne Ostertage..

Ich werde das mal alles so ausprobieren und meld mich dann mal was wie wo geklappt hat. 

Danke dir schonmal für die Tipps, BeRo und wünsche dir auch schöne Osterfeiertage.

ps: Aha, jetzt verstehe ich den Sinn dahinter warum du das mit einen transparenten Rechteck über Button und Text machst.  Text der nicht verlinkt mit einen Button gruppiert ist wird ja nicht als Grafik gespeichert und besitzt demzufolge auch keine "optischen Qualitätseinbußen" durch das konverten in Png und das transparente Rechteck legst nur verlinkt darüber, damit sich der Mauszeiger nicht in einen Textfeldzeiger ändert und halt ebend einen echten Klickbutton simuliert. Guter Trick, wäre ich nicht drauf gekommen.

Richtig?

[...] Richtig?

Absolut!

Einen Nachteil hat jetzt zwar die ganze Sache, der Button der aktiven Seite (zb. Startseite Index) ist jetzt nicht mehr rot (MouseOver), da ja der Link -logischerweise- auf der MouseOff Ebene des übergeordneten transparenten Rechtecks liegen muss aber das ist verschmerzbar.

Dafür werden die Buttons jetzt gar nicht mehr als qualitätsverlustgefährdete PNG im Index Folder gespeichert, da ja im Grunde nur eine CSS Box mit Text darüber und einer transparenten "Mogelpackung", tricky ausgedacht.

Vorteile des ganzen:

• der Text bleibt immer 100% konturenscharf
• der Button kann qualitätsverlustfrei auch in der Größe reduziert für kleinere Website Varianten verwendet werden (zb. Laptop/Tablet Auflösung)
• der meiner Meinung nach entscheidenste Vorteil aber ist, WD10 speichert keine Armada von PNG Buttons mehr im Index Folder, weil es ja im Grunde keine echten Grafiken sind und das macht bei meinen Projekt zb. nur in der 1200px. WS-Variante schon über 30!! gesparte KB aus, die "nur" für verwaschene Buttons verplempert werden würden. 2ter Vorteil ist ja auch noch, daß CSS Boxen wesentlich flotter aufgebaut werden als Grafiken, also auch noch schneller und das bei verlustfreier Qualität.

Da sollten die Entwickler von Magix mal beim nächsten Bug-Update drüber nachdenken, ob die so ein "Feature" nicht mal in WD10 mit einbringen. Denn diese, im wahrsten Sinne des Wortes, wischiwaschi Buttons aus zb. den Content Katalog kann man mal komplett vergessen. Die taugen nix und kosten nur kostbaren Speicherplatz.

Nochmal danke für den tricky Tipp, BeRo, ich werde dann hier das Ergebniss der von dir vorgeschlagenen Tipps beizeiten posten, spätestens aber wenn das nächste Problem ansteht. Weißt ja, Murphys Law usw.

So, Murphys Law hat wieder zugeschlagen!

Folgendes: In den WS-Varianten PC und Laptop funktioniert die Button Geschichte tip top einwandfrei, in der WS-Variante Tablet benutze ich nun Buttons die auf einer Buttongrafik statt wie bei zuerst genannten WS-Varianten -einer CSS Box- aufbauen.

Die vorgehensweise ist identisch: Buttongrafik in MouseOff und MouseOver Ebene / Text darüber in MouseOff und MouseOver Ebene / in MouseOff Ebene transparentes, verlinktes Rechteck darüber / gesamten Button in der MouseOver Ebene Weich gruppieren (wegen der Platzierung).

Funktioniert wie gehabt, mit einen Unterschied: Der Button der "aktiven" Seite ist nun rot statt wie bei den WS-Varianten zuvor grau (was ja kein Nachteil wäre) ....ABER.... der Text auf den Button der aktiven Seite ist pfutsch!! ..hmmm.. und das, obwohl der Text ja eigentlich ÜBER der Buttongrafik, sowohl auf der MouseOff als auch auf der MouseOver Ebene angeordnet ist.

Idee warum das so ist?

Hier die Projektdatei wo man das in der Tablet WS-Variante sehen kann: http://filehorst.de/d/boAxurzA

ps: Fotos über die Platzhalter Methode in Dateigröße 1:1 einzubinden funktioniert übrigens, allerdings habe ich Probleme dabei diese Fotos als Platzhalter dann via MouseOver Effekt zb. zu schattieren (Foto wird dunkler wenn Maus darüber fährt -> bei Mausklick dann Verlinkung zum passenden Thema). Das geht scheinbar nur über die konventionelle Methode mit den Nachteil, daß ebend WD da wieder KB's beim exportieren drauf packt. Schade eigentlich, dann muß ich da wohl per Hand im Index Folder bei Fertigstellung des Projektes die betreffenden Fotos tauschen und umbenennen. Viel Arbeit aber naja.