Help - caught in a web of responsive + retina confusion!
I'm a freelance graphic designer who's starting to get more into responsive website design and design for retina and there are some things that I'm not entirely clear on when it comes to setting up PSDs, particularly with regard to screen size and resolution.
I've been mostly working with already designed PSDs (just helping out by updating their already designed pages) - but as I'm working on more responsive projects I'm finding that each project seems to be different in that some of them are designed at a really high dpi and screen size while others are just a standard 72 dpi ( and I'm presuming are just being saved out / sized up for the developer at 2x (200%)?)
Could someone settle this for me once and for and tell me what the best and most current / correct dimensions AND dpi to set my PSDs up to?
Any help would be super appreciated!
I do not have any direct experience of retina devices (or anything Apple for that matter), so I have left it to others to comment. However, as no one has done so, I'll offer some thoughts...
I use responsive techniques to develop for a wide range of devices, not any one (retina or otherwise). The only concessions are to provide graceful fall-back for legacy browsers (IE8 etc.), and the minimum of browser-specific syntax for CSS3 features that require it. So I see neither need nor purpose in writing specifically for retina devices.
Indeed, to do so is to pander to Apple's marketing strategy, which from the early 80's (before the web existed) has always been to fragment the market in computing devices by deliberately introducing incompatibilities, thus protecting their market share from direct competition.
There is no meaning of DPI on a screen - it is a print thing. Whether an image has 1000dpi or 72dpi, it will display identically. So I've just eliminated half your problem. You only need to debate about dimensions, which is a hard enough problem to tackle
I think it is an over-exaggeration to say "there is no meaning of DPI on a screen". Screens have a combination of pixel count and ppi (which correlate to dpi). What I think you are referring to is the fact that browsers auto-scale images to fit the given dimensions, but that does not make a 640x360px image the same as a 1920x1080px one when displayed on a Full HD screen.
That's not what I mean. Pixellator is referring to psd files "designed at 72 dpi" or "high dpi" and asking what dpi (and resolution) he should be designing at. He's talking about image files, which can be set to certain dpi. The dpi of those image files is irrelevant for screen display. The overall size if the image (e.g. 640px wide) is the only relevant item to debate and decide.
Yes, the screen itself has a concept of "dots per inch" or preferably "pixels per inch" but that is completely unrelated to the psd file dpi asked about.
I've reread the OP and agree that the term "DPI" was used in a sense that is meaningful only when printing.
Welcome to just ANOTHER reason I say that screwing around drawing goofy pictures in Photoshop is NOT web design. Making some layered PSD before you have semantic markup of content of value and a working HTML/CSS layout is putting the cart before the horse and a completely back-assward way of building a website, no matter how many PSD jockeys who know absolutely NOTHING about HTML, CSS or accessibility claim otherwise.
Responsive layout, like every other stepping stone to building an accessible website -- like dynamic fonts, elastic layout, and semi-fluid layout -- puts to lie that very practice. The simple fact is that what it happens to look like on the display in front of you -- REGARDLESS of what that display is -- has little if anything to do with what everyone else is going to see. That's why WYSIWYG's are nonsense, and it's why pushing pixels around in some paint program has nothing to do with sane and rational design.
1) Take your content or a reasonable facsimile of future content and put it into a plain text editor.
2) Put that content into a logical order as if HTML never even existed.
3) Add HTML saying what things ARE, NOT what they look like -- aka numbered headings or horizontal rules as section breaks, numbered headings indicating what is a subsection of what, paragraphs around actual grammatical paragraphs (and not things that aren't paragraphs like single images or somethign that just happens to be text), ordered and unordered lists around things like menus or lists of short bullet points. (as in grammatical bullet points, not things that happen to have bullets before them!)
4) Bend that markup to your will to create the layouts; (YES, PLURAL) markup and content dictating the layout NOT the other way around. Said layouts should be:
elastic -- auto-expanding off the broswer or OS font size, which is NOT consistent across platforms or user preferences!
semi-fluid -- no fixed width overall with a max-width to prevent long lines of text from being hard to read
responsive -- auto-adjusting the number of columns and swapping out the layouts so as to best fit the CONTENT to the available screen space.
Then and ONLY THEN would paint programs like Photoshop have any business being used to hang graphics ON that layout -- if any with CSS3 now in the mix.
Unless you're going to sit there for months making THOUSANDS of different possible combinations, you're not going to get that dicking around with pointless PSD "template" asshattery. It's a mind-numbingly dumb way of trying to build a website, and the people promoting it are usually doing so either out of ignorance, or just flat out being scam artists not qualified to actually be working on websites in the first place; using flash over substance to dupe people with checkbooks and zero knowledge into writing a big fat check in their ignorance on just how badly they are being ripped off.
Last edited by deathshadow; 09-19-2014 at 02:08 PM.
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Tags for this Thread