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!

My answers to a quiz about the EU referendum

I’ve been on the fence about the EU referendum. It’s a difficult choice, especially when you have to choose between supporting one of these:

david cameron and boris johnson

Which is like choosing whether to eat dog poo, or horse poo. Both will leave a nasty taste in your mouth.

Today took one of those quizzes that you often see linked on Facebook. I thought it might be interesting to share my opinions about each point, and you can see the decision at the end that the quiz thinks I should vote. Continue reading My answers to a quiz about the EU referendum

Who needs actual reality when you have VIRTUAL REALITY!!

I’ve noticed for quite  while that some Youtube videos have a little cardboard symbol:

google cardboard icon

I’ve seen some of the 360 videos before, and I think the first was this awesome Star Wars scene, that you can look around in 3D:

On a whim, I decided to get a Google cardboard to see if it’s a decent experience, and now I’m hooked! Continue reading Who needs actual reality when you have VIRTUAL REALITY!!

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);
}

Game progress – Escape the sector maps

So I’ve been creating maps! This game will be a race against time to reach the end of the level. And I wanted it to be set in space. Because space is cool, and spaceships are cool.

But, space is full of nothing, so what is the map made of?

I wanted it to be made of asteroids. The best spaceship sequences in Star Wars, Star Trek etc are when there’s asteroids, otherwise space is just big, empty and boring.

Continue reading Game progress – Escape the sector maps

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

Game progress – Escape the sector

So I’ve been working on a game which I’m calling “Escape the sector”. Haven’t yet decided if it’ll be Android-only, or for desktop – but I’ve noticed you can export to WebGL, which means it’ll hopefully work embedded in a browser without much effort.

This started out as a project called “Escape Vector” which I’ve been writing about on IndieDB (see here). I created some 3D assets, rocks and buildings which I really liked the look of in 3DsMax because the lighting made it look really nice and lego-y, like this:

nice shading lego Continue reading Game progress – Escape the sector

Page title is still the most important on-page SEO factor on any web page in 2016

I recently read this article about page title optimisation tips in 2016, and here’s some notes:

The page title tag ( the <title> element) is still massively important in 2016

The title of a snippet on the SERP probably won’t show this though, and on mobile it might be totally different.

Don’t do this across pages:

Page 1: <title>my website’s keyword - page 1</title>

Page 2: <title>my website’s keyword - page 2</title>

The number of characters for a title tag is as many as Google will fit into about 512px, the number of characters depends on the text, but will be about 70.

I don’t often post stuff about SEO, but when I do it’ll go here.

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 think Mac should abandon the menu bar at the top of the screen

I have a problem with the way the Mac menu is always at the top of the screen, detached from the app.

I can see the reasoning, it’s a good idea to make sure the menu is in a standard, predictable place for all apps. But, that all falls to pieces when you’ve got a massive screen (like an iMac, or a large monitor like I have), and you’re using floating windows.

In the screenshot below you can see I’ve got 2 PHPStorm project windows open. I’m using the VCS controls in the menu to update one of them. But which one?

2 projects open

See how this can be confusing? The top menu shows options for the project window in focus – but when you’re skipping between windows, are you definitely sure you’re editing the right menu? Continue reading I think Mac should abandon the menu bar at the top of the screen