Category: Web dev

Devices in Browserstack are as factory defaults, without latest updates

I use Browserstack a lot for testing website in devices, and It’s especially useful as I don’t have a lot of popular devices that I need to test on. iPhone 5, iPhone 6, iPad, iPad air etc.

I noticed a problem a few times now, and it’s mostly the way these iOS devices handle vendor prefixes – or more specifically that they *require* vendor prefixes for things like transform: rotate();

Sometimes, a page might look totally different on Browserstack (which shows the design messing up disastrously) to on iPhones and iPads that I’ve tested on.

It seemed a bit odd to me that the most favoured devices in the world still required vendor prefixes, when Chrome mostly doesn’t need them. I assumed they must have been updated recently surely, and that Browserstack is only showing me the devices at their factory settings. So I asked them to find out.

Are your iOS devices as they are out of the box, or include latest updates? - ‏@browserstack @davidonionball Yes, we provide iOS devices with the OS and browser versions shipped along with it.

So there’s proof. Devices on Browserstack are at their factory settings, which means any updates to the browser (and there might have been loads by now, surely?) won’t show.

This is good and bad, I can see why you’d want to see what your website looks like on a brand new out-of-the-box iPhone, but also, with the amount of browser updates there’s been, that might display totally different to the majority of iPhones.

But, just something to bear in mind.

Update – Browserstack got back to me saying they do provide the latest version of Safari on iPhone 6S and 6S Plus, which is what I’d expect.

browserstack - You are correct. However, we do provide Safari v9 on iPhone 6S and iPhone 6S Plus.

Although still it looks like you can’t test on an older phone that’s upgraded to Safari 9 (assuming that does happen of course?!).

Transitioning the colour of an SVG image

So when trying to make the BTB website load as quickly as possible (which requires an unhealthy obsession with tweaking small things to get a better score on Google page speed insights) I removed Fontawesome, which was previously baked into our CSS file. I like Fontawesome, it makes adding icons easy, but has problems, and in this case the problem was unnecessary addition of loads of styles we didn’t need, and valuable kilobytes of data I wanted to shave off. Continue reading Transitioning the colour of an SVG image

Schema.org name vs headline

I’ve been tasked with adding schema.org markup to a website, which is something I’ve known about for quite a while, I even added some to OngoingWorlds, although still don’t really know what the benefit is apart from the obvious company name, address, opening hours, telephone number etc which I assume is what gets used when showing a company at the top of a SERP, or on Google maps. Useful for some things, like restaurants you’re googling, but not others.

Another example of data I assume comes from this sort of data is cinema times, and probably e-commerce website data showing on the Google “shopping” tab.

But that’s about all the examples I can think of, even though there’s looooads of different types of metadata you can add, including fictional characters in stories, accessibility hazards, audience, quests in games, and loads of others – problem is, if these aren’t presented in interesting or useful ways like the restaurant result example, then what’s the point?

There seems to be some duplication too. I was marking up the blog articles template (blog on schema.org) with things like author, publishedDate etc, (which are useful), but there’s also a headline and name.

Description of headline:

Headline of the article.

Description of name:

Text – The name of the item.

I wouldn’t be so bothered, but Google’s structured data testing tool is marking the lack of name as an error in red. Not sure how serious that is, but it’s RED!

Google structured data testing tool result showing errors

I’ve had a look at other examples, and The Guardian uses itemprop=”headline” on it’s main article title, ignoring name completely (hey they also use BEM, thats cool!). The Independent uses headline too, so I’m going to do what they do and ignore name.

Although, there’s a discussion on W3C to deprecate headline completely, in favour of name, which is more standard. So I don’t know what to believe!

Combining media queries in Foundation

Edit 2017: This article was originally written for Foundation 5, but I’ve updated it for the new way Foundation 6 uses CSS @includes for media queries. 

I really like the way Foundation 6 makes media queries easy by putting them into variables, so that I can easily put breakpoint into a CSS class. Like this:

.my-class {
   font-size: 1rem;

   @include breakpoint(medium up) {
      font-size: 2rem;
   }
}

I’ve written before about the way I write media queries (see here), and I think this is the best way to avoid hunting through documents to find a selector that might be in a separate breakpoint somewhere.

However I sometimes want to combine multiple breakpoints to save duplication. For a long time I thought this wasn’t possible, but you actually can by writing it like this:

@media screen and #{breakpoint(small only)} and #{breakpoint(large up)} {

}

I find this useful with height breakpoints

Sometimes I need to use a media query that detects the height, to make sure we’re not using elements that are too large.

I’ve made my own height media queries as variables:

$short-only: "(max-height:600px)" !default;
$tall-up: "(min-height:601px)" !default;

I use “short” and “tall” for height like you’d use “medium” & “large” for width (maybe Foundation should change their variable names to “narrow” and “wide” instead?).

So I can do this sort of thing to change heading menu font size if the screen is really wide, and definitely tall too.

@media screen and #{breakpoint(large)} and #{$tall-up} {
    font-size: rem-calc(36px);
}

My current projects – May 2016

Unity – Escape the sector

cliff building escape vector

I’ve abandoned the Escape Velocity game where you control a spaceship on rails, in favour of one where you’ve got more control, and it’s a race against time to finish the track. It’s a simplistic idea, but I’m hoping to make it exciting with explosions. Yes. Explosions are cool.

I’ve written a bit more about this here.

Burnthebook

I’ve been building website frontends for work, which is going fine. My latest project has used Foundation 6 (previously I’ve used 5), and CraftCMS which is new to me. I’ve also been wireframing a few projects, using Protoshare (which I’ve written about here).

burnthebook website on mobile

I’ve just finished the company’s main website – www.burnthebook.co.uk

Looking for a new best CMS

voxel art city
This doesn’t have anything to do with the subject matter – I just saw it and like it, it’s by Sir Carma on Behance

We need to review the CMS’ we’re using to make sure we’re using current technology, and making use of latest developments to make sure we’re able to build websites quickly, and with all the features the client expects in 2016.

It’s my personal opinion that all CMS’ are terrible. So I’m trying to find the LEAST terrible 😛

Qualities I’ve been looking for:

  • A wealth of features – Some CMS’ have more than others, and built-in features that we commonly use will make development quick and easy.
  • Customisability – Whatever out of the box functionality is provided, we need to be able to extend this for whatever design or functionality a client may want.
  • Community – A CMS with a strong community is a big benefit because it means you can google for errors, ask for help, and pick from many existing plugins which massively saves project time. Also, dedicated conferences show the firmness of a CMS in the marketplace.
  • Documentation – I don’t like reading documentation. Especially when it’s long-winded and hard to find what you need. So concise documentation is a massive plus.  
  • A decent way for creating a hierarchical menu – As we mostly make brochure websites, a good way of creating a hierarchy is a benefit. The reason I’m mentioning this is that it’s actually quite rare! In EE, hierarchy isn’t actually built in and we have to use a 3rd party plugin, which might stop being supported.
  • Speed of installation – Unnecessarily complicated installation processes annoy me, and add to project time. IMO a well-built CMS will have a speedy installation process.
  • A good experience for clients – Clients need to be able to login and use the site with confidence or they’ll bother us with support calls. If the experience for a client is good, they’ll be happy with their service.

I’ve only been looking at CMS’ that use the LAMP stack, as that’s what I’m familiar with.

Bear in mind that the below information is based on research about the CMS’, the only ones I’ve have firsthand experience with are WordPress and EE. Better research can be done by experimenting with them, and actually using it to build a website!

CMS’ I’ve been looking at:

  • WordPress
  • Craft
  • Concrete 5
  • Drupal
  • ExpressionEngine (what we use right now, included to show comparison)

WordPress

Twitter followers: 380,000+

Questions on Stackoverflow: 88,873 (has it’s own Stackexchange site at http://wordpress.stackexchange.com with 66,901 questions)

Built in features: Create a blog, with posts organised by date. Static pages can be created and added to static menus (meaning a new page is not automatically added to a menu). That’s about it, everything else is achieved by a plugin – of which there are MANY.

Pricing: Completely free.

Plugins: Many thousands, WordPress has a very active developer community and it’s difficult to find functionality that isn’t already covered by a plugin. Plugins are easily added through a marketplace/directory, with a few clicks – currently in EE we have to download files, place the files, and upload the files, which is time-consuming. Plugins also seem very well supported and maintained between versions of WordPress.

Customisability: The problem with WordPress, is that although there’s thousands of plugins changing its functionality, it all feels like a hack. It’s a simple platform (which I assume is why it’s popular) but I know many backend developers who say it’s terrible to work on.

Documentation: There’s a “codex” which is pretty extensive.

Community: WordPress is massively popular so it’s easy to find people who know it, which is great for support. There are multiple WordPress-specific conferences all over the world each year.

Templating: WordPress uses pretty basic HTML with PHP, which means you can do pretty much anything, but it’s not very sophisticated, and end up with files which are a mixture of HTML & logic which might make any seasoned developer cry.

Client experience – Clients seem to love WordPress probably because it’s popular and they know they can host it elsewhere. The basic experience is good, but WordPress can spiral out of control if many plugins are added which abstract it’s functionality, causing the clients experience to be muddled, especially if they have to move between different plugin interfaces. However, it’s so popular, that they’ll likely be able to find a solution by googling rather than calling us.  

Craft CMS

By Pixel & tonic, the creators of many plugins for EE that we already use.

Pixel & tonic twitter account followers: 2,996

Craft twitter account followers: 3,881

Qustions on Stackoverflow: 0 (has it’s own Stackexchange site at http://craftcms.stackexchange.com with 4,733 questions)

Built-in features: Has content elements by default, which is what we use all the time in EE (although always seems like a hack). Their solution *looks* pretty elegant, and seems easy for a client to edit, and give them a lot of control.

Pricing: Their “client” package (building sites for clients) is $199 per site which only has 2 users (which might be ok for us), or $299 for pro which allows more users and built-in translation functionality.

Community: There’s an active slack channel, which is nice to chat to other developers, but I don’t find all that useful for support because it’s a single linear thread. It’d be more useful using something that allowed multiple comments on a subject. It has 2000+ users in the #general channel.

There is a yearly online “summit” about Craft.

Documentation: There’s a decent guide for getting started (although I haven’t followed this, so don’t know how accurate or useful it is).

There’s also a searchable knowledgebase with tips and useful snippets.

Templating: Uses Twig, a third-party templating engine.

Client experience – I haven’t used this so can’t comment on the experience of a client. Videos show the CMS being easy to use, especially the way content elements are moved around. But the way the pages are abstracted into entries (an entry might or might not be a page) means it could be confusing for them.

Craft CMS seems (from a first look) to match the way that we currently build sites in Expression Engine, with entries and custom blocks (we call them “content elements”). It gives the client a lot of control – although I’m not sure how much we can lock them down, as it might give the client *too* much control that they might create a combination of blocks that doesn’t work.  

Concrete 5

Twitter followers: 5,989

Questions on Stackoverflow: 409

Built-in features: Has content elements by default, which allows users to add predefined “blocks” to an area of the page (main or sidecol etc), which allows a lot of custimisability without needing a massive amount of templates, and is much easier than how we currently do content elements in EE (which feels like a hack).

It also has a page hierarchy by default, without having to add any plugins.

Pricing: Completely free to build and host a website. Some add-ons are paid for, which start at $15.

Open Source, source code is available on GitHub, which shows active development. Changes being made daily by multiple people.

Community: There’s a member forum, with multiple new threads created each day, and most questions asked get responses.

Documentation: There’s a docs area, with tutorials submitted by users.

Add-ons: There seems like plenty, some paid, some free. You can also buy themes, which provide a frontend for a site, which might be a good way of making a project cheaper and faster by choosing a theme similar to what needs to be achieved.

A lot of “blocks” can be downloaded as add-ons, which might also make development faster.

Client experience – I find the page editor interface a little confusing (I’ve only tried it a bit), so the client might also be confused.

I want to tell you that Concrete 5 is great because you can drop all sorts of pre-defined blocks, but it’s hard to find a list of all blocks. I assume we can create and reuse these between projects.

Concrete 5 certainly doesn’t seem a very popular option (look at the Twitter followers & amount of Stackoverflow questions compared to others in this list), although it does seem feature-rich. 2 back-end developers I know tell me this is the easiest CMS they’ve ever worked on.

Drupal

Twitter followers: 64,100+

Questions on Stackoverflow: 16,652 (has it’s own Stackexchange site at http://drupal.stackexchange.com with 59,311 questions)

Built in features: A bit like WordPress, you can create pages and bind them together using taxonomies, instead of a page hierarchy. Which makes it a bit awkward to do what we need, as we create many sites with a hierarchy.

Community: I know several Drupal users, both freelance. It seems to be a popular choice for freelance developers selling to small one-man-band websites.

Documentation: It has documentation of course, and quite a lot of it. It doesn’t seem as clear as other documentations on this list.

Add-ons: The module marketplace seems lacking, and plugins listed near the top are many years old, although that could just be due to the poor website listing them badly.

Client experience – I can’t really comment much on the interface the client uses, but I do think it looks very old-fashioned and not what I’d want a client to see in 2016.

Expression Engine

Twitter followers: 10,100+

Questions on Stackoverflow: 1,221 (has it’s own Stackexchange site at http://expressionengine.stackexchange.com with 10,997 questions)

Built-in features: Channels & entries, which allows us a lot of customisability, although hierarchy isn’t built in. Normally we use a plugin called “structure” for EE2 we don’t yet have a plan for how to replace this in EE3.

Pricing: $299 per website. There’s also an optional support plan starting at £49 per month. Individual plugins do cost, but are usually cheap and are 1-time payments.

Community: The closest meetup is in London, where a group meets monthly. The turnout was descripted as “small”. There has been an annual conference for the last 6 years in the US.

There’s an active slack channel, similar to Craft CMS, although seems slightly less active. It has 600+ users in the #general channel.

Documentation: The guides are mediocre, and when following them I found it less than straightforward. Better as a reference than a guide perhaps.

Add-ons: Has an ok amount of plugins on a separate website called devot:ee – although many we use haven’t yet been converted to the new version 3 of EE, and the slow rate of adoption is worrying for future support of those plugins between versions.

Templating: Uses it’s own custom syntax, which is ok, but a standard solution would be nicer.

Working in EE is fine, we get a lot of customisability, although at the cost of simplicity and taking a long time to setup. The cost of the licence is an odd one, I can’t see what we get extra, when some of the cheaper or free CMS’ provide comparable functionality.  

So which is best?!

Honestly, I’m not even sure there is a “best”. There’s quite a lot of choice in CMS’, and the ones I’ve chosen here have comparable features – to a degree. They might all be used for solving the same problem, but the method will be quite different.

WordPress obviously has it’s place, and is a great solution if you’re creating a blog. If a client needs a blog (a list of articles ordered chronologically), I wouldn’t recommend anything else. If a client requires a fairly complex system involving multiple channels, obviously EE has always done well for us. But if a client requires a simple brochure website, where they need control over content elements (I’m thinking something like TT Gillard) I do wonder if using Craft CMS or Concrete 5 would actually get the job done effectively, and much quicker than the way we do it currently in EE.

Difficult to tell without installing and playing with these systems though, which I think would be useful when we have some time.

If you’ve got a favourite out of these, or want to suggest another, feel free to comment below – or tweet me @davidonionball

I admire this guy for not using a preprocessor, but I just couldn’t

I read this article today about someone who doesn’t like using preprocessors (like LESS or SASS) to compile CSS. It’s worth a read, here it is:

http://www.456bereastreet.com/archive/201603/why_i_dont_use_css_preprocessors/

I put off learning SASS for a long time, because I find it fiddly. You have to install something, and often have to run commands in a command prompt (something I hate), running gulp or grunt or whatever. But I was converted when I realised PHPStorm did it for you – which is AWESOME.

But now that I do, I feel like I can write styles so much clearer and more effectively, without getting lost in a massive page of WET CSS code. I use the word WET as the opposite of DRY (don’t repeat yourself), as without compilation your CSS can end up with lots of repetition. Especially if you need to target things inside a specific class, you might end up with this:

.main-content p,
.main-content ul {}
.main-content h1 {}
.main-content h2 {}

Look how many times you have to type .main-content! Whereas in SASS you could write:

.main-content {
   p,ul {}
   h1 {}
   h2 {}
}

Isn’t that cleaner?

There’s also loads of advantages – being able to split code into useful components you can paste between projects, rather than one big mass of CSS. Also, keeping colours as variables is amazing. I’ve no idea how I managed before that!

Here’s more articles about the way I like to write styles:

Here’s an article to read about preprocessors: Why your reasons for no-longer using a CSS pre-processor are wrong, and you’re wrong, and you should feel bad.

4 examples of CSS being weird

I know many people find CSS quite difficult, and often I see this gif shared as an example of how people work with CSS:

Peter Griffin doing css

But if you’re doing CSS like this, YOU’RE DOING IT WRONG! CSS isn’t that difficult, but sometimes the chosen syntax does make me WTF. Here’s some examples of that:

Comma inconsistencies

Sometimes you need a comma to differentiate multiple values, like:

transition: color 200ms, background 200s;

But sometimes not:

transform: translateX(-50%) translateY(-50%);

Why isn’t this consistent?!

Slashes in shorthand

Ever seen this?

font: 12px/18px "Lucida Grande", sans-serif;

The first 2 values are shorthand for font-size and line-height. Why they’re separated with a slash though seems unusual as I’ve not seen that used anywhere else.

Apart from you can apparently use it in border-radius (here’s an article explaining that) to separate horizontal and vertical axis, but again – that’s inconsistent to how we do it elsewhere!

Camel Case or hyphen?

CSS has always been hyphenated, for example background-color, text-transform etc, so why did we start adding camelcase like translateY, rotateX? It’s inconsistent!

Edit – Also, overflow-y and translateY – Y so different?

Vertical Percentages are Relative to Container Width, Not Height

I didn’t actually realise this for a long time. It can be really useful once you know what it’s doing. Here’s an article about it. But why can’t I also set a height based on a percentage of the container’s height?