The engineering team here at DevResults has a lot going on right now. These are some things we're working on these days that we're really excited about.
As more and more people have started using DevResults over the last few years, we’ve been adding more and more functionality and complexity to the site, and the cohesiveness and simplicity of the user experience has suffered as a result. It’s become more and more difficult to "ease into" the software, without having everything pre-populated from the beginning. This means that introducing DevResults to an organization has become more of a front-heavy operation, with a lot of labor-intensive setup required before anything can be done.
We’re working on reintroducing the software’s original simplicity, hiding the complexity behind the scenes. We’re in the process of rethinking a lot of the user interfaces that have become unnecessarily complex, so that they’re as simple as possible for users with simple needs, while still supporting the sophistication that some users require.
Making DevResults faster
We’re currently in the process of rewriting DevResults’ software in place, screen by screen. Sometimes this feels like we're turning a 747 into a jet fighter midflight. It's certainly exhilarating.
Here are the technical details. DevResults currently mostly uses Microsoft’s classic ASP.NET webforms approach, where each page is calculated and generated entirely on the server and then sent, fully formed, to the browser.
While this has been a standard way of creating web applications for years, frameworks and technologies are now available that allow for a much faster and more responsive user experience. The paradigm we are moving towards uses the ASP.NET Web API framework on the server plus Google’s Angular framework in the browser. Once this shift is complete, the server will mostly just respond to API requests for raw data, while most of the site’s logic is transferred to the browser.
This will result in a much faster user experience because:
API requests are more cacheable at the server level, so that once a response has been generated for one user, it can be reused for another user with similar privileges, without having to perform the original database query again. That not only makes the second response faster, it frees up the server to respond to other requests more quickly.
API requests are more cacheable at the browser level, so that once a user has asked for a dataset (for example, the list of a program’s indicators), that dataset won’t have to be requested again. This saves the user an unnecessary round trip to the server, and also lightens the load on the servers so they can deal with everyone’s requests more quickly.
Moving complex calculations to the browser - for example, pivot tables on large datasets - makes the site feel more responsive to the user, while at the same time lightening the load on the server.
Most of the application’s interface elements - menus, templates, images - only need to be transferred from server to browser a single time, instead of every single time the user goes from one page to another. That means less work for the server, less stuff to be transmitted over the network, and less waiting for the user.
Helping DevResults make friends: The public API
DevResults’ API allows other computer systems to talk directly and securely to DevResults. This will ultimately allow anyone with approved access - DevResults staff, customers themselves, or third parties - to build connectors between DevResults and other systems like financial systems, other M&E databases and reporting systems, etc.
The API currently supports a subset of DevResults’ functionality, but will soon be expanded to encompass 100% of the software’s capabilities.
This is a RESTful API. It is discoverable and invoked via standard web protocols - simple, humane URLs, standard HTTP verbs, and standard return formats including JSON and CSV. All of that means that a programmer from any background, working in any technology, can use it.