Clutch spoke with Levent Gurses, President of Movel, as part of a series of interviews about wearable technology.
Could you describe your company and your role there?
Movel is an enterprise software development company that creates mobile platforms, with a strong emphasis on enterprise integration, user experience, and data security. We are a high-end mobile app design and development firm, mostly specialized in enterprise solutions.
Enterprise solutions are different from regular mobile apps, as they require higher levels of specialization in various business domains, such as financial services or healthcare. They also require a deeper knowledge of the integration patterns and platforms that larger enterprises use, such as enterprise service buses and service-oriented architecture (SOA). Our mobile apps are enterprise-ready and designed for iOS, Android, Internet of Things, and wearables.
My background is in development, user experience, and security. Currently, at Movel, I am responsible for the growth and strategic direction of the company.
When did Movel begin designing applications for wearables?
We started looking into various platforms with wearables at the end of 2013. Several of our projects started in 2014 – a couple of proofs of concept and customer projects. We’re still building wearable applications today.
Wearables Platform Differences
You have worked with multiple wearables platforms. Can you describe the differences between these platforms?
The main difference is how you approach the hardware and design of the APIs [application program interfaces]. Apple has traditionally been a closed system. They have a fairly well controlled system, where outside applications and developers are held to a high standard. [Apple’s] ecosystem is very different from the Android ecosystem. For example, while Google and Sony are on the Android platform, they support Android, Java, Python, and a couple other languages, but the Apple Watch is tightly controlled and limited to the support that’s offered for iOS devices, namely Objective-C and Swift.
From a developer perspective, the learning curves are similar, and we think for a good developer the differences are minimal. A good developer that’s used to the Android platform will have no problems developing wearable apps for the Android wearable devices and vice versa for the Apple platform as well.
Could you describe some of the wearable applications Movel has developed?
We’ve worked on a couple of applications.
One of our clients is a service provider for professional integrators and installers. The company provides mobile technology to perform site surveys. Pictures, videos, and note taking are all integral parts of site surveying. Through tablet software, our client can eliminate paper-based processes, but they also wanted to develop a system, perhaps with the help of a wearable device, that would simplify the surveyors’ jobs even further. Our task was to discover an easier way to take photos, videos, and notes and integrate them into the application database. That’s why we decided to go with a Google Glass app for this project.
What factors contributed to your choice of platform?
We chose the Google Glass platform for several reasons. One is, of course, the name-recognition coming from Google made a lot of sense in 2014. The support that Google provides to its new APIs and devices has been phenomenal. The entire Android platform is maintained and supported very well.
There were a couple of key features that made Glass one of the strongest choices, namely its ability to take hands-free photos and videos and to use gestures and voice commands. Voice dictation was particularly interesting because we wanted to have the ability to take notes during the surveys without using a tablet or paper. The Google Glass device, along with the app, offered this ability, as well as the potential for easier integration with other platforms, apps, and APIs.
Who do you believe is Google Glass’ ideal audience?
I don’t know if there is one right answer for the best audience for Google Glass, but there have been a couple changes in the market dynamics since we started the project. One of the changes was Google’s suspension, in a way, of the Glass program and their internal seeking of either a better market definition or rebranding of the Google Glass platform. So that’s one interesting dynamic that impacts people’s and businesses' perceptions of and developers’ adoption of the Google Glass platform.
In our opinion, there are a lot of highly specialized professional domains where we see the Google Glass applied very successfully: construction site surveys and medical domains come to mind, as well as other professions or specific domains where hands-free operation is critical.
Just as a side note, we also built another wearable application for the Sony Smart EyeGlass. This project was a teleprompter application for TV anchors reporting from remote locations and/or from disaster zones, where there was no realistic chance of setting up a real teleprompter. The app displayed three lines of text very quickly on the Glass itself, so the anchor could see notes or upcoming news information. That’s one example of a highly-specialized, highly-niche area where these devices can be helpful.
Could you describe the process of developing these wearable applications?
Understand the Problem and Identify the Platform - The process for developing these devices is somewhat similar to the typical mobile application development project. It starts with a good understanding of the problem domain. There is no jumping into a solution without really understanding the problem first. Familiarity with the users and the conditions under which the device and the app will be used can make a big difference in selecting the platform and/or the device. Remember, for any particular problem domain, you have a plethora of choices when it comes to devices, apps, and features, so the problem itself should guide you in selecting the platform and wearable device.
To give you an example, for this site survey solution, why not use a smartwatch instead of Google Glass or even a smart camera that can perform similar hands-free operations? Understanding the problem domain and the necessary app features is crucial to selecting a device and platform.
In our case, at Movel, we spent a day with the site survey crew and watched how they used paper and tablet technology, in order to understand their process and try to come up with an easier way to collect survey data. From that research, we chose the wearable device. Like I mentioned, there were a number of choices: watches, glasses, and smart cameras.
Understand Existing Knowledge and Platform Limitations - After selecting the device, you have to consider your existing knowledge of and the design language limitations for the chosen device. Desired features should be evaluated based on the device’s capabilities and limitations.
One of the key limitations for all wearable devices with a screen, is the screen size. In this case, I’m talking about the Glass, the smartwatch, and other devices with a little LCD [liquid-crystal display] screen. Typically, the device size dictates what you can do with it.
In a lot of cases, you have the concept of cards. You can display a card either fully colored, or, in the case of some devices, as just green or white text. Sometimes, you have limitations on the number of lines of text that you can display, the length of the text, and/or the resolution of the images. A good understanding of these limitations will help you create a user experience that not only is acceptable but also helps people that are going to use the app.
Develop a Clickable Prototype - After understanding the design principles, we developed a clickable prototype. We prepared a realistic, clickable demo for the customer. This phase is really critical because before investing time and effort, it’s necessary to understand what the product will look like when it’s finished.
Because the domain is so new and new devices are coming online every day, even the manufacturers are still adjusting the APIs and debugging the hardware and software platforms. It’s critical for companies, like Movel, to help visualize the end product for their customers, as well as help them understand how the user interactions will work.
Begin Application Development Process - Once the prototype is approved, the device APIs and libraries are studied, and the application development starts. We do development and testing hand-in-hand. Movel’s strategy is that we import developer testers, who write code and automate the tests all the time. One of the purposes of this approach is that we don’t want to leave testing to the end of the project. We test the app on simulators for speed, but we also test the app on real devices to avoid any last-minute hardware surprises.
Once the app meets all functional requirements and passes all quality checks, it’s ready for deployment to a real device and rollout to the field.
Duration and Timeline
From a duration and timeline perspective, it really depends on the features and the integrations we are incorporating. The last part is key, because whether you integrate the Google Glass app with an existing Android app or iPad app, or whether it uses its own database, the architectural design, dictates the timeline and the costs.
In many cases, the wearable app will have a somewhat limited set of features – or screens, if you will – which could shorten the development cycle. In other cases, since the industry is still fairly new and APIs are still evolving, it may take a little longer to discover a problem or get an update from a manufacturer for a particular defect with the API.
As far as the cost is concerned, it’s going to vary depending on the features, the architecture of the app, and the kind of integrations desired. In some cases, if the scope is limited, the development cost will be smaller.
Another cost factor for wearables is device acquisition and maintenance. In some cases, bulk purchasing, manufacturer warranties, and automatic replacement programs may make sense for certain business domains, and these will alter the cost.
From your experience, what are the ideal application features and functionalities for wearables?
Small Size - In our experience, one of the best features for wearables is the small-size factor. Because these devices are so small and portable, in certain domains, they become a critical part of accomplishing the task at hand. Some of the domains that come to mind are medical and site surveying, but there are thousands of domains where these kinds of devices can be applied in a professional job aid manner.
Hands-free Operation - The second feature is hands-free operation, again for certain domains and applications.
More Integrated World - The third key feature is that these wearables, when applied properly in both consumer and business environments, move us into a more integrated world, where we can use different forms of mobile devices to capture and share information and respond to notifications.
What challenges did you face during the project’s rollout, and what steps did you take to overcome these challenges?
Novelty of Platform - The main challenge was the novelty of the platform, from a development perspective. When implementing wearables, the first couple of projects are always tricky. There is a learning curve involved. You have to decide whether to apply the design principles from previously used platforms and match them with the APIs and best practices offered by the manufacturer – in this example, Google. You’re trying to follow both their guidelines and your knowledge from past experience.
Wearables do not have any proven platforms yet. There aren’t well-documented features or tutorials. The AppStore itself had maybe 100 to 150 wearable apps at the time we started, so you don’t have a lot of examples in front of you. You are a trailblazer, trying to discover a lot of things. Those were some of the challenges on our part.
We approached the project as a foray into the wearables domain, as a way to specialize, and as a means of offering more services to our clients. With that in mind, we took a little bit of a hit during the initial phases, but later on, we stabilized.
User Testing - The other challenge was actually testing with real users. Again, because the platform itself is new, and it’s also new to users in our domain, some of the clients were not used to interacting with a lot of high-tech gadgets. That was one of the barriers, but we solved that pretty quickly.
WiFi Connectivity - The other challenge we had was actually connectivity difficulties in some remote areas, but luckily for those situations, we had a backup plan with offline capability on the tablet.
In what ways did your initial conceptualization of the application change throughout the development process?
It’s probably hard for me to account for all the things that we’ve discovered, but like any learning company or team, what you start with is a big idea. It doesn’t matter how well you conceptualize or how well you try to design based on the language offered for a particular platform, things always change.
One of the things that changed from our clickable prototype was the interaction screens. We discovered that they were lengthy or just didn’t make sense, so we took out a few features and changed the layout of a couple of screens.
Understanding the device’s design language upfront and creating that clickable prototype helped us. We didn’t have huge changes to the app from the initial inception, but we would have had more if we had not done that prep work.
Could you share any statistics, metrics, or feedback that might demonstrate the application’s performance?
Overall, the app has been very fast, and the Google Glass operating system is very responsive. Our app takes, on average, less than a second to launch, and even with the network latency, photos and videos have not been an issue. But, we really don’t have any metrics at this point, to be honest.
The Glass app is still evolving, we’re working on improving certain features, such as the gesture-controlled actions. We have not matured the app enough to where we can actually collect either performance data and/or user analytics, but that’s on the roadmap for the future.
Can you provide the application’s name, or is it better to refer to it generically?
We have not released the app in the Google Glass Store. We’re just deploying it to the devices individually. Right now, we’re still waiting to see Google’s next step.
What lessons did you learn from this experience, and what areas would you like to improve upon or do differently in the future?
We’re a learning company, and we like new platforms, especially wearables and IoT [Internet of Things]. It’s so popular right now that we are building proofs of concept within Movel for other devices as we speak. Experimenting and making sure we understand the platform and the limitations is a key part of our learning company. With that, come lessons.
Complexities of Small Screen - For this particular project, one of the lessons we learned was not to underestimate the complexity of a small-screen app. It can be fairly complex. Just because the screen is small, or the number of cards displayed on the screen is limited, does not mean that it’s going to be an easy process.
Wearables, fundamentally, are different from existing mobile apps in both design and user experience. We develop our apps with that in mind and design them specifically for a particular wearable device. This means we can account for the restrictions imposed by the generally smaller form factors – the screen layouts – and use features that take advantage of users’ gestures, if the device supports those gestures, like Google Glass. With that, we ensure that the user experience the capabilities of the device for which we’re designing. We actually test it on the real device. That’s another lesson learned.
Testing - Initially, for the sake of speed or development cycles, we would only test an app on the emulators. Later on, we made it a practice that in sprints, (in our case, sprints are one week periods where we develop a demo for a client) we decided that all the demos would be performed on a real device. This added a real sense to the project, meaning the practice displayed where we were at any given time and gave us an opportunity to find the quirks related to the hardware, which were not apparent in the emulators.
Factor for Complexities - That’s another lesson learned: factor for complexities associated with a new device. Understand that you’re probably going to be working on a new paradigm and account for that, both from a project management perspective and from a budget perspective. From a development and testing perspective, make sure that a real device is always handy and available for performing real testing and/or user demos on the device itself.
What advice would you share with another organization that is seeking to develop a wearable application?
Developing a clickable prototype is one of the cheapest investments any company can make in order to come up with a good product idea.
Wearable technology is fairly new, so finding experienced companies or developers can be a challenge. Their cost rates are probably a little higher than normal as well. It’s just supply and demand. So, before making an investment into wearable technology or a problem domain, it may be useful to understand the associated uses and user applicable user behavior trends.
Future of Wearables
What role do you see wearable technology playing in the next 6-12 months?
This goes with a similar question you asked before, and my funny answer is, predicting the future is particularly hard. I foresee the usage of wearables increasing in a couple distinct domains.
Consumer Devices - First, the consumer devices, such as the Apple Watch, the Pebble, and other either fitness trackers or personal health trackers, will continue to gain market share and be selected by users as the prices come down. As they become more prevalent and accepted in society, people will find them more useful. Fitbit and others are making their devices more integrated, easier to use, and even easier to find if you lose them. That’s a really critical feature for some of these small devices because you’re more likely to lose them.
Specialized Personal Devices - The second domain that I see getting new traction is specialized personal devices, such as medical wearables. They will become more prevalent and more accepted. Think of blood pressure wearables, glucose meters, or other health-related specialized devices that people will buy because they need to, not necessarily because they want to, as opposed to the first category of consumer products, which are more desired products, or status-symbol products, like the Apple Watch.
Business Usage - The third category is probably niche business usage, like professionals using wearables to perform their jobs in the field or in highly specialized environments. These are probably medical and surgical environments, site surveys, security surveys, and photo editing and reporting in the field. These are more specialized business domains where wearable technology will find some niche users, and it will probably increase the overall usage.
Usability and Security Concerns - In general, wearable devices will probably continue to grow in adoption and popularity, and we may see better versions and new families of devices. Two key features will likely continue to occupy people’s attention: usability and security. With this many connected devices, it’s a hacker’s wonderland. App developers and device manufacturers must take cyber-security seriously and invest in creating usable and secure apps.
Those are the trends that I see in the proliferation of these devices as the prices come down, the features improve, and the accessibility expands. But, one area that must improve is security. Wearables collect so much personal data, which puts people at risk if not taken care of properly.