I read and article talking about moving beyond 960px width for websites. This width is considered optimal since it is divisable by 3, 4, 5, 6, 8, 10, 12, 15, and 16 (no these aren't the Lost Numbers ;-) ) This helps in grid placement and this really doesn't apply to Silverlight apps but I started to wonder what would be optimal.
What would you recommend as the optimal resolution for a Silverlight app?
I'm thinking 960 x 720 would be in the range of almost every monitor out there.
Or maybe the next step down 720 x 540?
The optimum for a Silverlight application would be whatever the user has the resolution set to - the application scales accordingly.
Refer to this MSDN article for more information.
Personally, for the type of apps I do, I wouldn't bother to try and support people with less than 960px of available space. There is always going to be somebody with outdated tech/monitor size...and 960 is probably going to cover 95% or more of any target audience for me.
One thing you need to be careful of is that a lot of laptops have a maximum vertical resolution of 800 pixels, and once you add the title bar, toolbars, start menu, status bar, etc. you're actually very easily below 600 pixels for vertical screen space. It can be even worse with netbooks. I've seen too many Silverlight apps that are 600 pixels or more vertically and they get cut off because the div isn't set to the proper height to make the page scroll.
I agree with Anthony that you should just let the app resize itself. Just make sure that the app and all of the controls scale well (nothing gets cut off or stretched too big or too small) when going to a really small size to a really big size.
Related
I am about to deploy my first React Native application to the iOS app store. I am having a problem however when it comes to layout. I am utilizing the flexbox system and currently designing for iPhone 6. I have done all the mockups and Sketch and have everything how I would like it to look.
I have run into a problem however whenever I try to run the application in iPhone 4. The design that I have implemented for the iPhone 6 does not fit with the constraints that iPhone 4 possesses.
I can try to redesign things for iPhone 4, but then things become too small / ugly on the iPhone 6. I really need things to look great on all of the screen resolutions (i.e., iPhone 4 - iPhone 7 plus).
I have seen on the web many different solutions: apply a constant to each stylesheet value, dependent up the aspect ratio of the device; check the device and render different components based off the device your are on; and make better use of flexbox in order to make the layout responsive.
The first solution doesn't seem like it will give an accurate representation on each screen size, the second solution seems to create too much excess code just for styling, and the third solution seems to not account for static sizes and font sizes.
I normally would begin to follow the third solution, but there are some things that can simply not be a percentage of the container (e.g., button height, font size, some margin and padding, etc.)
Therefore, I am asking the question: What is the best way to approach this problem in React Native? I really need a thorough de-facto answer that can explain the best way to go through the development process as well (e.g., should I design for the smallest screen size and then fit it to bigger sizes? should I design for all resolutions? etc.).
A big thanks in advance for those of you who have felt my pain and have discovered a great solution, please let me know what that solution is.
Ok, so I think i understand how to go about doing this now. It looks like the key for designing for multiple screen sizes in iOS is not to necessarily make things bigger on bigger phones and smaller on smaller phones, but to design for what works on the smallest screen size, and let the items look small on the bigger devices.
It seems that the idea behind this type of responsive design is that individuals with bigger phones desire to see MORE CONTENT, not blown up content. Therefore, if it works on small phones, it can also work on big phones.
Take buttons for instance: If a button at 40pt looks good on an iPhone 4s, it will also work well on an iPhone 7 plus. The benefit is that the user of the iPhone 7 plus is able to see more content, rather than just a bigger button.
This design also makes it to where multiple screen sizes are not necessary for styling.
There is still a role in determining the dimensions of the device you are on, but this is more to determine whether you are able to display more content (e.g., in the case of iPhone 5 vs iPhone 6, whether or not to display an additional tab button), as well as the layout (e.g., where should I place the menu).
You can see this type of design on most of the very popular web application native apps.
Images and videos are one of the only exceptions. It seems that it is helpful at times to automatically grow the images whenever the device and the design call for it. Fortunately, this is very simple by using a flexbox and responsive technologies as are included with react-native.
I hope this helps others and saves them some time. Note: this does not provide for the problem of landscape vs portrait. Under that situation, it is probably best to use some sort of varying styles.
I have felt your pain and choose a similar solution to your first one also similar to the blog post mentioned by Shukarullah Shah. In my style.js file first I obtain the device width and height using;
const x = Dimensions.get('window').width;
const y = Dimensions.get('window').height;
Then I divided each dimension, x and y, to 10, 20 and 40. For width, it become like;
const widthS = x / 40; // ~10 px
const widthM = x / 20; // ~20 px
const widthL = x / 10; // ~40 px
Then I use these values to define any size for margin, padding, image size etc. Also I use a common style.js file for each component I have. So that I define these constants once and I can see/compare every style piece I have easily. Of course you can improve these kind of definitions like in the blog post mentioned. But I am a developer not a designer so that I am not so edgy about perfect ratios.
I have read useful blog on medium about Responsive Design in React Native. I did not get time to try it but I think it will solve your issue, let me know how it works for you.
if i put everything in viewbox container then my wpf apps will be resolution independent or do i need to do anything else. please help with concept.
Scale elements accordingly to the available screen or medium size
If your desire is, to allways fill some room of the screen or output device, independently of the metrics, using the viewbox is a good choice. If you have a big monitor, you will have a big element, if you have a small paper, you will have a small print out of the same element.
With the Stretch-property of an image you have a similar possibility only for pictures.
Make elements on every device equaly sized
WPF is designed "resolution independent". The goal of this resolution indepency is, that if you design an element to be 15 inches, then it will be on every output medium this 15 inches, independently of the resolution of your output device. Calculaction and specification of dimensions is done in "device independent pixels" (DIP) which you can convert to centimeters or inches without having specific knowledge about the output devices resolution.
96DIP == 1inch == 2.54cm;
1 inch == 96DPI;
1 cm == 37.8DIP;
If want to use this resolution indepency, you can set fixed values (in DIPs) to your elements. On a large monitor then your element then maybe only uses a small part (e.G. 15inches), and on a small monitor it fills the whole screen (also 15inches).
WPF is resolution independent without any extra tricks at all. If you host legacy controls (non-WPF controls) then this may break for them, but WPF itself is resolutions independent and vector based.
Viewbox has nothing to do with resolution independence.
Resolution independence means, controls you specify can be drawn on different resolutions while keeping scale. So you can use display that has 10x bigger density of points, but controls will still look same to you.
And like it was said, WPF itself was designed with this in mind, you dont have to do anything.
Is it possible to decrease the default width of a Panorama control's PanoramaItems?
They can be made wider by specifying Orientation="Horizontal" and a width larger than 432. However, specifying a width less than 432 does not result in a smaller PanoramaItem. It's minimum width is 432 always.
I played around with the templates but couldn't figure out how to achieve this.
I'm afraid there isn't anything you can do about that. The Panorama has the width of its items baked in as 48 pixels less that its own width.
PanoramaItems are not designed to have a smaller width. If you wanted to do this you'd probably need to create your own version of the Panorama control.
Don't do this though!
Not only would it be a lot of effort to get right you'd break user expectations about how the panorama would work.
Would/could you allow multiple items to be displayed at once?
What would be the impact on navigation?
How would you communicate to users that your app works slightly differently to all the other ones on the phone?
How would you justify the mental cost to the user of the different behaviour?
What would the impact be on the item headers if they were smaller?
With the PanoramaItem width set to at least (almost) the width of the screen it allows the user to see and focus on a single item at a time.
Also, potentially having fewer items on screen at once can also help with performance too.
Does anyone know what measurement units are used by Silverlight/WFP? For example, if I create a new button and set its height to 150, is that 150 pixels? points? millimeters?
I design all of my applications in Adobe Illustrator before proceeding to code, and although I try and set everything to the dimensions in my Illustrator file, the Silverlight application is usually larger.
Although in theory, 1 unit in WPF is 1/96th of an inch, that's frequently not the case in practice.
It's usually true when printing. But it's rarely true on screen. The reason for this is that Windows almost always knows the true resolution of a printer, but almost never knows the true resolution of a screen.
For example, I have three screens attached to my computer. Windows thinks that they all have a resolution of 96 pixels per inch. Actually they don't. Two of them have a resolution of 101 pixels per inch, and one has a resolution of 94 pixels per inch. (Why? Because Windows has no way of working the true resolutions out for itself, and I haven't told it. The fiction that they all have the same pixel size is close to the truth, and turns out to be a convenient fiction.)
So when I create, say, a Rectangle in WPF with Width and Height both set to 96, the size of the Rectangle actually depends on which screen it appears on. Windows thinks that all 3 screens have a resolution of 96 pixels per inch, and so it'll render the rectangle as being 96 pixels tall and wide no matter which screen it appears on. That'll make it appear 0.95 inches tall on two of the screens, and 1.02 inches tall on the third.
So in practice, that means that units in WPF on my computer here are either 1/100th of an inch, or 1/94th of an inch in practice. (I.e., in practice, the size of 1 unit in WPF is exactly the size of 1 pixel on my particular setup, no matter how big the pixels happen to be.)
I could change that. I could reconfigure Windows - I could tell it the actual resolution of all 3 screens, in which case the nominal and actual WPF unit sizes would coincide. Or I could lie - I could claim that I have 200 pixel per inch screens, in which case everything would be massive...
The basic problem here is that there is no standard way for the computer to discover the true size of the physical pixels on the screen, and very few people bother to set it up by hand. (And in fact you can cause problems by configuring it 'correctly', because a lot of software doesn't behave correctly when you do.) So the majority of Windows computers don't report physical pixel sizes correctly to WPF - they can't because they don't know.
Consequently, there's no reliable answer to the question - 1 unit in WPF could be pretty much anything on screen. (In practice, most of the time, it turns out to be 1 pixel, simply because if you don't tell Windows anything else, it defaults to assuming that your screens have pixels that are 1/96th of an inch tall, which is the same as 1 WPF unit. And for most desktop screens, that's actually quite likely to be a good guess. But this isn't universal. On systems configured with what used to be called 'large fonts' for example, you'll find a different nominal screen resolution, and 1 WPF unit will correspond to slightly more than 1 physical pixel - about 1.2 in fact.)
With printers, it's all much more predictable. Printers are invariably able to report their resolutions correctly. So if you print something that's 96 WPF units high, you can be confident that it will be 1 inch high.
MSDN's documentation states that the FrameworkElement.Height property (for Silverlight) refers to:
The height, in pixels, of the object
However, for WPF it refers to:
a device-independent unit (1/96th inch) measurement
So, to answer your question... pixels for Silverlight, device-independent units for WPF.
The documentation refers to Pixels, however these are Pixels where there are 96 such pixels per inch. A line of Width 96 when display on a 120 DPI display will be 120 actual device pixels. Similarly such a line drawn on a printer output which has 600 DPI will be 600 pixels long.
They are Device Independent Units.
You can find more detailed explanations here.
My developer's box has a screen resolution of 1680 x 1050. I'm developing a full-screen Silverlight 3 application that I'm considering deploying to the Internet. So, I want to make sure the application looks good on a variety of screen resolutions. I just started testing on other boxes, the first one having a screen resolution of 1024 x 768. During the test I found some of the pages on the application were partially truncated. It seems the controls on the page didn't adjust for the lower screen resolution. So, I'm looking for some tips on how to make a Silverlight application, to the extent possible, adjust for screen resolution. For example, are there things one should or should not do on XAML to make adapting to screen resolution easier? Should I just optimize for a minimum screen resolution? Your thoughts and suggestions are welcomed.
You can easily enforce a minimum acceptable resolution by setting the MinHeight and MinWidth properties of your root visual. (Of course, this should be less than the minimum screen resolution to account for browser chrome.)
Try to specify absolute Width and Height only when necessary: for example, for images or icons of fixed dimensions, or for obvious cases like TextBoxes (whose width should reflect the average length of the data entered).
Grid panels are excellent for mixing scalable and fixed layout areas. The star sizing specification takes a bit of getting used to--it's not as simple as a percentage-based proportioning--but it's much more flexible, especially in combination with row/column min/max dimensions.
You don't really need to test on multiple resolutions unless you're interested in testing a range of dots per inch--just resize the browser to approximate different screens. Since there's always a bit of give and take depending on the user's browser configuration, you'll have to account for some variance anyway.
You can make your application scale with the Silverlight Toolkit ViewBox or make it strech with layout controls like the Grid, StackPanel, and WrapPanel. Make your main UserControl have a Width and Height of Auto (or remove the width and height entirely) and the size of the app will resize to the size of the parent div (the default HTML template uses 100%x100%). Then just resize the browser accordingly. IE8 has developer tools that can help you see your app resized to specific screen resolutions.
Testing on a variety of screen resolutions is always a good idea.
I covered the resizing of elements and making it resolution independent on another thread.
You can have a look here, there are multiple ways to sizing and resizing things automatically.