For about 6 years, I have mostly stopped reading my daily paper physically, unless sipping lattes in a coffee shop. I used its app instead. In those years, they released various updates, and these updates got me thinking about what I want from a newspaper app.

My app-based news consumption was somewhat of a necessity. I was abroad and kiosks abroad very rarely sell Dutch dailies. I’ve since really come to like reading digitally, and it also saves paper and sending screenshots to friends is useful.

My ideal

Ideally, the app just downloads a PDF and lets me browse through that page by page. A screen that has all pages would be useful, too, so that it is easy to jump to that one cartoon that I know will be on the last page. Yup, that doesn’t contain links and isn’t easily updated, and it doesn’t peruse some of the unique features of the web platform. It’s boring, simple and not very smart. To read articles you even need to zoom in, as the text is not HTML, it’s not responsive, it’s literally a PDF (it does contain plain text for users who need or prefer this).

Two things I like about the PDF-style newspaper reader: first, it looks like the newspaper everyone else buys from the kiosk, second, this formatting is the one a editing team of smart people have chosen over the course of their night. Up until moments before the thing really needs to go to press, they can still tweak things. After that time, that’s it: the paper of that day.

The good thing about producing one paper a day rather than a continuous stream of news is that the daily deadline forces decisions about what’s most important. Even if that means the occassional ‘when this went to press, we only knew 80% of the election results’. I can live with that. It is good for my sanity to take in one thing a day rather than continuous streams of news.

I like artificial intelligence, but for some things human judgment clearly wins. Let alghorithms calculate my fastest route to work or what the best way is to distribute food droppings in a war zone. For news, I think intentional prioritisation and placement in the page are best left to humans.

Their innovations

Two things De Persgroep have added to their Volkskrant app:

• ads that take over the whole screen
• animated page switch

I probably don’t need to explain what’s underwhelming about the addition of ads. This doesn’t belong here.

An animated page switch is cool, it keeps the interface fresh, but my tablet is too old to do the animation, causing it to freeze for a few seconds halfway an animation.

Both the ads and the animation slowed down the app considerably. This meant that, over the years, my digital paper became harder to read. That is remarkable for what is essentially a PDF reader.

What I’m not looking forward to

What I’m mostly concerned about is that my news will be displayed like it is on the newspaper’s website. This is great when one wants to see the latest news at a glance, but, with the bath water, it would throw away the daily carefuly curated prioritisation that news physical papers offer.

With CSS Grid Layout, the kind of layouts that are mostly unique to newspapers, are now possible in browsers. But until the process of filling a web based newspaper grid becomes a process similar to filling the physical paper with content, and I think having one daily thing that doesn’t change (much; small updates could be useful), I’m hoping the PDF-viewer version will stay on offer. Otherwise I would likely switch back to paper.

Originally posted as My ideal newspaper app is not very smart on Hidde's blog.

Reply via email

The other day I was building a form, and I was surprised how event firing works when you press ENTER on the keyboard.

When you’re on a form field in most browsers, pressing ENTER on the keyboard triggers the browser to submit the form. This is called implicit submission (thanks Tim). I suspected pressing ENTER would cause a submit event to be fired on the form, but it is more nuanced than that.

‘ENTER’ submits the form, even if it contains no submit button. If the form does contain one or more submit buttons:

• pressing ENTER results in a click event on the submit button of the form
• when the submit button is clicked, it submits the form, which triggers a submit event on the form

In the above, “the submit button” is the first submit button that exists in your form, the HTML spec calls this the form’s default button.

What surprised me, is that functions that listen to the click event on your default button, run before the form’s submit event is fired. Running event.preventDefault() on the form’s submit event will not stop that click handler from running (thanks Matijs for helping me figure this out).

Originally posted as Form events when submitting with keyboard on Hidde's blog.

Reply via email

Inspired by Nienke, I’d like to share some of my highlights and learnings of 2017.

Highlights

Projects

2017 was the first full year working via my Dutch company, after I had hiddedevries.nl Limited struck off the English companies registry as part of my personal Brexit. The Dutch company was there since January 2007. It’s been over ten years now, but it feels so much shorter.

This year, I really, really wanted to focus on work with social impact (in government, culture or non-profit). How millennial! But really. In a world that is more and more powered by technology, choosing what kind of technology to work on and which people benefit from that technology seemed super important. This was not easy per se. If I’m honest, as a contractor, the kind of work I can do largely depends on what kind of projects I am approached for. Recruiters usually laughed when I mentioned my preference. But I feel it would be sad if all the bright minds of our industry helped some webshop create a better checkout flow and sell more tvs, if we could have helped citizens get the support they need. I tried being proactive, but luck and chance were probably as important. Anyway, I got to do some pretty impactful projects this year.

• At Wigo4IT I worked on a web page where people can apply for income support from their local government (for the cities of Amsterdam, Rotterdam, Utrecht and The Hague)
• At Logius I worked on a website where Dutch governmental organisations can generate an accessibility statement
• At KOOP I worked on the redesign of various data-heavy websites, like overheid.nl and wetten.nl
• For Web Conferences Amsterdam, I worked on visual design for the CSS Day and PhoneGap Day EU conferences (building upon Stephen’s designs)
• I made various small changes to websites of Xander Publishers, Trio42, Stichting Piet de Vries and others
• I joined Mozilla’s Open Innovation team as a contractor, and my contract was extended until far into 2018

Conferences and events

I have attended a couple of conferences this year:

• CSS Day, which this year was a two day event about CSS and Browser APIs (write-up)
• PhoneGap Day EU
• Brique, a design conference by Fabrique
• Patterns Day, about pattern libraries (write-up)
• Fronteers 2017, its tenth edition and the first where I had no responsibilities whatsoever, great catching up with people
• the year opening of Communication & Multimedia Design in Amsterdam, which I thought had a ‘work on stuff that matters’ theme to it (write-up)
• Web Accessibility Live (which has no website, but it was great to see Job and Bruce speak)

Speaking

This year I also stepped out of my comfort zone and did my first public speaking, thanks to Niels and Léonie for encouraging me.

• I talked about hiding content (slides) and the basics of accessibility (slides, video), at meetups.
• At Fronteers Jam Session, I did an even shorter version of my talk about hiding content
• At Inclusive Design 24, I spoke about the argument for accessibility from philosophical ethics (slides, video)
• For Fronteers, I hosted two workshops about CSS Layout, which, to my own surprise, sold out. It’s awesome to see so many people excited about new lay-out techniques

Also to my own surprise, I thoroughly enjoyed preparing and giving talks. So much, that I would love to do more in 2018. Nothing much planned so far, but the CSS Layout workshop is running again and there may be another workshop in the first half of 2018.

Writing

On this blog I published 32 posts, some longer than others, some more interesting than others. There were also many posts that did not make it past the Draft stage, I guess that will always be the case. Writing can take up a lot of time, but I can recommend it to everyone working in the web field. It helps understand stuff better, can expose what you don’t know yet and also just to align thoughts.

These are some of the most read:

• Did CSS become more complicated since the late nineties?
• This website now uses Grid Layout
• How to make inline error messages accessible
• Accessibly labelling interactive elements
• On hiding content

Volunteering

On April 1st this year I stopped volunteering at Fronteers, after over 8 years. It’s been a lot of fun and I learned a lot, yet it felt very good to step down.

The decision has given me a lot of free time, which was good. But I couldn’t really help myself and did organise a small event with Sharon: a film screening of Hanzi the movie, its European premiere. Responses were great, some people even suggested we could do a monthly design documentary meetup in Rotterdam. That would be very cool.

Things I learned

Finally, some random things I learned:

• In two projects I was involved in we had official WCAG 2.0 audits, it was great to get feedback on our accessibility efforts. Before the auditor came I had done all I could to be 100% compliant, but they found several issues anyway, most of which we were able to resolve, others we could use as leverage to convince people of different prioritisation. Because accessibility is, as many things, team work.
• I presented a couple of sprint review demos. It was fun to try and explain our technical projects to an audience with various less technical people in it. I learned to switch quickly between more and less technical narratives.
• Remote working can be tiresome, especially working across time zones. I’ve had to force myself to do some non work things in my days to balance stuff out. Knowing when to ignore notifications late at night is acceptable and also key.
• I wrote a lot of vanilla JavaScript, I owe a lot this year’s progress to Matijs, his patience is A+
• Learned loads about how big organisations manage projects and how to be political about getting accessibility to be a priority. For example: be nothing but positive and constructive in meetings (this is a skill I’ve had to get much better at). I owe a lot of this year’s progress in that part of work to Jeroen. who is very good at this stuff
• It’s been good to plan for holidays. However much it might seem like they’re not necessary, they absolutely are.

Some resolutions for the next year:

• More reading of books and newspapers, less looking at my phone
• More public speaking if I can
• Better time management
• Help other people get started with a personal blog like this one (get in touch if you need proofreading/advice)

I am looking forward to 2018. Happy new year!

Originally posted as 2017 in review on Hidde's blog.

Reply via email

Last week I was at Mozilla’s All Hands in Austin, Texas (hence the hashtag). All Hands is an all company event where the people who work for Mozilla come together in one city. Staff, but also prominent volunteers, contributors and community leaders. It’s all about sharing experiences and meeting people.

It was my first All Hands, and the first time for me to meet any of the people I have worked with for the past six-ish weeks. The week went by faster than I could have imagined. I had been warned for this. Beforehand, I had heard great things about the event, but, wow, it was incredible! So many people met, so many productive sessions had, so many stickers acquired and various American foods tried.

Throughout the week I was in many meetings in various settings with colleagues from Open Innovation, as well as with the IT department whom we collaborate with for identity and access management work (the IAM project). We made plans, shared ideas, talked about planning and discussed our processes. Tons of things that are easier to do in person. For me personally, it was great to learn that and how our daily work fits in the broader Open Innovation and Mozilla goals.

Below, I’ve provided a couple of links to projects and ideas for y’all.

Plenaries

A plenary session opened the week, featuring most of the people leading Mozilla, including CEO Chris Beard and Executive Chairwoman Mitchell Baker. There was a lot to celebrate about 2017 for Mozilla. The launch of Firefox Quantum which had been years in the making, projects like Common Voice that want to facilitate machine learning of voices for all, the programming language Rust that gained a lot of momentum and an MDN that is supported by all major browser vendors. All these initiatives are means to support Mozilla’s mission: to have a web that puts people first and empowers, rather than one that facilitates harassment, walled gardens, fake news and digital exclusion. Sillicon Valley isn’t necessarily society’s friend. These are things that need fixing. Katharina Borchert explained that, as these fixes need an answer that goes beyond technology, Mozilla has set up a policy team. Mozilla focuses on five issues in particular.

“Even mainstream media are noticing”

Throughout the week I learned about lots of different projects that clearly work towards this mission. I picked up lots of dots and it was great to see how well they all connected. For example, later in the day, I attended the Mozilla Foundation’s plenary session. Some of the Mozilla fellows presented their work on things like Net Neutrality, the Internet Health Report and privacy. All things that help fix what’s currently broken on the web.

Electives

On Wednesday afternoon I attend various electives: sessions open to anyone, focused on a specific subject. There was a lot of good stuff to choose from, I ended up going to the ones about the Photon Design System, WHATWG and a design system approach to Mozilla’s websites.

Photon Design System

Photon is the design system used by the people who build Firefox. It was created because browser engineers and designers wanted it, to make it easier to have the same look and feel across the browser, on all the platforms it works on. Currently it is ‘just’ a website that documents the design choices, but the team are looking in turning the style guide into a living style guide. In a fun post-it note exercise we looked at the pros and cons of Design Tokens. They are design decisions abstracted into JSON files, so that they can be reused. In CSS or Sass, but also in design software like Sketch. This setup can create an application agnostic approach to documenting design, because the tokens are easily shareable between platforms and people.

It was fun to think about Design Tokens

WHATWG

At the session of standards community WHATWG, I learned about their recent changes to dealing with intellectual property rights and what they mean for contributing. The new IPR agreement and way of working was developed together with all major browser vendors: Apple, Google, Microsoft and Mozilla. They all have representatives in the Steering Group. Spec contributors of all of those companies now contribute to the Living Standard/WHATWG-version of specs like HTML, rather than the W3C version (as GitHub activity shows). The session was quite positive and people seemed eager to work together with others including W3C, and minimise confusion for developers and browser implementors.

From wagile to agile with mozilla.org

Craig Cook, front-end developer at mozilla.org held an elective about design systems. Mozilla has hundreds of websites, some quite old and some brand new. Many of those have been developed in a process that started as agile but quickly became waterfall, something he ironically referred to as wagile. Design systems can help here, because if multiple sites make use of one design system, it is only that system that needs updating rather than individual sites. That would really offer the flexibility in process that wagile lacked. Other than process it will likely improve user experience, as human brains are good at pattern recognition, having reusable patterns leverages that. As someone who works on some Mozilla sites now and in 2018, I look forward to seeing the design system flourish.

Lightning talks

I also attended a number of lightning talks. Some facts from those:

• you can have sourcemaps for Web Assembly (wasm) compiled Rust code in the browser, which can make wasm debugging as straightforward as JavaScript debugging
• user testing showed that action-oriented users of MDN are better served with a live preview CSS editor.
• the RNNoise project teaches computers to reduce noise with recurrent neural networks
• incremental Rust compilation is coming, which will make things a lot faster
• Web of Things is a horizontal stack and open source approach to Internet of Things, for which Mozilla submitted the Web Things API spec
• there is talk about a Rust-powered version of Ember
• Common Voice aims to create an open source data set that can be used by anyony who wants to teach machines about recognising voices; it has collected as much as 500 hours worth of speech data

CSS editor in MDN

This week has given me a lot of energy, despite the inevitable shortage of sleep. It has been a lot of fun to be part of this. It was refreshing to meet this super global community, with different countries and cultures represented. I am looking forward to Q1 of 2018, and the work that lies ahead. Because executing things is even more fun than planning them!

Originally posted as #yallhands on Hidde's blog.

Reply via email

If you have learned how to use Grid Layout, you might wonder what to use it for. In this post, I will give some use cases where I think Grid will excel.

In the last two weeks I gave two workshops on CSS layout techniques. Heavily inspired by Jen Simmons’s remarkable Grid Layout experiments, I picked three posters that Wim Crouwel designed. Crouwel is a graphic designer that has been making use of grids for a long time, including for all the characters in his New Alphabet typeface. His work is iconic and I was quite excited to see some of it could easily be built for the web using CSS Grid Layout.

I liked how working on non-real world examples played out, as the focus was really on applying all those different properties, rather than writing production-ready code. Old posters are great to try this stuff out on.

After the workshop, Michael asked me what we can use Grid Layout for in the real world, if not for recreating iconic posters from the history of graphic design. I talked to others about this and found various people weren’t sure what to use Grid Layout for in actual websites for clients.

I’m sure we can use it for a lot more than recreating old posters. There definitely are good use cases, so I thought I would make a list of where I believe Grid can help us create cool stuff.

Use cases

To show what’s on offer

Grids are perfect for showcasing things, inspire visitors, communicate to them what kind of stuff we have on offer, in a very broad way.

We can do these things with old-school layout methods. However, using CSS Grids they can look more exciting, it is trivial to make some things appear more prominently than others and it is easier to have the browser deal cleverly and responsively with content differences.

• For an online supermarket: a listing of products with prices, reduced prices, product names
• For a library: a page with reviews of the five books that have recently come out and have great reviews.
• For an airport: an overview of the tax-free shopping available
• For a railway company: a selection of exciting holiday destinations, weekends away, day trips

These are all listing pages that want to inspire people to find stuff, whether it be groceries or books. They can benefit from things only Grid offers.

For one-pagers with a lot of different sections

Many front-end developers will have had to code them if they worked on marketing sites in the past five years: one-page websites in which every section is quite different. They often have lively designs. Lots of differences between sections makes it hard to code systematically.

With Grid Layout you can keep the markup of these sections nice and plain and choose a sensible and consistent source order, while still allowing yourself to go wild creatively on each section.

To display a schedule

We can use grids to display information about what’s happening at a given event, conference. Note that proper markup will be extra important here, as for accessibility reasons we want to make sure the content makes sense without its Grid Layout.

For embedded layouts that fill the entire screen

If you’re building an interface that is supposed to go full screen on some physical product, Grid Layout might be quite a helpful way to distribute space.

A while ago, I built an interface for a Dutch department store that would be used by the cashier when you pay. It had things like your products on and stuff about loyalty card usage. This kind of interface runs full screen in some sort of embedded browser.

Some use cases:

• your digital tv interface
• the self-check-in screen in an airport
• the screen you see when you return books at the library
• a screen that shows information on the next train

With a grid that is based on viewport units (vw/vh) and/or fractions, space distribution and alignment may get a lot easier. (I have to admit, in my case the screen ran a browser that was almost identical to IE7 and the system’s output gave me only tables to work with).

The Grid Layout Spec has an example of a game that always fits on your screen. The required markup/CSS is ridiculously little.

An example

Imagine we have a grid with cards in it for a supermarket’s weekly offers.

All offers take one spot in the grid using autoplacement. However, some offers are more prominent, and we could make them use two rows:

.offer {
    // regular offer code goes her
}
.offer--prominent {
    grid-row: span 2;
}

I don’t work at a supermarket’s marketing department, so my knowledge of its possible marketing strategies is lacking, but maybe there are other offers. Perhaps one that will expire after this week. This is people’s last chance, so we make it use three columns and two rows.

.offer--last-chance {
    grid-row: span 2;
    grid-column: span 3;
}

This is stuff that is trivial in a Grid Layout and impossible to do so easily and flexibly using traditional methods like display: inline-block;. For those of us who have used floats, inline-block and even tables to do lay-out, using Grid Layout may be a bit of a mental shift. I suspect this applies a lot less to people who learn CSS layout today, as they will start in a reality where the new stuff already exists.

Conclusion

There are plenty of uses cases where Grid Layout would be a sensible implementation choice. I have listed some examples above, but I am sure there are more — please leave a comment or tweet if you have found other ideas.

Originally posted as What to use Grid Layout for? Some ideas. on Hidde's blog.

Reply via email