Last year I experienced Responsive Day Out through its audio podcast (RSS), this year I decided to buy a ticket and travel from Bristol to Brighton for the real thing. It was a varied day, with room for aspects like design, business, information architecture and even CSS specs.

The day was structured in three blocks of three speakers talking for 20 minutes, plus one block of Ethan Marcotte, who came up with the term ‘responsive web design’. The event’s Twitter hash tag, #beepcheeks, was named after him.

Part 1: Stephen Hay, Sally Jenkinson and Ida Aalen

In the first session, Stephen Hay introduced us to the method of ’sculpting text’, Sally Jenkinson discussed aspects of responsive web design beyond just designing for different screen widths and Ida Aalen shared her experience working on a large responsive project for the Norwegian cancer association.

Sculpting text

Stephen Hay explained that text is what underlies the web. Structured text, to be more precise. Structured text is portable, it can stay the same regardless of which device you use to access a web page. It exposes inappropriate and irrelevant content more easily than a full fledged web design comp would. Web designers have been designing containers to fill with text for ages, so that text would be the last step in their project work flows. But if text is the most portable, shouldn’t we really start with text first? Stephen argued we should.

Increase screen size, until you feel the layout breaks, at which point you add a breakpoint

The method of sculpting text, Stephen explained, consists in adding layers of CSS rules to structured text. It can start with styling text on a small width, a ‘single column grid’ if you will. Start simple. To structured text on a narrow screen you can do things like colour, typography, spacing, et cetera first. Then you increase screen size, until you feel the layout breaks, at which point you can add a breakpoint. You can then introduce things like columns. Sketching is helpful when trying to come up with solutions for larger screen widths.

Sculpting text first and coming up with a canvas later in the process, rather than designing a canvas to put content in afterwards, will help designers understand what they are designing. As a methodology, it helps us cope with the multi device world they design for, Stephen argued.

A more in-depth discussion of responsive design workflow, can be found in Stephen’s book with the same name, which I recommend reading, or have a look at his slides.

Responsive planning

Sally Jenkinson emphasised that responsive design is not only about designing for multiple screen widths, it is also about being very good at planning, not being afraid to experiment and making the right choices.

Our choices have great impact

The choices web designers and developers face, Sally argued, can have large philosophical and ethical impact. A developer often makes choices that impact what a user experiences. This can include ‘invisible requirements’, like progressive enhancement. The decision to make a website ask for a user’s location, may feel awkward or unnecessarily invade their privacy, especially if the app does not evidently require location.

Sometimes we should make choices or do things that aren’t part of our job descriptions. Planners can try out new technologies, rather than solving problems with solutions that we happen to be used to. Choices should not be about what is beneficial to us as designers, developers or businesses, they should be made with the bigger picture in mind. It is about end users ultimately, we should avoid ‘narcissistic web design’, Sally advocated. And we should avoid making choices that invade our users’ privacy.

The core model

Ida Aalen described the ‘core model’ for information architecture, and spelled out how it benefited her team when working on the website for the Norwegian Cancer Society (lang=no). (Slides)

In information architecture, which is a lot about users navigating, it is important to note users will often not (want to) navigate your site. They often just look at one page, coming in following a Google search or a link on Facebook.

Core pages serve both business and user needs

Ida talked about the overlap between business needs and user needs. Some pages only serve one of the two, some serve both. Those are core content pages. An example she discussed is a page about lung cancer: it serves business goals (informing people, sharing knowledge) as well as user needs (getting to know more about symptoms, prevention and treatments). From core content pages, one can think about pages that precede it, and those that can lead a user to elsewhere. The core content is the same on all pages, regardless of device used.

For the Cancer Society, a lot of time was spent on mobile. Ida shared some data on usage. Users visiting with small screens spent roughly the same amount of time on the site as those with large screens. Conversion rates did not differ much between screen sizes used, so it was worthwhile to spend time on designing for all screens.

Part 2: Rachel Andrew, Dan Donald and Inayaili de León Persson

In the second session, Rachel Andrew talked about the CSS Grid Layout Spec, Dan Donald considered the flexible web and Inayaili de León Persson shared her experience of making ubuntu.com responsive.

CSS Grid Layout

Rachel Andrew discussed the new CSS Grid Layout spec. Since it was originally proposed by Microsoft and used in IE10, it evolved a lot.

Rachel discussed different ways of defining grids in CSS, using Grid Layout. There is line based positioning, and the use of grid area names, also known as ‘defining grids in ascii art’. For components you specify in which areas they should be displayed. Then, on the wrapper they are in, you define where those areas are. To see how it works, have a look at her code examples or her blogpost about the subject.

She also explained how grid layout differs from flexbox: whereas the former is most suitable for full page layout, the latter works best for smaller UI components.

The flexible web and element queries

Dan Donald talked about building for a flexible web. In particular, he talked about flexible components using element queries.

Element queries are media queries that respond not on a document level, but on a component or element level.

Element queries are media queries that respond not on a document level, but on a component or element level. Currently, they exist mostly as a concept, i.e. there is no standard with browser support. Nevertheless, it is possible to use the concept in web pages today. Dan explained how he did so in a project for BBC, using data attributes to specify queries, a bit of JavaScript to make them more flexible and, of course, CSS to define what to do at breakpoints.

Realistic responsive design

Inayaili de Léon Persson showed us what she learned when working on the responsive version of Ubuntu.com. At the time, the team did not have the luxuries of starting from scratch, or working on it full time. The mark-up and content had to stay the same, and the team had to squeeze the project in between their other duties.

Inayaili explained that when making a site responsive, it is often not only about just that, there are many priorities, goals and needs. The team behind Ubuntu.com benefited from buying some of the most used devices, using Basecamp to document as much as they could and making clever use of stuff others had done, inside and outside the organisation.

An interesting step in the process that Inayaili described was the writing of ‘responsive rules’, like ‘Content that is divided in half or thirds should convert into single column when it becomes too narrow’. See also Setting the rules in the series Making Ubuntu responsive on the Ubuntu site.

Part 3: Oliver Reichenstein, Kirsty Burgoine and Stephanie Rieger

In the third session, Oliver Reichenstein proposed a better way of structuring websites, which his company recently employed for The Guardian, Kirsty Burgoine shared how her responsive web design process developed and Stephanie Rieger dived into new media queries.

The container model

Oliver Reichenstein explained that making information easy to find for users is hard. Most information architecture starts from the homepage down, with lots of diverging branches. These kind of trees can be very sturdy. Home pages and sidebars are often full of stuff, because of politics.

The alternative [to sturdy information architecture] is the container model

Oliver Reichenstein explains the container model (photo by Marc Thiele)

The alternative is the container model: have containers with specific content and decide where to put them. Containers are full width and horizontal, pages can have a series of containers stacked up.¹ Containers are self sufficient and can appear anywhere. On a news site, a container can be a world cup section, or a top news section. The article is a container, the comment section is a container. Container based design is without columns, but you can put content next to each other, if the content is comparable, for example a top sport section next to top politics.

The container model is to avoid pages where lots of unrelated bits of information are placed next to each other, just because there is a sidebar that can be filled with content. Responsive design or mobile first forces us to have priorities. We should stick to those priorities when working up to larger screens. If you work up from mobile to larger screen, you should still not put lots of random content to fill up space.

Oliver’s company Information Architects helped newspaper The Guardian implementing the container system on their new site, which is currently in beta. But the model is not only useful on news sites, it works for e-commerce and corporate sites, too, Oliver stressed.

¹ Blogpost about the container model at The Guardian

Responsive deliverables

Kirsty Burgoine shared various approaches her business tried when making responsive websites. She also discussed the importance of trust.

All approaches shared that the website was going to be responsive. The first approach was not telling the client, and surprising them with the fact that the website worked on mobile. It resulted in happy clients, but it had a steep learning curve and caused unbilled time. The second approach was to tell them about responsive design, but not to promise anything. The good thing was that her workflow could stay roughly the same. The downside, that it required a lot of trust from clients. The third approach was to dive straight into code, and do HTML early. It made Kirsty happy as a developer, but clients would have hardly any deliverables. The client would have to have trust, without seeing what was being done.

The fourth and final approach was a very practical one. It embraced the chaos that making responsive websites can be. There were lots of different deliverables, or in lieu of them, sharing of ideas. Regular meetings were held to make sure the client was still on board.

The future of CSS media queries

Stephanie Rieger went into some of the new media queries that are being discussed.

There are proposals and drafts for media queries based on user’s JavaScript support, light level, the kind or lack of pointer, ability to hover, screen’s update frequency and overflowing capabilities.

Stephanie also discussed additional media queries that she thought could be useful, including one to see what language a device can use (Chinese interfaces need less space for words then Western ones, as less characters are needed).

Another interesting thought Stephanie shared was that of a browser built-in navigation system, that would just expose the page’s nav items via a control that is best for the device. For example, a phone could have a built-in hamburger icon to open it, a Google Glass could have a speech command to request it.

Part 4: @beep

The last talk of the day was delivered by Ethan Marcotte, who gave the idea of designing flexible web pages its thoughtful name. His talk, which I was lucky enough to see him do at CSS Day earlier this month, was about being lazy. Or, as I would rephrase it: keeping things simple. According to Ethan, being lazy is the only response to the increasingly complex web we work on, with its multitude of devices, connection speeds and interaction models.

He showed some ideas for being lazy about lay-out: the padding trick and nth-child for infinite grids with relatively simple CSS. He also discussed frameworks. On the web they are often too descriptive, too ‘heavy’. In a broader sense, there are examples of great ‘frameworks’: Disney’s 12 principles of animation (video), the Whitney museum with its logo that can have infinite variants, all based on one simple rule, and Karl Gernsters idea of set of solutions rather than just solutions.

Ethans talk made a lot of sense to me. The multitude of devices, connection speeds and interaction models is a fact. There are roughly two ways of dealing with this fact: designing a solution for each of them, or designing a few simple rules that automatically deal with all of them. The latter works for Disney or the Whitney museum, and it is sensible to say it will work best for us, working on responsive web design.

Round-up

Throughout the talks it became clear that responsive web design is now just web design. The great variety in devices people view the web with has influenced web design a lot. In a good way. It has lead many of us to do away with assumptions, and begin to build more solid websites. The idea of separating structure, style and behaviour is definitely not new, but seems to have become inevitable at last. It is key to a great responsive workflow. This starts with structured text, as Stephen explained. Responsive web design also lead us to radically change workflow and planning, as Kirsty, Sally and Inayaili discussed. The surge of small devices with browsers forced web makers to think about priorities in content and navigation, as Ida and Oliver discussed. New standards and ideas, like those discussed by Rachel, Dan and Stephanie, will help us cater even better for a multitude of devices, but we should not just use new technologies for the sake of it, like Sally emphasised.

Responsive Day Out 2 was one of my favourite events this year. It was simple: no lunch, no WiFi, no coffee, no after parties, but also: a low price. And admittedly, good coffee or food is never really far away in Brighton anyway. The format, 20-minute talks, worked well. It resulted in a great variety of subjects. There was a good balance of theoretical/conceptual talks and practical case-study like talks.

---

Originally posted as Responsive Day Out 2 - the squishening on Hidde's blog.

Reply via email

“Museums Get Mobile!” was a one day event on designing mobile experiences, aimed at managers, curators and consultants in the cultural sector. It was organised by the UK Museums Computer Group in MShed, Bristol.

The day kicked off with a welcome from the organisers and a short talk from the sponsor, about the advantages of apps. This was followed by the first keynote: Clearleft’s Andy Budd.

Andy Budd – Responsive design is easy

Andy Budd started off by claiming that responsive design is actually quite easy, quickly adding ‘as long as you have been paying attention’.

He took us through the various stages of the history of web design, going for flexible to fixed to flexible and responsive. He showed the very first web page, that was just text, had no CSS and was therefore already responsive. It could be accessed from any kind if device. This is no accident, as the web was envisioned with universality as its underlying principle. Paraphrasing Tim Berners-Lee, it should be accessible from any kind of hardware that can connect to the internet. Along came designers, and they messed it up. Designers have been breaking responsiveness by placing content in fixed width containers.

Embrace the flexibility of the web

There have always been voices that we should embrace the flexibility of the web, most notably John Allsopp in his [classic] article A Dao of Web Design: “we should embrace the fact that the web doesnt have the same constraints [as print], and design for its flexibility”.

Just like people thought tableless CSS sites would never become the norm, some people still think responsive design never will. Andy emphasised responsive design definitely is the future, as it is the most sensible thing to do.

Andy briefly discussed apps versus websites, and was in favour of the web, arguing from statistics. The chance someone will visit your website is much higher than that someone will go through the whole process of finding, downloading and installing your app, especially if they rarely ever visit. Secondly, a problem with apps is that there are a lot of different ecosystems: iOS, Android, Windows Phone, Blackberry, and so on.

Responsive web design can be regarded as a logical next step in the history of web design. There were fluid sites, then fixed sites designed for fixed widths, then half fluid sites and now fully fluid and adaptive sites that are meant to work everywhere.

It started to be used in personal projects first, and quickly made its way into commercial sites, The Boston Globe being one of the first. A great example of a responsive museum website is that of the Rijksmuseum [see also the case study of the new Rijksmuseum website at Fronteers 2013.

Being such a logical next step, for front-end developers, responsive design is not so hard, especially if you have been paying attention to things like fluid design. If you haven’t, it may snuck on you. Learning responsive design from scratch is probably hard and scary, as there is a lot involved.

Organisations have to make their sites responsive. “Wait and see” is not a great strategy, your competitors will get ahead of you. “It’s hard” is not a valid argument. Yes, it will take extra time (and budget), in our [Clearleft’s] experience about 10% more. But if 50% of your visitors visit from mobile, which is likely to be the statistic in 2014, is spending 10% more to reach 50% more people really so bad? Why spend 100% of the money on 50% of the people that access your site? As a museum, you would not discriminate against sex or race, why discriminate mobile users?

Responsive design is not designing three versions for mobile, tablet and desktop respectively. It is a way to pour your content in as many as possible ‘glasses’ (Andy visualised content as water, and devices as glasses). Responsive design demands you understand your content.

Our job is not to dictate design, it is to hint design

In responsive design, never think of devices, think of breakpoints instead: optimise where the layout breaks, not where a specific device is used. You have no control over what devices a visitor uses to access your website, what browser they have, what font size they set. Our job is not to dictate design, it is to hint design.

In a responsive design process, developers and designers should work closely together and talk to each other.

Responsive retro-fitting, the process of making an existing website responsive, does not work well, as it fails to address content problems and does not have the benefits of starting with mobile first. Companies like the Guardian started with a responsive mobile site from scratch, built next to the existing site. It was initially only shown on mobile devices, whilst it was being optimised for bigger screens. It is planned to replace the existing site sometime this year.

Mobile first is a very useful conception to think of, as it can helps focusing attention. There is less space available, so it forces content, marketing and design people to prioritise.

Jeremy Keith would hate me for saying this, but I prefer tablet first, it is a nice midground. You start from a tablet version, them scale up a bit for larger screens and scale down a bit for smaller screens. We are currently taking this approach working with a client.

There are still a lot of issues to resolve with responsive design, an important one being how to deal with images. yay for <picture>

The question shouldn’t be, “when should I make my site responsive?”, it should be “when can I make my site responsive?”

Q: How do you deal with people within the organisation that are convinced they need an app?
A: Mobile apps are part of a healthy ecosystem, but responsive web design is a sensible and logical approach to take. Irregular visitors of your museum will not take the hassle of searching for and installing your app, fans of the museum may like app. You don’t need to talk your boss out of apps, but you should be doing responsive web design as a default.

Ask for forgiveness, not permission

Q: How to ask for budget to do responsive design?
A: Use statistics. Personally, I prefer to ask for forgiveness, not permission. In the project description, don’t make a big deal about it being responsive, maybe call it “has to work on a variety of devices”. That is just very sensible, no one can argue against that. And then when it launches and happens to work across lots of devices, everyone is happy.

Designing for changing museum audiences in-gallery and online

Ivan Teage

Ivan Teage of the Natural History Museum (NHM) explained how the NHM’s approach to mobile caters for the basic needs of visitors.

NHM offers WiFi, which is activated through a splash page that comes up when users try to connect. On this page, NHM can get the visitor’s attention. Analytics are used to see what people are doing and test different content.

NHM research shows 77% of visitors have a smart phone. Many have a tablet, but they don’t bring it to the museum. Before visiting, 1 in 3 visitors research their visit on their phone.

Nearly 10% of the visitors, uses the WiFi, making it a big hit, especially since no efforts were made to promote it. Most use it not to find information related to the museum, but for Facebook.

In 2014, on average, websites will have more mobile visits than desktop visits

As Andy said before, in 2014, on average websites will have more mobile visits than desktop visits. The website of the NHM currently hovers around 44%. There is also a notable difference between pages, some pages are much more popular on mobile, others on desktop.

One of the great challenges NHM faces is that there are a lot of different priorities within the organisation, some “nondigital”.

Frankly green + webb

The biggest aspect in mobile is the organisation. There is a lot of making things for mobile just for the sake of making things for mobile, those are the most challenging projects to work on.

Some regard mobile as a tool. Working on mobile, people tend to focus on choosing tools first, rather than on the actual project. Maybe because it is not very physical, mobile is often called “an experience”.

Let’s look at defining what we have to design before we choose the tool to design it with.

For a specialist (…) it can be heart-breaking to be asked to summarise something in three sentences

For a specialist, for example, a curator who studied 15 years on a subject, it can be heart-breaking to be asked to summarise something in three sentences, they would probably prefer more detail.

Digital services often exist of more than just a website. As they often involve with physical services as well, [like a physical box office in the case of a museum], there are lots and lots of people involved in any given project. It will be hard to get them on the same line, or in the same meeting room.

Two tools to deal with this complexity:

• a digital services manifesto, a set of shared objective like the one GDS released, can be a great tool to push a project in an organisation
• a visitor journey, an outline of every step a visitor can be involved in, to try to understand what the whole experience is like. There are a lot of examples of visitor maps on the internet, from companies like Lego and Starbucks.

Léonie Watson

Léonie Watson talked about accessibility (on the web).

Accessibility is not boring, we can creative visually exciting and creative experiences that are accessible. It is not difficult, it is no rocket science, but there may be unfamiliarity.

Accessibility is usability for all of us.

Everybody benefits from accessibility

Who benefits:

• You do. You can make your content available to more people, you open it up to a larger audience, which makes a great feal of sense.
• We do (us being people with disabilities, like sight, hearing, learning, cognitive).
• Everybody does. The real minority in the world, are just regular people. People surfing the internet wearing glasses or with a hangover, or people who are tired, because their young kids kept them up all night.

There are accessibility guidelines that make sure we can find out what to do, and help to make things testible. BBC recently launched their Mobile Accessbiblity Guidelines.

There is accessibility testing. Some things can be automated, but putting your content in front of people with disabilities will likely be more effective.

There is also legislation. In some countries more than others. In the UK, there is the Equality Act. It does not have any requirements for accessibility, it only says “digital services have to be accessible”, it doesn’t specify to which standard.

Accessibility does generally cost a little bit more. If your people are good and used to accessible best practices, they can do optimisations at no extra cost. But if you want to do testing, which you probably should, it can cost more than other usability testing, for example transport costs.

Retrofitting accessibility is probably just as hard as retrofitting responsive design

It is best to ‘do’ accessibility throughout all stages of the projects. Keep an eye on it as the project goes. It works with waterfall and agile. Test as often as possible, fix as quickly as possible. It is easier and perhaps cheaper to fix things in early versions than it is in live sites. Retrofitting accessibility is probably just as hard as retrofitting responsive design, which Andy discussed. It will cost much more and probably achieves less.

Accessibility is forever, not just for launch. Keep an eye on accessibility after the project goes live, maybe monthly or yearly.

Andy Budd: Five to six years ago, developers were very involved with accessibility, do you think that is decreasing now?
Léonie: Yes, it does get lost in the buzz sometimes, but there are still a lot of efforts and generally the situation is quite good.

Making responsive design a reality: accessibility and content strategies and commissioning content strategies

Andrew Lewis – thinking holistically about mobile-responsive services

Andrew Lewis of the Victoria & Albert museum discussed how they think about responsive web design. A responsive web service is one that adjusts content to your audience.

V&A did a responsive retrofit in 2012.

Responsive design is not about technology, it really is about social behaviour.

Situations in which people use their phone:

• preplanning a visit
• visual diary
• comfy sofa time

Mobile users and tablet users are often the same people. The V&A website optimises for different contexts, orientations and screen sizes.

Dan Goodwin – Collaborative discovery: commissioning a big web project when you’re not sure what you want

Dan Goodwin, UX Director at Bristol-and Cornwall based agency fffunction, talked about kicking off a big web project.

It is difficult to choose the right agency for the job. A traditional commissioning approach could include asking within your network, send out request for proposals, asking agencies to come up with quotes.

But an important thing to note is: in the process of building a website, requirements are going to change. That is a given. The problem with the traditional commissioning approach is that nobody really knows 100% what’s needed.

Working on the Bristol Museums websites, fffunction did a collaborative discovery phase, to make sure all the different requirements were analysed and looked into.

They did a stakeholder workshop, a get together with a selected number of shareholders, getting them to put post it notes on the wall, with things like target audience, principles, content ideas and potential features. It gave a great insight into the scope of the project and what needed addressing. They also did user interviews, which helped testing their assumptions.

During the Q&A, some pros and cons of working agile were discussed. Working with flexible requirements is one thing, agreeing to or getting permission for flexible pricing another.

Shelley Mannion – Learning from mobile experiences in museums

Shelley Mannion from the British Museum showed how (people) interacted with various kinds of devices and experiences within the British Museum.

Contrary to other speakers before, Shelley did have some good experience with apps. Some webbased, some native.

In statistics of the British Museum website, mobile has also grown a lot. It increases reasonably quickly, but not as fast as the first graph showed.

In her talk, Shelley challenged some common assumptions, like “It has to be the latest device”, this really depends on the device you are using. Another assumption she challenged: “the bigger the screen, the more people can stand around it” . They found the maximum seems to be about 3-4 people around a screen, regardless of how big the screen is.

Shelley showed a couple of very interesting examples of projects in which visitors interact with exhibitions. Imagery, videos and URLs will be in the slides, but they were unavailable at the time of writing.

Conclusion

Some important takeaways of the day were that mobile is here to stay, that it will be bigger than desktop in 2014, and it would be ideal to make things universally accessible, embrace the flexibility of the web and have a flexible workflow. It became clear that those things can be difficult and scary, but they will be beneficial in the long run. Some solutions were discussed: more research —into visitors/users as well as into the project scope—, better teams in which designers, developers and content people work well together and always keep challenging your assumptions.

---

Originally posted as Museums Get Mobile! on Hidde's blog.

Reply via email

When trying to improve front-end skills, we should improve our knowledge of HTML, CSS and JavaScript first and our knowledge of specific tools later.

Most of the web is written in three simple yet powerful languages: HTML, CSS and JavaScript. Terminology in job ads and portfolios comprises a lot more: LESS, Sass, grunt, Foundation, Bootstrap, jQuery and the like. They are mentioned alongside the big three, but they really are quite different. The former are the foundation of the web, the latter are ‘just’ tools to do stuff with them. Tools that have their merits, surely. But the only thing that constrains how effective one can use front-end tooling, is how effective one can use HTML, CSS and JavaScript.

An example: CSS preprocessors, like Sass en LESS. They can be incredibly useful and powerful tools for writing CSS, but they require knowledge of how box models, positioning, inheritance and specificity work. Limited understanding of these things can makes things worse if applied through a preprocessor (for instance, unintended nesting). Preprocessors provide power, but it is a kind of power that should be used wisely.

Bower is another example: it can help manage dependencies, and makes it very easy to add new dependencies. This may sound like an advantage, but it makes it too easy to bloat a codebase and complicate a project too soon. Whilst it was easy to add a CSS library through Bower, it is now hard to manage <button> styles as the CSS library does overly specific styling that is hard to override.

Tools like preprocessors and package managers have their merits, but to become a better front-end developer, one should focus on HTML, CSS and JavaScript.

---

Originally posted as Keeping it simple on Hidde's blog.

Reply via email

At State of the Browser in London, a one day event in Conway Hall, organised by the London Web Standards team, eight speakers talked about recent developments in the web and web browsers. Topics included Service Workers, performance, responsive images, web ‘apps’ and new CSS features for responsive web design.

These are my notes of the day.

Fernando Campo & Borja Salguero – Firefox OS: not only promises

In their talk, Fernando and Borja of Telefónica’s Firefox OS team discussed what they have been working on and what their priorities are in terms of new features.

They said the phone is slow, as they focused first on getting it launched and focus now on making it better. It also has few apps, missing features and is hard to debug, but the team is working hard on making it better, faster and stronger.

Recent improvements

What they’ve been doing in the last half year to improve Firefox OS:

• There is an app manager which can be used from Firefox nightly. It helps to check the manifest file amongst other things. There is also a simulator, debugger (which works with either the simulator or a real device if you have one) and profiler (with which you can profile actions).
• In addition to that, two new measuring tools were launched that can help Firefox OS devs to improve performance: Datazilla and Eideticker (with which you can analyse ‘real’ fps)
• They have also introduced more APIs.

Ideas behind Firefox OS

Firefox OS is a project to push the web forward

Firefox OS, Borja explained, is really a project to push the web forward. To do this, Mozilla/Telefónica work together with a lot of partners. One improvement they want to achieve is the exchange of information between apps. Their solution for this is “Inter App Communication”, which helps apps ‘talk to each other’.

In the newest version, your phone will not be a thing you install apps on, it will be more like a browser. Because that is what Mozilla is good at, making browsers. The OS that doesn’t require you to install apps, completely changes the way we work with devices.

More is coming from the makers of Firefox OS, including FirefoxAccounts, your settings in the cloud, and project ‘Loop’ that employs WebRTC to let users call for free. There is also Project ‘Mulet’, which allows developers to do all things related to Firefox OS from the browser.

If we want to know more, Borja explained, there is a lot of documentation available on the Mozilla Developer Network, including screencasts.

At the end of the year new 25 USD devices will be introduced, with all the power of the web, aiming to open the web to people that could previously not afford devices with the same acces to the web.

Andreas Bovens – Intro to @viewport & other new Responsive Web Design CSS features

Andreas discussed some of the lesser known features for responsive web design that are in browsers already, but not used so much yet.

First, Andreas showed the various different browsers that Opera currently offers. There are Chromium-based browsers for Android, Opera Mini based on Presto and the experimental UX of Coast for iOS.

He then discussed four CSS features that are ideal in responsive design.

1. @viewports

The web started off fluid, there was hardly any way to do fixed layouts. Then table layouts came in and fixed CSS widths. Some years later, liquid layout made a comeback, using percentages, max-widths and min-widths. Then, along the lines of the fluid trend, came responsive web design, employing use of media queries and encouring thinking more about different devices. It is now an established way of working.

Karl Gernstner introduced the notion of ‘design programme‘, a set of rules for constructing a range of visual solutions. See also: Lupton, Thinking with type; Kerstner, Programme entwerfen.

Two technologies make RWD possible: media queries and the meta viewport tag. Media queries allow developers to apply CSS rules conditionally, the meta viewport tag allows setting the zoom level (most browsers ‘zoom out’ to display legacy, non-mobile-optimised ). With the meta viewport tag in a page, media queries work as intended.

The whole zooming out to the page width thing started in mobile Safari, and they added the meta viewport tag to allow developers to circumvent the zooming. Soon after, it got implemented in most other modern browsers.

Not a standard

A bad thing about the meta viewport tag: it was not a standard, so people started confusing syntax, e.g. adding semicolons instead of commas (eventually both ended up being supported). As there was no standard, edge cases are now handled different by each browser. Some features are not supported everywhere, e.g. user-scalable=no, so you’re never sure whether things will work or not. Android added target-densitydpi, which Opera also added. Internet Explorer implemented device-width as 320px as that was the original iPhone width. Safari zooms in 1.333% in landscape mode, which could be avoid by (their propriety) initial-scale:1 rule. Then Apple came up with minimal-ui properties. Anyway, end of rant, Opera decided to write a spec for viewport.

To standardise the things the viewport meta element did, Opera wrote @viewport as a CSS spec. Settings that you can set with the meta element can now be set in CSS. [Sidenote Yoav Weiss added to his talk: if you use @viewport in CSS, set it an inline <style> -element, as otherwise it will mess with things, including responsive images].

Example:

@viewport {
  width: auto;
}

In some senses @viewport is better than the original meta tag, and for sure it is better documented as it is a standard.

If you want to try it out now, you turn it on in Opera or Chrome flags and you can play with it. Currently, it would be advisable to use both as support for @viewport has hardly landed in browsers.

2. Resolution media queries

When devices with higher pixel densities came about, they started interpreting 1px in CSS as 2px on the device, for example iPhone 4 interpreted 1 CSS-pixel as 4 device-pixels. This makes fonts and vector graphics look very pretty, but can make bitmap graphics look blurry.

Resolution media queries can use ‘dots per px’ units (dppx).

Example:

@media (screen and min-resolution: 2dppx) {
  .thing {
    background-size: 50%; 
  }
}

@media (screen and min-resolution: 3dppx) {
  .thing {
    background-size: 33.33%; 
  }
}

<p>This technique is similar to <code>device-pixel-ratio</code> that works in some browsers, except this one is standardised. It is in some browsers, and not behind flags so can be used today (but it is not available everywhere yet). </p>

<h3>3. object-fit</h3>

<p>New <span class="caps">CSS</span> rules: </p>


```css
object-fit: fill;

object-fit: contain;

object-fit: cover; 
overflow: hidden;

These features are very useful to make small adjustments to images. They were already possible on background images, but not on inline images.

4. Viewport percentage widths/heights

Units: vw, vh, vmin, vmax

Think of your canvas as a 100 by 100 units, then vw and vh are those units, e.g. 50vw would be half of the width of your canvas.

Opera was heavily involved in all four, both at spec level and implementation level.

Ruth John – Browsers at play

Ruth builds interactive prototypes at 02. At State of the Browser, she showed some great things she built.

VJ’ing with CSS Animations and WebAudio API

When she was at uni, Ruth used to be a VJ. Recently, she thought, with all the cool things now possible in the web (CSS animations, WebAudio API), can I recreate the visuals of those days in the browser?

Ruth showed various demoes, including one that heavily used the Web Audio API (recommended reading: O’Reilly’s book on this subject). It allows you to control volume, create sound and analyse sound. The latter, Ruth used to create graphics that responded to changes in a music file.

With getUserMedia, microphone input can be analysed in JavaScript, using the Web Audio API. Ruth showed a cool demo in which graphics responded to her voice.

Demoes online: dancing.rumyra.com/shake-n-track dancing.rumyra.com/vibrate

Jake Archibald – Network connectivity: optional

The web is in a state where developers do dirty tricks to get you to go to download their native apps. “Why is that, why are mobile apps still preferred to the web versions?”, Jake asked.

Some reasons:

• availability offline
• server push
• background synchronisation
• geo fencing
• payments
• performance
• ‘app presence’

The web is really exciting, said Jake, as people are currently working on implementation of all of the above.

To improve performance, the 300ms double tap delay was removed from Chrome and Opera (soon to be removed in Firefox), for whenever a screen is small and the device-width meta tag is used.

To improve presence, so that the app can be in start menus, home screens, status bars, etc, the app manifest spec is being written at the moment, describing a way to have a json file with properties of apps, to make all the different <meta> elements that are currently used to do the same, obsolete.

Service workers

To improve offline availability, service workers are coming! There was, of course, AppCache. It tried to create shortcuts for a destination it didn’t know, it was hard to know what to expect from it and its API was too complicated.

We should treat online as a progressive enhancement to offline, and work ‘offline first’. That way, cached content is shown first, whilst making a request to the network for fresh content. When that network request fails, the cached content will still be there; if it succeeds, there will be fresh content.

Service Workers are reactive, not predictive, as AppCache was. It will try stuff and see what happens. The advantage of that is: if the thing it tried does not work, fallbacks can be added, making it very suitable for progressive enhancement.

What the web can do vs what apps can do

Native app developers can do everything, the web can sometimes feel like a massive can’t. Packaged apps are not the solution, they are interim, until the web has improved and become better. Native will always be better on their platform, the web will not win on that front. But it will win in being more accessible and much more widely available.

Martin Beeby – High-performance web platform

Martin Beeby, developer evangelist for Microsoft’s Internet Explorer, explained how to improve performance of websites, and what to keep in mind when building for Internet Explorer 11.

Things limiting speed on the web are bandwidth, latency and data plans.

Perceived performance is the most important to optimise. An important part of this is the use of memory. Inefficient use of memory can be a problem for performance, but also for the user’s hard drive life expectancy. Most of the memory websites take up is taken up by images.

Power consumption is something to think about as well, as it is about the user’s battery.

New website: status.modern.ie to give community more insight in what features the IE team considers supporting, as well as what’s already built in.

Microsoft built two tools to measure performance: the F12 dev tools, in IE10 and more even in IE11 this has improved a lot. There is also the Windows Performance Toolkit, which can be used to measure any app on Windows.

Performance improvements that can be made:

• One of the most important performance optimisations are in images: often images for mobile do not have the right size and this can take a long time (not only downloading the images, but also image decoding).
• Defer script execution: put scripts in the footer, or, if you put them in the top, add the async/defer attributes.
• Reduce number of frameworks: not only because they would have to be downloaded, but also because they have to be garbage collected
• To fix items don’t add timers or events, they fire at the wrong timing or too often (e.g. scroll), use requestAnimationFrame (fires whenever the browser is ready to paint the screen, and can therefore be a lot smoother than something that fires each time the user scrolls)
• use CSS animations, not JS animations where possible
• use JPG instead of PNG where possible, JPGs have a huge performance benefit
• keep in mind: download size vs memory size. Memory size needed to store an image is often bigger than the image download size: width * height * 4, roughly. Copying an image from memory to gpu can relatively take quite a lot of time. In IE11, JPGs are hardware accelerated.
• when you develop on mobile, use a ‘low end first’ approach.

Yoav Weiss – Brace yourselves – responsive images are coming

Responsive images is to ‘efficiently load propertly dimensionsed images that fit the pages design’. My main concern is with performance here, we cannot be developing websites for 550$ smartphones only.

vs srcset

<picture> was thought up by the responsive images working group, Hixie of WHATWG did not like it and added, without much public discussion, the srcset idea. Two years later, both will be implemented.

Tab Atkins came up with src-n, apparently over a bottle of wine. It was great for discussion, this time amongst browser vendors, which was good. Then, the original picture syntax was redefined, with a new proposal that can make everyone happy. Now the Responsive Images Community Group and WHATWG are working on it together.

Yoav is implementing it in Blink, Mozilla are also working on implementing it it. Should be there in a couple of months.

picture 2.0

Usecase 1: bigger images for high resolution devices / the ‘retina’ use case

<picture>
  <source media=”mq” srcset=”/path”>
  <img/>
</picture>

There can be multiple <source> elements, the srcset attribute can have more than one image.

In Chrome, the srcset attribute works on <img> elements today.

Use case 2: art direction, in case you need multiple images to be properly cropped for different layout)
Use case 3: mime type fallbacks (jpgr, webp, jpeg2000 are formats that only work in some browsers, they would need a fallback)

An image element is always required, otherwise the picture will not display.

The sizes attribute, variable widths

Use case 4: variable width images

‘Picture is a magical span, nothing more’ said Tab Atkins. You should not try to style it using CSS.

When looking up what ‘w’ means, look at the picture spec, as the ‘old’ syntax is quite different.

If you want to play with <picture> and srcset today, there is a polyfill available: Picturefill 2.0 was released by the Filament Group, it is officially spec compliant.

Dan Donald – What it means to be flexible

Dan Donald explored what it means to build websites in a flexible manner.

Responsive web design is a recipe for managing and constraining the fluidity of the web. It is a recipe in the sense that it leads to a lot of improvements to the web, like responsive images.

An example of flexibility: the nature of breakpoints. They are a tool to describe change. Are we designing for content or devices? One can use device-oriented breakpoints, but they make the assumption that we can rely on devices having the same widths. Another option is content oriented breakpoints.

When using device breakpoints, we get a conflict with the universality principle of the web. There’s little to no correlation between viewport width alone and devices.

We have a breakpoint purpose mash-up. We work in a world of assumption, but what do we really know? E.g., the user agent string we get on the service side, is full of lie.

An important concept within building flexible pages, is the ‘element media query’. It does not currently exist in a standardised form or in browser implementation, but that did not stop various developers from building their own JavaScript solutions. Dan showed us his.

Chris Heilmann – Open web apps

Chris talked about the open web, and about what Firefox OS can mean within the context of the open web.

Open Web Apps: manifest file that says what your app is/does. Apps are a better form factor for devices (then URLs).

What makes a good app? Why do people download a calculator app, rather than typing their calculation into an online tool like Google?

• focused (it is full screen)
• mobile (it works offline)
• contained (you can delete the icon to delete the app, you can send it as one thing)
• integrated (it works together with the OS and has hardware access)
• it is responsive and fast

Can all of the things that make apps great be done in HTML?

A great app does one thing and do that one thing well. Simplicity is what makes app so popular.

Service workers is the most important thing at the moment, offline viewing is a very important thing that needs to be solved.

Go low in your testing, do not test on too fast connections, as the web is universal and it would be bad preventing people with low bandwidth connections from accessing your website.

Everyone with an FTP connection and text editor can work on Open Web Apps, not just rich kids in Sillicon Valley that can pay 99 dollars and buy the newest devices to test on. That’s not the web!

Q&A

Throughout the day, attendees could ask questions via Twitter and to the organisers. After the last talk, Daniel Appelquist confronted the speakers with some of the questions that were asked.

(Answers are based on my notes, and should not be considered to be literally what the panelists said).

Q: How will HTTP2 change any of the thinking about responsive web design thinking?

With HTTP2, combining all your JS into one file will become an anti pattern […] the same goes for sprited images

Jake: HTTP2 will turn a lot of good practices into bad practices, for example, starting a new request would be less of a deal. Combining all your JS into one file will become an anti pattern, lots of small files will work much better. The same goes for sprited images.

Yoav: Today, the browser has to download everything to get started, which today is good because it saves HTTP requests, but if that is no longer needed, it will be better to have many small files.

Andreas: I agree, best practices like sprites will have to be rethought. This will mostly be an education problem, we will have to ‘unevangelise’.

Chris: Most people use build processes nowadays, and an advantage of that problems like this can be solved by adjusting those tools. These things are already abstractions, so we only need to adjust the abstractions.

Q: How can we be a web industry that women don’t feel alieniated in?

Martin: All I can do is not be a dick, that is the only thing I can have control over.

Ruth: It is an issue. I have been lucky, as in most places where I worked, people weren’t dicks. I think it is mostly a social problem. I’ve had sexism and it isn’t nice, but there are worse problems in this world.

Chris: Sites like Codebabes are blatant trolling, they’re not much more than a clickbait. We are not going to solve social problems on the internet by clickbaits. We should not give them a lot of attention in tweets.

Ruth: listen to ‘the science of the sexes’ podcast, it is a great resource.

Q: Everyone keeps talking about “the web platform“, what is a platform and should we want the web to be a “platform”?

Chris: The web is an opportunity for people to publish on, it is a way to spread information in a world wide manner. It is a set of technologies.

Andreas: It is just a matter of naming. We have called it ‘web standards’, and later internally at Opera we called it ‘the web stack’. Some use the word ‘HTML5’, maybe ‘platform’ is a better term for it all. Whether it means something deeper than that, I’m not sure.

Q: How can we make the web platform a better platform for games?

Ruth: That’s a really good question, but very difficult to answer. We already have things that are amazing at games, like Xbox and Playstation. I think we need to build a lot more to show what is possible. The Audio API and Vibration API i talked about seem great for games.

Martin: we [at Microsoft] go to lots of game developers, at big companies, but also indie game developers. I don’t know much about game development, it is a very different world. Interesting is what is happening with WebGL, not just for games but for parallel computing in general, it it has implications for lots of things outside gaming as well. It is very complicated though, hard to learn.

Chris: It is a different world, like native vs web. Gaming is a speed test, if we can get games running on web technology, we can learn from it for other applications of the web.

Q: How will Web Components change the way we work on the web?

Chris: Web Components are an amazing opportunity, they allow us to write proper widgets on the web. Whatever HTML you were missing, you can now actually write and publish yourself. It allows for widgets that are running with the browser and not against it. They becomes part of the browser. Jake had a talk about a tabs component some years ago, that is one to watch again. [I think Chris meant Jake’s talk ‘Reusable code: for good and for awesome’ at Fronteers 2010. Video / transcript and slides

Jake: Web Components are an important part of the extensible web. For someone new to HTML, it was weird that

and

looked different — CSS helped to explain why this is. Developer tools in modern browsers to this with things like performance waterfalls. Service Workers does a similar things to help understand the network. Web Components will help to show why things render the way they do. Libraries like jQuery UI that change a <div> into a widget will no longer be needed, you could just have a new element doing a widget.

Yoav: I’m slightly worried about performance of Web Components, for example in terms of blocking rendering. The browser has to download the import and files within that file and files within that file. We have to make sure it will not become the next @import of CSS.

Q: What is the future state of deep linking from web apps? And into web apps?

Barjo: Haida does that for Firefox OS, it will make the flow more natural for the user, linking will feel more natural like it is in the native OS already.

Jake: We can’t lose the URL.

Andreas: I agree. URLs are the power of the web and an advantage of the web over native apps. The web can link to apps, but URLs can also be used to link from an app to the web.

Conclusion

I’ve had a great day in London, and enjoyed this very affordable conference a lot. There was plenty to learn and it is exciting to know that a lot of the stuff presented today, will be in browsers in the not too distant future.

Thanks Krijn and Mathias for pointing me at spelling errors in previous drafts of this post.

---

Originally posted as State of the Browser 2014 on Hidde's blog.

Reply via email

Many videos on the web are hosted at third parties and included through an <iframe>. This can be a problem for flexible width sites, as an <iframe> with 100% width will not automatically have a height that respects the aspect ratio of the embedded content.

Forcing an aspect ratio-respecting height

The embedded content will, it its simplest form, be like:

<iframe/>

The width of the video can be adjusted to the width of its container or viewport by setting a width: 100% to the <iframe>, Because the width is not set on the video element itself, as it can be with inline <img> or <video> elements, the browser doesn’t know what the height should be, as there can be any number of elements in your <iframe>.

Let’s wrap the <iframe> in its own container.

<div class="embed-holder">
  <iframe/>
</div>

The embed-holder will be positioned relatively, so that it flows with the page. Its max-width will be 100% and its overflow will be set to hidden. We add a padding-top to the container to reserve some space for the YouTube player.

Now comes the trick¹: the embed-holder will get a padding-bottom of 56.25%. Using a percentage for the padding forces a height that is relative to the width of the element. If we want the embed to stick to the aspect ratio of 16:9, we need to express that ratio as 100:x. We can calculate that by dividing 100 by 16, then multiplying the answer with 9.

Let’s for now assume videos in the ratio of 16:9. Using the following CSS, .embed-holder will have the correct aspect ratio in any container or viewport.

.embed-holder {
  max-width: 100%;
  overflow: hidden;
  padding-top: 30px;
  padding-bottom: 56.25%; /* ensuring 16:9 aspect ratio; 
use 75% for a 4:3 ratio */
}

<p>The last step is to fit the video into the container.</p>

```css
.embed-holder iframe {
  position: absolute;
  left: 0;
  top: 0;
  width: 100%;
  height: 100%;
}

The .embed-holder acts as the positioning context for the <iframe>. The width and height will be that of .embed-holder, so it will have the correct ratio.

Extra step for WordPress users

If you want to do this in WordPress, one extra step is required.

By default, WordPress creates embeds from any URLs to video services like YouTube and Vimeo. Rightfully, it does not add an extra wrapping element to your code, which is what we need in this particular situation.

To do this, simply add a filter² to the embedding function in your functions.php :

add_filter('embed_oembed_html', 'wrap_embedded_els', 99, 4);
function wrap_embedded_els($html, $url, $attr, $post_id) {
  return '<div class="embed-holder">' . $html . '</div>';
}

This wraps the WordPress-generated embeds into a container, to which the above CSS can be applied.

Please note: this wraps all embeds, including some you may not want to apply a different aspect ratio to, such as SoundCloud.

Notes

¹ This is not my own idea, it has been explained by others. Original idea by Thierry Koblentz on A List Apart (May 2009)

² Function via cubecolour , who also made a WordPress plugin to add both the CSS and the filter)

---

Originally posted as Embedded video in responsive lay-outs on Hidde's blog.

Reply via email