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.
In July 2010, we had our first beard-growing competition–AKA “beard-off”–and it ended in just 17 weeks.
We started our second competition in November 2012 and it’s. still. growing. Er, going. Only three of the original seventeen competitors remain and we’re forty weeks into it. Yikes.
So really, why?
Earlier this year, friend and former meltmedian, Nick Crohn and I were discussing hiring challenges over lunch. The question of the day was, “How do we attract great talent to come to Phoenix and keep them here once they do?” We easily listed handfuls of reasons we love living here and it dawned on us. We spend a lot of time building up and promoting our brands and projects, but we spend little time talking about Arizona. Our state has a lot to offer and so why.az was born.
We wanted to avoid a sales pitch. Our first goal of WhyAZ was to share honest and real reasons why we love living and working in Arizona. To provide interesting, digestible information that many may be surprised or delighted to learn. Our second goal of WhyAZ was to make the site visually and technically interesting with hopes designers and developers might appreciate the aesthetic and examine how it’s built.
When deciding what approach to take, I thought a lot about what makes web design exciting for me. In May I attended CSSConf in beautiful Amelia Island, Florida. One of the recurring themes was the blurring between design and development and utilizing CSS3, Sass, and browser tools to enhance our designs. With only a few lines of CSS, we can easily duplicate the intricate design work we’ve previously reserved for Creative Suite. As a designer who prefers to work in a text editor, it really is exhilarating to type words and numbers and see pictures come out the other side.
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.
AF: The other day you and I were chatting and you asked me, “How would you define a company’s culture?” I had to think about it. Generally when you ask me questions, they’re loaded or you’re expecting me to crack a joke. Seriously, I had to think about it.
Then I had to think about it more. I thought a little more than that. Then I thought for another 2 seconds or so. The on-the-fly answer I gave was a little like this: “I guess I’d always considered culture as the combination of the environment of an organization and the sum of the personalities in that organization. It’s the way people work and the way they interact. Maybe a little of the space in which they work is mixed in there for good measure.”
AG: Well, the reason I asked is because I’ve been reading a lot about company culture lately. I liked what I was reading, but I wasn’t really sure all the different authors were defining “culture” in the same way. And then I realized that I didn’t really know how to define it myself. And then I realized I should probably put some pants on and leave the office.
So, I started looking for more formal definitions of company culture. There are a lot of great articles about culture, but very few articles actually defined how they were using the term. The Harvard Business Review even went so far as to ask, “What the hell is culture anyway?”
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.
Over a year ago we released a small collection of free icons on our blog. As it turns out people liked them, and not just because they’re free. So in keeping with the spirit of being Interactive Superheroes we’ve made a new and improved set, and we’re calling them melticons Mk 2!
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
Responsive design is a different approach to creating a website so, naturally, other parts of the process will be different too. Some aspects may be new or challenging. We hope to prepare you for how a responsive approach may contrast with your past experiences in the following ways:
Timeline and Budget
A responsive approach will take longer and thus cost more up-front than what you may be used to. But over time, if managed properly, a responsive approach can save you effort and cost on maintaining multiple platforms across devices. So how much more to go responsive? Hold on to your hat(s). I’ve heard of some responsive design projects costing 100% more than a traditional redesign. And it’s safe to say the average will fall somewhere between 25-75% more. Why is it so much more? Basically, there’s more planning, more cases to consider, and much more testing.
Conversations around budget are a great time to discuss the benefits of a responsive approach with your team. While the price of a more traditional redesign might seem easier to swallow, there are many costs of not optimizing for the different devices and connection speeds your users are sure to encounter. So while responsive will take more work, it reduces the risk of losing business from visitors who can not load or view your site on their devices.