Good news music fans! We’ve released a children’s music app, Moozart. Well, we released it in 2010 and thousands of people paid to download it, BUT, thanks to changes in iOS over the years, a few new bugs needed to be worked out.
For the holidays, we’ve released an update to Moozart that fixes audio issues on iOS 8, provides retina graphics, stops intermittent crashes some people have encountered, provides stereo audio, and has better music. And we are now offering it for free! Get it now in the App Store.
After a few years of evolving beacon technology, hardware providers are introducing a new generation of products into the marketplace. Estimote is doing this with Estimote Stickers, complementary to their standard beacons. Stickers contain an accelerometer, temperature sensors and an optimized ARM processor (with flash memory and a Bluetooth Smart controller). This is all inside a significantly smaller and thinner form factor. These stickers are designed to be placed on everyday objects, which brings us to the Estimote coined term, “nearable.”
By attaching a Sticker to an item, it turns into a nearable – a smart, connected object that broadcasts data about its location, motion and temperature. Estimote defines a nearable as an intelligent object linked by a smart beacon, with a rich SDK, to the cloud.
Join this week’s “Introducing Nearables” TweetChat, #iBeaconChat #nearables, with Estimote’s Roshan Prakash (Business Operations Manager) and Wojciech Borowicz (Community Evangelist) as we discuss why nearables matter and what they can do for you.
To prepare yourself for the chat, review the questions here:
- What are nearables?
- What are Estimote Stickers?
- How do Stickers differ from enterprise grade Estimote Beacons?
- What are possible use cases for #nearables?
- How to create apps for #nearables?
On Tuesday, October 7th at 8:30AM PDT / 11:30AM EDT
Join us on Tuesday at http://twubs.com/ibeaconchat for the live chat! To join please use the hashtags: #iBeaconChat and #nearables
We’ve been talking to lots of people about beacons these past few months. There’s a ton of interest from local businesses of every size who have quickly recognized the power of connecting real-world users and environments with apps on smartphones and tablets. Our conversations often lead to impromptu brainstorming sessions as business owners think of ideas to incorporate beacons into their marketing mix.
But, there’s one question we always bring to the table, and sometimes it stops ideas in their tracks: “How is this idea good for your customers?”
meltmedia is not a typical interactive marketing agency.
Nearly half the company’s employees are technical and actively develop code. We don’t outsource any of our technology needs because we have plenty of expertise in our Tempe, AZ offices. We don’t call ourselves a “Java shop” or a “.Net shop” because we know how to make use of the best technology for any solution regardless of what language or platform is popular at the time.
We are a company of passionate people. Over the past year, we’ve focused our passion on the practice of automation. The following quote is of great significance and inspiration to us:
Machines need to be productive. People need to be effective. – Jim Benson & Tonianne DeMaria Barry, Personal Kanban
As you read this, Apple has already deployed iBeacons (referred to from here on as, “Beacons”) in its US stores. shopkick is testing its own Beacons in New York and San Francisco. A number of Beacon vendors are shipping their own versions of Beacon hardware to developers (we have several in-hand here at meltmedia). The buzz started when a slide at Apple’s World Wide Developer Conference listed the term, “iBeacons” among a myriad of other technologies being introduced there. Once the industry figured out what the term meant, it went all giddy about Beacons and for good reason.
We met 5 times before the hackathon began to plan our app. When the Node Knockout finally came, we were ready. We broke up the 48 hours into shifts, and after a lot of beer, coffee, and sleepy status updates, we finished our app with an hour to spare.
UPDATE: FLTR is now live at fltr.io!
meltmedia has something cool we’re going to share with marketers and digital professionals. It’s called FLTR: Forward Looking Tech Radar (pronounced: “flitter”).
The digital marketing landscape is populated by an overwhelming glut of buzzwords, technologies and tools. FLTR will provide you with a quick visual indicator of trends in technology that are relevant to you. At a glance, you will see which tech topics are trending toward more or less relevance in the marketplace. With FLTR, you will be able to move backward and forward in time to track the history and predict the future of these “bogeys” on the radar screen.
Ten years ago, Dave Shea announced the CSS Zen Garden. His original goal was “[…]to create a page that allows for some wildly different CSS designs, while coding valid XHTML 1.1, valid CSS, and conforming to Section 508 and AAA accessibility guidelines.” It is a single page of HTML that you can apply any of 213 CSS stylesheets to.
Back in 2003 seeing the power of using CSS like this with valid markup wasn’t revolutionary, but the idea of separating content and style was. The Zen Garden made people re-think how they made web sites. The internet was filled with nested tables and inline styles at the time. And just two-and-a-half weeks after Dave Shea announced the CSS Zen Garden, Jeffrey Zeldman published the first edition of Designing with Web Standards. It was the beginning of the Web Standards Movement.
Since then it has become the industry standard to keep content and design separate, and to write HTML and CSS that is valid according to the standard set by the W3C.
Part 2: The “Why” and the “Why Not”
If I counted correctly (I can count to 2, for sure), this is the second and last article of a two-part series. In this article, I write about the pros and the cons of each of the three methods for building a mobile app.
Typical Timelines for Mobile App Development Methods
The three major stages to most software development processes involve design, development (coding) and quality assurance (QA). The chart below attempts to show a rough comparison of those project timelines for an imaginary mobile app project that involves three platforms (iOS, Android and Windows) and the web. Based on past experiences here at meltmedia, the impact on time is shown by the length of the bar, as a percentage and in actual (imaginary) hours. Actual miles may vary, of course.
We’ll refer to this chart in each of the three sections below. For the sake of having numbers that we can wrap our brains around, our project chart up there shows (vertically and by color) the three main segments of a typical application development timeline: Design (orange), Development (green) and QA (blue). The imaginary “Native App” project has three tracks (iOS, Android and Windows) of 250 hours each (62.5 hours for design, 112.5 hours for development and 75 hours for QA), totaling 750 hours for all three platforms. The “Hybrid App” project will total 550 hours. The imaginary “Mobile Web App” project (the bottom track) will take 250 hours total for design, development and QA.
I haven’t met a designer yet who didn’t know at least a little about color theory. It’s a great tool to have in your belt when you’re working with anything visual. But what tools do you use to generate your color scheme, and what about when those colors are handed off to a developer?
LESS is a CSS preprocessor developed by Alexis Sellier (aka cloudhead). At meltmedia, we use LESS for the majority of the websites we develop. It’s quite a powerful tool, and speeds up development significantly. For this article, we’ll focus on LESS color operations. You can use the color operations to dynamically create just about any color scheme you’d like.
Part 1: The “How” and the “What”
It turns out this topic of building a mobile application is difficult to write about. In our experience at meltmedia, all the methods discussed below have their merits and their caveats. In reading around the blogosphere and web-o-whatever-it’s-called-sphere for more opinions, I’ve found that there are many great discussions about building mobile apps and even more opinions and defenses for each of them. After all that, my answer to your question, “Which method?” remains the same: “It depends.” Today, for you only, that advice is FREE.
This first part of the series describes the methods by which mobile apps are built and gives some familiar examples of apps that use those methods. The next article will look at which method might work best for your project by examining the benefits and caveats to each method and other considerations in making the best choice.
Let’s get on with some definitions, shall we? There are three major ways to build your mobile app: Native, Web and “Hybrid.”
Native Mobile Apps