I´m having some difficulties deciding content width...
I´m going for 960 pixels using the stuff from the 960.gs (960 grid system)
Wich do you recommend?
A - 940 px width on the actual content with 10px margins on left and right side
or...
B - Get more out of the width and use full 960 px for the total content length
Which one is recommended or used in general?
I would think this would depend heavily on your design. Generally speaking 960 seems to be the most commonly used but I think as long as you stay under 980 you'll probably be fine. 960 just lends itself well to easy math where 978 or 940 are a bit more complicated.
My experience has been that I've never received a design that naturally fits the 960 gs all that well and content width has been dictated by the design. The gs is a helpful guideline but not a rule.
Related
SVGs are vectors so they can rescale in size without losing any quality.
Knowing this my mind says, why would I ever use an SVG at the correct size. It seems to me that the same size SVG at 100px x 100px is far larger in size than at 10px x 10px.
So then the question is should I go for a smaller file size and let the browser resize the image, or is it better to serve the image at the correct size so the browser doesn't have to do any rescaling (accepting that in many cases due to responsiveness it will have to do this either way).
I'm aware that this might fall into the category of micro-optimisation but it seems that many of my SVGs could be significantly smaller, and that might help with a Google pagespeed score.
Like you said, SVGs are vectors.
should I go for a smaller file size
You cannot shrink the file size of an SVG. The SVG's XML code remains the same even if you lower the SVG's stated DPI or pixel size.
Will the SVG's file size change if the viewBox is changed?
It usually won't, or at least not much. Here's a convoluted example in which it WOULD change.
Here's the original ("small") version:
<svg viewBox="0 0 10 10" xmlns="http://www.w3.org/2000/svg">
<rect y="5" x="5" width="2" height="2"></rect>
<circle cx="5" cy="5" r="20%" fill="white"></circle>
</svg>
Now let's up the viewBox size. We need to proportionally increase the absolute coordinates of all elements.
<svg viewBox="0 0 10000000 10000000" xmlns="http://www.w3.org/2000/svg">
<rect y="5000000" x="5000000" width="2000000" height="2000000"></rect>
<circle cx="5000000" cy="5000000" r="20%" fill="white"></circle>
</svg>
The result is the same image, but 48 bytes larger (28%!). 48 bytes larger FOR NO GOOD REASON - the represented image is exactly the same, with the same level of precision.
This example is convoluted because most SVGs won't be like this - they will use floating point numbers, and even if the decimal (the literal .) position shifts, the number of digits will not - so there will be little or no size difference.
If you are changing the viewBox size and rescaling all of the values and do see a difference, then it is either like the convoluted example above, OR you are actually losing precision because the rescale is reducing the number of digits in the floating point values -- which would reduce the quality of the final image.
When your SVG "size" matters
Sizing on SVG is pretty arbitrary as it is a vector format, the layout is done with maths and so isn't dependent on the size you specify.
However, if the SVG is rendered on the page and then gets resized size it can make a difference at the rendering stage.
This is because all SVGs are built and then converted to raster images for display. So if you have a gigantic image as you have set the size using cm and the browser has not yet calculated it's final width you can end up in a scenario where there is a lot of wasted rendering work done.
This is an edge case so it is unlikely to affect most sites, especially if their critical CSS is inlined etc.
The only other time it matters is if your CSS fails to be applied correctly for any reason. But on most sites gigantic SVGs are not going to be the biggest things that are broken if the CSS fails for any reason so yet again, super minor point.
In Summary: Do not worry about this, it is not worth the effort in 99.9% of cases and will perform equally well.
Optimising SVGs for performance.
SVG optimisation is more about removing unneeded nodes (so if you are displaying an SVG at a 10px by 10px size it may be worth removing some nodes and simplifying the SVG to save bytes and rendering complexity at the expense of detail.) and optimisation of the SVG by simplifying complex paths and removing bloat.
A great tool for minimising an SVG is SVG OMG, that is where you will see the performance gains from fewer bytes and simplified paths etc.
A final thought
I have a site that is very heavy on SVG, other than DOM complexity it's size is tiny at only 80kb gzipped (as SVGs can be minified and Gzipped as they are just text), I would imagine your time would be better spent optimising elsewhere unless you are already scoring 95+ in Page Speed Insights.
I need some fullscreen images for a react native app. What size should I stick to? Should I add multiple images for different resolutions, like one of width 320, one of width 480, 720, 920, 1280, 1920 etc and choose them according to Dimensions.get output? If so, which sizes should I include? Or maybe I don't need that much images and sticking to one with average resolution is still fine? What are best practices to choose image size?
the size of the images to serve depends on the data you get from Dimensions, pixelRatio and NetInfo.
Let's say regular iPhone width is 320. If you get that and pixelRatio is 2, it makes sense to serve 720 if you want the images to be sharp. That is the math to base the sizing upon.
On top of that it makes sense to check NetInfo.isConnectionExpensive() and downgrade the quality if the network isn't appropriate.
I think a good way to handle this is to have 3-4 base image sizes - small, medium, large, extraLarge (to cover tablets) and use them accordingly.
The documentation describes, that you can place your Image where you want in your JS-Structure and you can use #2 and #3 suffix to support different Pixel-Densities, if you use static resources: https://reactnative.dev/docs/images#static-image-resources
The rest will be handled by reactnative (even like only importing images are really needed.
But I also wonder what are a good starting-point to provide good resolutions.
Maybe anybody has an additional suggestion, wich resolution to start with on default density, and which to use for #2 and #3 suffixes.
I'm having an issue in that I am coding for a non-dpi aware process, until a bug fix lands.
So for now I need to do a work around. My thought is this: figure out the scale up factor, and give my elements width/height scaled down by that much.
So right now I am drawing a canvas that is full width and height of second monitor, it s 1920 x 1080 (WxH). But visuaully (as measured by photoshop after screenshot) it is coming out to be 2880 x 1620. This is a scale up factor of 1.5 (2880 divided by 1920 or 1620 divided by 1080).
I tried getting dpi with methods of GetDeviceCaps and EnumDisplaysettings but all of them returned that of the primary monitor (note: EnumDisplaySettings sets dmLogPixels which I think is DPI to 0 if I do EnumDisplaySettings with constnat of ENUM_REGISTRY_SETTINGS so I had to use ENUM_CURRENT_SETTINGS).
The only method i found that returns differently is GetDpiForMonitor with MONITOR_DPI_TYPE constnat of MDT_Angular_DPI or MDT_Raw_DPI, if I use MDT_Effective_DPI it gives that of the primary monitor.
So now this is my results of running GetDpiForMonitor:
None of the secondary values divided by the primary are giving me a scale up factor 1.5. Is there anyway to get this scale factor?
Thanks
I just had an idea nad it works I am getting the scaled height/width with any of the three methods outlined in my question here: Improper width and height for second monitor from GetMonitorInfo and GetDeviceCaps
GetDeviceCaps on hdcScreen or
GetMonitorInfo or
EnumDisplayMonitors
Then I divide it by the width/height from EnumDisplaySettings.
This is the only way I found how, is there any other way? Can the experts please verify.
Okay, so let me start by saying: PLEASE do not tell me how to create a fluid website or that I should read some statistic from Google on just how much pixel width by height is visible by website visitors as tracked by Google analytics...
As a web designer, certain assumptions about your audience must be made in order to design an effective website. So, what pixel dimensions do you assume are the minimum pixels width and/or height that these users should view your website at?
I understand that with a properly formatted "fluid" design, you should be able to view it at any dimensions - HOWEVER, there is always a target that the designer is hoping for as their minimum and maximum viewing sizes.
So, how about it? I want to hear people's personal experiences. Please do not point me to some obscsure net-article. All of that is great, BUT, I want to hear from those others, like me, who are in the trenches, actually designing websites: what pixel dimensions do you think are the minimum that your site should be seen at?
So, once again, for those in the cheap seats....
WHAT I WANT TO KNOW IS THIS:
What size is the optimal size to view your latest, greatest website design at?
Please, no flaming-weenies telling me what is wrong with my post... if you have nothing constructive to add, please do not respond.
I usually design for 800x600, taking out some vertical space for the browser, so around 800x450 - 800x500. If all of the important information falls in that resolution when viewed with OS-default font size settings, I consider that a good thing.
We had to build a webapplication for users from several systems. We decided that the users will need at least a resolution of 1024x768. the bad part with this page is that graphic designers had too much influence in creating the site. Well, also on bigger screens, everything is in a maximum 1024 pixels wide. We wanted to use the whole screen, but no: "doesn't look cool enough".
At the company I work, we design for a target resolution of 1024*768. This just stems from the fact that the place we are writing an application (GWT) for at the moment have a few old 15" computers lying around, and the application needs to run on their browsers too.
For on-screen viewing, you should trim about 40 pixels off of the width of the screen resolution. The narrower width accommodates for borders and scrollbars.
Think of your target audience:
Are they more likely to have high-resolution monitors (and a 1024x768 or larger display)? If that is the case, keep your width to about 980 pixels.
If your target audience is elderly, or has poor eyesite, they tend to prefer the larger fonts that an 800x600 resolution provides. For this audience, keep your width to about 760 pixels.
Will your audience print out your web pages (or a portion of them, e.g., for order confirmations or instructions/directions)? If so, the page to be printed must fit a 540 pixel width for 8.5x11" paper with .5" margins or 511 pixels for A4 paper.
(HTML5 standards may stray from these traditional guidelines, as pages can grow horizontally and vertically when the user expands viewing areas of the page.)
Is there a standard max for the width of the main content area of a web page? I want to maximize screen real estate without affecting usability. I've seen a lot of sites stick to 980px or less. Anyone have any suggestions?
Target either the 800x600 or 1024x768 resolution.
For 800x600 it is around 750px.
For 1024x768 it would be 970px.
I'm assuming you're referring to the wrapper width since you mentioned 980.
The most ideal solution is to not think of pixels at all and instead rely on ems/%s and scaling, be as fluid as possible so your design fits on small mobile devices and your elements heights are not fixed but auto. Example being: http://www.456bereastreet.com/
But if you're stuck with web designers who still think pixel and you know for sure you'll be unable to get them to try making images that are liquid/fluid, I would say shoot for 960 pixels in width so you have enough viewing area in a 1024x768 with scrollbars in IE6/XP, but this really depends on your audience and the majority of your audience's screen resolutions.
Research, such as that referenced here suggests that people have a more difficult time reading long lines of text. That's why I restrict my content width to 800px or so.
You have to first ask the question. Who is my audience?
There's no "standard", especially in this age of PDAs/smartphones/netbooks/smartbooks/kiosks/etc... - while it may sound cliche, the best thing is to design a fluid layout not depending on exact screen size.
The answer may change depending on your intended/anticipated user base, of course (e.g. assume 1024 px screen width leaving you with 980 working px - and consciously decide that you are not interested in supporting anyone with smaller screen resolution).
Another solution is to allow size layout customization by making it into portal-like with user having control of layout of the portlets (ala My Yahoo).
960 is a pretty common standard, and the rationale behind that figure is the fact that fitting on a 1024 pixel wide screen will allow a big majority of your users to see the content without scrolling. See here for one of 100's of sites that give access to browser & user system capabilities statistics for some initial inspiration.
But in the end, it'll up to you to understand the structure of your customer base - if your site targets iPhones, targetting 1024 pixel wide screens may not be your smartest decision.
Not sure about absolute pixel values, but one thing I'd make sure of is that the text columns don't get too wide. There is a number of characters beyond which reading comprehension is impaired.
1000 pixels in width, is what I use which fits into the minimum 1024x768 resolution used these days without a horizontal scroller at the bottom of your browser ....