Mobile-l

mobile-l@lists.wikimedia.org

4 participants
6884 discussions

Performance audit example
by Joaquin Oltra Hernandez 06 Jul '15

06 Jul '15

Hey, I saw the other day a performance audit that Paul Irish did for the mobile site of reddit. It is a great audit and a great example of how to do a performance review of a site, I encourage all to carefully read it as we are going to have to do something similar in the following sprints in order to enable us to do more concrete performance work on the mobile website. https://github.com/reddit/reddit-mobile/issues/247 Awesome stuff.

2 3

Mobile MediaViewer and the Seattle Japanese Garden
by Pine W 06 Jul '15

06 Jul '15

English Wikipedia's "Seattle Japanese Garden" article looks good in the Android app, and the MediaViewer-like slideshow feature works well for the gallery. However, I'm unable to scroll through the photos in Mobile Web like I csn using the Android app. Are there any plans to add the slideshow functionality to mobile web? Thanks! Pine

2 1

[reading web] Phabricating in Q1
by Joaquin Oltra Hernandez 01 Jul '15

01 Jul '15

[Long email, sorry] Hi friends, There's been some talk about how we currently phabricate and there doesn't seem to be much satisfaction in our current workflows, and as part of the new team we are getting more software artifacts so we are going to have to adapt to this new situation. For that, I've mapped how we do things now, and proposed how we could move forward to effectively avoid more conphusion (sorry 'bout that). ## Current workflows Reading web currently uses 3 permanent boards + current sprint board. Reading-web: * Type: Team project. * Contains: Epics, bugs, features. * Board: Columns with should have, could have, etc. Mixed columns. Triaging column. MobileFrontend: * Type: Software project. * Contains: Bugs, tech tasks, features, discussions. * Board: Backlog. Gather: * Type: Team project + Software project (mix between the two above). * Contains: Epics, bugs, tech tasks, features. * Board: Columns with should have, could have, etc. Mixed columns. Triaging column. ### Bugs MobileFrontend bugs are added to MobileFrontend and Reading-web. They get categorized and triaged in Reading-web by team/standup and brought into the sprint if appropriate. Gather bugs are added to Gather & current sprint. Gather is triaged by JonR -- high priority are brought straight into the sprint. ### Features MobileFrontend/Gather features added to Reading-Web **Needs triage** column. Have MobileFrontend or Gather project added by TechPro as needed. Moved to **Must Have**, **Should Have**, or **Could Have** as necessary ### Problems * Workflow is different for MobileFrontend and Gather. * Boards have mixed responsibilities. * No one place to triage bugs and features. * Reading-Web is *noisey*. * Tasks with several tags -- leads to noise across all projects. * No clear high level overview of Reading-Web workload/workflow. On top of how we are currently working, we are getting a bunch of software artifacts that we are going to have to triage & maintain really soon. We need to adapt to deal with multiple projects/boards and maintain team vision of what we are doing. (Current process probably won't scale well with more than a few software projects). ## Proposal Taking into account that we want to: * Be able to work across multiple phabricator projects for different software artifacts. * Maintain a high level overview of team focus through time (so that we all know what we are focusing on mainly). * Have a clear place to triage for the projects we are responsible for. ### Solution #### phStructure Reading web will use N+2 boards. N+1 permanent boards + current sprint board. * *N being the number of software projects we maintain*. Reading-web: * Type: Team project. * Contains: Epics. * Board: Time based columns, left is closer, right is further on time. (Can be sprint based + Quarter based, or something else) (Ex: In progress | Next sprint | ...). MobileFrontend: * Type: Software project. * Contains: Bugs, tech tasks, small features, discussions. * Board: Backlog | Discussion. Gather: * Type: Software project. * Contains: Bugs, tech tasks, small features, discussions. * Board: Backlog | Discussion. PageImages: * Type: Software project. * Contains: Bugs, tech tasks, small features, discussions. * Board: Backlog | Discussion. TextExtracts: * Type: Software project. * Contains: Bugs, tech tasks, small features, discussions. * Board: Backlog | Discussion. ETC. (same for the rest of the software projects we're getting). Suggestion is that software projects get the same layout, but not necessary. #### Phrocess ##### Bugs and pheatures Such tasks will get submitted against the corresponding software project that involves them. If there is a bug on the mobile web, it'll get submitted to MobileFrontend, if there is a bug with collections, it'll get submitted against Gather. Same for feature requests. If there is a bug on MobileFrontend & PageImages it'll get submitted to both. Default priority *Needs triage* means task hasn't been triaged yet. Each project has tasks that involve that project. Reading-web stays a high level view of the team's focuses through time available for everybody. ##### Triaging We'll have a **saved query** available to everybody to triage (standups or else). Example: https://phabricator.wikimedia.org/maniphest/query/c_ZQlOwVk9I8/ (note this looks like shit because we don't use priorities at all right now). When triaging a bug, we'll set it's priority to something that makes sense regarding severity and add to current sprint project if priority is high. When triaging a feature, we'll set it's priority to something that makes sense regarding perceived importance and ping product owner. PO should add as subtask of epic if makes sense. ##### Sprint preparation. Task creation. >From the epics on Reading-web we'll spin off subtasks of specific work that'll get tagged with the concrete software project where they need to be acted upon with a priority. Sprint grooming and prioritisation will put subtasks of epics in *Next sprint* into the next sprint board. Also give a pass on work on software artifacts projects that needs to be added to sprint. Then we'll analyse and estimate. ------ I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png (I've tried with the current workflow but I don't even know how to accurately draw it. Sorry). --- What do you guys think? Beginning of next quarter is approaching so it would be great if we discussed this and arrived somewhere better than our current workflow. Thanks! Joaquin

4 8

Re: [WikimediaMobile] [reading-wmf] maps w/ nearby
by Adam Baso 01 Jul '15

01 Jul '15

Moving thread to mobile-l. On Fri, Jun 19, 2015 at 1:43 PM, Yuri Astrakhan <yastrakhan(a)wikimedia.org> wrote: > Hi everyone, sorry for not replying earlier. Ulf, thank you for your offer > to help, and everyone’s support of the map project! > > Here's our accomplishments so far and the approximate path forward: > > We now have built a vector-based Tile rendering service, called > Kartotherian <https://github.com/nyurik/kartotherian> (work in progress). > It is based on the components from Mapbox & Mapnik, and data from > OSM->osm2pgsql->Postgress w/Postgis. > > * Demo Server > <http://ns512621.ip-167-114-156.net:4000/static/#6/40.731/-73.989> > * Project page <https://www.mediawiki.org/wiki/OpenStreetMap> > * Implementation Info > <https://www.mediawiki.org/wiki/Maps/Tile_Server_Implementation> > > At this point, we are implementing a server-side Vector->PNG conversion, > similar to mod_tile approach. But, internally, all data is stored as vector > tiles, and converted to images on the fly. We are capable of also serving > those tiles raw, without rasterisation, but we will still need to do some > extra work to optimize their size at low zoom levels, wait for the complete > font implementation (e.g. Arabic is not showing correctly), and a number of > other minor issues. So client-side vector rendering is pushed for the > second stage. > > Feel free to use the Demo Server > <http://ns512621.ip-167-114-156.net:4000/static/#6/40.731/-73.989> for > any development and testing work. > > > On Fri, Jun 19, 2015 at 3:24 PM, Corey Floyd <cfloyd(a)wikimedia.org> wrote: > >> I've been waiting to follow up on this until I got official clarification >> on WMF's position for using the Apple's framework… >> >> Good news, WMF legal has no privacy/legal concerns with using the MapKit >> framework - so we will be able to proceed with implementing map features >> using the official iOS SDK! >> >> This should make it much easier to develop this feature. >> >> On Sat, Jun 13, 2015 at 7:12 PM, Ulf Buermeyer <ulf(a)ijure.org> wrote: >> >>> >>> Jon, >>> >>> thanks for following up! >>> >>> Just in order to share what we discussed yesterday let me briefly >>> summarize: >>> >>> Last year I submitted a pull request that introduces a simple map view >>> to display places referenced by coordinates mentioned in an article >>> (replacing the somewhat clumsy "look, there are 34 or so map providers >>> on the internet" page). The code was technically fine but not merged in >>> so far for policy reasons as MapViews on iOS display non-free content & >>> hit Apple's servers. >>> >>> So here are the options to move forward: >>> >>> * WMF may revisit the issue and approve use of Apple maps >>> + could be rolled out almost immediately >>> - non-free content >>> - privacy issue? >>> - community may be fond of that map selection page? >>> >>> * the MapView could be quickly tweaked to show nearby places >>> (accompanying the current nearby list) >>> + quick to implement >>> - non-free content >>> - privacy issue? >>> >>> >>> I have also coded an OpenStreetMap layer that can be displayed in an >>> ordinary iOS MapView but replacing Apple map content so it could be used >>> in both scenarios mentioned above to avoid hitting Apple servers. >>> + free content >>> - some time to implement (currently running in one of my apps but not >>> yet transformed into a separate component) >>> >>> >>> As for the OSM tiles to display in said layer, there are once again >>> three options: >>> >>> * set up WMF tile rendering infrastructure >>> + control over tile design >>> + download from WMF servers -> no privacy issue >>> - HUGE impact on engineering & operations resources >>> >>> * cache official OSM tiles >>> + download from WMF servers -> no privacy issue >>> + small impact on operations, little engineering >>> - some tile expiration logic / tweaking needed >>> - need to consult with admins: >>> http://wiki.openstreetmap.org/wiki/Tile_usage_policy >>> >>> * proxy official OSM tiles >>> + download from WMF servers -> no privacy issue >>> + small impact on operations, practically no engineering >>> - OSM guys from the UK may have concerns regarding load on their >>> infrastructure >>> - need to consult with admins: >>> http://wiki.openstreetmap.org/wiki/Tile_usage_policy >>> >>> Hope that helps, happy to help. >>> >>> Best, Ulf >>> >>> >>> >>> On 12/06/15 18:08, Jon Katz wrote: >>> > Hi All, >>> > Tilman brought Ulf (copied) to the office today and it was great and >>> > energizing to sit down with him and hear his thoughts on maps and >>> nearby >>> > options. As Tilman said earlier, Ulf has already done some work in >>> this >>> > area and is happy to help out. He also has some ideas about how we >>> > could make things scale. I think the only thing holding him back right >>> > now is not knowing where he can add the most value. >>> > >>> > I encourage Corey, Dmitry, Yuri and Max, in particular, to include Ulf >>> > in any conversations about this moving forward. >>> > >>> > -J >>> > >>> > On Fri, Jun 5, 2015 at 4:55 PM, Tilman Bayer <tbayer(a)wikimedia.org >>> > <mailto:tbayer@wikimedia.org>> wrote: >>> > >>> > Hi all, >>> > >>> > as it happens, Ulf (CCed, the author of last year's GitHub pull >>> > request >>> > <https://github.com/wikimedia/apps-ios-wikipedia/pull/3> that >>> Brian >>> > mentioned; he is the developer of a fairly popular geolocation iOS >>> > app <http://mapalarm.net/wp/> and runs his own OSM tileserver) is >>> in >>> > SF again currently; we'll have lunch early next week. He would be >>> > delighted to come by the office and chat with people working in >>> this >>> > area. (IIRC Max, Monte and Brion already met him last year, which >>> > led to that pull request.) Would some of the apps/maps people be >>> > interested in talking to him around 2pm on Monday, say? >>> > >>> > I showed Wikiminiatlas <https://wma.wmflabs.org/> to Ulf yesterday >>> > and he would be excited to use it to update his iOS app patch for a >>> > proof of concept that's in line with the privacy policy. I guess he >>> > could also use the new Karta server instead for something more >>> > production-like. >>> > >>> > >>> > On Wed, May 27, 2015 at 3:32 PM, Yuri Astrakhan >>> > <yastrakhan(a)wikimedia.org <mailto:yastrakhan@wikimedia.org>> >>> wrote: >>> > >>> > Disclaimer: I do not know much about the specifics of the iOS >>> > implementation, so can only speak about overall approach and >>> > possible concerns. >>> > >>> > * Per WMF privacy policy, we cannot use outside servers if that >>> > exposes our user's browsing behaviour. Thus any outside servers >>> > must be proxied to be consumable by our users. >>> > * OSM data is not the same as the tiles people see - there is >>> > data (clone of OSM db), there is data tiles (vector tiles) that >>> > only contain the features we try to show on a specific zoom >>> > level for that area, and there is rendering of that data as an >>> > image. From what I have learnt so far, most of the OSM-based >>> > stacks implement "raster tiles" - all images are pre-rendered >>> as >>> > PNGs for speed. >>> > * We are trying to switch to vector based approach, where tiles >>> > are stored as data, and converted to image on request, either >>> by >>> > the server or by the user's browser. Which means that if you >>> > have retina screen, the image will be rendered twice the >>> regular >>> > size, and will be much crispier. This also means that you can >>> > rotate it on your device, or dynamically change the language. >>> > * I suspect, and please update me on this if you know the >>> > details, that the built-in iOS implementation can only handle >>> > images (raster) from the 3rd party (WMF). Mapbox's vector >>> format >>> > is gaining in acceptance, and IIRC, has been selected by OSM >>> > community in general for the future development, but I am not >>> > sure iOS supports it natively. >>> > >>> > On Wed, May 27, 2015 at 10:24 PM, Brian Gerstle >>> > <bgerstle(a)wikimedia.org <mailto:bgerstle@wikimedia.org>> >>> wrote: >>> > >>> > Agree with Corey, I've mentioned this elsewhere >>> > < >>> https://www.mail-archive.com/mobile-l@lists.wikimedia.org/msg03395.html >>> >, >>> > but it's important to note that as of iOS 6 >>> > <https://blog.openstreetmap.org/2012/10/02/apple-maps/>, >>> > Apple has been (and still appears to be >>> > < >>> http://applemapsmarketing.com/2014/11/open-street-map-apple-maps/>) >>> > using OSM for map data. I don't know the rationale behind >>> > why we need our own OSM servers, but does that rationale >>> > also prevent our iOS app from using Apple-provided OSM >>> data? >>> > >>> > >>> > On Wed, May 27, 2015 at 4:05 PM, Corey Floyd >>> > <cfloyd(a)wikimedia.org <mailto:cfloyd@wikimedia.org>> >>> wrote: >>> > >>> > Any reason to import a 3rd party library for >>> > functionality built in to the iOS SDK? Seems like work >>> > to explore/integrate a dependency where none is needed. >>> > Without this extra work, this is something that can be >>> > built in < 1 day. >>> > >>> > >>> > >>> > On Wed, May 27, 2015 at 10:01 PM, Brian Gerstle >>> > <bgerstle(a)wikimedia.org <mailto:bgerstle@wikimedia.org >>> >> >>> > wrote: >>> > >>> > Cool, looks like mapbox has an iOS SDK >>> > <https://www.mapbox.com/mapbox-ios-sdk/>. Is >>> there >>> > somewhere that the progress on funding is being >>> > tracked? Put another way, where should I direct >>> PM, >>> > design, etc. to get this prioritized? Also, I >>> think >>> > it'd be worth it to ship this to a percentage of >>> > users to (further) validate the feature. >>> > >>> > On Wed, May 27, 2015 at 3:56 PM, Yuri Astrakhan >>> > <yastrakhan(a)wikimedia.org >>> > <mailto:yastrakhan@wikimedia.org>> wrote: >>> > >>> > Current state of affairs: >>> > https://karta.wmflabs.org/static/ is up and >>> > running, and should have all the data soon. It >>> > uses mapbox stack, which means that it >>> generates >>> > vector data tiles, and creates a PNG tiles on >>> > the fly. This also means that in a few days, >>> you >>> > will be able to view WebGL based maps there too >>> > - rendered on the browser, with multiple >>> styles, >>> > and rotatable. >>> > >>> > The community needs this service, and has >>> > already built a large number of amazing >>> projects >>> > even without the production-level vector >>> > service. Examples include >>> > * atlas-style drill-down map >>> > < >>> http://umap.openstreetmap.fr/de/map/wikipedia-clustermap_36725> >>> > (umap, see more info >>> > <http://umap.openstreetmap.fr/>) >>> > * Wikidata-based map of pages by class >>> > < >>> https://tools.wmflabs.org/wp-world/wikidata/superclasses.php?lang=en>, >>> > e.g. all rollercoasters >>> > < >>> https://tools.wmflabs.org/wiwosm/osm-on-ol/kml-on-ol.php?lang=en&uselang=en… >>> >. >>> > * There is an amazing presentation >>> > < >>> https://tools.wmflabs.org/wp-world/docs/ICC2013-WP-OSM-white.pdf> >>> > (pdf) by Kolossos (Tim Adler), that gives many >>> > more examples of the community-built map >>> > services and projects (OpenOffice format >>> > < >>> https://tools.wmflabs.org/wp-world/docs/ICC2013-WP-OSM-white.odp>) >>> > >>> > >>> > P.S. Tomasz, it's Yuri, not Yuvi, and don't >>> > blame IRC auto-complete :) >>> > >>> > On Wed, May 27, 2015 at 7:57 PM, Max Semenik >>> > <maxsem.wiki(a)gmail.com >>> > <mailto:maxsem.wiki@gmail.com>> wrote: >>> > >>> > Hey - yes, we're workig on serving map >>> > tiles. Both raster and MapBox vectors. Our >>> > current demo implementation is >>> > at https://karta.wmflabs.org/static/ - >>> only >>> > raster tiles ATM, vectors coming in 1-2 >>> > days. The main problem, however, is >>> > budgeting - yet if we get very little >>> > hardware, concentrating on maps for apps >>> > might even be a reasonable option as apps >>> > traffic might be lower than if we exposed >>> > maps to all web users. Getting no bugdet at >>> > all is also a possible outcome, though. >>> > >>> > >>> _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org >>> > <mailto:Mobile-l@lists.wikimedia.org> >>> > >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> > _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org >>> > <mailto:Mobile-l@lists.wikimedia.org> >>> > >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> > >>> > -- >>> > EN Wikipedia user >>> > page: >>> https://en.wikipedia.org/wiki/User:Brian.gerstle >>> > IRC: bgerstle >>> > >>> > _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org >>> > <mailto:Mobile-l@lists.wikimedia.org> >>> > >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> > >>> > -- >>> > Corey Floyd >>> > Software Engineer >>> > Mobile Apps / iOS >>> > Wikimedia Foundation >>> > >>> > >>> > >>> > >>> > -- >>> > EN Wikipedia user >>> > page: https://en.wikipedia.org/wiki/User:Brian.gerstle >>> > IRC: bgerstle >>> > >>> > >>> > >>> > _______________________________________________ >>> > Mobile-l mailing list >>> > Mobile-l(a)lists.wikimedia.org <mailto: >>> Mobile-l(a)lists.wikimedia.org> >>> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >>> > >>> > >>> > >>> > >>> > -- >>> > Tilman Bayer >>> > Senior Analyst >>> > Wikimedia Foundation >>> > IRC (Freenode): HaeB >>> > >>> > _______________________________________________ >>> > reading-wmf mailing list >>> > reading-wmf(a)lists.wikimedia.org <mailto: >>> reading-wmf(a)lists.wikimedia.org> >>> > https://lists.wikimedia.org/mailman/listinfo/reading-wmf >>> > >>> > >>> >> >> >> >> -- >> Corey Floyd >> Software Engineer >> Mobile Apps / iOS >> Wikimedia Foundation >> > > > _______________________________________________ > reading-wmf mailing list > reading-wmf(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/reading-wmf > >

1 0

Freedom of Panorama banner campaign breaking mobile
by Jon Robson 01 Jul '15

01 Jul '15

I noticed a banner on the mobile site that renders the site unusable: http://imgur.com/qVGz3mZ I'm not sure who is responsible for "Freedom of Panorama in Europe in 2015" but can someone disable this on mobile asap or make it work on mobile? Please also reach out to us on the mobile-l mailing list ahead of running these campaigns if you are unsure how to test campaigns, we're happy to help. Jon

4 8

[Apps] Android Wikipedia beta app release (2.0.105-beta-2015-06-30)
by Stephen Niedzielski 01 Jul '15

01 Jul '15

Hello! The Android team[0] is delighted to announce a new Wikipedia Android app beta release, v2.0.105-beta-2015-06-30[1]. This revision is largely a maintenance patch[2]: * Fix full-text search in main Search bar * Preserve search results across screen rotation * Fix crash when rotating with highlighted text * Fix sporadic article back history crash Make it better! Read our getting started guide[3]. We can't wait for your contributions! [0] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team#Android_App [1] Rolling out at https://play.google.com/store/apps/details?id=org.wikipedia.beta [2] A complete list of changes is available at http://git.wikimedia.org/compare/apps%2Fandroid%2Fwikipedia/beta%2F2.0.104-… [3] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_ha…

1 0

Skins Usage Data
by Adam Baso 01 Jul '15

01 Jul '15

Hi, I think it was Joaquin, Sam, and Bryan with whom I discussed relative skins usage on some popular skins, in the context of which skins Reading is on the hook for in the sense of full maintenance or high priority fixes (even if only coordinating) when issues arise. Here's that data, based on some queries Timo ran recently (thanks, Timo!). * en.wikipedia.org, users active since 2015-01-01, skin=cologneblue: 7k users. * en.wikipedia.org, users active since 2015-01-01, skin=monobook: 193k users. * en.wikipedia.org, users active since 2015-01-01: 3.1m users. * en.wikipedia.org, users active since 2015-03-01, skin=cologneblue: 6k users. * en.wikipedia.org, users active since 2015-03-01, skin=monobook: 179k users. * en.wikipedia.org, users active since 2015-03-01: 2.3m users. * commons.wikimedia.org, users active since 2015-03-01, skin=cologneblue: 1k users. * commons.wikimedia.org, users active since 2015-03-01, skin=monobook: 59k users. * commons.wikimedia.org, users active since 2015-03-01: 687k users. -Adam

6 8

Re: [WikimediaMobile] [reading-wmf] Improving Privacy Policy on Mobile
by Adam Baso 29 Jun '15

29 Jun '15

Moving to mobile-l. Discuss. -Adam On Wed, Jun 24, 2015 at 10:05 PM, Jon Robson <jrobson(a)wikimedia.org> wrote: > cc. reading-list. You'll get more feedback there :) > Short reply: There are lots of bugs and larger problems here that need > to be solved. > > > On Wed, Jun 24, 2015 at 5:42 PM, Jacob Rogers <jrogers(a)wikimedia.org> > wrote: > > Hi Jon, > > > > James A suggested you might be the right person to talk with about > improving > > the readability of the WMF privacy policy on mobile devices. Currently, > it's > > pretty difficult to look at. It starts with the massive language list, > the > > disclaimer renders 1-2 words a line, and the blue boxes also render in > hard > > to read lines as well as pushing the main section to scroll off the > screen. > > > > If you are the right person, what I'm hoping we can do is make the > language > > list into an expandable menu, get rid of the blue boxes on the sides if > > necessary, and possibly make the examples into an expandable view rather > > than have everything shown by default. > > > > If you're not the right person to this, could you forward me on to > someone > > that might be able to help? > > > > Many thanks, > > Jacob > > -- > > > > Jacob Rogers > > Legal Counsel > > Wikimedia Foundation > > > > NOTICE: This message might have confidential or legally privileged > > information in it. If you have received this message by accident, please > > delete it and let us know about the mistake. As an attorney for the > > Wikimedia Foundation, for legal/ethical reasons I cannot give legal > advice > > to, or serve as a lawyer for, community members, volunteers, or staff > > members in their personal capacity. For more on what this means, please > see > > our legal disclaimer. > > > > _______________________________________________ > reading-wmf mailing list > reading-wmf(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/reading-wmf >

2 2

CFP for DIPDMWC2015: International Conference on Digital Information Processing, Data Mining, and Wireless Communications
by Grace Allas 27 Jun '15

27 Jun '15

*** CALL FOR PAPERS *** The Second International Conference on Digital Information Processing, Data Mining, and Wireless Communications (DIPDMWC2015) Islamic Azad University, Academic City, Dubai Dubai, UAE December 3-5, 2015 http://sdiwc.net/conferences/dipdmwc15/ All registered papers will be included in SDIWC Digital Library. =========================================================== The conference aims to enable researchers build connections between different digital applications. The event will be held over three days, with presentations delivered by researchers from the international community, including presentations from keynote speakers and state-of-the-art lectures. RESEARCH TOPICS ARE NOT LIMITED TO: • Digital Information Processing Adaptive Signal Processing Artificial Intelligence Bioinformatics & Biomedical Imaging Natural Language Processing Computer-Aided Surgery Speech Recognition, Analysis and Synthesis Biometric and Pattern Recognition Face Recognition and High-Resolution Imaging Network and Cyber Security E-Learning E-Marketing Parallel Programming & Processing Expert Systems Information Security and Cryptography Multimedia Signal Processing Biomedical Signal Processing Neural Networks and Genetic Algorithms Data Compression and Watermarking Energy Minimization in Cluster-Based Wireless Sensor Networks Video Compression and Streaming Object Detection, Recognition and Categorization Data Modeling for Cloud-Based Networks E-Commerce E-Banking •Digital Information Processing Data Mining Techniques Risk Management and Analysis Multi-Task Learning Data Cleaning and Processing Data Mining for Complex Dataset Data Mining for Customer Retention Data Mining for Business Intelligent Data Mining for Network Intrusion Detection Online Algorithms for Data Mining Ethics of Data Mining Data Classification and Clustering Feature Extraction and Data Reduction Optimization Techniques Text and Web Mining Data Mining for Network/Cyber Security Data Mining for Climate Change and Impacts Data Mining for Social Network Analysis Data Mining for Traffic Control Data Mining and Cloud Computing •Wireless Communication Energy Minimization in Cluster-Based Wireless Sensor Networks Coding and Modulation Vehicular Wireless Networks Wireless Sensor Networks Wi-Fi and Wi-MAX B3G/ 4G Wireless Networks Bluetooth and Personal Area Networks Mobile Management in Wireless Networks IP Multimedia Sub-Systems Mobile/ Wireless Network Modeling and Simulation Wireless Network Standard and Protocols Bioinformatics and Scientific Computing Mobile IP Networks/ Ad-hoc Networks Security and Robustness in Wireless Networks Network Management Wireless Local Area Networks Wireless System Architecture Mobile Database Access and Design Key Management Protocols Mobile / Wireless Network Planning Digital Right Management and Multimedia Protection ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IMPORTANT DATES: Submission Deadline : Open from now until October 30, 2015 Notification of Acceptance: 3- 4 weeks from the submission date Camera Ready Submission : Open from now until November 15, 2015 Registration Deadline : Open from now until November 15, 2015 Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Paper Submission: http://sdiwc.net/conferences/dipdmwc15/openconf/openconf.php Registration: http://sdiwc.net/conferences/dipdmwc15/registration Conference Email Ad: dipdmwc2015(a)sdiwc.net

2 1

[Web] Monday: QA Day
by Sam Smith 26 Jun '15

26 Jun '15

The Reading Web team will be taking time every Monday to QA the mobile site. We're currently lining up work around improving our development, testing, and release processes. In fact, work on improving our browser testing infrastructure has already begun [0]. This work is all about reducing the size of a critical feedback loop: from a developer submitting a patch to a bug being reported. Taking a day every sprint to QA each others work on the beta cluster isn't ideal but it does help us to reduce the size of the feedback loop until we're finished improving our workflows. Here's what I sent out to the team members in the QA Day invite: According to the deployment schedule [1], our latest and greatest code will > be hitting group 0 wikis on a Tuesday. I strongly encourage you to take the > time to test a few common and uncommon workflows across the myriad features > new and old and report any bugs you uncover before the train starts > rolling. You might also want to take a look at a few of the group 0 wikis > on Tuesday too while our development environments don't replicate that of > production. If you find the time after all of this, then perhaps you could > try translating one or two workflows into browser tests (!!!) [0] https://phabricator.wikimedia.org/T100293 [1] https://wikitech.wikimedia.org/wiki/Deployments/One_week <https://www.google.com/url?q=https%3A%2F%2Fwikitech.wikimedia.org%2Fwiki%2F…>

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l