Although it may be very exciting to make new things for the web, it’s important to think about archiving what we have made before. This requires one to think about the long term, and about whom we trust with our content.

Last week, Jeremy Keith held a lecture about digital preservation at Amsterdam’s university of applied sciences. This is a write-up of his talk.

Why keep old websites?

“This is for everyone” is the message that appeared behind Tim Berners-Lee, the inventor of the web, when he made a surprise appearance during the London 2012 Olympics ceremony. The web is meant for everyone. It is there not just to consume, but also to create for, Jeremy said.

Geocities used to be where people with hobbies hosted websites to share with the world what they did. Over 30 million of them. Websites about pets, football clubs, fan sites, you name it. From a web designer’s point of view, they were not necessarily the most beautiful or user-friendly websites. But, Jeremy said, “an ugly website that we find ugly today, may be the first website made by the future president of the United States“.

When Geocities shut down, no backup plans were made. We were looking at the removal of over 30 million websites, to be gone forever. This was a threat. It would have been where archeologists of the 2090s would have found what we were up to in the 1990s.

Other than their cultural significance, existing websites can also break the web if they are removed from it. This is because links to them will break.

Luckily, in the case of Geocities, the Web Archive team stood in and managed to save a large part of these websites.

Third parties

If recent history is an indication, trusting your content to third parties only is not a good idea, Jeremy emphasised. Geocities was bought by Yahoo!, so was Tumblr. Many websites that offer to host your content for you are bought by some big internet company at some point. We trust our content to these start-ups. But rarely, when they close, they offer a way to export the data. They do usually thank you for being on their incredible journey.

Indieweb type of solutions can help here: there are tools that let you publish on your own platform as well as on third parties, so that you always have your own content.

Hard work

The good news is that the web, Jeremy said, is actually very suitable for being preserved. Apps you build now will likely not work on devices from 5 years in the future, whereas websites probably will (as long as someone pays the web hosting bill).

The saying “the internet never forgets” is not actually true, Jeremy explained. The internet does forget, a lot of things get deleted and are then gone forever. One has to work hard to keep things online, preferably on their own URLs (to not break the web).

Preserving your websites requires one to think about the long term: you will have to make sure to keep paying your hosting bills, for one thing. But what about when you pass, are there any hosting companies that will let you include hosting fees in your will? Some compelling questions to think about!

Originally posted as The internet does forget on Hidde's blog.

Reply via email

Yesterday I attended NCDT, the Dutch conference for digital accessibility. Hundreds of people whose work somehow involves digitally exposing information gathered in Utrecht.

The interesting thing about NCDT, I found, is that many attendees work in roles that require them to organise accessibility within their organisations, having to convince management and stakeholders of accessibility benefits. As a front-end developer, I usually only have to convince designers and interaction people. Convincing the whole of a company seems lots harder!

Here are some reasons for accessibility that I heard on the day, in no particular order.

Because we ought to put users before egoes

The excellent Gerry “top tasks” McGovern could not have said it clearer in his talk: “we measure production, not consumption. If we want digital excellence, we must measure actual use”. Many organisations put out web pages because some employee made the page and is excited about it. They put out web designs, because the designer made something pretty and the team liked it. They contain web copy that their content marketeers think provides value. But your website should not be about your employees, your designers or your content marketeers, it is about the users and what they want. That’s what websites should invest in, McGovern said. The users on your website should be put before the egoes in your organisation. Therefore: always be user testing.

Because it could be illegal not to

Users who cannot access your website, could potentially sue you. Eric Velleman of the Accessibility Foundation explained how. He showed there are currently a number of Dutch laws and regulations that make it illegal for companies to have an inaccessible website. Important to note: in The Netherlands, no one actually got one of those laws to be applied to them by a judge. In America however, judges have ordered large companies to pay sums of money and/or make their website more accessible.

More legislation is coming: an EU wide Directive is being implemented by EU member states. The Netherlands also recently agreed it will ratify the 2006 United Nations Convention on the Rights of Persons with Disabilities. The “College voor de rechten van de mens” was appointed as the regulator for this convention, and this will be where people can go to complain if they cannot access a particular site. At this time, it is not clear what the Dutch authorities will do in terms of fines or sentences. It is unlikely, Velleman said, that companies will get sued for inaccessibility.

Because our organisation has embedded inclusive design

Jonathan Hassell talked about embeddding accessibility throughout organisations (he was the main author of BS 8878, the British standard / code of practice on this subject). He said what’s more important than making accessibility checklists mandatory, is valuing accessibility as an organisation. To do this, the top needs to be on board, training needs to be in place (staff might leave), it should be embedded in company policies and it should be in a process that can be used over and over again.

Having accessibility is embedded in all those different ways, can really make it part of an organisation, which can ensure the organisation makes more accessible products, now and later.

Because there is passion for #a11y at the top

Jake Abma, head of accessibility of a major Dutch bank (the orange one) held a talk about how he got support for his radical idea to embrace digital accessibility practices. It was a truly inspiring story. He convinced his manager to get him 2 hours a week to spend on accessibility, this later became 4 hours, a day and even two days. Later others got time too, and currently, the bank has a dedicated accessibility team. They have their own accessibility guidelines (which is a superset of WCAG and other standards), do lots of accessibility testing and have “accessibility champions” across teams. They ensure doing the accessible thing is part of their process (in scrum terms: it’s in their definition of done). At a bank!

Part of what worked is that there were some people in the top of the hierarchy who had visual impairments: there was a passion for accessibility at the top. Otherwise, to get support for spending time on accessibility, Jake explained, is a matter of small steps. Focus on those people who do like the idea and most importantly, do not give up.

Conclusion

I am just a front-end developer. For me, accessibility is usually about practical things like checking the colours that come in from designers, getting my markup semantics right and providing alternatives (in all kinds of ways).

At NCDT, I saw that it is not just about single team members (“we not me”, said Jon Hassell). This makes sense. Especially for large organisations, there can be a lot of company politics involved, and it is some people’s job to work these politics every day.

Originally posted as Reasons to make digital products accessible on Hidde's blog.

Reply via email

A conference about conferences, isn’t that super meta? It is, a bit. Most web conferences aim to bring web people together and inspire them to do better work. ConfConf in Bristol did something similar for those who organise conferences.

Having originally been conceived as a joke between two event organisers, ConfConf became a real thing for the first time last year. It turned out that the event provided real value: with all the knowledge sharing, organisers were able to learn a lot from each other.

This year, the event was held in Bristol, and I attended as part of a group representing Fronteers Conference. The audience was small enough to have group discussions and not need mics, but big enough to have lots of conf-organising experience between them. These are my notes of the day.

The human side of event organisation

Marc Thiele, organiser of the Beyond Tellerand conference in Düsseldorf, gave the first talk. He walked us through his process and the tone of voice he tries to convey.

If one thing stood out from his talk, it is that communication plays a huge role in everything he does. It sets the tone of the event, Marc explained.

He makes a point of being very friendly to every single person involved with his event: attendees (including previous attendees), speakers, suppliers, even the venue staff. Being friendly includes checking in with people, being prepared to patiently answer the same questions over and over and being interested in everyone at the event. This goes a long way. For instance, if you need your A/V to think with you about new ideas, it helps if you get along with them.

Communication is also about being very clear. Marc took us through the various emails he sends to attendees, speakers and others, to make sure everyone has all the information they need.

Getting bums on seats

John Davey, who is responsible for the ‘Reasons to’ conferences, talked about what he does to sell tickets. He recommended selling tickets early, making use of social media (on accounts that matter to your target audience rather than those with huge numbers) and doing so creatively.

John likes people who pull faces and, as his slides confirmed, is quite good at this himself.

He emphasised communication should be provocative (never rude though) and not bland. Creative communication and attention to detail also helps convince potential attendees of the quality they will get.

John gave some tips to increase ticket sales: by setting limits on based on quantity or time, you can create an urgency; you can be loyal to past attendees and email them with a special discount; you can also use the audience of your sponsors for promotion (their coverage/promotion could be more valuable than money).

Panel: all things to all people: striving for the impossible

In the first panel, there were discussions about curating a quality and diverse lineup, single track vs multi track and dealing with criticism.

Some organisers said they think of speaker names first, others think about talk subjects first and then come up with names for each subject. I like content-first, as it makes it much easier to explain to speakers why you want them. This increases your chance of getting speakers to agree to come to your conference.

We also discussed conferences with tracks. Having a single track can sometimes force people to sit in talks they would normally not attend. Marc Thiele said he likes that and tries to play with that. Rachel Andrew recommended that, in multi track conferences, speakers state the experience level at the beginning of their talk, to allow people to leave if the level is not what they were looking for (better for speaker and attendee).

The panel also talked about video: most conference organisers that attended said they had their talks recorded (some said they no longer did for cost reasons). Brief discussion followed on making videos available accessibly. At Fronteers we provide transcripts and captions for all our talks (see my blog post about how we do this).

What do speakers really want?

For her talk, Rachel Andrew did a survey amongst conference speakers and shared her results. She illustrated those brilliantly with personal experiences (she speaks at a lot of events) and gave a huge number of tips. There was a lot more in her talk than I can cover here, but I will try my best.

She talked about how important it is to be clear to speakers. What it is you do, what you expect a speaker to do where, when and for which audience and what you offer in return. Speaking is expensive, especially for those speakers who are freelancers / run a business. If your event makes a profit, you should pay speakers; only if you organise a community event you may get away with not paying.

Another thing Rachel talked about is to be helpful: make sure they have your contact details (and make sure there is always someone on phone duty), have professional audio/video people (‘agressive A/V people are a thing’, Rachel’s survey showed) and try to get post talk feedback to them (best filter it for constructive notes).

Rachel also said all speakers should be treated equally (rockstars and newcomers). That means they require equal pay, but also equal taking care of and being friendly to. If you are going to differentiate, best be extra helpful to newcomers rather than rockstars. If you have newcomers, inexperienced or vulnerable speakers (in any way), covering expenses can make a huge difference: paying their expenses and fees can empower them.

Panel: the future of conferences

In the ‘future of conferences’ panel, we discussed structure, and techy vs creative events.

Thomas van Zuijlen of Fronteers asked whether the “Fronteers model” (2 days of ‘just’ 45 minute talks) is going to die out in favour of newer models like the “responsive day out model” (1 day with sessions of three 20 minute talks followed by a panel discussion). Most of the panel agreed that the old model is likely there to stay, but new structures are interesting and bring in new benefits: more concise talks, easier to cover subjects that are too new to be suitable for a full length talk, etc).

The panel touched on the difference between events about technology and those about creativity. Some noted that the ones about creativity and inspiration are much harder to sell tickets for. One reason for this, the panel concluded, may be that it is easier to get management approval for attending a conference, if it is easier and more tangible what the conference covers (Angular vs creativity).

The conference survival handbook: extreme edition

Cat organises the international Smashing Conference as well as ConfConf itself. Cat’s talk was about a subject that will be familiar to anyone who has organised an event before: conference nightmares. There is so much that could potentially go wrong! Cat talked about known knowns, known unknowns and unknown unknowns.

Known knowns are things that can be planned for, like not running on time, slow registration process, speakers illnesses and poor WiFi. To avoid running off schedule, Cat recommended planning time for getting everyone seated without gaps, factor in welcomes and introductions and being very clear to speakers about how long they are on for. To make registration smoother, she said events should avoid requiring ticket print outs and have one person available to investigate in case someone shows up and their badge is not there. She also mentioned preregistration, which can be good, but requires extra plain badges as people tend to forget theirs on the conference day.

Unknown knowns are things that happen on the day: a speaker oversleeps, someone is angry or rude on Twitter or a complaint is made. The crux of solving such issues is being ready for them when they happen: having people available that can react quickly is important. Cat mentioned at Smashing, she asks speakers to be on site a minimum of 3 times the travel time between hotel and venue.

Unknown unknowns are things that almost never happen: the projector’s bulb blowing (ask A/V staff if they have a spare), power cuts (again, ask venue for their backup plan) or natural disaster (take insurance).

Wrap-up

If there is one thing that I learned from this day, it is that taking care of all the little details, being very friendly and communicating clearly are very important additions to your main conference organising duties. Probably thanks to having had an experienced speaker (hi PPK!) and a very friendly personality (hi Krijn!) amongst our founding organisers, I realised during some of the talks, many of these things have been in the FronteersConf handbooks for years. But I also heard many things we could improve on.

It’s been great to hear from some seasoned organisers and a speaker. And it was very useful to exchange knowledge on the day and in the pub afterwards. ConfConf showed me that there are many types of events, as well as styles of organising. Recommended for all (web) conference organisers!

Originally posted as ConfConf on Hidde's blog.

Reply via email

In preparation of the Grid Layout Workshop in Amsterdam this Friday, I read the grid spec. I highly recommend doing this.

This specification is a great read, even for those not familiar with reading CSS specs. It first introduces all the concepts with comprehensible examples, and then dives into the syntax in more detail (including diagrams that show exactly which properties can be used how, available shorthand syntaxes and the algorithms used to decide about sizing and alignment).

Why?

“We already have many clever combinations of HTML, CSS and JavaScript to do layout”, I hear you think, “so what do we need Grid Layout for?” All layout mechanisms we have used to date come with specific problems. Floats need clearing, inline-block grid elements need comments to remove spaces and make widths work, and tables misused an HTML element for layout. CSS Grid Layout addresses our layouting problems, and lets us ‘divide available space for layout into columns and rows using a set of predictable sizing behaviors’. Yeah!

New terminology

The grid spec introduces a number of new terms. A grid is a set of lines that divides the grid container. Within the grid container, columns or rows exist between the lines. Columns and rows can both be referred to as grid tracks. On the grid, each cell is called a grid cell. One or more cells can form a grid area, which can be occupied by grid items.

I found it a bit confusing at first to see the difference between grid areas and grid items, but as I understand it, grid items are the bits of content that authors can specify to live in a specific grid area.

More alignment options

Some of the best new CSS properties that were introduced in flexbox, also work on grid containers (justify-items, align-items), grid items: (justify-self, align-self) and the grid itself (justify-content, align-content).

See also: fantasai re: “Too Many Alignment Properties”

Naming lines and areas

With grid-template-columns and grid-template-rows you can not only specify how much space each grid cell takes up, you can also give the lines surrounding them names. So for a 3 column layout with a width of 25%, 50% and 25% respectively, you do something like:

grid-template-columns: 25% 50% 25%

And if you want to lines surrounding the 50% area, you do:

grid-template-columns: 25% [start-main-area] 50% [end-main-area] 25%

so that you can set a specific bit of content to live in the 50% area between ‘start-main-area’ and ‘end-main-area’.

You can also define names for the areas themselves, using the ASCII art method (if a word appears multiple times, it means it spans multiple columns/rows):

grid-template-areas: "header header header"
                     "main main sidebar";

so that you can set a specific bit of content to live in the ‘header’, ‘main’ area or ‘sidebar’.

fr

The fr unit can be used to define flexible lengths and represents a fraction of the free space in the grid container. I think this is how it relates to auto: if all lengths are set auto, that would be equivalent to them all having 1fr, but if they have different amounts of fr, the fr unit gives more control as they can give some grid tracks more space than others.

Changing visual order

The grid spec frequently talks about the order keyword, which lets you visually change the order of your document (this property also exists in flexbox).

This makes that there are now two different orders to keep in mind:

• document order / source order (this is what you see when you view source)
• order-modified document order (this is the document order with all the ‘order’ properties in your stylesheet(s) taken into account)

Browsers are supposed to paint in the order-modified document order (this is also good to know for if you’re setting z-index).

The spec emphasises that order will only change your visual order, and not update speech order (for people that have your page read out to them) or navigation order (for people that use keyboards to navigate). Therefore it is important that the source order is sensible (this is an important accessibility concern).

Auto

Lots of things within grids can happen automatically. This is a bit complex to get your head around, but it is rather exciting (if you have not seen it, I can recommend fantasai’s CSS Day talk on defining auto). The good news is: to use grids, you do not need to know how the auto algorithms work, they just do.

With grid properties, you can set your grid exactly how you want it to be (‘explicit grid’). If you forget something or position an element outside of the bounds of your grid, the grid algorithm will create ‘implicit’ grid tracks.

Grids in grids

Grid items can be grids themselves (they are then ‘subgrids’), but this is still being discussed by the CSS Working Group. With display: subgrid, the subgrid would be able to inherit the cols/rows of its parent.

Thoughts

This is exciting! I really look forward to using CSS grids in my daily work.

I do think the transition to actually using the new properties for page layout will come with some problems, especially around giving grid areas names that can be shared across everyone working on the same site, and letting grid areas be occupied by components (as component libraries are the deliverable of many front-end developers these days).

And if that all works, should we give content managers controls to set content to flow in specific columns (perhaps the CMS would show a representation of the grid on various different viewports?).

Originally posted as Notes on CSS Grid Layout on Hidde's blog.

Reply via email

In “Meaningful CSS: style like you mean it”, Tim Baxter argues for replacing CSS approaches that heavily rely on classnames with a markup-centric approach. I think adding styling to HTML elements is hugely beneficial, but works best when combined with a class-based approach. We need a bit of both.

In his article, Tim explains that in the past few years, HTML (especially when enriched with ARIA) has become much more expressive. So expressive, that we can throw away class-based approaches to styling. We can just style on HTML elements themselves, he says.

Your team’s standards vs web standards

The challenge in CSS is to find a way to apply the styles you want to the things you want to apply them to. Classes let you give your things any name. Classes are to “[represent] the various classes that the element belongs to”, says the HTML standard. With a ‘class-based approach’, I mean approaches like OOCSS and BEM, that recommend you to define components or objects with just or mostly classnames.

The most-used argument for a class-based approach to CSS is that it makes things easier for teams. Once a team agrees on the preferred nomenclature for a thing, they can consistently use those names within their team.

But consistent standards already exist, in the form of web standards. Why not make those the baseline? Tim Baxter also says this:

if there is any baseline level of knowledge we should expect of all web developers, surely that should be a solid working knowledge of HTML itself, not memorizing arcane class-naming rules

Yes, let’s add styling to HTML where we can! This is wonderful, because web standards for markup were made through a long process of mailing lists, IRC discussions and face to face meetings. They have already gone through the trouble of defining what things are on the web.

Web standards define the difference between inputs for phone numbers and those for email addresses. They define the difference between a definition list and an unordered list. And the difference between quotations and paragraphs.

We need a bit of both

Adding style rules to native HTML elements, and use the power of some of the many attributes HTML comes with, sounds very sensible to me. Because the web standards people have already defined and documented what things mean in HTML, we can just use those semantics and be done with it. This also aids your users. Some of them may be using a screen reader or search engine to access your site.

But there is a problem here. The issue with using ‘just’ HTML to apply CSS, is that HTML is simply not as expressive as the design languages that often underly our web projects. Many web projects contain various instantiations of the same, meaningful HTML elements. In such projects, the meaning cannot come just from the elements themselves.

To be more precise, I think avoiding class-based approaches does not align with how web teams collaborate.

Some examples

Web standards document:

• what a form is

Our project’s design language contains:

• a newsletter form
• a search bar
• a contact form
• a poll (why not?)

These are all different types of forms, and would often not benefit from sharing style rules. The interaction designer has had user tests done and decided to do labels next to inputs in the contact form, and make the search bar expand when you click it. They’re all forms, but they’re all different.

Web standards document:

• what an input with the type ‘submit’ is

Our project’s design language has:

• the newsletter signup submit
• the search button
• the ‘Contact us’ form’s submit
• the button to submit your choice in the poll

Again, I think their is much more difference in meaning than we can ever distinguish between with styling just <input type="submit"> .

We can design beyond the list of available HTML elements

If we expect to be able to style just HTML elements, we should only allow designers to design one style for each HTML element. We would just hand them the list of available HTML elements, and they would create a design for each. That would be an insane process to follow. Unrealistic, too. Interaction designers have user journeys to worry about, they need to keep track of the whole picture.

Designers for the web, rightly, design more than just individual HTML elements. This is why, for front-end developers, it makes sense to use classes like .form--newsletter, .form--search or .form--contact. Or, depending on whether they differ a lot, .newsletter, .search-bar and .contact-us.

I have built websites where all the forms look the same, all the tables look the same and all the quotes looks the same. In those projects, they really exist, classnames are mostly unnecessary. Yet, most larger web projects are not like that. They have a lot of variations and for their meaning they cannot rely on HTML elements alone.

We have to be pragmatic about this. We should collaborate on websites that go beyond just what native HTML elements have to offer. Creative combinations of markup can bring our users a great experience. Classes aid creative combinations.

Using classes to draw distinctions

So, I think we need to define blocks with classes, so that we can distinguish between all the different components that are in our project’s design language. There is no harm in adding classes for variations of those blocks, or elements within the blocks. After (a lot) of initial scepticism, I quite like BEM and have seen it work (but as with all best practices, it is good to be critical, the problems they solve may not be your problems).

Classes are essential to do the work we need to do: style websites with a varied design language that creatively uses combinations of HTML elements. But using lots of classes should not stop one from using meaningful markup. CSS experts should always also be markup experts.

Conclusion

I really liked Tim Baxter’s article about styling with HTML elements and attributes, mostly avoiding classnames. It provokes thought and is a welcome alternative to the let’s-add-classes-to-all-the-things consensus. And I agree, adding styling to HTML elements is powerful, as they have inherent meaning that is specified in a standard.

But I think HTML and ARIA are (still) not expressive enough to draw the distinctions our designers draw. Classnames are essential in making such distinctions. The best approach, imho, would be to combine both classes and meaningful markup.

Originally posted as Collaborative CSS on Hidde's blog.

Reply via email