We are excited to announce our new help site, which makes finding answers faster with improved search functionality and article categories.
The new site lets you vote on whether articles are helpful so we can improve the content. Please note, you may experience 404 errors if you use links to the old website — in that case, use the search engine to find what you are looking for.
His talk will focus on how Ona uses geospatial check-ins to improve the targeting and delivery of IRS malaria spraying in over 120,000 homes in Zambia. With geospatial check-ins, we are able to link service delivery to physical structures in OpenStreetMap. Erick will also discuss how we will be applying this approach to child vaccine programmes with the goals of improving coverage and coordination in humanitarian aid.
If you want to meet up with Erick, send him a note at firstname.lastname@example.org.
Every data collector eventually runs into this issue at some point — you know the makeup of your population as a whole, but you only have access to a small group that isn’t representative. For example, you know that as a whole, the population pizza topping preference for plain cheese:pepperonni is 1:1. However, you only have access to a population heavy in vegetarians and you need opinions that reflect everyone.
In this article, we’ll build a survey function that randomly selects people to survey in a weighted manner. The weighting adjustment is a common statistical correction technique that compensates for the presence of bias. It gives underrepresented people or elements in your sample a larger weight than those over-represented. In the pizza example, you know you’ll need to weight the non-vegetarian open-to-eating-pepperoni people more in order to avoid interviewing too many vegetarians.
We are excited to announce the Tableau App for Ona. Tableau is a data visualization tool that can create visually appealing reports, charts, graphs, and dashboards using your data from Ona. Here is an example:
A few months ago we received a support query from a user who was unable to
log in. We couldn’t replicate the issue and they weren’t able to work with
us to get it fixed.
We concluded that they were doing something unique and had ended up fixing it
from their end somehow.
Fast forward to March 5th, when we sent email invitations for a
Nairobi Linux Users Group meet-up with an HTTP—not HTTPS—link to the login
page, http://ona.io/login, and got a complaint that the site did not redirect
to HTTPS on the /login or /join routes. This was a serious problem because we only perform sign-ups, log-ins or any
other form of data exchange over HTTPS, including setting cookies.
When we find the user’s authentication cookies are not set, or are expired, we
reload the page so that they can get a new authentication cookie.
We implemented this as shown below, by checking for a 401 status from the OnaData API. More of that code is here.
As a consequence of this setup, when a user connects over HTTP and is not redirected
to HTTPS they can end up in an endless loop of reloads when they try to sign-up,
log-in or submit data in any other way.
When we tried it ourselves, HTTP redirected to HTTPS just fine. However, we
noticed that it didn’t redirect on a fresh Firefox install, assuming this fresh
install didn’t have add-ons like HTTPS Everywhere.