Other than big changes in how the app navigation was implemented (the current single scrollable view vs. the previous one with multiple independent views; I also tried different input modes based on the orientation of the remote), 1.0 did not gain new features compared to that initial AppLovin prototype. The prototype even had a preview of something that had to wait for the first update: As tvOS does not support EventKit and has therefor no access to calendar data, I developed a companion app for iOS that would allow to export phone/tablet calendars and sync them via iCloud. I waited with this feature mainly to see if the app itself would pass the app review process, after which I felt free to increase the complexity.
Update 1.2 became a bigger piece of work. Intended to only add a reminder to the Top Shelf items, I discovered that the memory problems I was able to circumnavigate before, reappeared with the tvOS 10.2 beta. While waiting for Apple to answer my question whether this could be a problem only observable with the beta, I started working on the next feature: custom images. As with the calendar sync or the new reminder feature, the companion app plays a major role for custom images. While it is possible to access the iCloud photo library from Apple TV, choosing and cropping images so that they fit the calendar format is much easier on iOS devices. So that’s where you can now select up to 12 images of your own.
As for the memory problem: I had to wait until the official release of 10.2 to find out that yes, extensions now seem to have less memory available to them. So for version 1.1 this meant that the Top Shelf extension would run into memory errors, resulting in everything resetting after the first item was generated. So the weather forecast and quote of the day item would never appear. I had been working on fixing this bug ever since I contacted Apple about it, but it still took me more than a week after 10.2 went public to finally fix it. Hope I did not loose too many users because of this.. Will have to see how 11.0 turns out in this regard.
Top Shelf Calendar
As I was one of the fortunate to win an Apple TV developer kit, I started working on ideas all the way back in September of 2015. As everybody was criticizing the text input (and as I can't help myself), I immediately tried to think of alternative keyboard designs. But as keyboard extensions were/are not allowed, I needed an app to implement the keyboard in. For some un-remembered reasons, I ended up choosing to develop a calendar app.
And while I had a working concept, once Apple implemented dictation and updated the iOS Remote app, it felt like too much hassle to force an alternative input method on the users.
At the same time, I became quite interested in the Top Shelf feature and explored what could be done in that space.
My basic concept was to create a TV pendant of classic wall calendars usually hung at home or in the office, but instead with some dynamic elements and - of course - living on the Top Shelf.
The Apple TV Tech Talk in January of 2016 could not have been timed better (or located more conveniently right here in Berlin). I had a problem when trying to update Top Shelf items and one of the engineers on site could point me in the right direction.
Next big milestone was the AppLovin Apple TV App Challenge or rather finishing a prototype to participate in it. Some troubles with the memory limitations of tvOS extensions made hitting the deadline of March 31st a challenge of its own, but I was able deliver a first version. While I did not win, having a deadline to get to a working state was quite helpful.
That initial prototype version still had to hibernate for some time, though, as I became a father on April 19th, reducing the time for spare-time projects to.. well.. zero.
1.0 hit the App Store February 20th, 2017. Here the initial (and current) app preview video
My initial driver to develop an iPad keyboard was to allow users to not have to look at the keys in search for the next letter. Thus, the eight button design was born. One button for each pinky, pointer, ring and middle finger. With that design, the user is supposed to place each finger above the buttons once and then just tap with the one/ones corresponding to the current letter. While it works fine, holding the hands still or getting them into the correct position to be able to hit the buttons can be challenging. So I kept looking for a better way to achieve my goal. During a WWDC presentation, a blind Apple engineer demonstrated some accessibility features and while I watched him orient his fingers on the iPad he was using I realised that this needed to be my goal: The keyboard should be designed with blind people in mind.
So with ‘Zwei’, I reduced the number of buttons to two (Zwei is the German word for 2), each spanning half of the screen’s width. Based on the number of fingers used to press one of these buttons, the user is presented with 5 characters. The first gets entered by simply releasing the button. Each of the remaining can be selected through a swipe gesture (up, down, left or right). In addition, while pressing the first button, the second button offers two functions that can be activated by tapping it with either one or two fingers. Examples for these functions are changing the input mode to upper chase letters, to delete the last character or the obligatory switching to the next keyboard.
Again, I think the app preview video will explain it much better
When the accessibility feature “Voice Over” is activated, the two buttons increase their height to half the screen as well. Characters are read out once selected and a confirmation sound is played when the character is chosen. I implemented this in contrast to the standard settings which announces the letter twice: once the button is touched and once the current button is released.
As you can see on the App Store, 'Shift' was actually published after the keyboard I will write about next. At the time, the other concept was just much more compelling to me, so I put this project on hold for a bit. As I started working on it beforehand, though, this order shall reflect that fact.
The concept behind 'Ahto' was to use up to three fingers in parallel on an eight button keyboard to enter specific characters.
For 'Shift', I kept the eight buttons (one for each pinky, pointer, ring and middle finger) but decided to give each one a modifier role. So if the user holds down on one button, the other seven get assigned specific characters based on that first button. The user can either release the first finger or tap one of the remaining buttons, each of which will enter a character (or perform a function). I designed the keyboard so that the one finger "tap and release" leads to common letters like 'a', 'e' or 'i' while entering e.g. the letter 'l' requires to hold down the forth button from the left and then tap the second one from the right. I think a preview video might be good at this point
As for the name:
I thought 'Shift' would be a good one as the shift key is the most commonly used modifier key. Everybody knows how it works and I hope it helps to get across the general idea. What I did not check in advance was whether there were any other apps with that name, much less keyboard extensions. Which - of course - there are. For a long time, there was a controversy regarding how Apple implemented the shift function. Some developers took it to themselves to provide alternatives and named their apps accordingly. So far, I stayed with my initial choice. But what to you think, is 'Alt' a better fit?
What also made the name a rushed decision was the easy path to the current icon
Visual design still not being my strong suit, I was desperately looking for something to use for the icon. With 'Shift' as the name, there was an easy answer, so I just went with it.
What motivated me to get back to this keyboard after I initially stopped working on it was the fact that the modifier concept allowed me to use 8 * 8 key combinations. As you can see, I used this for some bigrams i.e. two letter sequences that are common for the chosen language. Using 'Shift' for letters other than the 6 "direct tap" ones involves two buttons. The bigrams help to decrease the "taps per letter" ration below two.
Long time, no update
As it turns out "having a blog" is not motivation enough to actually publish something. At least not for me. While I have been working on projects I could have written about here, I tend to get lost in the development process (which I love) and ignore doing something about the outreach (which is just not my forte). It is not that I ignore this completely. I start formulating texts that float around in my head. But that is usually where they stay.
So let me do some catch up, now, and try to get out stuff closer to the related work, in the future.
I just checked, the last entry is from August of 2015.
Other than becoming a father since then, I also published some.. keyboards, of course. Two to be exact. I also dabbled in some tvOS development.
Swift is still my language of choice. My only choice really as I am still not fluent in Objective C but want to stay in the Apple ecosystem.
While reading up on the T9 text entry method on Wikipedia, I came across "chorded keyboards".
Even though it happens quite often, I keep being startled when I work on an idea for some time only to stumble upon someone who had the same idea.
Not that I am disappointed about not being the first. I am amazed how people come up with similar stuff.
Back to chorded keyboards..
Well, the naming is probably the reason I didn't find it, before. Still seems strange. Says the guy not playing any instrument.. And not that Ahto is any better.
The guy who introduced chorded keyboards was named Douglas Engelbart. In his initial design he used five keys valued 1,2,4,8 and 16. So powers of two.. Much like I tried in version 1.0, Engelbart used binary counting to go through the alphabet. Later designs (of course) tried different layouts (-;
There even seems to be some studies on chorded keyboards being faster than QWERTY keyboards. Will have to look into that.
Update and Promo Game are out
App Preview, Version 2.0
I am currently working on a major update that will include changing from the classic QWERTY layout to one based on the alphabetical order.
While 1.1 was already quite a departure from the initial version, I kept the name "Binary Keyboard" even though the visible binary counting (compare video for 1.0) was only happening in the background. This is still the case for the upcoming version (each major key corresponds to a power of 2), but I wanted to use this opportunity to change the name, as well.
Additionally, I think there was some confusion for people when reading "Binary Keyboard": There is this joke-keyboard out there with just two keys. One key for "1" and the other for "0". Binary, I get it, but not what I had in mind.
So, a new name..
The title gave it away,
With the change in layout, I also wanted to update the app icon. Above the old (left) next to the new (right).
Being as far away from having a feeling for design as humanly possible, I could never think of something when trying to envision the icon. That is why I ended up using my name, entered with Binary Keyboard version 1.0.
The redesign in layout luckily forced me to try it one more time and I think the new one is much better.
What do you think?
App preview, version 1.1
What a difference a month makes:
After quite some testing with version 1.0, I decided to completely redo the layout. The new one is based on classic keyboards, which will hopefully make the transition/learning process much easier.
The new version also just requires a maximum of three buttons to be pressed at the same time for letters, numbers or punctuation (while "space", "backspace" and "enter" need four).
Putting the iPad in portrait mode will add four additional "in-between" buttons which, when tapped, select the main buttons to their respective left and right. With these, a maximum of two fingers (probably your thumbs) is enough to type a character.
this is version 1.0 of my new iPad app/keyboard extension Binary Keyboard.
The basic motivation behind Binary keyboard is to provide a keyboard where the user does not have to move his/her fingers to enter different keys. Binary Keyboard provides one button for each ring, middle and index finger, plus a toggle for each pinky. Instead of moving, each finger has to be either lowered or raised to touch the screen or not. Multiple fingers have to be combined to enter different characters. Just have a look at the video above.
As I recorded the video outside the container app, I was not allowed to upload it as app preview. So I decided to put it on this page.
Hope you like it.
My name is André Nicolai, I am a software developer living in Berlin, Germany. While I mostly work with C# and Unity 3D during my day job, I have been developing apps with Swift in my space-time, ever since it was introduced in 2014. I am notoriously bad at blogging, but I will try to keep this page up to date with the projects I am working on.