"design" entries

Four short links: 7 July 2015

Four short links: 7 July 2015

SCIP Berkeley Style, Regular Failures, Web Material Design, and Javascript Breakouts

  1. CS 61AS — Berkeley self-directed Structure and Interpretation of Computer Programs course.
  2. Harbingers of Failure (PDF) — We show that some customers, whom we call ‘Harbingers’ of failure, systematically purchase new products that flop. Their early adoption of a new product is a strong signal that a product will fail – the more they buy, the less likely the product will succeed. Firms can identify these customers either through past purchases of new products that failed, or through past purchases of existing products that few other customers purchase.
  3. Google Material Design LiteA library of Material Design components in CSS, JS, and HTML.
  4. Breakoutsvarious implementations of the classic game Breakout in numerous different [Javascript] engines.
Four short links: 1 July 2015

Four short links: 1 July 2015

Recovering from Debacle, Open IRS Data, Time Series Requirements, and Error Messages

  1. Google Dev Apologies After Photos App Tags Black People as Gorillas (Ars Technica) — this is how you recover from a unequivocally horrendous mistake.
  2. IRS Finally Agrees to Release Non-Profit Records (BoingBoing) — Today, the IRS released a statement saying they’re going to do what we’ve been hoping for, saying they are going to release e-file data and this is a “priority for the IRS.” Only took $217,000 in billable lawyer hours (pro bono, thank goodness) to get there.
  3. Time Series Database Requirements — classic paper, laying out why time-series databases are so damn weird. Their access patterns are so unique because of the way data is over-gathered and pushed ASAP to the store. It’s mostly recent, mostly never useful, and mostly needed in order. (via Thoughts on Time-Series Databases)
  4. Compiler Errors for Humans — it’s so important, and generally underbaked in languages. A decade or more ago, I was appalled by Python’s errors after Perl’s very useful messages. Today, appreciating Go’s generally handy errors. How a system handles the operational failures that will inevitably occur is part and parcel of its UX.
Four short links: 29 June 2015

Four short links: 29 June 2015

Surgery Lag, Clippy Lesson, Telegram Bots, and Censorship Complicity

  1. Surgery Lag Time (ComputerWorld) — doctors trialling very remote surgery (1200 miles) with a simulator, to see what naglag is acceptable. At 200 milliseconds, surgeons could not detect a lag time. From 300 to 500 milliseconds, some surgeons could detect lag time, but they were able to compensate for it by pausing their movement. But at 600 milliseconds, most surgeons became insecure about their ability to perform a procedure, Smith said.
  2. Clippy Lessons (The Atlantic) — focus groups showed women hated it, engineers threw out the data, and after it shipped … It turned out to be one of the most unpopular features ever introduced—especially among female users.
  3. Telegram’s Bot PlatformBots are simply Telegram accounts operated by software – not people – and they’ll often have AI features. They can do anything – teach, play, search, broadcast, remind, connect, integrate with other services, or even pass commands to the Internet of Things. (via Matt Webb)
  4. New Wave of US Companies in China (Quartz) — Evernote and LinkedIn let the Chinese government access data and censor results. Smith believes that LinkedIn and Evernote are setting a dangerous precedent for other internet firms eying the Middle Kingdom. “More US companies are going to decide that treating the Chinese like second class information citizens is fine,” he says.
Four short links: 25 June 2015

Four short links: 25 June 2015

Enchanted Objects, SE Blogs, AI Plays Mario, and Google's Future of Work

  1. 16 Everyday Objects Enchanted by Technology (Business Insider) — I want a Skype cabinet between our offices at work.
  2. Software Engineering Blogs — ALL the blogs!
  3. MarI/O (YouTube) — clear explanation of how an evolutionary algorithm figures out how to play Mario.
  4. Google’s Monastic Vision for the Future of Work (New Yorker) — But it turns out that future-proofed life looks a lot like the vacuum-packed present. […] Inside, it is about turning Google into not only a lifestyle but a fully realized life. The return of the Company Town.
Four short links: 9 June 2015

Four short links: 9 June 2015

Parallelising Without Coordination, AR/VR IxD, Medical Insecurity, and Online Privacy Lies

  1. The Declarative Imperative (Morning Paper) — on Dataflow. …a large class of recursive programs – all of basic Datalog – can be parallelized without any need for coordination. As a side note, this insight appears to have eluded the MapReduce community, where join is necessarily a blocking operator.
  2. Consensual Reality (Alistair Croll) — Among other things we discussed what Inbar calls his three rules for augmented reality design: 1. The content you see has to emerge from the real world and relate to it. 2. Should not distract you from the real world; must add to it. 3. Don’t use it when you don’t need it. If a film is better on the TV watch the TV.
  3. X-Rays Behaving BadlyAccording to the report, medical devices – in particular so-called picture archive and communications systems (PACS) radiologic imaging systems – are all but invisible to security monitoring systems and provide a ready platform for malware infections to lurk on hospital networks, and for malicious actors to launch attacks on other, high value IT assets. Among the revelations contained in the report: A malware infection at a TrapX customer site spread from a unmonitored PACS system to a key nurse’s workstation. The result: confidential hospital data was secreted off the network to a server hosted in Guiyang, China. Communications went out encrypted using port 443 (SSL) and were not detected by existing cyber defense software, so TrapX said it is unsure how many records may have been stolen.
  4. The Online Privacy Lie is Unraveling (TechCrunch) — The report authors’ argue it’s this sense of resignation that is resulting in data tradeoffs taking place — rather than consumers performing careful cost-benefit analysis to weigh up the pros and cons of giving up their data (as marketers try to claim). They also found that where consumers were most informed about marketing practices they were also more likely to be resigned to not being able to do anything to prevent their data being harvested. Something that didn’t make me regret clicking on a TechCrunch link.
Four short links: 3 June 2015

Four short links: 3 June 2015

Filter Design, Real-Time Analytics, Neural Turing Machines, and Evaluating Subjective Opinions

  1. How to Design Applied FiltersThe most frequently observed issue during usability testing were filtering values changing placement when the user applied them – either to another position in the list of filtering values (typically the top) or to an “Applied filters” summary overview. During testing, the subjects were often confounded as they noticed that the filtering value they just clicked was suddenly “no longer there.”
  2. Twitter Herona real-time analytics platform that is fully API-compatible with Storm […] At Twitter, Heron is used as our primary streaming system, running hundreds of development and production topologies. Since Heron is efficient in terms of resource usage, after migrating all Twitter’s topologies to it we’ve seen an overall 3x reduction in hardware, causing a significant improvement in our infrastructure efficiency.
  3. ntman implementation of neural Turing machines. (via @fastml_extra)
  4. Bayesian Truth Seruma scoring system for eliciting and evaluating subjective opinions from a group of respondents, in situations where the user of the method has no independent means of evaluating respondents’ honesty or their ability. It leverages respondents’ predictions about how other respondents will answer the same questions. Through these predictions, respondents reveal their meta-knowledge, which is knowledge of what other people know.
Four short links: 21 May 2015

Four short links: 21 May 2015

Font Design, Pro Go, ICANN Foolishness, and Bad Organisations

  1. On Font Design (Kris Sowersby) — The many pairs of hands and eyes involved have made this typeface special for me. For the first time I don’t feel I have ownership of a typeface I have ostensibly “created.” Lovely to read about the design journey for a font.
  2. Why We Use GoWe use Go because it’s boring. Previously, we worked almost exclusively with Python, and after a certain point, it becomes a nightmare. You can bend Python to your will. You can hack it, you can monkey patch it, and you can write remarkably expressive, terse code. It’s also remarkably difficult to maintain and slow.
  3. Unfortunately We Have Renewed Our ICANN AccreditationYou can thank ICANN for this policy, because if it were up to us, and you tasked us with coming up with the most idiotic, damaging, phish-friendly, disaster-prone policy that accomplishes less than nothing and is utterly pointless, I question whether we would have been able to pull it off at this level. We’re simply out of our league here.
  4. Why Good Developers Write Bad Code (PDF) — trigger warning: software development pathologies from the real world.
Four short links: 25 March 2015

Four short links: 25 March 2015

Selling Customers, Classier Parsing, License Plates, and GitHub's CSS

  1. RadioShack’s Customer Data For Sale (Ars Technica) — trying to sell customer data as part of court-supervised bankruptcy.
  2. Classp: A Classier Way to Parse (Google Code) — The abstract syntax tree is what programmers typically want to work with. With class patterns, you only have two jobs: design the abstract syntax tree and write a formatter for it. (A formatter is the function that writes out the abstract syntax tree in the target language.)
  3. 4.6M License Plate Records From FOIA Request (Ars Technica) — from Oakland.
  4. Primerthe CSS toolkit and guidelines that power GitHub.
Four short links: 23 March 2015

Four short links: 23 March 2015

Agricultural Robots, Business Model Design, Simulations, and Interoperable JSON

  1. Swarmfarm RoboticsHis previous weed sprayer weighed 21 tonnes, measured 36 metres across its spray unit, guzzled diesel by the bucketload and needed a paid driver who would only work limited hours. Two robots working together on Bendee effortlessly sprayed weeds in a 70ha mung-bean crop last month. Their infra-red beams picked up any small weeds among the crop rows and sent a message to the nozzle to eject a small chemical spray. Bate hopes to soon use microwave or laser technology to kill the weeds. Best of all, the robots do the work without guidance. They work 24 hours a day. They have in-built navigation and obstacle detection, making them robust and able to decide if an area of a paddock should not be traversed. Special swarming technology means the robots can detect each other and know which part of the paddock has already been assessed and sprayed.
  2. Route to Market (Matt Webb) — The route to market is not what makes the product good. […] So the way you design the product to best take it to market is not the same process to make it great for its users.
  3. Explorable Explanations — points to many sweet examples of interactive explorable simulations/explanations.
  4. I-JSON (Tim Bray) — I-JSON is just a note saying that if you construct a chunk of JSON and avoid the interop failures described in RFC 7159, you can call it an “I-JSON Message.” If any known JSON implementation creates an I-JSON message and sends it to any other known JSON implementation, the chance of software surprises is vanishingly small.

Full-stack tensions on the Web

How much do you need to know?

Vista_de_la_Biblioteca_VasconcelosI expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.

In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.

Formal separation of concerns among HTML, CSS, and JavaScript made it easier to share responsibilities among specialists. As the dot-com boom proceeded, specialization accelerated, with dedicated designers, programmers, and sysadmins coming to the work. Perhaps there were too many titles.

Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
Read more…