Even more about Edgar

Thanks to my colleague Simon Pockley, you can now view a second video on Edgar, in which Professor Stephen Garnett from Charles Darwin University gives an example of the complex questions and issues that Edgar can help answer. 

The video is about 3.5 minutes long and can be found here:
http://www.youtube.com/watch?v=g8z2yFDYwHI

More about Edgar

One of the projects previously mentioned on this Blog is Edgar, a web based mapping tool looking at where Australia’s birds occur today, and what the impact climate change on their habitats might be. Edgar has three main functions:

1. Users can view where a specific bird has been observed, where it lives today, and what areas would represent a suitable habitat for the bird. The occurrence data underlying Edgar are provided via live web services by the Atlas of Living Australia.
2. Users can view what would happen to the bird’s habitat between 2015 and 2085 in Australia’s projected future climate.
3.  Birdwatchers and experts can correct and classify bird observations, thereby helping to improve the underlying data. These corrections and classifications are sent back to the bird occurrence records data base, held by the Atlas of Living Australia.

This project is now finished, and you can access the software at http://tropicaldatahub.org/goto/edgar.

ANDS has published a short video in which Jeremy VanderWal (James Cook University) and Stephen Garnett (Charles Darwin University) talk about what you can do with Edgar. You can view the video here: http://www.youtube.com/watch?v=szl61Eerfpo

Launch of the SMART Infrastructure Dashboard

The ANDS-funded SMART Infrastructure Dashboard under development at the University of Wollongong’s SMART Infrastructure Facility was officially launched on 9 November 2012, at the “Culture of Innovation” Symposium, part of the new Illawarra Futures Symposium Series, which was held on 8-9 November 2012 at the University of Wollongong’s Innovation Campus.

The SMART Infrastructure Dashboard provides visual, graphical and geospatial data analysis capabilities using publicly available infrastructure utility data. This information, crossed with relevant regional, state and national-level figures from demographics and economics, constitutes a robust foundation for powerful infrastructure analytics. The dashboard acts as a customer centric portal providing easy, transparent and intuitive access to primary data and information creating a better understanding of the complex relationship between infrastructure operations and uses across major utilities. It offers a flexible collaborative platform to local planners, researchers, business analysts and citizens.

Professor Pascal Perez presented the SMART Infrastructure Dashboard to an audience representing a number of Illawarra Businesses, federal and state government agencies, local councils, as well as the University of Wollongong. His presentation included a series of scenarios illustrating how the dashboard could help service providers and consumers make more informed decisions. A lively Q&A session followed, with a number of councils interested in getting involved and providing their data.

Media coverage of the launch: http://www.illawarramercury.com.au/story/1121741/uni-builds-web-dashboard-to-monitor-data/?cs=300

If you would like more information about the SMART Infrastructure Dashboard, please contact Neil Webster, Projects Manager, SMART Infrastructure Facility on +61 2 4221 4716 or webster <at> uow <dot> edu <dot> au.

The Proteome Browser mentioned in WIRED

The Proteome Browser being developed by the AP32 team at Monash University for the global proteomics community has been mentioned in an article about the Human Proteome in "The WIRED World in 2013" - a 'what's hot in 2013' special issue from WIRED magazine:

The full issue is:

• downloadable from within the Wired UK app on iTunes/Kindle/Android

• downloadable from tinyurl.com/wiredworld2013

• on sale in shops now

Key Apps Deliverable #8 - Final Product Post

All Applications projects have a common deliverable "Deposit of the software in an open source code repository such as Google Code, SourceForge or GitHub, ... ".  (it is usually numbered D8). To meet this deliverable, a Final  Product Report is required.  There are two options:

Option 1: 
For projects that chose not to blog, please ask your ANDS contact for the report template.
Please note that even if you choose this "non-public" version,  your ANDS contact may write a post for the ANDS Applications blog site based on the content you provide in the report. 

Option 2:
For projects that chose to blog, please write and publish a post to your Blog. The post should cover the following aspects:


1.     Introductory Product Information

·         The Name of your product (note: this can be different from the name of your project, especially if the name is more understandable/interesting for the user of the product)

·         The primary users of your product, e.g., researchers (what fields / areas?), policy makers, etc.

·         A simple "elevator pitch" for your product directed at your users that explains what problem or what situation your product is going to solve for them.

2.     Instructional Product Information

·         What is the use case for how the product is going to be used? Please tell a real story of how this product has been used by your users (e.g. Research and/or Policy Champion) and the real world effect it has had upon them. Don't be afraid to talk about a real user (with their permission) and quote what the user said for context.

·         Links to the actual product. This could be to several different "things", for example: If the product is an application for downloading on a computer or phone, a link to where the app can be downloaded, e.g. perhaps create a nice button to click on to signify this is the product.

·         Step-by-step end user documentation: this should include links to the project blog as well as to   the public source code repository. Please explain to them in a step-by-step way how they actually can start using the product right now. This could be in the form of a screencast or an Ikea-like instructional manual or any other clear guidance for how your intended user can use this product right now. (e.g. http://jcu-eresearch.github.com/Edgar/userguide.html).

·      Technical documentation (NB if you are using the a blog for your living SRS, then this should just be a matter of listing links as a table of contents for how the technical documentation relates to the final product).  Naturally these links should also reference the links to the files within the Source Code repository as it relates to the final product.

·         Don't forget pictures or (simple) diagrams for 'selling' the product to the user. If you have authorized testimonials from users, you could link to those.

3.  Product (or Product Components) Re-usability Information

·         If a product or its components can be reused in other contexts, please specify the reusable components and describe in which contexts they are reusable.

4.     Contextual Product Information

·         Licensing of final product, this should include both creative commons and any applicable code licenses, as well as a declaration by the team for how their commitment to assuring the product is available beyond the life of the product for reuse by others.

·         Sustainability: A deliberate effort should be made to explain the ongoing status of the product (under active development, in maintenance mode, orphaned, mature, etc).

The ‘final product posts’ should be simplified and made easy to understand by others in the sector.  Accordingly, ANDS will organise a panel of previous ANDS projects to review and provide (private) feedback to the project on their final product.  Therefore your 'final product post' should act as a product advertisement that will engage a range of users working in Academia.

Please assign the following TAGS to your post: andsFinalProduct,  andsApps,  andsProduct,  fundedByAustralianNationalDataService, DIISRTE, {your project's acronym or tag}, {your ANDS project code, e.g. AP67}, {any other keyword tags you can think of that will help your project be discovered by like-minded projects}.

Key Apps Deliverable #5 - Deployed, tested and documented software system

All Applications projects have a common deliverable "Deployed, tested and documented software that:  ...".  (it is usually numbered D5). To meet this deliverable, a User Acceptance Testing Report is required.  There are two options:

Option 1: 
For projects that chose not to blog, please ask your ANDS contact for the report template.
Please note that even if you choose this "non-public" version,  your ANDS contact may write a post for the ANDS Applications blog site based on the content you provide in the report. 

Option 2:
For projects that chose to blog, please write and publish a post to your Blog. The post should cover the following aspects:

1.     The Application

What does the software application do? -  You could e.g. describe the application in a series of screendumps / illustrations with some accompanying explanations, or if the software application is web-accessible, a link to the application with accompanying explanations.

For an example, please see  http://jcu-eresearch.github.com/Edgar/Management/2012/08/29/announcing-edgar/

2.     Who are the Users and the Testers?

What are the typical groups / types of users?
What are the user characteristics of each user group?
What are main tasks that each user type / group will perform with the application?
Please list / name the testers who have been involved in the User Acceptance Testing, and specify which user group a tester represents. If you do not want to make that information public, you can anonymize the users for the Blog, and provide their names to your ANDS contact. 

3.     Testing Methods and Findings

How did your project involve the users / testers in the application’s design and testing process? 
What were the testing methods employed?  (e.g. observation of researchers’ / users’ workflows, workshops with researchers / users, exploratory interviews with researchers / users, and / or usability testing of an evolving design).
If you have had phased releases of software, please outline this information for each phase.

Here is an example: http://jcu-eresearch.github.com/Edgar/Development/2012/08/08/user-interface-testing/

4.     Findings and Lessons Learned

Please summarize briefly  what worked and what didn’t work with the interface and the application development process.
Were the users’ needs met? 
Please quote what users said about the application, for example, in terms of usefulness, future improvements and their intention of  using the application in future,  etc.


Please assign the following TAGS to your post: andsUserAcceptance, andsOutputs, andsProduct, andsApps,  fundedByAustralianNationalDataService, DIISRTE, {your project's acronym or tag}, {your ANDS project code, e.g. AP67}, {any other keyword tags you can think of that will help your project be discovered by like-minded projects}.

The Proteome Browser has been featured in Australian Life Scientist and demonstrated at the HUPO World Congress in Boston

One of our Apps projects, the "Proteome Browser", which is being developed for the International Proteomics Community by Monash University, was featured in a recent article in Australian Life Scientist in which Prof Ian Smith was interviewed about the Chromosome-centric Human Proteome Project (C-HPP) initiative and The Proteome Browser. 

Click on the link above to read the article (a pdf version is also available from the AP32 project blog).

Additionally, the Proteome Browser was recently demonstrated by Prof Ed Nice and Rob Goode from the Monash team at the Human Proteome Organisation (HUPO) 11th Annual World Congress in Boston. Check out the pics on the AP32 Proteome Browser blog of Ed and Rob in action.