//========= CDI TSWG MAD Meeting =============//

24Jan2012

Attendees

Tim Kern (Lead, Presenter)

Brylian Foronda

Burl Goree

Cian Dawson

Dave Govoni

David Maltby

Derek Masaki

Greg Gunther

Jennifer Carlino

John Aguinaldo

Megan Hines (Presenter)

Mini Methew

Scott McEwen

Travis Lawall


 

@USGSted Project


 

Tim Kern (ppt) talked about USGSted Project (conceptualized by Paul Earle, National Earthquake Information Center), using Twitter as a means to support science.  ted = Twitter Earthquake Dispatch Project.















 

Proposed CDI Twitter Project:  Citizen Science Observation Platform - Using Curated Twitter and GeoRSS Enabled Feeds


 

Derek Masaki and Megan Hines ...


 

from Cian Dawson:  You can't DM an account on twitter unless they are already following you & have their account set to accept DMs.

from Cian Dawson:  Might want to talk to NOAA about their project http://www.nws.noaa.gov/stormreports/


 

O'Reily has printed a useful pub called ...


 

Open Discussion


 

"Augmented Reality" (Derek Masaki) will be the topic in 2 weeks, Feb 7.

"Fish Passage Barriers" (David Maltby) will be the second topic.


 

On Feb 21, ... (NY)


 

New York City Cricket Crawl & Hawaii Croci Frogs - Citizen Science events (Derek Masaki)


 

//========= CDI TSWG MAD Meeting =============//

29Nov2011

Attendees

Scott McEwen

Dave Govoni

Steve Tessler

Elizabeth Sellers

Nina Chenkeli

Julie Recker

Sarah Courchesne

Jeremy Newson

Tim Kern


 

Invasive Species Partnership


 

iMapInvasives -- tool to engage citizen scientist and for resource manager. iMapInvasives started as a desktop site, tried to leverage open source software. Backend - PostGre + PostGIS. OpenLayers front-end + hmtml5 and CSS.


 

Soon after launch of online site, a lot of citizen engagement that requested app for smartphones. This resulted in brainstorming about apps -- investigated native vs. browserbased apps. Intention is pretty simple, so keeping it to collect observation data and observation data.


 

iMapInvasives is devised to replace Nature Conservancy's weed information system. So there is intention to build a more robust tool. One of the issues that is pushing towards at a out of the box solution, is that a lot of NY  state doesn't have good network connections. So browserbased apps may not be a the best solution. Hoping push for html5 and more browserbased apps would push it to that direction as HTML5 matures along w/ universal broadband coverage.


 

Determine the best way to engage citizen scientists for NY state. NY has prisms --


 

prism - partnerships for regional invasives management


 

prism is the link to NYNHP's link to citizen scientists and other projects involving invasive species.


 

iMapInvasives: this is a tool to view invasive species data -- online training on youtube. if you're not a imap user, you can still view 10 most common invasive species across the NY state. Allow to look up species by state, county,


 

screenshots of iMapInvasives dashboard -- functionality overview.


 

iMap developed over time and initially displayed point data adn later used clustering techniques.


 

Observation Desktop data entry: who/ what/ when/ where


 

Mobile App:

- What would be the best way to do a mobile app for this? Researc shows UCLA has an app framework (What's Invasive) that could be leveraged. Issue is it doesn't allow as many species as NYNHP has (300). Can be used locally for collecting common invasive species (maybe 10 or 20). Focus on common invasive species b/c it helps w/ early detection. This will send email alert to people who are concerned. Also most citizen scientists are most useful w/ detecting common species.


 

Since then the app has been used w/ a changed CSS stylesheet.


 

Another app -- an app called iGIS. It has a lot of advanced features -- can use Shape files, and can work w/ ESRI products. Can be customized w/ custom base map.


 

Currently focused on browser based mobile app -- allows the best amount of coverage (no full time developer to focus on different platforms) and also easier to maintain code base. Currently working w. iOS and Android, but would like to include BB as well.


 
 

Browser Based vs Native App


 

Browser:

Largest pro is single set of code base (just tweak css), cross platform, data directly uploaded to cloud, access to content.


 

Con: Neet to be connected (need to make it a cacheable app -- this is still in progress ), hardware limitation (cannot invoke a camera programmatecially), less "App-ish" (advances being made in making it more app looking)


 

Native App:

Pros: familiar look and feel. Disconnected use. Access to device species hardware/OS API.

Cons: Device specific develpoment (ROI high), updates much more time consuping, dealing w/ TOS/APP store


 
 

Boyond Citizen Science: tring to get an advanced data entry app for


 

Assessment: polygon showing localized distribution, disturbance, maturity and densitiy of a local invasive.


 

Treatment: steps taken to remove or control invasive barrier, bio-agent, chemical (herbicide, pesticide), fire, grazing, mechanical, shooting, trapping


 

Survey: Intentional and systematic searh for a specific invasive surpvey type


 

Occurrence: group of geographically similar observations of a single species. -- this means a species can be submitted by multiple cit scientist.


 

Scientists & Land Managers -- Browser based vs. out-of the box app:


 

Brwoser:


 

ros: single set of code, cross platform, direct to cloud, access to content online, free

Cons: neeed to be connected, hardware limits, less app-ish


 

Out of the box:


 

Pros: functionality already built, customizable, disconnected or


 
 

Out of the box solutions:

Open datakit (ODK) --> sponsored by google

Episurveyor

Cyber Tracker

Phone Gap --> allows to create a wrapper around a browser based app and make it native


 

Free Software:

ArcPAD (windows mobile)

ArcGIS Mobile (iOS, Droid, Windows)

Trimble Terrasync (windows mobile)

Pendraggon forms (multiple)

iGIS (iOS)


 

Mobile apps are currently lagging behind the desktop site, but in the future that will most likely become the primary method of data collection.


 

Q&A:


 

Issue w/ PhoneGAp -- was bought by Adobe.

Tim Kern's group is concerned. So using both Phone GAp and Titanium. Haven't tried deploying PhoneGap through App Store.


 

Developer for iMapInvasives is a big Open Source fan and is using a lot of interesting

HTML to Python -- Jango


 

Can all the functionality be implemented using HTML5?

Most functionality required can be implemented using HTML5, but currently biggest limitation w/ web browser based app is not being able to submit a phone directly.


 
 
 
 
 
 
 

//========= CDI TSWG MAD Meeting =============//

15Nov2011

Attendees

John Aguinaldo

Scott McEwen

Megan Hines

Tim Kern

David Maltby

Travis Lawall

Julie Recker


 

Global  Feducials website


 

Geared for desktop but also building in features for mobile


 

YUI3 was used -- one of the only major library that does not distinguish between mobile and desktop -- this was picked so that apps developed for desktop using this library could be ported w/o work to tablet. Drag components also need to work.


 

Another strategy is to detect how much screen space is available.


 

Demo of GFP website - currently not even in Beta. Working to get minimal functionaliry in it.


 

Entrance by searching on keywords (can search by regions).

Goal of this website is to allow users to explore the imagary w/o having to download the images.


 

Have tools built in to do location based searches.


 

Initially no testing for mobile compatibility but no major issues as the libraries originally picked is mobile compatible.


 

ipad demo -- everythjing works except for the hover event


 

Mobile coding issues:


 

Dynamicallly size page elements


 

Custom build libraries for minimal load -- YUI3 is already modular. You don't need to load the entire library


 

Leverage accelerometer for map navigation


 

OpenLayers -- a lot of the mobile featuers is already built in. But there are specific contls that you can override.


 

YUI3 -- graded browser support. Attempt to be compatible with 99% of the browsers unlike jQuery or Sencha Touch.


 

YUI3 is more of a web framework with MVC built-in. Makes it much more easier to do large projects. Has no issues w/ cross-browser compatibilty.


 

YUI using GitHub


 

leaflet.js -- new mapping library


 

internal usgs code repository


 

cloudMade


 

SVG is the way to go -- styling lines on the fly. On the user end customizing their own apps.


 

ArcGIS  canvas libraries --


 

//========= CDI TSWG MAD Meeting =============//

02Aug2011

Attendees

Dave Govoni

Shiji Thomas


 

USGS Mobile Applications Development Support Framework "Pre-Proposal" -- scroll down to bottom of:  https://my.usgs.gov/confluence/display/cdi/CDI+FY12+Proposal+Ideas


 

AE (Enterprise Web) GMU student with some experience and interest: Christopher G Hill <chill@usgs.gov>


 

//========= CDI TSWG MAD Meeting =============//

19Jul2011 : Appcelerator - Lessons Learned

Attendees

Farial Shahnaz (Lead)

Abby Benson

Brad Williams

David Maltby

Julie Recker

Scott McEwen

Shiji Thomas

Travis Lawall


 

Presentation:  Appcelerator - Lessons Learned by Travis Lawall


 

Appcelerator, ($2,400/year; may be less now) a JavaScript toolkit, supports multiple mobile platforms and greatly decreases developer's time, but the developer must still deal with exceptions with each platform.  Therefore, code is focused on iPhone.  However, still helps keep code consistent across platforms. Appcelerator fills a gap until HTML 5 is fully implemented/deployed.


 

Demo of "Species Spotter" for citizen scientists to input tree species, river bank, and photo; app automatically geotags location.


 

Making it easy on the user to access

Interface design challenge: what controls to pick

Do a lot of Beta testing

Taking into account network connection -- when to cache


 

Demo of "I felt it" to display world-wide earthquakes from last 24 hours and last 7 days.  iPhone user can view quake locations and data, as well as add experiential info about a given quake.


 

Used RSS feeds:  last 27 hours and last 7 days.

Device orientation affects design decision

Native picker was slow; wrote own.

Uses table views to manage layout; easier to resize when adding rows and columns.


 

Demo of "KitchenSink"?

Created Android app w/ PhoneGap, but Appcelerator seems to have more capabilities.


 

Please email rviger@usgs.gov if you are not able to access http://usgs.titanpad.com/cdi-tswg-mad .  


 
 
 

//========= CDI TSWG MAD Meeting =============//

05Jul2011 : Overview of HTML5


 

Please email rviger@usgs.gov if you are not able to access http://usgs.titanpad.com/cdi-tswg-mad .  


 

Attendees

Alan Vaughn - new member

Gary Fisher

Shiji Thomas

Julie Recker

Burl Goree

Megan Hines

Don Holmes

Dave Govoni

David Boldt

Mark Hamil

Tim Mancuso

Brad Williams

John Baer

David Maltby


 

----


 
 

//========= CDI TSWG MAD Meeting =============//

21Jun2011


 

Please email rviger@usgs.gov if you are not able to access http://usgs.titanpad.com/cdi-tswg-mad .  


 

Attendees

Jeremy Newson

Mark Hamil

Abby Benson

Scott McEwen

Farial Shahnaz

Megan Hines

Dave Govoni

Mark Kutsko

Travis Lawall

David Maltby


 

- Should we focus on a specific platform at first or should we do a broad overview? May need ot poll the group to determine interest.

Development


 

- Looking forward we need volunteers to discuss different topics such as best practices, mobile web vs. native app, etc. Unfortunately, we don't have anyone on the call that has done development.


 

- Mark Hamil -- high level overview


 

- Don't have access to the camera and file system in many of the phones so development depends on what you want to do.


 

Maybe there needs to be a matrix of the different technologies out there and the pros and cons of each?? e.g. HTML5/PhoneGap/RhoMobile/Adobe Air


 
 

Sessions:


 

July 5: HTML5 overiew -- David Maltby / mobile web app: David Maltby -- HTML5 app for mobile web -- adobe web premium 5.5 - flex -- helps determine fish passages (this is not HTML5 it is Flash). David Maltby


 
 

I have an HTML5 app that shows AHPS sites that you can click and get the current gage height.


 

Basic info: What do you need to get started? What tools need to be in place? -- Start with mobile web.


 

July 19:

Travis Lawall -- appcelerator/phoneGap -- javascript engine wrapper -- developed for both Android and iOS. Technical details:

Appcelerator (?) on iphone thinking about using phonegap.  Good give a demo factoring based on the UI.)

+ lessons learned + best practices.


 
 

Aug 2:

UI questions: Megan Hines, Dave Govoni,


 

Epicollect -- perhaps get the developer to present - Megan H.

+ other Data collection apps -- make or buy scenarios.


 

Sept

Maybe there needs to be a  matrix of the different technologies out there and the pros and cons of  each?? e.g. HTML5/PhoneGap/RhoMobile/Adobe Air


 
 
 
 

Brad Williams - Android


 

- Don't have access to the camera and file system in many of the phones so development depends on what you want to do.


 

//========= CDI TSWG MAD Meeting =============//

07Jun2011


 

All, please email rviger@usgs.gov if you are not able to access http://usgs.titanpad.com/cdi-tswg-mad . If you log in, you will be able to help us with note taking (i.e., making sure I don't type your name wrong).


 

Attendees

Dave Greenlee (National Map)

Patty Damon

Mark Kutsko

Brad Williams

Shiji Thomas

Julie Recker

Scott Horvath

Doug Duncan (?)

Mark Hamill

Travis Lawall

Mark Wimer

Jeremy Newsom

Roland Viger

Jon Richards

Pete Cinotto

Abby Benson

Rob Wertz

Dave Govoni

Bob Matthias

Tim Kern

Robert Swanson


 

[see notes just below the agenda text]


 

Agenda:



 

PDE Goals:





There are repos available: cr.usgs.gov and then the sciencebase repo (for non-USGS)


 

Enough overlap between PDE and MAD to combine the two groups


 

Terms of service: What does it mean for Apple or Andoid SDK, Appstore ?

TOS for using the Apple SDK and then also another for AppStore.


 

How to promote USGS visual identity, come up with a model to get credit.


 

CDI workshop discussion session: discuss how to accomplish this goal.


 

Plan for reaching out to third party developers -- page on wiki for gathering ideas.


 

-----------------------------------------------------------


 

Best practices for QR code,


 

Action: Review goals of PDE and MAD and come up with a combined group goal.


 

USGS Publishing process: need details.


 

Looking into other DOI agencies to see how they have launched native apps. -- citizen science mobile apps. BLM. NPS.


 

http://whatsinvasive.com/


 

http://www.dmg.gov/index.php


 
 

Discussion/Question/Issues:

CDI: management driver or grass roots?

Sponsor : Kevin G. Lot of work going on at grass roots level, and it's a combination.


 

Central repository for services/apps approved by USGS/DOI?


 

Action: Get in formation from Scott H. regarding these services/apps. -- provide DOI and PDE URLs to MAD.


 

CDI is a Community of Practice -- a grass roots learning/knowledge sharing environment sanction by management. -- not strongly top down by design -- place to do your homework and where the informatics R & D takes place


 

Scott Horvath mentioned a worry about people going straight from the idea to production without putting the necessary steps inbetween -- group is maybe too new for this part of the discussion right now

 - Where do we get this information

 - Is there a place to find this information- resource on DOI internal site- have a list put together for USGS


 

Mobile app dev: operational direction


 


 


 








 

Senion leve executinve sponsor : Rich Freizer, Kevin G, -- have Kevin send out a survey.


 

Liason to Fundamental Science Practices.


 

Wiki cleanup.


 
 

- this is a new group.

- what is CDI? Sponsored by CSS, Kevin Gallagher. Not a top-down organization. Tries to discover, build consensus on best practices. Degree to which new work is "forced" to adopt these is not usually debated here. MAD might be special. There are somewhat strong policy implications about developing and distributing applications.

- purpose of group is to establish ideas of best practices to help push these up to policy makers.

- Folks ask for content to be added to MAD wiki. Cross link to Sharepoint from CDI.

- PDE group separate from CDI group? No need for this to happen because there is significant overlap

- PDE group was a lot like what MAD aspires to. Definitely focused on getting our needs up to DOI.

- source.cr.usgs.gov (USGS only)

-sciencebase source also available (open source, available to all) completely different than the publication stuff

- These apps are happening for USGS field work terms of service is platform or publication?

- Apple: 2 terms of service agreements

    -1 to just sign up (pay for) - DOI will not allow anyone to sign (check the box) for this

    -2 one to get the app published in the app store

- Android also has non-govenrment friendly agreements to sign

- Google and android having a little bit of spat right now - nothing getting accomplished

- So right now the app development group can't actually develop any apps

- Trying to compile a list of info to take to Rich Frasier to get DOI to move forward to be able to sign off on them--- but need justification for why this is important --- also reach out to third party developers to allow them to do the apps in the private market with access to our data

  - If USGS is constrained maybe we can open it up to private industry to use USGS data (like water)

  - BUT right now we are not the face for our data because others take it and develop these apps with it -- we need to be the face for our data -- we need to get credit for our data -- but our data is public domain data and should be available for others to use and we should ask for credit -- shouldn't duplicate effort that is already going on out there

- By having a working relationship with private app developers they are more likely to give us credit for our data

 - We need to have a business plan to work with third party app developers

 - Could discuss this at CDI Workshop about how to work with third parties to give us credit for our data- work with us to give us credit -- can have a page on the wiki for gathering ideas about working with third party app developers

- USGS data is public domain data so you can't restrict access to it- basically we can't force third parties to give us credit

- Also need to be looking at citizen science

- If we use web apps then don't have worry about service agreements

- Part of this group is to provide guidance on when to use web apps rather than native apps

- We need to build the information on policy hopefully Scott can help us do that

- We are missing the people who are developing- how do we get these people involved? They will see it as we want to stop what they are doing and that's not true.

- We are building a list of the mobile apps being develop- how do we reach everyone who is developing an app?

- Need best practices on making sure you are sending people to a mobile friendly page (so not just apps)

- Useful to know when an app has already been developed - needs to be built in to the development process

- Can we really compile a list of all the apps using USGS data- seems too big for this group to do - we need a more formal method to address this issue

- We write lots of different programs- how will all of this information apply to those?

- We have survived so far because the source code is published

- Need Privacy Impact Assessment needs to be done (access to personal data on that phone) to determine if there is any private info being collected (ie GPS location of phone) turns into a collection of records that has to be managed - makes DOI hesitant to move forward

- Circular discussion- we are going to have all these internal apps that we have no control over

- We have to build use cases for the native apps to submit to DOI so we don't have to have third party apps all the time- this group could work on that

- Traditional method for this is the publication process - fundamental science practices route

- What's Invasive?- app with the NPS and UCLA; Desert Managers - app for location of desert tortoises- citizen science type of apps for invasive or endangered species - Maybe could talk to the people who (probably .org or .edu that did the development)

- If USGS is not the primary partner then we are just providing the data

- NPS probably just went out and did it without permission- ran in to trouble with Google

- Agreement that we need a session at the CDI Workshop to discuss these topics more fully

- We need an executive sponsor - makes the most sense to go to Kevin - can work with Rich Frasier - Kevin needs to send something out to everyone

- What are we going to do about maintenance of the apps - who pays for those updates? How do we get them done?


 
 

Observation: discussion on "getting credit" for applications should include "branding" and maybe "watermarks" for authoritative data sources - also, we need to have friends outside USGS (and the executive part of the government) in order to communicate with Congress in a mannery that we are precluded from doing.


 
 

//========= CDI TSWG MAD Kick off Meeting=======//

Kickoff Meeting for CDI Tech Stack Work Group:

Mobile Application Development (MAD)

SubTeam, May 17, 2011


 

Attendees (please add details to your name)


 



















 
 

Proposed Purpose, Goals, Approach


 

Ideas and comments relative to the ideas and goals Farial presented:


















 

Next Meeting Agenda and Actions