Related
Please, I need your help.
I'm dealing with a background video for our homepage. This section has 100vh and is full-width. I'm using DIVI as a builder.
We hired a professional videographer to record a video for us. Now he asks me what should be the ideal:
frame size
frame rate
codec
file size
I've done some research and it seems like that the ideals are:
frame size: 1280 x 720
frame rate: 30FPS
codec: I don't know
file size: the less the better
Please, does anyone have any experience with background video? I'm pretty lost.
Also, would you upload it in the WordPress media library or would you use Vimeo/YouTube? I think you can't use YouTube as a background video, correct?
Thanks a lot!
Frame size:
1280 x 720 (=720p) means HD quality, which is quite good, but it is rather up to you, what quality do you find acceptable. Often 1920 x 1080 pixel (=1080p, fullHD) is used for background videos, like my main background video source is https://coverr.co/ where you can download free videos, specifically made for the purpose of being background videos. Those are 1920 x 1080 big. I would say, if you can ask for multiple files, ask for both, 720p and 1080p quality to be able to make a good decision.
The file size is connected to this, so the smaller frame sized video you will use, the smaller file size you will get.
Frame rate:
You could take a look at this image:
https://miro.medium.com/max/1300/1*uMlkXIMNF4VIZoi85NZ3aQ.png
to see what it means.
Movies on blu ray, dvd and cinema use 24 FPS, so that should be enough for you too. Here as well, the lower FPS means less filesize.
Codec:
h264
I'm a WordPress plugin developer and we always suggest this, when our users cannot figure out how to create a video, that plays on all browsers. So far it worked out well for everyone.
YouTube vs Vimeo vs MP4:
By default you cannot make Youtube videos to be backgrounds. There are some coding tricks, which might works, but I wouldn't suggest it.
Vimeo only allows background videos for Pro Vimeo users.
Using mp4 is simple, and also it works better in mobile and tablet devices. Some devices are opening up their Vimeo/Youtube applications automatically, when a Vimeo or Youtube video is started on a website. This is quite bad and your page will end up without background.
You should also note, that most browsers (even on desktop) only allow you to play videos automatically, if you will mute the video in the html code:
https://www.w3schools.com/tags/att_video_muted.asp
What #Gabor said.
1080p (1920 x 1080) is a good resolution for desktop.
If your user is on a mobile or other small-form-factor device it would be good if you could have the choice of 720p (1280x720) or even 360p (360x640). Those will save data downloads and fit the smaller devices. Look for a plugin that delivers the appropriate size video. You'll need a video file for each resolution.
Or don't show background video on users' mobile devices.
In your design think through what will happen in portrait mode. You probably want to clip off the right and left sides of the video material, so the center part fills the screen. So, the action should be in the center.
Is this video huge? Does it play for many minutes? If not, you absolutely should host it on your own site. Why get involved with, and pay for, some third-party media service if you don't have to? If it's really large (> 10MiB or so) you probably should ask another question and give more details.
Put no audio tracks in your background video files. Browsers restrict the playing of audio in background video, so there's no need to make your files fatter with audio tracks that won't play. (If you have audio, consider hosting a separate file to send users who click on the video to view it; most users won't.)
Use .mp4 files with H.264 video in them (one file per resolution). Other stuff, like webm with vp8 video, might generate smaller file sizes. But they don't play in as many makes and models of browser (I'm looking at you, Apple Safari.)
The video, in H.264 parlance, should be coded in the so-called Constrained Baseline Profile. It saves power when played on mobile devices and works better on slower devices.
Ask your videographer to give you streaming mp4 files (also known as fragmented mp4): they can start playing as soon as the first frame is downloaded.
Ask your videographer for advice about file bitrate. Your 1080p files should look decent coded with variable bit rate with a target of one megabit / second (8 seconds per megabyte). Your lower-resolution files will need a smaller bitrate: that's the point of them after all. But, your bitrate may vary. Action/adventure movies need a higher bitrate to look good than do talking heads.
As #Gabor mentioned, 24 frames/sec should be fine. 15 frames/sec is marginal. Ask your videographer what looks best for the material they created for you. Sometimes material shot at 30 frames/sec looks choppy at 24. (The way H.264 video works, once you get below 24 frames/sec the savings in file size aren't as dramatic as you might guess. 15 frames/sec takes more than half the file size of 30 frames/sec.)
I want to display "natural size" pictures of goods on web site.
First of course i calculate size of picture :
<Height of picture in pixels> * <real height of item in mm>
-----------------------------------------------------------
<height of item on the picture in pixels>
Formula is logicaly correct and it works fine on
desktop 17'' 4:3 monitor 1280*1024.
Any other device shows metrics wrong.
I test:
2 smartphone.
22'' 1920*1080 desktop monitor
13.3'' 1366*768 notebook
14'' 1600*900 notebook
They all not 4:3 aspect ratio.
what's wrong with that? How can i reach my goal?
I search web but only workaround i found is to display piece of A4 size paper and ask user zoom page.
I better ask user to setup their system, but how to do it?
Unfortunately, although methods exist to query the browser for the exact pixels per inch of its display, the browser vendors decided to agree to a convenient lie... all browsers report 96 pixels per inch. Although you can get a browser to report this fact to you, there is no way to get the real pixels per inch.
A famous example is that there is no way through Javascript, HTML, or CSS to detect the difference between an IPad 2 and an IPad Mini, despite having radically different pixel density.
Actually I find the approach of using the paper and asking the user to zoom to calibrate the "real displayed size" rather clever. If you make it easy to use, I'm sure they will appreciate this feature!
In theory, by CSS 2.1 specs, the mm unit (and similar units like cm and in) relate to physical units. So if you set an image width in mm units, browsers should scale the image to the given physical measure, with the accuracy allowed by the resolution of the device.
In reality, browsers behave more the way described in the CSS3 Values and Units CR. The section on physical units says that 1in equals 96px by definition, and on high-resolution devices like printers, the inch is the anchor unit, corresponding to real physical inch, whereas on lower-resolution devices like displays, the pixel is the anchor unit. It adds: “Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements.” (Besides, even in printers, the correspondence between CSS in and a physical inch is not necessarily exact.)
So, mission impossible.
For calibration by the user, I would not use an A4 paper. It’s large, and not everyone has A4 papers at hand, especially in countries with a different standard paper size. A ruler, with both inches and millimeters, would be better. And perhaps you could add a zooming widget to make the zooming easier.
Thanks to all! I combined all of tips and make picture :
http://www.clker.com/clipart-258249.html
user takes one of common thing and fit it to picture by zoom.
So I'm building a website for a client on the Wordpress platform and he says that when he views it on an old square monitor, the layout is all messed up. I know most monitors nowadays are more widescreen and you'd be pressed to find a smaller, square monitor, but he wants it to look good on every monitor, which I completely understand.
I'm just having a hard time trying to fix it because I'm building it on a widescreen laptop and widescreen monitor so I can't really tell if it's fixed when I make changes.
So my question is, how can I view the changes I've made as a square monitor? I've tried resizing the browser window, but it doesn't make any changes. It's not looking like anything he describes. Also, I know this is a longshot, but are there any WP plugins or anything that will fix it?
P.S. I've been making changes to the style.css file with the #media property. Thanks!
Back in the day, websites were always developed to accommodate the "square" monitor resolution. Today, the number of users using 800x600 or 640x480 is negligible which is why most sites leverage the space benefits introduced by the wider ratio. And, without getting into the possibility of an antiquated browser to go with his antiquated hardware and why one wouldn't want to pander to either of those over the mass as a whole, I'll stick to the question at hand.
Without seeing the website, I can't say for sure what's going on but I'm willing to guess that one of two things is happening:
The way in which the content is organized is causing one area to push into another
He has to use the horizontal scroll his on browser to see the whole site.
The solution for overcoming both of those problems is a whole other issue but, to get you both looking at the same page, set your monitor's resolution equal to his to simulate his view. On both my desktop and laptop, I can set it to 800x600 so I'm willing to be you can too.
Back in the day, 800 x 600 was the screen resolution to design for - and maybe 640 x 480. Then along came 1024 x 768, etc, etc, etc.
But then it gets worse: now we have not only different resolutions but also different aspect ratios.
What strategies do people use to accommodate today's ever-expanding range of screen sizes and aspect ratios?
(BTW - I was only thinking about laptop / desktop hardware, but of course there's smart-phones and tablets to consider too.)
I know this would be a somewhat controversial opinion, but I'd say it anyway: Don't
Don't design for multiple screen sizes or aspect ratios. There are of course a few exceptions: Heavy web applications like webmail clients can definitely do with more screen real estate, and are probably flexible enough to accommodate a large range of screen sizes anyway. Mobile versions of said website, with a more flexible design to accommodate the incredible spectrum of mobile screen sizes can help too for sites with high mobile volumes. However, if you stick to the so called 'desktop web', then I think we can say that 95% of the time there are more important things to care about than screen sizes, resolution and aspect ratio.
First off, lets tackle the easy one. I don't really understand why you would care so much for aspect ratio - it isn't like we care that much for the 'below the fold' nonsense anymore, do we? The web is a vertical medium - scrolling will always have a place in websites. Having everything above the magical 600px line is just stupid.
Next, screen resolution/size: Again, I find it difficult to defend.
Users with large screens do not usually maximize their browser windows, because they find that most website do not take advantage of them. While the web adjust to the user, the user also adjust to the web. Although you could argue that this is a chicken and egg problem, the fact remains that website are usually designed for the lowest common denominator. I'm not defending this position, but rather, pointing it out as the current prevailing trend in the industry.
There are certain things that simply won't work with resolution that are too high or too low. There is, for example, a small range of widths that allow people to read comfortably on screen. Any longer and the amount of movement for the eye to the next line would be annoying. Too low and the text would appear cramped. The fact that the web was designed to be resolution neutral means that paradoxically not many provisions has been made for those who wish to build fluid layouts. min-height and max-height would help, of course, but the wider the range, the more difficulties you will face. Things like orphaned elements, displaced images, backgrounds that run out, etc. are unavoidable for truly flexible sites built with today's technology.
So my opinion is that the simplest method for dealing with multiple resolutions is to ignore it altogether - with today's technology there are not many options anyway - and design for the lowest common denominator.
Watch out for high DPI settings
I think one of the most undiscussed issues facing front-end web development today is testing on high DPI systems. Everyone has learned to test and test and test on different browsers but designers/developers have not caught on to testing on different DPI settings.
High (or even low, for that matter) DPI settings break designs when fonts are scaled but images are not (which can happen), can cause images to look fuzzy/blurry, and absolutely positioned objects may not appear in the desired location (which would be devastating for CSS menus.) If nothing else, test your images at high DPI and re-render them as necessary.
This has never really been an issue until recently with the release of Windows 7 and people buying computers with high resolution monitors. First off, Windows 7 uses 96DPI as default (which is different from the rest of the computing world that has been using 72DPI as the standard. Moreover, Windows 7 will automatically adjust DPI settings and I have seen people with DPI of 150% of normal (96 DPI in Windows).
Here's a great link discussing this issue in more details: http://webkit.org/blog/55/high-dpi-web-sites/
A great cross-browser website designed with web standards is the goal but don't forget about DPI testing.
Well, trying to keep the answer not-too-long, this is what I do.
(A) Always start from the most likely used ratio/resolution
If your average joe is going to be on a modern laptop or a desktop machine he likely has AT LEAST 1024x768 (refs: w3schools elykinnovation), that gives you roughly a usable 960px width (you might want to check the 960grid system - there are a hell lot of new framework since I first wrote this).
If you users are more likely to start with a mobile device or a tablet, thing about them first.
If it's 50%-50%, it's usually better to start from small and then grow up, eg. Rock Hammer or Foundation
(B) Layout: fluid or not?
If your website could benefit from a larger width, pick a fluid design starting from this resolution. Be careful that the human eye does not like to read text over long lines, so do not abuse of fluid design; often sticking to 960px with large margins is acceptable.
You might want to add (javascript) some additional side-menus if you really have a lot more space. But design your website to work without JS as much as possible.
(C) Other resolutions
Finally it's time to check that with least used resolutions things are still acceptable.
(D) Other devices, ratios and stuff
There are not many options for different ratios; it often means you are running on a mobile, ipad, AAA or similar device.
My advice is to ... design for those devices specifically.
While writing your HTML keep in mind what you are going to need and remember to do HTML by semantic and not for design. Use properly HTML5 semantic tags if you can.
Avoid < bold > or similar tags, and properly use tags and classes that you are going to style with CSS instead.
Use a framework!
But you still can make a few different designs for very different devices. You don't have to do everything responsive /in the same design/.
There are several ways to serve a different CSS depending on the client; you can do it:
server side, checking the browser in the HTTP heading coming from the client, either with your web server or your dynamic scripting environment - be it python/django, php, or whatever else
javascript (you can easily get the window size)
html - in particular with some specific devices such as iphone
You can easily produce a generic design for small (eg. mobile) devices by following some simple rules:
1. fluid layout capable of fitting in very small widths
2. compact header/footers not too waste too much space
3. few, clear contents per 'page'
4. avoid :over effects as they won't work on touch devices!!!
If you want to go further, you have to check individual devices customizations; an example is the iphone viewport, see the apple ref library.
This is just to get you started. Experience and specific needs will drive the rest!
Your site can't work perfectly for every display. Even if you had enough hours in the day (or should I say year/decade) to design for every possible display, you'd have to do it over every time a new device comes out.
In my development, I still religiously try to avoid horizontal scrolling, and that isn't too hard with floating divs / variable-width divs. But beyond that, we really are at the "there's an app for that" cross-roads, where you need a specially designed display for specific devices.
One strategy I use is to reduce dependence on a single display -- a customer probably doesn't need to see your entire web page to do what they came to do. You can parse-out functionality to smaller/simpler web pages that scale better on differently-sized devices.
At work, I have a little more "power", as it were -- I can develop internal web apps that are "designed to run on...some specific browser, some specific display setting, etc. -- use other configurations at your own risk". This, only after getting the managers to agree that spending an extra week in development (and even more in upgrades / future maintenance) just to placate that one vegetarian at the other end of campus who refuses to use IE really isn't worth the cost. In that case, we need another Timmy, not a more flexible web app that can look good on his favorite non-IE browser.
This is a common but complex question, which unfortunately does not have a single best solution. It all depends on the kind of content that you have. You can use a fluid layout, or design your site differently for different resolutions (see http://www.maxdesign.com.au/articles/resolution/). For an example of a fluid design, check this out - http://hicksdesign.co.uk/journal/finally-a-fluid-hicksdesign
I think that responsive web design is the answer to your question. Have a look at these examples and techniques...Responsive Web Design
I've written a helpdesk monitor application that is designed to sit on a big plasma screen in a support department, the application has 5 views that it revolves around, the content of most of those screens is different, but they have some common components, being one silverlight control and a css background image.
I'm worried that over a period of time these will get burnt into the screen, I've looked into techniques to fix this, and some people suggest moving the image by one pixel every few seconds or displaying a different view.
I just don't know if these techniques are sufficient.
Does ensuring that I use a different css background, and a bit of silverlight animation 1-50% of the time actually fix this problem? The same image will be in the same place the other 99-50% of the time.
Check the documentation for the plasma screen, I did hear that many of them countered burn in by running colour flashes at some points and it is not as big a problem with modern plasma screens.
From what I've heard, this is a common complaint because of the annoying channel logos in the corner of screens so they had to do something about it.
What I am saying is, I think your hardware will probably manage it anyway.
Ryan
It depends on the plasma screen you use. Some manufacturers take steps to reduce the risk of it happening. However, if it does happen, I've found that there is something called JScreenFix that can be used to remove the burn-in. The basic problem is caused by the image on the screen not changing. You can either make sure the image moves at least slightly over time or reduce the contrast to reduce the risk.
Also, if possible you should use an LCD screen instead which are technically not susceptible to burn in...though they sometimes suffer from image persistence which is not permanent.
Check out for more detailed information:
http://www.plasmatvbuyingguide.com/plasmatv/plasmatv-burnin.html
http://www.wikihow.com/Use-JScreenFix-to-Remove-Plasma-Screen-Burn-in
http://compreviews.about.com/od/monitors/a/LCDBurnIn.htm
The comments that new plasma displays do not burn as easily is only partly valid since your department will probably buy the cheapest plasma they find.
mezoid is right. Reduce brightness and contrast and turn it off at night but I have found that burn-in isn't that serious. We have few monitors at work for this purpose and although there is obvious burn-in around borders of windows we can still see very clearly the important data.
If you are not presenting this to customers it should be okay although the staff may make fun of this occasionally :)
Plus you could run the JScreenFix every couple of months mezoid proposed you are okay.
Just be careful with JScreenFix, do note that it works merely by burning in the rest of the screen simply changing your perception of burnin and will, over time, make your monitor a washout.
There's an idea I haven't tried, but might help, If you phase the obvious static problem area through the 3 primary colours, or the 3 secondary colours, or both, you could utilise the benefit from only burning each pixel for 1/3rd of the time effectively tripling the time it takes for burnin to occur.
I think the risk of screen burn is much smaller than it used to be.
And why even bother if the screen will only be used to display the same view all the time? If the same image is kept in place all the time, it doesn't really matter if it gets burnt into the screen or not :-)
If you still would like to take measures, I would also suggest some animation or moving the image around a bit when the view rotates.
[EDIT]
Forgot something... A lot depends on time between the views rotating. If you only switch the view (and image) every few hours, the risk is a lot greater than if you switch to a different view every ten minutes...
[/EDIT]
I've used this program with pretty good success. You can probably create something similar in your program.
http://www.e-motional.com/TScreenLock.htm
Plasma Screen Saver Option.(TSL-PRO Only) A black bar of variable width floats across the screen preventing Plasma Screen Burn-In. This option allows TSL to be used as a Plasma Screensaver.