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?”

And where the hell is my car?

Right?

How about this question: What ISN’T culture? Turns out, there’s LOTS of stuff that isn’t culture: Nerf guns, cool furniture, artwork around the office, chalkboard-painted walls, dartboards… None of that stuff is culture. It’s a manifestation of the personalities of the people working at a company.

In The 7 Habits of Highly Effective People, Dr. Stephen Covey talks about the “Personality Ethic” vs. “Character Ethic.” The Short Attention Span Theatre version of it is this: Character is internal, harder to judge at a quick glance. It’s based on principles and morals and is difficult to fake. Personality is more of the outward appearance. You might define a person with a “great personality” as energetic, outgoing, fun, funny, etc. We can see (if you will) a personality almost immediately. A person can have a great personality but have a shady or milquetoast character.

WOOT! I used the word, “milquetoast!!!” Day is done.

No it isn’t, Andy, keep writing.

Gah. OK, so what if that person with the great personality has a crappy character? What does that mean? Well, they might be the life of the party, but in a real-life situation where their character must come out, you’ll see that the person isn’t really that nice or friendly or maybe they really only care about themselves.

I think this goes for company culture, as well. Many people think a company’s personality is its culture. Maybe that’s true to a degree.

I think you think they think that.

I think the bulk of a company’s culture is truly its character.

Okay, that makes sense. Then meltmedia’s character would include its five core values: outstanding results, innovation, client satisfaction, accountability, and teamwork. And meltmedia’s personality would include the nerf gun fights, chalkboard walls, casual dress code, and The Ronberry.

Another character trait I’ve noticed is our drive to compete against ourselves. Every new project is measured against the quality of the last best project. We’re constantly trying to one-up ourselves. And that’s definitely not a personality ethic.

I know that when I was hired in March, I went through several interview stages, including a cultural fit interview. Dave wrote a great post about this just as I was starting at melt.

So… you realize we’ve had this great conversation about culture and never actually defined it?

Shh!

About Anthony Garone

Anthony is the technology director at meltmedia. He likes to write and record music (see garone.org), blog (see TheCreativeTechnologist.com), and garden with his patient wife and 3 children.

About Andy Frey

Andy grew up in Michigan and is now married to an amazing and patient woman (see mad scientist stuff chronicled at StuffAndyMakes.com). Andy has logged over 2,400 skydives. He tinkers with electronics in his spare time and has built a number of semi-useful gadgets (see his website). Thankfully, motorizing one's office chair is not frowned upon at melt.

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.

Native Mobile Apps

A native mobile app is built specifically for a particular mobile platform using that platform’s native programming language and tools. The app works directly with the operating system and device hardware (see diagram above). Since native apps have a direct line to the operating system and hardware, they are arguably the fastest type of app. I say, “arguably” because the increasing power of mobile hardware and the maturity of the tools is making it difficult to distinguish native apps from the next two types in terms of user experience and performance.

Benefits of native mobile apps include:

• Native apps have a direct line to the operating system and the hardware: This affords them top speed, smooth graphics and computing power as raw as it gets. This also gives a native app easy connections to gyros, cameras, the compass, accelerometers, etc. Hybrid apps have similar access, as you’ll see.
• App debugging tools are a standard feature in the development tools for native apps and those tools are robust and tightly integrated into the development process.
• Standard user interface components (buttons, checkboxes, lists, etc.) are built into UI design tools: Users familiar with a platform will feel comfortable with the interface because standard components found in other native apps are readily available and easy for developers to implement.
• Deployment to users is handled through app stores: There is inherent trust in apps funneled through a moderated retail environment.
• Developer support is thorough and reliable through dedicated vendors like Apple, Google, Microsoft and RIM.

Caveats of native mobile apps include:

• Developer(s) must know the tools/language of the platform or platforms (iOS = Objective-C, Android = Java, Windows = .NET) in order to build apps on a particular platform.
• Code is written for each platform and is not interchangeable or portable.
• Design and development timelines are multiplied by the number of target platforms.
• Designer and developer resources may also be multiplied by the number of platforms.

Miscellaneous considerations about native mobile apps:

• Updates to software are performed through the app stores/markets.
• Both native and the hybrid methods provide access to tighter ad integration with iAd from Apple on iOS devices, for instance. This is a more versatile ad experience because of access to device features and easier integration from a developer’s point of view.

Timeline for native mobile apps:

• iOS: 250 hours (design: 62.5, development 112.5, QA: 75)
• Android: 250 hours (design: 62.5, development 112.5, QA: 75)
• Windows: 250 hours (design: 62.5, development 112.5, QA: 75)
• Total: 750 hours

You will not be able to simply port all of your iOS code to your Android code base. Code will be written for each platform. If you have the resources, development can be executed concurrently and we’ve certainly done that. Regardless, the required man-hours will be multiplied by the number of platforms.

Hybrid Mobile Apps

A hybrid mobile app is similar to a native app, however the core of the app is built using standard web technologies, like the web-based app above (HTML, CSS and JavaScript). That web app core is then stored and run from within a “wrapper” native app. The completed app is built using the same tools as a native app.

Benefits of hybrid mobile apps include:

• This method is considered by many to be the more cost-effective solution vs. native because of shortened timelines and reusable code bases.
• Design resources are used just once, as UI can be reused across platforms, if needed.
• Development resources are also used once (plus a bit more for fine tuning across platforms, but not to the extent of native development resources).
• HTML5 and related technologies are universal (including on Saturn, I’m told) standards not owned or controlled by a single vendor.

Caveats of hybrid mobile apps include:

• Sometimes, the UX is not as smooth as native because of web technologies overhead.
• Consider UX and platform idiosyncrasies in budgeting time: iOS has a single “home” button; Android has a hardware “back” button.
• Access to device frameworks is more limited than native without special platform-specific code development.
• Debugging is still problematic for web-based development and that impacts debugging in your hybrid apps.

Miscellaneous considerations about hybrid mobile apps:

Hybrid apps are becoming increasingly useful in more diverse roles. Access to hardware features is approaching the level of native apps. News of large players in the mobile space (LinkedIn, Facebook) dumping hybrid development for native are high-profile and well documented. Most of the complaints about hybrid apps revolve around user experience (“UX”) and developer tools: Users complain that the UX is not as smooth as the native UX and developers complain that it’s difficult to debug and analyze hybrid apps. We continue to take the “let’s evaluate the project requirements and decide per-project” approach.

On the topic of UX, we recommend that you do not try to mimic the native UI. The sometimes quirky UI behavior of hybrid and web apps makes users think your app is flaky. Build a UI that’s operates as smoothly and consistently as possible so that your users are pleased with the experience.

Timeline for hybrid mobile apps:

• Design: 62.5 hours
• General HTML/CSS/JS development: 112.5 hours
• iOS-specific development: 50 hours
• Android-specific development: 50 hours
• Windows-specific development: 50 hours
• iOS-specific QA: 75 hours
• Android-specific QA: 75 hours
• Windows-specific QA: 75 hours
• Total: 550 hours

The hybrid method will require fewer hours than the native method, but because the web technology on the various devices is different, like in the web-only method, some tweaking may be required to get the app to perform and look exactly the same on every device.

Web-based Mobile Apps

A web-based mobile app is a mobile-optimized web site or page that runs in a browser on your mobile device. It is written using standard web technologies, like HTML5, CSS and JavaScript.

Benefits of web-based mobile apps include:

• Design and development resources are the same as your standard web development team.
• Timelines are not much different from that of a normal web application.
• Again, HTML5 and related technologies are universal; standards not owned or controlled by a single vendor.
• YOU (as opposed to the App Store/Marketplace) control distribution and in-app payments with a web-based mobile app.

Caveats of web-based mobile apps include:

• Web-based apps have limited access to device hardware because they run inside the mobile browser app.
• By nature, web-based apps require an Internet connection, but can be made to run offline with a couple minor tricks in modern browsers.
• Trust for the security and origin of your app may be harder to earn if it isn’t being installed from a monitored app marketplace.
• As mentioned in the hybrid app section, debugging is not at the level of ease or robustness of the native app development tools.

Timeline for web-based mobile apps:

• Design: 62.5 hours
• Development: 112.5 hours
• QA: 75 hours
• Total: 250 hours

Other Considerations About Your Mobile App Project

Is one platform a better bet than another? How many do I support? Maybe some marketshare information will help with those questions. Let me cut-n-paste a little perspective on market share in the form of two charts:

Apple ranked as the top smartphone manufacturer (37.8% market share), followed by Samsung and then HTC. Blackberry, Microsoft and Symbian (ordered here by market share) all had market share percentages in the single digits, well out-of-range of the top two platforms.

Takeaways for the two charts above:

• Google Android #1 mobile platform with 52.3% market share
• Apple #1 smartphone manufacturer with 37.8% market share
• comScore Report – March 2013 - comScore Reports January 2013 U.S. Smartphone Subscriber Market Share

Two things I would add to this (file under, “For What It’s Worth”):

• The Android device marketplace is fragmented and the variations of devices and screen sizes are prolific compared to Apple’s marketplace where only a handful of variations exist.
• Apple users statistically spend more money. The travel site Orbitz found that Mac users spend up to 30% more a night on hotels. A Forbes study showed iOS users are more likely than Android users to spend money on apps.
• Apple and Google app stores have over 770,000 apps each, but two-thirds of them have not been downloaded. (Überflip)

Other marketshare factors would include the demographics of the user base. In searching around the web for answers, I found that the use of mobile devices, like most connected technologies, is gender-neutral. This might explain why statistics are generally broken out by age groups. The bottom line is to understand your audience, of course. Knowing your target audience and their tendencies is part of a successful plan for launch. Well, it helps to provide app users with a simple or elegant solution for which there really is a problem.

Another interesting bit of data to consider… The compound annual growth rate (CAGR) of the world population projected from 2012 through 2017 is 1.1% (AtKearney – The Mobile Economy 2013 [PDF]). The CAGR of mobile subscribers for that same range is 4.2%. The growth rate of mobile subscribers is outpacing the growth rate of the earth’s population by a considerable amount. Today, in 2013, there are 3.2 billion subscribers. That includes people like me, “multi-subscribers,” who have more than one device with a mobile account. The AtKearney report states that by 2017 there will be 3.9 billion mobile subscribers. This equates to 80% of the world’s adult population. Nearly 50% of the global total is from the Asia Pacific region. Take a thorough look at that link above to get a solid understanding of the future of mobile. It’s quite impressive.

Closing Thoughts

What direction should I choose for my app? “It depends.” That’s the proper answer you should expect from your mobile app development vendor(s) until the full scope of the project is understood. By “full scope,” I mean budget, timetables, business requirements, features and UX (to name the big items).

Here is a quick rundown for each of the methods discussed above:

Native Mobile App: Uses native programming environments and languages, smooth and consistent native UI, higher cost, more time/effort, native UI components, good for raw computing power, must develop an app for each platform, native store/market distribution, consistent in-app purchasing experience, debugging robust.

Hybrid Mobile App: UI generally smooth but not always at native level, shorter timeline for development than native, can develop one UI but will still need to tune on each platform prior to build, HTML/CSS/JavaScript core runs in a webview, wrapped in native app, can take advantage of nearly all hardware features of device, debugging more difficult.

Web-Based Mobile App: Entire app built with web technologies (HTML/CSS/JavaScript), must be online to access in most cases, easy updates to app (because it’s housed in one place), less access to hardware than hybrid and native, debugging more difficult.

About Andy Frey

Andy grew up in Michigan and is now married to an amazing and patient woman (see mad scientist stuff chronicled at StuffAndyMakes.com). Andy has logged over 2,400 skydives. He tinkers with electronics in his spare time and has built a number of semi-useful gadgets (see his website). Thankfully, motorizing one's office chair is not frowned upon at melt.

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!

So what’s new?

1. All the icons have been cleaned up and redrawn.
2. We’ve doubled the number from 20 to 40.
3. Each icon now has a circle-less variant, which technically brings number of icons up to 80 (but who’s counting?).
4. And in what is probably the coolest addition, we’ve made them into an icon font with ligatures.

Pretty exciting huh? Wait, what’s that?

A ligature is created whenever two or more letters are represented by a single glyph. The most common use for a ligature is to make fonts more readable. Like the examples below.

They can also be used to simply make a font more interesting to look at or to create a handwritten appearance by using so many ligatures that characters are rarely rendered in the same way (e.g. Liza Pro by Underware — seen below). The latest (and possibly coolest) use for ligatures is icon fonts.

Why use ligatures for icons?

Icon fonts have been around for a while. They are great for rendering vector icons in a single color on the web, but most icon fonts have one big drawback. They aren’t very accessible. If your user’s browser doesn’t support web fonts (or her connection is too slow to render them), she will be left with a single character instead of the intended icon. The same problem will occur for users accessing your site with screen readers. Where you wanted them to see a twitter icon, now they only get the letter ‘t’. But not so if your icon font is using ligatures. Using ligatures, your twitter icon can be rendered as a ligature of ‘twitter’. So your screen reading user and your user on IE 8 will now get your message “Follow me on twitter” instead of “Follow me on t”. Much better, right?

Technical deets

Implementing a web font with ligatures works just like implementing any other web font. Ligatures in web fonts are supported in all major browsers (IE 10, Chrome & Firefox, iOS), but some common browsers don’t support it (IE 9 & below, Android). If you need support for these, a CSS sprite fallback is never a bad idea. Without a fallback, the browsers that don’t support ligatures should just display the word itself instead of the icon. It just takes a few extra lines of CSS to enable ligatures in the browsers that support it:

Time to put it in action

As always our set of melticons are free of cost and of any rights management. Feel free to use them as you’d like without worry. If you’d like to give us some credit, that’d be great, but we won’t be hurt if you don’t.

The download includes the ligature set and an EPS file containing all icons. If there are any specific icons you’d like to see in a future release leave a comment or drop us a line.

Download the melticons web font kit here (or you can get it sans circle here). You can also download the EPS.

And for good measure, here’s a preview of the icons:

About Jimmy King

Jimmy King is a front-end developer. He is an avid motorcyclist, runner & dishwasher. When he's not building awesome internet things, he likes to spend most of his time with his wife & son.

About Guillermo Garcia-Mont

Guillermo is a user experience designer. He enjoys illustrating, designing interfaces for any device with a screen, reading up on emerging technologies, and the occasional comic book.

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?

Enter LESS

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.

To take full advantage of this, I wrote color operations for the nine most common color schemes. Most of them rely on the spin operation which takes two parameters, the base color and the number of degrees you’d like to “spin” it around the color wheel. For example:

This scheme is storing the base color and its complement (the color on the opposite side of the color wheel). In this case, #cc8f28.

Why should I use it?

Using LESS color operations to generate your color schemes has two primary benefits. It’s easy to create schemes based on color theory and some simple math, and far easier to maintain. (i.e. If you decide to change the base color for your scheme, you only have to change one variable instead of digging through all of your colors and updating them individually.) And if you’re like me and always want to know “why”, now the logic behind your color schemes will be preserved as long as your LESS files are.

Time to try it

You can see the demo of all nine color schemes and the LESS color operations that create them here. Go ahead and use the code in your own projects, it’s licensed under the MIT license. If you’re not a developer, check out the demo anyway and feel free to use it to generate your color schemes. If you think I’m missing a common/important color scheme (or there’s one you just really want to see and think others will too), submit an issue or open a pull request on the github repo.

About Jimmy King

Jimmy King is a front-end developer. He is an avid motorcyclist, runner & dishwasher. When he's not building awesome internet things, he likes to spend most of his time with his wife & son.

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

A native mobile app is built specifically for a particular mobile platform using that platform’s native programming language and tools. The app works directly with the operating system and device hardware (see diagram above). Since native apps have a direct line to the operating system and hardware, they are arguably the fastest type of app. I say, “arguably” because the increasing power of mobile hardware and the maturity of the tools is making it difficult to distinguish native apps from the next two types in terms of user experience and performance.

Certain types of apps that require heavy processing power are definitely best suited for native. Examples include 3D games or apps that add live functionality to a camera (augmented reality, realtime image manipulation). Apps that require in-app purchasing are another good case for a native app.

Apple’s iPhone and iPad run the “iOS” operating system. Apps for iOS are written in a language called Objective-C. Apple is the only source for iOS hardware.

Android apps are typically written in Java and run on a version of the open source Linux operating system. Android hardware is provided by a number of well-known manufacturers, like Samsung, HTC and Sony.

Windows Phone apps are written in C#, C++ or Visual BASIC and run on a mobile version of (you guessed it): Windows. Hardware is available from Nokia, Samsung, HTC, etc.

Examples of native apps: Angry Birds, big social names like LinkedIn and Facebook.

Mobile Web Apps

A web-based mobile app is a mobile-optimized web site or page that run in a browser on your mobile device. It is written using standard web technologies, like HTML5, CSS and JavaScript.

A good example of an elegant interface we like is forecast.io (http://forcast.io/). It has a simple and clean UI and feels like a native app, but it is installed from the web, not an app store. Another good example of a pure web app is the Financial Times website (http://www.ft.com/).

Listio (http://www.listio.com/) has an extensive list of true web apps.

“Hybrid” Mobile Apps

A hybrid mobile app is similar to a native app, however the core of the app is built using standard web technologies, like the web-based app above (HTML, CSS and JavaScript). That web app core is then stored and run from within a “wrapper” native app. The completed app is built using the same tools as a native app.

Examples of hybrid mobile apps: Netflix, Bank of America’s mobile banking app, Discover’s and Yelp.

In the next article, we’ll cover more specifics of why you would choose one method over the other and what the typical development cycle and associated costs and timelines might look like. Click here for the next part…

About Andy Frey

Andy grew up in Michigan and is now married to an amazing and patient woman (see mad scientist stuff chronicled at StuffAndyMakes.com). Andy has logged over 2,400 skydives. He tinkers with electronics in his spare time and has built a number of semi-useful gadgets (see his website). Thankfully, motorizing one's office chair is not frowned upon at melt.

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.

Workflow

You might be familiar with a Waterfall-style workflow, as illustrated below. The timeline is broken up into phases where each phase consists of a single discipline and the project gets handed from one group to the next.

While this process works for many a project, it is not the ideal workflow for a responsive approach. Each project will have different needs, but an example responsive workflow can be seen illustrated below. The lines between planning, design, development, and testing will be blurred. These “phases” will happen in varying order and usually simultaneously.

Roles

With the blurring of “phases” of a project, so too blur the lines between roles. Designers will be more involved with development. Developers will be more invested in content strategy. Project managers will be concerned with performance. Your role as client will also change. You will likely be asked to be more involved through the entire project and to give feedback on in-progress work during stages you’ve previously never seen. An awesome result of this role blurring is how it keeps the entire team involved and invested in the final product.

Deliverables

A responsive approach will not benefit from pixel-perfect Photoshop comps and producing these deliverables is often seen as time wasted. Especially counter-productive are “approval handcuffs” where site elements cannot be changed once this approval is received. Expect and allow for change as the project matures.

As the client, be open to receiving different types of work from your team. For example, a minimally-styled, clickable prototype in the browser will help you understand how your users will interact with the website better than with a static image. Getting a design into code sooner helps the team find problems earlier and make decisions faster.

And remember how we keep talking about all the different devices out there? Keep in mind that your website is now fluid. No longer can we or should we expect a website to look the same way in every browser and on every device. Embrace the variance. We aren’t aiming for identical experiences. We want to give the best experience for each user’s circumstances.

Content

I’m sure you’ve heard the phrase “Content is King.” Well it’s true and responsive design puts content front and center. Be prepared for your team to question your content. You’ll be asked to examine and prioritize and likely to reduce the amount of content. Ever have a project make it through design and development before content is ready? This leads your team to design, essentially, a pretty box to dump stuff. With responsive, your content will guide the design decisions and not the other way around.

Maintenance

Maintaining a responsive site does require additional planning and testing. However, you will only have to update one set of content as opposed to two or more in a desktop/mobile site combination. And just as the initial responsive redesign took more time and budget, so too will subsequent design updates.

So what’s the payoff?

If I made responsive design sound like a lot of work it’s only because it is. And the more prepared you are as a client the smoother your project will hopefully go.

Along with impressing your friends with how your site scales with the browser, here are a handful of the benefits you’ll now enjoy:

- Your brand now has the farthest possible reach to your widest possible audience. Users on a large assortment of devices will be able to access your site.

- Your site is now more usable under more circumstances. You’ve taken into account your users on low connection speeds and they won’t miss out on your content.

- You’ve provided a consistent experience for your users. Transitioning from a smart phone to the desktop will feel natural to a user because it’s still the same site.

- You’ve presented streamlined, prioritized content that is easy to read even on a small screen.

- You’ve had fun and learned new things from your team and this new process.

Here at meltmedia, we’ve faced a lot of challenges and had great success with responsive design. We’re still learning every day and finding new ways to make the process better. Got a question or a story to share about your responsive design experiences? Leave a comment or send us a note through our Contact page.

About Lynn Fisher

Lynn is a designer and developer for the web. She loves making websites, drinking diet soda, and talking about Battlestar Galactica. She's also been known to dabble with paint. See her work at lynnandtonic.com.

Culture is something every business has. Good or bad, fun, inventive, laid-back, entrepreneurial, stoic, it can be anything. Culture comes from the people involved in the business. Many small businesses begin their lives as a tiny, like-minded group with the same goals and ideas. Quite often as a business grows, these views and beliefs are not as easily scaled. In general, the larger the business, the less defined the culture.

I’m not implying a large company can’t maintain a culture. It’s just a lot harder. And it is something that once was just part of the understood way, but now must become instilled in an expanding group.

Apple has created a culture of exceptional quality. Zappos has created a culture based on staggering customer service. Netflix has taken a business model that shifted from mailed DVD’s to streaming movies yet maintained a culture of service and innovation. All these companies and countless more use their culture to reinforce their brand and provide a sense of unity and strength for their employees, and at the same time, for their customers.

This leads me to the point of this post. How can you be sure your job applicants match your culture? Well, you can never be sure. In the past our job postings looked very similar to everyone else’s in our industry: a short intro telling a bit about what it is we do, a bit about our culture (a very brief bit), and then onto the job description. This wasn’t bad. It was the standard, the norm. But we realized something was slightly amiss. During the interview process, there was much consternation about “fit”. This was about culture. “This is a person I will work with every day, do they fit? Do they want to embody what we believe?”

Andyfying it

This leads me to Andy Frey. Andy is our Chief Technical Strategist (a fancy way of saying he makes sure our sales and marketing teams know what to tell clients about technology). Luckily for us, underneath Andy’s technology background is a rapier-sharp wit and left-field sense of humor. Essentially a very big part of our culture.

I wish I could remember when it began. We were posting for a position and somehow Andy got hold of it. In a very short time he had taken the “standard” job posting and Andyfied it. It was chock full of oddity, references from movies, pop culture, business jokes, chicken jokes, anything, everything. It was brilliant. To us at least.

I had a friend ask why we would post “nonprofessional” job postings. It occurred to me, if our culture was “professional, reserved, predictable” this approach would be a bad idea, but what we were doing was more akin to meeting someone in a bar. We were giving them a sense of our personality, our culture. If they don’t like a free-spirited workplace, an oblique viewpoint, a place for contrary ideas, they probably won’t fit well at meltmedia, and the posting conveys that idea.

The more it continued, the more it made sense. It was the perfect introduction to our culture for potential employees. We never said, “hey, here’s our culture” by way of a vision statement or heavy-handed approach. We just infused ourselves into the first communication with potential meltmedians.

We recently received some emails validating our feelings about this approach. They were submitted to the comments form on our website:

My comments if any are: To Congratulate you on the most interesting and impressive job posting I have ever read. I wished I had the digital skills to apply for this job, I feel that working for this company would be an amazing and once in a life time experience!! Good Luck in your search!

My comments if any are: To give praise to the person in charge of making your job postings very, very entertaining. I’ve never seen anything like it. Out of curiosity, does the writer “chemically treat” himself/herself to come up with that stuff? It’s genius.

It’s not just these email anecdotes that validate this demonstration of our culture to candidates. Multiple recent hires have told us, after they’ve come on board, that the job description is what drew them to meltmedia. The fact that we eventually came to the same conclusion about this approach brings it full circle.

This method probably wouldn’t work for everyone, but truthfully… what does?

And to check out the postings for yourself, visit our Careers page.

About Dave Woodruff

Dave is one of the founding partners of meltmedia and currently serves as our Chief Creative Officer. He has an affinity towards good wine and fish and chips. He can usually be seen yelling, "Who's going to Four Peaks with us?!" throughout the office every friday at noon.

We love responsive design here at meltmedia and could talk about it in detail for a long foreseeable future. But we want to back up and talk about what makes responsive design really exciting: how it changes our perspective of the web.

So what is it exactly?

Responsive web design is a term coined by Ethan Marcotte back in 2010. At its most basic, a responsive website “responds” to the available screen size to present its content in the most optimal way. Using responsive design, the same website can be readable and usable not only on a desktop computer, but on the many mobile devices the market has to offer.

Why responsive?

The web is more accessible than ever. People can connect to the web on a desktop computer, a smartphone, even the screen on their refrigerator. The number of connected devices increases each day and the specifications for those devices vary dramatically.

Responsive isn’t just about adjusting the way your site looks. At its core lies the concept of One Web which encourages us to provide users the same information and services regardless of the devices they’re using. Of course supporting every device in every circumstance would be an unrealistic expectation. The goal is to connect as many users to your content as reasonably possible and to give them the best experience you can.

What about the mobile web?

There is no mobile web. This isn’t a Matrix “there is no spoon” type statement. But the web is the web, no matter the device you use to access it. While a user may be on a “mobile” device, he or she may not be mobile at all. I spend time on the weekend lounging on the couch and browsing the web on my iPhone when my computer is just a few feet away. Just because I’m using a phone, I shouldn’t have an inferior experience.

And that brings us to some common mobile myths.

You may have found yourself saying, “Our content isn’t meant to be viewed on a phone.” Or maybe, “Only an insignificant fraction of our users are on mobile devices.” While both of those statements may have some validity, considering the mobile experience can only benefit your brand. As we’ve said and will tirelessly stress: more and more connected devices are hitting the market every day and more and more people are using these devices while looking for your content. Don’t leave them behind.

Another myth to avoid falling victim to? Mobile users are always “on the go” and should only be served a small portion of the content you’d normally provide. Because the usage of connected devices is increasing, so is the difficulty of predicting what content people are looking for in what circumstance. What we can do is use this mindset to analyze our content and prioritize it. If I don’t think “mobile” users would want this information, is it really important to include at all? Present your content clearly and make it easy to find. Then let your users choose what to consume.

So it’s all about responsive?

We want to be clear that responsive design is an approach, not a product. The end goal is a website that gives the user a great experience regardless of device. Responsive is one way to get there. There are plenty of other techniques to move toward this goal, including making your site lightweight and extremely quick to load.

And for even more clarity, these are a few things responsive design is not:

Not a separate mobile site
A responsive site is one site with the same structure and content no matter the device. Mobile sites or “mdot” sites usually use different, simplified structure and content targeted for certain devices.

Not an iPhone or Android app
Native applications utilize functionality of the device being used, like push notifications. A responsive site is limited to the capabilities of the browser.

Not only the designer or developer’s responsibility
A responsive approach requires an entire team’s involvement, especially yours as the client. Content creation, prioritization, and project planning can take more thought and time than what you might be used to.

Not always the best approach
While responsive design is awesome, it may or may not be the right approach for you. Every project should be taken case by case.

So how do I know if responsive is right for me?

Every project’s needs are different and it’s wise to consider them before committing to an approach. Here are a few things to be mindful of:

Timeline and Budget
A responsive approach will take longer and cost more than a traditional redesign. It is also ideal to start with a blank canvas. If a full redesign isn’t possible, look into incremental ways to improve performance and to reach more users.

Maintenance
A responsive approach can reduce maintenance costs, when compared to a desktop site and a mobile-only site combination. Maintaining one set of content as opposed to two can save time and money. However, development updates to a responsive site can be more involved and thus, more costly.

Business goals
A project is really successful when it supports and fulfills your business goals. If your experience relies on accessing the device’s hardware, maybe an app is a better direction. Discuss with your team how the approach can help achieve your goals.

Still reading?

If all of this gets your blood pumping, read the next post in this series exploring what to expect during and after a responsive project.

About Lynn Fisher

Lynn is a designer and developer for the web. She loves making websites, drinking diet soda, and talking about Battlestar Galactica. She's also been known to dabble with paint. See her work at lynnandtonic.com.

“Analytics is confined to the past. Any number of companies can crunch historical data and provide insight into past trends, but today we can listen to the active conversation happening in real-time across the blogosphere and respond to what is happening now. We call this active social listening and this has the ability to provide that ‘look into the crystal ball’ to help predict consumer needs and tomorrow’s trend.” ~ Jon LeMire, SVP Business Development – Collective Bias

Existing real-time marketing tactics, such as digital/mobile coupons, will always have their place in the marketing mix. But using analytics to solve real business problems is the new holy grail for shopper marketing. And using listening analytics to sync perpetual inventory with the ability to respond to the current, unique needs of a community is a powerful new component of real-time marketing. Specifically, being able to quickly reconfigure shelf space (in-store and online) to react to demands from specific local demographics is empowering retailers with a better offering and higher sales.

Example

The local hardware store dutifully breaks out their inventory of snow shovels when the weather forecast calls for a foot of the white stuff. But when a community of moms begin posting on Facebook that they are all “home with sick kids”, the real-time opportunity is how quickly local retailers can respond to this need with Cold-n-Flu medicine, comfort food remedies and time savers, conveniently placed and grouped in-store.

Listening analytics creates triggers when combined with historic data (which on its own can be both promising and deceiving). The alignment of both provides incredible insight as listening tells us when a shopper marketing trend is about to occur and historical data shows us how to scale and prepare for it.

This Is About Learning What to Listen For

Much like an evolved SEO strategy, there’s a difference between just leaning on keyword content, versus listening to the language people actually use when sharing via social media. Assuming your organization has a highly segmented CRM strategy, the next-level challenge is tracking specific and/or known buying behaviors against unplanned events. Then you can measure how effectively your processes are able to respond in real-time.

For more information on how analytics can be used to solve for the need to respond locally, consult with industry experts and start building your real-time marketing solution.

About Nathan Wagner

Nathan is a Business Development Strategist and supports client initiatives with over 17 years of experience in Web & Mobile Technology, Software & Application Development, Marketing Campaigns and 360º Enterprise Solutions.

Over the past twelve years, we at meltmedia have dedicated our lives to becoming Interactive Superheroes. In 2012, we emphasized also being superheroes in our community. Phoenix is full of amazing and impactful non-profit organizations that are helping our community in ways we never could. So we decided to help out in the way we know best: creating meaningful web experiences.

From this idea, our Superheroes in the Community program was formed to donate website design and development to local non-profits that need it. How would we choose whom to work with? We decided to keep it simple by picking organizations whose missions we support and projects we could really impact.

Selecting the non-profit for our first project was a no-brainer. New Pathways for Youth (formerly known as Phoenix Youth at Risk) is an organization whose influence I’ve observed firsthand. NPFY pairs adult mentors with youth mentees and transforms lives. These kids are in tough and often dangerous life situations, but mentorship empowers them to fulfill their potential and to make new futures for themselves. And the mentors lives are also changed; it’s truly a powerful program.

Our project with New Pathways for Youth nicely aligned with their name change and rebranding. We worked closely with their team to deliver a website redesign that could support their mission and encourage volunteers and donations. Visit www.npfy.org to see the full site and to learn more about this amazing organization.

This first project was rewarding for us on so many levels. We’re energized and excited to begin our next Superheroes in the Community project. Keep your eyes open; there is more to come!

About Lynn Fisher

Lynn is a designer and developer for the web. She loves making websites, drinking diet soda, and talking about Battlestar Galactica. She's also been known to dabble with paint. See her work at lynnandtonic.com.