If conference videos are made more accessible, they can be shared with a wider audience. This is a great way to add value! Most Fronteers 2015 videos are now available with captions and transcripts. In this post I will explain why we did it, how we got our transcripts made and what happened next.

At Fronteers, we have had our videos transcribed in the past 2011, 2012, but it was quite a time-consuming process and we’ve not always been able to find volunteers for it. In recent years, the process has improved a bit, so this year I thought it would be good to have them made again.

What and why

To make a video more accessible, WebAim recommends having both captions and transcripts.

A caption is like a subtitle, but in the same language as the video. It contains whatever is said in the video, and other sounds, such as laughter, applause and description of any music that is played.

A transcript is a textual alternative for audio and video. On the Fronteers site, we use the content of the caption file and display it underneath the video.

Captions and transcripts can benefit:

• people with partial or total inability to hear
• people for whom the video’s language is not their first
• people who do not have time to watch the video, prefer reading it or want to search for a specific thing a speaker said
• people watching the video in a noisy environment
• your website’s SEO optimisation strategy for search engines1! (really)

Amara via Vimeo

For our transcripts this year, we have been making use of a service called Amara. It is integrated into Vimeo, which makes the process of ordering very convenient (we host our videos there).

We used Amara’s paid service, but, at the time of writing, they also give users access to their editor on Vimeo, so that they can DIY the transcripts. Or you can access the same tool on Amara.org and subtitle videos hosted anywhere (many formats supported). Both are free, but cost more time per transcript.

Amara is bigger than just their Vimeo integration: they are a project of a not-for-profit organisation that aims to ‘build a more open, collaborative world’. In this post I will focus on how to do it with the version built-in to Vimeo.

The process

The Amara service can be used from within Vimeo. The way it works is that, as the uploader, you go to your videos’ settings and under “Purchase Amara professional services”, you click “Purchase”. You then select the language that you require, choose a price tier and enter payment details.

You can also add a comma separated list of technical terms, to make sure the transcript reflects their spelling correctly. As an experiment, I decided to leave this field empty.

Purchase button on Vimeo

After submitting a video for transcription, each one took 3-6 working days to show up. The week after I had ordered them, they kept slowly coming in, giving me the time to check each one (see below). The quality was surprisingly good, with only very few minor corrections needed. This was despite not supplying a list of technical terms.

When we were happy with the transcript, we also uploaded the video to our own website, where we included:

• the video (as a , obvs)
• the subtitle file as captions (a )
• the transcript (which in our case was just the captions file as text)

(Example: Digital governance by Lisa Welchman)

In the front-end outputted by our CMS, Krijn built something nifty to make it so that when you click a sentence in the transcript, the video skips to that part of the talk. Check out the example above to see it in action, it is very cool!

If you want to do something similar, it is good to know that the caption that shows up in Vimeo can be downloaded as a WebVTT file. This is ‘just’ a text file with time stamps and sentences, so it can be opened and updated in a text editor of choice.

QA

In our case, we paid for our transcripts. The results were very good, and almost ready to go live. Just before that, I have gone through a few steps manually for each transcript:

• search for [INAUDIBLE] and have a listen to see if it really is inaudible. Sometimes it was added when the speaker said a technical term very fast (gulp.js, console.log())
• search for [?, these are words that the transcriber was unsure about. Again, these could be technical terms. If the video is about web development and you’re a web developer, you can likely fix it.
• scroll through and gloss over the text

!/_images/vimeo-amara-.jpg(Amara interface on Vimeo)! Amara’s handy interface to check and adjust your captions

Some notes

• At the time of buying, Basic, Professional or Full Service captions were priced at $1.70, $2.80 and $3.95 per minute respectively (difference is in how many proofreaders are used), so it is not very cheap. A conference video (45-60 minutes) will cost between $100 and $150.
• From the Vimeo interface, you cannot get all languages transcribed. Our conference videos were in English, which was supported. Many of our meetup videos are in Dutch, which is not supported.
• I was amazed at how good the transcribers were at getting technical terms right, words like SVGOMG, Sass and JavaScript were spelled and capitalised correctly and consistently so. Ideal for when pedantry does occur within your target audience!
• Using Amara’s “Professional” tier, leaving the technical terms field blank still gives great results
• We used Casting Words in the past, they work out slightly cheaper and offer integration with FTP and an API (but are not built into Vimeo)

So, that’s it. I hope this helps conference organisers in deciding whether and how to transcribe their conference videos. If you have experience with other services or workflows, please do leave a comment below.

Edit 26/01/2018: unfortunately, it is no longer possible to do the above through Vimeo.

---

Originally posted as Making conference videos more accessible on Hidde's blog.

Reply via email

In his talk at Beyond Tellerand last year, web designer Brad Frost talked about the website “as an instantiation of your design system”. I really liked that idea.

Design can be defined by many things: it is a thought process, the result of abstract thinking, something that requires research and a sense of style. From a practical point of view, it can be described in terms of the materials it is made of. Paint, wood, glass, ink… This is slightly different for web design. Web design, in particular, is made of some very specific materials: HTML, CSS, JavaScript, typefaces and images.

Design on the web, more than any other type of design, can be documented in a way that is powered by the materials it is made of. Pattern libraries can do this.

Pattern libraries

A pattern library is a set of components, in which each component can include:

• Documentation
• Mark-up in HTML (or Twig or Haml or Mustache)
• Style in CSS (or Sass or Less or Styles)
• Scripts in JavaScript (or Coffee Script)
• Images

Each component has at least documentation and mark-up.

The set of components, as a whole, describes the design system that exists in your website. The components, plus perhaps a couple of files like typefaces, a logo and an icon set (although they could be components of their own).

Advantages

The advantages of separating your design system out as front-end components are plentiful:

• great reference for all people involved in the project
• potentially a better workflow, as there is only one place where common patterns are created
• easier to spot and avoid inconsistencies in both design and code (‘Oh wait, we’ve already got a datepicker!’, ‘Actually, we can reuse most of that existing markup for this new button style’)
• more testable as everything is abstracted and nicely separated and organised, this makes it easier for a script (or anyone) to test

Zombie style guides

To create a style guide as an overview of your website’s design system and the corresponding code is one thing. To maintain it, is another. In her Fronteers 2015 talk, Anna Debenham referred to a phenomenon known as zombie style guides, style guides that live separate from the web project they power, and are not actively maintained. They are no longer as useful as they were at the start of the project.

To avoid that, a style guide should be what powers your actual website(s), so that your website(s) become instance(s) of your design system.

The website as an instantiation of your design system

This is what Brad Frost suggested in this talk at Beyond Tellerand in Düsseldorf (Video, scroll to 39:00):

“The website is one instantiation of your design system”

I think this brilliant. In the ideal set up, there is a set of components, and then those components are used in places. The set is built, updated, improved, refactored etc separately from the places it is used in. The website, but also a front-end style guide are just examples of places.

Brad quotes Nathan Curtis:

“A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.”

Copy/pasting mark-up vs “real” instantiation

One way a website could be an instantiation of a design system, is if all markup in the site is copied from the style guide. The copy/paste method is easiest to set up.

A much better and more ideal way, is if the site uses code to grab a copy of the actual markup for a component. This markup could live in its own repository so that it can be modified, refactored and improved. For example:

includeMyComponent('button', { text: "Click here" })

could render as this today:

<span class="button">Click here</span>

and render as this tomorrow, after an update to the component library:

<button class="button">Click here</button>

New mark-up, same include function.

The holy grail, Frost concludes, is a “magical setup” that contains “all the lego bricks of a site”, and if we make a change, anywhere that lego brick is updated, it just magically updates. Like the example above. Ian Feather and his team at Lonely Planet have built a system that can do this, with their API for components.

The front-end style guide

The front-end style guide, like the website, can also be seen as an instantiation of the design system. It is just another place that consumes your organisation’s set of components.

Documentation

There is one important difference though: a front-end style guide should, in my opinion, serve as documentation. So not only should it consume the components themselves, it should consume components with their documentation.

The person who builds a component, will have to write its documentation. This is essential, as a few month’s later, they may have left the team. Or they may still be on it, but have forgotten about what the component was for.

Documentation of a component should explain what it is, what it is used for and what its options/parameters are.

Conclusion

To summarise my thoughts: I think web design is a special type of design as it can be documented with the same materials it is made of: markup, stylesheets, scripts et cetera. This can be done by structuring the design in the form of a system of components. This system can then power both the website and a showcase of documented components. Statically, or, ultimately, dynamically.

For more info on different types of style guides and approaches to building ones that ‘live’, I can recommend watching Anna’s talk at Fronteers and Brad’s talk at Beyond Tellerand:

• Anna Debenham – Front-end Style Guides (Fronteers, Amsterdam, 2015, includes transcript so you can read instead of watch)
• Brad Frost – Style Guide Best Practices (Beyond Tellerand, Düsseldorf, 2015)

---

Originally posted as The website as an instantiation of your design system on Hidde's blog.

Reply via email

JSHint helps you enforce code correctness, whereas JSCS helps you enforce a code style.

JSHint is deprecating its code style related features and plans to remove them from the next major releases (see docs). Therefore, it makes sense to use both JSCS and JSHint. (Thanks Alex for pointing me at this)

---

Originally posted as JSCS vs JSHint on Hidde's blog.

Reply via email

WordPress is used by many different audiences. It is used by people who do not know much about code, as well as by experienced programmers¹. Expectations of plug-ins therefore vary.

Some want plug-ins to automatically do everything. If they use a plug-in to integrate their Twitter stream into WordPress, they expect the plug-in to not only pull tweets from the Twitter API, they also want the necessary mark-up and CSS to display tweets in the front-end. Others will only expect a plug-in to do a specific task, leave front-end hooks for developers to output data surrounded by their own mark-up, styled by their own CSS and made interactive with their own scripts.

My ideal WordPress plug-in is of the latter type. I write my own templates (mark-up, stylesheet and scripts). Then, in the mark-up, I simply replace all dummy strings of text with template tags. My ideal Twitter plug-in, for example, would take care of fetching tweets from Twitters API, and it would then expose an API to output tweet data (the tweet itself, its date, its author, avatars etc), allowing a developer to output the relevant strings of text where required.

When I add a new plug-in (or a client requests one to be installed), I have made it a habit to make sure it does not add any CSS or JavaScript (plug-ins can add assets through wp_head() and wp_footer()). If it does, I usually undo the behaviour and add CSS or script to fit within the existing code.

¹ And some experienced programmers will never touch WordPress (different discussion)

---

Originally posted as Scripts and stylesheets in WordPress sites on Hidde's blog.

Reply via email

CSS Grid Layout has been coming for a long time, browser support seems to be on its way (at last!). This is great news! It means we can soon use ‘just’ CSS to describe our lay-outs. But, arguably, this leaves us with a naming problem.

‘Just CSS’ vs classnames for lay-out

In the current situation, many lay-outs on the web work with a combination of classnames-for-layout-purposes and CSS to go with it. In the future, with CSS Grid Layout, classnames can just declare what a thing is. They then leave it to CSS entirely to describe how the thing is layed out. As Rachel Andrew points out in her recent 24 Ways article, this may mean the end of container, row and col-* type of classnames:

(…) my hope is that it will be the layout frameworks that tie our design to our markup. They have been a necessary placeholder while we waited for a true web layout system, but I believe that in a few years time we’ll be easily able to date a website to circa 2015 by seeing <div class="row"> or <div class="col-md-3"> in the markup.

CSS Grid Layout is awesome, because it would provide web page layout with a separation that the makers of the web always encouraged authors to follow:

• HTML is for what it is (structure)
• CSS is for what it looks like (style)

But I feel that this leaves us with a problem not easily solved: how can we sensibly sname page areas? In examples of Grid Layout, there is usually a header, main content, sidebar and a footer. In reality, there can be lots of different combinations of column widths. There are usually many variations, possibly more than we could possibly come up with classnames for.

Naming page areas

When using classnames-for-layout-purposes, page areas are defined by presentational classnames that do not require further naming. We just name the components inside the containers, and give their wrappers/containers presentational names to form a grid structure.

If we want to peruse the semantic classnames we have added to page areas to lay things out, we’ll need to give them sensible names. We can then apply grid CSS to each of them (and could do this reusably/automatically by clever preprocessor usage).

My argument is that coming up with such names could prove quite hard: what’s a thing called that has a 35% column and a 65% column, in which the latter column is divided into four? Arguably, names like col-6, or even col-md-6 are easier to work with (and yes, I’ve frowned upon them for long).

Making it easy to work with is probably what we are discussing here. It’s mostly an issue between developers, for the browser or user doesn’t experience what we call things. They can benefit from separation between semantic usages of HTML elements and separation of concerns generally, but classnames aren’t read out by screen readers (like a title attribute), used to construct the accessibility tree (like some attributes are) or linked to by users (like IDs).

Conclusion

So I think there are two views, really. Some will argue we should think of our grid as a system separate from the rest of a site’s front-end, and as a thing that we can leave for months without touching it. In this case, when regarded as a separate thing, presentational grid classnames are seen as okay. Others will say grid-structures should just arise from grid definitions that belong to each semantically classed component. Especially for those, CSS Grid Layout will make it a lot easier to do this.

---

Originally posted as Declaring grid layouts with ‘just’ CSS on Hidde's blog.

Reply via email