This blog let you participate in some of the thoughts before, during and after creation of the ios app Daily Scrum Time Keeper (DSTimeK) starting right after the first business concept and having a focus mainly on the technical aspects.
The first project of yaaZone is a timer app DSTimeK ( app link) motivated by some shortcomings in the daily scrum meeting. The daily scrum meeting is part of a project management method often used in IT projects. Creating an IT product like DSTimeK means making decisions, sometimes very fundamental ones that can’t be easily changed afterwards. Most of these questions are in the area of “How to set the right scope for the be produced functionality and how to deliver the functionality?”
The following questions answered for the project DSTimeK can be used as a template for other software development projects. Answering these questions before starting your project will give you a better orientation for what is really needed.
- Does your software/functionality/app require using of central services or storage of data centrally?
No, it’s just a timer running on one device – autonomous. The facebook app in contradictory stores information on central servers and communicates with that constantly.
- Can you run your functionality as a server application, e.g. showing it on a homepage?
Yes, possible. The timer could be shown on any page.
- Is the functionality used in a mobile scenario or can it be a desktop application?
Yes, mobile is recommended, which not immediately excludes showing the functionality “just” on a homepage on a mobile device browser – then the timer page needs to be responsive.
- Does your functionality require a lot device specific functions (Camera, GPS, Animations, store data …) and is it performance critical?
No, still the homepage is a valid media for delivery. Using device specific functions means also using installed apps (for communication e.g. send the timer to others by sharing on facebook, send via email). The core function of the timer doesn’t need device specific functions but the supplementary functions will: share the app with others and play own sounds as timer signal.
- Do you want the application to be run on different operating systems (ios, android, windows phone, …)?
Yes, the more the better. Most of the time you can’t limit the target groups devices. A mobile device browser (safari, chrome, …) is out of the box and more or less independent of the underlying operating system. Beside of that there are other methods for making an app platform independent (besides program it in the required native languages). Basically using a Web Container in the native application or using a framework translating from a platform independent language to the native (e.g. Cordova).
- On which mobile device types should the app run (iPhone, iPad, …) and which operating system version are going to be supported?
The more the better. At least the timer should work on a tablet and smart phone.
- Does the functionality require a (constant) internet connection?
No, the timer doesn’t need it but showing adverts is part of the concept which means from time to time an internet connection is necessary. Deliver the functionality as server application would prevent using it without internet connection. The seldom case that the timer for the daily scrum is used in an internet free zone can be ignored.
- How do you want to market and sell your functionality?
Via appstore, playstore… The marketplace takes care of payments, provides analytics, shows the app in rankings (creating additional demand), and provides download possibilities and many more useful services. On the other side this service is not for free.
- In which languages do you want to provide your functionality?
The more the better. Even if the timer is not really worthwhile to be translated for a better understanding, the different languages increase the reachability, meaning that key words in multiple languages lead to higher probability that the product is found. At least german and English should be provided.
It is of advantage to answer such fundamental questions beforehand. Speaking of effort – regarding all these points the question is, if oneself has the knowledge to execute it or if the project then gets too big for oneself, targeting the complete scope. Therefore reducing the scope is practical especially when you first want to test if there is a market at all for a product.
For this first yaaZone product the scope was reduced in the sense that the timer was only developed in ios. The decision was mainly influenced by making things easier. Native app development is easier than using frameworks or server side logic that is displayed in a Web Container. Additionally, you can make use of the app store. Plus, programming natively means that you are on the safe side functionality wise. You know the things that are possible just by looking at ios apple documentation – one source of truth. The DSTimeK project was a one-man-show. This holds true throughout the whole project except two things which were outsourced: the initial translation into different languages and testing on different devices, which has been done by friends.
The findings of the project are as expected, but some are pretty surprising:
- Not long after the release of the app to the market people have been asking if the app could also run on android or other devices. At least for different ios devices it is possible to smoothly run the app. Running the app on an iPad didn’t mean extra effort, since this is offered by ios with changing the screen resolution.
- Providing the app in 5 languages was a real turbo for its spreading since now keywords in different languages lead to the app. But having multiple languages at an early stage in the project increased the effort, since with every change of texts, screenshots for marketing and so on needed to be replaced.
- Submitting the app to the apple store was way too early. When you think you are done and could submit it to the app store, invest another remarkable timeframe in testing. The first version of the app was working but had major bugs, due to which customers might lost trust in the product – removed it and installed a competitor. A way to get around this, is to use test-driven development from the very beginning.
- You can’t have enough backups, versioning and documentation on all findings and coding during the project.
And the most important thing: With all these made experiences I would go for a platform independent implementation of the timer, if I would implement DSTimeK again.
All these experiences are input for the next upcoming project of yaaZone.