Henri Bergius - Tablet

Atreus: Building a custom ergonomic keyboard

henri.bergius@iki.fi (Henri Bergius) — Thu, 20 Apr 2017 00:00:00 +0000

As mentioned in my Working on Android post, I’ve been using a mechanical keyboard for a couple of years now. Now that I work on Flowhub from home, it was a good time to re-evaluate the whole work setup. As far as regular keyboards go, the MiniLa was nice, but I wanted something more compact and ergonomic.

The Atreus keyboard

Atreus is a 40% ergonomic mechanical keyboard designed by Phil Hagelberg. It is an open hardware design, but he also sells kits for easier construction. From the kit introduction:

The Atreus is a small mechanical keyboard that is based around the shape of the human hand. It combines the comfort of a split ergonomic keyboard with the crisp key action of mechanical switches, all while fitting into a tiny profile.

My use case was also quite travel-oriented. I wanted a small keyboard that would enable me to work with it also on the road. There are many other small-ish DIY keyboard designs like Planck and Gherkin available, but Atreus had the advantage of better ergonomics. I really liked the design of the Ergodox keyboard, and Atreus essentially is that made mobile:

I found the split halves and relatively large size (which are fantastic for stationary use at a desk) make me reluctant to use it on the lap, at a coffee shop, or on the couch, so that’s the primary use case I’ve targeted with the Atreus. It still has most of the other characteristics that make the Ergodox stand out, like mechanical Cherry switches, staggered columns instead of rows, heavy usage of the thumbs, and a hackable microcontroller with flexible firmware, but it’s dramatically smaller and lighter

I had the opportunity to try a kit-built Atreus in the Berlin Mechanical Keyboard meetup, and it felt nice. It was time to start the project.

Sourcing the parts

When building an Atreus the first decision is whether to go with the kit or hand-wire it yourself. Building from a kit is certainly easier, but since I’m a member of a hackerspace, doing a hand-wired build seemed like the way to go.

To build a custom keyboard, you need:

Switches: in my case 37 Cherry MX blues and 5 Cherry MX blacks
Diodes: one 1N4148 per switch
Microcontroller: a Arduino Pro Micro on my keyboard
Keycaps: started with recycled ones and later upgraded to DSA blanks
Case: got a set of laset-cut steel plates

Even though Cherry — the maker of the most common mechanical key switches — is a German company, it is quite difficult to get switches in retail here. Luckily a fellow hackerspace member had just dismantled some old mechanical keyboards, and so I was able to get the switches I needed via barter.

The Cherry MX blues are tactile clicky switches that feel super-nice to type on, but are quite loud. For modifiers I went with Cherry MX blacks that are linear. This way there is quite a clear difference in feel between keys you typically hold down compared to the ones you just press.

The diodes and the microcontroller I ordered from Amazon for about 20€ total.

At first I used a set of old keycaps that I got with the switches, but once the keyboard was up and running I upgraded to a very nice set of blank DSA-profile keycaps that I ordered from AliExpress for 30€. That set came with enough keycaps that I’ll have myself covered if I ever build a second Atreus.

All put together, I think the parts ended up costing me around 100€ total.

Preparations

When I received all the parts, there were some preparation steps to be made. Since the key switches were 2nd hand, I had to start by dismantling them and removing old diodes that had been left inside some of them.

The keycaps I had gotten with the switches were super grimy, and so I ended up sending them to the washing machine. After that you could see that they were not new, but at least they were clean.

With the steel mounting plate there had been a slight misunderstading, and the plates I received were a few millimeters thicker than needed, so the switches wouldn’t “click” in place. While this could’ve been worked around with hot glue, we ended up filing the mounting holes down to the right thickness.

Wiring the keyboard

Once the mounting plate was in the right shape, I clicked the switches in and it was time to solder.

Hand-wiring keyboards is not that tricky. You have to attach a diode to each keyswitch, and then connect each row together via the diodes.

The two thumb keys are wired to be on the same column, but different rows.

Then each column is connected together via the other pin on the switches.

This is how the matrix looks like:

After these are done, connect a wire from each column, and each row to a I/O pin on the microcontroller.

If you haven’t done it earlier, this is a good stage to test all connections with a multimeter!

Firmware

After finishing the wiring, I downloaded the QMK firmware, changed the PIN mapping for how my Atreus is wired up, switched the layout to Colemak, and the keyboard was ready to go.

Don’t mind the key labels in the picture above. These are the second-hand keycaps I started with. Since then I’ve switched to blank ones.

USB-C

The default Atreus design has the USB cable connected directly to the microcontroller, meaning that you’ll have to open the case to change the cable. To mitigate that I wanted to add a USB breakout board to the project, and this being 2017, it felt right to go with USB-C.

I found some cheap USB-C breakout boards from AliExpress. Once they arrived, it was time to figure out how the spec works. Since USB-C is quite new, there are very few resources available on how to use it with microcontrollers. These tutorials were quite helpful:

Here is how we ended up wiring the breakout board. After these you only have four wires to connect to the microcontroller: ground, power, and the positive and negative data pins.

This Atreus build log was useful for figuring out where to connect the USB wires on the Pro Micro. Once all was done, I had a custom, USB-C keyboard!

Next steps

Now I have the Atreus working nicely on my new standing desk. Learning Colemak is a bit painful, but the keyboard itself feels super nice!

However, I’d still like to CNC mill a proper wooden case for the keyboard. I may update this post once that happens.

I’m also considering to order an Atreus kit so I’d have a second, always packed for travel keyboard. The kit comes with a PCB, which might work better at airport security checks than the hand-wired build.

Another thing that is quite tempting is to make a custom firmware with MicroFlo. I have no complaints on how QMK works, but it’d be super-cool to use our visual programming tool to tweak the keyboard live.

Big thanks to Technomancy for the Atreus design, and to XenGi for all the help during the build!

Working on an Android tablet, 2017 edition

henri.bergius@iki.fi (Henri Bergius) — Fri, 10 Feb 2017 00:00:00 +0000

Back in 2013 I was working exclusively on an Android tablet. Then with the NoFlo Kickstarter I needed a device with a desktop browser. What followed were brief periods working on a Chromebook, on a 12” MacBook, and even an iPad Pro.

But from April 2016 onwards I’ve been again working with an Android device. Some people have asked me about my setup, and so here is an update.

Why work on a tablet?

When I started on this path in 2013, using a tablet for “real work” was considered crazy. While every story on tablet productivity still brings out the people claiming it is not a real computer for real work, using tablets for real work is becoming more and more common.

A big contributor to this has been the plethora of work-oriented tablets and convertibles released since then. Microsoft’s popular Surface Pro line brought the PC to tablet form factor, and Apple’s iPad Pro devices gave the iPad a keyboard.

Here are couple of great posts talking about how it feels to work on an iPad:

With all the activity going on, one could claim using a tablet for work has been normalized. But why work on a tablet instead of a “real computer”? Here are some reasons, at least for me:

Free of legacy cruft

Desktop operating systems have become clunky. Window management. File management. Multiple ways to discover, install, and uninstall applications. Broken notification mechanisms.

With a tablet you can bypass pretty much all of that, and jump into a simpler, cleaner interface designed for the modern connected world.

I think this is also the reason driving some developers back to Linux and tiling window managers — cutting manual tweaking and staying focused.

Amazing endurance

Admittedly, laptop battery life has increased a lot since 2013. But with some manufacturers using this an excuse to ship thinner devices, tablets still win the endurance game.

With my current work tablet, I’m customarily getting 12 or more hours of usage. This means I can power through the typical long days of a startup founder without having to plug in. And when traveling, I really don’t have to care where power sockets are located on trains, airplanes, and conference centers.

Low power usage also means that I can really get a lot of more runtime by utilizing the mobile battery pack I originally bought to use with my phone. While I’ve never actually had to try this, back-of-the-envelope math claims I should be able to get a full workweek from the combo without plugging in.

Work and play

The other aspect of using a tablet is that it becomes a very nice content consumption device after I’m done working. Simply disconnect the keyboard and lean back, and the same device you used for writing software becomes a great e-reader, video player, or a gaming machine.

This combined with the battery life has meant that I’ve actually stopped carrying a Kindle with me. While an e-ink screen is still nicer to read, not needing an extra device has its benefits, especially for a frequent one-bag traveller.

The setup

I’m writing this on a Pixel C, a 10.2” Android tablet made by Google. I got the device last spring when there were developer discounts available at ramp-up to the Android 7 release, and have been using it full-time since.

Software

Surprisingly little has changed in my software use since 2013 — I still spend the most of the time writing software in either Flowhub or terminal. Here are the apps I use on daily basis:

JuiceSSH for mosh access to my remote development servers
Termux for local and offline development
Flowhub for visual programming
The Grid for updating my various websites
Slack, Hangouts, and Inbox by Gmail for communications
Google Drive and the associated applications for budgeting and planning
Chrome for web

Looking back to the situation in early 2013, the biggest change is that Slack has pretty much killed work email.

Termux is a new app that has done a lot to improve the local development situation. By starting the app you get a very nice Linux chroot environment where a lot of software is only a quick apt install away.

Since much of my non-Flowhub work is done in tmux and vim, I get the exactly same working environment on both local chroot and cloud machines by simply installing my dotfiles on each of them.

Keyboard

When I’m on the road I’m using the Pixel C keyboard. This doubles as a screen protector, and provides a reasonable laptop-like typing environment. It attaches to the tablet with very strong magnets and allows a good amount of flexibility on the screen angles.

However, when stationary, no laptop keyboard compares to a real mechanical keyboard. When I’m in the office I use a Filco MiniLa Air, a bluetooth keyboard with quiet-ish Cherry MX brown switches.

This tenkeyless (60%) keyboard is extremely comfortable to type on. However, the sturdy metal case means that it is a little too big and heavy to carry on a daily basis.

In practice I’ve only taken the mechanical keyboard with me when there has been a longer trip where I know that I’ll be doing a lot of typing. To solve this, I’m actually looking to build a more compact custom mechanical keyboard so I could always have it with me. (Update: here is the keyboard I built).

Comparison with iOS

So, why work on Android instead of getting an iPad Pro? I’ve actually worked on both, and here are my reasons:

Communications between apps: while iOS has extensions now, the ability to send data from an app to another is still a hit-or-miss. Android had intents from day one, meaning pretty much any app can talk to any other app
Standard charging: all of my other devices charge with the same USB-C chargers and cables. iPads still use the proprietary Lightnight plug, requiring custom dongles for everything
Standard accessories: this boils down to USB-C just like charging. With Android I can plug in a network adapter or even a mouse, and it’ll just work
Ecosystem lock-in: we’re moving to a world where everything — from household electronics to cars — is either locked to the Apple ecosystem or following standards. I don’t want to be locked to a single vendor for everything digital
Browser choice: with iOS you only get one web renderer, the rather dated Safari. On Android I can choose between Chrome, Firefox, or any other browser that has been ported to the platform

Of course, iOS has its own benefits. Apple has a stronger stance on privacy than Google. And there is more well-made tablet software available for iPads than Android. But when almost everything I use is available on the web, this doesn’t matter that much.

The future

As a software developer working on Android tablets, the weakest point of the platform is still that there are no browser developer tools available. This was a problem in 2013, and it is still a problem now.

From my conversations with some Chrome developers, it seems Google has very little interest in addressing this. However, there is a bright spot: the new breed of convertible Chromebooks being released now. And they run Android apps:

Chrome OS is another clean, legacy free, modern computing interface. With these new devices you get the combination of a full desktop browser and the ability to run all Android tablet software.

The Samsung Chromebook Pro/Plus mentioned above is definitely interesting. A high-res 12” screen and a digital pen which I see as something very promising for visual programming purposes.

However, given that I already have a great mechanical keyboard, I’d love a device that shipped without an attached keyboard. We’ll see what kind of devices get out later this year.

Flowhub public beta: a better interface for Flow-Based Programming

henri.bergius@iki.fi (Henri Bergius) — Wed, 07 May 2014 00:00:00 +0000

Today I’m happy to announce the public beta of the Flowhub interface for Flow-Based Programming. This is the latest step in the adventure that started with some UI sketching early last year, went through our successful Kickstarter — and now — thanks to our 1 205 backers, it is available to the public.

Getting Started

This post will go into more detail on how the new Flowhub interface works in a bit, but for those who want to dive straight in, here are the relevant links:

Make sure to read the Getting Started guides and check out the Flowhub FAQ. There is also a new video available:

Both the web version and the Chrome app are built following the offline first philosophy, and keep everything you need stored locally inside your browser. The Chrome app and the upcoming iOS and Android builds will enable us to later introduce capabilities that are not possible inside regular browsers, like talking directly to MicroFlo runtimes over USB or Bluetooth. But other than that they’re similar in features and user experience.

New User Interface

If you read the NoFlo Update from last October, you might notice that the new Flowhub user interface looks and feels quite different from it.

This new design was implemented to improve touch-screen friendliness, as well as to give Flowhub a more focused, unique look. It also allowed us to follow some interesting UX paths that I’ll explain next.

Zooming

One typical problem in visual programming tools is that they can become quite cluttered with information. To solve this, we utilized the concept of Zooming User Interfaces, which allow us to show a clear overview of a program when zoomed out, and reveal all kinds of detail about it when zoomed in.

Zooming works with two-finger scroll on typical desktop computers, or with the pinch gesture on touch-enabled devices.

Another interface concept that we used to make interactions faster and more contextual is Pie Menus.

For example, you can easily navigate to subgraphs and component source code with the menu:

When you have selected multiple nodes, you can use the menu to group them or move them to a new subgraph:

The menu can also be used for removing edges or nodes:

You can activate the pie menu in the graph editor with a right mouse click, or with a long press on touch-enabled devices.

Component Editor

Another new major feature is in-app component editing. If your runtime supports it, you can at any time create or modify custom components for your project and they’ll become immediately available for your graphs.

The programming languages available for component creation depend on the runtime. With NoFlo these are JavaScript and CoffeeScript. With another runtime they might be C, Java, or Python.

Offline First

While some claim that in reality you’re never offline, the reality is that there are many situations where Internet connectivity is either not available, unreliable, or simply expensive. Think of a typical conference or a hackathon for instance.

Because of this — and to give software developers the privacy they deserve — Flowhub has been designed to work “offline first”. All your graphs, projects, and custom components are stored locally in your browser’s Indexed Database and only transmitted over the network when you wish to push to a GitHub project, or interact with a remote runtime.

We’re following a very similar UI concept as Amazon Kindle in that you can download projects locally to your device, or browse the ones you have available in the cloud:

At any point you can push your changes to a graph or a component to GitHub:

Runtime discovery happens through a central service, but once you know the address of your FBP runtime, the communications between it and your browser will happen directly. This makes it easy to work with Node.js projects running on your own machine even when offline.

Cross-platform, Full-stack

When we launched the NoFlo UI Kickstarter, we were initially only thinking about how to support NoFlo in different environments. But in the course of development we ended up defining a network protocol for FBP that enabled us to move past just a single FBP environment and towards supporting all of them. This is what prompted the Flowhub rebranding.

Since then, the number of supported FBP environments has been growing. Here is a list of the ones I’m aware of:

NoFlo
- browsers
- Node.js
- GNOME desktop
MicroFlo
- microcontrollers
ImgFlo
- image processing with GEGL
ProtoFlo
- Python

I hope that the developers of other FBP environments like JavaFBP and GoFlow add support for the FBP protocol soon so that they can also utilize the Flowhub interface.

Open Source vs. Paid

As promised in our Kickstarter, the NoFlo Development Environment is an open source project available under the MIT license.

Flowhub is a branded and supported instance of that with some additional network services like the Runtime Registry.

The Flowhub plans allow us to continue development of this Flow-Based Programming toolset, as well as to provide the various network services needed for making the experience smooth.

Just like with GitHub, Flowhub provides a free environment for anybody working on public and open source projects. Private projects need a paid plan.

Kickstarter & Pre-Ordered Plans

It is likely that many readers of this post already supported our Kickstarter or pre-ordered a Flowhub plan. Since Flowhub is still in beta, we haven’t activated your plans yet. So for now, everybody is using Flowhub with the free plan.

We will be rolling out the paid plans and Kickstarter rewards towards the end of the beta testing period.

Feel free to already log in and start using Flowhub, however! The plan will be added to your account when we feel the software is ready for it.

Examples

Here are some examples of things you can build with Flowhub targeting web browsers:

For a more comprehensive cross-platform project, see my Building an Ingress Table with Flowhub post.

There is also an ongoing Google Summer of Code project to port various Meemoo apps to Flowhub. This will hopefully result in a lot more demos.

Next Steps

The main purpose of this public beta is to allow our backers and other FBP enthusiasts an early access to the Flowhub user interface. Now we will focus on stabilization and bug fixing, aided by the NoFlo UI issue tracker. We’re also gathering feedback from beta testers in form of user surveys and will utilize those to prioritize both bug fixing and feature work.

Right now the main areas of focus are:

Improving the GitHub integration
Landing the graph autolayout feature
Compatibility with upcoming Chrome 35 and its native HTML5 Custom Elements support
Implementing real-time collaboration over WebRTC

We hope to release the stable version of Flowhub in summer 2014.

Software is not text

henri.bergius@iki.fi (Henri Bergius) — Sun, 11 Aug 2013 00:00:00 +0000

It has been interesting to watch the reactions to Bret Victor’s The Future of Programming and our NoFlo Kickstarter. While much of it has been supportive, there seems to be a largish group of people that are offended by these notions. How dare we suggest that software could be made in other ways than textually?

This is somewhat understandable. We all feel pride in being able to master the arcane skills our daily work needs. Even commanding a text editor like Vim can be daunting to a beginner, and yet we do it effortlessly! But therein lies the danger, as Bret Victor explains:

The most dangerous thought that you can have as a creative person is to think that you know what you’re doing. Because once you think you know what you’re doing you stop looking around for other ways of doing things. You stop being able to see other ways of doing things. You become blind.

Now, software development has been happening textually for quite a while — ever since Fortran came about. Some even see programming evolving into a form of literature. Nothing wrong with that!

Input is the problem

But at the same time, why not explore other avenues of building software? Visual programming has been around nearly as long as the textual variant, but has always stayed outside of the mainstream. There are many reasons for this, but I believe the primary one has been the lack of suitable input devices.

Until quite recently, the keyboard was the only efficient way of communicating with a computer.

But interestingly, while computer keyboards have become worse, the other input tools have improved. Graphics tablets, touchpads, and touchscreens are all way better and more ubiquitous now than ever before. As I’ve argued before this may eventually make our culture less textual.

Until now, text has been the dominant way of handling business communications. Touchscreens are bad for writing, and so the professions that have most benefitied from them have been from outside the traditional business domain: musicians, photographers, and many others can already do some things better on a tablet than they could on a traditional computer.

With tablets and smartphones becoming ubiquitous, it might not be far-fetched to imagine the business culture to change as well. Consider:

Video conferencing instead of email

Not being bound to a desk. Maybe offices will look more like lounges?

Large, zoomable visualizations of business data instead of rigid report generators

Bringing software and connectivity to areas outside of traditional office work

Replacing dedicated hardware for measurements, analysis, etc

Why should programming stand apart?

Building software by touch

One big benefit of flow-based programming is that the flow graph definitions are quite nicely disconnected from the way they’re produced. You can write them “as code”, or you can draw them in an editor. The system doesn’t care. A graph is a graph.

To give the necessary car analogy: When you power a car with electricity, you suddenly have many more options for generating that power… Solar, wind, or even just burning hydrocarbons. Similarly, when you decouple the logic — the flow of your software — from text you will have new ways to build and visualise it.

Writing software textually is to work on a 1D medium. The visual representation given by NoFlo UI allows us to interact better with the software with the 2D input tools we have now, like touch screens and mice.

Building software by speaking

But it would be easy to imagine other input types as well. Given that the problem domain of building graphs is quite nicely constrained, it is an area where speech input could actually work. Think of speaking to your computer and telling it to:

add node with component Foo
connect node Foo with node Bar

This might be something interesting to experiment with using the web-based NoFlo UI and the speech recognition API in Google Chrome!

Building software by gestures

I recently ran into the concept videos by Meta, a company building augmented reality glasses that include a Kinect-like gesture sensor.

While the current technology won’t be able to bring hard AR into reality, something like these glasses could be awesome when collaborating on software design with a group of people. Imagine seeing the graph floating in space in the middle of the room, and to be able to collaboratively pick up and move things around!

Letting all this merge

In the end, I think we will end up using some combination of various of these together. Sometimes we’ll want to have a desk and a keyboard to dive in and write some tests or new components. But sitting at a desk the whole day is also bad for you, and so sometimes it may be nice to move around and do development on your tablet. Or even dictate changes to the graph while sitting in a car?

By moving the logic into a graph, we can let software free.

NoFlo Kickstarter, the hacker's perspective

henri.bergius@iki.fi (Henri Bergius) — Thu, 01 Aug 2013 00:00:00 +0000

This has been a big week for NoFlo, the flow-based programming environment for JavaScript. Yesterday we released NoFlo 0.4, which added support for running flow-based programs in web browsers. And today we launched our NoFlo Development Environment effort on Kickstarter. Before continuing, make sure to watch the video!

This is our effort to bring visual and collaborative flow-based tools into the world of mainstream software development. Similar tools are already in use in many specialized industries from movie special effects to hardware simulation, but we programmers still have to construct these complex maps of our software’s control flow inside our brains based on their textual representation. With your support, we could change that!

We’ve already reached a third of our goal on the first day. Clearly people see the need for these tools. Exciting times!

The stories from TechCrunch and GigaOm tell the story well for non-programmers. But based on the questions I’ve received today, I thought it would be good to clarify various points from a more programmer-centric point of view.

Hasn’t visual programming been tried before?

The story of visual programming tools started with the GRaIL system of the 60s, and has progressed to tools like LabView and Pure Data. So far none of these tools has reached mainstream acceptance outside of their (sometimes fanatic) industry niches.

This is partly because these tools were built originally with a particular problem domain in mind, and partly because of the user experience. Execution matters, as we’ve seen so many times in the tech industry. After all, there were tablets a lot before the iPads.

With our team I have the confidence that we have the necessary skills and vision to build something that is actually a pleasure to use, and that makes it truly easier to work with the control flow of your software than it is with the text editors.

This is not a rehash of UML. UML is a diagram mapping out object-oriented constructs, often used for code generation. NoFlo graphs instead are only the coordination layer that manages the control flow of your software. The components are still handcrafted and unit-tested code that NoFlo merely wires together at runtime, following the edges specified in a JSON file. No code generation here.

Why map out the control flow?

All software is inherently a graph. Functions call other functions, sending data along. Signals are emitted and connections are made. But outside of some debugging tools we rarely see this in a visual format. Instead, when starting to work on a program you have to parse the code and build this map in your head.

This imposes a lot of cognitive load that tools like NoFlo could avoid. When you can see visually how things are connected, you can focus on the bigger picture and build the software you need in a more efficient way. This is what Bret Victor talked about recently.

What is the role for code, then?

However, there still remains a role for text-based code. The actual components, the boxes in the graph, are still written out in JavaScript. But since they’re isolated from their surroundings until a NoFlo graph wires them together, each component can focus on accomplishing a single task well.

My original NoFlo UI prototype already included the code editor for modifying and creating new components. By the principles of TDD, each component is always edited alongside its unit tests, and the tests can be run at any point with a single click. We’re now bringing that back into the new UI:

For those who don’t want this UI, NoFlo is still fully usable also without it. As a matter of fact, we don’t have a UI before the Kickstarter succeeds, and yet many companies are already building their applications with NoFlo. One way is by using the .fbp language.

Why now?

Another reason why the NoFlo development environment may succeed where many others failed is that programming has changed.

We no longer target a single protocol — whether the Win32 API or HTTP — in our applications. Instead, we need to talk multiple protocols and with multiple devices at the same time. Even just dealing with both REST and WebSockets is difficult to many traditional programming environments.

The other big change is the usage of different web APIs as part of your applications. Authentication, handling asynchronous requests and services that are sometimes down can be a pain.

NoFlo brings a controlling layer to your software that allows you to map out these scenarios and isolate the handling of each protocol or API into its own set of small, simple components.

Where could this be used?

Many of the nodal editing tools built in the past have been very domain-specific. However, flow-based programming is a general software development paradigm. NoFlo has already been used for a wide variety of tasks, including:

Business data extraction and reporting
Automating billing workflows
Receiving, routing, and sending text messages
Static site generation
Building server-side web applications

Now that we added browser support it will be possible to also build physics-based user interfaces with NoFlo. There should be some interesting examples of that coming up soon.

NoFlo being a general JavaScript library could in future enable us to coordinate the flows also in new kinds of places like desktop applications. There are several desktop environments where JavaScript is a first-class citizen. Combining flow-based interactions with declarative UI definitions could be something very powerful!

Many of the giants of the software industry, like Google, Facebook, Microsoft, Adobe, and Mozilla are all working on improving the JavaScript development tools. It would be awesome to have their support for what we’re doing.

How about open source?

If you’re following this blog, you probably know that I feel strongly for software freedom. Everything I’ve done during my professional career has been possible only thanks to the open source community.

NoFlo and the UI we’re building are and will remain open source available under the MIT license. As a matter of fact, the UI is designed to not only work with NoFlo, but also to be adaptable to work with other flow-based systems. I feel this is an area with a lot of potential for collaboration with the various functional and dataflow projects out there.

We will however be offering a hosted version of the software for a fee. The various Kickstarter rewards will give our backers an early and cheaper access to that.

But still, you’ll always be able to run the whole stack on your own infrastructure if you choose to do so.

What happens next?

Our Kickstarter campaign has been up for less than a day, and we’re already above 30% of our goal. This makes me quite optimistic for the effort. But of course we won’t succeed without the help of the wider open source and JavaScript community!

There are still quite a lot of days left in the campaign. Tonight I’ll be flying back to Europe, and then we’ll focus on the next steps.

One important area of attention is publishing more demos and examples of NoFlo in real-world use. I hope by early next week we’ll be able to show a few applications running on both browser and Node.js. I will also publish our flow-based port of the Jekyll static site generator. These should help people getting started with this style of programming.

We also have quite a lot of content lined up and waiting for editing. Something of interest to everybody working with flow-based or functional programming will be the long cut of the interview we made with J. Paul Morrison, the father of FBP. My hope is that video will be live by the end of the next week.

If you’re interested in the developments, make sure to follow NoFlo on Twitter, Facebook, or Google+. If you back our campaign, you’ll also receive the updates via Kickstarter.

Thanks everybody for helping to make this possible! Keep spreading the world and giving your support!

Leap Motion and the virtual interfaces

henri.bergius@iki.fi (Henri Bergius) — Sat, 27 Jul 2013 00:00:00 +0000

The eagerly waited Leap Motion controller is now out, and reviews are pouring in. Most of them see the promise but find the current experience frustrating:

Here’s the thing: the Leap Motion is almost amazing. When using it to interact with my desktop and perform actions (clicking, dragging, scrolling), the experience is about 50 percent fluid intuition and 50 percent screaming frustration. There are moments, sometimes ten or fifteen seconds long, when everything magically clicks into place—the Leap doesn’t decide your hand is too far away or too close to be able to execute actions, and for a few seconds, boom, you’re scrolling, dragging, and clicking effortlessly. It feels totally natural. Then, almost capriciously, your gestures aren’t good enough any more and you spend ten more seconds trying to get a single click to register.

I’ve had a Leap sensor as part of their developer program for a while now, and the description above feels quite accurate to both the Leap, and our Kinect air cursor work.

Lacking interface concepts

The problem is that our current interface concepts are simply not suitable for this sort of interaction. There must be incredible things you can accomplish when the computer can see your fingers or whole body in motion. We just haven’t discovered them yet.

This is very similar to the situation we had for a long time with touchscreen devices. There have been tablets available since the 90s, but they didn’t take off until there was a new kind of OS and new kind of UI guidelines for this world. After all, your finger is not a mouse.

Once those guidelines were out there, and manufacturers built compelling enough all-touch devices, the market took off. I’ve said for a long time that the tablet form factor is winning, an estimate validated by the recent sales figures. And yet, the new kind of tablets have only been available since 2006 or 2010 depending how you look. The big shift is only getting started.

Right now tablets are still mostly used for recreation and light data processing, as productivity applications and culture always take a bit longer to adapt. We need to move beyond text as the main way of communicating ideas.

I’ve already taken a few steps that way for us programmers.

Behind the glass

While there are many great user interfaces built on the touch paradigm, interacting with a featureless piece of glass lacks a lot of the haptic feedback we get from physical interfaces. The author Douglas Adams commented on this in The Hitchhiker’s Guide to the Galaxyalready back in 1979:

A loud clatter of gunk music flooded through the Heart of Gold cabin as Zaphod searched the sub-etha radio wave bands for news of himself. The machine was rather difficult to operate. For years radios had been operated by means of pressing buttons and turning dials; then as the technology became more sophisticated the controls were made touch-sensitive–you merely had to brush the panels with your fingers; now all you had to do was wave your hand in the general direction of the components and hope. It saved a lot of muscular expenditure, of course, but meant that you had to sit infuriatingly still if you wanted to keep listening to the same program.

Zaphod waved a hand and the channel switched again.

(thanks to Ars commenter Joannemullen, I had forgotten about that quote!)

The book Invisible Computer argues for building physical appliances for different computing purposes. I don’t see that happening anytime soon given the strong onward march of ephemeralization, of moving everything to converged devices and increasingly capable software.

But even with software there would be so much more we could be doing.

Physical interaction

The devices we carry around us are filled with different sensors which could provide new kinds of interaction concepts.

For example, on many Nokia phones you’ve been able to mute the phone by flipping it around. In 2001 I had an Ericsson phone which used the proximity sensor to snooze the alarm when you waved your hand over the phone.

iOS devices use the gesture of shaking the device to shuffle a playlist or undo an action. On many Android devices you can use NFC touches to move data or interaction between devices. Touch a screen to send a picture there, or touch a speaker to make your music play from there.

These are all great, natural gestures that allow us to interact with the device in a physical way, not with just with the virtual interfaces behind the glass.

Gestures like these should be more universally available, just like touch UI concepts like pull to refresh. When people trust a gesture to work consistently everywhere, it will be used a lot more, and users will be happier.

We are after all interating with physical devices we can not only touch, but also move around.

Working on an Android tablet: first six weeks

henri.bergius@iki.fi (Henri Bergius) — Tue, 16 Apr 2013 00:00:00 +0000

I’ve been working full time on my Android workstation for over a month now, and it is time to write an update about it. How has it worked out?

What I’ve been doing

I would love to tell stories of working from parks and cafes, like Mark O’Connor has on his iPad setup, but unfortunately we had a backlash of winter here in Berlin and the warm spring weather only came back this week.

Instead — quite atypically — I’ve been mostly desk-bound in this time. The EU projects that mandated a lot of travel have now ended, and my current projects are more about software development than evangelism.

But that actually makes this experiment even more useful, as it means most of the six week has been actual programming, which is what most of my readers also do.

For those who missed my setup in the previous post, this is how it looks in action:

On-screen are tmux, vim, and a Grunt test automation watcher running inside a MOSH client.

Here are some things I’ve done in the last month:

Porting the NoFlo flow-based programming engine to run in both browser and Node.js with the same codebase, including a tutorial on how others can do the same
Writing and publishing an implementation of Android-style Action Bars for web apps
Adding multiple major features to the web-based NoFlo IDE
Dealing with the issues raised with the release of jQuery UI 1.10 and Backbone 1.0.0 with Create.js and VIE
Blogging, including publishing some quite popular posts

In general the experience has been a positive and productive one. I’ll write about some nuances here.

Web debugging

As you can see from the list above, much of my recent work has been client-side. With this, the unavailability of web debuggers on mobile browsers can become a problem.

I’ve tackled this issue in two ways:

More tests. Instead of poking around in a debugger, I try to write Mocha tests for most aspects of my applications. This also has the benefit of automation, meaning that PhantomJS will test everything in my application every time I commit
VNC and desktop browsers. When I really need one, I can still use the web debugging tools of traditional web browsers via VNC

See Mark O’Connor’s setup instructions for VNC on one of these tablet workstation setups.

Post-PC means post-Office

One area where tablets are really lacking is support for traditional office tools like word processors and spreadsheets. There is a Google Drive client, but it is very slow (even small spreadsheets can take minutes to load) and mostly non-functional (word processor doesn’t even support headlines).

There are also some other office suites available, but even these are better used for viewing documents than actually making changes to them.

But the bigger question is whether traditional office tools even have a place in this modern world. The commentary on constant delays with Microsoft Office for iOS and Android shows that people don’t see them as that relevant any longer:

For the longest time, Office was the ubiquitous productivity suite. Everybody used it. Nobody considered using anything else. However, since this mobile revolution started, even non-geeks are starting to question whether Office is still all that. I had breakfast this morning with a CPA who does all of his work in Google docs. There is an entire generation of future workers going through high school and college now who don’t even have Office installed on their computers. If Microsoft has any hopes of keeping Office relevant, it needs to be everywhere, including the iPad.

Personally, I might be a lot better off writing my documents in Markdown, versioning them with git, and maybe using custom data-gathering applications with CouchDB map-reduces for data visualization.

The story of tablet productivity is still evolving. The new tools and interaction techniques we have will eventually give rise to new kinds of productivity applications. That may signal the end of the Office hegemony.

Presenting from the tablet

On the first week of this experiment I was actually traveling. The final review meetings for both of the EU projects were being held in Brussels and Luxembourg, and I had to present our results.

As the presentation tools on Android are not very good, I took this as an opportunity to finally start using an HTML-based presentation system. For this, I picked DZSlides, with a custom Jekyll-based flow for constructing slide decks from individual assets stored in git.

The results are quite nice, and I love being able to embed live demos inside the slides.

With every computing platform, there is always some fiddling involved with getting your device connected to a beamer. I was positively surprised with how easily the Nexus 10 worked. Simply connect using a micro-HDMI to VGA adapter, and you’ll have the tablet screen up on the projector.

Minor annoyances

Everybody knows about the common gripes with Android on large tablets — most apps have been written with a narrow phone screen in mind, and simply look bad on a wide 10” screen. Twitter is a good example of the typical neglect of Android’s UI guidelines.

Somewhat surprisingly, this even applies to Google’s own tablet applications. Apps like Google+ and Google Drive are a lot more functional on an iPad than on a large Android tablet.

However, these are more of a problem when using something like my Nexus 10 as a media tablet, and don’t really affect how well it works as a programming workstation.

For programming work, what matters is things like the beautiful screen, Android’s reasonably good support for hardware keyboards, user-accessible file system, and the ability to share information between applications. These are the main reasons why I went with Android instead of an iPad.

However, not all is sunshine. So far, the main annoyances for me have been:

Regressions in Magic Trackpad support mean that it is practically unusable when you also have a Bluetooth keyboard. A lot of character presses get duplicated, making typing near-impossible. I’m assuming other mouse devices would however work
MOSH ConnectBot — which I’m using for my programming sessions — makes Ctrl and Esc keys not work. Luckily I was able to find a workaround
Android 4.2.2 is buggy on the Nexus 10. Especially Chrome can cause the system to crash. Other browsers help here, and hopefully Google will fix the issue soon

Now, crashes and freezes may sound like a big deal. But thanks to using tmux, they just mean a short interruption, and not any lost work. I just restart my tablet or MOSH client, attach back to the tmux session I was working with, and I’m right back to where I was, cursor position, vim splits, and all.

Quantifying productivity

Calculating programming productivity is notoriusly difficult. While Mark was able to show impressive figures from his iPad setup, I don’t have anything similar because:

I haven’t had the time to crunch the numbers on the work I do
The ending of the EU projects meant that I’m now doing different things than I did with my laptop, and so comparing results from the two is hard

And in the end what matters more is the results of the work, not the effort spent getting there.

But still, it would be good to have a bit more data on how well the setup works besides the subjective “it feels like a good way to program”.

To this end, I recently started using the RescueTime tracker on both of my Android devices. It keeps calculates how much time I spend with different applications each day, and even allows me to give some sort of productivity scores for them:

I’ll be running this for a while, and will try to combine it with some statistics from my GitHub account. Those two should be able to paint a picture of how I work.

Conclusions

In the beginning, like with any new tool you have to start using, the Android tablet setup felt weird and limiting. But it has grown on me since, and right now I’m not regretting giving my laptop away.

But at the same time, if a new interesting device came out, the cost of switching to that would be minimal. After all, the Nexus 10 for me is essentially just a window into the web and my terminal running somewhere else.

In a way this decoupling is similar to the traditional desktop PC setup where you have a separate computer, screen, mouse, and a keyboard. The difference here is that none of those parts are bound to a desk or connected with cables. Instead, the peripherals talk with my screen over Bluetooth, and my screen with the “computer” over the Internet.

If I for instance want a better keyboard, I can just buy one and replace that part without having to change anything else with my setup.

Cost advantage

One aspect that people have remarked on is cost. Over the course of two years — which is the typical replacement cycle of a professional workstation — this setup is cheaper than a MacBook Air. And with that price I get a lot better screen and about double battery life, and even a smartphone.

What I lose is the ability to work fully offline, though somewhat alleviated by having local vim and git via Terminal IDE.

Moving forward

The experiment will keep continue. In these six weeks, I haven’t seen any negative impact on my productivity from working on an Android tablet instead of a laptop, and many positive ones. Portability, battery life, and the emphasis on tests and automation are probably the foremost.

Of course, new devices come to the market, and eventually something will come that beats the current setup. But then I’ll be able to switch without even losing my cursor position, so the only cost is the hardware itself.

In time, I will write more about how things are going.

Update: Read my Working on Android, 2017 edition post.

There are no smartphones

henri.bergius@iki.fi (Henri Bergius) — Wed, 03 Apr 2013 00:00:00 +0000

iPad is three years old now, and many tech blogs are writing stories to reflect what has changed. More than 100 million of them have been sold, alongside other popular tablets like the Kindle Fire and Nexus 7. But originally the reception was quite sceptical.

Many made the argument that the tablet was “just a big iPod Touch or iPhone”:

at the end of the day, the show’s centerpiece - the iPad – is just a big iPod Touch. Lots of folks will want it, in a hypothetical sort of way. But it’s hard to imagine all that many of them will fork over the initial $499 for a crippled version

The funny thing about this argument is that — while the skepticism was misplaced — the core point was true: The iPad is just a big iPhone.

Or to put it the other way, the iPhone is just a pocket-sized iPad.

Tablets of different sizes

There was a recent Time interview of the computer science legend Alan Kay. I shared it on Google+, and there was some discussion. I made the following argument:

In the end there are no phones any longer. Just tablets of different sizes, from tabletop (iPad, Surface) to pocketable (what we call smartphones)

The chances are that if you’re reading this post, you will have what you consider a smartphone. Look at it, and consider how you use it. Is it really a phone, or is the way you use it a lot closer to what you’d consider a tablet?

Back in mid-to-late 2000s, we had Nokia’s Internet Tablet devices. We considered them tablets, and did tablet-like things on them. The Nokia 770 tablet had a 4.13” screen. The iPhone has a 4” screen, and the Nexus 4 has a 4.7” screen. And yet somehow the first device was seen as a tablet, and the two latter as smartphones.

The software running on smartphones and tablets is nearly identical, as are the use cases.

Phablets meet in the middle

Smartphones and tablets are converging, quickly. Manufacturers know this, and the device-buying public is starting to see it too. But still the gadget blogs love to diss the large “phablet” devices, even though they sell quite well.

The problem here is that many technology bloggers still try to keep the two categories of devices — smartphones and tablets — separate, even though they really aren’t. Maybe these devices are two big for holding against your head for a phone call, but who really does that anymore?

In reality all of them are tablets — windows on the web — and the only difference is that some of them fit in your pocket, and others need a bag, providing a bigger canvas to see information and work on in exchange.

This is the use case I have. For most of my internet and communication needs, I’m using a Nexus 4 as a pocketable tablet. I also have a larger tablet, which I use as my workstation and for some things where a bigger screen is nicer, like graphic novels.

Some are even able to do all their work on the smaller phablets.

End of telephony

The big news here is that the telephony part of a smartphone is not going to matter for much longer. Internet-based communication tools like instant messengers, email, and hangouts provide richer ways to interact, and don’t tie you down to a specific device, or a specific telecommunications provider.

In the long run, this means an end to phone subscriptions. As I wrote on my “hacker’s toolkit”, buying prepaid data is cheaper and easier:

As the MiFi is only used for Internet access, I can buy cheap pre-paid SIMs from each country I travel to. Paying somewhere around ten euros for a month of Internet abroad certainly beats the usual roaming charges!

This is already happening. For example, Asymco reported on dropping SMS volumes in Spain:

After peaking at the end of 2008 at about €450/quarter, revenues have fallen by 60% to about €171 million in the third quarter of 2012. These figures represent almost 100% operating profit for operators so the impact is felt directly in the bottom line.

The culprit is IP-based messaging. Services like Whatsapp, iMessage and even Facebook offer “free” messaging to users who have a smartphone and a data plan. I’ve been told that 97% of Spanish smartphone users have Whatsapp installed. In some markets this “free” messaging is offered via BlackBerry Messaging.

This obviously is a development telecommunications companies are scared of. But while SMS and call volumes go down, the other change is that all these new devices will have SIM slots, and so the operators can sell a lot more of data plans.

Some of them are already targeting this new world. T-Mobile recently killed their traditional subscriptions and subsidies in favor of prepaid plans.

This is a new world

The computing world is switching to tablets rapidly. These tablets can be smaller or bigger depending on the requirements of the user, but they all are internet-connected, touch-capable and full of sensors. They already fit use cases from software development to watching media or social networking.

This will mean eventual changes in our culture:

My generation will be at something of a loss when this new world comes about. In my life, I’ve been rewarded for communicating effectively online via text. I’m a reasonably effective verbal communicator, but not nearly as good as I’ll need to be to compete with the telepresence-native adults that the children of today will grow up to be.

Today’s digital natives will be tomorrow’s telegraph operators. The only way to survive will be to understand the impact of pervasive video communication before it sweeps us under our keyboards.

PCs will still remain as the main productivity tool for some years, mainly thanks to all the legacy software built around that ecosystem. But the VisiCalc moment of tablets will come, sooner or later:

Every major shift in computing has brought its new big companies. PCs gave us Microsoft, web Google and Facebook. In the tablet space the focus has so far been on hardware and platforms, but I’m quite certain there will be winners in the productivity software space as well, companies that we may not have even heard of yet. Maybe your company is going to be one of them?

For now, I’m considering my adventures in the tablet productivity world an experiment. But day by day, my work tablet setup is feeling more and more comfortable.

Right now I don’t miss my laptop. Or having a phone number.

Working on an Android tablet

henri.bergius@iki.fi (Henri Bergius) — Mon, 18 Mar 2013 18:00:00 +0000

As mentioned in my post Hacker-nomad’s toolkit, 2012 edition, the lease period of my lovely — Linux-driven — 11” MacBook Air expired this month, and I had to consider what kind of gear to go with next.

The safe bet would’ve been to just get a newer version of the Air, or maybe the 13” Retina MacBook with its great screen. A fresher approach would be a ChromeBook, either the cheap and light ARM ChromeBook, or the Pixel with awesome screen and design but crappy battery life.

I’m spending most of my days developing software, and so I should be able to work with a ChromeBook and a remote Linux box. But if that works, why not try working on a tablet? They’re cheap, light, durable, and have an all-day battery life. And if Mark O’Connor was able to work productively a whole year with one, why couldn’t I?

Since I already had a Nexus 10, this is what I decided to try.

The setup

The Nexus tablet has a great, “better than retina” screen, which can render my coding sessions and web user interfaces beautifully. The 10” screen is somewhat smaller than what I had on my Air, but not terribly so.

However, the big problem with tablet productivity is text input. Much of our current work environment is still textual, and typing on a non-haptic glass touch-screen is simply not very nice.

Hardware keyboard

To fix this I purchased a Microsoft Wedge Keyboard, which connects to the tablet over Bluetooth. Recent Android versions have quite full support for external keyboards, allowing me to use it for all text entry, and even for some keyboard navigation. So yes, Alt-Tab works.

The Wedge keyboard is about the same size as typical keyboards on compact laptops. Microsoft has always made good hardware, and the keyboard is no exception, providing a quite nice feel for the size it has. A handy additional feature is the included cover, which puts the keyboard to sleep automatically, and can act as a tablet stand when opened. No more issues with keyboard waking up in your bag and deleting everything.

For those prepared to lug a heavier option, there is a Bluetooth mechanical keyboard, which is probably a lot better than any laptop keyboard on the market. And if you already have a good keyboard, Android supports most of the USB ones via an OTG cable.

Desk setup

While I’m spending quite a lot of my time on the road, living out of my backpack, I do have a regular desk in the Berlin office I share with Content Control. Since my coding sessions are often long, I’ve been a bit concerned with my programming ergonomics for a while now, even considering a standing desk.

Tablet has the same advantage as a traditional display in that it is decoupled from the input devices, giving you greater freedom in how to position them. I have a Callstel tablet stand that allows me to place the tablet in practically any place and height above my desk. The current setup is just slightly below my eye height in the normal sitting position, but I’m still experimenting with that.

Gorilla arms

The Gorilla arm syndrome is what everybody brings up with every touchscreen computer — it is simply not nice to constantly lift your arm to touch the screen.

In my experience this isn’t so much of an issue when you’re using the tablet positioned similarly as a laptop screen would. But when the screen is up in a more ergonomic position, like it is on my desk, then this quickly becomes an issue.

To solve this I bought a Apple Magic Trackpad, which connects to the tablet again via Bluetooth, and allows both regular mouse usage with Android, as well as many multitouch gestures.

Why Android

Most people experimenting with replacing computers with tablets go with an iPad, the established market leader. iPad has many benefits over the Nexus 10, including a more mature software ecosystem, and better availability — if you break or lose your tablet, you’ll be able to pick up a new one from practically anywhere, whereas the Nexus devices are only available online.

The reasons for me to go with Android have to do with openness. Since the core operating system is open source, there are custom ROMs I could use if I wanted, and I can do file management the traditional way when I need to. An even bigger reason is that the sharing system makes it possible to connect various applications together. Being able to run multiple broser engines is also nice for a web developer.

Another bonus is the availability of NFC on the tablet. I’m quite often sharing content between it and my smartphone. If I run into an interesting web article, I can either send it to my Kindle to read later, or touch the tablet with my phone and read the article on that. This is surely a feature that will gain more mindshare whenever it is introduced to iPhones.

I also prefer the rugged, rubberized look-and-feel of the Nexus 10 to the cold metallic iPad, even though a 4:3 screen would be better than the widescreen I have now.

Software used

I really don’t need much for my daily work — just a browser and a terminal. Here are the apps I use on a daily basis:

Chrome and Firefox web browsers
JuiceSSH SSH client to access my remote Linux server
TapChat IRC client
File Manager HD for moving stuff around, including between file servers
DroidEdit Pro for quick local file edits

In addition I’m using some of the built-in Google apps, like Google Talk, GMail, and Google+ for Hangouts.

For offline development I have an installation of Terminal IDE that allows me to run Linux utilities like vim and git locally. If I would root my tablet I could also install a Ubuntu chroot and run whatever I need. With a previous tablet I even was able to run Node.js servers and databases on the thing!

My development virtual machine is from DigitalOcean’s Amsterdam site, providing quite nice fast connections here in Europe. I mostly work on it via tmux and vim, and run whatever processes I need, including long-running NoFlo flows.

Pros and cons

Based on my initial experiences of working with this setup for a week, working on a tablet is quite different from a traditional computer. Here are some good things:

Battery life: the Nexus can easily get me through a full workday with a single charge, meaning that I only need to connect it to a wall overnight. It also charges via standard micro-USB meaning that I don’t need any extra power bricks with me
Portability: most tablets are smaller and lighter than full laptops. And they can be used more easily when standing, sitting on the couch, etc.
Instant on: there is no suspend/resume cycle. I press the power button, the tablet recognizes my face via the camera, and I’m instantly back to where I left off
Modularity: with a tablet, my work environment is built out of multiple modular pieces that I can take with me, or leave at the office depending what I intend to do. And I can set them up in different configurations when working
Touch: for software developers, working on a tablet really drives home the importance of touchscreen friendliness. I’ve already noticed this affecting my UI designs
Focus: everything is full screen, meaning no need for window management. Tablet software also tends to be simpler and has less configuration to fiddle with

But obviously there are some downsides as well:

Office documents: the office suites available for Android are quite poor, and the mobile version of Google Docs is simply terrible. One solution would be using MS Office or LibreOffice over a VNC connection
Mobile-first web: quite a few websites try to offer even large tablets like the Nexus 10 their silly mobile sites. Thankfully this is becoming less prevalent due to media queries and responsive design
Offline: much of my current tablet workflow requires me to be online. I could write code and blog posts offline with tools like Terminal IDE, but there would be no way to run and test software
Bugs: many tablet applications are still in their first generation and lack the maturity and robustness that their desktop counterparts have had time to gain
Web debugging: while WEINRE sort of helps here, it is still a lot less convenient than the web development tools that come with desktop browsers

Conclusion

This tablet work setup is for now an experiment. If I find it hindering my productivity, I’ll just have to get one of the laptops mentioned in the beginning of this post and work in more traditional manner. But if it works, then great! In that case I have finally found a more modern setup for programming work — one that gives me both better ergonomics and mobility.

I will try this setup for some period of time, and then report the results here on my blog.

Update: Read my Working on Android, 2017 edition post.

Hacker-Nomad's toolkit, the 2012 edition

henri.bergius@iki.fi (Henri Bergius) — Fri, 21 Dec 2012 00:00:00 +0000

Back in last July – when choosing photos to use in the epic The Dreams of the MeeGo Diaspora post – I noticed that it is quite fascinating to look at the various tablets and mobile phones we’ve been using over the years. Back then they all were so new, shiny, and exciting, and yet hardware moves so fast that something from a year or two ago would look quite dated now.

And so I thought it might be interesting to keep some sort of record on what kind of computing devices I’ve been using for my work – and how – over the years. This post is the first of the series, and shows the setup I’ve had during 2012.

The setup, and what I do with it

Many programmers believe in beefy workstations and huge multi-display setups. I was never so much into that, and as I’m spending half of my working time on the road, it has made sense to adapt to a more minimalist setup. A small laptop, a small tablet, and not much else.

Most of my programming is for web services, and so the main things I need are a browser and a terminal. After the move to Berlin, various video conferences with project partners all around the world via Google Hangouts or Skype are also almost a daily fare. My current setup handles these use cases quite well, and is simple and light to be carried around Europe without any problems.

At the same time, the nomadistic lifestyle has meant there is really quite little use for a phone. I do couple of calls or SMS per week, but in general the roaming charges, and better communication tools that Internet offers means that phone is just another screen to the services I use, essentially just a small tablet.

Workstation: 2010 MacBook Air 11”

My current main computer is the MacBook Air I got in early 2011. Apart from the lousy battery life, I’ve been generally very happy with it. It is small, light, and still has a reasonably good screen and keyboard. The solid state drive makes it also quite fast.

I’m running this laptop with Ubuntu 12.04 and the GNOME Shell. Linux supports this hardware quite well, meaning that I’ve never had issues with things like sound, the multi-touch trackpad, WiFi, or suspending. But external displays have sometimes been tricky.

During a typical workday, I only have two windows open: a full-screen Firefox window for email, browsing, and testing the software I write, and a full-screen terminal window running Vim with various splits. All of the rest of the software runs usually on a cloud hosting provider, or inside a Vagrant virtual machine. I sometimes also run Libreoffice, but more and more of my office productivity needs are now handled by Google Drive.

The battery life issue is what’s making me rethink this part of the setup. Apple promises a new MacBook Air about five hours of use, but after two years, and with running Linux instead of OS X, I’m down to maybe two and half hours. This is by far not enough, especially during conferences or travel where power outlets are not readily available.

I’d also love to get to a device with a bit more standardized ports. Having to replace faulty Apple laptop chargers and to remember the display dongles when presenting something is a bother.

Tablet: Nexus 7

Having used tablets daily for a long time, I’m a big believer in them as both production and communication devices and as a much better computer during free time. Actually, to help maintain a sensible work-life balance, our household of two programmers has a strict no laptops at home policy.

I used a Transformer Prime convertible tablet during the first half of 2012. With its detachable keyboard it was a great device as a travel computer and for conference live-blogging. The keydock contained an additional battery, and so I could rely on being able to use the device for a full day.

At the same time, the tablet was a bit big and clunky for travel. You’d always have to dig it out of the bag separately, and such a big device wasn’t comfortable when reading in bed. And so, when the Google’s Nexus 7 came out, I swapped devices. The seven inch form factor is great for both reading at home, and during travels. When you need to swich trains or board an airplane, you can just stick the device in your pocket. It certainly isn’t comfortable to keep there for long times, but pn short transfers this is a very handy possibility. No wonder people on the iOS side of the fence are so excited about the iPad Mini!

I use the tablet for the various video conferences I have, and do most of my web reading with Firefox Mobile and Instapaper. On work trips I also read books on the Nexus, so that I don’t need to bring the dedicated Kindle e-reader as an extra device. Firefox Mobile is great in that it synchronizes my passwords and browsing history between the tablet and my laptop, so that I can always easily pick up and continue on either device.

Internet access: Huawei MiFi

Since much of what I do happens online, being able to connect from everywhere is very important. While I could use JoikuSpot to share the Internet connection from my Symbian phone, having a dedicated device for this purpose makes sense. With the MiFi wireless base station I can spare the battery of my phone.

As the MiFi is only used for Internet access, I can buy cheap pre-paid SIMs from each country I travel to. Paying somewhere around ten euros for a month of Internet abroad certainly beats the usual roaming charges!

However, having to dig this device from my bag and start it whenever I need connectivity is a slight hassle. Now that there is a Nexus 7 with 3G support available that might be a better option.

Audio: Sennheiser noise-cancelling headphones

This is actually a piece of gear I’ve had for a while: For music and teleconferences I’m using Sennheiser’s noise cancelling headphones that I bought back in 2008. While they’re bulkier and pricier than typical in-ear headphones, they are great especially when traveling or working in a noisy environment.

The headphones are slowly getting a bit frayed, and so I will probably have to look for replacement soon. Having optional Bluetooth could be handy.

Thoughts for 2013

The current setup has generally served me well for about two years of intense travel and open source development. We generally run our computers with a two year replacement cycle, and so at least my laptop is due to be replaced quite shortly.

Thanks to services like Travis CI and Heroku, my computer needs are becoming even simpler than they used to be. Theoretically I could work with any device that has a good screen, a good keyboard, and can run terminal and a web browser. This means I could even work on an iPad. At least nearly.

For the next cycle of devices, the focus will be on features like:

Endurance: the battery should last a full working day when traveling or at conferences
Connectivity: I want Internet everywhere, without any unnecessary hassles
Resolution: having used some of the high-DPI devices like the new iPads and MacBook Pros, I definitely want something like that

I’m also intrigued about switching to a Kindle Paperwhite 3G as my reading device. Better screen, and ability to access WikiPedia anywhere in the world for free!

If you have any great suggestions for a device or a combo fulfilling those requirements, please comment!

If this all sounds very consumeristic, it should be noted that my old work devices always get recycled to other users. When you do mobile and web development, you need to have access to the new hardware that people are buying and using.