Page 1
Essence Care@Home

Senior monitoring – security flipped on its head

Let’s say you want to set up a security system for your home. In days past that would mean hiring a security company that would install sensors around your house, connected to a keypad, and linked via a phone line (usually a dedicated line you would need to add) to a monitoring company. Those sensors would probably have required wired connections to a central hub installed in a closet somewhere, or in a drop ceiling, requiring lots of installation work, cutting holes in walls, and cleaning up the mess afterwards with spackle and paint. Once installed, this system would only work if you paid the company that installed it a monthly fee.

DIY Security Systems

In recent years a new category of security systems have emerged, so-called DIY security systems. These systems are designed to be installed by the homeowner, and in general do not require ripping up walls to install them. Some systems allow you to monitor your house yourself, and some include monitoring for a fee, similar to the older systems. One good example of this type of system is SimpliSafe, which sends you a kit including various sensors to install yourself, and then provides a traditional monitoring service. In general these new systems use wireless connections to connect to a central hub, and each device therefore only needs power. This means you can simply plug in a sensor and connect it to your hub, wherever you have an electrical outlet. Smaller sensors can work with just batteries and can run for up to a year before needing the batteries to be swapped or charged.

Camera-based Security Systems

Blink system with 3 Cameras
Blink system with 3 Cameras

More recently, systems have come out where cameras, the most power-hungry of security sensors, have been able to be run on batteries as well. Whole security systems have been developed based on just using these wireless cameras with batteries. Examples include Netgear’s Arlo system, as well as Blink, Homeboy and Canary.

All of this innovation is great, but runs into a problem when one wants to set up a system to help their elderly relative. Much of the technology is the same, but usage is flipped on its head. You don’t want a system that is triggered every time it senses movement, but one that recognizes when there is a lack of movement. While a standard security system can be dumb in that any movement is considered bad, a system set up to monitor the elderly should be smart and learn patterns of movement, only notifying when there is a change in the pattern.

Some security system are cognizant of privacy concerns, offering physical shutters to block cameras when a system is disarmed, and insures all video streams are encrypted. When monitoring the elderly, however, your system is never really disarmed, it’s just in a different mode. If your security system is camera-based and gets its motion-detection capabilities from the camera, then closing the shutter means your system cannot operate at all.

Of course, having a camera on all the time has major privacy concerns, and your elderly relative may, understandably, not want a cameras watching them at all times, even if its just for motion sensing. All of these new camera-based systems sadly cannot be used for the elderly, or at least the system cannot be solely based on cameras. This means another type of solution is required.

Existing Security Systems Adapted for the Elderly Wellness Notification Wellness Notification

Some existing security system companies offer versions adapted for the elderly., for example, offers a service called Wellness that monitors seniors in their home, recognizing patterns, and even sensing how long someone stays in bed or in a favorite chair. This system is integrated into their monitoring service, and can alert a family member if their relative leaves the house at a strange time, or doesn’t get out of bed all day, or doesn’t open the fridge.

Essence [email protected]

Essence Care@Home
Essence [email protected]

Israeli company Essence, which sells panic-button systems for use in elderly homes, has come out with a more comprehensive system called [email protected] that uses a combination of motion sensors, door sensors, cameras, etc. as well as a traditional panic button, in combination with a service to look for patterns and notify family and care providers accordingly. This system is sold to monitoring companies that install the system in people’s homes and sell a monitoring service. Silver Mother

Silver Mother Sensor on Medicine Bottle
Silver Mother Sensor on Medicine Bottle

One interesting solution is from French company, which offers a product called Silver Mother. Silver Mother works with a central hub with small wireless motion sensors. These sensors can be used many ways. For example, place one on the refrigerator door to sense how often the fridge is opened. Place one on a mattress to see how often and how long a person is in bed. Put one on a medicine bottle to know that someone has taken their medicine (or rather at least one can determine if they have not taken their medicine if the bottle never moves). Another advantage of the Silver Mother system is there are no monthly fees. It is for the most part a self-contained system, although it can work with Nest and IFTTT.

DIY Options for Senior Monitoring

If you wanted to build your own senior-focused security/monitoring system, there are a few options, although none that are perfect. One approach is to use a multi-purpose hub like Samsung’s SmartThings Hub, or Wink’s Hub. Both products connect to devices from many different manufacturers, using multiple home-automation protocols, such as Z-Wave and Zigbee, as well as WiFi and Bluetooth. Wink additionally works with some manufacturer-specific protocols like ones from Kidde and Lutron.

Protocol Problems

The use of popular home automation protocols like Z-Wave and Zigbee is key, as it allows many devices from many manufacturers to be used together. Unfortunately, that’s only partly true. Both protocols have their problems.

Z-Wave uses different frequencies in different countries, and there is no such thing as a hub that can handle more than one frequency. If you’re in the US and you buy a US hub, you need to buy sensors that are intended for the US market. There are more than a dozen different frequencies used around the world. The US is different than Europe, which is different than Australia, which is different than Japan, which is different from China, etc. Hong Kong shares one frequency used in the US, but not a second one. For a large multinational company that can manufacture dozens of versions of their products, this is okay. For a small company looking to break into the home automation market, this is a major problem. If you move around, you also may not be able to take your equipment with you.

Zigbee can for the most part be used on a single frequency (although it does support using similar frequencies to Z-Wave in some cases) worldwide because it works in the same frequency as WiFi and Bluetooth (2.4 GHz), although it uses different profiles for different devices, and devices designed for one profile will not work if the device its connecting to uses a different profile. For example, the Samsung SmartThings Hub supports the Zigbee Home Automation profile, but not the Zigbee Smart Energy profile. Add to this that the signal strength allowed in different countries can be different (the US allows almost twice the signal strength of Zigbee devices as is allowed in Europe, so if you buy a Zigbee device in the US it’s probably illegal to use it in Europe).

Programming a DIY System

Putting aside these protocol problems, we run into another problem. You need to program the system to notify you based on the sensors in ways that make sense for seniors. The non-DIY system have built that intelligence into their system. If you build something yourself, you need to figure out a way to create a similar intelligent method for notifying you. Some types of notifications are easier than others. For example, if the door to the outside opens between 11pm and 6am, send a notification. If the resident hasn’t gotten out of bed by 11am, send a notification. If the system sees no movement for over an hour during the day, send a notification. These are simple rules that could be enhance by using advanced pattern recognition, but still will work for the most part. A more sophisticated system would know when the resident gets up every day (i.e. between 8am and 9:30am) and would know if something is out of the ordinary (the resident is not yet up by 10am), but if you watched the data for a few weeks, you could probably just set the notification for 10am and get the same thing.

Both Wink and SmartThings can be programmed using IFTTT. This allows some level of interoperability between them, as well as with other systems that don’t support the same protocols, but do support IFTTT. IFTTT stands for IF This Then That, and is a simple rules-based system for telling Internet-connected services to trigger actions based on certain conditions. These sets of rules are called Recipes. For example, you could set up a recipe to send you an SMS whenever a specific stock went over a certain price, or you could get an e-mail whenever a specific product showed up on eBay. In Home Automation scenarios, you could have a recipe that whenever someone passes a motion sensor outside your door, the light outside is turned on and a beep is sounded inside. These can be very powerful, but are limited in intelligence. You could use an IFTTT recipe to turn on a light through your Wink Hub when the sensor in a Silver Mother system detects the resident gets out of bed (although you would need both the Wink hub and the Silver Mother hub).

Samsung gets Groovy

Samsung, in addition to supporting IFTTT, also supports creating programs using Groovy, a language developed by the Apache Foundation which works in the Java Platform. This means it can use Java libraries, and is run through the JVM. The technical details don’t matter too much, but in short it means that you have a lot more control in building intelligent applications using SmartThings than you do with Wink.

As an example, here’s a program I found posted in the SmartThings Community that triggers a notification if there is no motion between a specific start time and an end time:

 *  Notify if no motion
 *  Copyright 2015 Bruce Ravenel
 *  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
    name: "Notify if no motion",
    namespace: "bravenel",
    author: "Bruce Ravenel",
    description: "Notify if no motion during some time period",
    category: "Family",
    iconUrl: "",
    iconX2Url: "[email protected]",
    iconX3Url: "[email protected]")

preferences {
	section("Which motion sensors?") {
		input "motions", "capability.motionSensor", title: "Motion(s):", required: true, multiple: true
	section("Text me at (optional, sends a push notification if not specified)...") {
		input "phone", "phone", title: "Phone number?", required: false
    section("Unless this presence sensor is not present...") {
	    input "presence1", "capability.presenceSensor", title: "Which presence?", required: false, multiple: false

        section("If no motion between these times...") {
		input "starting", "time", title: "Starting", required: false
		input "ending", "time", title: "Ending", required: false

def installed() {

def updated() {

def initialize() {
	subscribe(motions, "", motionHandler)
        schedule(starting, startingTime)
        schedule(ending, endingTime)

def motionHandler(evt) {
	state.noMotion = false

def startingTime() {
	state.noMotion = true

def endingTime() {
    if(presence1) if(presence1.currentPresence == "not present") return
	if(state.noMotion) {
    	    def msg = "There has been no motion since $starting"
	    if (phone) sendSms(phone, msg)
            else sendNotification(msg)

I don’t mean to show this as an example of a complex program, but rather just what the code looks like for a simple program. Samsung has a Marketplace within their phone app that allows you to download many applications (dubbed SmartApps in keeping with their naming pattern), including a whole category called Elder Care. I wasn’t able to find a list of the SmartApps in that category online, and I can’t look at them in their app because you need to connect it to a Hub before you can view the Marketplace.

The average person isn’t going to develop machine-learning algorithms in Groovy to learn the daily activity patterns of their elderly relative. Hopefully enough relevant SmartApps exist in Samsung’s Marketplace that they wouldn’t have to do it themselves.

Where does that leave us?

It would appear that we have either pre-packaged systems that have intelligent activity monitoring which requires monthly payments, or DIY systems that are a bit touch-and-go considering you need to buy lots of sensors and hook them into some existing applications that may do what you want, or you may need to write custom applications to get there, and none of those are likely to have the full level of intelligence needed to prevent frequent false positive notifications. There are some good DIY systems like Wink and SmartThings, and even senior-focused systems like Silver Mother, but they’re not set-it-and-forget-it easy to configure. We’re at the point where system like Blink have pretty much brought that easy of installation to the home security market, but the senior market is still catching up. It should be interesting to see how this niche makes up the ground in the next few years.


Why product design is like writing a recipe

While reading a cookbook recently I realized the goal of the cookbook author is not entirely different than a product designer. In both roles, the designer and author, there is a need to anticipate the needs and knowledge of the user, and design around those needs within the constraints of their knowledge.

There is also a parallel here between the engineer and the professional chef. Both have much more knowledge than the end user, and rarely understand how their user will be using the product they are creating. If you’ve ever read a cookbook actually written by a professional chef (as opposed to a professional cookbook author), you’ve probably not understood many of the terms or known what many of the ingredients were. If you did understand everything, then either you’re either an experienced chef, or the book was likely co-written with a writer who specializes in cookbooks.

User-Focused Design

It’s not that different with engineers working on a product to be sold to consumers. If you’re a computer programmer selling a product to a computer programmer, maybe you can get away with designing it. If you’re a computer programmer selling to a consumer, you probably need someone to guide the development of the product so it anticipates the needs of the user.

Diagram of the CL-9 CORE remote from a patent filing
Diagram of the CL9 CORE remote from a patent filing

One of the products that sticks out in my mind in this regard is the first product Steve Wozniak worked on after he stopped working for Apple. He left Apple to start CL9, the company that made the first universal programmable remote control (called the CORE). Many of the useful features developed by him back in the mid-to-late 1980s are still hard to find in remote controls today. The remote was built with essentially the same processor that was in the Apple II, also developed by Wozniak. The remote had 16 primary thumb-size buttons that could be programmed to control multiple devices, so a single button could turn on the TV, the VCR, and then start recording. The remote had 16 layers, allowing for 256 possible actions (16 buttons in 16 layers). The remote could even be programmed to activate a specific button’s programming at a specific time (i.e. start that above recording sequence at 6pm).

To keep the settings and time in the remote, there was a coin-battery soldered to the circuit board. If the battery ever died, however, you needed to have it de-soldered and a new one soldered to the board. If the battery ever lost charge, you needed to connect the remote to a computer though a serial cable and re-load the firmware. The keys did not correspond to standard remote functions, but in keeping with its ‘universal’ concept, the keys were labeled in hexadecimal (i.e. 1-9 and A-F). These issues, in addition to it’s cost (over $300 I believe) and the fact there were other simpler ‘universal’ remotes introduced around the same time, drove the company out of business before it ever really got started. I don’t know who decided that hexadecimal was a good user interface, but it seems clear general users were not really considered during the design process.

When writing a recipe to be placed in a cookbook, the author needs to think about who is reading the recipe. It could be the recipe is in a professional cooking textbook geared toward culinary students, but in most cases cookbooks are geared towards the average home chef. That means that the terms used need to be well known, and anything unlikely to be known needs to be explained. If the recipe is for an ethnic dish that uses ingredients not normally found in the supermarket, the recipes needs to explain what the ingredient is, and hopefully explain where it can be found.


"Noomi Basra"
“Noomi Basra”

As an example I can use an ingredient found in the cookbook I was just looking at, which the cookbook author refers to as Noomi Basra. She does explain that these are dried limes, and that they can be found in Middle Eastern markets. She also explains how to prepare them. One interesting thing about Noomi Basra, which I know because I’ve looked for them, is that they have a different name depending where you are. If you went to the average Middle Eastern store and asked for Noomi Basra (Lemons from Basra) they probably wouldn’t know what you’re talking about because that’s only the name used in Iraq. In other Arab countries it’s referred to as Limoo Omani (Limes from Oman), and in Oman itself simply as Loomi. In Israel they’re referred to as Limon Parsi (Persian Lemon). In the US they are most likely known as a Black Lime or simply as a Dried Lime (although in a Middle Eastern market they may be known by one of the above names). As an aside, even though some of the names refer to them as lemons, they are always limes. Another thing a cookbook author should do when using hard-to-find ingredients is offer alternative ingredients that may work as substitutes when the reader cannot find the ingredient.

Do you know what Mirepoix is?

Another problem in recipes is the use of terms for other recipes. For example, when an ingredient listed is something like Mirepoix or Demi-Glace. These are not ingredients, as much as other recipes chefs are expected to know and make separately. These terms may be outside the knowledge space of the reader, and should be explained.

In a similar vein, culinary verbs such as julienne (to cut in long thin slices) or brunoise (to julienne and then turn 90 degrees and cut again into small chunks) must be explained, if not in the recipe, then in a glossary. Obviously not every term and ingredient needs to be explained, but finding the cut off of what to define and what not too requires testing the book on readers outside your normal comfort zone. If you’re writing a book on French food and only show it to experienced French chefs, you’re not going to get the feedback you need.

Specialized domain-specific terms are known as jargon, and the world of technology is filled with such terms (just like the culinary world). If these things are not explained, it’s because the author makes assumptions about the knowledge of their reader. Similarly product designers many times make inappropriate assumptions. Product usage assumptions can run the gamut of thinking the usage is obvious when it is not, thinking the user will read the documentation, and assuming your user will use the product in a specific way, when they might assume it is meant to be used a different way.

Making the wrong assumptions

In Israel there have long been only two options for getting lots of TV channels. You could get service from HOT (the country-wide cable company) or from YES (the country-wide Satellite TV company). Recently a third option came into existence, called Cellcom TV, from a cellular phone company. Cellcom’s option operates over existing Internet infrastructure (which ironically is either using the cables of HOT or YES’ largest shareholder Bezeq, the landline phone company). Cellcom can install a cable box that has an okay selection of channels (although no where near as extensive as HOT or YES).

Now imagine this is across the room from you and you need to pick a channel

Once set up (which you can almost guarantee will require multiple visits from Cellcom and your Internet infrastructure provider) you are left with a very advanced cable box with a very simple remote. The box lets you select channels, or review video-on-demand options, or use various Internet applications such as YouTube. Very advanced, however, doesn’t translate into very easy. The remote has no numbers on it, so in order to select a channel you need to press the menu button, select ‘Channels’ and then use the directional buttons to move over a grid of tiny channel logos until you find the channel you want, and then select it. You might have to press a dozen buttons to change the channel. You can’t even keep a few favorite channels in easy reach.

It is possible to use the channel up and down buttons, but how do you know what is up and what is down if there are no numbers? In addition, there is no pause in using the up and down buttons, so you can fly past several channels without even seeing what they were. Someone working at Cellcom was thinking that using numbers is an old method that isn’t necessary with today’s interactive user interfaces, but didn’t think through what removing the use of numbers meant for users.

Making sure to have the correct use cases

Imagine setting up this television service for an elderly person who is used to simply entering the numbers of the channels they want to watch. Now they need to remember which button pops up the menu, which menu item to select, where the channel icon they want is located (possibly off-screen and requiring scrolling down to see), and they need to pick from logos of channels so small even a young person without glasses would be hard pressed to identify them all. An elderly person might also want to look up programming in the TV listings in the newspaper, but without numbers it’s hard to know which channel they are referring to when they say something is on.

The product designers behind the Cellcom TV box were obviously not thinking about the above use case. Perhaps they were focused on young millennials that were more likely to switch from the existing providers, and who would be more appreciative of the Internet features in the box. Evidence of this comes from the fact that for the menu button they use the 3-bar icon (nicknamed the Hamburger) commonly used in mobile apps and web sites to represent a menu.

Aiming for perfection

When designing a product, or writing a recipe, the goal is the largely the same. You want the end-user to be able to use your product, or follow your recipe, with as little help as possible. The ultimate product design is one that is so obvious in its operation that it requires no documentation at all. In a recipe, you want to make sure that there is no confusion over what to do in each step (ever seen an ingredient referenced in a recipe step that wasn’t listed in the ingredient list? or seen an ingredient mentioned in the ingredient list that is never mentioned in the instructions?).

Recently I was working with a software developer on a product I was designing. He was 100% certain that the product would be used a certain way, when in my mind that was only one out several ways it might be used. The product was going to be installed by less-technically-skilled people than we would have liked, so covering all the bases in what might go wrong was critical. He had come up with a usage he thought optimal, and had ignored any other possible use cases. One could argue on how he came to that conclusion. Perhaps the specifications were not detailed enough (my fault), the communications between me and him broke down (with several other people in the mix), or he ignored specifications and communications and did what he thought was right (which could be arrogance like the architect, inexperience, or simply laziness). I believe it was a mix of all of the above.

The end result, however, was a product that in several non-trivial cases simply failed. When these failures were pointed out, the developer answered that if they did things the right way (i.e. the way he decided was best) those would never happen. Needless to say, or perhaps not so needlessly, you should design flexibility into your products so diversions from the intended path don’t cause it to fail. That’s why thinking through use cases and doing sufficient product testing with members of each use case is so important. In this product, those failures were fixed, and the product was made so it would never fail (rather it would try to fix problems that arose automatically).

Designing a product takes some imagination both in how the product should work and who will be using it, needs product testing with multiple user types, and the willingness to change what you originally envisioned to make it usable by the people who will actually be the end users.


High lights and design

Recently while driving down the highway I noticed a crew changing lightbulbs on a street lamp. This particular street lamp was one of those extra-high poles with the circle of lights around the top that you see only on highways and some industrial or sports complexes. I had occasionally wondered why the transition was made to those poles that were double or triple the hight of standard street lamps. My assumption was that being higher they provided a larger spread of light, and they could be placed in the median so they could provide light to both sides of the highway. However, as I knew street lamps had their lights changed by crews with cherry-pickers, I wondered how these high poles whose heights were clearly beyond the reach of a normal cherry-picker had their lightbulbs changed. The answer to that question was now answered, but more on that in a moment.

Seeing this crew change the lightbulbs reminded me of two homes with the same issue. Both homes had living rooms with high ceilings, which were very nice, but had the same practical issue – changing the light bulbs was difficult.

In the first home, the lightbulbs were standard Edison-screw bulbs, in spotlight style with flat tops. In order to change them, you pulled out a telescoping pole with a suction cup on the end. You extended the pole and attached the suction cup to the bulb. You then rotated the pole until the bulb came out of the receptacle, and lowered the pole to remove the lightbulb. Then you did the reverse, attaching the new bulb to the suction cup, lifting the pole and inserting the lightbulb into the receptacle, and rotating the pole until it screwed in all the way. The process was a bit tricky, but not impossible.

In the second home, which I was involved in renovating, there was a row of lights at the highest point. These light fixtures were embedded into a design element built out of plasterboard. Remembering the first home, I asked the architect how you changed the lightbulbs which were clearly out of reach, even with a ladder. He explained to me that each bulb was held in by a frame that needed a screwdriver to remove, and that the only practical way to change the lightbulbs was to bring in scaffolding and stand up there with a screwdriver to take out the frame, then replace the lightbulb, then add back the frame. You’d then need to move the scaffolding a few times to reach all the lightbulbs.

Form over function? I was in shock. While design is important, how could one install lighting into a home that no homeowner could change on their own? The architect was perhaps a bit arrogant, wanting his design to be perfect and not taking into consideration such practical matters. What happened next truly threw me for a loop. After I had discussed the issue of replacing the bulbs, the design element that the lights were embedded into had to be changed. While the architect clearly was not going to change the lights after they were installed the first time, when the whole area had to be redesigned and reinstalled (I forget the reason, but I seem to recall it having to do with the air conditioning) I thought for sure he would change them to something more practical. Nope, same crazy lights.

So with all that in mind it’s not hard to figure out why this crew changing lightbulbs on the highway reminded me of these two homes.

So how do these road crews change the lightbulbs on a pole so high no cherry-picker can reach it? The crew lowered the lights down from the top on a series of cables. Presumably they simply opened a panel at the bottom of the pole and pressed a button, lowering the lights using a motor built into the pole. When they’re done changing the lightbulbs, they just press a button again and the lights head back up to the top of the pole. Brilliant. Not practical for a home lighting installation, but perfect for highway lighting.


The world of Mac software development

I was recently sent an offer to beta test a new service. The service is interesting – it is a subscription service for applications on the Mac operating system. Let me digress for a moment. Selling applications on the Mac, or any desktop operating system, has become more difficult in recent years. In the case of the Mac, this is partly Apple’s fault.

The App Store

Apple introduced the App Store for the iPhone back in 2008, and it completely turned the traditional software business on its head. Many companies made a lot of money from the App Store, and others went out of business. It messed with existing business models, and the reverberations in the software industry are still being felt. My own company, Command Speech, was founded shortly before the launch of the App Store, and it had severe effects on our business.

The App Store today
The App Store today

One of the big effects of the App Store was the race to the bottom. Traditionally, software companies had to spend money to market their applications – through magazines, newspapers, and online. There were also distribution costs. In the old days you had to pay for the media it was distributed on, whether a floppy disk or a CD-ROM, and the printed manual and box as well. You had to keep inventory. You needed to ship products, or put them in retail stores where it cost a lot of money to get shelf space. That meant you couldn’t charge too little for your app, or your acquisition cost for that customer would be more than you were getting paid. Some smaller developers could charge less, especially when the Internet brought down distribution costs, but it was still hard to get the word out. The App Store as a searchable marketplace for apps solved this problem, and allowed developers to charge less for their applications since their distribution was handled by Apple, and anyone could find their applications in the App Store. Add to that viral marketing on social networking sites, and you had the perfect storm to lower the price of software.

If you look back to the days of the Palm Pilot or Psion, the software prices were not that different than desktop software. A bit less maybe, but still in the double digits. With the App Store and viral marketing, the most common price for apps shot quickly to the lowest possible price, $0.99, if not free. It’s rare to find software in the App Store more than $9.99, and the only software I’ve seen in that category are apps that work with expensive desktop apps or with hardware, and can charge $14.99 or $19.99 because if you’re a captive user of their other product, you will pay to have a compatible mobile app.

The best example of this that I’ve seen was when Nuvo introduced a mobile app for their home music system. Nuvo has a great system that distributes music to multiple rooms, offers in-wall touch-screen controllers, and has a music server that can stream audio from its hard drive or from various online streaming services. Besides the in-wall touch screen controllers, they also offered a wireless touchscreen remote for hundreds of dollars. When they introduced their iPhone app, they knew they would be cannibalizing the sales of their touchscreen remote, so they priced the app at a price that probably made them more money than the remote – $99. I don’t know how long they kept the price that high, but I can tell you that they now give the app away for free. In fact, the great majority of apps in the App Store are free. Instead of selling the apps upfront, most developers have come up with other business models, such as in-app advertising. Advertising on the desktop has never been very popular, however, so apps on the Mac needed a different model.

The Mac App Store

In 2011, Apple launched the Mac App Store, bringing the same model of app sales to the desktop, except with one major difference. On iOS, Apple controlled all apps that were made available on the device. The only way to get your software on an iPhone or iPad was through the Apple-controlled App Store (without hacking the phone which most people would not do). On the Mac, Apple didn’t close access to the computer, so developers could choose to continue selling directly, could switch to the Mac App Store, or could try some combination.

The Mac App Store today
The Mac App Store today

At first, the Mac App Store seemed great to developers, particularly smaller developers. Basically free distribution, people could find you by doing a search, and updates were automatically pushed out to users. Of course there was a 30% cut for Apple, but other distribution methods were not free, and meant dealing with credit cards, refunds, issuing serial numbers, etc. The App Store simplified everything. At the beginning the App Store was missing a few things, but developers figured Apple would get around to fixing the missing features. One missing feature was a way to do a paid upgrade. Upgrades are the lifeblood of the software industry. You get a customer, they like your software, you spend time to improve the software, and you get paid for that work. Except for reasons that are still not clear, Apple’s decision not to include an upgrade route was not a missing feature, it was by design. Another missing capability for most developers was a way to do a free trial. Developers can of course create another version that users can download from their web site, but that kind of defeats the purpose of selling through the App Store.

Apple has still not added the ability to do a real upgrade. Some companies have gotten creative, by introducing a new app with a new version number, and offering it for less for the first few weeks to allow people to ‘upgrade’ and then raising the price before publicizing the software. This is an imperfect solution to be sure. The worst part is that if a user doesn’t upgrade in the set period, they cannot get the upgrade price in the future. Other developers have come up with more sophisticated solutions.

Omni Group, a long-time Mac developer, has created a way to do both free trials and upgrades, although it’s a bit complicated. They’ve started to make their apps free on the store, enabling for a free trial. After a couple of weeks, features in the app are disabled unless you purchase them through an in-app purchase. If you want to upgrade, you can find the old version of the app on your hard drive, and it will verify that it’s a valid version of the app, and then show you less expensive in-app purchases to get the same features. Not particularly elegant, but still workable.

There were other problems with the App Store, including additional security features (sandboxing in particular) which prevented some developers from selling through the App Store. Other developers found the effort too complicated, and reduced their interaction with their customers, and so abandoned it. Even so, the world for Mac software was changed. Prices had come down and they were not going back up just because an app was not in the App Store.

Loss of Marketing Avenues

In the old days there were magazines and web sites focused on the Mac, but even the web sites slowly started shutting down. Back in 1997, MacUser magazine in the US merged into MacWorld Magazine. MacWorld shut down its printed magazine in 2014. MacUser UK closed down its magazine in 2015. The MacMinute web site, a popular mac news site shut down in 2008 after the death of its owner., the web site of MacLife magazine merged into the generic TechRadar site in 2015. Is there still a magazine? I have no idea. MacNN, another popular Mac news site shut down in 2016.


In 2006, a new style of software marketing was introduced – the bundle. MacHeist pioneered this marketing scheme, where multiple software products were bundled together and sold for a low price. The site gamified the process, adding challenges that could get the user additional software. The site also raised money for charity at the same time.

The original MacHeist in December 2006

Controversial at the time, since relatively little money went to the developers themselves, the developers looked at it a bit differently. They looked at it as a way to gain new customers, who they would get more money from through future upgrades. MacHeist marketing its bundle as a limited time event, generating lots of sales over a short period of time. This model was copied by many other companies, generating all kinds of bundle sites such as BundleHunt, BundleFox, StackSocial, FairBundle, and more. Many sites came and went, such as Bundleecious, MacBundleBox, TheMacBundles, etc. How many bundle sites could operate at the same time?

Deal Sites

Another variation on the short-term deal are the individual deal sites. They offer a discount on one or more apps separately for a day or a week. Some sites of note include MacZOT and MacUpdate Promos, which is a directory of Mac software that also offer deals on a regular basis.

MacZot today

Besides the lack of immediate payback from bundle sites, another downside is that it precludes selling through the Mac App Store. Of course, not every developer wants to sell through the Mac App Store, but if you could properly promote your app, even at a big discount, it would help your rankings in the store, and make your app more visible, which would bring in more sales, etc. A beneficial cycle. One site that targets this opportunity is Two Dollar Tuesday, a site that promotes discounts on apps, but which sends you to the Mac App Store to make those purchases.

Two Dollar Tuesday today

Two Dollar Tuesday markets the discount (if an app is normally $9.99 then they market it as 80% off) to their subscribers and the developer lowers the price of the app in the app store for the period of the discount (up to a week usually). Like MacZot, the site is essentially a large mailing list that allows software publishers to reach a large number of targeted customers. Another site that follows a similar model is MacAppStoreSale.

A Subscription Model

So back to the beta service. The service is called SetApp, and offers a large number of Mac applications (currently 60 and new ones have been added over time) for a set monthly subscription price of $9.99/month. I was sent an invite from a software publisher whose application I’ve already paid for, whose application is one of the applications in the subscription. Of course, that’s a bit of the problem. I already own many of the applications I like in the subscription.

Here are the 61 applications currently in the subscription:

Aeon Timeline Get Backup Pro Permute
Alternote Gifox Pixa
Archiver GoodTask Polarr
Base HazeOver RapidWeaver
Be Focused Home Inventory Remote Mouse
Blogo Hype Renamer
Capto iFlicks Screens
Chronicle Image2icon Shimo
ChronoSync Express iMazing Simon
CleanMyMac iStat Menus Sip
Cloud Outliner iThoughtsX SQLPro Studio
CodeRunner Jump Desktop Squash
Disk Drill Lacona Studies
Downie Manuscripts TaskPaper
Elmedia Player Marked Timing
Findings MoneyWiz Ulysses
Flume My Wonderful Days WiFi Explorer
Focused Numi XMind
Folx Pagico Yummy FTP Pro
Forecast Bar Paste
Gemini PDF Squeezer

The service installs a folder on your hard drive with all the applications, except they’re not really the applications. The first time you launch one of them, it shows a preview of the application with a screenshot and a description, and if you want to use it you then have it installed remotely. The next time you launch the application, it launches normally. It’s a nice solution that both gives you a way to find out about the applications, and removes the need to store applications on your hard drive that you’re not using.

For me, since I already own most of the applications I want to use, I need to calculate if the $120/year is worth it for the applications I don’t own. That depends on how many of those other applications I want to use. Sure, if I subscribe to the service I won’t have to pay upgrade fees for the applications I do own. That requires a more complicated cost/benefit calculation. In general I’m opposed to software subscriptions, such as Adobe Creative Cloud. I particularly don’t like the idea of software stopping to work when I stop paying, and I can’t stand the massive number of Internet calls these subscription apps seem to make back to their servers. Try installing a single Adobe CC app with a network monitoring tool such as Little Snitch, and you’ll be shocked how often and to how many servers that single app tries to phone home.

That’s the case where there are no other options. Adobe gets away with that because there are not many alternatives to many of their applications. There’s nothing yet to indicate that these software publishers are planning to use this subscription as their only means of distribution. I suspect that wouldn’t make sense for most of them. As such, as an additional option, it’s probably a good thing. Someone should probably put together a chart showing the cost of each of these applications, and the upgrade costs over the last few versions, to let someone see if they would be paying over $120/year in upgrade fees on the apps they want.

In a world where many of the most ubiquitous desktop applications are available through the web, such as office suites (Microsoft Office 365 and Google Docs) and photo editors (Adobe Photoshop Express, Fotor, Pixlr), it seems logical that even non-web-based applications would find a way to get into the subscription model. For SetApp, I suppose the big question is does their mix of applications appeal to enough people and provide a big enough payoff to the developers who include their applications in the subscription. The beta ends in March, and it will be interesting to see how many people make the shift to paying $9.99/month. I don’t expect they would be promoting their numbers, at least not right away, but I suppose a good proxy for that information will be if new developers continue to add their apps to the subscription in the months that follow.


Three delayed keyboards (or four future keyboards)

Anyone who has been involved with crowdfunding sites like Kickstarter and IndieGoGo, and particularly those who have backed hardware products, know all about product delays. I’ve written before about how crowdfunding sites are invigorating the hardware startup market, allowing hardware products to reach the market that would never have done so in the past. The flip side is of course that not all the hardware products that receive crowdfunding do in fact reach the market.

Many crowdfunded products have famously failed, such as the Eyez by ZionEyez HD video recording glasses whose principles seemed to simply disappear off the face of the planet without delivering any products (and it’s unclear if they ever worked on their product at all). That case was covered by Forbes and Network World, although it only raises about $350,000. More recently Kickstarter has made it harder for pie-in-the-sky hardware ideas to make it onto the site. One interesting case was the Skarp Laser Razor, which raised over $4 Million on Kickstarter before the site suspended their campaign. The company quickly switched to IndieGoGo and raised over $450,000. Whether Kickstarter was right and the project ultimately fails remains to be seen.

A product doesn’t need to be crowdfunded to be a colossal failure. The Gizmondo handheld gaming console built up a lot of hype before flaming out fast once they launched. I suppose it’s good they at least launched, although it was apparently the worst-selling console of all time, selling less than 25,000 units. The company behind it had apparently burned through $300 Million, most of it in the six months before it declared bankruptcy. In case you were wondering how a company could spend that much money in such a short period of time, you might remember the story of one executive of Gizmondo who the year following the bankruptcy crashed his $2 Million Ferrari Enzo into a poll on the Pacific Coast Highway at such a such speed that he literally split the car in two. It was later found that he had illegally imported over $10 Million worth of sports cars that were being leased in the UK to the US, and then stopped paying the leases.

Now I wanted to look at three keyboards I’ve previously discussed, and see where they fit into this story. I’m not saying these products will fail, and I certainly hope they do not, but some are examples of hardware crowdfunding projects that have been excessively delayed. Two keyboards, the King’s Assembly and the KeyMouse, were crowdfunded. One, the Kinesis Advantage, is an existing keyboard from a longtime keyboard manufacturer, that has been awaiting an update for many years (for example being announced as forthcoming in 2013).

Let’s start with the two crowdfunded keyboards, since they are incredibly similar. Both the King’s Assembly and the KeyMouse are split ergonomic keyboards whose halves can be moved as mice, allowing one to both type and use the mouse without having to ever move your hands off the keyboard. Both raised similar amounts of money (the KA raised just under $240K and the KM raised just over $150K. The KA cost $200 during the campaign (and is currently accepting pre-orders for $320), while the KM cost $299 during the campaign (and is slated to sell for $399 retail). Both keyboards launched their campaigns with non-mechanical key switches, and later updated their designs to support Cherry MX mechanical switches (I suppose if you’re buying a keyboard for $200-300 you expect quality switches). Both companies are beyond their promised ship dates.

The KeyMouse
The KeyMouse

For a long time I suspected the KeyMouse, even though it raised its money later than the King’s Assembly, would ship first. I thought that because the company was out there showing working demonstration hardware of their designs. The KeyMouse was shown at CES 2015 in Las Vegas, and won an Innovation Award at CES 2016, just a few months ago (it was actually announced in November 2015). I didn’t back the KeyMouse, and the updates they’ve posted have been made available only to backers, so it’s not entirely clear what is going on with the product. What I can glean from the comments is that they’ve offered all their backers full refunds, as well as a promise to sell them the final product when released at the same price they paid during the campaign. That seems like a very good way to deal with whatever problem they’re having. Most companies don’t ever offer refunds to Kickstarter campaigns, as it’s not required, and they’ve usually already spent the money. So while I don’t know what happened to cause KM to start offering refunds, it seems a good sign that they’re offering refunds, as it means they’re likely not insolvent. Maybe we’ll see products shipping from them, but don’t hold your breath on seeing it this year.


KA Beta Pair Pic from KS
King’s Assembly 3D-Printed Beta (from the back)

The King’s Assembly has never, to my knowledge, actually shown off its prototypes publicly. Some pictures have been released to backers in updates on Kickstarter, and recently they took orders for what they called Beta keyboards, basically prototypes with 3D-printed plastic parts, that they somehow managed to sell to people for $650 each before the Kickstarter units are ready to ship. I suppose it’s pretty clever getting people to pay for your beta testing hardware. It’s a little galling for some KA backers who paid for two units – a final unit when released, and a pre-production unit earlier. That pre-production unit was supposed to be ready a few months after the campaign ended in April 2014. Those backers, who paid $350 for the privilege of getting an early unit in addition to the final one, don’t get the Beta units. I guess if the money and testing received through the beta program help get the product finished, however, people will be happy to get their products in the end. At this point even the Beta units haven’t shipped yet, although they seem to be in some form of final assembly. Once they get to Beta customers, it will be interesting to see people’s reaction to them. I wonder if Beta customers are restricted from posting photos of the units online. We’ll see what happens when they get into customer hands. Even assuming they get them out soon, and they all work perfectly, I wouldn’t expect a final unit to ship from KA before 2017. If they do get the Beta untis out, it will at least show they’ve managed to manufacture working units in some quantity, although that won’t prove that they can mass-produce the product using the money given them by backers in 2014.

Advantage Pro Keyboard
Kinesis Advantage Pro

Back in 2012, an employee of Kinesis started a thread on the Geekhack keyboard forum about what features people would like to see in a future version of the Kinesis Advantage contoured keyboard. I’ve written about the Advantage before (Why haven’t there been any keyboard innovations in decades? and How I would re-design the Kinesis Advantage keyboard). It’s a great keyboard, and I’ve used one myself on and off for years. The thread on Geekhack is actually still active, and there have been some interesting updates in the past four years. Of note, in early 2013, that same employee said the keyboard could be expected that year. As recently as last week, he was saying no date for the release, although other indications show that it is likely to come out this year (and in response to a tweet I sent them, they responded Q2). In the discussion online, it was revealed that the company only has about a dozen employees, and while the Advantage is the company’s most expensive keyboard, it isn’t the company’s most profitable. They sell many more of their less-expensive split adjustable Freestyle line of keyboards, which they’ve updated more frequently, adding for example Bluetooth support. In addition, they sell a line of foot pedals and other accessories.

Other priorities combined with some design problems has led to this delay now of more than four years. In the scheme of things, however, what’s four years? By my reckoning the last major update to the Advantage line was in 2002, when they introduced USB to the keyboard. That’s fourteen years since the last update. The overall design, however, hasn’t changed since it’s launch in 1996, which is twenty years ago. Twenty years selling the same design is pretty long by any reckoning, although Kinesis’ design is certainly modeled, at least in part, on the original Maltron keyboard that was designed in 1976 – so one could argue it’s a forty year old design. I’ve written how I would improve it, although my suggestions from 2014 are mostly functional, not design, changes. One design change that many people have asked for is the ability to split the keyboard into two halves, similar to their Freestyle keyboards. It seems that isn’t in the cards for the update planned this year, but they’ve said it’s not impossible in the future. It’s important to note that while this design update has been delayed, it’s not like the other keyboards which have backers that have put up money for them in advance. Kinesis certainly is under no obligation to update their keyboard, and while many people want an updated version, they’re not financially on the line if Kinesis never updates it.


Keyboardio Model 01
Keyboardio Model 01

I know the title of this post mentions three keyboards, but I’m going to mention one last keyboard because technically it’s not late yet. In fact I’ve mentioned this keyboard in at least two previous posts – A few interesting keyboards, nearly in existence… and The rise of hardware startups – thank you crowdfunding. The keyboard is the Keyboardio Model 01, and I’ve been following it for quite a long time. If you look at the two previous posts you can see quite a change in its appearance over time. Part of what has been interesting about this keyboard is how much information was shared about its design long before it was crowdfunded on Kickstarter. What started out as an, I guess obsession is not too strong a word, for its designer Jesse Vincent, has been shared all along the way. Jesse started by documenting his keyboard on his blog, as well is in keyboard forums. He went through many many prototypes, and landed in a hardware incubator called Highway1, where he further refined the design. Finally, after years of work, sharing his trials and errors, and even his code, he launched a crowdfunding campaign on Kickstarter.

The campaign was actually quite simple for a crowdfunding campaign. No stretch goals or other oddities. The keyboard was sold for $299. A $999 limited edition actually sold 11 units, amazing to me (to many people it’s probably harder to believe they sold over a thousand keyboards at $299, but while there are many keyboards available for over $299, I don’t know of too many over $999). The Keyboardio folk did a 25 State road trip during the campaign, driving from coast to coast and showing off the keyboard in various maker spaces. In the end, they raised over $650K, more than both the King’s Assembly and the KeyMouse combined. In addition, while I don’t expect the keyboard to ship by its April 2016 date (see, it’s not late yet), I do expect it to ship well in advance of the other two crowdfunded keyboards. There’s no question in my mind that the Keyboardio Model 01 will ship, and not many months after their original ship date.

One can certainly argue that the King’s Assembly and the KeyMouse are much more complicated than the Keyboardio, and that’s mostly true. The Keyboardio has no pointing device (although it can move the mouse position using keys), it doesn’t move, it has many fewer parts, less keys, etc. However, it’s clear from looking at the stories of these keyboards that the Keyboardio was planned out well in advance of being crowdfunded, while the other two were only rough prototypes then (and over a year later for both, they essentially still are).

In the end, we have four new keyboard designs all supposed to be released in the coming year. I hope they all make it to production, and sooner rather than later. This is, to some extent, the beginning of a keyboard renaissance, and in large part it’s due to crowdfunding expanding the hardware market (see The rise of hardware startups – thank you crowdfunding). While not all keyboard crowdfunding campaigns have ended well (such as the failed Multi-Touch glass keyboard), it seems that if keyboards like the above can all reach the market it will encourage others to experiment and come up with new keyboard designs. While hardware crowdfunding has almost always been associated with delays, it’s still a major driver of innovation, and I hope we’ll see more products soon (although if you really want to ship stuff on time, I won’t oppose that).