Developing a new app
An Ideas2Executables customer was building a unique social media platform and faced a challenge when planning the back-end tools needed to power it. On one hand, these tools would be used by only a handful of administrators, so it seemed excessive to pour time and money into building them. On other, if those tools were too clunky to use the site may suffer and the user experience negatively impacted.
This is a common app builder’s dilemma: invest too lavishly on back-end tools, and the front end’s budget may suffer. Skimp too much on the back-end tools, and the whole site-experience may be impacted.
Back-end tools, because they are used by specific, site-designated, administrators don’t need the same polish and pizazz the front-end user experience does. However, they require no less care when planning their functionality. In the case of our customer looking to build a social media platform, his site administrators would be called on to upload and update site content on a regular basis. Providing bare-bones tools to do this would make mass updates a frustrating and dreaded task. The ideal solution is to develop more feature-rich tools that can handle bulk updates.
Unfortunately, we don’t live in an ideal world. Building feature-rich administrative tools would be both cost and time prohibitive.
Fortunately, we were able to recommend a third option, one that provided more sophisticated tools without a notable increase in cost.
This option involved wiring Google Sheet synchronization into the back-end. Administrators could make changes to site content in Google Sheets, leveraging its advanced user interface, including real-time collaboration support. And when they wished to make this information live within the app, they clicked a synchronize button that we provided.
This solution was relatively fast to develop, because we needed to only focus on the synchronization procedure, leaving front-end editing functionality to Google Sheets. It met the need of the customer on two fronts: their administrative team could work in the robust Google Sheets environment, and the cost was below what their budget called for back-end tools, allowing more resources to be spent on front-end functionality.
Google Sheets synchronization is made possible by the Google Sheets API. This facility allows the customer’s custom app to programmatically talk to Google Sheets. This is one example of a larger strategy, where custom app builders use 3rd party APIs to efficiently add functionality to their offering.
This Google Sheets synchronization strategy has limitations. It’s relatively fragile and assumes that site administrators will closely adhere to required conventions that are prescribed ahead of time. With this in mind, as powerful as this synchronization strategy is, as your app grows, it will almost certainly be replaced by a more robust solution. However, from an app building perspective, being able to have high quality admin tools at a low cost is a huge win while you are just beginning development.
Existing Platform
A customer with an eCommerce site approached us with a frustrating situation: their shoppers were occasionally having issues during the checkout process. When this issue was reported to the hosting provider, shopping cart vendor and shopping cart plugin authors, all declared that the issue wasn’t due to their software and they were unable to provide further assistance. Ideas2Executables worked with the customer to cut through this blame game and diagnose and fix the underlying issue.
The first step in deriving a solution to this check-out bug was to determine a method for recreating the issue. Fortunately, the customer had already determined this and setup a product that we could purchase that triggered the issue. When there’s an issue with your software platform you may feel powerless to fix it. However, being able to reliably recreate the issue is an invaluable step you can assist with, regardless of who undertakes the final fix.
The second step in building out a solution was to decide where the problem should be debugged. Broadly, you have two choices: either on the production system itself or in a cloned-development environment. Working on the production system means less setup time and allows the developer fixing the issue to begin debugging immediately. However, working on a production system risks causing downtime or other issues that may impact real customers. If your software is in active use and time allows, setting up a cloned-development environment is a much lower risk option for setting up an environment to fix the issue.
A cloned development environment is just what it sounds like. An isolated series of servers and software in which to debug the issue that is created by cloning your production system. Your hosting provider may assist with setting this up, or the developer debugging the issue may opt to do this.
Working with a cloned environment allows a programmer to work without impacting production systems. If a programming mistake is made that causes orders to be deleted, for example, the production system isn’t damaged. However, setting up a new environment takes additional time and cost, which may not be in your budget. Also, it’s possible that when the production environment is cloned, the bug no longer shows up. If this is the case, then this fact alone serves as an important clue to help understand the bug.
The customer who contacted us to fix the issue with their eCommerce site opted to have us debug the issue in production. They made this decision because sales were so severely impacted by the bug that it was reasonable to prioritize quickly fixing the issue over negatively impacting shoppers.
Our customer was utilizing a robust shopping cart vendor with a number of additional plugins. The result was an overwhelming amount of code where the bug could be hiding. To narrow down where the issue could be, we developed an auditing facility that let us see precisely which areas of the code were in use during the checkout process. This allowed us to focus in on the relevant blocks of code, and ignore thousands of lines that weren’t relevant. This auditing facility served as sort of an x-ray vision: we could debug the behind the scenes processes, but to shoppers continuing to checkout on the site, nothing was visible.
It was gratifying when we finally understood the issue that was causing the problem. When a customer starts shopping, their session is tagged with an order-number. During checkout, the cart details are turned into an order record. This temporarily assigned order-number is discarded, and a persistent and permanent order number is assigned.
This process was complex, but working well. The issue was the customer’s use of a plugin that was not cooperating with this process. The plugin utilized the original order number, but wasn’t being properly reset when the permanent order number was assigned.
We fixed the issue for the customer, and reported the bug and fix to the relevant shopping cart plugin author.
It took a few debugging sessions to resolve this situation, but ultimately, the bug was slain and the customer’s website returned to its former working status. The auditing framework we developed is still available to us should future issues arise. Most importantly, the customer has learned they have an advocate they can turn to whenever their site encounters an issue.
Existing Platform
An Ideas2Executables customer with an existing educational friendly web application found himself with a significant uptick in demand during the Covid-19 pandemic. Teachers were eager to provide their students with novel learning tools, and our client had a unique educational online offering. The challenge arose at the administrative level, as there were concerns about how the integration with a new platform would scale among schools. Would students have to manually create and track new accounts? Would teachers have to manually set up classes on the new platform? Would IT administrators be confident that the new platform was safe and secure for the school to use? Our client was looking for a cost effective solution that would quickly address these concerns.
While these are challenging issues, our client was fortunate that vendors exist to meet many of these concerns. The core solution was to integrate the customer’s custom platform with two well known education platforms that many school districts already leverage: ClassLink and Clever. These platforms provide a secure and convenient interface to teachers, students and administrators, while behind the scenes integrating with third parties like our customer.
Two common services schools rely on are Single Sign On (SSO) and Rostering. SSO allows students to seamlessly access our client’s platform without creating yet another account. Rostering allows for the organization of students and teachers into their appropriate classes without manual intervention. ClassLink and Clever both offer these services.
For our customer’s app to leverage these services, we needed to write custom code to respond to SSO and Rostering requests. We developed this custom code in such a way that not only were Clever and ClassLink accommodated, but so that future vendor implementation can benefit from this development as well. This was accomplished by building out a common framework for handling SSO and Rostering that ClassLink and Clever both share. Then vendor specific code was plugged in, allowing nuances of Clever and ClassLink to be accommodated. Should a future vendor be identified, the common framework can be re-used and only the vendor specific code needs to be implemented.
On the surface, it seems possible to add Clever and ClassLink support without making changes to the core of our customer’s application. However, some minor changes were made to the authentication aspect of the system. Whenever significant features are added to the system, we believe it’s important to integrate them into the system so the result is a healthy, streamlined system. Simply bolting on feature after feature can result in a Frankenstein-like system which over time becomes inefficient for both end users and those working to make changes to the system itself.
Integrating with well known educational service providers successfully addressed the teacher and administrator’s concerns. Teachers didn’t have to worry about sign-on issues they and their students may have, nor did they have to concern themselves with data entry relating to managing classes. Instead, teachers could focus on providing fun and inspiring content to their students. Administrator’s concerns about security and privacy were alleviated because they continued to work with a trusted partner, ClassLink or Clever. Our client was excited to be able to offer their educational toolset to a wider audience in a truly scalable manner.
If you find yourself in a situation similar to our customer, consider the following:
Developing a new app
An Ideas2Executables customer who was in the early phases of designing her app expressed a common concern: how can she be sure that she’ll be designing the optimal user experience? The concern is that with so many apps striving to capture users’ attention, a less than perfect app will not thrive.
Of course, there’s no easy way to ensure your app will be a run-away success. However, as a new app creator, you have a number of strategies you can deploy to help get you there. Here are two common measures we recommend for nearly every project we work on.
Strategy 1: Know the problem you’re solving and be laser focused on making sure your app delivers. Yes, your app needs to be esthetically pleasing and needs to follow modern user experience guidelines. But those details should almost always take a back seat to the core question of whether you’re delivering on the problem you’re claiming to solve.
Let’s say after years of research and analysis you’ve got an app idea that’s sure to be a winner: your app helps parents get their newborn to sleep through the night. If your app works, parents aren’t going to care if you have a slick logo or not; or if it takes 1 click or 4 to complete the daily baby survey. All they are going to care about is that your app has single handedly changed their world for the better through the miracle of sleep. Sure, parents may have complaints about the app–they wish it was easier to use, or faster, or whatever. But if it actually works, they will stick with it.
The opposite scenario is true, too. If you fail to deliver on your promise, then the slickest user experience in the world isn’t going to save you. Sooner or later, probably sooner, users are going to see through the fancy veneer and abandon the app.
Strategy 2: You’ve identified your problem and you believe you have a top notch solution. But the concern is still there: what if the app you build is too cumbersome and users give up? There are a number of solutions to this challenge. You could pick an existing app that users love and more or less copy its user experience. You could hire a user experience expert who could give you professional advice on building the app. Both of these strategies have value and both have limitations, the latter typically in the form of budget concerns.
The tool we use to overcome this issue is iterative development. That’s a fancy way of saying you build version 1, share it, learn from what users have to say, build version 2 and so on.
Most products don’t have the luxury of iterative development as an option. If you are building a solar powered car, you need to design, build, market and sell the very best version of the car. Undoubtedly, there would be early adopters who would be eager to buy version 1 of the car, but these same users would quickly tire of being stuck with this early, limited version.
But in the case of app, users don’t just get version one, they get all versions. What may start off as a basic app, will over time, turn into a fully featured robust one.
What’s beneficial about this strategy is that the app owner learns from real users between iterations. You don’t have to guess at what users want, they’ll gladly tell you.
Imagine our hypothetical baby app from above. You may imagine parents want a ‘share on social media’ button that they can click when their baby has slept through the night (#parentingisntthathard #supermom #wonderdad). When in fact, what they really want is ‘Dark Mode’ so they can check the app without waking their little one. The time and money spent on designing and implementing the ‘share on social media’ button would be lost, and a delay would be introduced for the ‘Dark Mode’ feature.
Iterative development works hand in hand with ‘Strategy 1’ above. The very first version of the app has to deliver on solving the problem. That can’t come in future versions. But the user experience tweaks and additional features, those absolutely can. And they can be driven by actual user needs, not educated guesses.
You’ll find both of these strategies baked into our development process. First, we identify the problem the new app creator is solving, and work rigorously to ensure that the very first version of the app meets this need. We also regularly push back on features and ideas, asking: is this core functionality critical to the app, or something we can delay to a future version? This saves development time and creator resources and gets your app into the hands of users sooner.