Android has a nice way to make screen elements scaleable so they look good on most devices. One of those is Device Independent Pixels:
basics of device-independent-pixels
Is there anything similar to dips on Windows Phone 7?
What about autosizing a control to its contents? Such as width=wrap_content?
Thanks!
WP7 devices always have the same resolution so you shouldn't need to worry about DPI.
While devices can have different physical sizes they shouldn't differ too much. If you are really concerned you shoudl simply design and test on devices with the smallest and largest physical sizes.
If you still run into issue then it's probably due to trying to put too much on the screen. If that's the case then you should redesign the app.
One of the original design objectives for WP7 was to create a platform which did not suffer the consequences of device fragmentation such as wildly differing screen sizes and resolutions. As such there is no need to have to code for them.
NB This is the case for WP7, however WP8 supports 3 resolutions. For details on how to support WP8 see http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206974(v=vs.105).aspx
Not sure if that answers your question, but the Grid control is usually the best approach when you want to create a layout that adapts to different sizes.
I don't know of an equivalent to Android's device-independent pixels, though.
Related
I have a personal project designed for the desktop that I previously created in Adobe XD, and now I would like to put it on Behance. To do so, I need to adapt the layout, designed for the desktop, to mobile.
I don't usually design for smaller screens, so I am wondering how much I need to decrease text and element sizes? For example, if I have a text with a font size of 40px, what calculations should I use to decrease the size for mobile? Is there a default percentage to reduce desktop values? Alternatively, are there visual rules that other designers follow?
I always design for Bootstrap, but I'm not sure if I am thinking about mobile the right way.
I've also posted this on the User Experience Stack Exchange forum, but I'm not sure which one is the best for my question.
Thank you for sharing your thoughts and advice.
I have designed mostly for desktops as a traditional web designer, and now I'm trying to migrate to UI/UX.
Modern devices do most of the scale conversion work for you by adequately scaling the viewport to compensate for the smaller screens and often higher resolutions. Depending on the type of application you are designing, the technology is different, but the result is very similar.
For example, if you were implementing the design for the Web, you would likely need to use browser features like media queries to manage your content.
However, because you are focusing on the design of the site, you should not need to worry about the 'how', so you can focus on what to do.
Here are some tips:
Elements and text appear roughly the same size on desktop and mobile if you hold the device at a casual but comfortable distance and compare it to the size it appears on your desktop's screen at an average viewing distance. You can try this by going to a website built for mobile like Apple's.
Because of the similar size but reduced screen dimensions, you need to simplify your design, avoid multiple columns (especially for phones).
Because you see a smaller portion of your design at once on mobile, there is less need for significant visual hierarchy. For example, if you have multiple heading levels with a significant visual size difference on the desktop, you can probably get away with making them closer in size on mobile.
If you want to see what your design looks like on mobile, try emailing the design to your phone, save it to your pictures, and load the image full screen. You may need to zoom the image in a bit so that the left and right of the design are touching the sides of your phone's screen. If your text looks too small or your elements are too large, adjust the design and load it on your phone again. Keep doing this until you get it right.
With a little practice and effort, you will get the hang of Mobile design. And, if you want to take it to the next level, try researching mobile first design. Here is just one of many articles on the subject.
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.
While I have some experience with the WinAPI I do not have a ton, so I have a question for people who do have much experience in it. My question concerns what the limit of our power is. Can we change how windows fundamentally displays?
For example, can I cause windows to render a screen size bigger than the display and pan across it, kind of like workspaces but without separation? Can I apply distortion to the top and bottom of the screen? If distortion is not possible can I have an application mirror what windows is displaying with very little delay?
The biggest question I have is the first one, because if I can make windows render virtual workspaces and pan seamlessly between them then I figure it is possible to make a separate application which handles the distortion on a mirrored image of the desktop. Again, apologies for the vague questions, but I really want to know if we are able to do this stuff, at least in theory, before I dive deep into learning more on the API. If the WinAPI does not allow it is there another way to do this kind of stuff in Windows?
EDIT: Some clarification. What I want to do is basically extend the desktop to a very large size (not sure on exact size yet), both vertically and horizontally. Section the large desktop into workspaces of a specific size which can seamlessly be transitioned across and windows moved across. It would transition workspaces based on a head tracking device and/or mouse movement. Note that when I say workspaces this could be achieved by zomming in and then panning the zoom as well. I also need to be able to distort the screen, such as curving the edges, and render the screen twice. That is the bare minimum of what I am wanting to do.
Yes, you can. The most feasible way I come up with is using a virtual graphics driver (like what Windows Remote Desktop does, which creates a virtual graphics card and a virtual display). Sadly you will lose the ability to run some programs needing advanced graphics API (such as 3D games, 3D modelling tools or so).
There're some examples:
http://virtualmonitor.github.io/
https://superuser.com/questions/62051/is-there-a-way-to-fake-a-dual-second-monitor
And remember Windows has a limit on display resolution (for each and for altogether). I don't remember the exact number but it should be less than 32768*32768.
(Sorry if I missed the answer)
So I just started out making an XNA game for windows.
And while designing the UI, I was wondering how to scale the UI at different resolutions.
So, imagine that I make a UI for a 1920*1080 screen, how do I make sure this is displayed correctly on a smaller 4*3 screen?
Thanks in advance!
Simon.
Usually one designs the GUI in a way that will be usable in the lowest resolution your game offers (traditionally 800x600), then you are sure everything fits correctly at all resolutions.
This is usually why games at higher resolutions seem to have a lot more space for the "playfield" and less for UI than at smaller resolutions.
You could scale the UI once the resolution is higher as well, as easy as using the scale parameter on SpriteBatch.Draw, or you could do it a bit more smartly, by having your assets 9-sliced and aligned to WIDTH/HEIGHT constant percentages.
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