Net Neutrality Day of Action

Net Neutrality Day of Action

When Art & Logic started doing business in 1991, we were a fully remote company that pre-dated the availability of the consumer internet; by the time I joined up in 1997 that transition had happened. My initial internet connection when I started here saw me upgrade from a dialup connection to a local ISP over a 56Kb/s modem to a pair of bonded ISDN lines that gave me a screaming 128 Kb/s connection to the A&L servers and my co-workers.

As the consumer internet exploded, our project mix followed the same transition that the rest of the world did — we went from 100% of our projects being standalone desktop applications running natively on Windows or macOS, to a few web projects (including a ton of embedded web projects — in 2017 you expect to be able to configure networked hardware by pointing a web browser at it, but in the late 90s that was the New Frontier) to our current mix that’s largely web and mobile with some interesting desktop apps tagging along as well.

We, along with every one of the clients that we’ve developed projects for in that period, have depended on strong net neutrality to enable our innovation — once your service is on the internet, your traffic is on the same footing as everyone else’s. As Gertrude might say today, a bit is a bit is a bit.

Recently, the FCC has proposed rule changes that have the potential to turn this all upside down — here’s a bit of background from meta.stackeschange.com :

Back in 2014, the United States Federal Communication Commission, in response to numerous complaints and concerns, implemented a set of rules that prohibit Internet Service Providers from blocking specific content providers or charging them for access to their networks. Essentially, a set of rules that prevent an ISP from double-dipping on service they’re already being paid for, or blocking access to specific websites just for the hell of it.

In order to do this, they had to change how ISPs were classified, moving them from a “Title I” classification to “Title II” – more or less the same framework for regulation that’s been in place for phone companies for decades, establishing them as a so-called “common carrier” – that is to say, one which may not discriminate between customers. If you already assumed that this is how the Internet worked, you’re not alone; however, due to how they were classified previously the FCC had been unable to enforce rules that would ensure that traffic over the Internet would continue be allowed to work as, well, traffic over the Internet was expected to work.

(also scroll down for the answers on the rest of that page for more discussion and links on the topic than you probably have time for today).

The group Fight for the Future has declared today, 12 July 2017, as a day of action, for “regular friendly Internet users like you to submit your comments and concerns to the FCC about their plans to do away with net neutrality.”

If you’re in the US and would like to participate, you can:

Other links on the topic:

Art & Logic at SXSW Interactive 2017

Art & Logic at SXSW Interactive 2017

Once again, Art & Logic will have representatives from our development, recruiting, and sales/marketing groups attending the South by Southwest Interactive Festival in Austin, Texas from March 10th – 14th. We’d love to meet with anyone there who’s interested in talking about a software development project or opportunities for software developers & designers at A&L.

Please send me an email at bgporter@artandlogic.com so we can coordinate a meeting amidst the madness of SXSW.

(Also, please keep me in your thoughts, as my airline keeps sending me text messages warning that a winter storm arriving overnight threatens massive delays and cancellations of flights tomorrow, hopefully not including my flight to Austin).

 

A C++ Class Factory for JUCE

A C++ Class Factory for JUCE

The Problem

So, I’m working on a side project (as one does), and reach the point in development where I need to be able to take a tree of objects that all share a common base class and persist them to and from disk.

I prefer using plain text files to binary (for a bunch of different reasons, most of them enumerated in the original The Pragmatic Programmer book), so the problem really boils down to:

At runtime, I need to be able to convert a string containing the name of a class into a pointer to an object of the corresponding C++ class.

If you do like I did, and go to the shelf to see what the old Gang of Four Design Patterns book has to say on the matter, maybe you’d have been underwhelmed, too. (more…)

Book Review: Programming Beyond Practices

Book Review: Programming Beyond Practices

Be More Than Just A Code Monkey

I wrote this book because I believe the shift away from “programmer as coding specialist” is inevitable. If that’s true, then our entire field will need to prepare itself for the not-so-distant future where “programmer as skilled solver of ordinary human problems” becomes the norm.

— Gregory T. Brown

I picked up this deceptively slender (~115 pages) book after reading an article about it on the O’Reilly site a week or so ago that said “it’s sort of like The Pragmatic Programmer for a new generation.” Given how important that book’s been for me as a developer (it’s in my periodic re-read pile, along with Code Complete, the GoF Design Patterns book and Knuth’s Literate Programming), it didn’t take much thinking before ordering a copy.

(more…)

The Best Interface is an Enchanted Object

The Best Interface is an Enchanted Object

A few weeks ago, I posted a review of the recent book on building connected products from O’Reilly. I also have a few more books on the shelf here that touch on this area from a slightly different angle.

The Best Interface Is No Interface

nointerface

I became aware of Golden Krishna, the author of this book when I attended his panel criticizing the use of dropdowns at SXSW 2016. The content in this book predates that panel by a few years, originally presented as a keynote at SXSW 2013.

The basic thesis of the book is that it’s variously easy, lazy, and sloppy to always try to address the problems we’re solving through technology by slapping a screen-based interface on top of things. Early in the book he gives the example of a keyless entry system advertised by BMW, that requires the following 13 steps to occur between a user walking up to her car and actually opening the door:

  1. Walk up to my car
  2. Pull out my smartphone
  3. Wake up my phone
  4. Unlock my phone
  5. Exit my last opened app
  6. Exit my last opened group
  7. Swipe through a sea of icons, searching for the app
  8. Tap the app icon
  9. Wait for the app to load and try to find the unlock action
  10. Make a guess with the menu and tap “Control”
  11. Tap the Unlock button
  12. Slide the slider to unlock
  13. Physically open the car door (my goal)

Compare that with the obviously better sequence

  1. Walk up to my car
  2. Physically open the car door (my goal)

…which is how things behave on recent Tesla models (with the added coolness of the door handles changing from being completely recessed into the body until someone tries to open them).

The book’s 21 chapters thoroughly outline the problem, three general principles to follow in addressing the problem (“Embrace Typical Processes Instead of Screens”, “Leverage Computers Instead of Serving Them”, and “Adapt to Individuals”), and some of the challenges that make this approach to design not quite so easy.

Enchanted Objects

Mining a similar vein is David Rose’s 2014 book Enchanted Objects:

enchantedobjects

Some believe the future will look like more of the same—more smartphones, tablets, screens embedded in every conceivable surface. David Rose has a different vision: technology that atomizes, combining itself with the objects that make up the very fabric of daily living. The Enchanted Objects of fairy tales and science fiction will enter real life.

The opening paragraph of the book’s prologue could almost have been extracted from somewhere in ‘The Best Interface is No Interface’:

I have a recurring nightmare. It is years into the future. All the wonderful everyday objects we once treasured have disappeared, gobbled up by an unstoppable interface: a slim slab of black glass … its face filled with tiny, inscrutible icons that now define and control our lives.

These two books work together as great complements; however, Rose’s focus on building Enchanted objects alters the tone of things quite a bit. Recurring themes and references take that idea of Enchantment quite literally, as he looks at fictional magical artifacts from the Harry Potter universe.

Besides many case studies of examples that illustrate his premises, he provides a pair of frameworks for thinking about systems that can be used as a designer of enchanted objects:

Six Human Drives

In these chapters, Rose develops dialectics between fictional enchanted objects (e.g., Dorothy’s Silver/Ruby slippers) and an analogous real one (in this case, the Nike+ shoes). He delineates six human drives that can be augmented or addressed through enchanted objects:

  1. Omniscience
  2. Telepathy
  3. Safekeeping
  4. Immortality
  5. Teleportation
  6. Expression

The Design of Enchantment

This set of chapters discusses opportunities and techniques for engaging more of our users’ senses through system design, rather than requiring the user to focus on a glass slab. He calls for a careful use of ‘subtle and subliminal phenomena’. He calls these out as the ‘Seven Abilities of Enchantment’:

  1. Glanceability
  2. Gestureability
  3. Affordability
  4. Wearability
  5. Indestructability
  6. Usability
  7. Loveability

Optimism and Humanism

Especially when considered as a pair, even though there’s much in these books that’s deeply and sometimes harshly critical of products that have been widely lauded, I see these books as extremely optimisitic visions of the future than not only should be, but that actually can be.

I’m not sure which will prove to be more difficult in practice:

  • Learning to put these kinds of approaches and principles into practice when desiging systems
  • Convincing the stakeholders on our projects that we can use these ideas to build better systems that adapt to their human users instead of continuing to require the opposite.

One could say that the ideas behind these ideas go back a long time, popping up in books like Donald Norman’s classic “The Design of Everyday Things”, “User Centered System Design”, or Jef Raskin’s “The Humane Interface,” but those were all written in an era when the idea of tiny battery-powered computing devices that are orders of magnitude more powerful than desktop/workstation machines of the era was still purely speculative.

The future is finally getting here, let’s try not to mess this part of it up.