Recommended Workflow for Webpage Design

[firstdefence]

Another helpful Avenue is using grids as explained on this website: https://webdesign.tutsplus.com/articles/a-comprehensive-introduction-to-grids-in-web-design--cms-26521

This document has the 12 grid system set up: 960_grid_12_col.afdesign

[All Media Lab]

8 hours ago, Mark Oehlschlager said:

Yes, I'm familiar with the rudiments of HTML and CSS. I understand that responsive websites depend upon CSS and JS queries about browser version, OS, Device Pixel Ratio, and browser width in order to associate relevant stylesheets with the HTML page, which can then dictate size and placement of blocks and links to appropriately sized image resources.

I'm sorry with all due respect  but this proves that you have no clue how it works! That's why I gave you de links to the `<picture>` and `<srcset>` examples.

Someone that's want's to create a design for a website needs the knowledge of image resolution on multiple devices with "Art Direction" (yes "Art Direction" it's an important thing to know when you design a website) I uploaded the images for you that show the "Art Directions" for a image header.

No matter if it's on a peace of paper you do the design on, the "Art Directions" is the most important part of your design. It implicates using the proper Aspect Ratio's of images, video,  typography and animations for the proper orientations of the multiple devices. That's why it's so important to get your head around those things and study the  `<picture>` and `<srcset>` examples and the basics of responsive webdesign.  You don't have to become a coder, but at least understand how the mock up has to look like including all devices and orientations Desktop, laptop, tablet, phone and small phone.

Anybody that learns  web design front or backend knows that the order is: "Mobile First" and from there you go with your design. 

If you do this in the Pinegrow Pro Editor it takes you 2 minutes to set up a responsive Bootstrap 4 website (HTML Prototyping) including header, footer and content parts and it is already full responsive (works on any device and you can see it in a browser on your laptop in any nowadays device phones, tablets, laptops, desktop etc all included in the Pinegrow app). If you create a mock up for all devices and all non identical pages it takes you weeks in Affinity Designer. 

A Bootstrap 4 example: 

[Mark Oehlschlager]

@firstdefence

Thank you for the article and the related sample Designer file.

Question: When you set up your 12 column guides, is there an advantage to drawing the columns as curves rather than using the Guides Manager to set up column guides?

In your sample file for a 960 px wide webpage, you set up the document in pixel (px) dimensions with the DPI set to 72. This is of interest to me, as it gets to the heart of my original question.

I've since taken a closer look at the Page Presets in Designer's "New Document" dialogue box for the type categories "Web" and "Devices". I've noticed that any new document started from a "Web" preset assumes page dimensions set in pixels (px) with the DPI set to 72. Any new document started from a "Devices" preset assumes page dimensions set in points (pt) with the DPI set to either 72, 144, or 216 (depending on the device targeted). All of which suggests that Serif are using point units (pt) to represent so-called "Logical Pixel" page dimensions (the CSS reference pixel dimensions that get scaled up by the Device Pixel Ratios), and using the underlying DPI raster density settings to represent the 1x, 2x and 3x device pixel densities that dictate linked raster image dimensions.  

I guess one of the assumptions made here by Serif is that the collection of "Web" page presets are targeted at desktop and laptop displays with an assumed 1x Device Pixel Ratio, and therefore page units are set to pixels (px) and the DPI is set to 72. The latest iMacs and MacBooks from Apple, however, employ Retina displays and are considered 2x devices.

So, it seems that the best practice, whether targeting desktops or mobile devices, is to set up Designer documents/artboards with page dimensions set in points (pt) that reflect the "Logical Pixel" dimensions of the targeted device, and to set the DPI at 216 (3x pixel density). That way, one can lay out a page design using points (equivalent to CSS reference pixels, or "Logical Pixels"), and know that placed raster images can be sliced and exported out at 1x, 2x and 3x sizes.

[R C-R]

20 minutes ago, Mark Oehlschlager said:

I guess one of the assumptions made here by Serif is that the collection of "Web" page presets are targeted at desktop and laptop displays with an assumed 1x Device Pixel Ratio, and therefore page units are set to pixels (px) and the DPI is set to 72.

Nope. The (correct!) assumption is that for web output, DPI/PPI is irrelevant. See for example this article or carefully reread Understanding DPI, paying particular attention to what James says about the difference between logical display size & pixel resolution and how operating systems scale interfaces.

[Mark Oehlschlager]

@R C-R

Not sure that DPI is irrelevant here with respect to slicing and exporting assets.

Here's the way I'm understanding the page presets:

Traditional typographic points from the print world have been conveniently adopted here as a proxy for CSS Reference Pixels ("Logical Pixels"). Traditional typographic points are 1/72nd of an inch – 72 points per inch. Nevermind that on my 110 PPI iMac a 72 x 72 px PNG will actually appear to be 0.65 inch and not a full inch. What's important is that on a 1x display, 1 point equals 1 device pixel. But, for a 2x display, 1 point (stand in for the "Logical Pixel") equals a 2x2 device pixel cluster, hence the doubling of the DPI setting in the Designer Page Presets from 72 to 144. And, for a 3x display, 1 point equals a 3x3 device pixel cluster, hence the tripling of the DPI setting in the Designer Page Presets from 72 to 216.

The benefit here, as I see it, is that the page layout designer can start a new document measured in points (an assumed 1x design scale) with an underlying 3x raster density (216 DPI) and be able to slice and export raster assets for 1x, 2x, and 3x device displays.

[All Media Lab]

I wonder do you  read what people post to help you?

If your going to print your designs it matters on the web not. So if you print your designs you can use like 300 dpi or more.

If you print your mock up you stay in that one DPI value for everything on that page say 300DPI! Then when you start a mock up you create a page in Affinity Designer and give it a 300DPI value and from there you go. If you place an image on that page it has to be 300DPI too etc.etc. 

The same idea but even more advanced grid sits in Bootstrap 4.

On the web only pixels count. Higher resolution screens just pop more pixels in the same place as low resolution screens.

So you can have a iMac with 1080px X 1929px and a iMac of 5120px X 2880px and the screens can be the same size.

This is explained 5 times now. 

https://www.webdesignerdepot.com/2010/02/the-myth-of-dpi/

[R C-R]

27 minutes ago, Mark Oehlschlager said:

Traditional typographic points from the print world have been conveniently adopted here as a proxy for CSS Reference Pixels ("Logical Pixels").

For web page design, don't think in terms of "logical pixels." Instead, think in terms of the logical display size of the entire image (or as James mentioned, its real estate) vs. its pixel resolution (sometimes referred to as it "physical pixels") -- the actual number of pixels in the image.

Also consider that the operating system can scale images of the same pixel resolution to different logical display sizes, & that most web browsers are capable of displaying web pages at different 'zoom levels' which also change the logical display size of images.

For example, open the apple.com web page on an iPhone & use the pinch outward gesture to zoom in on any part of the web page. Note how, within limits, you can smoothly zoom in on any of the Apple product images (thus changing their logical display sizes) without causing any pixilation or other artifacts. Clearly, the images are not being limited to just 1x, 2x, or 3x display sizes -- they can also be displayed at non-integer multiples of their actual pixel resolutions.

As for the built-in Affinity presets, note that for the Device presets, if you select one of the Apple iOS products from the list, the Document Units will be automatically set to points (because iOS automatically maps points to pixels on the display), but if you select one of the others (Nexus, Kindle, Surface Pro) they will automatically be set to pixels. Likewise, the document width, height, & DPI values change depending on the device selected.

For all the Web presets, the DPI is always 72, but that does not matter because DPI is irrelevant for web page content -- only pixel resolution is relevant, & only for output to raster image formats like JPEG or PNG. This has nothing to do with typographic points or so-called "reference" or "logical" pixels.

If you still don't believe what everyone has been telling you, see also this article, which specifically addresses the (non)relevance of DPI for web images displayed on Retina & other "high DPI" devices.

[JonnyFartPants]

DPI has no relevance at all, which is why Affinity photo should be used to design a webpage. I used to design websites and we always used PS. If we needed icons, logos and graphic elements they would be designed in AI and then pasted in as objects.

After your design is finished, you then need to use HTML and CSS to create the structure and then decide which (most), elements can be created using HTML and which parts are images. That is all there is too it. If you want your design elements to look good with retina screen then make sure that each element is either an SVG or x2 the size you want it. You can resize it using CSS and media queries

https://designmodo.com/design-retina-displays/

[Mark Oehlschlager]

@All Media Lab

I've read the article you linked to.

4 hours ago, All Media Lab said:

https://www.webdesignerdepot.com/2010/02/the-myth-of-dpi/

I understand it completely. I don't disagree with any of the points made.

Here's where DPI is relevant to a workflow that uses the Affinity apps to design and build webpage mockups: the New Document dialogue box which asks for Document Units, Page Width, Page Height, and DPI.

Note in the screenshot below that the Page Preset for an iPhone 5/SE (Retina) establishes points (pt) for Document Units. Page Width: 320 pt. Page Height: 568 pt. DPI: 144. What's going on here?

Well, the Retina display for the iPhone 5/SE has an advertised "Logical" display size of 320 x 568, but has an actual device pixel dimension of 640 x 1136 (326 ppi for what it's worth), 2x the so-called "Logical" display size. The Affinity Page Preset for this device sets me up with an artboard that measures 320 x 568 pt (units that correspond to the "Logical" display size) with an underlying raster density of 144 DPI (2x the assumed raster density of 72 DPI) And, if you temporarily switch the document units to pixels, you'll find a 320 x 568 pt artboard at 144 DPI produces an artboard that measures 640 x 1136 px, exactly the dimensions of the 5/SE display in terms of physical device pixels.

What does that mean for me?

It means that I can begin a webpage mockup in Affinity Designer, targeted at a 2x mobile device with a "Logical" display width of 320 px, work in the 1x equivalent units of points, but still have the underlying device pixel density to slice up and export raster image assets with sufficient 2x pixel dimensions. I can also use Affinity's Export Persona to generate a 1x version of those raster image assets if I choose.

So, it is within the context of using Affinity apps to design webpage mockups and export raster image assets that DPI is relevant.

[Mark Oehlschlager]

@R C-R

This is interesting.

2 hours ago, R C-R said:

As for the built-in Affinity presets, note that for the Device presets, if you select one of the Apple iOS products from the list, the Document Units will be automatically set to points (because iOS automatically maps points to pixels on the display), but if you select one of the others (Nexus, Kindle, Surface Pro) they will automatically be set to pixels. Likewise, the document width, height, & DPI values change depending on the device selected.

For all the Web presets, the DPI is always 72, but that does not matter because DPI is irrelevant for web page content -- only pixel resolution is relevant, & only for output to raster image formats like JPEG or PNG. This has nothing to do with typographic points or so-called "reference" or "logical" pixels.

It appears that the Page Presets for the non-Apple devices like the Nexus 5 just takes a different route to the same logical conclusion. Whereas the Presets for the Apple devices define artboard dimensions in terms of "Logical" display pixel dimensions with a DPI setting that calculates device pixel dimensions by essentially doubling or tripling the "Logical" display dimensions, the Presets for devices for the Nexus 5 just expresses dimensions in terms of actual device pixels with an actual screen density of 445 pixels (that's equivalent to the density of the iPhone 11Pro, a 3x device).

The Affinity Presets for "Web" are targeted at desktop and laptop displays. My 2012 iMac has a device pixel density of 110 ppi. Newer iMacs and MacBooks have displays with a device pixel density of 220 ppi. I believe they present themselves with a Device Pixel Ratio of 2, which means that all of the elements of a webpage described by CSS units will scale up 2x, but the raster images that are referenced will have to be correctly sized for the 2x environment. So, going forward, it may make sense to build webpage mockups in Affinity for desktop page widths where the page dimensions are set up in points with a DPI of 144. In that way, one can still be thinking of a 1280 wide page, but in Affinity that's expressed in points, while the underlying raster is double, expressed as 144 DPI, which means you can slice and export 2x raster assets directly.

 

[R C-R]

1 hour ago, Mark Oehlschlager said:

The Affinity Presets for "Web" are targeted at desktop and laptop displays.

No, they are 'targeted' at creating documents that (among other things) can be exported to web-friendly file formats like PNG, JPEG, or SVG. (That's why this group of preset types named "Web.") And as a multitude of sources we have linked to make extremely clear, all that matters for web pages that contain raster images is the resolution of the image (the total number of pixels) of those files. For this use, DPI is irrelevant, period.

As with the Device & other preset types, the built-in ones just offer a quick way to set up new documents for various uses, but you can create custom presets for whatever you want, & change any of them on-the-fly while you work as the need arrises.

If you are still unclear about this, please refer to the AD Document setup help page, which among other things says

• Type—Select the aim and deliverable for your project (for quickly populating settings below). As well as print (press-ready CMYK), you can work to specific Photo print sizes, specific Web screen resolutions, and with the Devices option, design to iPad, iPhone, Apple Watch and Nexus document specifications.

Again, as all the previously cited sources will tell you, "web screen resolution" has nothing to do with DPI. Resolution is measured in pixels, not pixels per anything.

[Mark Oehlschlager]

 

In the context of setting up an Affinity document, the document dimension units and DPI setting in the New Document dialogue box is absolutely relevant to exported size of raster images.

The Preset for "Web", WXGA 1280 x 800, sets up an artboard where document units are pixels, the artboard dimensions are 1280 x 800 px, and the DPI is set to 72. If that artboard were to be exported out as a PNG, one would get a PNG with pixel dimensions of 1280 x 800. That raster image would look half as big on a new 220 ppi iMac than it would on my 2012 110 ppi iMac, unless, of course one used CSS values to scale the image up 2x, in which case the image would look fuzzy on the new 220 ppi iMac.

On the other hand, if you were to modify that Preset such that the document units were points, the artboard dimensions were 1280 x 800 pt, and the DPI were 144, one could layout the page in points (1x equivalent units) and export the artboard as a PNG with 2x pixel dimensions of 2560 x 1600, suitable for display on a new 220 ppi iMac without loss of size or clarity.  

Those are the effects of choosing those document units and DPI settings in Affinity apps.

Postscript: If one sets up a document in points with a 144 DPI and then goes to export, the 2x pixel resolution is present, but only gets exported as 2x with the @2x export setting.

[R C-R]

1 hour ago, Mark Oehlschlager said:

The Preset for "Web", WXGA 1280 x 800, sets up an artboard where document units are pixels, the artboard dimensions are 1280 x 800 px, and the DPI is set to 72. If that artboard were to be exported out as a PNG, one would get a PNG with pixel dimensions of 1280 x 800.

That is just one of an infinite number of possible export size options Affinity supports. If the intended end use for that export is as a graphic element on a web page, DPI won't matter, nor will the document units you use while creating it. All that does is if the pixel resolution of the exported file is high enough (it has enough pixels) to display that element at the desired sharpness & detail level when the page is viewed with a web browser on whatever device that browser is running on.

There are various ways to achieve this, each with benefits & drawbacks that need to be weighed one against the other to decide which is best for the intended use, but there is much more to this than just choosing a new document preset, whether built-in or custom, or choosing among the export options at export time.

The short version is there is no single "one size fits all" workflow for this. If that is what you are looking for you won't find it, not here or anywhere else. It does not exist.

[All Media Lab]

https://www.udemy.com/course/web-design-affinity-designer-affinity-photo-windows-serif/

Mark, I suggest to follow this course first to clear all things up!

Regards,

David

[thomaso]

@Mark, kann es sein, dass deine Fragen zur korrekten Auflösung daher kommen, dass du gewohnt bist, eine Mindestauflösung für Druckmedien nicht zu unterschreiten – und aber viele Antworten von Webdesignern gegeben wurden, die diese Frage selbst nicht haben?

Wenn ich dich richtig verstehe hast du die Aufgabe, Webseiten zu gestalten, aber nicht zu programmieren. Die technische Realisierung der div. Endgrößen musst du also nicht beherrschen. Und diese Webseiten sollen responsive sein, d.h. ihre Darstellungsgröße + ihr Seitenverhältnis sind variabel, und zwar nicht nur für verschiedene Geräte sondern auch innerhalb eines Browserfenster, das vom User größer/kleiner oder breiter/schmäler eingestellt wird.

Daraus folgt zwangsläufig, das Design wird nicht für jede mögliche Skalierungs-Situation, sondern nur für einige wenige Grenzwerte entworfen, an denen relevante Layoutelemente wechseln, z.B. von 2-spaltig zu 1-spaltig oder von vertikalem zu horizontalem Menu. Die Größen des Designs werden daher selten absolut definiert, sondern für ca. 3-5 Größenbereiche, innerhalb derer das Layout flexibel seine Spielräume nutzt. Diese Flexibilität des Designs gilt auch für die relative Auflösung, es ist also egal, ob ein Bildschirm mit 72 oder 400 dpi anzeigt – entscheidend sind die konkreten Pixel-Maße. Damit der Programmierer aus der Layout-Datei möglichst alle Größen bestücken kann, wird man z.B. beim Designvorgang mit der größten Fläche beginnen und kleinere Varianten davon ableiten. Dadurch wird erreicht, dass Layoutelemente, die nicht Vektor sondern Pixelbilder sind, verlustfreier für jede mögliche Größe erstellt (weil verkleinert) werden können.

Zwar ist es interessant, dass Bildschirme heute mit wachsender Vielfalt an Auflösungen (dpi, ppi) existieren, doch für die Gestaltung der Inhalte ist es irrelvant, weil Geräte mit hoher Auflösung meistens geringere Bildschirmmaße und Pixelgrößen haben und bei geringerem Betrachtungsabstand verwendet werden. D.h. wenn ein Text einer gedruckten A4-Seite in 10 pt passend wirkt, passt er auch auf anderen Geräten, weil Pixelgröße, Betrachtungsgröße u. Betrachtungsabstand zusammenhängen. Fernsehbilder haben heute 1920 Pixel Breite, trotzdem funktioniert diese Bildgröße auch für 3-m große TV-Screens, ohne unscharf zu wirken. Oder Kino: obwohl ein Bildschirm mit z.B. 4K Auflösung wesentlich kleiner ist als eine Kinoleinwand, müssen Texte für den Kinofilm nicht andere Größen (vgl. Auflösung) haben als für den Leseabstand eines Handys, eines Buches oder eines Kinoplakates. Der 10 pt Text wird quasi immer passend mitskaliert, weil der Betrachter entweder näher kommt, oder, bei größeren Pixeln (geringerer Auflösung) weiter weg geht – ganz automatisch.

Ein mögliches Ausgangsformat des Layouts kann also z.B. die für Grafiker vertraute A4-Seite in 300 dpi sein – also ein gängiges Print-Format. Vorteil: für Kundenabstimmung auf Papier können die üblichen Bürodrucker verwendet werden, Designbeispiele können in PPT-Präsentationen passend platziert werden. Oft wird zum Webdesign auch InDesign verwendet, also ein Programm, das die Einstellung einer Dokument-Auflösung weder erfordert noch ermöglicht.

Die spätere tatsächliche Webseiten-Größe ist dagegen selten auf eine fixe Fenstergröße begrenzt, sondern wird eher ein sehr hohes, schmales Format sein, bei dem der User durch vertikales Scrollen den jeweils sichtbaren Ausschnitt wählt. Dabei ist es für den Designvorgang kaum sinnvoll, eine solche Seite in voller Länge zu layouten. D.h. auch für's Layouten nimmt der Designer eine Größe, die ihm und seiner Hardware entspricht. Das geht auf einem iPad so gut wie auf einem 27-Zoll-Portrait-Monitor und die Wahl ist eher eine Frage von Gewohnheit und Geschicklichkeit.

Den nicht zu unterschätzenden kniffligen Part der Übertragung auf scheinbar stufenlos div. Ansichtsgrößen erledigen die Programmierer, die oft auch Webdesigner genannt werden und die Schnittstelle zwischen Layout (Gestaltung) und Hardware-Adaption (Programmierung) perfekt beherrschen. Aus analoger, mittlerweile überholter Grafiker-Sicht sind sie die früheren Druckvorlagenhersteller, Lithografen und Drucker.

Man sieht der Website später nicht an, in welcher Größe sie layouted wurde. 

[Mark Oehlschlager]

@thomaso

Vielen dank für Ihre Antwort.

Viele haben darauf hingewiesen, dass dpi / ppi für Bilder, die für HTML-Webseiten bestimmt sind, keine Bedeutung hat, dass es nur um die Pixelabmessungen der Bilder im Verhältnis zur "device pixel density" der Anzeige geht. Natürlich verstehe ich diesen Punkt und stimme größtenteils zu.

Die Auflösung, das Verhältnis von "Pixel-per-inch", ist jedoch in zwei Fällen für Rasterbilder relevant:

1.) die dpi / ppi des gerätes anzeigen (das muss man einplanen).

Bezüglich der dpi / ppi der Geräteanzeige ist die Variation von dpi / ppi zwischen Geräten groß und ohne universellen Standard. Es ist so wie du geschrieben hast. Es besteht nur allgemeine Übereinstimmung, einige Pixeldichten als 1x, einige als 2x und einige als 3x zu klassifizieren. Für den Designer bedeutet dies, dass alle Rasterbilder mit Pixeldimensionen in drei Maßstäben erstellt werden sollten, um die schärfste Qualität zu erzielen. Natürlich wird das Bild zwischen dem vom Anzeigegerät angegebenen "Device-Pixel-Ratio" und dem CSS-Code richtig skaliert, aber das Bild muss die richtigen Abmessungen haben, um mit den dpi / ppi des Geräts übereinzustimmen.

2.) die dpi / ppi der eigenen Bildsoftware.

Hier stimmen einige Leute nicht überein, aber wenn man die dpi / ppi der Bildsoftware so einstellen kann, dass man Bildausschnitte mit 3x Pixel-Abmessungen exportieren kann, während man das Dokument in einem vernünftigen 1x-Maßstab zeichnet und anzeigt, ist es schöner. Wie du geschrieben hast, ist es möglich, eine A4-Seite mit 300 ppi einzurichten, die für viele Zwecke geeignet ist. In den Affinity-Apps habe ich festgestellt, dass dies möglich ist, wenn man die "Document Units" auf "Points" und die DPI-Einstellung auf 216 setzt (wodurch effektiv ein zugrunde liegendes 3x Pixel-Raster erstellt wird). Man kann dann die "Export Persona" verwenden, um die alternativen 1x, 2x und 3x Bilder zu exportieren.

In Bezug auf das Problem der Anpassung des Designs für eine "Responsive Site" denke ich, dass die Lösung, die ich jetzt bevorzuge, darin besteht, separate "Artboards" für jeden sogenannten "Breakpoints" zu erstellen. So könnte man zum Beispiel die folgenden Artboards in Designer erstellen:

• 960 pt breit (Desktop)
• 768 pt breit (Portrait-Tablet)
• 480 pt breit (Landscape Phone)
• 320 pt breit (Portrait Phone)

Man löst das Design für das Desktop-Layout, kopiert dann den Inhalt auf alle anderen Artboards und nimmt Anpassungen an Skalierung und Position vor.

Was sind deine Gedanken hier? Welche Methode bevorzugst du, wenn du Webseitenmodelle in Affinity entwirfst? Was sind deine bevorzugten Dokumenteinstellungen?

Alles Gute.

[All Media Lab]

Hi Mark,

https://www.udemy.com/course/web-design-affinity-designer-affinity-photo-windows-serif/

I did not give you the link for nothing! Your replies in German still prove you don't understand it.

I attached the grids for you to this post. They come from:

https://hackerthemes.com/bootstrap-4-affinity-designer-grid/

Have a close look at it! They contain the proper sizes as a start and give you a idea how to set it up.

Regards,

David

 

There are two links at the bottom:

bootstrapGrid.afdesign bootstrapGrid_noArtboard.afdesign

[thomaso]

9 hours ago, Mark Oehlschlager said:

Bezüglich der dpi / ppi der Geräteanzeige ist die Variation von dpi / ppi zwischen Geräten groß und ohne universellen Standard. Es ist so wie du geschrieben hast. Es besteht nur allgemeine Übereinstimmung, einige Pixeldichten als 1x, einige als 2x und einige als 3x zu klassifizieren. Für den Designer bedeutet dies, dass alle Rasterbilder mit Pixeldimensionen in drei Maßstäben erstellt werden sollten,

Jain, nicht wirklich. Ein JPG weiß nicht, ob es für 1x oder 3x Pixeldichte gespeichert wurde, und niemand kann das anhand eines JPGs feststellen. Das Objekt hat nur einfach bestimmte Maße, die für verschiedene Darstellungsgrößen geeignet sind. Dabei ist es egal, ob seine 100 px Breite auf einem Desktop mit 72 ppi oder einem Smartphone mit 400 ppi betrachtet werden, je nach Gerät sitzen seine Pixel nur enger beieinander, weil die Gerätehardware kleinere Bildpixel besitzt. Dadurch wird das Bild zwar auf unterschiedlichen Geräten in unterschiedlich groß gezeigt, doch für dich als Layouter ist das egal, weil dort sämtliche Objekte deines Designs entsprechend skaliert werden.

Deine Gedanken sind ein bisschen so, als würdest du eine Postkarte in den Händen halten und dich fragen, bei welchem Betrachtungsabstand die Postkarte in ihrer richtigen, wahren Größe angezeigt wird, um dann festzulegen, wie groß du als Gestalter die Briefmarke anlegen musst. Dass die Briefmarke bei 5 cm Abstand viel größer erscheint als wenn sie vor dir auf dem Boden liegt ist zwar richtig, aber dieser Unterschied ist unerheblich für die Definition der Briefmarkengröße. Zur Gestaltung wirst du sie sogar in einer Größe anlegen und betrachten, in der sie später, im Gebrauch, nie wieder gesehen wird.

Richtig ist aber dein Gedanke, dass Pixelbilder in verschiedenen Größen auf dem Server der Webseite den div. User-Browsern zu Verfügung gestellt werden. Aber ob du die Größenvarianten als Gestalter selbst exportierst, oder ob du dem Programmierer deine Max-Größe übergibst, aus der er div. Varianten nach seinen Vorstellungen ableitet, ist u.U. noch offen und sollte von dir im direkten Kunden- und Programmierer-Kontakt geklärt werden, denn es ist auch eine Frage von Effizienz und Kosten, an welcher Stelle des Workflows dieser Schritt erfolgt. So ist s z.B. möglich, zunächst für den Kunden das Webdesign mit einigen Unterseiten in dessen Desktop-Bildschirmgröße fertig zu stellen bis zur Kundenfreigabe – und alle weiteren Größen erst anschließend in Angriff zu nehmen. Bei diesem Workflow wäre es Unfug, wenn du jedes der Pixelbilder bereits in möglichen Größen erzeugt hast.

9 hours ago, Mark Oehlschlager said:

für eine "Responsive Site" denke ich, dass die Lösung, die ich jetzt bevorzuge, darin besteht, separate "Artboards" für jeden sogenannten "Breakpoints" zu erstellen. So könnte man zum Beispiel die folgenden Artboards in Designer erstellen:

• 960 pt breit (Desktop)
• 768 pt breit (Portrait-Tablet)
• 480 pt breit (Landscape Phone)
• 320 pt breit (Portrait Phone)

Der Breakpoint-Gedanke ist gut. Aber die Erwähnung von Hoch- vs. Querformat und ihre angegebenen Maße drücken noch ein Missverständnis aus: Als müsstest du beim Layouten berücksichtigen, in welcher Ausrichtung der User sein Gerät verwendet. Beim Drehen des Geräts sieht der User aber einfach nur unterschiedliche Ausschnitte deiner Webseite und scrollt sich entsprechend durch. Auch liegen deine 4 Pixelbreiten etwas nah beieinander und die größte Größe ist vermutlich für heutige Bildschirme zu klein. Die 4 Größen von @All Media Lab berücksichtigen eine größere Bandbreite, wobei 1366 px als obere Grenze von heutigen Geräten auch überschritten werden bzw. eine Berücksichtigung zukünftiger maximal-Größen (4K, 8K) sinnvoll sein kann, wenn dein Webdesign über mehrere Jahre und Gerätegenerationen einsetzbar sein soll.

Ich weiß nicht, ob du bewusst Punkt (pt) als Einheit geschrieben hast, – für den gesamten Workflow sind als Einheit der Flächen aber Pixel (px) leichter zu handeln, weil sie ein Umrechnen ersparen. Für Text-Elemente innerhalb dieser Flächen kannst du bei den gewohnten pt bleiben.

Relevanter als Hoch-/Querformat ist dagegen, welche Elemente du als oben/mitte/unten definierst und welche davon eine feste, stets sichtbare Position haben und also vom Bildausschnitt unabhängig sind oder beim Scrollen anders ragieren als andere Elemente. Das kann z.B. oben das Firmenlogo oder das Navigationsmenu sein und unten das Impressum oder ein Menu, das beim Scrollen von oben nach unten springt.

Dieses oben/mitte/unten heißt aus Programmierersicht head, content, footer und kann je nach Inhalt sehr komplex und verschachtelt werden head, content (body, main, aside), footer wobei sich darin auch Teile mehrmals wiederholen können. Die Bennung der zentralen, mittigen Bereiche ist nicht eindeutig, manche Begriffe werden unterschiedlich verwendet oder finden gar keine Verwendung – das ist auch von Vorlieben und Sprachgebrauch des Programmierers abhängig. Mit zunehmender Komplexität des Inhalts und der Navigationsstruktur kann die Anzahl der unterschidlichen Bereichskennzeichungen zunehmen, muss aber nicht.

   >>>  

Dabei ist für den Gestalter leider ein Grundverständnis von HTML sehr hilfreich, besonders auch zur Kommunikation zwischen Gestalter + Programmierer. Das ist aber zu umfangreich, um es durch Frage/Antwort in einem Forum zu erreichen, sondern ist zunächst im Selbststudium (Buch, Tutorials) oder Unterricht/Kurs für dich und das Forum wesentlich effizienter (z.B.: wiki.selfhtml.org, deutsch / www.w3schools.com, english). Als zweites Verständnis-Paket ist CSS relevant, weil damit die Layoutanpassungen definiert werden.

Diese beiden "Sprachen" musst du nicht anwenden können, aber es hilft sehr, die wesentlichen Vokabeln + deren Wirkungsbereiche zu verstehen und zu wissen. – Für den Nachttisch:     1 HTML codes.pdf   ...  1 CSS codes.pdf

Welche Größen du nun als Breakpoints wählst hängt 1. von Kundenwünschen ab (sofern der welche hat), 2. vom Programmierer (der sicherlich welche hat) und erst 3. von deinen Layoutgewohnheiten. Es ist also sinnvoll, die Breakpoints in Kontakt mit dem Programmierer zu klären und festzulegen – wobei du ja schon gemerkt hast, dass es nicht die 1 richtige Lösung gibt.

Es gibt einige Webseiten, auf denen du div. Größen sehen + responsive testen kannst. Hier z.B. siehts du bei Klick auf die lila Geräte-Icons oben-links jeweils die große Bandbreite an möglichen Geräte-Größen (px x px):  http://responsivetesttool.com/

Wenn du im folgenden Beispiel auf "Try it Yourself" klickst + dann auf der Folgeseite den vertikalen Trenner zw. Code/Bild verschiebst, kannst du die ganze Komplexität schön beobachten:  https://www.w3schools.com/html/html_layout.asp

[MEB]

I believe you are missing Mark Oehlschlager's point. He isn't talking about the issues of how images are served and displayed on a browser after coding (or the importance or not of the dpi on those circumstances), just the best workflow in Designer to generate all the assets required from start from the same original design for regular and retina/high density displays at once using the Export Persona so different image/assets sizes can be served for different devices/densities without relying on rescaling a single image version in code alone or rescaling in software several times to get the sizes you need. It's a similar issue as generating several icons sizes from a single design for different resolutions/densities thus the use of points as a logic unit from which the correct pixel sizes are generated for each variant 1x, 2x etc. The approach is described in an article on Affinity Spotlight (here) and shoud clear up what he's trying to achieve albeit for assets on a graphic web design "mockup", not simply icons. Then all assets size variants are passed to whoever is coding the page to be used as they see fit.

[Mark Oehlschlager]

@MEB

Yes. Exactly. Thank you for chiming in. 

Can I suggest that someone at Serif author an article on Affinity Spotlight to make this approach clear. 

Regards,

Mark

[Mark Oehlschlager]

@All Media Lab

Thank you for sharing the very useful Affinity Designer template files for the standard Bootstrap page grids.

[R C-R]

4 hours ago, Mark Oehlschlager said:

Can I suggest that someone at Serif author an article on Affinity Spotlight to make this approach clear. 

Do you mean something other than the article @MEB linked to in his post?

[Mark Oehlschlager]

@R C-R

Yes, just to make explicit how this approach to setting up Affinity documents can be useful for webpage design and the export of 1x, 2x and 3x raster assets. 

I read the article on Affinity document settings for iOS icon design and eventually understood that it could be applied to webpage design as well as to iOS icons, but this concept of setting up a Designer document with Document Units set to points and DPI set to 216 (3x) received considerable pushback from others who work differently. 

An article on Affinity Spotlight that explicitly shows how this approach applies to webpage design would have answered my original question and I probably would not have posted the question to the Forum that has generated so much back and forth.

[R C-R]

1 minute ago, Mark Oehlschlager said:

Yes, just to make explicit how this approach to setting up Affinity documents can be useful for webpage design and the export of 1x, 2x and 3x raster assets. 

Keep in mind that for web page design work you are not limited to 1x, 2x, & 3x sizes, or to just raster image formats. For example. if your AD project file includes placed raster image files, pixel layers, or anything that will be rasterized on export, you may need to work at a higher document resolution than you would if everything is just pixel-aligned vector shapes.

[Mark Oehlschlager]

@R C-R

Yes, that's a good point.

Designer offers helpful feedback in the contextual toolbar when one places an image. See screenshots below.

I placed an image in a 1280 x 800 pt Designer document with a raster DPI of 216. By default the image gets placed at a point size and pixel density (216 DPI) that is consistent with 3x pixel dimension export. If I were to manually scale the image up, the contextual toolbar would report a new DPI for the image that would fall below the 3x DPI of 216. That would be the clue that the raster image at that point size ("Logical Size") would be insufficient to export a true 3x asset.

I suppose that one could decide that exporting out at 2x would be sufficient, in which case one could afford to scale the image up to the point where the context toolbar indicates an image DPI of 144. Or decide that 1x assets are sufficient, in which case one could scale the image up further to the point where the context toolbar indicates an image DPI of 72.

Which reminds me of a neat UI feature I've seen in a WYSIWYG website design app. In that app, you indicate your preferred page dimensions in "Logical" point units, and when you place and resize raster images, a graphic bar gives you instant, real-time, visual feedback about the relative pixel density of the image at its current size, and whether it's sufficient for 1x, 2x, or 3x output.

It's one way of working.