We would like to thank all of our partners, contributors, volunteers and testers for the great cooperation in the past three years! The project that included Mycitizen.net has now officially finished, but we will continue on a voluntary base.
Please understand that future updates won’t happen as frequent as before and that we cannot respond immediately to your requests!
With some delay but still in time before the presentation in Myanmar (Burma), we are able to announce the version 0.2. Although it is in beta and many features on our wish list are still pending, the app provides now all basic functions and even exceeds in some points the initial plans.
The app is not yet available as public download but if you like to check it out we ask you to contact us.
Our testers can find the changes on the changelog.
Including English as default, mycitizen.net is now available in 20 languages! Most of this work has been done by volunteers. This result is mostly owed to the project Trommons where the volunteers managed an impressive work load in just a few weeks.
We plan to add also more languages to the mobile app as soon as we can be sure that the translatable parts won’t change any further. Currently we are still fully engaged using another, not human language.
Since the work beyond Myanmar (Burma) is not within our core mission, we will be able to continue localization only as much as free resources are available. Nevertheless, it is one of our personal ambitions to make mycitizen.net available in many regions.
Sign up at Poeditor or let us know if you can provide a new language (or if you need one that is missing).
It has been long time silent around the app – mainly due to the fact that the production was entirely outsourced and our in-house contribution restricted to necessary adjustments to the API. In mid-October, however, we received the final base package and the code from the developer so that we can now pick up from here and go ahead with the work. This concerns mainly the layout, but also some bugs and features.
Particularly the languages are still causing headaches: The Burmese language is officially supported only since Android 5.0 and in earlier versions the font doesn’t render properly on buttons. Android also seems to have a problem with “commercially-not-so-important” languages by limiting their codes to two letters.
While we are working on a solution, we present you some screenshots from the current development version:
List of users
Tags of a user
If you would like to help us testing, you are very welcome to get involved!
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.
The original concept has started out from users, groups and resources as the basic building blocks of mycitizen.net, suggesting their equal significance. It nevertheless was clear from the beginning that these three categories would not contribute with the same quantity of items, and particularly groups and resources would be used in very different ways:
- It can be assumed that each user is able to participate only in a very limited number of groups, and the number of users certainly exceeds the number of groups. Groups would naturally serve as focal points of activity and as nodes of communication.
- The number of resources could easily grow into larger quantities. Imagine, for example, that a group decides to import a voluminous library of reports. You may easily end up with numerous entries in the listings that all look similar, making it arduous to find the relevant ones.
Despite their different nature is the filter mechanism almost the same for users, groups and resources. This is by design since the concern (or interest), the language and the geographic location are the primary criteria that define relevance across the entire platform. The current method of filtering by tags and a search radius on the map may, however, still leave you with 100 or 200 entries that are potentially interesting. So how would you find what really matters?
The natural way how most people would probably tackle this task is to look through the results and to gradually narrow down the selection by discarding unsuitable items. Unhappy with the presently available options, I realized that a distinct form of presentation was needed for resources, a search layout with the following features:
- Resources should be displayed on one page, rather than users having to browse through long lists that span over many pages.
- The selection of displayed items should immediately reflect changes in the filter settings.
- After automatic filtering, it should be possible to additionally hide Items manually, or to re-order them by simple drag-and-drop.
Find this and more changes in the new version 0.10.