I've developed some iPhone apps before, but I focus mostly on design. When designing in Photoshop, the dimensions are easy for the iPhone: 320x480 and 640x960. However, I'm trying to find documentation on dimensions for Mac AppStore. I'm not sure if there are any dimension requirements, since there are many different Mac screen sizes. What guidelines should I follow for designing? Any resources?
Unless there's a really good reason for your app to work at a single size, you should make it resizeable. You should make sure that it at least works well on a screen size as small as 1440x900, and making it fit on the 11" MacBook Air's 1366x768 screen shouldn't be too hard for most apps. If your app is likely to be used in a multitasking scenario, you should make sure that it works with less than half the width of the screen.
Apple's Human Interface Guidelines specify that Mac OS X supports screens with resolution as low as 800 x 600 pixels. It also says that the display could be rotated for a minimum of 600 x 800 instead. Their advice is to optimize your application for 1024 x 768 pixels, but be resizable for any situation possible.
Related
Todays displays have a quite huge range in size and resolution. For example, my 34.5cm × 19.5cm display (resulting in a diagonal of 39.6cm or 15.6") has 1366 × 768 pixels, whereas the MacBook Pro (3rd generation) with a 15" diagonal has 2880×1800 pixels.
Multiple people complained that everything is too small with such high resolution displays (see example). That is simple to explain when developers use pixels to define their GUI. For "traditional displays", this is not a big problem as the pixels might have about the same size on most monitors. But on the new monitors with much higher pixel density the pixels are simply smaller.
So how can / should user interface developers deal with that problem? Is it possible to get the physical size of the screen? Is it possible to set physical sizes instead of pixel-based ones? Is that still a problem (it's been a while since I last read about it) or was that fixed meanwhile?
(While css seems to support cm, when I try here it, it is not the set size).
how can / should user interface developers deal with that problem?
Use a toolkit or framework that support resolution independence. WPF is built from the ground up to be resolution-independent, but even old framework like Windows Forms can learn new tricks. OSX/iOS and Windows (or browser if we're talking about web) itself may try to take care the problem by automatic scaling, but if there's bitmap graphic involved, developers might need to provide different bitmaps such in Android (which face most varying resolution and densities compared to other OS)
Is it possible to get the physical size of the screen?
No, and developers shouldn't care about it. Developers should only care about the class of the device (say, different UI for tablet and smartphone), and perhaps the DPI to decide which bitmap resource to use. Vector resource and font should be scaled by the framework.
Is that still a problem (it's been a while since I last read about it) or was that fixed meanwhile?
Depend on when you last read about it. Windows support is still spotty, even for the internal apps itself, and while anyone developing in WPF or UWP have it easy, don't expect major third party apps to join soon. OSX display scaling seems to work a bit better, while modern mobile OS are either running on limited range of resolution (iOS and Windows Phone) or handle every resolution imaginable quite nicely (Android)
There are a few ways to deal with different screen sizes, for example when I make mobile apps in java, I either use DIP(Density Independent Pixels; They stay at a fixed size) or make objects occupy a percentage of the screen with simple math. As for web development, you can use VW and VH (Viewport Width and Viewport Height), by adding these to the end of a value instead of px, the objects take up a percentage of the viewport. For example 100vh takes 100% of the viewport height. Then what I think is the best way to do it, but time consuming, is to use a library like Bootstrap that automatically resizes elements, even when the window is resized. W3Schools has a good tutorial on bootstrap and more detailed explainations on any of these options can be looked up with an easy google search.
The design of the GUI in today display diversity era is real challenge. I would suggest several hints, mainly about the GUI applications design:
Never set or expect constant pixel size of the text - the user can change it from the system settings of the OS. Use some real-world measures for the text and check its pixel size when drawing. Provide some way to put the random size text in the boundaries of the window.
Never set or expect constant pixel size of the GUI widgets. Try to position them on the window in some adaptive way - according to the size of the window. Most GUI widget toolkits today have such instruments.
Never set or expect constant pixel size dialog windows. Let the OS to choose the size for you and then use what you get (X). Or, if you need to set some size and position (Windows), define it as a percent of the screen size.
If possible use scalable image formats for the icons. SVG is great for icons actually. Using sets of bitmap icons with different sizes is acceptable, but highly non-optimal as memory use and still will not provide perfect scaling in most cases.
i am building windows store app. I am using windows 8 and WPF with visual studio .net 2012.
UI of this application should be scalable to different screens. I have created a page where the controls (buttons, images, texts) fits correctly when running the app on simulator with resolution 1920 x 1080 for 10.6" screens. The problem is that when i change resolution, controls do not behave correctly
when resolution or screen sizes are increased (ex. 1920 x 1080 for 23" screens) empty spaces are created on the page;
when resolution or screen sizes are decreased (ex. 1024 x 768 for 10.6" screens) controls sizes are increased too and some of them are not visible in UI because they are displayed too far in bottom.
Is there a way to build "scalable" store app which are independent of screen sizes or resolution? Control sizes and font sizes should increase and decrease when resolution change or from one screen to another but all of them should fit in the space and shouldn't create empty areas.
Any help would be very appreciated.
thank you
This MSDN article discusses the guidelines for scaling to screens.
it touches on Screen size, Screen resolution, and Aspect ratio. It provides a table which shows best practices recommended for apps that use scale-to-fit functionality and it touches on adaptive layout. there is a reference to [Guidelines for layouts] at the end of the article as well.
Hope this helps!
http://msdn.microsoft.com/en-us/library/windows/apps/hh780612.aspx
joelcitizen
I'm making a program that will have a widget that has to be fixed in size, is there an industry standard for smallest resolution width?
What are some common way of dealing with this problem?
On traditional PCs (i.e. no mobile, no "custom", no specialized hardware) You usually will not find a display with a resultion below 640x800x256, so that is the "technical" de-facto standard.
However, if you try to design for that resolution, your controls will look ugly and uneconomically designed, wasting lots of available space on real-world platforms.
I'd say 800x600x16 is an absolute minimum requirement. Even windows save mode usually is able to come up with (or can be switched to) 800x600. So I usually design resizeable apps for 800x600, and if done right, they look and behave great under even the largest resolutions. In contrast, if you design a resizeable app for 640x480, you will make an awful lot of compromises in layouting etc. due to the limited space available, and that while "nobody" uses that resolution in the real world.
Furthermore, I love applications that resize intelligently. Depending on your GUI framework/toolkit, that is a requirement that you can be met easily, or not-so-easily. It's worth the hassle, though.
You might also consider the font scaling setting. On large-resolution displays, many users prefer the "large fonts" setting, or something else different from the original font scaling setting. Then, your app must scale accordingly, and the minimum resolution criterium gets less important, while the apps's ability to re-size intelligently gains much more significance.
In short:
a) Design for 800x600x16
a.1) Let your app terminate with an error message if the resolution is smaller than that
b) Make sure all resizeable dialogs resize intelligently
c) Test all layouts on large and small font scaling settings as well
d) When saying "800x600", this is useless, since your app usually cannot use the whole screen, even if maximized. (We are not talking about fullscreen apps, do we?) So you should account for the task bar and possibly other fixed screen elements that cannot be used by a normal Window, and for the window's title bar when maximized. You will want the window to fit into the desktop area in all cases. (Well, maybe you will.) Windows can tell you the dimensions of that area, taking account all task bar etc. stuff that the user might happen to use, so you could alert/abort if the usable space is smaller than your minimum resolution that you designed for.
For PCs (excluding embedded stuff like handphones, wristwatches, mp3 players, washing machines etc..) the smallest resolution is 640x480 otherwise known as VGA resolution.
There may be some PC-class computers like early Macs, Ataris or TRS-80s with smaller resolutions but nobody uses them nowdays. Conventional wisdom says the smallest monitor width is 640 pixels wide.
In the last 10 years a lot of developers have upped the assumed minimum resolution to 1024x768 otherwise known as XGA (btw, nobody calls them VGA or XGA anymore since the mid 1990s). All graphics card manufactured since 1999 can handle at least 1024 pixels as the minimum width.
768 pixels used to be assumed as the minimum height by a lot of developers in the last 10 years until 3 years ago when Asus invented the Netbook category. Most netbooks have a resolution of 1024x600. So a lot of software cannot fit on netbook screens (much to the annoyance of netbook owners).
Currently (since I'm one of those netbook owners) my own standard minimum is 1024x600, that is, 1024 pixels wide vs 600 pixels high (actually more like 560 pixels because I usually have to account for the menubar and the taskbar).
Note: wikipedia has a nice summary of standard monitor resolutions: http://en.wikipedia.org/wiki/Graphic_display_resolutions
Screen resolution has increased in iphone OS4. Since lot of UI stuff have hardcoded co-ordinates, will my app run properly on OS4? I still haven't got Snow Leopard, so cant test run the simulator for OS4.
It is publicly known that the number of points vs pixels is 2:1 so point 320 has 640 pixels in hi-res and 320 pixels in low-res. Low resolution images will be somewhat jaggy, but their positioning on the screen would remain the same.
Most statistics out there for browser stats show you the resolution of the screen.
Thats fine for Windows where browsers typically open full screen and most people leave it as that. So if the browser stats say 1024x768 you just need to subtract a little width for the browser chrome.
On a Mac however browsers typically dont open full screen.
What kind of width is a mac browser likely to be when it opens as such.
I'm thinking of a width of 960 as recommended by what-is-the-best-absolute-width-for-a-webpage. However I'm wondering if this is equally as good width for a mac?
I'm not sure when Apple last made 1280x768 laptops or screens anyway so its probably a non issue. It just frustrates me a little that most places I find statistics on screen resolution dont show you the actual available width.
Design away, my friend. The Apple display packs many pixels.
A window will open to fullscreen on the Mac, no problem. It simply conserves space when it can, unlike the PC behavior, which will fill the screen regardless of how much space the site actually needs.
In other words, the case where the Mac doesn't open the window fullscreen is the case where the user has room to spare. So those are cases you don't need to worry about. If a Mac OS browser has to go fullscreen to fit the site, it will. But when the site is only 960px and the user has a gorgeous 2560x1600 cinema display, it will stop at 960, enough to eliminate the horizontal scrollbars.
The reason people notice this behavior is because apple displays are often too big, so the fullscreen is often not needed. The smallest display Apple ships on any notebook is a roomy 1280x800. The smallest iMac is already 1680x1050. They only get bigger from there.
As far as choosing your dimensions, the normal considerations apply. Play to your lowest common denominator. Simply know that the screen resolution of even a modest apple display will be on par with the industry standard. If you're willing to go 990 or 960 for the PC, it will also be acceptable for the Mac.
(source: akamai.net)
Most of the designers I work with are more concerned with making designs too narrow for Apple users. They design in the 960 pixel realm so that it works for the larger audience, and then they try to find creative ways of showing a little extra love to the owners of that giant cinema display.
Sidenote: #Taylor Marshall asks a good question: "What if the widths are all set to 100%? How big does [the browser window] get..?"
Without any constraints, Firefox will simply go fullscreen, like the MS Windows behavior. Safari will expand up to a width of 800px, unless the width is already greater than 800, in which case it maintains that width and only modifies the window height. Of course, if there aren't any hard width values, then the design is a liquid layout, so the concern about designing for a particular width is somewhat altered. Usually good liquid layouts, despite being displayed correctly at any dimension, are nonetheless designed to be viewed at reasonable window widths.
Instead of fretting about absolute widths, why not do percentages, and give it a min-width so that it doesn't start to look too terribly bad at lower resolutions?
The min-width could be where your 960 or 990 comes into play.
The stats you've read are based on actual screen sizes of visitors. If you're looking for stats on what size the average user's browser is at, you'll need to look elsewhere. Also I never browse full screen on windows or mac OS, and I consider a design that's wider than 960px or so to be very annoying. (it's 2^16+2^17+2^18+2^19)
I'm feeling lucky for browser size. See the second chart.