Monday, 18 February 2013

Responsive design - em or px for breakpoint measurements


Introduction

As I stated in an earlier post this year (actually my first post of the year) I'm going to be writing posts on responsive design as I'll be building my first site using it this year. This is about what I've learnt through trial & error about what measurement to use when defining breakpoints.

Using em measurements for breakpoints

I read a few posts on Google basically stating that defining your breakpoints in em measurements instead of pixels has the benefit that if a user increases the browser text size then the page will switch between responsive breakpoint designs as well as switching at different screen / browser window sizes.

This sounded great to me as I'm sure people have the text size permanently increased on their browser / operating system, I personally do on my mobile phone and giving them a design which best suited the larger text size and not just the browser window size seemed like a great idea. I started to have problems though while actually trying to implement this in a HTML & CSS wireframe I was making (I got a bit carried away with that wireframe and pretty much made the site, but that's for another post), mainly with mobile phones.

My problem with using em for breakpoints

I had the problem that some mobiles phone browsers have the default font size larger than 100% to compensate for the smaller size text the user will see on a website designed for desktop browsers. This in-turn would show a page layout that I had designed for a smaller screen size and as a result I didn't feel the user was getting as good as an experience as they could.

Here's and example of what I mean, I had a layout designed for large screen phones like the Galaxy Nexus but when using the default browser that comes with Android it would showed the design made for the really small Android phones. So I had one of the biggest screened phones on the market displaying a design for one of the smallest phones on the market, this confused me for a long time as I couldn't see why it was doing this but other browsers were fine on the same phone. Then I worked out the default browser text size for the Android browser is larger than 100%.

This was looking ridiculous to me and I really thought people were losing out on a large part of the experience, after all the text wasn't getting so big that it would've broken my design for large screen phones anyway

So I switch back to pixel measurements for breakpoints

In the end I decided using pixel based measurements for breakpoints would certainly be the better way to go as using em had caused me so many problems and when I actually used it, it didn't seem to work as well as I'd hoped or imagined.

I however still had to take into consideration that some people use text zoom on their browsers and some browsers have the text zoomed in by default so I used the same method I've been using for years which is to make sure the design of the site is fluid enough to take text size changes into account. Also to help mitigate this potential problem is to make sure your responsive breakpoints for smaller screens are designed so that text size isn't an issue and users won't have to zoom in or increase text size anyway.

Concluding thoughts

If anyone reading this has had different results when using em measurements for breakpoints please let me know as part of the reason I gave up on them was to do with my frustration of not realising some browsers default to a zoomed in state. However I also think using em measurements wasn't very useful and having a fluid design which can cope with various text sizes at the different breakpoints you set for your design is a much better way to go to deliver the best experience to users.

Further reading



Wednesday, 13 February 2013

Opera move to the WebKit rendering engine


Introduction

For those who haven't heard yet Opera will start using the WebKit rendering engine and V8 for its JavaScript engine in future releases of the browsers. They were / currently are using Presto as their rendering engine and Carakan as their JavaScript engine which are both proprietary and developed by Opera.

Why make the change?

If you want to know what they say then read their blog post but I think it really comes down to cost (like most business decisions) and it's just not cost effective to develop their own any longer. Originally they made their own as there wasn't any decent open source alternative, the only two decent rendering engines out there were Internet Explorer's and Netscape's both of which were proprietary at the time.

Developing their own engines I'd guess is no longer setting them apart from the competition either any longer either as they're all pretty standards compliant and quick at rendering.

What does this mean?

Well not much really, you just need to keep developing to standards and testing like normal but it does mean there's one less competitor in the market of rendering engines now.

In one way this is good in that more browsers using the same rendering engine means they'll be less 'quirks' and oddities between them and we'll also have Opera developers contributing and improving both WebKit and V8, they seem like pretty good developers too so that must be a good thing.

On the other hand it means less competition and that never seems to end well, although currently there's still Trident and Gecko out there, both of which are large and certainly make good competitors.

Further reading

Tuesday, 5 February 2013

MediaElement.js loads full video before streaming


Introduction

A few days ago I was using MediaElement.js to put a video on a website, nothing to special.
For those that don't know what MediaElement.js is, it basically turns a HTML5 video tag into a Flash player if the browser doesn't support the video tag or doesn't support the video format(s) your using. See their website for more details, it really looks quite good and is recommended by a lot of people; my first time using it though.

The problem

The .mp4 file I was using (rendered out from Adobe After Effects) loaded fine on the website but before it started playing it had to buffer the whole video, which meant quite a delay between the user clicking play and actually seeing the video. Not ideal.

So what caused this? Well I'm no video expert so can't say for certain but this is what I can gather by reading about a little, although it was really only a little bit of reading I did. It seems to be some h.264 (possibly all?) files have the index saved at the end of the file and to play a video while it's still loading it needs to be at the beginning  What the index file does exactly I haven't looked into but at a guess I'd say it has information about the video and is the video equivalent of a database index.

The solution

How did I solve this? Well with a bit of Googling about, in my situation an Adobe Air program called QTIndexSwapper which you run on your local machine, select the video file & it saves out a new file with the index moved. That's it, works really quick too.

Another solution

Another solution which was suggested on StackOverflow but for a slightly different scenario seems to work according to replies and comments there (I've not tried it myself though).

This is for situations where a user uploads a video and you need the index moved by PHP on the server after it's uploaded rather than doing it manually yourself. There's a class hosted on Google Code called moovrelocator which does exactly this, I haven't used it personally so can't comment much on it.

Sunday, 3 February 2013

Domain & hosting separation


Hello,

Just a quick post, I just read about this myself somewhere else but can't find the link although that post just mentioned it in passing. The basics of it is to keep the company you have your domain hosted with and the place where your website is actually hosted separate as that way if someone hacks one of them they haven't got access to everything.

I've always done this but I've never thought of it from a security perspective, I've always wanted it them separated encase I want to change hosting provider (I've had a few bad ones) that way they have no control over my domain if they get awkward.

I've got another post lined up about Wordpress v3.5.1 which will hopefully be done soon, but researching into all the changes is taking more time than I thought!