Hi everyone,
This is the summary of the work the Android team is planning on tackling in sprint 53. You can see the full workboard in Phabricator https://phabricator.wikimedia.org/tag/mobile-app-sprint-53-android/.
This will be our final sprint this quarter, so our number one priority will be to fix bugs that come in from the release of the Share a Fact feature to the Wikipedia Beta app yesterday. It's our goal to get this feature out into a production release by the end of the month.
We're going to be spending some time trying to figure out if there's a good way to strip/collapse information that's displayed in the first sentence. A particularly blatant example of the problem can be seen in this image https://trello-attachments.s3.amazonaws.com/54f9fbdb2ddb36b3be7f1cf9/984x750/7152f9b6db75f082feb74eb1bd6b6cf8/Firstsentencesimplification.png, where the sentence is broken up by pronunciation information. We recognise, however, that stripping this information completely (like Hovercards does, in the right screenshot) is suboptimal because it causes too much information loss. In the long run, we think Wikidata descriptions serve this use case better, but we want to see if there are any quick wins to be had in the mean time. We're going to meet on Monday to explore solutions.
We're going to push ahead with deploying our first iteration of the mobile apps content service as an experimental API in RESTBase. When it makes it to production, this service will give performance increases to all users of both the iOS and Android app by performing work currently done on the client on the server instead. The largest performance increases would, fittingly, be on the devices that suffer the most from performance issues. Yay!
Finally, building on the work in the current sprint to cache pages to the file system instead of RAM, we'll be performing some refactoring of the way that the app uses a WebView http://developer.android.com/reference/android/webkit/WebView.html to display content, trying to reuse a single WebView rather than creating and destroying new ones for each navigation event. Users of less powerful devices have been experiencing random crashes and out of memory errors, and our work will help address this.
If you have any questions, feel free to let me know!
Thanks, Dan
I just want to quickly note that this email notes the team's initial thoughts about what we are planning to do next sprint. It is not yet a commitment to do said work; that happens after our estimation meetings. That will happen next week.
Dan
On 6 March 2015 at 12:07, Dan Garry dgarry@wikimedia.org wrote:
Hi everyone,
This is the summary of the work the Android team is planning on tackling in sprint 53. You can see the full workboard in Phabricator https://phabricator.wikimedia.org/tag/mobile-app-sprint-53-android/.
This will be our final sprint this quarter, so our number one priority will be to fix bugs that come in from the release of the Share a Fact feature to the Wikipedia Beta app yesterday. It's our goal to get this feature out into a production release by the end of the month.
We're going to be spending some time trying to figure out if there's a good way to strip/collapse information that's displayed in the first sentence. A particularly blatant example of the problem can be seen in this image https://trello-attachments.s3.amazonaws.com/54f9fbdb2ddb36b3be7f1cf9/984x750/7152f9b6db75f082feb74eb1bd6b6cf8/Firstsentencesimplification.png, where the sentence is broken up by pronunciation information. We recognise, however, that stripping this information completely (like Hovercards does, in the right screenshot) is suboptimal because it causes too much information loss. In the long run, we think Wikidata descriptions serve this use case better, but we want to see if there are any quick wins to be had in the mean time. We're going to meet on Monday to explore solutions.
We're going to push ahead with deploying our first iteration of the mobile apps content service as an experimental API in RESTBase. When it makes it to production, this service will give performance increases to all users of both the iOS and Android app by performing work currently done on the client on the server instead. The largest performance increases would, fittingly, be on the devices that suffer the most from performance issues. Yay!
Finally, building on the work in the current sprint to cache pages to the file system instead of RAM, we'll be performing some refactoring of the way that the app uses a WebView http://developer.android.com/reference/android/webkit/WebView.html to display content, trying to reuse a single WebView rather than creating and destroying new ones for each navigation event. Users of less powerful devices have been experiencing random crashes and out of memory errors, and our work will help address this.
If you have any questions, feel free to let me know!
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation