As indoor mapping becomes foundational for many digital experiences, building flexibility into our mapping platform is critical. The need for indoor mapping spans across a variety of industries, each of which has different needs and use cases for their digital map.
While pre-built applications are great for certain platforms and verticals, they don't allow for heightened flexibility in terms of look, feel, and function of a product. Enter a robust mapping SDK that houses all the great components required to build any indoor mapping experience imaginable. In this post, we outline the pursuit of building great indoor mapping SDKs, both for our clients and the developers working with them.
The most important factor we consider is the needs of our users. Developers looking to build an indoor mapping experience with our SDKs come in many forms. Regardless of whether you're creating a shopper-facing website for a mall, or building an asset tracking application within a hospital or warehouse, Mappedin's SDKs have been developed to support these and everything in between. Even across this large spectrum of experiences, there are common indoor mapping elements. These elements are the ones we continually invest in, ensuring they're easy to work with and ahead of the curve in terms of capability.
For Mappedin, that means the basic elements such as rendering a 3D map, setting up the venue and map view options, building A-to-B wayfinding and search, as well as showing venue data. These functions are common among most indoor mapping use cases, so we've made them simple to work with. With a solid and existing mapping foundation, developers are encouraged to build unique features that are custom to their application. These features encompass anything you could imagine as part of indoor mapping, including indoor positioning, proximity marketing, heat mapping, and many more.
Being a foundational ingredient to many experiences, it's important for our indoor mapping SDKs to be highly flexible. At Mappedin, we have the benefit of offering pre-built applications for indoor mapping and wayfinding that are built on top of our SDKs. This means that we get to learn first-hand the downfalls of our SDKs, understand the features and capabilities that current and future clients are looking for, and ultimately continue to improve them with a forward-looking roadmap.
Considering the different verticals and projects that Mappedin SDKs are used for, we are constantly evaluating which features are most important and how we can better document our work. While the roadmap for pre-built applications is typically driven by individual verticals, the SDKs roadmap is built with a "one-to-many" approach. To prioritize efficiency, we look for features and components that can be used and repurposed for multiple use cases. For example, a mapping feature such as optimized pathing within a wayfinding application could be tailored to either a picking and packing app for grocery store associates, or a wayfinding app for shoppers. The core of this "optimized pathing" feature is the same, while its application serves two different users and use cases.
This one-to-many approach with our mapping SDKs enables our business to take on unique opportunities and mapping challenges that have never been solved before. With strong documentation, tutorials, getting started guides, and sample applications, we can empower developers to utilize indoor mapping in creative ways. And, while we have a team of developer evangelists who are available to work through challenges with our clients and partners, we want our SDKs to be self-explanatory, enabling developers to watch their vision come to life with as few barriers as possible.
What do you think makes a good SDK? How do you prioritize the needs of different SDK users and use cases? Subscribe to our newsletter to keep the dialogue going.
Tagged In
Share