Gary Graham writes about some of the dangers of the smart city movement in Too-smart cities? Why these visions of utopia need an urgent reality check:

Ideally a future city will have inner-city areas that are sustainably created through private, for-profit initiatives, and investment based on genuine competitive advantage — not through artificial inducements, charity or government mandates.

The people living in cities far outnumber the people making decisions about what those cities should look like in the future. They are disconnected from the plans being made by companies and even governments on their behalf.

We need to start working with everyday citizens to find the right questions — and then work with them towards developing solutions to the problems they raise.

The article also mentions the city of Brasília as an example of a failed experiment because it didn’t take the needs of its citizens into consideration. That’s a topic that’s near and dear to me:

Together, we can avoid building digital Brasílias — projects that generate buzz, but don’t meet the needs of the people who live there.

Tim Wu brings up some interesting points in Why Making Technology Easier to Use Isn’t Always Good:

We make ourselves into what we, as a species, will become, mainly through our choices as consumers. If you accept these premises, our choice of technological tools becomes all-important; by the logic of biological atrophy, our unused skills and capacities tend to melt away, like the tail of an ape. It may sound overly dramatic, but the use of demanding technologies may actually be important to the future of the human race.

Wu explains that if everything is easy, we’ll simply stop learning things. So what are these “demanding technologies” like?

Three elements are defining: it is technology that takes time to master, whose usage is highly occupying, and whose operation includes some real risk of failure. By this measure, a piano is a demanding technology, as is a frying pan, a programming language, or a paintbrush. So-called convenience technologies, in contrast — like instant mashed potatoes or automatic transmissions — usually require little concentrated effort and yield predictable results.

In WordPress: How It Came To Be And Where It’s Heading Alex Moss interviews Matt Mullenweg and Mike Little, the two cofounders of WordPress. The whole interview is interesting, but their approach to technical debt caught my eye in particular:

We rewrite or refactor about 10 to 15% of WordPress in most releases, so that we can keep users getting updates and new features quickly, while doing the “ground up rebuild” incrementally in the background, fixing bugs and getting feedback as we go.

This is, in my experience, the best way to handle technical debt: pay down a little bit of it in every release. To steal a slide from my Product Management course, here’s my general rule of thumb (and of course there will be exceptions) for balancing a product roadmap:

Lee Hutchinson, who was a system administrator at Boeing at the time of the space shuttle Columbia disaster in 2003, looks back at that tumultuous time in a long but absolutely fascinating article for Ars Technica:

In August 2003, the Columbia Accident Investigation Board (CAIB) issued its final report. Behind the direct cause of the foam strike, the report leveled damning critiques at NASA’s pre- and post-launch decision-making, painting a picture of an agency dominated by milestone-obsessed middle management1. That focus on narrow, group-specific work and reporting, without a complementary focus on cross-department integration and communication2, contributed at least as much to the loss of the shuttle as did the foam impact. Those accusations held a faint echo of familiarity—many of them had been raised 17 years earlier by the Rogers Commission investigating Challenger’s destruction.

The report also asked a team at NASA to figure out what a rescue plan might have looked like:

To put the decisions made during the flight of STS-107 into perspective, the Board asked NASA to determine if there were options for the safe return of the STS-107 crew.

The rest of the article explains the possible rescue plan in detail. If you have any interest in science or space exploration this is a must-read.

I found the article particularly interesting because I had just finished reading my favorite novel of the year so far: The Martian by Andy Weir. The article echoed a lot of the concepts mentioned in the novel, which gave me a new appreciation for the story. I highly recommend this surprisingly plausible and funny book as well.

---

1. See, this is a problem everywhere, not just in software development… ↩

2. This too. ↩

I really enjoyed Nick Stockton’s exploration of the space syntax concept in architecture in There’s a Science to Foot Traffic, and It Can Help Us Design Better Cities. He explains:

Space syntax [is] the science of how cities work. In the late 1970s, British architects Bill Hillier and Julienne Hanson hit on the idea that any space within a city — or the entire city itself — could be analyzed in terms of connectivity and movement. They reasoned that a city’s success depended largely on how easy it was for people to move about on foot.

This wasn’t a huge revelation. Studies reaching as far back as 1960s have shown walkable cities have higher property values, healthier residents, and lower crime. What set Hillier and Hanson’s ideas apart was the notion that a city’s geometry did more for movement than any other design factor. They argued that every other cog in a city’s engineering depends on the walkable grid. Cars, buses, trains, and bikes play a role, too, but only as much as they transport people to places where they then proceed to walk around.

There’s some great examples in the article, including a case study on the redesign of Trafalgar Square in London.

A big thanks to Creative Labs for sponsoring Elezea’s RSS feed this week with their AXX 200 sound system!

We believe there’s so much more that your portable wireless speaker should do for you. That’s why we made the AXX 200.

The AXX 200 is a Bluetooth wireless speaker + Sound Blaster audio processor. This means a portable wireless speaker with power for real-time audio enhancement.

Intelligence. That’s what the AXX 200 brings to the table.

• Make a call. Listen to music. AXX 200 intelligently adjusts the audio settings for you.
• The Sound Blaster Central App for your iOS or Android device places the control in your hands.
• Built-in quad array microphone - That’s FOUR microphones in a single wireless speaker for 360° of clear, unmatched audio pickup for voice calls and recording.
• A wireless speaker that automatically cancels out noise during voice calls. For real.

It’s for work, it’s for play. It can be everything you need it to be.

The AXX 200 is now on sale for a limited time at Creative.com and Amazon.com.

The small screens are coming, and we’re going to have to adjust our design processes accordingly. Emily Schwartzman does a great job of exploring how they worked through some of this complexity in Cooper, Augmedix and Google Glass: No Real Estate? No Problem:

Designing for Google Glass made us rethink the way we do software design. Many of our projects devote a significant amount of time to defining the framework of an application and developing the detailed design of key screens. When designing for Glass, we discovered that these phases needed almost no time, given the restrictive framework and visual language defined by Google. For future projects we might devote more time to refining personas and scenarios. We might even name the project phases a little differently—instead of “detailed wireframes” it might be “detailed scenarios.”

In general, Glass design projects will be focused more on flows than screens, and spending time on scenarios will help crystallize the flows.

In The Dawn of the Age of Artificial Intelligence Erik Brynjolfsson and Andrew McAfee talk about some of the good things that are coming out of the Artificial Intelligence community:

A user of the OrCam system, which was introduced in 2013, clips onto her glasses a combination of a tiny digital camera and speaker that works by conducting sound waves through the bones of the head. If she points her finger at a source of text such as a billboard, package of food, or newspaper article, the computer immediately analyzes the images the camera sends to it, then reads the text to her via the speaker.

There are a few more interesting, feel-good examples in the article.

Jeremy Keith writes about the challenges of turning large, established desktop-centric sites into responsive sites in Climbing Mount Responsive. This method remains my favorite:

Rebuild the mobile site, using it as a seed from which to grow a new responsive site. On the face of it, having a separate mobile subdomain might seem like a millstone around your neck if your trying to push for a responsive design. In practice though, it can be enormously useful. Mostly it’s a political issue: whereas ripping out the desktop site and starting from scratch is a huge task that would require everyone’s buy-in, nobody gives a shit about the mobile subdomain. Both the BBC news team and The Guardian are having great success with this approach, building mobile-first responsive sites bit-by-bit on the m. subdomain, with the plan to one day flip the switch and make the subdomain the main site.

I also really like Brad Frost’s illustrations of this approach in Planting the Seed for a Responsive Future.

John Foreman digs into Disney’s MagicBands in his article You don’t want your privacy — Disney and the meat space data race:

Disney World is like a petri dish for advanced analytic techniques because the hotels and parks are all tied together in one large, heavily controlled environment. If you ever wanted to star in The Truman Show, a trip to Disney is the next best thing — it feels like a centrally planned North Korea only with more fun, less torture and the same amount of artifice.

From the mundane to the magical, the fact is there’s probably an engineer behind the scenes at Disney who has thought through it. Disney has industrial engineers that work on everything from optimal food-and-beverage pricing and laundry facility optimization, to attraction performance and wait-time minimization (the vaunted FASTPASS system).

The article is largely a negative look at (legitimate) privacy issues with programs like these, but in Disney’s case, I just think it sounds awesome.