Tags: law

99

sparkline

Tuesday, May 28th, 2019

How Ireland became Europe’s data watchdog - BBC News

The coming GDPR storm:

Ireland’s Data Protection Commissioner, Helen Dixon, is expected to circulate her decisions on some cases by July or August, with final rulings made by the end of the year.

(That’s my sister-in-law, that is.)

Friday, March 22nd, 2019

Gutenberg and the Internet

Steven Pemberton’s presentation on the printing press, the internet, Moore’s Law, and exponential growth.

Thursday, November 8th, 2018

Designing, laws, and attitudes. — Ethan Marcotte

Ethan ponders what the web might be like if the kind of legal sticks that exist for accessibility in some countries also existed for performance.

Monday, October 15th, 2018

Website Accessibility Begins with Responsive Web Design

I recently asked a friend who happens to be blind if he’d share some sites that were built really well—sites that were beautifully accessible. You know what he said? “I don’t use the web. Everything is broken.”

Everything is broken. And it’s broken because we broke it.

But we can do better.

Monday, September 10th, 2018

Robustness and least power

There’s a great article by Steven Garrity over on A List Apart called Design with Difficult Data. It runs through the advantages of using unusual content to stress-test interfaces, referencing Postel’s Law, AKA the robustness principle:

Be conservative in what you send, be liberal in what you accept.

Even though the robustness principle was formulated for packet-switching, I see it at work in all sorts of disciplines, including design. A good example is in best practices for designing forms:

Every field you ask users to fill out requires some effort. The more effort is needed to fill out a form, the less likely users will complete the form. That’s why the foundational rule of form design is shorter is better — get rid of all inessential fields.

In other words, be conservative in the number of form fields you send to users. But then, when it comes to users filling in those fields:

It’s very common for a few variations of an answer to a question to be possible; for example, when a form asks users to provide information about their state, and a user responds by typing their state’s abbreviation instead of the full name (for example, CA instead of California). The form should accept both formats, and it’s the developer job to convert the data into a consistent format.

In other words, be liberal in what you accept from users.

I find the robustness principle to be an immensely powerful way of figuring out how to approach many design problems. When it comes to figuring out what specific tools or technologies to use, there’s an equally useful principle: the rule of least power:

Choose the least powerful language suitable for a given purpose.

On the face of it, this sounds counter-intuitive; why forego a powerful technology in favour of something less powerful?

Well, power comes with a price. Powerful technologies tend to be more complex, which means they can be trickier to use and trickier to swap out later.

Take the front-end stack, for example: HTML, CSS, and JavaScript. HTML and CSS are declarative, so you don’t get as much precise control as you get with an imperative language like JavaScript. But JavaScript comes with a steeper learning curve and a stricter error-handling model than HTML or CSS.

As a general rule, it’s always worth asking if you can accomplish something with a less powerful technology:

In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.

  • Instead of using JavaScript to do animation, see if you can do it in CSS instead.
  • Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like required.
  • Instead of using ARIA to give a certain role value to a div or span, try to use a more suitable HTML element instead.

It sounds a lot like the KISS principle: Keep It Simple, Stupid. But whereas the KISS principle can be applied within a specific technology—like keeping your CSS manageable—the rule of least power is all about evaluating technology; choosing the most appropriate technology for the task at hand.

There are some associated principles, like YAGNI: You Ain’t Gonna Need It. That helps you avoid picking a technology that’s too powerful for your current needs, but which might be suitable in the future: premature optimisation. Or, as Rachel put it, stop solving problems you don’t yet have:

So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.

There’s no shortage of principles, laws, and rules out there, and I find many of them very useful, but if I had to pick just two that are particularly applicable to my work, they would be the robustness principle and the rule of least of power.

After all, if they’re good enough for Tim Berners-Lee…

Tuesday, August 21st, 2018

Design Laws in Nature by Jordan Moore

A deep, deep dive into biomicry in digital design.

Nature is our outsourced research and development department. Observing problems solved by nature can help inform how we approach problems in digital design. Nature doesn’t like arbitrary features. It finds a way to shed unnecessary elements in advancing long-term goals over vast systems.

Friday, April 20th, 2018

Picture 1 Picture 2

It’s heeeeeeeere!!!

Thursday, April 12th, 2018

The Eponymous Laws of Tech - daverupert.com

Dave has curated a handy list of eponymous laws.

Thursday, January 18th, 2018

Dude, you broke the future! - Charlie’s Diary

The transcript of a talk by Charles Stross on the perils of prediction and the lessons of the past. It echoes Ted Chiang’s observation that runaway AIs are already here, and they’re called corporations.

History gives us the perspective to see what went wrong in the past, and to look for patterns, and check whether those patterns apply to the present and near future. And looking in particular at the history of the past 200-400 years—the age of increasingly rapid change—one glaringly obvious deviation from the norm of the preceding three thousand centuries—is the development of Artificial Intelligence, which happened no earlier than 1553 and no later than 1844.

I’m talking about the very old, very slow AIs we call corporations, of course.

Tuesday, January 16th, 2018

Laws of UX

  1. Fitts’s Law
  2. Hick’s Law
  3. Jakob’s Law
  4. Law of Prägnanz
  5. Law of Proximity
  6. Miller’s Law
  7. Parkinson’s Law
  8. Serial Position Effect
  9. Tesler’s Law
  10. Van Restorff Effect

Not listed:

  1. Murphy’s Law
  2. Sturgeon’s Law

Monday, June 12th, 2017

Here are 3 legal cases from the future

  1. People v. Dronimos
  2. Writers v. A.I. Rowling
  3. The Algorithm Defense

Friday, February 3rd, 2017

Legal Advice Forum for EU/EEA Nationals Tickets, Thu, 16 Mar 2017 at 18:30 | Eventbrite

Are you an EU/EEA national living in the UK? Worried about your rights and options post-Brexit?

Alex has an organised an event at 68 Middle Street for March 16th with an immigration advisor, The £5 ticket fee is refundable after the event or you can donate it to charity.

Monday, November 21st, 2016

Designing for new digital rights

A series of quick’n’dirty prototypes to illustrate some of the design challenges involved in handling personal data:

If we don’t start exploring what the General Data Protection Regulation means for people, the same thing that happened with the cookie law will happen again.

These new rights have the potential to improve how our digital products and services work.

Saturday, October 8th, 2016

Why we are suing Apple for better HTML5 support in iOS?

Finally! Apple are being sued for refusing to allow any non-Webkit browsers to be installed on iOS.

I’m not usually in favour of legal action but in this case, there doesn’t seem to be any other recourse.

We would be delighted at Nexedi to create a Web browser for iOS with better HTML5 support based on a recent version of Blink library for example. But as soon as we would publish it, it would be banned from Apple’s AppStore. Many developers have experienced this situation already. Many companies are being hurt by this situation. Some companies have already begged Apple to improve HTML5 support in iOS with little significant results.

Tuesday, May 17th, 2016

Design systems and Postel’s law | Journal | The Personal Disquiet of Mark Boulton

Marvellous insights from Mark on how the robustness principle can and should be applied to styeguides and pattern libraries (‘sfunny—I was talking about Postel’s Law just this morning at An Event Apart in Boston).

Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.

So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable.

Monday, February 8th, 2016

Prohibition Of Discriminatory Tariffs For Data Services Regulations, 2016 (PDF)

Good news for net neutrality from India:

No service provider shall enter into any arrangement, agreement or contract, by whatever name called, with any person, natural or legal, that has the effect of discriminatory tariffs for data services being offered or charged to the consumer on the basis of content.

Friday, September 25th, 2015

What Happens Next Will Amaze You

I refuse to believe that this cramped, stifling, stalkerish vision of the commercial Internet is the best we can do.

Sunday, June 28th, 2015

Grilled butterflied leg of lamb.

Grilled butterflied leg of lamb.

Sunday, December 7th, 2014

An immigration lawyer reviews Paddington

Sounds like a cute idea, right?

In fact it’s the best thing you’re ever likely to read on Peruvian ursine immigration.

Wednesday, December 3rd, 2014

The Spirit of Flickr and the Problem of Intent - mor10.com

This is a superbly-written, empathetic, nuanced look at the issues around Creative Commons licensing, particularly the danger of inferring a “spirit” in a legal agreement.

“Spirit” as it’s being used in this conversation is a relative term. You have the spirit of the user, the spirit of the license, the spirit of the community, the spirit of the service, and the spirit of the law. All these can align and all these can diverge and that’s OK. It is also the reason we have a legal system that sets clear parameters for how things can be interpreted: Spirit is relative, legal decisions and documents are not (at least in theory). The whole idea of a legal contract (under which we can find CC licenses) is that there is no room for interpretation. The meaning of the document is singular, unambiguous, and not up for debate. Of course this is purely theoretical, but that’s the idea anyway.

The problem arises when the spirit – or intent – of the user when applying a license differs from the actual legal interpretation of that same license.