Making a resolution independent UI(blog.wolfire.com)
blog.wolfire.com
Making a resolution independent UI
http://blog.wolfire.com/2009/09/resolution-independent-ui/
14 comments
Absolutely. UI-scalability is not simply an issue of adapting to display resolution. Also to be noted that different resolutions often come with very different devices, which mean a difference in capabilities and controls available.
I can't speak for device development, but the way in which I've always cheated this was to capture common resolutions, and watch for resize events.
Basically, I would build 320x240.css, 640x480.css, 800x600.css, etc., have an event listener polling for windowWidth, and change to the best stylesheet available. If you were, for example, at 799px width, you got the 640x480 display.
This was, of course, labor intensive, so you don't do this for everything. The last project I employed this on was done many years ago, and HAD TO look good at almost any resolution. This worked out well, except for images (which there were very very few of in this app), but that could be swapped out on resize as well, if you were really had to make it perfect.
Basically, I would build 320x240.css, 640x480.css, 800x600.css, etc., have an event listener polling for windowWidth, and change to the best stylesheet available. If you were, for example, at 799px width, you got the 640x480 display.
This was, of course, labor intensive, so you don't do this for everything. The last project I employed this on was done many years ago, and HAD TO look good at almost any resolution. This worked out well, except for images (which there were very very few of in this app), but that could be swapped out on resize as well, if you were really had to make it perfect.
Everything in this article is extremely common knowledge:
Don't use pixels as absolute measurements and don't scale up raster graphics.
Don't use pixels as absolute measurements and don't scale up raster graphics.
What explains all the bad designs out there then?
Perhaps many people design without having the artistic talent to design. These are well-known design principles, yet without talent, you will still create bad designs. Take me, for example. I do not have the slightest bit of talent for static visual arts. I can't scribble, draw, paint, or design.
So you repeated what was already common knowledge?
I see what you did there!
I see what you did there!
WPF (http://en.wikipedia.org/wiki/Windows_Presentation_Foundation) is supposed to help solve a lot of these issues in desktop apps. I am developing a desktop application with it and so far the results have been positive. Here is an indepth article about supposed the resolution independence of WPF: http://www.wpflearningexperience.com/?p=41
I think I must be missing something here. Don't people set their screens to higher resolutions because they want to see more stuff on their screen.
I always assume that people set their resolutions such that they can read normal-sized (12-14pt) text. If that's too small for their eyes, they would have set their screens to a lower resolution. As someone who likes to see a lot at once, this would probably irritate me.
I always assume that people set their resolutions such that they can read normal-sized (12-14pt) text. If that's too small for their eyes, they would have set their screens to a lower resolution. As someone who likes to see a lot at once, this would probably irritate me.
Yeah, their example goes exactly the wrong way for me. I use Terminal 6 (or XTerm "Tiny") on a 1600x1200 15" LCD, and I don't use Antialiasing because at this font size every pixel counts, I don't need 6 blurry pixels, I need 9 sharp ones.
All of this said, there's no reason why, if they provide proper instrumentation/controls, that I couldn't use a resolution independent display to crank the UI down to tiny size (tell it that I have low DPI) and provide a lot of screen real estate.
All of this said, there's no reason why, if they provide proper instrumentation/controls, that I couldn't use a resolution independent display to crank the UI down to tiny size (tell it that I have low DPI) and provide a lot of screen real estate.
It is for monitors with a higher DPI
These guys do some pretty cool things, here is a video of procedural animation in Overgrowth (the same game this blog post is about):
http://vimeo.com/2360652
I'd like to see a writeup for the WebKit / Awesomium integration.
http://vimeo.com/2360652
I'd like to see a writeup for the WebKit / Awesomium integration.
I have been waiting for 10 years now for screens with significantly higher DPI. Remember how the NeXT was the first computer to go to 96 dpi?
I was hoping for 150 DPI on screens ("paper quality" at the time was defined by laserprinters doing 300 DPIs, so 150 for screen sounded good enough). Never happened.
Would it be useful? After all, what do you think is an HDTV? smaller pixels, higher resolution.
I was hoping for 150 DPI on screens ("paper quality" at the time was defined by laserprinters doing 300 DPIs, so 150 for screen sounded good enough). Never happened.
Would it be useful? After all, what do you think is an HDTV? smaller pixels, higher resolution.
high DPI screens were never developed because scaling UIs was a pain. Scalable UIs were never developed because most screens cluster around the same DPI value.
There doesn't seem to be any elegant way around this problem unfortunately.
There doesn't seem to be any elegant way around this problem unfortunately.
- UIs tend to depend on things lining up, in order to look good. If you allow any scale, at some point things will not look quite right. One decent solution is to choose fixed scales, limiting what the user can choose; then, everything is (perhaps manually) made to work at those zoom levels.
- Detecting something like a mouse click is no longer the same problem at an arbitrary scale. If you need to know "was this clicked?" when using pixels, you're only talking about mapping one pixel to a region that is expressed entirely in units of whole pixels. But at an arbitrary scale, neither the mouse nor the target shape will "appear to" be rendered with whole pixels.
- In order to scale, everything must be scaling-aware. This turns out to be a pain, especially in established code that is accustomed to thinking in terms of a rigid pixel grid. You can see this problem, say, in Windows XP; while it allows users to customize system fonts extensively, it's pretty easy to find an installer or other program that didn't leave enough space (and wasn't thinking in the right terms), causing half the text to be truncated when a certain font and size are used.