-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Quote: '''These are "simple" to implement as they have few server-side dependencies. - - Remote / push. These notifications hook up to services (e.g. Google Play Services) to retrieve information and only trigger when they information is received (i.e. pushed) to them.'''
Dan: i'm just pointing out that not every android user is using the play services, those users should get notifications as well. On 10 באוקטובר 2014 15:00:28 GMT+03:00, [email protected] wrote: >Send Mobile-l mailing list submissions to > [email protected] > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/mobile-l >or, via email, send a message with subject or body 'help' to > [email protected] > >You can reach the person managing the list at > [email protected] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Mobile-l digest..." > > >Today's Topics: > > 1. [Apps] Notifications: product/technical details (Dan Garry) > 2. Re: [Apps] Notifications: product/technical details (Yuvi Panda) > 3. Mobile article preview gadget (Brion Vibber) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 9 Oct 2014 17:31:21 -0700 >From: Dan Garry <[email protected]> >To: mobile-l <[email protected]> >Subject: [WikimediaMobile] [Apps] Notifications: product/technical > details >Message-ID: > <caow03mhoipsekmbojjsq+6wswo_ykejydc14bj0n9aodyby...@mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >Hi everyone, > >The Mobile Apps Team met to discuss some of the technical aspects of >notifications and how they can be served in the apps. This email >summarises >the technical aspects of the discussion as seen through the lens of >product. > >Broadly speaking, there are two classes of notifications: > > - Local / pull. These are triggered on some kind of schedule or timer >(e.g. every X minutes). They may, if they choose to, retrieve (i.e. >pull) > data from an API call when they are triggered, and present information >retrieved from that API to the user. These are "simple" to implement as > they have few server-side dependencies. > - Remote / push. These notifications hook up to services (e.g. Google > Play Services) to retrieve information and only trigger when they > information is received (i.e. pushed) to them. The nature of the > notifications means they can typically be more personalised. These are >"hard" to implement, as there is server infrastructure required to push >the > information to the device. > >>From a UI perspective, there is absolutely no difference between a >local >and remote notification. This distinction is not presented to the user, >so >it is totally irrelevant to them. > >In terms of evaluating the success of notifications, it is important to >consider that there are three interaction patterns that a user can have >with a notification: > >- Engage. The user taps on the notification and is directed to wherever > the notification wants to direct them to. > - Dismiss. The user dismisses the notification and it's not shown to > them any more. >- Languish. The user sees the notification, but neither engages with it > nor dismisses it. > >So, it is possible to build metrics around notifications. You can say >"Of >the X users we served this notification to, Y engaged with it, so we >have a >Y/X engagement rate". However, it's important to take these interaction >patterns with a pinch of salt, for a variety of reasons. > > - Firstly, do not assume that dismissing a notification means that it >was ineffective, as that depends on the intent of the notification; if >the > notification was a reminder, then dismissing it means the user was >successfully reminded! The exact metric used to evaluate the success of >a > notification will have to be decided on a case by case basis. > - Secondly, on iOS, users may heavily customise the way notifications >are presented to them which will mould the way they interact with them. >- Thirdly, it is difficult on a technical level to distinguish between >a > "dismiss" and a "languish", and in fact on iOS there is often no > distinction between these modes anyway. > >That's all I have for now. Our initial discussion was very exploratory. >More to come. :-) > >Thanks, >Dan > >-- >Dan Garry >Associate Product Manager, Mobile Apps >Wikimedia Foundation >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: ><https://lists.wikimedia.org/pipermail/mobile-l/attachments/20141009/8e232252/attachment-0001.html> > >------------------------------ > >Message: 2 >Date: Fri, 10 Oct 2014 06:39:08 +0530 >From: Yuvi Panda <[email protected]> >To: Dan Garry <[email protected]> >Cc: mobile-l <[email protected]> >Subject: Re: [WikimediaMobile] [Apps] Notifications: product/technical > details >Message-ID: > <CAFw=ySgpLuqMU6Zh=3kpf6zEkyrH=g4sjnelvcksl++++i4...@mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Fri, Oct 10, 2014 at 6:01 AM, Dan Garry <[email protected]> >wrote: >> From a UI perspective, there is absolutely no difference between a >local and >> remote notification. This distinction is not presented to the user, >so it is >> totally irrelevant to them. > >While there's no UI difference, there are a couple of UX differences: > >1. Server side push messages are 'instant' - client side pull ones >will have a 'lag' of X/2 minutes on average, where X is the >notification checking period >2. Doing a network request every, say, 10 minutes, is not good for the >User's phone battery life. > > >There's also the other technical distinction of: >1. Client side, you have to pick and choose which notification types >you would want to be notified for, since different ones would require >different API calls. Does hitting every 10 minutes for a change that >rarely happens, but is very important when it does, a good idea? >2. Push is *far* more forgiving on the servers than pull is, since >there's no 'empty' hits that still require db scans, etc just to say >'nothing new' > >There are also possible *legal* concerns, since push notifications >from the server would entail us contacting Google / Apple's servers to >send data via them and sending data via that. This can be properly >encrypted in a way that Google / Apple can not view it - we just >exchange a symmetric key when doing the initial registration from the >client side, and everything is encrypted with that afterwards. Still, >would need wider consultation. > >Also, yay notifications!!1 \o/ > > >-- >Yuvi Panda T >http://yuvi.in/blog > > > >------------------------------ > >Message: 3 >Date: Fri, 10 Oct 2014 00:45:49 -0700 >From: Brion Vibber <[email protected]> >To: Wikimedia-tech list <[email protected]>, mobile-l > <[email protected]> >Subject: [WikimediaMobile] Mobile article preview gadget >Message-ID: > <CA+30r1Qeg_CAeexhwW+Eh+gdbn=7rfq5mdhggf6blqeq1cc...@mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >Here's a quick first draft of a mobile article preview gadget: >https://meta.wikimedia.org/wiki/User:Brion_VIBBER/mobile-sidebar.js > >This shows the currently viewed page on the mobile view in an <iframe> >sidebar, and captures link navigation within the iframe to navigate on >the >desktop window as well. > > >To enable add to your ~/common.js: >mw.loader.load(' >https://meta.wikimedia.org/w/index.php?action=raw&title=User:Brion_VIBBER/mobile-sidebar.js&ctype=text/javascript' >); > > >Todo: >* add an on/off switch >* fix width to adjust for scroll bar if visible >* make a couple common sizes selectable instead of just 320x480? >* figure out how to apply this to edit previews? (is this even feasible >without API changes?) >* fix edge cases with the navigation detection >* pretty it up >* enable as a gadget on some major sites > >-- brion >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: ><https://lists.wikimedia.org/pipermail/mobile-l/attachments/20141010/fa192cc4/attachment-0001.html> > >------------------------------ > >_______________________________________________ >Mobile-l mailing list >[email protected] >https://lists.wikimedia.org/mailman/listinfo/mobile-l > > >End of Mobile-l Digest, Vol 55, Issue 9 >*************************************** -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQJABAEBCgAqBQJUN9HNIxxNYXRhbnlhIE1vc2VzIDxtYXRhbnlhQGZvc3MuY28u aWw+AAoJEKzSGXfsOI0vIH4P/AjS2uFlz2xVCBmM8usubrpGq9MvXyn42ZZRYN3p wWaYgq+W/NFl5n4JT0QRHT2+6ix37Xhetkjw3oxOB03ozHEisGbtwWVgfHTgT6QD Jct0mU1G57hxqfYKh1KhWBmpWwR3EfQKzKP1eNC6qsbYqytvOxyNb0srT3yOgI6w wwEU++JgOoIbaBdm+B+lxZnR4virQmwA/Qas0DIBXx1u7kVRlRH3TNp5tfueQwAq it35Nj21lMUQ21cUaYzhOuPd75VcmXLxDglJdUXiPPqldu/MuzFOoDRDQd8KFB2v gj+0mDrY3pj6ksKb1RztTixpJeiOGnPu57AUXQ3p4C+Pny+/iTI988XRmki8/qL7 ZvtSkwhspAvYC7RvjbX1fsXyc0JAVGXgTL5TVM1vDOACtA9m2I2NNuKiDm8KaV7O zHaXuf/RnA53RV9FJ3SPn0L2hp030c87Kw69M/WH/xDbTYZ8J7L8NMses017UnoL HEB/1s1WLJLx85F6EXh+SpcpgvUly5pEAJnco5xItAHCR5mLXSG6eYWp22jhOGgZ vnO0GPgoGQvg1TNCivHlya5ztE3LEao/vcl6qCvW+aqsdK4tEM9p7TQMZwC6vDLq YnxvJhyQ96t02Gs+tUqZSQ4qXQuh8WjeeMTXNPWqjmFqnI/9d16ihpQaHQXyFtba YKKg =8aR1 -----END PGP SIGNATURE----- _______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
