> I mean, the legislation.gov.uk website is great too – they designed it after a brilliant research on user needs. The only thing which remains bad is the very final product: the law. Lawyers made it. Why couldn’t law be designed by designers as well?
So...they've effectively discovered legal study guides, which have been doing turning the law into diagrams and (where appropriate) tables for decades.
The problem with design, especially with the example given in the article, is that it only captures the most basic, generic information. The detail--the part that matters to specific applications of the law,i.e., the most important part--is left out. (For example, the sample design on contracts leaves out crossing responses, a very common event in where rejection or acceptance of a contract is sent after an offer has been revoked but before the revocation has been received.)
Law is complicated because it needs to be to deal with the very many edge cases that arise from the natural ambiguities inherent in language. There are limits to how simple law can be.
> (For example, the sample design on contracts leaves out crossing responses, a very common event in where rejection or acceptance of a contract is sent after an offer has been revoked but before the revocation has been received.)
I tried Googling it, but I think my terms are wrong. How is this typically dealt with? Does one stricly supercede the other (i.e. revocations win over acceptances), do postmarks come into play, or similar time of transmission evidence?
This is all off topic, but I never thought about this scenario before.
If you want to add support for a new kind of register class in GCC, do you refactor everything as you make your change? No, you'll break a dozen architectures you've never heard of. Instead, you add some logic in a self-contained way, conseratively, assuming you don't fully understand the corner cases of the existing implementation. It's much easier to understand new logic as a delta of existing behavior, which may be then partially specified, than to reimagine the logic from first principles.
That's why the law is full of "But in cases under subsection C where Z applies..." You don't refactor subsection C because you may break it. Better to specify the additional behavior in a self-contained way. You can summarize the behavior of a legal code in diagrams, the same way you can diagram the high level operation of GCC's register allocator. But the diagram isn't the code, and the diagram can't be canonical.
Thank you for this. I've tried to use a similar metaphor with profs in law school back in the day, but never this well. When you experience this many edge cases, it's time to refractor the code.
While I like the idea of more readable, usable documentation of law... I also worry about it. Because law is really all about the interpretation within the courts -- past case history, different levels of courts, various jurisdictions, etc. You can read all you want, make your own judgments on it, and make intelligent choices based on what you read... but in the case of a conflict, it is a judge who will decide what really applies to you.
I like these! Sure, there are many legal concepts that are too complex to be explained by a diagram - that's why us lawyers still have jobs - but a well designed image can certainly help with some of the simpler sets of rules.
This is an interesting area of exploration. When I was in law school, the big thing was using "plain english" in your legal writing. No more "party of the first part" etc. This takes it a step further by taking the written language and using images to convey meaning. I have always likened the law to coding, and this seems to fit with that: taking written code to express a graphical interface. Take the written laws and express them as a graphical interface.
> Here is an example of the sort of thing that infuriates the advocates of plain English. It's an extract from one of those handbooks put out by the Occupational Safety and Health Administration, an outfit notorious not only for its torture of English but for the fact that many of its thousands of rules and regulations render each other what they call in Washington "inoperative." It's hard to decide whether the people at OSHA are simply ineffectual bumblers or supremely talented satirists boring from within. Here, for instance, is how they define an exit: "That portion of a means of egress which is separated from all other spaces of the building or structure by construction or equipment as required in this subpart to provide a protected way of travel to the exit discharge." That's not all. Now they elaborate on "means of egress": "A continuous and unobstructed way of exit travel from any point in a building or structure to a public way [which] consists of three separate and distinct parts: the way of exit access, the exit, and the way of exit discharge."
> That's certainly ugly, and it makes us wonder whether an exit has to be defined at all, and, if it does, why couldn't it just be called a way to get out. Then we wonder why a "means of egress" has to be defined at all, and, if it does, why couldn't it be called a way to get to the exit. If these reservations seem reasonable to you, it's because you're just not thinking. You are assuming that any ghastly mess of verbiage that comes from a bureaucracy needs to be simplified because it is needlessly complicated to begin with. Wrong. As it happens, that horrid prose serves its aims perfectly. Regulations of this nature have one clear purpose, and that is to answer, before the fact, any imaginable questions that might be asked in a court of law. For that purpose it's not enough to assume that everyone knows what an exit is. Is a door an exit? Maybe, but maybe not, if a drill press just happens to be standing in front of it. Is a hole in the wall acceptable as an exit? Do you really get out of the building (let's say it's ready to blow up) if you go through a door and find yourself in an enclosed courtyard instead of a "public way"? You don't have to be very clever to think of lots of other such questions, and the writer of this regulation is thinking about your questions. He has done a good job, although he has written something very ugly. But it's only ugly; it's not wrong, it's not more complicated than it has to be. It doesn't need simplification; it needs simply to be kept pretty much out of sight, lest it provide some plain English fanatics with what they think is a useful example.
I'm not convinced I agree with him. I'm sure someone could re-write this example such that it keeps the same meaning but is easier to read.
11 comments
[ 309 ms ] story [ 570 ms ] threadWhy couldn't your app's core business logic rules be designed by designers as well? See: http://www.chris-granger.com/2015/01/26/coding-is-not-the-ne....
The problem with design, especially with the example given in the article, is that it only captures the most basic, generic information. The detail--the part that matters to specific applications of the law,i.e., the most important part--is left out. (For example, the sample design on contracts leaves out crossing responses, a very common event in where rejection or acceptance of a contract is sent after an offer has been revoked but before the revocation has been received.)
Law is complicated because it needs to be to deal with the very many edge cases that arise from the natural ambiguities inherent in language. There are limits to how simple law can be.
I tried Googling it, but I think my terms are wrong. How is this typically dealt with? Does one stricly supercede the other (i.e. revocations win over acceptances), do postmarks come into play, or similar time of transmission evidence?
This is all off topic, but I never thought about this scenario before.
http://en.wikipedia.org/wiki/Posting_rule
If you want to add support for a new kind of register class in GCC, do you refactor everything as you make your change? No, you'll break a dozen architectures you've never heard of. Instead, you add some logic in a self-contained way, conseratively, assuming you don't fully understand the corner cases of the existing implementation. It's much easier to understand new logic as a delta of existing behavior, which may be then partially specified, than to reimagine the logic from first principles.
That's why the law is full of "But in cases under subsection C where Z applies..." You don't refactor subsection C because you may break it. Better to specify the additional behavior in a self-contained way. You can summarize the behavior of a legal code in diagrams, the same way you can diagram the high level operation of GCC's register allocator. But the diagram isn't the code, and the diagram can't be canonical.
http://www.sourcetext.com/grammarian/less-than-words-can-say...
> Here is an example of the sort of thing that infuriates the advocates of plain English. It's an extract from one of those handbooks put out by the Occupational Safety and Health Administration, an outfit notorious not only for its torture of English but for the fact that many of its thousands of rules and regulations render each other what they call in Washington "inoperative." It's hard to decide whether the people at OSHA are simply ineffectual bumblers or supremely talented satirists boring from within. Here, for instance, is how they define an exit: "That portion of a means of egress which is separated from all other spaces of the building or structure by construction or equipment as required in this subpart to provide a protected way of travel to the exit discharge." That's not all. Now they elaborate on "means of egress": "A continuous and unobstructed way of exit travel from any point in a building or structure to a public way [which] consists of three separate and distinct parts: the way of exit access, the exit, and the way of exit discharge."
> That's certainly ugly, and it makes us wonder whether an exit has to be defined at all, and, if it does, why couldn't it just be called a way to get out. Then we wonder why a "means of egress" has to be defined at all, and, if it does, why couldn't it be called a way to get to the exit. If these reservations seem reasonable to you, it's because you're just not thinking. You are assuming that any ghastly mess of verbiage that comes from a bureaucracy needs to be simplified because it is needlessly complicated to begin with. Wrong. As it happens, that horrid prose serves its aims perfectly. Regulations of this nature have one clear purpose, and that is to answer, before the fact, any imaginable questions that might be asked in a court of law. For that purpose it's not enough to assume that everyone knows what an exit is. Is a door an exit? Maybe, but maybe not, if a drill press just happens to be standing in front of it. Is a hole in the wall acceptable as an exit? Do you really get out of the building (let's say it's ready to blow up) if you go through a door and find yourself in an enclosed courtyard instead of a "public way"? You don't have to be very clever to think of lots of other such questions, and the writer of this regulation is thinking about your questions. He has done a good job, although he has written something very ugly. But it's only ugly; it's not wrong, it's not more complicated than it has to be. It doesn't need simplification; it needs simply to be kept pretty much out of sight, lest it provide some plain English fanatics with what they think is a useful example.
I'm not convinced I agree with him. I'm sure someone could re-write this example such that it keeps the same meaning but is easier to read.