It took almost three months to create a new version. The reason is simply that there are not many new features left to be done and that we are now focussing our efforts on the mobile app.
Most of the changes have happened behind the scenes: We have removed many bugs and increased the speed, and much has been done to help the mobile app play nicely with the server software. We also added a new feature: Users have been requesting the possibility to invite their friends to groups.
If you like to see it live, try it at the demo deployment. And stay tuned for soon upcoming news about the mobile app.
This version has been lingering in the queue for quite a while. Most of the changes won’t be immediately visible to users. For this blog I pick one that exemplifies the priorities of the upcoming mobile app:
Testers inside Burma (Myanmar) have reported that downloading the initial data to the app still takes considerable time. This will need to be addressed by an improved download mechanism, including lazy loading. Since the development version of the mobile app can now determine the network speed, we are also able to transfer different image sizes depending on the connection quality.
The avatar sizes of the fictional user Ma Lay, for example, are:
- 12.1 KiB for the full-size avatar
- 2.1 KiB for the large icon
- 1.4 KiB for the small icon
On the list view, the API therefore delivers on slow networks the small (instead of the large) icon and on the detail view the large icon (instead of the full-size avatar). For our sample deployment, this reduces the amount of data for the list view from around 59 KiB to 30 KiB, which amounts to roughly 50%. This ratio results from the fact that images make up the main part of the volume. For the detail page, the difference is 14 KiB versus 4 KiB – reducing the volume by about two third, as a rule of thumb.
These amounts seem negligible to us who are used to have a fast connection but they appear to be relevant on networks that allow just a trickle of data.
Looking at the trade-off in terms of image degradation, the difference becomes particularly visible on larger images:
List view in high quality
List view in low quality
Detail view in high quality
Detail view in low quality
Note that the image quality loss has not been caused by a different JPEG compression ratio, but by enlarging an undersized image. Using a different compression would mean additional work for the API, while simply delivering a different image size can be done from resources that are already available.
Find the code at GitHub and the changelog at the mycitizen.net docs.