aspect layout design

[lkjdfaslkdfas]

When designing for dps 2015, does anyone have any tips regarding card design?

are you natively designing your cards for 2048x1536?  anyone know of any grids for photoshop that could help?

[rperez_bonnier]

Yu can make your own Photoshop document and replicate the grid you'd like to set up beforehand.

Personally I would use inDesign. Just quicker and easier to work with I guess. Plus, you can have pages and/or layers in the same document that constitute content that you can then export as .article files.

And...

I recommend using 768 x 1024 as your document size. I believe that is what the app is using. I could be wrong but I believe content is upscaled on retina devices. This is similar to the reason why, when you're setting up responsive HTML you use 768 as the min-screen-width of the CSS media query classes that target tablets.

Set up the document rulers to show pixels. Then set up the number of columns, top and side margins, and gutter values in pixels as well.

[lkjdfaslkdfas]

thanks for your response.  Are you just scaling up your photoshop work 200% when saving your pngs then?

[Neil_Enns_-_Ado]

We will downsample as necessary when retrieving the image for display to avoid large download times. Best thing is to save as a good high-res image (i.e don't save as 200x200px!) so we have lots of good image data to work with when we need it.

Neil

[rperez_bonnier]

Yes, as Neil points out, images meant the be displayed as collection images in card layouts should be saved as large as possible. In this case, yes by all means think of 1536 x 2048 and use larger images. It's a bit confusing but after working with this setup for a while it will be second nature.

The Layout where the cards are displayed should be thought of as 768 x 1024. Is this correct Neil? I would not like to have that information mixed up.

[Neil_Enns_-_Ado]

You shouldn’t think of the layout as having any specific pixel size nor aspect ratio. It will vary depending on what type of device you target.

Andrei, our expert here, will likely chime in tomorrow with additional thoughts.

Neil

[rperez_bonnier]

Thanks Neil.

I know device pixels are relative to the device they're being displayed on and they're hard to pin down or think of as fixed, but they way I see it, it's best to pick a starting point or reference point.

For example, when setting the side and top margins, or the gutter width, it's easy to think of 20 pixels in a 768 x 10424 display, and know that the app will double that in a device with a display that is 1536 x 2048 rather than the other way around and have to split values in half in my head. In this case they're space (read: empty) pixels and not actual pixel data in an image. Same with the column widths. It's just space measured out in a grid and scaled up based on the device and display.

The images however, do have fixed pixel data and pixel dimensions. And the app can down-sample or down-scale when needed. However it cannot add pixels to an image that already has a finite number of pixels and therefore images look fuzzy and pixilated when enlarged (same with print btw). That would be why it is best to supply as high res (large size) images as possible (same with print).

Looking forward to Andrei chiming in with his thoughts.

[lkjdfaslkdfas]

I agree... I have been trying to refine my design (browse) pages inside of photoshop.  I have been natively working in 2048x1536 dimensions.

Still having major issues with how things show up on my browse pages.  It's like there is a bug or something.

I design a card to be (2) Columns Wide, and 1 row high.  Made sure that there are no other "cards/preferences" active or applied... and still... my card shows up as 1x1 card.  doesnt make sense. pulling hair out.

meow.

[Colin_Fleming]

IMO, just designing a card image at 2048x1536 is missing the process.

Sure, if you're designing a collection background image, that might make sense because that image fills the screen. We do some scaling, likely to fill the screen -- so you want a big image for the big treatment.

But for cards, you should consider how the image will be used, and this should likely influence what you do.

Do you really need a 2048x2048 image for a card that's always going to be 1/4 the width of your screen? IMO, probably not. But some would say "just make it big, DPS will resample it on the fly" -- and that is what happens. So a big image provides flexibility and isn't a bad idea all by itself.

I think though, that understanding what will happen to that image is really important. If that card image (for an article, banner, or collection) will appear on more that one card designs or more than one layout, you have to build a flexible image. Size or dimension may help, but perhaps your card image's aspect ratio is also important. A square image is likely more flexible if it might be used as both wide and tall in different cards or layouts. But if you know you're designing a card image for content that will only use one card (maybe a banner is always full width and two rows and you won't change your layout) then it might be appropriate to design the card image to match this particular use case.

So what controls the image?

The layout's aspect ratio.

The card dimension.

The card format and image aspect ratio for 3 of the 5 card formats.

And what happens to the image?

The image will appear in the image area of a card.

The card can have one of four formats with a card image (full, top, left, right) and all but full have an aspect ratio for the image on the card.

The card format and aspect ratio control the "crop" or "frame" for the card image.

DPS will scale the image to fill the image area, center the image, and crop all pixels that do not show. DPS also resamples in this process.

So a big image provides flexibility, but you also have to design an image that will withstand the scale/center/crop process.

HTH

[rperez_bonnier]

Sorry I'm not sure that I was totally clear.

‌I did not mean to recommend that folks use 1536 x 2048 for their card sizes but rather to think of 1536 x 2048 as full screen when sizing images. In this case yes, like you said Colin, a full screen card would be 1536 x 2048. That would be quite a card! So yes images should still be sized based on the number of columns (and perhaps also gutters) that you would want the image to span, but the reference point is 1536 x 2048 if you wanted a full screen image and you crop away from this size. And yes, remember that the image can then be cropped when displayed in the app based on the aspect ratio that you assign to the image container when generating a card layout. A square image can end up cropped to a rectangle.

I like to think of it as assigning a size/resolution to the layout itself, and attaching another size/resolution to the images:

A - Layout is 1x and full screen is 768 x 1024 (at least because it can scroll and be taller than 1024).

B - Images are 2x and full screen is 1536 x 2048 (double the size/resolution of the Layout (A).

Works for me!

Sorry I didn't mean to cause any confusion folks!

[andreig1004688]

Lots of activity on this thread .

1. On image resolutions:

Use largest assets available, and keep in mind in working with images in DPS2015, it's the aspect ratio that matters in their positioning, and not their pixel size. We encourage the use of large images so that when higher-res devices are out there, you don't want to re-upload all article assets to avoid fuzzy pixelated images. Colin did a great job explaining above how the various settings influence the image and the way it is cropped.

2. On other card/grid margins/paddings:

Here you have 2 options.

* Use a fixed value in dip (whatever the device knows as "pixels") . As mentioned above, for Apple devices it could mean the actual pixel size is in fact doubled ( @2x ) to match the retina display.

* Define the values as % of the parent container (e.g. 50% margin top for a metadata group means that the metadata group would fill the lower half of the card)

Depending the responsiveness you want in your grid, you may choose fixed values, relative(%) values, or a mix between the two.

3. On grids

I generally advocate for a more finer-defined grid because it gives you more design flexibility. A 12 column grid would work most of the time, but for simpler designs for the phone for example you may use coarser grids.

4. On metadata/mapping rules

Make sure your layout engine is set-up to follow concrete content metadata and not vice-versa. E.g. don't tag an article as a "2x2" internal keyword because you want to display it in a certain card. I'd recommend you take some time, step back and think what content you would like to publish, how you want it to be distinguished, what kinds of content you want to emphasize. Then enhance your content with the relevant metadata and build your layout system from there. This way you'll ensure that with future design-updates you won't need to edit content metadata as well.

And on process there were some good remarks above, use whatever tool you want to quickly mock-up some expected end result. But don't dwell too much in there - switch over to the layouts&cards system early and tweak your designs in there, preferably accompanied by a preflight app. There's a more visual way of authoring layouts coming soon as well. Stay tuned for that!