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.
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
Recently, we were invited to talk on a number of tech topics at a small in-house corporate conference, mostly geared toward mobile web and apps. One topic for which I gathered information was a list of the latest technology trends I thought this audience (brand management) should keep an eye on.
To make sure this tech trend list wasn’t just my singular world view of trendy tech, I searched a number of sources online and compiled a unified list of about 26 of the most mentioned techs I found. I then had our illustrious and tech-savvy team here at meltmedia check off the items in that list that they thought were truly trending tech for 2012. I compiled the results and wanted to share them outside of that conference.
The best part about this list is the title of ten words which fits it to a T: The Two Thousand Twelve Top Ten Tech Trends To Track
The argument between whether the web is dead and mobile apps will reign supreme or vice versa has been a hot topic lately. My recommendation is to forget this argument for now. The web and apps are here to stay over the next few years and the discussion should be focused on what does this mean for your business. I see the following innovation cycle, described below, continuing to occur over the next few years. Understanding this cycle will help drive your mobile strategy.
Arguing over semantics is pointless, right? Not when it comes to your markup. Semantic HTML is a crucial skill that many junior website-makers ignore. Using smart, semantic markup will make sites more future-proofed, more accessible, friendlier to search bots, and much less headache-inducing for the human side of the matter.
What Is Semantic HTML?
What does it mean for markup to be semantic? It means that your markup tells a story. HTML is not just a series of elements thrown together on a page; it needs to represent the meaning of the website. Remember junior high when you had to make outlines with endless roman numerals and headlines for organization? That’s how your HTML should feel. Every element should represent something real– not something merely for presentation. And if it doesn’t, find a better way to write it.