Hi,
I’m a developer. I write software all day, except for when I do my role as scrum master. Then I talk on Skype or write text documents and emails. But most of the time I read and write code. In front of a computer. That is on a desk. In an office. Almost every working day. All day. And I’m actually very happy about it.
However, this is not great for my health. Sitting all day in front of a desk. So I gave up sitting nine months ago and have been standing at my desk since then. However, standing all that time isn’t great either. It’s better, but not great. So I was ready to take the next step: to walk in front of my desk.
Yes, walk. I had heard a lot about this at conferences and read blog posts about it. Yes, I realize replacing one monotonous posture with another isn’t solving everything, but it’s a step, right? And it sounds very interesting, so I ordered a two-week trial today, with the intent of buying an under-the-desk treadmill. This post is my thoughts before trying it out.
There have been a lot of in-betweens, of course. For many years I’ve raised my desk and stood a while and then sat a while. I’ve had issues with my arms when I was younger and had a physiotherapist guide me to good sitting positions where I rest my arms. However, I’m getting older, and my back is noticing this more and more, leading to me using a chiropractor. That’s been quite good, really.
Where I’m at today is that the standing has become harder on my heels and my knees. So I’ve bought shoes that I hoped would relieve part of the stress, and then higher heels when I noticed that I really was standing wrong. I was standing too much on my heels. So I fully expect to have to do the transition gradual, and perhaps need to mix in some sitting again. Just so as not to over-do it, and to let my current aches heal.
I’m wearing an Apple Watch, and my daily average active energy is 717 calories, including 8,7 km walking/running distance and 9.947 steps. My goal, without doing too much research in how feasible this is, is to add 15.000 steps by walking 6 hours a day at 2km per hour, after having used the treadmill for two weeks. I honestly do not know if this is a too ambitious or too low goal. We’ll see.
Also, my goal is to keep using the treadmill for three years. I’m sure the move goals will change once I get settled into the routine, but being committed to this kind of working sounds good to me. Things I will not regard as breaking my plan is walk-and-talk meetings, travel days when visiting customers, and attending conferences. Also I have no plans to change my weekends and holidays, since this should already be impacting the majority of my days. But it’ll be interesting to see if there will be some spillover effects.
This is the sixth and final installment of the behind-the-app series, showing the making of Well Tempered version 2.0.
Marketing and launch
When Well Tempered was first launched back in early 2009, the way I had understood the app store proposal was this: Apple would host and market my app, and take 30% of the sales. Boy was I wrong. The app store was never a marketing tool, and very few apps are promoted by Apple at all.
With version 2.0 coming up, I knew I could not expect Apple to do my marketing. Also, since this was not a new product, but an update, it would be a hard sell to get peoples attention. So this looked like an up-hill battle.
Many people will tell you that you should think of the marketing both before you start making the product and all the way through your development. I had been thinking very much of the user experience, and to me the marketing I had to do was to communicate this.
So while Well Tempered was finishing the localization job, and I was iterating through versions together with my beta testers, I began approaching bloggers and influential musicians to get them interested and want to tell people about Well Tempered and write about the app.
App marketing, building those relationships, is probably the job I have done least well at during the development of Well Tempered 2.0. Because after all my effort, on launch day and the following days, it was announced in four places. That made for the best sales day in Well Tempered history, and its top placement: 55th grossing app in the music category of the Danish app store for that day.
After the first day, it went downhill, and by the fourth day I was not selling any copies of Well Tempered. This was despite having my marketing material localized in 9 languages, despite having focused on accessibility, despite being a universal app, despite (in my humble opinion) being the best tuner out of the many tuners I had tried in the app store, and despite supporting the latest iOS technologies, including the Apple Watch. My marketing strategy needed a new angle.
So far, I had been focused on making the best tuner, especially for early music players, but also running it by rock and jazz musicians to make sure it worked well for them. I had reached out to 60 or so bloggers, members of early music societies, conservatory teachers and people I thought have an influence on people. Surely, having made Well Tempered really well would make them like it and tell people about it?
Well, some reported publicly about it and told me about a bit of the feedback they got from others. But for the most part, they never installed Well Tempered themselves. Apparently I could not get them excited enough to tap the link so that they could redeem their free copy and try it out. This part really surprised me, and going forward I think I will need to work at this slowly and steadily, so that for future updates, at least they will want to try it out.
I decided to try advertising. Advertising is one of these things I see every day, yet haven’t tried much myself. I ended up trying Facebook, since there I could target very specifically whom I wanted to reach. So I made an advertisement for my app where I included my video, and let it run for a week. The demographic was very narrowly defined to harpsichord players in English-speaking countries. The result after a week was depressing: I had seen no new sales. 1010 people had seen it on average 1,9 times, and 12 of them had bothered to play the video and 3 had decided to tap “like” on it. At the very end of the campaign Facebook told me it could be credited for one sale - but with no sales in that period, that was incorrect.
So now I had two failed strategies, and close to no downloads from people who found it in the App Store. The last point is no wonder, if you search for instrument tuner or chromatic tuner, chances are you won’t even find it, at least not for the first 15 pages of apps! I’ll need to do some research into how to rank better there, but this just confirmed my first point in this installment, I can’t expect the App Store to do the marketing for me.
For my third alternative, I tried giving away as many copies as I could, hoping, like I had at first, to generate some more awareness of the app, that people would talk about it. Also, I started posting more about Well Tempered in relevant Facebook groups. I was super-nervous about this: since I did not want to come across as spammy, I made sure to post in just one or two groups every other day or so, and be careful to follow up on comments I would get in those groups.
This actually turned out quite well: I would get a nice spike in my sales, and people were interested, asking questions and “liking” my post. This also led to a lot of support requests coming in as personal Facebook messages. I had not been expecting this amount of a support burden on an overall small amount of sales, but oh well, I would not let my customers down.
While most of the support was easy to help out with, a few of the comments I did get back were really helpful to make Well Tempered better. I was already in the process of making version 2.1, but the support messages gave me an attention to choices I had made that perhaps were not the best ones after all. And this was issues that I would have expected to be alerted about in the beta testing stage, so I must admit I was a bit embarrassed when I discovered they had a point. So version 2.1 will hopefully relieve most of their concerns.
This taught me a lesson about marketing apps that I don’t think I have heard before: even though I’m working on issues that I’m embarrassed about in the current version, I should not stop marketing the current version. I know the updates are coming, and all customers will get the improved version for free. Most of the new customers will not notice the issues I’m improving, and like the tuner. For those who do, well, an update is under way. So even though I was working on version 2.1, I continued to post to different Facebook groups.
And now we have reached today, but absolutely not the end of the journey. Well Tempered 2.1 is under way, and parallel to that I’m working on an update for iOS 9. And I’ll do my best to blog about it, so you can follow along on my journey. Thank you for having followed my series, and do contact me for any questions - I’ll do my best to blog my answer. :-)
Full index:
This is the fifth installment of the behind-the-app series, showing the making of Well Tempered version 2.0.
Localization
If you care about your instrument being in tune, and in tune being a tuning system that compliments your music, I really think you should use Well Tempered. That’s why I made the decision to localize Well Tempered so that it would be native to at least 70% of people with an iPhone or iPad, and then the second language to most of the rest. I thus localized the application to English, French, German, Spanish, Italian, Russian, Chinese, Japanese and Korean.
Thinking about localization, I found two really hard questions:
Starting off with the name, Well Tempered could be thought of as a brand name. If a French speaking person reads a review on an English blog and wants to try it out, I really want that person to find Well Tempered. Calling it Bien Tempéré would make that harder.
Then again, the name is based on Bach’s Well-Tempered Clavier, and that name already has a translation to French: le Clavier bien tempéré. And of course, the English name is a translation from German: Das Wohltemperierte Klavier. Keeping the enlighs translated name in German seemed absurd. In other languages, such as Korean, I was told by the translators they would use the English name. So I ended up with a mix: in some languages I kept the name, and in some languages it was translated. I was curious to see what difference it would make.
The data in my app is temperament names and temperament calculations. I was curious whether I should translate all the names, but since I had so many temperaments, where some perhaps had appropriate translations and some did not, I chose not to translate them. I have yet to get any feedback on this from my users, so the question still stands.
Apart from these questions, the translation process was smooth enough. I used Tethras that I already have a good relation with, and I think the level of service I got was excellent compared to the price I paid. After that I wanted to use my network to get musicians who had that language as their native tongue to look over the end product. This didn’t go very well as I still miss hearing back from most people that I asked. If something is amiss in a language, I expect I will hear about it.
Accessibility
I have been impressed by how much effort Apple has put into making iOS accessible to people with disabilities. With them making it so easy to make my app accessible, it was only natural for me to implement this for Well Tempered. Not only would I make sure it was accessible, but I would also make sure the accessibility labels were localized the same languages as the interface in general.
Unfortunately, I was not able to get people with disabilities in my test group - I would really have liked to have more input on this. So I ended up testing it myself, and I shipped something I was happy with for the languages I understand. I really hope to hear back from users with disabilities, preferably in many languages.
Testing
A side benefit of making Well Tempered accessible, is that this makes it more easy to make automated tests for it. I have earlier used Calabash a great deal, but for this project I wanted to use UI automation, since I wanted also to use it to prepare my screenshots for the App Store. I had found that I could use snapshot from fastlane.tools to take screenshot based on my UI tests.
If you have ever used UI automation, you’re probably rolling your eyes now, and you would not be surprised to know that this was my biggest mistake. I would make my scripts, and spend a good time making those scripts since I got no feedback from the editor. Not a good experience at all. While working on the script it would lock up midway, and after finishing it, it would not reliably run again. Some runs it would not complete, some it would only take black images.
So instead of getting frustrated and wasting time, I should have made real tests and used that to take images. I would explore going back to Calabash every now and then, but I didn’t get how to change the language of Calabash and how I should write my scripts for an app where also the accessibility was localized, so in the end I ended up without UI tests.
Well, in the end is perhaps overstating it, a little while later Apple released UI testing with iOS 9 and Xcode, so this is what I will be using now. It even allows me to test with localized accessibility labels. :-) And Felix who is behind fastlane.tools is already working on UI testing and screenshots for snapshot. I had a bit of an issue about how to launch my app in different languages, but that has been solved now, so I can build my comprehensive test set that I hopefully can reuse for the UI testing.
Thanks for following me this far. In installment six I’ll cover the launch of version 2.0, and talk about app marketing. Stay tuned!
Full index:
Apple Music was released today, and just like the entire internet west of Androidia, I updated my devices so I could try it out. Here are my initial impressions. They will surely be moderated with time.
Getting started was easy. That’s great. And browsing through the music catalog is very nicely designed. Unfortunately, the first tracks I browsed to were broken. Not because of something Apple did, but because the publisher didn’t pay enough attention when he ripped the CD!. Long story… I know the guy… but I wish Apple would have some algorithm in store to detect these weird anomalies.
I had heared good things about “For You”, so I fired it up. I like baroque music. That is what I want it to find. So I got the circles, and the closest match was Classical. Ok, double tap on that and Next. Then my only choice was Bach. Really?! Oh, there’s a “More artists” button (Artists? You mean composers, right?), and that got me one more: Vivaldi. But it insists I had to choose three. And there were no more baroque composers to choose from. Also no renaissance, early 16th century or even Rococco. Bah. So I chose Beethoven. I don’t plan to listen to much Beethoven. Nothing against the guy, but I wanted to listen to baroque music.
So I hit done, and for the first screen there is absolutely nothing that is classical music! Also nothing for the second screen, and by the end of the third screen there’s Brahms. Really? He’s no baroque composer. Fourth screen, nothing classical ethere either. And at the end of the fifth screen, there’s Beethoven. I guess “For You” is not for me. Apple Music has a lot of great baroque music. But it lacks discovery of this at the moment. I look forward to it being added.
Implementation
This is the fourth installment of the behind-the-app series, showing the making of Well Tempered version 2.0.
In Well Tempered 1.0 I explained how Well Tempered got to be an iPhone app. For version 2.0 I wanted to make sure I integrate with all relevant parts of the iOS ecosystem. That meant implementing it so it would work well on all iPhone sizes and on the iPads, and if it made sense, also integrating the Apple Watch.
Version 1.0 had been compatible with the original iPhone, but keeping compability is expensive. So for version 2.0 I gave myself a clean slate, and set the current platform, iOS 8, as a base line.
I chose to make the app universal, meaning that it would support any iOS formfactor. While working with AutoLayout, I have not used size classes, preferring to have the UI shrink and grow and only change a little bit to accommodate the different sizes. I think this worked well for the different iPhone sizes, while there is perhaps still a little bit too much free room on the iPad.
An important part when designing an application is finding its logical units, and how they will compose. Up front it was important to me that defining your temperament should all be done on the main screen. So the topmost part of the screen was designed for that, leaving the bottom part to either the pitch pipe or the tuner. To make this modular, I implemented this as two view controllers within one main view controller. I must admit I am surprised on how non-trivial this was, or how hard AutoLayout would make this for me - especially if I wanted to recompose during rotation. I trust, though, that stack views in iOS 9 will do much to relieve the pain experienced there.
I chose to write my entire application in Swift. This was at a point in time when Swift 1.2 had just come into beta, and CocoaPods support for Swift was not entirely complete. My first patches for AudioKit were thus support for CocoaPods, and bug reports to Apple about the upcoming Xcode 6.2.
Using Swift is of course not only about changing the syntax of one language to write Cocoa in to another. With Swift came new concepts - or rather, concepts that I got to use more than what I was used to. Three to mention in particular are value types, protocol oriented programming and functional programming.
My interest in value types came out of Andy Matuschaks presentation at Realm. In short, it is about using structs instead of classes to store model data, thus letting data be just data. I thought this would be especially beneficial when implementing state restoration, something I view as an important part of being a good iOS citizen, yet something that many app developers find too complex in their apps and choose to neglect. I discovered, though, that I had to serialize them myself, having no good JSON or plist serializer at hand. However, I think my work paid off well when it came time to pass the application state to my Apple Watch companion app, and I learned a lot. I expect I’ll be encapsulating all my model data in structs rather than classes for the next few years.
I also found it really nice to encapsulate my model functions together with my structs, as well as having my structs conform to different protocols. Apple described this later, at WWDC 2015, as protocol oriented programming. That, btw, was a really good video, and you should see it. Thereafter, of course, you should read Crustys reply.
Functional programming, while not new to me, is much more natural to embed into my code when writing Swift than writing Objective C.
Finally, I thought I should write an Apple Watch extention to be able to remote control the application. I did this while reviewing Pearson publishing’s Learning WatchKit Programming book my Wei-Meng Lee. His book about WatchKit 1.0 is a brilliant starters guide. When I finally got an Apple Watch to try it out on, I was surprised by the speed of it - or rather the lack thereof. It had been intentionally slow on the simulator, and I was expecting Apple to have overdone the slowness. I did not expect that the real-life experience of the app would be even slower. Or rather, that the communication between the app UI and the app extension would be as slow as it was. I am definitely looking forward to reworking the Apple Watch companion as a watchOS 2.0 app.
In the next installment, I’ll talk more about implementation, and in particular the implementation of Localization and Accessibility.
Full index:
Follow Me
Follow me online and join a conversation