Dan Bricklin's Web Site: www.bricklin.com
Home Writings	How Alpha WatchBench Came About The story behind the WatchBench iOS app for doing Apple Watch development using JavaScript on an iPhone. < Rethinking Forms in the Age of Tablets and Amazon S3    How Alpha Anywhere supports offline mobile apps >
	I've released a new app to the Apple App Store. It's WatchBench from Alpha Software. I did this as part of my role as CTO at Alpha. You can read about what it is on www.alphasoftware.com/watchbench. I've also embedded a video at the end of this blog post. This is the story about how it came about. I've been intrigued by the wearables area for some time. I've worn a FitBit for a long time (going through two of them -- they do get lost, dropped and ridden over in parking lots, etc.). It made me much more aware (in a positive way) of my activity throughout the day and the value of simple gamification. (I also took Kevin Werbach's wonderful MOOC about Gamification after starting to use it.) When Apple announced Apple Watch in September 2014, I was intrigued. I went over the video a few times, especially the part where Kevin Lynch demoed the UI. It was clear to me that Apple put a lot of effort into this and that this would eventually be a very fertile platform for development. It was also clear that it would be a long time before I got my hands on one. One thing I saw, though, is that I needed to learn about this new type of platform, and I couldn't just do it by thinking about what it would be like. This was going to be different than the handheld devices I had been concentrating on for the last few years. Just like the iPad was clearly different than "a big iPod touch", the Apple Watch was going to be different than a tiny iPhone on your wrist. After a few friends sung the praises of their Pebble watches, and finding the Pebble Steel good-looking enough and small enough for me (I have a small wrist) as well as being compatible with the iPhone I carried, I bought a Pebble Steel and wore it continually from the end of September 2014 until just a few weeks ago. I wrote a simple demo app in Alpha Anywhere with PhoneGap to show how Alpha Anywhere can make notifications that show up on it and explained to Alpha users how wearables could be important for internal business use in the future. I like the Pebble, and it convinced me that the watch form-factor could be helpful to at least me personally for uses like date/time, timers & stopwatches, alerts, integration with phone apps, etc. It was more useful to me in daily life than the plain watches I had worn before, and not too geeky looking. When Microsoft announced their Microsoft Band, it looked like another way to learn about this new space. I had listened to a podcast by David Smith and read one of his blog posts, and agreed with him that using a Microsoft Band was a good way to get into this world. It had a touch display, could be worn separately from my Pebble, could be used for fitness stuff including running, and worked with my iPhone. It was much trouble to get one (they were in short supply) but I finally bought one in December, and wore it daily until just recently. While it was not very comfortable to wear, after a few weeks I got used to it. (You can see I'm dedicated to learning here -- it was very uncomfortable at first.) Using these two powerful wearables has been very helpful. I could compare and contrast different UI implementations. I had some baselines to compare other devices, including the upcoming one from Apple. I knew what I actually continued to use repeatedly or just appreciate after months, and what I ignored or was bothered by. David Smith has been kind enough to document his journey learning about Apple Watch and the WatchKit development environment that Apple released in late 2014. In February, following one of his tutorials, I tried writing a simple app that would run in the simulator (there were no Apple Watches available to normal developers at that point). It wasn't too hard. (Thanks, David!) In March, I figured out what I wanted to build: An app that would let me do prototyping in JavaScript that would interface with WatchKit to do some of what Apple was giving us access to. Talking with others, I had a few target applications, such as "How many orders have we gotten so far today?" or "Check off this item on a list". I spent several days trying out different parts of the technology I'd have to use. I delved into using the "hidden" attribute of visible user interface objects to let me give the user of my app the ability to build different UI configurations. I tried displaying dynamic lists. I tried loading data from a remote server. I experimented with the iOS WebKit JavaScript environment. I had used it before a bit, but did just some simple communication with native code. This time I got further into the details. I had just finished some important work (in JavaScript) for Alpha's Alpha Anywhere system. We were on target building new capabilities to help developers build powerful mobile tablet apps that replace clipboards and paper. We made the decision that being early on Apple Watch with an app that would be helpful to corporate mobile architects would be a good thing for Alpha. Wearables was a hot area, and those architects would need to experiment to see how it applied to their company, even if only to say "not yet" or "just for this one use". Normal app development was probably too expensive here. A simple app like mine that let them experiment without needing iOS development expertise would be of interest not just to our current customers, but also to people who were not already familiar with our company nor our products. This could be a way to show them how Alpha has their interests in mind with a product they could use no matter what type of development system they were using. It would be a different type of PR vehicle than the normal "Alpha Software, who you haven't heard of, has yet another new feature in its development system, which you also haven't heard of" announcement. We could use it as a vehicle to talk about wearables in the enterprise, how they relate to tablets and other mobile devices, etc. "Thought-leadership" based on real experience and a real product is a good way to create visibility. We were already getting this through our podcast series, Adventures in Alpha Land, which had some really good interviews of general interest to business software developers. Once I had enough of the basic technology working in a test app, I started writing the "real" app in late March. I used much of what I've learned over the years with building other iOS apps to get my code up to speed (including using lots of tried-and-true code I had written), though this was the first Objective-C app I had built that didn't use manual retain/release memory management, among other "newer" capabilities. (I did not think this was the time to switch to the Swift language yet -- I had too many new things already to deal with and using Objective-C made it easier for me to draw on my old, working code.) We, at Alpha, also started coming up with a name. We settled on WatchBench. It gave the right feel for something you build on that is related to a smartwatch. There were almost no hits on the term on Google nor were there any iOS apps with that name. We didn't need the domain since this was just one of Alpha's products. Until the Apple Watch shipped, I could only test on the Mac Xcode simulator that Apple provides. I didn't try signing up for testing in California at Apple's lab at first since I didn't know when I'd have working code, and spending time flying across the country to test too early would be a waste of time. By the time I had something solid enough, all of the time slots were gone. (In hindsight, the one day you get would not have been enough.) As the day approached when you could order an Apple Watch, I was getting close to something solid. I woke up just before 3 AM (12 midnight Apple-time) to order some watches: One for me (a Space Gray 38mm Sport), one for my wife (a green 38mm Sport), and one for Alpha (a 42mm to let me test both screen sizes and to lend to others in the organization). I wanted one for my wife so I could experience the new types of personal communication Apple Watch provided that only worked when both sides of a conversation had one. (I couldn't see learning that from test messages to co-workers.) Luckily for me, my wife had chosen the green. When I went to order (I had some Wifi issues at the hotel where we were staying that night), the 38mm I wanted was only available for delivery a few weeks after the first ship date. However, when I tried the green, it was unpopular enough that I could still get it on first ship (in both 38mm and 42mm), even though it was already a few minutes after 3 AM. (My confirmation emails from Apple were time stamped at about 3:10am.) My wife would have to wait to try it until my Space Gray arrived. (She was in no hurry anyway.) I really hoped that I'd have everything ready before the watches were shipped so I could submit the app to Apple and be available in the Apple App Store on day one and get a PR boost. But that was not to be. WatchBench had too many parts. It needed documentation, it needed sample apps, and it needed to be easy to use. I worked on the app continually, losing lots of sleep, exercise, and other work. I worked with my daughter Adina, my UI designer, who came up with a much better design than I had started with. It became clear that incorporating her design would make the app easier to use and learn, but that took up more development time. (This all, of course, is not unusual for a new project.)  When the first watches arrived, I quickly did a test. My app pretty much worked! There were a few issues that would take a few days to work out, but the basic system worked fine on a real watch. However, there was much tuning to do, and lots of documentation. Before the end of the first 7 days with Apple Watch I had the complete app working, two sample applications running, and the start of the documentation (it has a pretty full API that it provides to the user). I set up my camera and recorded a video for internal use showing the whole thing working. I could use that to explain to others what I had been envisioning all this time. However, it would be many days before I finished the documentation, basic support web site, and all the things you need to submit a full app to the App Store. One thing that I had to do was decide the configuration of items visible on the screen. I had put off this choice until I had a real watch in hand and got to see how a designer might use it. The initial design of Apple's WatchKit is such that I had to fix these choices in my app, and then my users would be stuck with them, limiting what designs they could implement. The only runtime option was hiding unused items, as well as changing some basic color and size attributes.  Adina, under time pressure from me, worked out a visual design for my main sample app. I used that as a guide for the basis of some of the template pages, adding other items that you might want instead or in addition. I also looked to other apps pre-loaded on Apple Watch by Apple to get some idea of the types of table row layouts I needed to provide. This was a stressful exercise. I wanted to enable as many different types of apps and designs as possible, but I didn't want so many options that it would be confusing nor take too long to document. There was also the question of whether I'd end up with a sluggish app if there were too many options. Since I was probably only going to get one chance to get some publicity about this app, and first experience with it would be key, the bar for documentation, default values, etc., was high. The way Apple Watch interfaces to an iPhone, on a technical level, is not something people would already understand unless they were already a WatchKit developer (in which case they had less need for my app). It is not like what most people are used to for plain smartphone apps. I really wanted the chances to be high that a good JavaScript programmer could quickly build something with WatchBench and feel they would be able to build more. That drove lots more crafting of the "whole product": Documentation, videos, samples -- everything feels into this. Luckily, over those next many days, no one else came out with anything else like WatchBench. It looked like it would be the first app you could use on an iPhone to build something with buttons, lists, etc., that would run on a paired Apple Watch using JavaScript. Also, I quickly realized that many of our target developers didn't yet have an Apple Watch. It would still be there when most of the potential market first needed it. Two and a half weeks after I got my first Apple Watch, I submitted WatchBench to the Apple App Store. As usual, it took many days for Apple to start reviewing it, and then, unusual for me, many days more for it to be approved. During that time, I worked on improving the on-line documentation and support. I recorded some videos and improved the sample apps. It was everything I had hoped as a product. It's not every time that your vision for a complete product comes to fruition. This time, though, it had all of the parts I had decided were needed at the start, and felt complete. Finally, on June 4, 2015, it was approved and I released it to the Apple App Store. Here's the video: Video of Alpha WatchBench on YouTube -Dan Bricklin, 4 June 2015
	Writings  Home  < Previous  Next > © Copyright 1999-2018 by Daniel Bricklin All Rights Reserved.