Question: What would be the ideal image dimensions pertaining to newsletters delivered to mobile devices?
Background: I need to provide dimension specs to my graphics designer so we can deliver specific images related to the mobile device (using media queries).
Target devices are: iphone 3.5" , 4", iPad 10.1", iPad Mini, Android devices - Galaxy Nexus, Note, HTC One 4.7"
Thank you for your time answering my question.
This really depends on your layout. Are the images going to be full screen width? Padding? A general rule in design is to make it big because you can always downsize without losing quality. If there is even the tiniest possibility you would need these images for something bigger, create them big or in vector graphics.
There is also the issue of retina display. If you want to cater to this you need to double your image resolution, however this makes the email slower to download. There is no correct answer, so it depends on your target audience as you'd be benifiting retina displays but putting out the rest of mobile users.
Related
We’ve had a recent issue with some asset images, where the Retina #2x version was being used on non-Retina devices. The Retina and non-Retina versions of the assets exist. We’ve tracked the problem down to compression, so we’re able avoid it for now, but if anyone has additional insights, I’d love to hear them.
The icons on the left show how they’re rendering inside the running app. The Retina assets are being used on a non-Retina screen, so they’re being scaled down to 50%, which is causing some blurry edges.
The icons on the right are the original assets.
This is only happening to some assets. Most of the app is okay. We’ve been using ImageOptim to compress the PNGs used in the app. ImageOptim is using a variety of compression combinations for the assets. These are the common best results:
PNGOUT
PNGOUT+AdvPNG
PNGOUT+Zopfli
AdvPNG+Zopfli
The assets that have problems all seem to be using PNGOUT+Zopfli, but not all assets with PNGOUT+Zopfli are bad. I am not 100% confident with this diagnosis though.
Given that the issue isn’t always easy to spot, and given I don’t know exactly what’s wrong, we’ve unfortunately decided to not compress our new PNGs used in Mac apps. This is a shame, because the space savings are good.
We’ve tried a few different Xcode project settings, including turning Combine High Resolution Artwork on and off.
I’d like some answers, but I am also posting here so there’s some information that may help others with this issue, even if I only have a partial solution.
Have you seen this issue before?
If you have seen it, do you have a solution?
By default, NSImage representations are chosen using color type and resolution [1]. In case of PNG files, there are situations when a more generic color type gives a smaller file. This is what causes the mixed color types between representations.
You need to set prefersColorMatch to NO. There are User Defined Runtime Attributes to do it without leaving Interface Builder. This will fix the issue.
How to set prefersColorMatch in Interface Builder
More information about the bug can be found here:
OS X doesn't like mixed types of PNGs.
Retina version of an image always used on non-retina display
It looks like there is no solution, except to force the same color_type for the PNG pairs.
I've developed a WinJs app for the Surface pro 4. The app Runs in fullscreen and is layoutet with the screen resolution of 2736x1824 (surface resolution).
Now when i start the App on the surface the DPI scaling comes into play and messes up my Layout.
Is there a way to disable the scaling for the app?
I've tried:
Windows.UI.ViewManagement.ApplicationViewScaling.trySetDisableLayoutScaling(true);
but that doesn't seem to work.
Actually, making your app layout only for one resolution, especially for such a big resolution is not really great idea since the app can run on device with, for example 1920x1080 resolution where even with DPI scaling disabled your layout will be messed up.
So I recommend making the app layout responsive so it will look right on every resolution.
Not sure if you're still looking at this issue but I've found that the code that you see all over the place is actually XBox only (Link To Docs)
And the Microsoft Devs have been saying for a while that it's a user based setting and they don't plan on allowing you to ds(Forum Link)
You can detect the scaling value though with ResolutionScale (docsLink)
Windows.Graphics.Display.DisplayInformation.getForCurrentView().resolutionScale
Here's a link to a sample that detects it and adjusts.
So what you can do (and what I did) was where needed I used css scale to adjust the system to fit. Most of my app is responsive so it didn't matter, but if you use an iFrame and set it to be 1000px wide with this scale factor it will actually be 1400px or even 1800px wide and totally cut off..
I have listeners setup for the resize events and just adjust as needed.
Hope that helps!
-Dennis
I just developed an app for mobile and in the process of upscaling the UI layouts to tablets i.e xhdpi resources. But, the problem I face is that I have to restrucure a lot according to xhdpi screen and have to use different images as the image resource doesn't scale up with good resolution. Is it a good practice to have all images in common drawable folder with higher resolutions and resize it accordingly in different layout types. This also makes me wonder, should we have to consider tablet first design and then move to mobile.
It's not the good idea to have all images in common drawable folder with higher resolutions. Why? Rescaling overhead. I think that tablet and mobile design should be considered concurrently.
I am writing an app and willing to package it for different BlackBerry devices with different properties/features and resolutions.
My problem is how do I go about creating a DeviceConfigurationManager that will give me device specific properties/paddings/margins/resolutions etc? I have read here on SO about using Ui.UNITS_pt for fonts, having multiple images for different resolution devices and other things that has helped me in designing my DeviceConfigurationManager . For example in my buttons I have used margins and so for various devices I kept one device as a reference and relatively returned margins for other devices on width(Display.getWidth()>320) check. But I have seen I still don't get exact perfection for other devices (Buttons set centered for the base device doesn't also get perfectly centered for other devices). Please suggest some other or a better way about designing my DeviceConfigurationManager class. Thanks a lot.
Can't offer too much help - but plenty of sympathy. If you're developing for the BlackBerry Java OS you're just going to have to get used to having lots of boiler-plate to handle the different devices. I suspect you do the same as me; have a class that runs on startup, reads the screen size and then sets all kinds of static params for font sizes, padding etc etc.
On the iPhone, we design applications around a standard screen size of 320x480. Is there a standard screen size we should use for developing Mac applications, specifically ones targeted to the Mac App Store?
You don't. Desktop computers don't have a fixed size like phones do. Users could have a screen (or two or six) with a resolution anywhere from 800x600 to 3200x2400 or more.
Instead, design your application to be dynamically resizable. Allow the user to resize windows by dragging their corners to make them as large as they want. Ensure that the layout of elements is fluid, and that they move/resize accordingly as their parent window is resized.
Whatever you do, do not try and lock your users into a particular resolution or window size. They will resent it, and your app will not be very successful. You need to abandon the iPhone model when developing Macintosh applications. There are some similarities, but also lots of important differences.
Examine the other applications on your computer, and see how they behave. Good examples are the applications Apple bundles with new Macs, like iTunes, iPhoto, TextEdit, Pages, and Keynote, among others. Certain third-party companies also design award-winning software applications, like Panic's Coda, Fetch, and even Microsoft Office. Hard to go wrong by following their example.
For all modern macs, at least 1024x768 will be usable screen real estate (the actual screen will be larger, but you need to account for menu bars, 16:9, etc.). Still, this is generally not a good question to ask - you should probably have dialogs that look good at 800x600 and scale larger at the very least - most people like to be able to arrange their windows to their preferences, and if you have a large minimum size that will be very annoying.