In 2018, the iPad Pro is the most sophisticated tablet to date. How close is it to matching a Mac, Windows, or Linux computer for creative or productive tasks?

Not very close, it seems. Our user research indicates that most creative professionals — that is, artists, scientists, writers, designers, software engineers — mainly use a desktop or a laptop computer for their work. They often like the idea of tablets, but in practice their iPad is used for Netflix and social media on the sofa. As application developers, we might ask why.

One possibility is that tablet apps are mostly designed as scaled-up smartphone apps. And phone apps are designed for consumers: optimized for zero learning curve rather than power or flexibility.

Watch a creative professional using a tool like Photoshop, AutoCAD, vim, or Excel and see how quickly and confidently they can make complex changes to a document. What would it take to create a fast and precise tool like this on a tablet?

The Ink & Switch research team set out to explore this question. Our preliminary findings are that a tablet can be a powerful tool for creative tasks — but only by challenging some of the design orthodoxies of mobile app development.

The prototype

Our proof-of-concept is an iPad app called Dossier.

Dossier is Evernote meets Pinterest. You can capture text, images, links, PDFs, and any other file format into a collection. Each item displays as a card which can be arranged spatially on a virtual pinboard.

Dossier requires a stylus and uses Dropbox for storage.

Challenging the mobile app design orthodoxy

We built this prototype with five unusual interface ideas in mind, as follows.

1. Stylus required

When I got started with computers running MS-DOS in the 1980s, the mouse was an optional accessory. Software developers couldn’t assume it was available. Today, the stylus gets the same treatment. Because most tablets (such as the iPad or Microsoft’s Surface) don’t come with a stylus by default, app developers treat the stylus as just another finger, albeit a more precise one.

For Dossier, the stylus is required, opening new possibilities for command richness.

2. Put your hands all over it

I find tablets appealing because they are similar to my A5 paper notebook. It’s a delight to sketch in my notebook at a coffee shop, at my desk, or sitting on a park bench. A tablet is roughly the same size and shape, but often doesn’t offer the same joy of use.

One reason is that tablet apps typically have many active buttons and controls on the edge of the screen. Given the nearly edge-to-edge screen, it’s hard to grip the device without accidentally pushing a button or scrolling the page. I end up holding my tablet with the tips of my fingers, vaguely afraid to grip it the way I would my paper notebook.

Apple’s Keynote has active controls cover two out of four edges of the screen

For Dossier, we tried to have a minimum of active controls onscreen, particularly near the edges.

3. No-wait commands

Touchscreens have a small number of gestures: tap, swipe, double-tap, pinch, and a few others. Smartphone apps further assume a small screen and one-handed operation — which means many commands end up tucked away behind long-press or other commands with built-in delay.

Dragging items between pages is similarly friction-inducing: users have been trained to drag an item to the edge of the page, then wait a while for the scrolling to kick in.

Perhaps the worst offender for power users is copy and paste. On the desktop these crucial commands can be invoked almost anywhere with ctrl-C or ctrl-V. On mobile, it’s a fussy process of accessing a context menu.

For Dossier, we made it a goal that no input method would require the user to wait, even briefly.

4. Read the manual

Consumer app development assumes that users must immediately understand how to use the app with little to no instruction.

But creative professionals are different. We are okay with investing some time learning a tool if that investment pays off in power, flexibility, and expressiveness using the tool later on. Again think of packages like Photoshop, vim, AutoCAD, and Excel.

Further yet: we appreciate documentation. A product that comes with a manual implies it has depth.

For Dossier, we ask the user to read the manual, considering that a reasonable tradeoff for a more capable tool.

5. Command vocabulary

Every user interface has a command vocabulary. Desktop platforms typically show their full vocabulary including keyboard shortcuts in the menu bar. Combined with a pointing device and modifier keys and you have thousands of discrete inputs that can form the app’s command vocabulary.

On a tablet, the usual list of input gestures (tap, two-finger tap, swipe, pinch, etc) is quite small. Even allowing for two hands (e.g. pinch with one hand, tap with the other) and our potential command vocabulary only counts in the dozens. But the stylus opens up a whole new class of input: writing.

Our team took inspiration from the 1991 tablet operating system PenPoint OS. Among it many gestures, PenPoint allowed the user to draw glyphs over the top of onscreen objects to issue commands. For example, a circle to edit the item, and an X to delete it.

For Dossier, we resolved to build a rich command vocabulary using stylus gylphs in addition to all of the finger gestures.

Putting it all together

Using these five premises, we built the prototype app as follows:

1. Stylus required: We take advantage of everything at the disposal of the average human: two hands (including ten individual fingers) and the stylus as distinct input methods, sometimes used in tandem.
2. Put your hands all over it: Dossier has almost zero chrome, allowing the user’s content to occupy the entire screen, and very few buttons activated by a single tap.
3. No-wait commands: Nothing in the Dossier command vocabulary requires long-press or other delay. The common operation of moving a card via one-finger drag responds instantly, metaphorically like sliding index cards around on a table.
4. Read the manual: Dossier has a cheatsheet available in the main menu which describes the full palette of commands available to the user.

All of this comes together with point 5, the command vocabulary. Commands such as copy, paste, and delete (normally hidden behind long-press context menus on mobile applications) are available by drawing a glyph with your stylus. We recognize glyphs using the $1 Unistroke recognizer as implemented in Swift.

Each command gives a flash notice (inspired by Pixelmator on Mac) that matches the command name shown on the cheatsheet. Draw an X to delete and you see “delete card” as well as the card disappearing animation. Draw that same X over a page in the collection overview and you see “delete page.”

Also included is the more common use of the stylus: freeform sketching. In Dossier it takes the form of annotations with a feel similar to drawing on a whiteboard with a black marker.

See the full tour in this 2-minute demo video:

Findings

Our team tested the app internally for our own use cases: project brainstorming, travel planning, meal prep notes, an office remodel project. We found it a useful alternative to Evernote, Pinterest, or Google Docs for this type of “get your thoughts together” or “make a plan” work.

We tested Dossier with four external users. In each case, the user exhibited initial confusion that mobile app conventions such as one-finger swipe didn’t work as expected. But as they consulted the cheatsheet and experimented with the commands, they developed an ability to work with the tool within a few minutes. Our takeaway was that the learning curve was surprisingly small relative to the payout in capabilities offered by Dossier relative to other iPad apps.

In my personal experience using the app, I really enjoyed quickly pulling in text, image, and PDF cards from different sources and grouping them spatially to find patterns. I also found Dossier useful as sort of fast, low-effort slide deck creator for ad-hoc presentations over screenshare with my team.

Conclusion

We set out to question some common mobile design practices in pursuit of making the tablet a fast and precise tool. The result was the command vocabulary with no-wait commands, stylus glyphs, a flash notice to reinforce the user’s actions, and a mini-manual in the form of the cheatsheet.

Based on these preliminary findings our team believes that the tablet can eventually be a viable platform for creative professionals. But to achieve that may require app developers to break free of some assumptions from the consumption computing world.

We’re sharing our findings in hopes that other digital toolmakers might borrow these ideas for their production apps, or that other researchers might continue to explore further in this direction. Further ideas to explore include multistroke recognizers, voice commands, and chorded keyboards.

We’d love to hear what you think or hear about your work in this domain. You can reach us on Twitter or at hello@inkandswitch.com.

Update August 2019: Want to try it? Many of the ideas from the Dossier project will appear in Muse for iPad.

Dossier was built by Julia Roggatz (engineering), Miloš Milikić (design), and me, Adam Wiggins (project lead). Special thanks to James Lindenbaum, Roshan Choxi, Orion Henry, Mark McGranaghan, and Martin Kleppmann.

The first stop on my European startup journey is a deep-dive with reproductive health app Clue. This week I’m working with their engineering team to explore possibilities for how to add a backend to the app.

Mobile syncing technology

So it’s 2014, and well-behaved mobile apps that connect to a backend should use a syncing model rather than a network call for every user action. Right?

Apps like Pocket, SimpleNote, and WunderList do a great job of continuing to operate normally when your internet connection is spotty or non-existent. They queue up your changes and stream them out to the network when it becomes available. The apps don’t become unresponsive or pop up weird errors when you use them on the U-Bahn (a common use case for those of us living and working in Berlin).

But much more common are apps like Facebook, Yelp, and Twitter, all of which behave erratically when your network connection is slow or unavailable. You could argue that these apps are essentially fancy web browsers to connect to a web service and syncing doesn’t make sense in these cases. But I’d prefer to see Clue’s app behave more like Pocket than Facebook when it comes to intermittent network capability.

Couchbase

Over the last few days, the Clue engineering team and I have looked at a number of services, open source libraries, tutorials, and general discussions on syncing (like this excellent slide deck). There are surprisingly few options given what a common use case mobile syncing. We did a handful of spikes to see how some of these different approaches would feel in practice.

One of these spikes had quite interesting results that I’m going to talk about here: Couchbase Mobile.

Couchbase is an open-source document database that has a confusing pedigree involving CouchDB and Memcached. But for the purposes of how the sync works, it seems to be conceptually compatible with the CouchDB multi-master replication model.

Client-server vs multi-master

It took some effort to get my head around the Couch syncing model. But once it clicked I found it quite elegant.

Client-server is what I’m most familiar with. Here you have a client, something like an iOS or Android app, or a good old-fashioned web browser. The client makes an HTTPS call to a server, probably some Ruby or Python or Go app that is running on Heroku or AWS or the Raspberry Pi in your closet. The web app can do whatever logic it wants, probably talking to a database (like Postgres, Redis, or MongoDB) for persistence. The web app returns its results and the client renders it.

This is the model that breaks down when network connectivity is intermittent. Any user action has the client waiting for the server to respond.

The Couch model differs in that it puts a Couch database everywhere you’re going to store the data. If you have an iPhone talking to a backend, that means you have two CouchDBs: one on the iPhone, and one on the backend. If you add an iPad to the mix, you now have three CouchDBs. And so on.

The lightbulb moment for me came by thinking of the difference between client-server vs master-master syncing as the difference between Subversion and Git.

With Subversion, you can’t commit changes unless you can talk to the server. Unavailable or intermittent network connectivity blocks your ability to work. Git (and other DVCSes), on the other hand, store a copy of the revision control database (as the .git directory) with every repository. So you can work continuously without network, committing as you go. Git pull & push do a sync.

Using Couchbase for mobile syncing is conceptually and architecturally similar, and offers many of the same benefits.

Couchbase Mobile

Couchbase Mobile is a stack of technologies using Couchbase as the backend data store and a series of embeddable Couchbase libraries (iOS, Android) for your clients. These clients are called “Couchbase Lite.”

A key point is that these aren’t CouchDB clients, like you’d think of with a Postgres or MySQL client library. They are complete databases which you embed into your app. (The “Lite” name was probably chosen to help you compare to SQLite, which is not a SQL client but a complete embeddable SQL database.)

These clients are usable as a local datastore all on their own. But these embeddable databases additionally have the ability to replicate themselves to a remote backend.

For our spike, I set up a Cloudant database. This worked flawlessly with the Couchbase clients, and as a bonus Cloudant has a really slick web admin dashboard that lets you run ad-hoc queries and introspect the database.

Open questions

While our team is feeling good about the Couchbase approach to syncing, many open questions remain.

Multi-tenancy

Naturally each user should only be syncing a copy of their own data.

One approach to this seems to be to do a single database per user, although this creates at least two more problems. One, queries across users become annoyingly difficult. And two, can the backend (Cloudant or a standalone Couchbase install) handle hundreds of thousands or millions of databases that will result from one database per user?

Another approach is a single database but with filtered replication. We got this working in our Cloudant + couchbase-lite-android prototype and were impressed with its simplicity and speed, but we need to do further investigation, especially around enforcing authentication and user partitioning.

User management

Following on from the above, how do you manage and authenticate users? The patterns and practices for this are very well-known when it comes to client-server HTTPS calls. It’s less obvious and well-documented with the CouchDB model. But that ties into the next point:

Backend logic

With a standard backend web app, it’s very clear where the backend logic goes. With the CouchDB model, you’re talking directly to the database. So if you want to do something like, say, send a notification to another user when a certain action happens, where does that code run?

Couchbase’s solution to this is a concept they call Sync gateway, and they have a piece of software you can use. It appears you could also write your own to sit in the same slot. Essentially it’s a proxy to the database that receives replication requests from the client and can decide what to do. Here you can do authentication or other user management, and pass on replication calls to the database when appropriate. We haven’t had a chance to try this out yet so I can’t speak to how well it works, but I like the concept.

Conclusions

Based on our few days of experiments and research, the Clue team and I have the following conclusions:

• Syncing produces a far better-behaved mobile app than client-server. Anyone making a mobile app should favor the former over the latter.
• …but syncing practices and libraries/frameworks are spotty. There aren’t a lot of mature, maintained, well-documented options.
• Trying to write your own syncing is probably a bad idea unless you have a lot of resources and syncing is pretty core to your business. It’s a hard problem that is likely a huge distraction for your technology team.
• The CouchDB multi-master replication offers a good model for mobile syncing that is conceptually similar to how Git works for revision control.
• Couchbase Mobile is a nice stack of technologies that sees to include everything you need to do mobile syncing.

But we have far more questions than answers at this point. We’ll be continuing to explore this area over the coming weeks.

Are you interested in this type of problem? If so we’d love your help. Drop me a line at adam@helloclue.com if you have any thoughts or comments on this article, or if you’re interested in joining our team as a backend engineer. CouchDB enthusiasts & experts particularly welcome.

Mobile syncing with Couchbase was originally published in Wandering CTO on Medium, where people are continuing the conversation by highlighting and responding to this story.

On January 2, 2014, I boarded a one-way flight to Germany.

I’ve never lived outside the US, and my career, professional network, and friends are based in San Francisco. My intention: to connect with startup people in Europe. But what would they say when a stranger showed up out of the blue, asking to join their scene?

What I discovered was a vibrant and thriving community of people and companies, and they welcomed me with open arms. In this article I’ll tell you why I did this, how it’s played out, and what’s next. Let’s start at the beginning.

About me

I’m Adam Wiggins, hacker and serial entrepreneur. You might know me as cofounder and former CTO of Heroku.

I was drawn to entrepreneurship when Orion Henry lured me away from the video game industry in 2000 to start TrustCommerce. I quickly came to love the challenges, passion, and intellectual stimulation of entrepreneurship.

Orion and I started several more ventures together, and along the way we met the third member of our trinity, James Lindenbaum. In 2007, the three of us set out to solve the web app deployment problem. Thus, Heroku was born.

We knew we wanted to go big with Heroku, but we had no idea of the success — or the struggles — that lay ahead. We moved to San Francisco, joined Y Combinator, took VC investment, and went deep in the Ruby community. Six years later and we had seen it grow to a 120-employee company with a quarter-billion dollar exit to one of the world’s fastest-growing public companies. Most satisfyingly, we had become a household name among developers and changed the way that people think about building and running web apps.

In the summer of 2013 I made the extremely difficult decision to leave Heroku. The team there is like a family to me. I’m incredibly proud of everything we did there — and the great work they’ve continued to do since my departure. But my creative muse for that problem space was tapped out, and it wouldn’t have been right for me to stick around longer.

Now, after eight months of R&R, I’m ready to get back into the game.

You win at startups. Now what?

After a successful exit, startup founders often go on to become angel investors, advisors, or EIRs (entrepreneurs-in-residence) at VC firms. This path is appealing because it lets you dabble in a lot of things, satisfying your intellectual curiosity and using your hard-won startup experience to help others succeed. It also avoids the crushingly heavy day-to-day responsibilities of being a founder or senior manager at a growing startup.

I dabbled in investing and advising, but found it unsatisfying. I like to build things, I like to own things. I want to make tough decisions with limited information, weigh risks and take bold action, on a daily basis. I love the intensity and emotional rollercoaster of day-to-day life in a startup.

The spiritual exhaustion that followed the six-year adrenaline high of growing Heroku has not entirely lifted, so I’m not quite ready to make the implicit commitment that would go with founding a new startup. Just as importantly, my lifelong business partners James and Orion are both working on their own projects right now: James on Heavybit, the accelerator for developer-facing product startups; and Orion (assisting his wife Jaymie) on The Right to Heal, a documentary and public health initiative to bring basic essential surgeries to developing nations.

So what can I do to get hands-on with the work I love in the time between now and the next company that James, Orion, and I will start?

Deep-dive advising

The answer has turned out to be a cross between advising (infrequent, high-level assistance to a company paid in pure equity) and consulting (deep, short-term projects, usually paid as an hourly rate). I have started referring to this as “deep-dive advising.”

Here’s how I go about a deep-dive.

I start by talking with founders (or whoever the senior leadership for the company is) to help figure out what some of their biggest challenges are, right now, in their company. Then we identify a project that fits with my skills that I can go deep to help them solve, or at least make a very substantial start on.

For example, my first project is with Clue, a 10-person startup based in Berlin. They’re an app for women to track their menstrual cycles, although this is just the beginning. They have a much grander vision, addressing reproductive health with modern technology products. I’m helping them build technical infrastructure, make some key hires, and address some critical data privacy questions.

Clue first caught my eye because of this line on their Jobs page:

“Make no mistake, we are in a world of pink body parts, but that does not make us love pink and pastels. We are modern, sexy, confident and scientific.”

(You can tell quite a lot about a company’s culture from its jobs page, I’ve discovered.)

I’m scheduled to work with Clue for most of February. It’s a full-time gig, with me in their Kreuzberg office every day at 10am, participating in the standup, attending the company all-hands, and participating in the company chatroom and email. (Email me at adam@helloclue.com if you’ve got a Clue-related question.)

Why Berlin?

I love San Francisco, and it’s a place that has been very, very good to me. And it’s home to many dear friends. But the tech boom there feel like it has hit a saturation point. It’s no longer the frontier.

Like many entrepreneurs, I thrive on novelty, exploration, and discovery. I’m a pioneer and I want to be on the frontier.

For startups, this means seeking new problems, new markets, and new talent pools. So I made a list of criteria for what I was looking for out of a new place and asked about a dozen of my well-traveled friends for their recommendations.

This informal survey turned up the following list: Cape Town, Prague, Krakow, Melbourne, Amsterdam. But the one that floated to the top was Berlin.

Discovering the Berlin startup scene

The uncertainty I felt at flying to a new country to connect with an unfamiliar scene quickly dissipated as I met people here. Starting with a few cold emails to companies I discovered by searching job boards, I managed to get dozens of meetings and attend a great startup event.

I was absolutely floored by how welcoming the startup scene is here in Berlin, and in Europe in general. I’m equally thrilled by the vibrancy: the number of startups, the quantity of smart and ambitious people, and even the quality (if not quantity) of investors.

I was looking for the frontier, the exciting edges where new growth is starting to blossom. I found it in Berlin.

The feeling here in Europe reminds me of San Francisco when I moved there in 2007. It’s hard to even remember this now, but back then, Y Combinator was practically unknown. When my partners and I joined the YC mailing list, the alumni from the previous class (all of about 10 people) excitedly put together a dinner for us. At that dinner the Dropbox founders proudly told the group that they had just closed their first round of funding and made their first hire. How the world has changed since then.

Nowadays there are thousands of YC alumni, not to mention thousands of tech and startup people of all types coming to the city to find their fortune. I think this is wonderful. But for me, I’m happiest in a community that is smaller and more tight-knit.

Bringing Silicon Valley to Europe

I believe in the Silicon Valley / startup approach to problem-solving. I think there are a vast many ways that the human condition can be improved by applying this approach, and that we’ve only just scratched the surface with the startups that exist today.

I’d love to see a diaspora of startup thinking and startup culture spread around the world. That culture is one that believes things can be better; believes that “user experience” is found everywhere; and believes that small teams of dedicated people can make breakthroughs not possible via the established institutions of big companies and governments.

I’m hoping to bring some of whatever Silicon Valley street cred I have to Europe. I’m not the only SF person to come here, but I hope I can help light the path, and maybe change a few minds that the only place startups are possible is in California or the US.

Conclusion

Deep-dive advising in the up-and-coming Berlin startup scene is proving to be very rewarding. I’m looking forward to continuing my adventures here.

Update: Curious how the story ends? Here’s my follow-up post from a few months later.

My journey into the Berlin startup scene was originally published in Wandering CTO on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bonnie Nardi is an anthropologist who studies interactions between humans and computers. In 1993, she published her first book, A Small Matter of Programming. The book's thesis is bold and simple: every human being can, and should, learn to program computers

The book didn’t get much attention outside of academia and is now long out of print. I picked up a secondhand copy in the summer of 2007, just as I was working on the initial prototype of Heroku. The ideas from this book have inspired and haunted me ever since.

Universal literacy

It’s commonly assumed that there is a divide between "geeks," who can program, and "normals," whose use of computers is limited to using software created by the geeks. But is this the case? Let's consider a parallel situation from history: the written word.

A thousand years ago, writing was a technology enjoyed by an elite few: rulers, clerics, scribes. This technology offered the power to store information with more permanence than human memory, to pass such information between people, and to archive it for future generations.

The invention of the printing press in the 1400s made books widely available, and literacy spread. Today, literacy rates exceed 90% in most of the world. Not everyone is a novelist or English professor, but almost everyone can read street signs, write down a grocery list, or send a text message.

Programming as literacy

We increasingly live in a computer-embroidered reality, and the ability to manipulate that reality is empowering. If we can find a way to bring that ability to a wide audience, it could have an impact comparable to the invention of the printing press.

This is end-user computing. “End user” means everyone: people like you, me, your friends and family. We all use computers in our daily lives to accomplish both work and personal goals. When those end users can write and run their own programs, they will have fully harnessed the power of computing.

I'm far from the first to address the topic of programming as literacy; see Programming is the New Literacy and Computer Programming for All: A New Standard of Literacy for two recent examples. But while the renewed interest in this topic is exciting, the methods proposed are often nothing but wishful thinking, and the true challenges of programming literacy are rarely addressed.

A Small Matter of Programming, though two decades old, contains hard research on the real benefits and obstacles to end-user computing. Surprisingly, these findings are just as relevant today as when they were written. Programming-as-literacy enthusiasts should take a close look.

Two gaps

The research presented in the book demonstrates two major gaps that block programming accessibility. These gaps are in the tools, not the teaching process. What we’re missing is 1) no-fuss setup, and 2) task-oriented tools.

Gap 1 – No-fuss setup

Professional software developers favor composable tools that can be combined in a customized stack according to the developer’s taste. Consider the number of tools in a web development environment: language runtime, code editor, revision control system, webserver, database, web framework, dependency management tool, templating language, test harness, and more. The bewildering array of choices often proves defeating to beginners.

The lengthy setup instructions for Ruby on OS X or PHP on Ubuntu illustrate this, each with many pages of error-prone manual steps and incomprehensible jargon. A newbie programmer cannot run even the simplest program without having invested many hours struggling through this setup process.

Even worse, the budding programmer is often pressed to make many choices: what IDE? what language? what database? Experts want choice; newbies want to be handed an integrated product where good choices have been made for them and they can dive straight into their task.

Beginners would be better off with a single integrated tool that they can install (or access on the web) and use to begin programming immediately.

Gap 2 – Task-oriented tools

I recently demonstrated the simplicity of programming to a friend of mine by showing her how to write a short Ruby script. "That's cool," she said. "But what would I use this for?"

Her response demonstrates the second gap in programming accessibility: too much focus on the technology (e.g., programming language) and too little focus on the user’s task.

The first few chapters of nearly any introductory book on programming illustrate this mentality. The focus is on topics like syntax and data types, rather than what meaningful tasks the reader can accomplish with programming.

Most laypeople don't care about computers; they care about what they can use a computer for. They learn how to use a given computing tool so that they can share vacation photos with their family online, write a term paper, or check the value of their stock portfolio.

It follows that most people will only care about computer programming when it offers them a clear way to accomplish specific goals that are relevant to their lives.

The spreadsheet

To date, there has been one pervasive success for end-user computing: the spreadsheet. Spreadsheets fill both of the end-user computing gaps:

No-fuss setup: Install Excel or sign up for Google Docs and you can start your first spreadsheet with a single click. There are no lengthy setup instructions and no decisions to make.

Task-oriented tool: The spreadsheet’s appearance instantly identifies it as a ledger for entering and doing calculations on columns of numbers. A user firing up a spreadsheet for the first time can immediately imagine the tasks they might use this for: totaling line items on a receipt, calculating interest payments on a home mortgage, or tallying up hours worked during a week.

Spreadsheets are specialized on basic accounting. This specialization is reflected deeply in the domain-specific language used to program them. SUM() is usually the first function a spreadsheet user learns. That function performs one of the most common tasks in basic accounting: totaling a column of numbers.

Compare the ease of SUM() to the amount of code needed to total an array of values in a programming language like Java or PHP. In those general-purpose languages, the programmer will need to understand concepts such as loops, arrays, and variables in order to perform this task.

Visual interfaces

Another appeal of spreadsheets is that they are visual: users see their data laid out on a grid. Variables are named for the value's spacial position on the sheet (for example, A1 is the upper-left cell). Code is entered into cells, where it executes as soon as the user leaves the cell. The results of the recalculated spreadsheet are plainly apparent.

Visual interfaces are more discoverable and less intimidating. Bret Victor's fantastic Learnable Programming illustrates how visual elements can improve discoverability and usability while still putting code front and center.

Note that neither spreadsheets, nor Victor’s examples, attempt to hide logic creation behind a point-and-click interface. Purely visual programming is a red herring, and history is littered with the corpses of products that have attempted to offer programming without code.

Other end-user computing successes

While the spreadsheet is the only end-user computing tool to reach the mass market, there have been many successful products in more specialized domains: Industrial designers use scripting to automate AutoCAD; statisticians visualize data with tools like Matlab; and businesspeople build database apps using tools like Filemaker Pro and Microsoft Access.

These tools all share the same two golden traits: no-fuss setup, and a programming language and development tools focused on the specific tasks their users want to achieve.

Codecademy doesn’t focus on the task

Software developers are passionate about their craft and many, like me, would love to see more people gain basic competency with programming. To that end, a number of online learning resources have appeared in the last few years: learn-by-doing apps like Codecademy and Code School, courses from Khan Academy, and tutorials for kids like Hackety Hack.

But while these efforts are well-executed and well-meaning, I question whether they put us on a path toward broad programming literacy. Learning to program for its own sake, rather than focused on a task the student wants to achieve, suffers from the problem of attracting only people who are already interested in programming.

Codecademy courses are named for technologies like Javascript and Python, instead of tasks students might be interested in, like creating a website or a game. Khan Academy's courses are named for a task – digital drawing and animation – but it may be unclear to the average person why one would learn to program for this, when a non-programming tool like Photoshop does the job just as well.

A different way to learn

An alternative to the Codecademy-style approach is tools focused on programming with a particular task in mind. For example:

Many teenagers spend a huge amount of time on Facebook. How about a way for teens to build their own Facebook apps, where the program lets you traverse your social graph with just a few lines of code? Just as spreadsheets offer SUM(), a social programming tool could give you functions like my_friends() and my_photos().

Home automation is easier than ever with devices like the WeMo. How about a product that allows homeowners to attach scripts to household devices? Parents could write scripts to control their kids' access to the TV, adjust the thermostat, or the feed the pets via an automated food dispenser.

I learned to program because I loved video games as a kid and wanted to make my own. How about a toolkit for kids to make games for their iPad or Xbox that allows them to easily share the games they’ve created with their friends?

In each of these examples, the tools must be incredibly simple to set up. If at any point the user needs to download and install Python, choose a text editor, or configure a database, then the jig is up before it has even begun.

Conclusion

Broad programming literacy is crucial in a world increasingly made of computers. If we can make programming a part of the end user’s computing experience, it has the potential for impact on par with the invention of the printing press.

Despite common stereotypes, programming is not out of reach for the average person. If the tools are easy to set up and specialized on the programmer’s task, programming can be a small matter after all.

Thanks to Sarah Day, Wade Roush, and Mark McGranaghan for help with this post.

End-user computing was originally published in The Truant Haruspex on Medium, where people are continuing the conversation by highlighting and responding to this story.