How it Works:
Each team attempts to play a secret song on the provided keyboard (via a simple play-by-numbers music score). The player gets no indication towards the timing or rhythm of the song, just the notes. The team must figure out what the name of the song is before the 30 second timer runs out.
Updates/Feedback
First time use of app user is very confused as to what to do next. Usually they click solo first, and skip over instructions.
Potential Solutions: A intro screen and walk through of the game would be helpful. Though that could be skipped too. So offering an “easy” version of the game that grows in complexity over time may be more helpful. e.g. less keys, keys to play light up etc
Note: Users wanted to keep the keyboard as the point of interaction.
Even when the instruction are read there is a lot of confusion on how the workflow of the game works. This was expected as Jackie and I even got confused playing it ourselves. Just didn’t have ideas yet.
Potential Solutions: One user used the game in a way that gave me an idea. Before I thought the lack of providing a rhythm would make the game fun, ergot I set it up so the player didn’t know the song name before playing (this add to a very complex workflow).
This user wanted to know the song name they played ahead of time and seemed to have a lot more fun trying to communicate the song name through the keyboard, to the other players. This workflow would be MUCH easier to present and understand. I’m just not sure if it would be too easy. Maybe there are other ways to add complexity over time (per #1)
People who have never played the piano have no idea what “#” means. Though I suspected it wouldn’t matter since all the keys are labeled, it was to much information to digest on a first time use.
Potential Solutions: per #1. A “how to use the kayboard and music sheet” before presenting the keyboard would help. As well as lighting up the keyboard for first time game use.
Keyboard was a bit too small
Potential Solutions: Not sure how I can have many song with few keys. The original keyboard had bigger keys but couldnt get much out of it. This could again play into harder level, more songs and smaller keyboard.
When the game got going people had some laughs and fun, so the potential is there, just needs a much smoother and well informed experience.
More About the Inspiration and Background for Why I Chose to Build BitLang:
While on our “year long trip around the world” I found myself going back and forth between Duolingo (a language learning app) and Google Translate (a phrase translation app). While I love both products, they had a few shortfallings when it came to a couple of specific needs I had.
First, I wanted to learn from a pre-organized set of phrases that pertained to my immediate needs. I would then want to build upon that set of phrases with custom phrases of my choice.
Although I enjoy the general Duolingo-made learning process, it is built with a long-term lesson plan in mind. I am required to learn phrases like “Your horse ate my apples” to get familiar with the grammar of a language. What I want, however, is to learn phrases I can use for my one week tour through France. For example, due to travel plans this weekend I may just want to prepare myself to say, “May I have a local beer on tap?”, “Check please”, or “Two more red wines.”
Of course, I can accomplish my phrase-by-phrase translation needs using Google Translate, but it doesn’t do a great job organizing the translations by category or language. Also, it isn’t built to help me practice the phrases once I’ve looked them up.
I was frustrated by those gaps left between my favorite products. So, I posted feature requests to both product’s sites and got a “[not in our roadmap]” answer. (Which I completely understand and respect.) At first I was disappointed, but then I realized, “Hey, wait a sec, I know how to build things. Maybe I should just create a solution myself.” And so, BitLang was born.
The app is still a work in progress and is growing from its humble MVP beginnings. Here are the designs I mocked up for the first few iterations. Currently it just looks up phrases and allows the users to bookmark them into a single folder. It currently only translates for three languages: French, Spanish and German.
In the next few versions users will be able to login, view pre-made translation packages, and bookmark those packages. Beyond that I will start digging into deeper learning based workflows (quizzes and tests) as well as some community based features.
You can read more about the iterations I took in fleshing out the BitLang concept below.
Phase I
At first, I focused heavily on the learning part of the concept. Trying to simplify the lessons into premade (but pertinent) Q&A with very simple phrases. Users would translate a phrase one word at a time.
Phase II
Phase I became very complex, and the questions ended up getting pretty redundant. Also, I was missing the whole aspect of being able to generate a list of phrases that interest the user the most. For it all to work, the system would have to be made up of a custom lesson, not UGC. So for the next iteration I focused more on the “looking up of phrases” side of things. To make things even more challenging decided to build it while learning Polymer 1.0.
It was starting to come together, but as I mentioned in my key learnings for iOS development, I was forcing a web app model in what was obviously better suited for a native app. My lack of skills to develop in iOS has annoyed me for years so I figured it was time to make the move. That is when the BitLang app became to be.
Updates/Feedback
Is really looking for a tool that provides gender along with translations. e.g. spanish: Cup -> Taza … should be … La Taza
Is looking forward to the helpful learning side. One users suggests getting notifications for any words looked up. The interesting thing he asked here is: why should I organize things – If i’m looking it up I want to learn it so assume it.
Big win: Tons of people find the same holes in language learning tools. I’m not the only one. People urn for crash course mixed with lookup.
If you haven’t picked up any iOS development skills yet, now is the time. It’s never been easier. Below aremy reasons to finally take the plunge (successfully), followed by some helpful links to help you learn to create your first app too.
Contrary to popular belief, I’ve never coded up an iOS app myself. My excuse? For one, hiring great iOS developers gave me more time to focus on building great teams and products for my startups. In addition, Objective-C has a unique syntax and requires a deeper understanding of handling memory, which demanded even more learning time. Finally, there was an immense level of complexity involved in testing, certifying and delivering native iOS apps to market. As a matter of fact, those higher than normal learning curves inspired many startups (including a few that I launched) to focus on making developing apps easier.
Since I already had a strong web development background, I always found it easier to build prototypes for my ideas using the latest web-based, app-building, technologies. Year-after-year a new product claimed to have “the right stuff” needed to create an iOS app that felt fully native, without needing to learn to code directly in Objective-C. Year-after-year I found those claims to be more wishful thinking than reality. Although quicker to develop, those technologies always left the final product feeling hacky, unresponsive or limited, and, in order to go full steam ahead with a project, a fully native version would be necessary.
Earlier this year I took another shot at using a new piece of web tech to build out a mobile app idea I had. This time I learned Polymer 1.0. I loved it as a web framework, but my hopes that Google had managed to finally develop an SPA framework that translated into a smooth functioning mobile app was, yet again, overly optimistic.
It isn’t really the technology’s fault though. The rendering mechanisms for HTML/Web (et al.) just weren’t made to process smooth app-like features. It renders top to bottom, grabs all its assets remotely, makes a lot of inferences, is based on standards that try and work across an array of products made by a variety of companies, and manages general security measures that must be spread across every site. In the web world, the browser is the ad-hoc gatekeeper, and its fighting to keep up. The mission of a browser is critically different to that of apps: to allow a user to serendipitously browse a large breadth of sites in a single view, all the while protecting the user from exposure to malicious pages that are inherently sprinkled into a user’s browsing session. Native apps are different. Both the user and the developer have a strong working agreement between what the developer would like you to see and how the user would like to see it. With that level of trust the developer is able to confidently create an experience specifically tailored to the goal of the app and the interest of the user; the OS can focus on greasing the wheels.
…
Sorry, I digress. Point is, yet again I was disappointed in what the web (and web wrappers) could offer, and, almost as a yearly tradition, I took a stab at learning how to develop directly in iOS again. This time, I’m glad I did!
Maybe it was due to all the free time I had while on our year long trip, but I doubt it; it came rather easily this time around. No, I think the main contributor to my smooth transition is that Apple has done a stellar job incrementally improving the life of an iOS developer over the years. I think the real turn was the release of Swift in 2014. The language is a natural leap from other common languages, as compared to its Objective-C counterpart. Also, there is no longer a heavy requirement to understand how to manage an app’s memory and delegations. The other power ally in creating ease for iOS developers is XCode’s more powerful yet simplified environment, along with interactive interfaces like Storyboards, segues, IB Designables and more. In addition, now that TestFlight is fully integrated with iTunes Connect and Xcode, testing an app on a device, releasing it to external testers, and pushing it to the App Store is only a few clicks worth of effort; fairly brainless really.
All this added up to a surprisingly easily made V1 of my very first fully native iOS app! Yay! This will be fun 😀
Links to Learning iOS
Here are some key links I bookmarked while learning Swift in Xcode 9.0, including: vides, Q&As on StackOverflow, and tutorials. I strongly recommend learning the language by working toward implementing an idea you want to bring to life. Not only does it give you an inherent direction in what needs to be learned, but it also helps you push through the tough parts of learning that would otherwise spell defeat. The app I built used APIs, JSON, CoreData, Table Views (for listing data), Audio, and more. Hope this list helps!