Freedom of Information request FOI30/5958
Document: 1
Date: July 2013

---

---

1. Executive Summary
5
1.1.
Mobile Vision
5
1.2.
Our Objectives
6
1.3.
Our Approach
6
1.4.
Learnings & Recommendations
7
1.4.1. Unprepared for Mobile
7
1.4.2. A Lack of Tools
8
1.4.3. The Wrong Focus
9
1.4.4. Late to Market
9
1.4.5. Agility
10
1.4.6. ROI Expectations
10
1.4.7. Actions
11
2. Market Assessment
13
2.1.
Market Overview
13
2.1.1. Application Purchase
14
2.2.
Addressable Market
15
2.2.1. Overview
15
2.3.
Market Challenges
17
2.3.1. Overview
17
2.4.
Best Practices
19
2.4.1. Overview
19
2.4.2. Insights
19
2.4.3. Actions
21
3. Program Planning
22
3.1.
Opportunities
22
3.1.1. Overview
22
3.1.2. Current Opportunity: Mobile Apps
23
3.1.3. Future Opportunity: Near-Ubiquitous Experience
24
The Bureau of Meteorology’s Mobile Strategy bys47G
2

---

3.1.4. Actions
26
3.2.
Apps Assessment
26
3.2.1. Overview
26
3.2.2. Mobile Websites vs. Mobile Web Apps
27
3.2.3. Native Apps
28
3.2.4. Actions
29
3.3.
App Features
29
3.3.1. Overview
29
3.3.2. Measurements
30
3.3.3. Feature Priority
32
3.3.4. Minimum Viable Product
33
3.3.5. Revenue opportunity
35
3.3.6. Actions
37
3.4.
Data Solutions
37
3.4.1. Overview
37
3.4.2. Responsive Web Design
38
3.4.3. A Content Proxy
39
3.4.4. Screen-scraping Services
40
3.4.5. Linked Data System
41
3.4.6. Actions
43
3.5.
Program Components
43
3.5.1. Overview
43
3.5.2. Guidelines
44
3.5.3. Frameworks
45
3.5.4. API
46
3.5.5. Process and Templates
47
3.5.6. Actions
48
4. Roadmap Options
49
4.1.
Apps
49
4.1.1. Overview
49
4.1.2. The Business Case
50
4.1.3. Risks
53
4.1.4. Components
54
The Bureau of Meteorology’s Mobile Strategy by s47G
3

---

4.1.5. Costs
54
4.1.6. Actions
54
4.2.
Publishing
55
4.2.1. Overview
55
4.2.2. The Business Case
56
4.2.3. Example: Forecast.io
56
4.2.4. Risks
56
4.2.5. Components
57
4.2.6. Costs
58
4.2.7. Actions
58
4.3.
Services
58
4.3.1. Overview
58
4.3.2. Risks
59
4.3.3. Recommendation
59
4.3.4. Costs
60
4.3.5. Actions
60
4.4.
Roadmap
60
4.4.1. Overview
60
4.4.2. Year One
61
4.4.3. Year Two
61
4.4.4. Year Three
62
The Bureau of Meteorology’s Mobile Strategy by s47G
4

---

1. Executive Summary
1.1. Mobile Vision
General mobile use is growing at the fastest pace we've ever seen. Although there are already 
many weather apps in market, the Bureau holds the most valuable piece of the product 
roadmap – its weather data combined with generations of dedicated scientists 
and meteorologists. 
That said, there are countless hurdles to overcome as the mobile channel is created.  
Challenges with processes, lack of mobile expertise, monetisation goals, technical architecture 
problems, internal groups that move forward quickly with their product, and others.
And externally, we will continue to see a shifting mobile landscape, new devices in market, and 
new products from the competition that will require the overall strategy be adjusted.  It will be 
no small feat to implement a mobile strategy and align the organisation to a common agenda.
Vision
We believe the following vision can serve as guiding principles for the Bureau’s mobile program:
‣ To provide every Australian with timely, accurate, and relevant weather information and 
notifications on their mobile device
‣ To retain status as Australia’s most authoritative and trusted provider of weather, climate, and 
severe event forecasting information and services
‣ To surpass the current weather market competition by offering a superior mobile product and 
superior mobile experience
Goals
This vision can be achieved by adopting the following goals:
‣ Increase customer engagement by publishing Bureau content on mobile and tablet devices 
‣ Increase the number and frequency of Bureau mobile and tablet products in the marketplace 
The Bureau of Meteorology’s Mobile Strategy by s47G
5

---

‣ Increase the data and presentation quality of weather applications in the Australian 
marketplace 
‣ Decrease the time it takes to publish content to multiple devices 
‣ Decrease the time it takes to design and deploy new products, features, and enhancements 
‣ Create profitable program that can become self-sustaining
1.2. Our Objectives
‣ A mobile product in the marketplace by end of 2013 
‣ The ability to support for more than one platform with a single source of data by 2013 
‣ A mobile app in a major App Store in 2014 
‣ Have an average customer rating of four stars in all available App Stores by 2014 
‣ A revenue generating product in the market by the end of 2014 
‣ A 30% reduction in the time it takes to roll out new features by 2014 
‣ A 40% reduction in costs to publish content to multiple channels by 2015 
‣ The ability to rollout and manage at least three multi-channel products by 2016 
‣ A fully self funded digital program by 2017 
1.3. Our Approach
The Bureau is moving quickly to address what customers are requesting in the mobile channel.  
Evidence of this is in this strategy initiative, and other projects such as the “Water App” that was 
put into market both quickly and effectively.  This app seemed to be a one-off mobile solution – 
now recognising the importance to develop a greater Mobile Strategy and move forward.
The following are groups of high-level actions found in the Roadmap Options section in the 
strategy.  Each action is meant to kickoff individual workstreams to move forward with the 
Mobile Program.
Apps
‣ Establish a Product App Roadmap with defined core feature sets
The Bureau of Meteorology’s Mobile Strategy by s47G
6

---

‣ Resource, plan, and develop a free application per the Roadmap. This app will recruit 
customers away from the competition and show that the Bureau has the best, most relevant 
data
‣ Resource, plan, and develop a premium application per the Roadmap.  This app would 
provide detailed, specific weather information for users that need it for frequent, industry 
impacted weather decisions
Publishing
‣ Review the current data architecture to determine data that can be made easily available vs. 
data that would be difficult to access
‣ Determine the technical strategy to have data be made available for both mobile web and 
mobile app – both short term (perhaps temporary) and long term strategies
‣ Resource, plan, and execute on the Publishing strategy to make data available for internal 
web and application use
Services
‣ We recommend that the Bureau further explore the possibility of developing a services 
strategy, in additional to the app data necessary via the publishing strategy
1.4. Learnings & Recommendations
We are not be privy to a number of factors that may impact the following challenges. From what 
we were able to uncover throughout our engagement, these areas are of concern. We designed 
the Mobile Strategy to address these issues. 
1.4.1. Unprepared for Mobile
‣ We are concerned that the Bureau is not properly prepared to execute a mobile strategy. 
‣ Departments and stakeholders are still very siloed and appear to have conflicting priorities. 
However stakeholders did show their passion for the Bureau a strong willingness to rally 
around a shared vision. 
The Bureau of Meteorology’s Mobile Strategy by s47G
7

---

‣ Decisions are still being made by committees and not people. We saw limited evidence of 
empowered product management, technical or creative direction. These roles are crucial for 
guiding any mobile strategy. 
‣ We didn't see any evidence of the product, design, or technical infrastructures that we would 
expect for a mobile strategy. These are necessary components in order to properly execute a 
modern mobile strategy. 
‣ We believe that the unpreparedness in these areas will severely limit the Bureaus ability to 
build a profitable mobile program that can both respond to current market needs quickly as 
well as be competitive in the marketplace. 
‣ Therefore we tailored our original Mobile Strategy report to be more instructive in nature. For 
both the workshop and the mobile strategy we felt it a requirement to “level set” the 
stakeholders and include broad overviews for each of these areas. 
‣ At this stage, it is premature to recommend a more in-depth or, overly prescriptive strategy. 
Instead our hope is to help stakeholders better understand some of the basic necessities of 
running a modern mobile program and provide depth where needed. 
1.4.2. A Lack of Tools
‣ The Bureau does not have any of the tools in place to create even the simplest of mobile 
strategies. 
‣ Even the most rudimentary production tools – like CSS frameworks, that increase consistency 
while reducing time to publish – are not in place. There are no tools in place to support the 
multi-platform complexity of mobile. 
‣ From our understanding the majority of web content is being manually published. There is no 
CMS in place, and it appears it will be one year before one is in place. This is of great 
concern. 
‣ While the Bureau's primary product is data, we saw no evidence of an API making that data 
available in an industry acceptable way. Like the CMS, it appears it will be a year before basic 
data is available. This is of critical concern. 
‣ With no CMS and no API in place, it could be at least one year before we can get content to 
mobile devices, we see this as a critical obstacle to beginning to build a mobile strategy. 
The Bureau of Meteorology’s Mobile Strategy bys47G

---

1.4.3. The Wrong Focus
‣ We are concerned that the Bureau becomes too easily distracted with ambitious and lofty 
goals, and is not paying enough attention to the basics.
‣ For example, the goal to earn revenue from mobile apps seems very premature. The weather 
app marketplace is very competitive and the Bureau hasn't shown they have the resources or 
tools needed to be competitive with free apps. 
‣ There is also a heavy focus on native apps, specially for iOS, which seems overly ambitious 
without any of the basic tools in place for delivering data to native frameworks. 
‣ Creating apps designed specifically for Industry customers are also a popular topic with 
stakeholders. We do believe that the non-consumer market is the most like source of 
revenue, however we feel that the basic consumer interest must be served first before we 
begin to address the more complex and diverse needs of non-consumer markets. 
‣ We recommend making the modernisation of the Bureaus web publishing techniques a 
priority. We need to reduce the time and cost to publish so we can simultaneously publish to 
desktop, mobile and tablet platforms. 
1.4.4. Late to Market
‣ We are concerned that we may be too late in delivering a basic weather app to consumers – 
the most popular and most commonly purchased. By the time the Bureau is able to deliver 
even a basic mobile product, we believe the addressable market will have decreased 
considerably in size, further reducing an already small ROI. 
‣ We find when a client is late to market, the best strategy is either a.) leap frog the competition 
with amazing design and features, or b.) commoditise the industry – driving down cost to 
customers while increasing value, making it unsustainable for smaller competitors to draw 
away Bureau customers. 
‣ We feel because of the issues listed above, that commoditisation is the best strategy, 
however this directly conflicts with the mandate to produce a revenue generating strategy. 
We've attempted to produce a roadmap in the Mobile Strategy document that resolves this 
over three to five years. 
The Bureau of Meteorology’s Mobile Strategy by s47G
9

---

1.4.5. Agility
‣ Unless a new strategy is adopted, we believe it might not be until 2015 that we see a 
competitive mobile product from the Bureau. By then the market could look much different 
than it does now, introducing the risk of market shifts during unnecessarily long development 
cycles. 
‣ We are concerned about the Bureaus ability to be agile, establishing the right roles and 
empowering staff to make decisions quickly. It is simply taking too long to get critical systems, 
infrastructures and staff in place. 
‣ We feel that in order to be competitive, the Bureau must be able to plan, approve, fund, and 
execute a product, feature or enhancement within three months – producing at least four 
cycles a year. Ideally we'd like to see each cycle reduced to two months, producing six cycles 
a year. Most app teams – the Bureaus competition – use one month cycles, producing twelve 
cycles a year. 
1.4.6. ROI Expectations
‣ Due to the aforementioned challenges, as well as the limited addressable market of Australia, 
we are concerned that it may be impossible to break even or generate a profitable return on 
investment of a mobile program. 
‣ In order to increase the likelihood of a reasonable return on investment, we feel the following 
areas must be addressed:
• Provide focus to staff by prioritising fundamental and achievable goals over long term 
vision. We recommend establishing a single very high level vision or direction that can 
serve as a general beacon for Bureau staff and stakeholders – currently this is pursuit of 
revenue, which is a desired outcome not a vision. Then have teams create achievable 
and timely goals that help support the vision, giving the staff empowerment and focus. 
• Reduce the cost of web publishing by modernising tools. We fully expect that more 
money will be saved in the first two years by simple modernisation of tools, than would 
be made from mobile app revenue. 
The Bureau of Meteorology’s Mobile Strategy by s47G
10

---

• Increase the Bureau's agility by empowering staff, reducing cycles and eliminating 
bureaucracy. Harder said than done we know, but from the passion and commitment we 
saw from Bureau staff, we believe the team is up for the challenge. 
• Forgo pursing revenue in the mobile channel until year three or four, after the proper 
tools and services can be put in place. In the meantime, optimise web publishing to 
support mobile and tablet, commoditising weather data in Australia and to prevent 
further attrition of customers. 
• Heavily invest in the modernisation of digital technology and tools. Modest investments 
over the next 24 months can highly reduce costs and increase ROI over the subsequent 
years. 
1.4.7. Actions
These actions are a section by section summary of the actions listed throughout the strategy 
document.
Market Assessment
✓ Commission a market study focused study on monetisation opportunities.  Both this Mobile 
Strategy, and the strategies we reviewed to inform the Mobile Strategy, have not focused 
deeply enough to understand the true monetisation potential required for business goals.
✓ Stay connected to the rapidly changing mobile device and platform landscape.  Driven by 
product, these are evolving as fast as any market we have seen.  With the speed at which the 
Bureau can execute a strategy, markets should continually be examined.
Program Planning
✓ Approve a multi-pronged strategy and move forward – continue to keep abreast on 
changing devices, standards, and market conditions.
✓ Think “disruptive” – with the products already in market The Bureau needs to provide 
something even better, a more meaningful application experience for the Australian public.
✓ Further discuss an “BOM Everywhere” strategy – providing weather and climate data on 
anything with a screen.
The Bureau of Meteorology’s Mobile Strategy by s47G
11

---

✓ Make significant investments into data publishing capabilities – data services architecture to 
serve data to mobile apps, including a way for customers to submit weather data from 
mobile devices.
✓ Focus on a disruptive free application using the appropriate app class that provides users 
the highest fidelity experience based on the v1 feature set
✓ Increase internal staff subject matter expertise, regardless of the intent to build the app 
within the Bureau or commission the build.
✓ Define a v1 balance feature set to be launched in a free product that can be built in a timely 
manner and in an engaging customer experience, based on the recommendation of this 
strategy.
✓ Review the defined feature set with an external audience – it is our experience that 
companies try to do too much too quickly, which results in delayed launches and a poor 
experience.
✓ Plan a v2 feature set that should replace the first product in market.
✓ Create a Content Proxy that uses data from MetEye and other data sources to efficiently 
serve necessary content to a mobile app
✓ As mentioned in the Opportunities section, make significant investments into data 
publishing capabilities – data services architecture to serve data to mobile apps, including a 
way for customers to submit weather data from mobile devices.
Roadmap Options
✓ All actions are listed in the Approach section.
The Bureau of Meteorology’s Mobile Strategy by s47G
12

---

---

---

change.Consumers are willing to pay for an app that performs well and provides valuable 
features.  This is also supported by our global observation of mobile app purchases.
In this study, iOS commerce was four times greater than that of Android.  Recent security 
reviews5 have also been released, suggesting Apple ranks much higher than Android in 
providing a secure device.
Based on these trends, the Bureau will be able to generate mobile revenue provided 
application development and monetization strategies are well executed. Later in this report we 
will analyse subscription and app purchase strategies based on market projections, 
competition, and revenue requirements.
2.2. Addressable Market
2.2.1. Overview
There should be no doubt that the overall Australian mobile market is sizeable. The question is, 
“How many of these users will our product be able to reach?” This is called the ‘Addressable 
Market’ – the portion of the market that is likely to have an interest in a weather product.
The good news is that 73% of all smartphone users have indicated they want news and weather 
services on their phone, which are a very big slices of the pie. We can use that figure to project 
the number of smartphone and tablet owners that will want news and weather applications on 
their device over the next three years.
However, that is only our gross addressable market – the maximum number of users that would 
download a free application. We see the numbers go down dramatically once we ask customers 
to pay $0.99 for an application, and even further down as we increase the price.
In the best case scenario, if the Bureau launched one $0.99 product or add-on feature per year 
and were able to get the entire addressable market with each release, the estimated revenue 
would be $1,941,304 AUD over three years. Adding Android would increase the value to 
$2,745,559 AUD.
5 http://tech.fortune.cnn.com/2013/04/14/apple-enterprise-android-malware/
The Bureau of Meteorology’s Mobile Strategy by s47G
15

---

---

2013
2014
2015
2016
3yr Total
Revenue
$1.99
$22,603
$26,808
$31,965
$38,321
$97,095
$2.99 Price Point
0.02%
975
1,156
1,378
1,652
4,186
Revenue
$2.99
$2,040
$2,419
$2,885
$3,458
$8,762
$3.99 Price Point
0.001%
59
69
83
99
251
Revenue
$3.99
$163
$194
$231
$277
$702
$4.99 Price Point
0.0001%
4
4
5
6
15
Revenue
$4.99
$12
$15
$17
$21
$53
While these numbers are far from being conclusive, they do provide valuable insight into the 
addressable market size, and  help us understand and plan a realistic long term mobile strategy.
2.3. Market Challenges
2.3.1. Overview
There are a great number of challenges that are holding back the mobile market- despite this, 
the mobile market continues to grow at an exponential rate with consumers.
We’ve repeatedly observed this disconnect between the real challenges of providing long term 
mobile products while meeting high consumer expectations of today’s market with some of the 
largest companies in the world. Nine times out of ten this results in a mobile strategy that is far 
outside the initially allocated time, budget, and resourcing constraints.
Just as Web 2.0 needed early content management systems and Ajax in order to create 
companies like Facebook, YouTube, Blogger, Wikipedia, and Twitter, mobile still needs similar 
starting points to reach its full potential. These milestones have yet to be reached in mobile.
Our first recommendation when developing a mobile strategy is to understand the challenges 
of the mobile market and to focus on developing a very pragmatic approach to addressing 
them over time.
The Bureau of Meteorology’s Mobile Strategy by s47G
17

---

A Fragmented Marketplace
‣ Currently, the mobile application market is tied to multiple platform-based App Stores.  This 
requires that businesses make multiple versions of their application and support a plethora of 
mobile devices in order to sell their product. 
‣ Supporting multiple devices and marketplaces quickly becomes cost prohibitive for most 
businesses. This has remained unchanged for nearly a decade.
Unmet Consumer Needs
‣ Due to the rapid growth of smartphones, mobile is currently the number one business 
consideration in the market today.
‣ Consumer demand for Apple-quality mobile solutions is incredibly high.
‣ The majority of businesses do not have the resources or expertise to define, create, or 
maintain a mobile solution.
‣ Skilled mobile resources available are extremely limited.
Lack of Tools
‣ The majority of Fortune 500 companies do not have data infrastructure to support a strong 
long term mobile strategy.
‣ The W3C has an extremely restricted roadmap for HTML5, limiting most businesses mobile 
strategies to 1-2 years.
High Cost of Support
‣ The high cost of device fragmentation continues to hinder innovation.
‣ Due to the lack of standards in the mobile market HTML5 mobile strategies can quickly 
increase in cost as additional devices come to market.
‣ The Android platform continues to be fragmented and can be cost-prohibitive to support.
‣ A go-to market mobile strategy costs cost between 0.01% and 0.05% of gross revenues per 
year.
‣ Limited data is often available to justify appropriate budgets, KPIs, and ROI.
Needs Critical Mass
‣ These problems will continue to limit the available tools and solutions in the marketplace.
The Bureau of Meteorology’s Mobile Strategy bys47G
18

---

‣ The lack of viable cross-platform mobile solutions will continue to hinder efficiency and 
innovation- reaching critical mass on mobile marketing, advertising, commerce, and 
payments.
2.4. Best Practices
2.4.1. Overview
Given the steady rise of smartphone use in the mainstream public and the increasing 
commonality of tablet usage there has been a significant cultural shift toward cross-platform 
digital media consumption. The reality of this swell has resulted in a highly competitive 
landscape for weather apps. 
This section is an overview of best practices based on market comparison research (on 35 of the 
top free and paid weather apps in the Apple and Android market, for US and Australia). 
Included are Insights to Top Market Weather Apps, Comparing and Contrasting Weather Apps, 
Weather App Design Trends (interface, design, data presentation), and a conclusion of the best 
practices and research data.
2.4.2. Insights
The “Top Market Apps” are defined categorically by having high ratings and usage reported- 
listed under “most popular” by the App Store. The data in this comparison research 
demonstrates that apps in the weather category captivate and enlighten customers, primarily 
when the product finds and focuses on a particular niche- e.g. current, hyper-local weather 
information, lifestyle forecasts, radar mapping information, or real-time severe weather alerts. 
By further specialising the customer experience through interface and design e.g. simplistic, 
highly informative, creative, fun, or innovative- apps maintain customer loyalty and receive high 
ratings in the market.
‣ there are currently 4,900 weather apps in the American market 
‣ priced from free to up to $4.99 (for a one-time purchase with in-app purchases)
‣ there are a few very specialised apps in the $10-60 range (marine, radar)
The Bureau of Meteorology’s Mobile Strategy bys47G

---

‣ most popular customer apps were paid apps (as reported by Apple App Store)Australian 
Weather Apps
There are several apps that are used globally for weather: AccuWeather, The Weather Channel, 
and Weather Underground (and its many related apps).  Theyare recommended by LifeHacker 
as free versions of excellent weather apps for Australian consumers.
In an App Directory category for Best Weather App for iOS, Pocket Weather was named as the 
one to beat in the Australian Market. 
The following shows a sample of features.
Top Features
‣ current weather
‣ high/low temperatures
‣ humidity
‣ precipitation 
‣ cloud cover
‣ wind
‣ sun rise/set 
‣ hourly forecast
‣ real-time severe weather warning alerts
‣ push notifications
Additional Features
‣ 3,7,10,15 day forecast
‣ animated radar or satellite images
‣ lifestyle forecasts
‣ user-generated content (i.e.photographs, weather reports)
‣ socialisation (Twitter, Facebook, etc.)
The Bureau of Meteorology’s Mobile Strategy by s47G
20

---

2.4.3. Actions
✓ Commission a market study focused study on monetisation opportunities.  Both this Mobile 
Strategy, and the strategies we reviewed to inform the Mobile Strategy, have not focused 
deeply enough to understand the true monetisation potential required for business goals.
✓ Stay connected to the rapidly changing mobile device and platform landscape.  Driven by 
product, these are evolving as fast as any market we have seen.  With the speed at which the 
Bureau can execute a strategy, markets should continually be examined.
The Bureau of Meteorology’s Mobile Strategy by s47G
21

---

3. Program Planning
3.1. Opportunities
3.1.1. Overview
While there are many discussions about the next evolution of mobile apps and content, little is 
understood by the market. The market can sense something is coming, but it is not able to 
articulate what it will be and how to take advantage of it – simply pointing to the bespoke 
efforts of big names like Google and Facebook. 
The market will often conflate different incompatible technologies, leaving businesses poorly 
prepared to create a realistic mobile strategy based on their own business goals.
This can lead to speculative or unproven strategies, based more on the press than actual 
business needs. For example, many research firms might recommend mobile web apps one 
quarter, only to recommend native apps the next.  
We recommend employing an evolving mobile strategy, picking an entry point and evolving the 
strategy to changing devices, standards, and market conditions.
The Bureau of Meteorology’s Mobile Strategy by s47G
22

---

3.1.2. Current Opportunity: Mobile Apps
Currently, the market is focused 
entirely on the mobile application 
space in an almost reactive way. 
Historically, this has been the only 
viable mobile distribution 
strategy. Today’s mobile apps are 
an evolution of a ten-year-old 
strategy made possible by current 
mobile hardware.
Due to the problem of a 
fragmented market, many companies are caught off-guard while holding off on developing their 
mobile app strategy, waiting for more cost efficient option.
This creates a significant opportunity for competitors to enter the mobile app space early and 
disrupt or acquire customers through marketplaces like the Apple App Store or the Android 
Market.
This market is expected to reach $183 billion by 2015.
What this means for the Bureau?
This is where the Bureau is now. With a large number of weather apps already in the market, 
many on the second, or third major version, the Bureau must be able to disrupt the market with 
a better, more meaningful application experience for the Australian public.
The Bureau of Meteorology’s Mobile Strategy by s47G
23

---

3.1.3. Future Opportunity: Near-Ubiquitous Experience
The number of devices currently 
connected to the Internet is over 5 
billion. Several different 
technologies (LTE, IPv6, HTML5, 
etc) will merge to enable what we 
call Near-Ubiquitous Experiences 
(NUE) across a multitude of 
devices- from phones, to cars, to 
environmental advertising. 
In this model, the business logic 
lives in The Cloud and there are 
many clients – both native and 
web-based – that can start, 
resume, and complete 
transactions.
We think of this stage as “Cloud Computing” meets Near-Field Communication (NFC). Cloud-
based services – which is the best indicator of the potential market size – claimed $68.3 billion in 
revenue in 2010 and is expected to reach $148.8 billion by 2014.
Today HTML5 is being viewed as the primary framework of this stage. Although, the lack of 
standards being defined by the W3C and other standards bodies is currently holding it back 
and making it more costly than native mobile apps. 
This may change, but we believe it is more likely that we won’t see a mobile friendly framework 
until we are closer to HTML6 being defined. 
Alternately, if the mobile platforms create a more open mobile standards process, we could see 
industry-led standards. Though as long as Apple and Google are the primary mobile platform 
providers we do not think this is likely to happen soon.
The Bureau of Meteorology’s Mobile Strategy by s47G
24

---

What this means for the Bureau?
We see a significant opportunity for the Bureau to take advantage of this next stage. Being able 
to present highly relevant weather and climate data on a variety of screens and platforms 
around Australian will be a big win for customers. The Bureau will have a ubiquitous presence in 
customers’ lives, simply being anywhere people are.
In order to prepare for this next shift, the Bureau will need to make significant investments into 
their data publishing capabilities.
3.1.4. Future Opportunity: Linked Data
Tim Berners-Lee – father of the World Wide Web – described “Linked Data” as a “new form of 
Web content that is meaningful to computers will unleash a revolution of new possibilities” in 
2001. The concept is, data will increasingly come from multiple sources and be in multiple 
formats. We need a way to bring data together dynamically to create new contextual 
experiences on demand. However, these concepts are still stuck in academia.
Multiple data systems need a common language in order to work with the 
coming age of near-ubiquitous experiences and devices. 
To date, this market need is completely under-served and 
therefore no one knows its market size or potential. 
However,
s47G
 has worked with companies likes47G
 
and others and observed first-hand the value 
that Linked Data solutions can bring to customers.
What this means for the Bureau?
Currently the Bureau is fortunate enough to be in content publishing – creating weather 
forecasts and pushing them out to various outlets. But as the industry shifts more toward a 
Linked Data model, we will likely see a future where many devices can become meteorological 
sensors, with the ability to transmit data back to the Bureau.
The opportunity presents itself for the Bureau to prepare for this transition by further investing 
into its data services architecture, developing a true linked data system.
The Bureau of Meteorology’s Mobile Strategy s47G
25

---

3.1.5. Actions
✓ Approve a multi-pronged strategy and move forward – continue to keep abreast on 
changing devices, standards, and market conditions.
✓ Think “disruptive” – with the products already in market. The Bureau needs to provide 
something even better, a more meaningful application experience for the Australian public.
✓ Approve an “everywhere” approach – provide weather and climate data on a variety of 
screens and platforms around Australia
✓ Make significant investments into data publishing capabilities – data services architecture to 
serve data to mobile apps, including a way for customers to submit weather data from 
mobile devices.
3.2. Apps Assessment
3.2.1. Overview
There are many ways to deliver content to mobile devices. We tend to call of them “Apps” but 
there are subtle differences that are important to understand and consider when building a 
mobile program. 
To make matters more confusing, we hear of technologies like HTML5 or techniques like 
Responsive Web Design that appear, at least on the surface, as simple solutions to big mobile 
problems. 
For most organisations a mobile strategy is typically defined by how you intend to use mobile 
devices to create two-way dialogue with your customer. However the Bureau’s role for mobile 
customers, at least initially, is simple to publish weather data to Australian’s.
This gives us a lot more options to choose from, allowing us to explore each of the different 
types of apps to find the right strategy. 
In this section we will define each of the different types of apps.  More detail and the 
advantages and disadvantages of each can be found in the Appendix.
The Bureau of Meteorology’s Mobile Strategy by s47G
26

---

3.2.2. Mobile Websites vs. Mobile Web Apps
There are distinct differences between a Mobile 
Website and a Mobile Web App, sometimes 
referred to as a HTML5 Mobile App. These 
differences are important to note as not all 
mobile technologies and solutions are equal.
A mobile website is a website designed 
specifically for mobile devices, not to be 
confused with viewing a site made for desktop 
browsers on a mobile browser. Mobile websites 
are characterised by their simple “drill-down” 
architecture, or the simple presentation of 
navigation links that take you to a page a level 
deeper.
Different than a Mobile Website, Mobile web 
applications are mobile applications that do not 
need to be installed or compiled on the target 
device. Using HTML5, CSS, and JavaScript, 
they are able to provide an application-like 
experience to the end user while running in any 
mobile web browser. By “application-like” 
experience, we mean that they do not use the 
drill-down or page metaphors in which a click 
equals a refresh of the content in view. Web 
applications allow users to interact with content in real time, where a click or touch performs an 
action within the current view.
However the app will be limited to the capabilities of the onboard browser of the planned 
devices. There are four classes of devices it is possible to support, these are further define in 
the Appendix
The Bureau of Meteorology’s Mobile Strategy by s47G
27

---

---

According to s47G
 research, it's not a question of “either/or” when it 
comes to a choice between apps vs. the HTML5, but both. 
Native Apps offer a superior user experience as well as a new marketplace to introduce your 
brand to new customers. However supporting multiple native frameworks can be costly. 
Having an HTML5 mobile strategy ensures that your site is visible to users regardless of device, 
but the experience is limited to the lowest common denominator of device support – a low end 
Android device.
3.2.4. Actions
✓ Focus on a disruptive free application using the appropriate app class that provides users 
the highest fidelity experience based on the v1 feature set.
✓ Increase internal staff subject matter expertise, regardless of the intent to build the app 
within the Bureau or commission the build.
3.3. App Features
3.3.1. Overview
Features are the core of a mobile strategy, defined as “a distinctive attribute or aspect of 
something.”  Features are the tiny details that will draw users and determine how they interact 
with data.  In some cases, a key feature may simply be the design aesthetic used in the 
application. 
Features are subjective, being as unique as the person using them or the person requesting 
them to be in your app. They can fall anywhere along the spectrum – high priority, high impact, 
and “me too” copycat features. For better of for worse, they are the details that help define your 
mobile strategy and how it will be remembered. 
We’ve found that properly defining and managing product features is a critical component of a 
mobile strategy. With good feature management we can define priorities, vision, and provide 
focus – in other words, what to do and what not to do.
The Bureau of Meteorology’s Mobile Strategy bys47G
29

---

3.3.2. Measurements
The first step in feature management is organising them fors47G
.  Our approach 
was to s47G
 
 
.  We thens47G
 
 to identify key features that should be included in the Bureau’s 
mobile strategy. We evaluated each feature categorically by:
Priority
s47G
 
Revenue & Premium Features
s47G
 
 
User Value
s47G
 
 
 
The Bureau of Meteorology’s Mobile Strategy bys47G
30

---

Business Value
We gave one of the following scores to each feature based the business value based on the 
April 2013 Mobile Workshop and additional conversations with Bureau staff. We s47G
 
 
Complexity
We gave one of the following scores to each feature based on the complexity to deliver 
according to the April 2013 Mobile Workshop ands47G
 experience designing and 
building mobile applications for similar sized organisations [to the Bureau]. 
We use s47G
y.  Generally speaking thes47G
 
. However if a feature has s47G
 
.
‣ s47G
 
 
 
The Bureau of Meteorology’s Mobile Strategy bys47G
31

---

3.3.3. Feature Priority
Business Input vs. Premium Scoring
Current Conditions
Forecast
Severe Weather
User Interface
Historical
Radar
0%
20%
40%
Business Input
Premium Scoring
After scoring the features using this criteria, we found an interesting insight common to mobile 
strategies – many features that were thought to be important by the business scored less 
important to users. In other words, we are spending a good deal of time looking at solutions to 
problems we don’t yet have, or ones that may not exist.
For example, when we look at features being evaluated based on Business Input, we see that 
the highest scoring were related to Current Conditions, Forecast, and Severe Weather. By using 
this scoring alone, it could be easy to assume this is where we should focus our strategy.
However, once we scored the features based on market research and user value, we see a 
different picture.  Both Forecast and User Interface score much stronger than Business Input 
predicted, with Current Conditions and Severe Weather validated important as well. 
The biggest scoring variances between the business and user were the features pertaining to 
Radar and Historical information, which were repeatedly mentioned in the Bureau provided 
research and the April 2013 Mobile Workshop. Radar can provide a user value, but its score 
shows that users find it less valuable than the business anticipated. Historical information results 
swayed in this direction even more.
The Bureau of Meteorology’s Mobile Strategy bys47G
32

---

This is a very common problem with mobile strategies of this type. With many areas of 
complexity, the lists of desired features can become quite long, while subjectivity or internal 
priorities can trump actual priorities.  Though this scoring is not scientific, without a quantitative 
scoring formula to give clarity to the strategy, perception can become reality resulting in the 
investment of valuable time and resources in the wrong strategy or channels.
This is a good example of how a product can easily fall into the trap of failing to meet market 
expectations, simply by focusing on the wrong priorities.
3.3.4. Minimum Viable Product
By using our feature analysis data, we are able to recommend the Minimum Viable Product 
(MVP), defined as the core feature set which meets customer expectations. Additional features 
can be included and should be considered to round out a product offering, but without these 
core features, the product would likely fail to resonate with the target audience.
We recommend the mobile strategy include a MVP that includes a well designed, beautifully 
executed core feature set that will serve as a foundation for future enhancements. An 
established roadmap will incrementally add more features over the lifespan of the product.
Listed here are Core Features that should be considered as the base feature set for the MVP.  
They are not ranked in order of importance, but one can see a groupings of Current Conditions, 
Forecast, Severe Weather, and User Interface.
Core Features
‣ Current Location Conditions – Display the current weather conditions and forecast for the 
users current location.
‣ Current Temperature – Display the current temperature for location in view.
‣ Perceived Temperature – Display the perceived or “feels like” temperature in addition to the 
actual temperature, for the location in view.
‣ UV Index – Display the UV Index for the location in view.
‣ Wind Speed information – Display the windspeed information for the current location.
‣ Chance of Rain – Display the chance of precipitation for the location in view.
The Bureau of Meteorology’s Mobile Strategy by s47G
33

---

‣ Expected Rainfall – Provide the user with forecasted Rainfall information for the location in 
view.
‣ Daily High Temperature – Allow the user to view the forecasted high temperature for each of 
the days in view.
‣ Daily Low Temperature – Allow the user to view the forecasted low temperature for the 
location and days in view.
‣ Time of daily high expected – Provide the user with the time and temperature of the 
expected daily high.
‣ Time of daily low expected – Provide the user with the time and temperature of the expected 
overnight low.
‣ Sunrise/sunset times – Provide the user daily sunrise/sunset times.
‣ Daily Synopsis – Provide the user a synopsis outlook for the next current and next day based 
for the location in view.
‣ Forecasts - 1hr increment for the next 12 hours – Provide the user an hourly forecast for the 
next 12 hours for the location in view.
‣ Forecasts - daily increments for next 7 days – Provide the user a daily forecast for the next 7 
days for the location in view.
‣ Severe Weather Alerts – Provide the user with a push notification to their device in the case of 
a severe weather warning.
‣ Flood Warning Information – Provide a push notification and display general (not location 
specific) flood warning information to the user.
‣ Hail Warning Information – Provide a push notification and display general (not location 
specific) hail information to the user.
‣ Heatwave Conditions Warning Information – Provide a push notification and display general 
(not location specific) heatwave warning information to the user.
‣ Thunderstorm Warning Information
– Provide a push notification and display general 
(not location specific) thunderstorm warning information (thunder and lightning) to the user.
‣ Fire Danger Warning Information – Provide a push notification and display general (not 
location specific) fire danger information to the user.
‣ National and state radar – Provide the user with national and state radar.
The Bureau of Meteorology’s Mobile Strategy by s47G
34

---

---

app that would allow sophisticated data to weather-hungry users in the public or industry 
audiences.  
Potential Premium Features
‣ Custom Push Notifications – Provide the user a method of defining custom push notifications 
based on weather conditions that they specify.
‣ Wellness report – Provide the user with an observed weather update based on selected 
locations outside of their current location.
‣ UV Forecast – Provide the user with forecasted UV Index for the location in view.
‣ Recent Rainfall – Display the amount of rainfall for the current location over a set period of 
time.
‣ Rainfall intensity – Display rainfall intensity information for the current location.
‣ Soil temperature information – Display the soil information for the current location.
‣ High definition radar – Provide the user with high definition radar.
‣ Severe Thunderstorm cell based maps – Provide the user with severe thunderstorm cell maps.
‣ Water Availability / Usage – Display water availability information for the current location.
‣ Seasonal Outlooks – Provide the user seasonal outlook information based on their region 
based on location.
‣ Marine Forecast – Provide the user with forecasted Marine information for the location in 
view.
‣ Swell Forecast – Provide the user with swell information based on selected location.
‣ Tide Tables – Provide the user with tidal information based on selected location.
‣ Heat Maps – Display Heat Maps for the location in view.
‣ Additional Warning Information
– Provide a push notification and display general (not 
location specific) for other warnings such as tsunami, pollen, dangerous seas, tropical cyclone, 
etc.
‣ Unlimited favourite locations – Allow user to add an unlimited number of locations for the 
ability to monitor weather in other areas.
‣ No Advertising – Allow user to turn off advertising. 
The Bureau of Meteorology’s Mobile Strategy by s47G
36

---

Premium Offering Recommendation
When looking at the premium features, many of these fall into the category of the power public 
user, the industry user, or both. 
Because the Bureau has the most sophisticated forecast and notification system in Australia, 
and perhaps the world, there is no doubt a premium offering could generate revenue.  It is 
unknown at this time as to how much revenue could be generated.  
When considering the addressable market defined in this strategy and the current choices 
already in market by competition, it is unlikely that apps alone could generate enough revenue 
to sustain the mobile channel for the Bureau. 
It would be advisable to perform additional research (and review of existing audience research) 
to maximise the mobile channel’s monetisation potential.
3.3.6. Actions
✓ Define a v1 balance feature set to be launched in a free product that can be built in a timely 
manner and in an engaging customer experience, based on the recommendation of this 
strategy.
✓ Review the defined feature set with an external audience – it is our experience that 
companies try to do too much too quickly, which results in delayed launches and a poor 
experience.
✓ Plan a v2 feature set that should replace the first product in market.
3.4. Data Solutions
3.4.1. Overview
Any mobile solution will require data. The better the data, the more features the solution can 
provide. Though the Bureau currently delivers large amounts of data to its traditional clients, 
this section will explain options to deliver that data to mobile clients, something the Bureau is 
not currently equipped to do.
The Bureau of Meteorology’s Mobile Strategy by s47G
37

---

This strategy takes the position that the Bureau should provide a mobile data solution in year 
one with whatever data can be made available, while concurrently creating a RESTful web 
service to enable more robust solutions in the future. There are a number of data solutions 
available to us in the first 12-18 months while a data service is being developed, that should 
focus on the most valuable bom.gov.au pages and recommended mobile features from this 
strategy. And how we collect data will ultimately determine the course of the strategy, therefore 
we present four data solutions for consideration and discussion.
3.4.2. Responsive Web Design
In this scenario we would develop 
CSS Media Queries to alter the 
presentation of the experience 
based on the customers device 
and/or orientation. Under the 
hood, we use the same markup, 
but separate out the presentation 
CSS by device or device class.
Advantages
‣ Very minimal changes to the 
markup
‣ Can be done without the 
support of a dev team
‣ Can be implemented quickly
Disadvantages
‣ Not optimised for the mobile context, e.g. the tablet experience may be lacking
‣ Would require a media query for each screen size and orientation (typically between 8-9 
media queries)
‣ Limited tablet support
‣ No native app support
Platforms Supported
‣ Extensive – Responsive Mobile Website on WebKit browsers only
The Bureau of Meteorology’s Mobile Strategy bys47G

---

3.4.3. A Content Proxy
In this scenario, we would deploy a 
content proxy, or web service that 
translates data between differing 
systems, or in other words creates a 
mobile API where one doesn’t exist.
This solution is a standalone piece of 
technology that would coexist with 
other sites. Mobile requests would 
be rerouted to the content proxy 
and deliver the appropriate 
experience based on their user 
agent.
This provides a reliable end point to 
which the Bureau can develop 
mobile experiences – historically, the 
most expensive part of mobile 
development. All layout, caching, 
and content transformations are 
handled on the content proxy, not the parent web application server. 
For lower priority sites/pages, we may need a screen scraping service, but unlike the market 
solutions, we would avoid doing DOM-level transformations. 
We’ve found Proxy-based adaptation to be an extremely effective method of dealing with older 
data in the mobile context.
Advantages
‣ Optimised user experience based on the requesting device
‣ Supports many platforms (known and unknown)
‣ Reduces network latency
‣ pinch/zoom has already built it
The Bureau of Meteorology’s Mobile Strategy bys47G

---

---

Advantages
‣ No infrastructure or additional technology is required
‣ Can be turned around very quickly.
Disadvantages
‣ Very costly, base cost will be multiplied by each site
‣ When the site is updated, the scraping rules will break
‣ Does not support multiple applications, only creates a simple mobile website
3.4.5. Linked Data System
Linked Data is a method of 
publishing structured data so that 
it can be interlinked and become 
more useful. It builds upon 
standard Web technologies such 
as HTTP and URIs. Rather than 
using them to serve web pages 
for human readers, it extends 
them to share information in a way 
that can be read automatically by 
computers. This also enables data 
from different sources to be 
connected and queried.
Another way to think of it, a Linked Data System takes data from multiple places and creates 
experiences at the moment of request, depending on the client or context. A content proxy 
strategy is the baby brother to this more robust solution.
This approach is especially valuable when thinking of creating the contextual experiences that 
today’s mobile consumer are demanding.
For the Bureau, who is already dealing with multiple data source inputs, a Linked Data System 
would enable direct hooks into the host data sources, but also transform and output data to 
The Bureau of Meteorology’s Mobile Strategy by s47G
41

---

external systems or platforms. For example websites, mobile web apps, native apps, Facebook 
apps, etc.
How it Works
A Linked Data System would support multiple tenants in a consistent fashion (as opposed to 
different code being used for different properties). The system serves two primary functions. 
Serve a Mobile User Interface
‣  Accept the incoming request
‣  Extract and validate the property domain
‣ Detect the device profile of the requesting user agent
‣ Retrieve the appropriate application configuration from the datastore
‣ Adapt the content based on the detected device profile
‣ Render the user interface
Handle API requests
‣ Accept the incoming request
‣ Validate that the API caller is authorised
‣ Extract the request parameters and map the call to the appropriately defined resource and 
method handler
‣ Retrieve data cached in the datastore and/or execute procedural logic
‣ Send data back to client with appropriate content type
For the API serving, the infrastructure will get more complex over time. This is the boundary 
between the mobile application’s API (its user interface) and the plumbing that connects it to 
myriad data sources and procedural logic. This is where we connect with notification systems 
such as Web hooks, job queues, PubSubHub hubs for aggregating feeds and more.
Advantages
‣ Optimised user experience based on the requesting device
‣ Supports many platforms (known and unknown)
‣ Reduces network latency
Disadvantages
‣ An unknown level of effort would be required to build to the Bureau’s specifications
The Bureau of Meteorology’s Mobile Strategy by s47G
42

---

Platforms Supported
‣ All platforms– HTML5 Mobile Sites, HTML5 Mobile Apps, iPhone, Android, iPad, etc.
3.4.6. Actions
✓ Create a Content Proxy that uses data from MetEye and other data sources to efficiently 
serve necessary content to a mobile app.
✓ As mentioned in a Opportunities section, make significant investments into data publishing 
capabilities – data services architecture to serve data to mobile apps, including a way for 
customers to submit weather data from mobile devices.
3.5. Program Components
3.5.1. Overview
Mobile projects are inherently complex and are often prone to unforeseen problems. Together 
with the challenges of supporting multiple screen sizes, platforms, and deployment 
requirements, it is not uncommon for a mobile project to take far more resources than similar 
sized web projects. Therefore, the best mobile strategy will minimise as much risk as possible.
There are four types of enabling components to a mobile strategy, the building blocks so to 
speak, that are required to execute any roadmap. 
‣ Guidelines – Standard operating procedures and guidelines to ensure that users receive a 
consistent experience across all digital platforms.
‣ Frameworks – The specific tools we employ to ensure that we are using consistent technology 
with all markets and vendors- it supports both the customer experience guidelines as well as 
the long term mobile roadmap.
‣ APIs – The technology and documentation that is required to deliver the customer experience 
across multiple digital platforms.
‣ Process & Templates – The methods we will need to employ to ensure project sponsors, 
vendors, and stakeholders are meeting both organisation and platform guidelines for 
successful market deployment from the start.
The Bureau of Meteorology’s Mobile Strategy by s47G
43

---

The following is a comprehensive list of the necessary components for a mobile roadmap.
3.5.2. Guidelines
Standard operating procedures and guidelines to ensure users receive a consistent experience 
across all digital platforms.
Business Case
Given the limited experience the Bureau has had deploying mobile applications, the guidelines 
necessary to support the mobile roadmap are lacking. Guidelines are required for everything 
from app deployment strategy, design, market specific device support plans, usability testing, 
accessibility, etc.
Return on Investment
Developing a set of mobile guidelines will ensure that all mobile projects conform to the mobile 
roadmap, where each mobile project contributes to the other. These guidelines will reduce the 
long term costs associated with each mobile project.
Example Guideline Components
‣ Mobile Strategy – We need to develop both a UI and development strategy for how users are 
going to engage with the Bureau with mobile and tablet devices. For example, will there be 
one "BOM App” or "many BOM Apps"?
‣ Mobile Requirements – We need a consistent process for gathering mobile/tablet 
requirements from business units/owners, since it will deeply impact the business, the user 
experience as well as the technology needed to support it.
‣ Device Plans – A document that defines the minimum devices that need to be supported in 
order to properly plan requirements.
‣ Mobile Design Language – Creating a Mobile Design Language will not only ensure that all 
Bureau applications are visually consistent with other Bureau products, but reduce the time 
and cost to deliver multiple mobile products.
‣ Interaction Guidelines – A document that provides the interaction and gesture guidelines for 
mobile and tablet experiences.
The Bureau of Meteorology’s Mobile Strategy by s47G
44

---

‣ App Blueprints – A document that defines a variety of mobile and tablet application types, 
with example time, cost, and user benefits.
‣ Mobile App Vendor Guidelines – Produce a list of certified mobile vendors to provide services 
for the Bureau based on roadmap criteria.
‣ Deployment Process – Produce an app preflight, quality assurance, and deployment plan that 
markets should adhere to in order to maintain App Store and customer experience 
consistency.
‣ Mobile Accessibility Guidelines – Develop global mobile accessibility best practices to ensure 
that all mobile products confirm for local laws.
‣ Mobile Usability Testing Guidelines – A document capturing the process and best practices 
for mobile usability testing that has unique lab and deliverable requirements.
‣ Mobile Pattern Library – Document the common mobile user experience patterns that 
adheres to App Store acceptance guidelines and policies as well as the Bureau's own 
patterns.
3.5.3. Frameworks
The specific tools we employ to ensure that we are using consistent technology with all markets 
and vendors that supports both the user experience guidelines as well as the long term mobile 
roadmap.
Business Case
As more mobile and tablet applications are sponsored, reliable frameworks are required to 
provide a consistent customer experience across multiple projects and platforms. These 
reusable frameworks ensure that the mobile customer experience guidelines and best practices 
are consistent from project to project, while reducing complexity, time to market, and costs.
Return on Investment
The costs associated with supporting a variety of different technology frameworks will be 
compounded with each added device or platform the Bureau supports. Using an agreed set of 
frameworks that supports the guidelines and roadmap will reduce costs associated with each 
project.
The Bureau of Meteorology’s Mobile Strategy by s47G
45

---

Example Framework Components
‣ Prototype Framework – A framework to rapidly produce mobile/tablet prototypes to use for 
business validation and user testing, which is also very useful for creating/defining 
engineering end points.
‣ Container Framework – Produce a native container framework that supports journeys for 
mobile/tablet devices using a single container.
‣ Responsive Design Framework – Create, select, or customise an approved HTML5 library to 
serve as a starting point for mobile/tablet applications.
‣ Javascript Framework – Create, select, or customise an approved Javascript framework that 
will serve as the shared library for all HTML5-based mobile projects.
‣ CMS – Evaluate and recommend a CMS solution that can produce non-secure content for 
mobile and tablet apps.
3.5.4. API
The technology and documentation that is required to deliver the user experience across 
multiple digital platforms.
Business Case
To easily support multiple mobile and tablet applications a RESTful web services roadmap, 
documentation, and requirements are required. Understanding what user data can be accessed 
is the primary requirement for all mobile and tablet initiatives. Until this roadmap is defined it 
will be impossible to set appropriate expectations on timeline and cost for the business.
Return on Investment
Having a fully documented API to support mobile applications will greatly reduce the costs of 
mobile and tablet projects by having a consistent end point for development. As common user 
experiences are solved they can be reused across multiple projects.
Example API Components
‣ Web Services Roadmap – Document the requirements and roadmap of a JSON or RESTful 
Web Services to enable mobile/tablet solutions.
‣ Alerts Engine – Document the requirements of an API to deliver alerts to the customer.
The Bureau of Meteorology’s Mobile Strategy by s47G
46

---

‣ Data Visualisation Engine – Document the requirements of an API to deliver or create data 
visualisations to the application interface.
‣ Authentication Gateway – Document the requirements of how customers will authenticate 
themselves across multiple mobile/tablet applications.
‣ Mobile Analytics Solution – Review existing analytics solutions and evaluate their ability to 
support both an HTML5 and native app strategy.
3.5.5. Process and Templates
The methods we will need to employ to ensure that project sponsors, vendors, and 
stakeholders are meeting both Bureau and platform guidelines for successful market 
deployment from the start.
Business Case
Developing a process for defining mobile and tablet projects, and templates for documenting 
the outcomes is a crucial step to ensure that each mobile project contributes to the success of 
the overall mobile roadmap.
Given that the Bureau is unaccustomed to the complexities of mobile and tablet application 
development, creating processes and templates for sponsoring and kicking off projects will 
better align the business, design, and technology requirements for a more consistent customer 
experience across all markets.
Return on Investment
By having a codified process with supporting templates, the Bureau can ensure that each 
mobile project contributes to the overall mobile roadmap, producing greater consistency, 
efficiency, and effectiveness across multiple markets and with multiple vendors.
Example Process & Template Components
‣ Mobile Project Brief Template – A document to capture the high level requirements for a 
mobile/tablet project.
‣ Journey Framework – A template used to document mobile/tablet journeys.
‣ Screen Description Diagrams – A document used to prioritise features and requirements for a 
mobile/tablet application.
The Bureau of Meteorology’s Mobile Strategy bys47G

---

‣ Wireframe Templates – A template to rapidly produce wireframes for mobile/tablet based on 
approved assets and patterns.
‣ Design Templates – A template to rapidly produce mobile designs for mobile/tablet based 
on approved assets and patterns.
3.5.6. Actions
✓ These actions will be shared in the Roadmap Options section, summarised in the Executive 
Summary.
The Bureau of Meteorology’s Mobile Strategy by s47G
48

---

4. Roadmap Options
4.1. Apps
4.1.1. Overview
The first strategy is the most obvious one in today's marketplace – Apps. Mobile Apps, loaded 
on the device, provide a meaningful point of presence for users. Simply tapping to open it, they 
extract the information they want, and close it. The transaction is quick and simple.
The single biggest advantage that Apps provide the Bureau are push notifications, being able 
to send weather alerts out to users based on their location or preferences. An app of some kind 
is required as push notifications cannot be delivered through any other technology (e.g. 
HTML5). 
Weather applications are a unique utility in the mobile application space. Being a pre-built 
utility on most smartphones, consumers tend to pay for simplicity (e.g. Solar) and for detail (e.g. 
Dark Skies) over the pre-installed weather option. 
As far as we can tell, location-based relevancy isn't a high demand feature in the global app 
marketplace, but a highly requested feature in the customer research for the Australian market, 
likely due to the impact severe weather has on many Australians.
In order to meet this market need, any Bureau weather app must compete directly in App Store 
rankings in order to be seen by users and then downloaded. The competition may not have as 
relevant of data as the Bureau can provide, but they have hundreds, even thousands of ratings 
and reviews to reinforce the user’s decision on which app to download. 
In the consumer marketplace, if an application is free, then users will download them [multiple 
applications], trying each one once or twice before making a decision on which to use on a 
regular basis. If an application costs money, the user will review the application based on its 
The Bureau of Meteorology’s Mobile Strategy by s47G
49

---

ratings, reviews, icon, and screenshots. The higher the price point of the app, the more the user 
will be more discerning.
In other marketplaces affected by weather, such as labour, industry, transportation, aviation, 
government, or education, the app acquisition model is largely the same as consumer. Apps are 
downloaded through an App Store. For larger organisations they may maintain an internal App 
Marketplace, or do automatic asset provisioning. However this model isn't widely commonplace 
yet as many larger organisations are still switching from Blackberry infrastructure to an iOS or 
Android infrastructure.
In order to produce revenue from mobile applications, the Bureau must compete with similar 
weather applications on merits other than just data relevancy. Elements like application speed, 
design, innovation- must all be catered to in order to gain a large share of the addressable 
market. Only then will a viable revenue strategy around mobile applications become possible.
4.1.2. The Business Case
The strongest business case for mobile applications is the ability to provide users push 
notifications based on their location or location preferences. Together with the relevancy and 
accuracy of the Bureau data, we feel that push notifications would certainly be the "killer" 
feature of any Bureau app.
However, push notifications are not considered a premium feature by the public, and we do not 
believe that consumers are willing to pay for push notifications. Consumers think of push 
notifications as a feature of the application, and not a product unto itself. Therefore, we do not 
consider a premium push notification service as a viable product for the consumer market.
Industry users on the other hand are highly likely to pay for a push notification service, as the 
value and return on investment can easily be calculated and justified. Although, if a consumer 
application is providing push notifications for free, then why would the industry user pay for 
push notifications? The Bureau would have to provide other features specific to the industry 
market that differentiate an industry app from the consumer app. 
The Bureau of Meteorology’s Mobile Strategy by s47G
50

---

Therefore we recommend building two mobile applications:
Free Application
The first being a very simple and elegant weather report utility that allows the user to add up to 
five locations in addition to their current location, receiving push notifications and forecast 
information for each of the locations they follow.  This would largely be designed to be a 
replacement of their current default weather application, meant to be more relevant to the 
Australian market.
This application would be free and offer a few in-app upgrades (e.g. multiple locations, more 
detail, etc.) with its core focus would on simplicity- quick and easy weather on the go.
Premium Application
The second application would be a more robust premium weather application, providing 
custom push notifications, current weather conditions on unlimited locations, more detailed 
forecast data, high definition radar, and other premium features. While this application wouldn't 
be explicitly labeled industry, further research and analysis could tailor it to industry needs 
without losing a consumer focus. 
This application would cost anywhere from $1.99 to $4.99 and offer either in-app upgrades or a 
premium push notification service tailored to the needs of its power users. 
Both applications are necessary. The free app is designed to recruit customers away from the 
competition and show that the Bureau has the best, most relevant data to Australians. It is a 
necessary footprint on Australians phones- to provide them important alerts that concern their 
safety and illustrates the Bureau’s goodwill toward Australian citizens. 
The premium app borrows from the goodwill and trust earned by the free app to increase the 
perceived value of the Bureau’s data to those who need it most. In other words, the free app 
serves as a demonstration of the premium app, designed to recruit customers willing to pay for 
weather and climate information.
The Bureau of Meteorology’s Mobile Strategy bys47G

---

---

---

We recommend starting with iOS support, which is the most cost effective. We predict that 
Android will become a viable platform in Australia within the next 24 months and it will 
ultimately need to be supported.
4.1.6. Components
The components required for this strategy would be the following:
‣ Guidelines
• Mobile Strategy
• Mobile Requirements
• Device Plans
• Mobile Design Language
‣ Frameworks
• Prototype Framework
‣ APIs 
• JSON Data Service
‣ Process & Templates
• Mobile Project Brief Template
• Journey Framework
• Screen Description Diagrams
• Wireframe Templates
• Design Templates
4.1.7. Actions
✓ Establish a Product App Roadmap with defined core feature sets
✓ Resource, plan, and develop a free application per the Roadmap. This app will recruit 
customers away from the competition and show that the Bureau has the best, most relevant 
data
✓ Resource, plan, and develop a premium application per the Roadmap.  This app would 
provided detailed, specific weather information to users that need it for frequent, financial-
impacted weather decisions, e.g. Industry
The Bureau of Meteorology’s Mobile Strategy by s47G
54

---

4.2. Publishing
4.2.1. Overview
The second strategy focuses on how the Bureau publishes content, aiming to reduce the 
complexity of publishing to the web, while simultaneously increasing support for mobile 
devices, potentially saving the Bureau hundreds of thousands of dollars per year. 
Currently, the Bureau publishes content to the Web using data driven tools.  By adopting a 
modern publishing process – using a web standard HTML5 framework, responsive web design 
techniques, powered by a content management system – the Bureau will be able to publish 
content once and distribute to a number of mobile, tablet, and other digital devices far easier 
and faster than the publishing process being used today.  
The downside is that HTML5 mobile apps do not have a viable application marketplace, 
meaning distributing and earning revenue from HTML5 mobile apps is not as simple as 
publishing an app to a few App Stores.
However HTML5 is perfectly suited for a free consumer mobile application. The Bureau could 
offer an HTML mobile app through any web browser on any platform. And with the addition of a 
simple native WebKit container like PhoneGap, the Bureau could also distribute an HTML5 
application to the mobile App Stores, delivering push notifications to consumers.
With a more streamlined publishing process in place, a premium software-as-a-service also 
could be introduced for industry customers. A web service would provide customers a simple 
point of presence to handle management of settings, all credentials, multi user access, and 
billing.
In this strategy all application logic lives in the cloud, therefore complex applications do not 
need to be created to cater to the needs of multiple audiences. A single container app could be 
deployed for both consumers and industry customers, reducing the cost and complexity of 
managing multiple native applications.
The Bureau of Meteorology’s Mobile Strategy by s47G
55

---

---

required to evaluate and deploy a CMS within the organisation as well as pilot a mobile 
program would be significant. 
To mitigate this risk, a data proxy or content adaptation service could be used instead of a CMS, 
to enable a mobile publishing pilot while a search for a CMS can take place.
UI
Another risk is the lack of a standard mobile user interface for HTML5 mobile applications. Any 
HTML5 mobile app deployed with a native container will still need to meet Apple's certification 
guidelines. This means that an HTML5 mobile app must meet Apple's stringent Human 
Interface Guidelines.
5.1.2. Components
The components required for this strategy would be the following:
‣ Guidelines
• Mobile Strategy
• Mobile Requirements
• Device Plans
• Mobile Design Language
‣ Frameworks
• Prototype Framework
• Container Framework
• Responsive Design Framework
• Javascript Framework
• CMS
‣ APIs
• JSON Data Service
‣ Process & Templates
• Mobile Project Brief Template
• Journey Framework
• Screen Description Diagrams
The Bureau of Meteorology’s Mobile Strategy by s47G
57

---

• Wireframe Templates
• Design Templates
5.1.3. Actions
✓ Review the current data architecture to determine data that can be made easily available vs. 
data that would be difficult to access
✓ Determine the technical strategy to have data be made available for both mobile web and 
mobile app – both short term (perhaps temporary) and long term strategies
✓ Resource, plan, and execute on the Publishing strategy to make data available for internal 
web and application use
5.2. Services
5.2.1. Overview
The third strategy focuses on producing premium digital weather services, with focus on the 
Bureau's efforts of making data available for a fee.
Producing native applications, or even retooling the Bureau's publishing strategy may simply be 
too costly of an investment with not enough of a return. Therefore, instead of entering the 
consumer marketplace, the Bureau should consider simply making data available through a web 
service to those willing to pay for quality weather information.
A digital weather service can take many shapes – it could be to provide raw weather data to 
competing applications, to partner with operators to provide weather alerts to subscriber, or to 
provide a rudimentary software-as-a-service solution for industry, similar to what is described 
above in the publishing strategy. 
The substance of this strategy is that there is potentially more revenue to be made from 
licensing the Bureau's weather data, than could be gained from entering consumer or industry 
markets on its own.
The Bureau of Meteorology’s Mobile Strategy by s47G
58

---

The focus on a premium digital weather service is an extremely prudent strategy, as it is a 
mandatory component to any other strategy. Both the native application and publishing 
strategy would require a web service in order to be competitive. 
Starting with a digital services strategy would establish an incredibly strong platform for the 
Bureau. Any application that the Bureau wishes to create in the future would be based on this 
platform.
The key to this strategy is empowering external entities to create weather applications using the 
Bureau's data. With the proper licensing, co-branding, and developer tools, the Bureau could 
have dozens of Bureau-powered weather applications in the market, rather than just one or two. 
The cost to the Bureau would be nominal, but the market reach extensive.
Furthermore, as developers create Bureau-powered applications, the Bureau can recruit the 
best developers to work for the Bureau directly, solving two big problems in one step – 
acquiring both talent and code using the Bureau’s data for less than the cost of developing an 
app internally and from scratch.
5.2.2. Risks
API
The greatest risk to a services strategy is the lack of a RESTful API. The level of effort required to 
deploy an API and services and billing model within the organisation would be significant. 
Lack of Resources
In addition to the lack of an API, it is uncertain if the Bureau has resources that understand the 
technical architecture and software-as-a-service model well enough to successfully lead the 
Bureau toward a positive outcome.
5.2.3. Recommendation
A services-only strategy does not meet the criteria from the business requirements or customer 
research we gathered, therefore we do not consider a services-only strategy to be a viable 
stand-alone option.
The Bureau of Meteorology’s Mobile Strategy by s47G
59

---

5.2.4. Actions
✓ We recommend that the Bureau further explore the possibility of developing a services 
strategy, in additional to the app data necessary via the publishing strategy.
5.3. Roadmap
5.3.1. Overview
With both the App strategy and the Publishing strategy achieving identical scores, we 
recommend the best strategy for the Bureau is to move forward with both – starting with 
reducing the time and effort being invested into web publishing and then moving to apps.
Although the Services strategy scored lower due to this being a new model for the Bureau, we 
also recommend the Bureau develop a services strategy to eventually offer fee-based data to 
the public or industry segments.  This would require refined, modern data feeds with the 
flexibility for the customer to customise content based on their need.  As mobile technology is 
rapidly changing, and as development tools become increasingly available to the market, the 
data services product will require a dedicated team to evolve for the ever-changing need.  That 
said the Bureau is truly a data company, capturing some of the most accurate weather data of 
any country, and this is thought to be a very valuable, long-term revenue generator in the years 
to come. 
Using this roadmap, by end of Year Two, the Bureau would have the following:
‣ a free public offering, both on the web and natively
‣ a premium option, available to the public and industry for those who want more than the free, 
minimum viable product
‣ an option that provides customised alerts to multiple industry users
‣ the foundation of a services strategy
‣ a great number of evolved program components to expedite the design and development of 
future products
The Bureau of Meteorology’s Mobile Strategy bys47G
60

---

5.3.2. Year One
Program Components 1.0
✓ Begin building version 1.0 of core components necessary to Year One of the Road Map.
✓ Establish user interface design language, elements and style guide
Publishing Strategy 1.0: Responsive Web Design
✓ Offer basic functionality of current market apps– location based conditions, multi-day 
forecast, multiple locations – using responsive web approach
✓ Available on any modern smartphone
✓ Deploy a CMS and/or publishing system
✓ Begin publishing pages using a cross platform framework
✓ Use responsive web techniques to reflow content to desktop, tablet and phone
✓ Promote/surface high-value web products that would benefit from a responsive strategy
Services Strategy 1.0: Invest in Data Architecture
✓ Build a simple JSON data service required for native applications
✓ Develop a content proxy to support data service for App strategy
App Strategy 1.0: Free Weather App with Alerts
✓ Design, develop and deploy an iPhone only application
✓ Leverage brand recognition to displace competition
✓ Offer basic functionality of current market apps – location based conditions, multi-day 
forecast, multiple locations
✓ Attempt to earn a maximum amount of iOS market share
✓ Alerts for severe weather – wind, thunderstorms, fire, flood
✓ Provide a beautiful interface design
✓ Establish a page stack and native direction that will carry forward to support the roadmap
5.3.3. Year Two
App Strategy 1.5: Premium App
✓ Provide a premium app, or paid in-app upgrades, e.g. customisable alerts
The Bureau of Meteorology’s Mobile Strategy by s47G
61

---

✓ Include additional features that add depth and breadth
✓ Upgrade to a Plus app to support both mobile and tablet
✓ Conduct additional research on how to serve all the industry markets
✓ Use the same code base as future industry apps
Program Components 2.0
✓ Begin building version 2.0 of core components necessary to Year Two of the Road Map.
Publishing Strategy 2.0: Reduce Web Pages
✓ Begin to sunset un-used web services
✓ Begin to replace web products with program outputs with more appropriate mobile 
solutions
✓ Reallocate redundant web expenditures toward the mobile program
App Strategy 2.0: Free, Premium & Industry Apps
✓ Employ a build it once, use everyone approach
✓ Begin to deploying industry specific apps based on the Free & Premium code base
✓ Add Android support
5.3.4. Year Three
Services Strategy 2.0: Data Pilot
✓ Build service that is able to offer JSON data feeds
✓ Establish monetization tiers and weights for services strategy
✓ Develop a billing system
✓ Continue to make more data available to the web service
✓ Begin running a pilot program of a data services pilot
Program Components 3.0
✓ Begin building version 3.0 of core components necessary to Year Three of the Road Map.
App Strategy 3.0: Disruptive Apps
✓ Begin empowering public to become meteorologists through mobile apps
✓ Begin establishing the Bureau as world renowned experts and leaders in weather
✓ Begin migrating Bureau mobile brand from current to future state
The Bureau of Meteorology’s Mobile Strategy by s47G
62

---

6. Market Research
6.1. App Reviews
Reviews of the Australian competitors conclude that apps using extremely localised data 
(provided by the Bureau) for current conditions, now-casts and multi-day forecasts, radar, and 
especially weather warnings are preferred to other outside apps using data that varies- resulting 
in inaccurate forecasting.
6.1.1. App: Pocket Weather
‣ Priced at $1.99
Highlighted features include:
‣ hourly temperature updates for four territories
‣ push warnings for BOM weather alerts
‣ Tide data available offline
‣ Australian rain radars
‣ satellite maps and synoptic charts
‣ forecast data on app badge
‣ localised information: pressure humidity, forecasted UV, live UV, dew point, rainfall, wind, 
sunrise/ sunset 
‣ "follow me" location
Other positive notes include:
‣ hourly forecasts (ranging out to six days)
‣ detailed knowledge of localised weather
‣ straightforward and simple interface
‣ localised forecast data
‣ short-term forecasting (for the day/ hourly breakdown)
The Bureau of Meteorology’s Mobile Strategy by s47G
63

---

‣ accuracy with data from BOM
‣ UV conditions, sunrise/ sunset, wind conditions, weather warnings 
6.1.2. App: Weather Zone Plus
Weather Zone Plus is another app using BOM data. The reviews stated:
‣ more detail for each day with hourly and three-hour predictions 
‣ weekly forecast is not easily visible
‣ rain radar is not as detailed as Pocket Weather radar 
‣ too many banner adverts on the free version
6.1.3. App: The Weather Channel
‣ does not use bureau data 
‣ forecasts can vary
‣ don't have access to the many of regional Aus forecasts
‣ no BOM weather warnings
‣ cluttered interface
‣ banner adverts
‣ lack of access to Australian rain radar
‣ good travel app- but Australians want a better regional app for home
6.2. Design Insights
6.2.1. Simple Presentation
Consumers will find weather apps falling into a two main categories. Densely designed for 
maximum weather information or very minimal with a few points of information, allowing the 
user to decide how much data to receive by electing to drill down into the app. 
However, the highest rated, best reviewed apps are designed so that relevant weather 
information is on the first screen without being overloaded, so as not to overwhelm the 
The Bureau of Meteorology’s Mobile Strategy by s47G
64

---

customer- an example of provided relevant data includes: current temp, precipitation, wind, and 
brief forecast. The app will use a combination of simple design, yet available detail data for 
consumers to discover. How does the customer justifying paying for the app when there are 
great free apps? The difference is in interface, design, data presentation, and accuracy.  
An example of a high-quality, informative app with simple design is Yahoo! Weather. On the 
primary screen one can view a flickr photograph of the location, hour, photograph of current 
location, current temp, “feels like” temperature, and cloud cover. Almost the entire app can be 
navigated in one gesture- scrolling down into the app (upwards gesture on screen): first to 
reveal an elegant presentation of the weekly forecast, and details like cloud cover, weather 
description, and humidity. Next, a map of current location area is shown which can be touched 
to expand upon to reveal  radar and colour coded temperature and wind conditions. Further 
scrolling reveals more details on precipitation (chance of rain), wind and pressure, and sun and 
moon information. The upper right hand corner presents a navigation button allowing the user 
to add more locations. Swiping is used to switch between locations.
Another app falling into the simple yet informative category, Weather Puppy (a lifestyle app for 
charity, dog-lovers) also uses a simple interface to provide the customer with a lot of 
information, but simply, using a few gestures to drill further into the app to reveal more detailed 
reports. A touch on the temperature reveals precipitation, pressure humidity, wind, visibility sun 
rise/ set information. Swiping down on the temperature reveals an hourly forecast. Touching on 
days of the week in 7-day forecast reveal more weather information about the day.
6.2.2. Interface, Design, and Data Presentation Trends
The trend in app design overall has been towards a simpler design with flat interfaces- this 
includes weather apps. It is a design solution to a problem. The apps rated as most valuable 
(customer willing to pay) and successful (highest ratings and most reviews) apps appear to be 
apps moving towards a fully digital design. Easy to use, intuitive, lacking in visual metaphors 
that tend to look cluttered on a mobile device- clarity and creative data visualisation in the UI, 
and UX design is the trend in weather apps.
Although, with the abundance of weather apps on the market- much to the consumers’ benefit, 
one will find many different perspectives in design.
The Bureau of Meteorology’s Mobile Strategy by s47G
65

---

6.2.3. Navigation
Reminiscent of the productivity app Clear. Weather cube is gesturally based in its navigation. 
Using multi-touch in lieu of scrolling- pinching, swiping, and tapping to see more or less 
information. It has a very modern appeal, using an entirely digital, flat design. Though, like a 
Rubix’s Cube one can turn the entire cube in the app and find more information, tapping 
squares for details. Reminiscent of the productivity app Clear.   
Living Earth allows the user to spin the globe around to discover different areas climate and 
weather information.
The Weather Channel uses buttons as a navigation metaphor giving it more of a traditional 
web-page feel. Provided is a menu to which customers can turn for navigation. And tiles along 
the bottom of the screen to visit more information (pollen), videos, and radar. The hourly 
forecast buttons are ever present at the top of the app.
Weather Channel, Earth 3D, Clear Day/ Weather HD (uses buttons, splitting half the button 
indicators between very simple icons and plain typeface).
6.2.4. Dynamic and Static Design
Live radar maps are usually presented with a “play” button to begin radar mapping animation 
for cloud, temperature, and other weather revelations. Furthermore, the market research shows 
that animation can be used in very creative ways- to give a certain richness to overall app 
experience and appearance of the app. 
Parallax effects, the use of slow moving background visuals have been used in Clear Day 
(formerly Weather HD)- as richly coloured, “real-life” animated image of clouds, or dew on the 
earth to make a very simple app quite beautiful. This effect is also very subtly in use in the 
Yahoo! Weather app when swiping to change cities, and the blurring of the background as one 
chooses other weather information. 
Thoughtful, yet subtle details such as these help to give a “weight” to the app that is 
meaningful to customers and creates a sense of value in the app and data presented. 
The Bureau of Meteorology’s Mobile Strategy by s47G
66

---

6.2.5. Animation & Colour
Using animation to reveal a selected or pressed state button, or bending and stretching buttons 
(see Haze example below).  Ambient glowing, jiggling or undulation in icons or “buttons” to 
indicate action (Solar, Good Weather, Climate Clock). 
Also included in the examples are context dependent colours: i.e. blue or navy for night or 
cooler temperatures, orange or yellow or red for day or warmer temperatures (Solar, Skye, 
Weather Pup, radar).
6.2.6. Lifestyle & Social Sharing
There are customisable apps that can be suited to your lifestyle and activities. Certain apps 
provide the option for a tailor made set of conditions for various activities. 
Socialisation is a large part of the app experience. The ability to stay connected with friends and 
share current conditions seems to be an important feature to digitally native consumers. 
‣ Takeweather is an app wherein users take photos of their current conditions. 
‣ Weather HD Tweets includes a map and location of tweets about weather around the country. 
Earth 3D allows a live tweet of reported conditions to Twitter.
‣ AccuWeather gives users the option of setting their perfect conditions (temperature, wind, 
rain, etc.) and entitle the set for “Fishing” or “Golfing”, or “DIY Projects”. The Weather 
Channel provides points of interest for activities (see below, like parks, golf courses, 
lakes).Weather Quickie is a comparison to weather from the day before.
‣ Swackett uses avatars, “peeps” to demonstrate appropriate clothing options for the day. The 
app includes other useful information but uses the “peep” avatar to convey quickly to the 
user what the weather will be like.
6.2.7. Overall Impressions
The consumer is clearly the winner in this market flooded with options- they benefit from 
innovations in what appears to be one of the most competitive markets in the app industry.
The Bureau of Meteorology’s Mobile Strategy by s47G
67

---

According to the consumer purchase data and innovation trends in an internal review- it should 
be noted that the “Top Apps” ratings, based on:
‣ innovation
‣ design quality
‣ data quality
Only three percent of the apps rated received perfect scores across the board. Over 54% of the 
cream that rose to the top were paid apps, less than 50% were free apps.
People are willing to pay for quality apps. The apps focused on thoughtful and useful interface, 
design, data presentation were in the top tier for customer ratings and purchase. To the users, a 
focus on these aspects of the app design and experience translates to high quality and 
simplicity of use- and these apps win out in the crowded weather-app landscape.
The Bureau of Meteorology’s Mobile Strategy by s47G
68

---

7. App Descriptions
7.1. Mobile Websites
A mobile website is a website designed specifically for 
mobile devices, not to be confused with viewing a site 
made for desktop browsers on a mobile browser. 
Mobile websites are characterised by their simple 
“drill-down” architecture, or the simple presentation of 
navigation links that take you to a page a level deeper.
Mobile websites often have a simple design and are 
typically informational in nature, offering few—if any—
of the interactive elements you might expect from a 
desktop site. Mobile websites have made up the 
majority of what we consider the mobile web for the 
past decade, starting with the early WML-based sites 
(not much more than a list of links) and moving to 
today’s websites, with a richer experience that more 
closely resembles the visual aesthetic users have come 
to expect with web content.
Advantages
‣ They are easy to create, maintain, and publish.
‣ They can use all the same tools and techniques you 
might already use for desktop sites.
‣ Nearly all mobile devices can view mobile websites.
Disadvantages
‣ They can be difficult to support across multiple devices.
‣ With now CMS in place they can create a significant content redundancy 
The Bureau of Meteorology’s Mobile Strategy by s47G
69

---

‣ They offer users a limited experience.
‣ Most mobile websites are simply desktop content reformatted for mobile devices.
‣ They can load pages slowly, due to network latency.
7.2. Responsive Mobile Websites
A responsive mobile website is an experience that is built for multiple device contexts, but with 
a single source of content. Under very specific circumstances the user experience of this 
approach can be equal to a Class 1 Mobile App, which we will come back to.
Advantages
‣ Support mobile devices from a single code base
‣ Based in web standards
‣ Increases accessibility and SEO.
‣ Data integration is very simple.
Disadvantages
‣ Does not address the users context.
‣ Most websites are not designed to be “responsive” and need to be refactored from scratch.
The Bureau of Meteorology’s Mobile Strategy by s47G
70

---

7.3. Mobile Web Apps
7.3.1. Class 1 Mobile Web App
A Class 1 Mobile Web App uses the latest innovations 
and capabilities present only in the iPhone, iPad and 
late model Android devices (3GS and higher, iPod 
touch 4th Gen and higher, iPad 1 and higher, most 
2013 Android devices).
Advantages
‣ Best possible mobile experience
‣ Complex user interfaces, animations is possible.
‣ Access to device features is possible.
‣ The user experience can be very close, and in some 
cases on par with native iPhone apps.
‣ Fixed headers and footers are possible.
Disadvantages
‣ Class 1 Mobile Apps does not have backward 
compatibility and does not support other 
platforms.
‣ Complex Javascript is required for data integration 
and is difficult to debug.
7.3.2. Class 2 Mobile Web App
A Class 2 Mobile Web App supports high end WebKit browsers with devices that have at least 
1Ghz processors (all iOS devices and most 2012 model Androids).
Advantages
‣ Complex user interfaces are possible.
‣ Support the majority of high end smartphones on the marketplace.
The Bureau of Meteorology’s Mobile Strategy by s47G
71

---

‣ Has limited backward compatibility.
Disadvantages
‣ Use of animations are processor and battery intensive.
‣ Cannot use fixed footers and headers
‣ Complex Javascript can be required for data integration and is difficult to debug.
7.3.3. Class 3 Mobile Web App
A Class 3 Mobile Web App has the highest degree of smartphone device compatibility, 
provides for high quality user experience, as well as supporting higher and lower classes 
(supports all iOS devices, all Android devices, BlackBerry Torch and higher).
Advantages
‣ Supports the majority of devices, but not all.
‣ Provides a quality user experience on more capable browsers, and degrades to lessor 
devices.
‣ Is easier to support with complex data integrations.
Disadvantages
‣ Cannot support fixed header or footer.
‣ Cannot support animations or screen transitions.
‣ Limited Javascript support.
7.3.4. Class 4 Mobile Web App
A Class 4 Mobile App is designed with compatibility in mind, seeking to have the best possible 
user experience across the widest number of devices. This is the best approach for supporting 
Windows phones or BlackBerry devices other than the Torch.
Advantages
‣ Support the largest number of handsets
‣ Is simple to design and develop
‣ Is simple to deploy
The Bureau of Meteorology’s Mobile Strategy by s47G
72

---

---

At any rate, a native application requires resources that understand how to build and deploy 
native apps, as well as a RESTful data service to power it. None of which the Bureau currently 
has in place.
Advantages
‣ Best possible customer experience
‣ Probably the best experience for the audience, but this would need to be confirmed
‣ Takes advantage of Apple App Store marketplace (a new SEO)
‣ A strong reference design can lower overall costs for other platforms
‣ It could possibly be the least development effort
Disadvantages
‣ Limited to iOS devices
‣ Unknown level of effort to produce
‣ Requires in-house staff to manage after the product it is complete
The Bureau of Meteorology’s Mobile Strategy by s47G
74

---