Praw Emit

booklovertwilight

enki2

How much bad UI design comes from a focus on making the UI consistent with underlying code that was designed based on ease of implementation in the programmer’s language of choice?

This process should be inverted: a consistent UI that can be fully understood by end users should have its principles encoded, & a language & toolkit chosen to match this design. This requires ignoring the selection of widgets toolkits provide & ignoring your own tech preferences in favor of problem fit – which requires stack cosmopolitanism.

But, the end result is that the UI becomes fully understandable to the end user & maintaining the system becomes straightforward. Users stop feeling imposed upon by the inexplicable whims of a powerful dev priesthood.

The norm for a system is that, to understand why the UI behaves the way it does, you need to understand the structure of the program and the facilities of the language – and thus, what was easy for the coder. So, modeling & predicting behavior accurately is something end-users can’t do with these systems unless they learn to code. This is “I drink your milkshake” shit.

This is not a defense of skeuomorphism. People have a mental model of their tasks, and machinery needs to match that mental model of the task, rather than matching devices previously used to perform that task.

The real problem is that instead of thinking about the end goal (what is the most efficient way for the user to think about their task) the programmer thinks about what tools they are most familiar with and how they can use vice grips and duct tape to solve a distorted version of part of the problem with those. (This isn’t always bad. I do this kind of thinking when I’m solving problems for myself, because I’m the end user. Also: ‘ease’ differs between tasks and users and much of the time it makes sense to require study when the user is amenable to it & a dumbed-down interface would simply be inefficient to the point of unusable for an expert user.)

argumate

UI design is fuckin’ hard, even more so because we have near infinite freedom.

stormyeyedsoul

One of the big problems on the programming end is that we’re often building on top of something that already exists, and sometimes you wind up with something that was first designed using Assembly with the work of the next five programmers awkwardly building on top of that, so you’re trying to make something functional while also not toppling this hulking edifice made out of marshmallows and toothpicks

booklovertwilight

I’d add that there’s another layer of chaos to all this, which is that users will frequently want you to design what they’re used to. The problem is that this ends up with a carbon copy of the system that they’re trying to get rid of, because that’s what they’re used to. And oftentimes users don’t realize that this is what’s going on, so the analyst is sitting there halfway through requirements determination going “wait……”

Source: enki2

inferentialdistance

enki2

How much bad UI design comes from a focus on making the UI consistent with underlying code that was designed based on ease of implementation in the programmer’s language of choice?

This process should be inverted: a consistent UI that can be fully understood by end users should have its principles encoded, & a language & toolkit chosen to match this design. This requires ignoring the selection of widgets toolkits provide & ignoring your own tech preferences in favor of problem fit – which requires stack cosmopolitanism.

But, the end result is that the UI becomes fully understandable to the end user & maintaining the system becomes straightforward. Users stop feeling imposed upon by the inexplicable whims of a powerful dev priesthood.

The norm for a system is that, to understand why the UI behaves the way it does, you need to understand the structure of the program and the facilities of the language – and thus, what was easy for the coder. So, modeling & predicting behavior accurately is something end-users can’t do with these systems unless they learn to code. This is “I drink your milkshake” shit.

This is not a defense of skeuomorphism. People have a mental model of their tasks, and machinery needs to match that mental model of the task, rather than matching devices previously used to perform that task.

The real problem is that instead of thinking about the end goal (what is the most efficient way for the user to think about their task) the programmer thinks about what tools they are most familiar with and how they can use vice grips and duct tape to solve a distorted version of part of the problem with those. (This isn’t always bad. I do this kind of thinking when I’m solving problems for myself, because I’m the end user. Also: ‘ease’ differs between tasks and users and much of the time it makes sense to require study when the user is amenable to it & a dumbed-down interface would simply be inefficient to the point of unusable for an expert user.)

argumate

UI design is fuckin’ hard, even more so because we have near infinite freedom.

inferentialdistance

People also have different mental models, which is fucking horrifying to design for.

enki2

Yeah, I don’t think the ratio of implementers to users is appropriate here – or even necessary.

If we wrote UI libraries that weren’t dogshit, even non-programmers could write frontends that make sense to them – and if those frontends don’t make sense to anybody else, that’s fine.

Source: enki2 q

How much bad UI design comes from a focus on making the UI consistent with underlying code that was designed based on ease of implementation in the programmer’s language of choice?

This process should be inverted: a consistent UI that can be fully understood by end users should have its principles encoded, & a language & toolkit chosen to match this design. This requires ignoring the selection of widgets toolkits provide & ignoring your own tech preferences in favor of problem fit – which requires stack cosmopolitanism.

But, the end result is that the UI becomes fully understandable to the end user & maintaining the system becomes straightforward. Users stop feeling imposed upon by the inexplicable whims of a powerful dev priesthood.

The norm for a system is that, to understand why the UI behaves the way it does, you need to understand the structure of the program and the facilities of the language – and thus, what was easy for the coder. So, modeling & predicting behavior accurately is something end-users can’t do with these systems unless they learn to code. This is “I drink your milkshake” shit.

This is not a defense of skeuomorphism. People have a mental model of their tasks, and machinery needs to match that mental model of the task, rather than matching devices previously used to perform that task.

The real problem is that instead of thinking about the end goal (what is the most efficient way for the user to think about their task) the programmer thinks about what tools they are most familiar with and how they can use vice grips and duct tape to solve a distorted version of part of the problem with those. (This isn’t always bad. I do this kind of thinking when I’m solving problems for myself, because I’m the end user. Also: ‘ease’ differs between tasks and users and much of the time it makes sense to require study when the user is amenable to it & a dumbed-down interface would simply be inefficient to the point of unusable for an expert user.)

mine q

stormyeyedsoul

enki2

How much bad UI design comes from a focus on making the UI consistent with underlying code that was designed based on ease of implementation in the programmer’s language of choice?

This process should be inverted: a consistent UI that can be fully understood by end users should have its principles encoded, & a language & toolkit chosen to match this design. This requires ignoring the selection of widgets toolkits provide & ignoring your own tech preferences in favor of problem fit – which requires stack cosmopolitanism.

But, the end result is that the UI becomes fully understandable to the end user & maintaining the system becomes straightforward. Users stop feeling imposed upon by the inexplicable whims of a powerful dev priesthood.

The norm for a system is that, to understand why the UI behaves the way it does, you need to understand the structure of the program and the facilities of the language – and thus, what was easy for the coder. So, modeling & predicting behavior accurately is something end-users can’t do with these systems unless they learn to code. This is “I drink your milkshake” shit.

This is not a defense of skeuomorphism. People have a mental model of their tasks, and machinery needs to match that mental model of the task, rather than matching devices previously used to perform that task.

The real problem is that instead of thinking about the end goal (what is the most efficient way for the user to think about their task) the programmer thinks about what tools they are most familiar with and how they can use vice grips and duct tape to solve a distorted version of part of the problem with those. (This isn’t always bad. I do this kind of thinking when I’m solving problems for myself, because I’m the end user. Also: ‘ease’ differs between tasks and users and much of the time it makes sense to require study when the user is amenable to it & a dumbed-down interface would simply be inefficient to the point of unusable for an expert user.)

argumate

UI design is fuckin’ hard, even more so because we have near infinite freedom.

stormyeyedsoul

One of the big problems on the programming end is that we’re often building on top of something that already exists, and sometimes you wind up with something that was first designed using Assembly with the work of the next five programmers awkwardly building on top of that, so you’re trying to make something functional while also not toppling this hulking edifice made out of marshmallows and toothpicks

Source: enki2

The whole ranking-https-sites-higher thing is actually kind of stupid.

One problem is that it’s absurdly specific (and specific only to the most mediocre form of web security). HTTPS is kind of shit because it lies in the intersection between DNS attacks, registrar attacks, bad UI design encouraging insecure behavior, a wide array of old/bad supported encryption schemes, widespread use, government targeting, and user error – it’s the Windows 95 of protocols. It makes no sense to be rewarding HTTPS over HTTP the same way it makes no sense to be rewarding people for using Windows 95 over DOS – the security improvements are so sparse as to be almost meaningless, and the thing’s so full of holes that most of the ways it can be trivially owned have been documented to death fifteen years ago. If google wanted to encourage security, it would put higher ranking on sites that were only accessible over TOR, or at least on sites that *forced* HTTPS.

Another problem is that HTTPS feeds into existing power structures in several different ways. For one thing, certificates are often quite expensive – your twelve year old nephew can buy a domain name and some server space with his left-over lunch money, but he’ll need to fork over some C-notes if he wants a cert (and if he self-signs, every browser in the world will, for good reason, suspect him). For another, your hypothetical twelve year old nephew can only ultimately buy certificates from a handful of root certificate authorities (and if he buys one from his hosting provider, the money goes right up the tree to the same handful of authorities the same way it will go do the same handful of naming authorities). The same hierarchical structures that have made it so easy for people to pwn huge subsets of the web with a single leaked key represent unavoidable critical paths of money. So, by ranking HTTPS sites higher, you are ranking the sites of people who can’t blow a couple hundred dollars casually lower, and you’re encouraging those who have been on the fence to expand the pocketbooks of GoDaddy and DigiNotar.

The third problem is that it’s ultimately mostly theatre. Widespread use of HTTPS will increase the amount of encrypted traffic around, making it clear that encrypted traffic isn’t an indicator of nefarious purposes, but we aren’t living in the clipper chip era anymore – people use HTTPS to do legitimate banking far more often than they use it to (poorly) mask some illegal or grey-legal deed (hell! they probably use HTTPS to casually browse *wikipedia* more often than they use it to try to break laws or social strictures). TOR needs this kind of widespread non-nefarious use because it not only benefits from the PR but also legitimately benefits from mask traffic (increased volume prevents a wide variety of proposed deanonymization attacks from working, as well as making brute force decryption even harder), but HTTPS in no way benefits from it, particularly if the NSA-inserted backdoors into random number generation hardware and NIST RNG specifications are in active use.

outofcontextargumate

the only useful part is actual specification and UI design, things that most programmers are terrible at.

Source: argumate reblog outofcontextargumate q

Cyberpunk generations

Your opinionated guide to the three generations of cyberpunk

First generation

Archetypal examples: anything in Burning Chrome, Semiotext(e) SF, Cheap Truth, or Mondo 2000; Neuromancer is the only book in the Sprawl trilogy to fall into this generation
Typical cast of characters: burnt-out programmers, drug dealers, petty thieves, obscure gangs, low-level Yakuza or Mafiya hitmen
Common themes: in the near future things aren’t any better than in the recent past; the street finds its own uses for things
Common stylistic concerns: worldbuilding to ensure the world contains old/broken objects (no apple-store utopianism)
Media at the fringe: Web of Angels, A Song Called Youth, Count Zero, Shockwave Rider, Software, Rx: A Tale of Electronegativity, Brazil (film), Transmetropolitan, Cyber City Oedo 808 (series)

Second generation

Archetypal examples: Netrunner (card game), Johnny Mnemonic (film), Hackers (film), Altered Carbon
Typical cast of characters: young and spunky wizard programmers, vast evil corporations, corrupt government officials
Common themes: corporations are sociopathic; don’t trust anyone over 30
Common stylistic concerns: crapsack world (whether or not things are new or functional, things aren’t designed for use by the people – so, brutalistic architecture, or absurdly powerful military organizations)
Media at the fringe: Blade Runner (film), Shockwave Rider, A Song Called Youth, Brazil (film), Lawnmower Man (film), Robocop (film), Paycheck (film), Elysium (film)
Differences from first generation: while the characters in first-generation cyberpunk are largely victims of an uncaring social structure that exacerbates petty human failings, characters in second-generation cyberpunk are victims of active malice by powerful but unambiguously evil organizations. Much of the moral ambiguity is missing – while our protagonists from first generation cyberpunk were clearly antiheroes of questionable moral standing, and are often doing tasks that they themselves consider immoral for money or because of extortion, second-generation cyberpunk protagonists have their own moral failings dwarfed by the moral failings of the antagonists. The focus on worldbuilding and introducing historicity to the setting is largely lost.

Third generation

Archetypal examples: The Matrix (film), Cypher (film), Ghost in the Shell (film), Swordfish (film)
Typical cast of characters: young and brilliant programmers, terrorists
Common themes: computer skill is a force multiplier; robots are scary
Common stylistic concerns: apple-store utopia set dressing with the lights turned off; our heroes are well-equipped and well-trained professionals while our villains are dirty and poor; everyone has impractically large and bulky guns; gunkata
Media at the fringe: The Thirteenth Floor (film), Casino Royale (film), Robocop (film), Paycheck (film)
Differences from second generation: the protagonists of third-generation cyberpunk are often the antagonists of second-generation cyberpunk. Tech fetishism takes priority over worldbuilding. Revenge fantasy is replaced with power fantasy.

The generations somewhat strictly follow a progression from least convenient to drop into an existing story to most convenient, and as a result, the number of pieces of media that essentially use cyberpunk as window-dressing grows as you go down through the generations.

While in first generation there are no unambiguously evil characters and no unambiguously good characters, in third generation our protagonists are unambiguously good and our antagonists are unambiguously bad.

While in first generation there is a focus on ensuring a world just as strange and wooly as the real world, bursting with competing factions and strange cross-cultural misunderstandings and scam artists and pieces of cheap mass-produced junk, by the third generation everything can be shiny-new and streamlined.

While in first generation our main characters are the dregs of society, objectively disempowered and typically performing illegal tasks for selfish reasons, by third generation our main characters are wealthy, well-trained, professional defenders of the status quo performing their tasks out of a sense of duty.

First-generation protagonists are junkies; second-generation protagonists are teenage rebels; third-generation protagonists are super-soldiers.

cyberpunk

Published: How much bad UI design comes from a focus on making the UI consistent with underlying code that was…

Poor UI Design Can Kill – Air Inter Flight 148, a harsh lesson learned | Martin Doms

Published: The end-game of the voice UI (like that of the chat UI) is the command line interface.

See, that’s what the app is perfect for.

More you might like

Published: How much bad UI design comes from a focus on making the UI consistent with underlying code that was…

Poor UI Design Can Kill – Air Inter Flight 148, a harsh lesson learned | Martin Doms

Poor UI Design Can Kill – Air Inter Flight 148, a harsh lesson learned

Published: The end-game of the voice UI (like that of the chat UI) is the command line interface.

Cyberpunk generations

First generation

Second generation

Third generation