If you are a senior planning to apply to a graduate program next year or a current graduate student early in your program of study, you should consider applying for a National Science Foundation Graduate Research Fellowship.

NSF has opened the application for the 2014 Graduate Research Fellowship Program. These Fellowships give three years of funding to students in research based science, technology, engineering, and mathematics master’s and doctoral programs.

Funds are awarded to the student and can be used in any appropriate program. If you will be applying to graduate programs for next year, you only need describe the insititutions that you plan to apply to.

NSF's Computer & Information Science & Engineering Directorate is looking for strong applicants in this year’s program. The deadline for submission is November 4, 2013 and the application can be found here.  If you are interested, you should start by talking with your advisor and or other faculty members about the program and how to submit a strong application.

There are loads of job titles in our industry. The opinion on their usefulness range from harmful (i.e. leads to “not my job” syndrome) to vital (i.e. people change companies sometimes and need common language). Since they are out there and we use them, there should be some consistency to their definition. Perhaps we can get closer to nailing that down.

Let's light this fire, shall we? This is all debatable, of course.

Job Titles

These are legit in my opinion.

Web Designer

If "designer" is in the title, the job is designing. Literally deciding and implementing how websites look and work. "Web" is in the title because the job is specifically focused on the web. Specific skills would be design-tools-of-choice, HTML, CSS, and light JavaScript.

If the job is also designing for print, apps, signage, products, clothing, etc., the title would be widened to Designer.

Front End Developer

This job is focused on HTML, CSS, JavaScript, and light backend work. Not design. The lack of "designer" in the title is intentional. Because the job doesn't require design, deeper skill in the other technologies is implied. You likely have a grasp on some concepts beyond the core technologies, for instance regression testing or performance.

A synonym might be Front End Engineer. I tend to think of that as a requiring a deeper and more specific skillset, possibly with more narrow focus or at a higher level.

Technology specific job titles may be also be appropriate here, like "JavaScript Developer" or "JavaScript Engineer" for a job where that is primarily what needs to be done. Although, none of the front end technologies live in a bubble so I generally prefer Front End Developer.

UI Designer

This job is more about designing and less about implementation. Really good at design-tools-of-choice with perhaps only light HTML and CSS skill. A synonym might be a Visual Designer.

UX Designer

A specific focus on studying and researching how people use a site. Then ushering changes for the better through the system and testing the results. May not have or need any design or implementation skill. All jobs should care about user experience, but this job lives it.

Interaction Designer

Primarily design, just like a UI Designer, but with specific focus on how things are used and movement.

Art Director

The job is quality control, leadership of other designers, and client communication. A synonym could be Design Director.

Web Developer

This job is focused on back end work and working with languages specific to the web, like PHP, ASP, Ruby, Python, etc. Medium skill in database/server work, medium skill in JavaScript, light skill in HTML. This is very different from a Front End Developer as there is little working with the design and heavier on programming concepts and concerns, like security and structure.

Synonyms could be Web Programmer or Web Application Developer.

Full Stack Developer

This job is a combination of front and back end work. Seriously though, not mostly one and a little of the other. Good crossover people are needed at organizations and this is a high end job.

Content Strategist

Rather than working directly on implementation, this job is about the structural design of websites. Things like the taxonomies, metadata, scheduling, and analysis of content. A synonym might be Information Architect. They might work with people who work with content in a more general way like a Writer, Copywriter, or Editor.

IT Technician

This job works with the actual computers and tech equipment. A hardware person.

Dev Ops

The job bridges the gap between IT and Developers. They handle things like server software, version control, deployment, build processes, and testing servers/processes. I wish this had a more job-title-y feeling to it. As it stands it sounds like what you would call the whole team of people with this job.

Product Manager

This job is about guiding the site as a whole (or a major feature of the site) toward a better future. Largely dealing with people and planning. A Project Manager would be similar but smaller in scope and possibly a temporary role rather than full job title.

Customer Service Representative

This job is about communicating directly with users of the site to provide help. Then triaging bugs/problems to the internal team. Also understanding/communicating the voice and vibe of the community around the site.

SEO Specialist

This is a big enough sub industry that it can be its own job.

Job Title Prefixes

Any of these job titles can be prefixed with Junior or Senior. Junior meaning less skill/experience. Senior or Lead meaning more skill/experience. Responsibility and pay commensurate. The tech is the same.

Consultant might be suffix to any of these job titles as well, like a Front End Development Consultant, in which you offer strategic advice and help.

Bad Job Titles

The following are not job titles.

• Ninja _______ - Cutesy and meaningless. It's a recruiter trying to say "we want someone really good" but then shooting themselves in the foot.
• Rockstar _______ - Same.
• Web Master / Webmaster - It feels outdated and cheesy, but more importantly, never developed any specific meaning.
• _______ Hacker - Cheesy for anything with the possible exception of a job with the specific responsibility of finding security exploits.
• I kind of like Web Worker as a term, but not as a job title (too vague).
• Mobile _______ - Even if the job has that focus it feels overly specific.

Not Caring About Titles

Like I said in the intro, the opinion on job titles is hugely variant. Right in the middle is not caring at all. If that's you, awesome! That probably means you work for yourself or for some little startup where your title can be like "Lead Hucklebucker" or some other nonsense. That's just good fun, live it up!

Not Web

Careful with these if the job is actually web related.

• Graphic Designer - This has come to mean "design, but not web design."
• Software Engineer / Programmer - This has come to mean "programming, but not for the web."

Conversation

Did I miss any important ones? Surely there is very specific job titles that are legit. That's fine because they are specific. It's the big general ones that we need to be concerned about. Did I get any wrong? Have you ever changed jobs and found it problematic? How does your organization handle it?

Job Titles in the Web Industry is a post from CSS-Tricks

W3C published today a summary of the Workshop on Rich Multimodal Application Development, hosted by Openstream on 22-23 July in the New York Metropolitan Area.

One of the Workshop aims was to accentuate the merits of HTML5 and the W3C Multimodal Architecture to help create the appropriate level of awareness of the maturity of the MMI Architecture and its suitability for developing innovative and compelling user-experiences across applications/devices.

Workshop participants prioritized work on use cases and requirements for rich multimodal applications, including service/device discovery, HTML5 integration, extending EMMA for output, specific industry snapshot, streaming, timing handling and related standards.

As discussed during the workshop, the W3C Multimodal Interaction Working Group will hold Webinars like the one held in January to discuss the issues identified during the workshop with all the stakeholders. Learn more about the Multimodal Interaction Activity.

Google isn’t completely transparent with how web pages are ranked on their search engine results pages, but Google employee Matt Cutts has in the past confirmed that site speed does have a bearing on search engine ranking. Why? "Faster sites create happy users," Cutts said.

A recent study by Moz (producers of SEO software) carried out by data scientist Matt Peters along with Zoompf (a website performance platform) took an in-depth look at the correlation between site speed and Google search engine rankings.

The findings confirmed that website speed does matter when it comes to search engine rankings, but it’s Time To First Byte (TTFB) that makes the difference rather than page load times.

When building commercial websites, we have to find a happy balance between usability and ensuring the site performs well on search engine rankings: User-friendly SEO.

SEO and usability, side by side, are both important. And, when done correctly and with the best intentions, SEO and usability will not be at odds, and they will actually reinforce one another.

If the conclusion of Peters’ study is true — that TTFB is the measurement used for determining how fast a website is, and thus, how a web page should be ranked in search engine results — this could change the way we go about building fast websites for SEO.

Why the Time To First Byte Study Was Done

To begin the research, Peters worked with the Moz team to create a list of 2,000 random search queries from the Searchmetrics 2013 Ranking Factors Study. They then chose a representative sample of queries with varying amounts of terms (1-5 search terms) and then they took the top 50 ranked results. This enabled the researchers to assemble a list of 100,000 pages to be used in the study.

They then launched 30 Amazon EC2 instances running in the Northern Virginia cloud. These were all loaded with a private version of WebPageTest, a popular website performance and optimization testing tool, to collect more than 40 test measurements.

Google Chrome was used as the test browser and each page was tested with an empty cache.

You can download the raw data from Moz.

The study took two measurements that are commonly associated with site speed. These are:

1. Document Complete: the time it takes for a web page to load static content
2. Fully Rendered: The time it takes for a web page to completely render, which means even dynamically-generated content (such as your third-party Twitter widget, Google AdWords widgets, JavaScripts, etc.) has been fully loaded and rendered

The researchers expected both of these metrics to have an influence on search engine rankings.

They were taken completely by surprise when no correlation was found.

That then led them to look at Time To First Byte.

Time To First Byte is measured as the time it takes for a web server to send the first byte to the requestor.

TTFB is traditionally a measurement of how responsive a web server is, not how fast and a web page is.

The study revealed "a clear correlation" between low search engine rankings and high TTFB times.

Why Use Time To First Byte?

According to the study, the most likely explanation for Google using TTFB to measure site speed is due to it being the "quickest and easiest metric for Google to capture."

This is because Google’s robots are capable of taking a full measurement of TTFB, whilst gathering document or rendering speeds would require more resources if it were done on a large scale. It’s highly unlikely that Google (or anyone else) would actually have the resources to carry this out, despite the company’s massive data centers, if you consider for a moment the sheer volume of web pages on the Web.

According to the researchers: "Not only is TTFB easy to calculate, but it is also a reasonable metric to gauge the performance of an entire site."

"TTFB is affected by 3 factors," the researchers said. These 3 factors are:

• Network latency
• How heavily loaded the web server is
• The speed in which a site’s backend can push content to the requestor

These factors could be indicative of how fast a web page is, but not in a conclusive way like page loading times can.

Why TTFB is Not Important to Your Users

A study from CloudFlare states that TTFB is irrelevant to the user’s experience. And there is truth to that.

How fast a web page fully loads is all that matters when we begin to look at what is good for our users.

Some things that negatively affect TTFB are actually good for our users, the CloudFlare study discovered. For example, the CloudFlare study saw that when gzip compression was used, the page itself was downloaded 5x faster, but that this negatively affected TTFB by making the time 8x greater.

"From the end user perspective TTFB is almost useless. In this (real) example it’s actually negatively correlated with the download time: the worse the TTFB the better the download time," John Graham-Cumming, a respected programmer in the industry who works for CloudFlare, said.

Therefore, if you care about SEO and your users, in the scenario above, you’re at a crossroads. Do you optimize page speed for your users or TTFB for your search engine rankings?

When it comes to website performance as it relates to the user experience, frontend design is what matters most, and not so much the backend (web servers) which is what TTFB effectively measures.

Source: Performance Golden Rule

If a web server can push a byte quickly due to factors such as a shorter distance from the request, server resources, web server architecture, using a CDN, and what web server software you use, it doesn’t automatically mean that the web page being requested is designed optimally to ensure that the rest of the page is quick.

Though there is a good chance that TTFB is also an indicator of web page speed, TTFB is not the best metric to measure it, and there are other better options.

The Bottom Line

It’s important to note that these are just studies and assumptions.

We won’t know for sure whether TTFB is the only measurement that Google uses to determine a web page’s speed or not.

But if it is, then it’s an inadequate way of determining whether a user will have fast and responsive experience on a given web page.

Related Content

• What Potential Impact Can HTML5 Have on SEO?
• 10 Excellent SEO Tips That Will Improve Your Web Design
• 10 Usability Tips Based on Research Studies
• Related categories: Web Development and Content Strategy

About the Author

Kerry Butters is a technology writer with a background in web design, tech and publishing. Kerry is passionate about all aspects of her job and heads up markITwrite, a digital content agency. Connect with Kerry on Google+.

The post Search Engine Rankings or Your Users? appeared first on Six Revisions.

Typography is a subject of two extremes: you love it, or you hate it.

Designers who love typography revel in all manner of archaic terminology like kerning, lining figures and ligatures. Designers who hate typography don’t know what any of that means.

It seems inconceivable to many designers that in their midst are colleagues whose approach to typography is to stick with the defaults, but in actuality it’s a common approach. Web designers have frequently relied on default browser settings for the simple reason that the control they had was minimal at best.

As web designers gradually gain access to the kind of control print designers have enjoyed for years, the need to understand the nuances of typography become increasingly urgent; as someone’s uncle once said, with great power comes great responsibility.

Hundreds of resources claim to be able to teach you typography, but few are as authoritative or accessible as Matthew Butterick’s Practical Typography.

A website in a book format, including a foreword by the omnipresent Erik Speikermann, Butterick’s essay is offered as shareware; there are a variety of ways to pay, which range from buying his fonts to passing on word about the site.

Butterick opens his book with 5 basic rules that he expects you to master in under ten minutes, and this enticing claim:

This is a bold claim, but i stand behind it: if you learn and follow these five typography rules, you will be a better typographer than 95% of professional writers and 70% of professional designers. (The rest of this book will raise you to the 99th percentile in both categories.)

What sets Butterick’s book apart from many typographic tomes is that Butterick doesn’t feel the need to justify his rules with 1200 pages referencing the development of the Italian Humanism. Whilst type nerds, myself included, may enjoy such a history I suspect its inherent inaccessibility is why so many web designers never make it beyond Helvetica.

Simple rules are spelled out in plain English: “point size should be 10–12 points in printed documents, 15-25 pixels on the web” and “If you don’t have real small caps, don’t use them at all”. The question of why isn’t addressed, like a parent answering an overly inquisitive child, the implied explanation is just because.

If you’d like to know why you shouldn’t use Times New Roman, how many fonts you should use in a document, or how to improve hierarchical numbering on the web, then read the full site. If on the other hand you’re happy to be a better typographer than just 70% of your colleagues, read the Typography in ten minutes and Summary of key rules sections. Your work will be all the better for it.

Have you read Matthew Butterick’s Practical Typography? Has it improved your craft? Let us know in the comments.

Featured image/thumbnail, typography image via David Navalha.

Modern-Yet-Retro Thirsty Script Font Family – only $9!

If you’ve developed mobile applications or have just started building one, then you probably realize that marketing should be as much of an ongoing concern as the product’s design and development. After all, what’s the point in creating a beautiful, valuable app if no one knows about it?

Assuming that promotion on Google Play or Apple’s App Store will take your app from beta to bestseller is… well, magical thinking. In reality, most successful developers kick off their marketing efforts months before release.

In this post, we’ll focus on how to get a head start with email marketing, not only by wrangling testers and staying in touch with users, but by successfully building hype for your app. Then, we’ll move on to how to announce the launch and measure results. Along the way, we’ll share techniques and code snippets from solid marketing campaigns, spanning different stages of an app’s lifecycle.

While this article isn’t heavy on coding and development, you’ll find an assortment of practical suggestions that you can apply to your projects. But if all you get is a little perspective on how important it is to actively work on getting the word out about your app from the get-go, then still consider this time well spent!

Why Email Marketing?

First, why focus on email and not, say, social media or word of mouth? Simply put, email gives you the most bang for your buck. With a return of $40 for every $1 spent, email marketing stands head and shoulders above other methods, such as keyword advertising ($17 for every $1) or banner advertising ($2). Email also generates superior conversion rates, while giving you full control over your message. And we haven’t even mentioned the big-picture goals, such as using it to keep your most valuable users in the loop — for example, when recruiting testers, announcing launch day or requesting feedback.

But HTML Email Is Hard, Right?

To be fair, creating and sending HTML email has always been a tricky sport. If your background is Web design and development (as it is for many app creators), then you’re likely aware that designing, coding and testing for the inbox is significantly different from doing that for the Web. A skim of Campaign Monitor’s “CSS Support” chart quickly reveals that providing a consistent experience across multiple email clients is truly a minefield.

Yet feel consoled that, if you’re primarily targeting mobile users (for example, by encouraging them to download an app directly to their phones), mobile email clients such as iOS Mail are powered by WebKit. This offers the luxury of a browser-like experience — including solid HTML5 and CSS3 support — in the inbox. Secondly, a number of email service providers, including Campaign Monitor and MailChimp, offer HTML email builders that not only whip up campaigns quickly and painlessly, but produce templates that make the most of mobile email clients, with media query support. In the email marketing business, we call these responsive email templates.

While we’ll touch on some of the code that goes into tailoring a better mobile email experience, we won’t dive too deep into responsive email design. To get up to speed on both the concept and code behind it, I highly recommend reading Smashing Magazine’s “From Monitor to Mobile: Optimizing Email Newsletters With CSS” and Campaign Monitor’s “Responsive Email Design.”

But before all that exciting stuff, let’s start with the fundamentals: building a mailing list of email addresses (i.e. subscribers). Without this, you’ll have no one to email — and let’s be clear, buying a list is never the right option.

An App Marketing War Plan

When you’re elbow-deep in designing or coding a mobile app, it’s hard to step back, change tack and focus on the equally important yet arguably less fun tasks of putting together a promotional website, a trailer and, yes, email campaigns. That’s why it’s best to make a marketing plan and execute it early on, instead of waiting until App Store approval anxiety has kicked in.

A marketing plan doesn’t have to be complex. For email, it could be something as informal as the following.

Pre-Launch

1. Choose an email service provider, and create a subscription list.
2. Build a pre-launch page with an email sign-up form.
3. Encourage people to visit the pre-launch page and subscribe for email updates.
4. Build an email subscription form into the app.

Beta Testing

• One week prior to beta testing
  Create an email campaign, inviting subscribers to a first look at the app in beta. Explain how they can download the app and provide feedback.
• Three days after beta launching
  Email your beta testers to request feedback.

Launch

• One week before launch
  Email subscribers to let them know the app is close to launching. Include positive reviews and encourage subscribers to spread the word.
• Launch day
  Email subscribers to announce the launch, and link to the app’s download page in the App Store, Google Play, Windows Store, etc.

Post-Launch

• One week after launch
  Thank your subscribers, and encourage them to leave feedback on the app’s download page.
• After major updates
  Email a summary of what’s new and improved, and encourage subscribers to spread the word.

It’s that straightforward — just jot down a rough outline of what you plan to do, on a napkin if need be. You can be as creative as you like with your email marketing strategy. Just make sure to make good on it!

Choose An Email Service Provider

If you’ve never fooled around with email marketing, choosing the right provider will likely be a touch confounding. Many services are out there for creating and running email campaigns, from Web-based ones such as Campaign Monitor and MailChimp, to self-hosted apps such as Sendy. My advice is to talk to other designers and app creators about what they’ve tried, and then open free accounts with some of the Web-based DIY services. The differences in the experiences (not to mention the features and pricing) between apps will soon become clear. Cheapest doesn’t mean best in this game, so shop around and run a few trial campaigns.

The benefit of a Web-based email marketing app is that getting started is generally quick and easy. Remember that if your needs change, you should be able to migrate your lists to another service.

Pull Together A Pre-Launch Page

Even when your project is in an early stage, it really pays to create a simple pre-launch, or landing, page with a few details about the app, perhaps some concept art and, of course, an email subscription form. After all, if visitors to your website like the concept, they’ll be keen to sign up for email updates and find out when your app is launching. These will also likely be your most valuable, passionate users for giving feedback and spreading the word when you launch. Below is the pre-launch page for the upcoming mobile game The Drowning, by Mobage:

I like The Drowning’s pre-launch page for its sophistication yet simplicity. The artwork and trailer for this ominous first-person shooter are polished and persuasive. There’s even a nice incentive to sign up to the mailing list: email updates and a free wallpaper. Above all, the entire page is geared to getting visitors to subscribe, and the subscription form is unmissable. You’ll find a couple of other great examples in the post “Building An Effective ‘Coming Soon’ Page For Your Product.”

Now back to your page. One thing your email service provider should be able to do is generate a snippet of code with which you can add a subscription form to your website and automatically push new email addresses to a list. Alternatively, a number of simple services and plugins not only enable you to build good-looking pre-launch pages, but integrate with some of the major email service providers. Popular ones include out-of-the-box apps like LaunchRock and Unbounce; if you’re already running a CMS such as WordPress, then the Launchpad plugin for WordPress is worth a look. Or you could create your own self-hosted launch page using a template such as Launching.me.

With a pre-launch page up and running, you can get back to focusing on your app for a while. Or you could start communicating with your new subscribers, using autoresponders.

Add An Email Subscription Form To Your App

While it might sound a bit odd, nothing is wrong with boosting your ongoing marketing efforts by adding a subscription form to your mobile app itself. You could collect email addresses from early adopters to inform them of updates. Or perhaps you’re planning a really great newsletter for your audience and feel that in-app sign-ups would give the app a real boost.

If Cocoa is your language of choice, then Campaign Monitor has an official Objective-C wrapper on GitHub, which can be used to create in-app subscription forms and more. With an extensive API, it’s also well documented and comes with usage examples. Unofficial Objective-C wrappers are also available for MailChimp and Mad Mimi. Just something to think about.

Experiment With Other List-Building Tactics

Creating a pre-launch page and adding an email sign-up form to your app are both great ways to bring more people into the loop with your current mobile app and future ones. While these tactics tend to be rather set-and-forget, you could try other things to actively build interest in your title:

• Collect email addresses at events.
  Do you attend developer meetups or conferences? If you’re going to be talking about your upcoming app, you might as well give attendees a way to track its progress. Pretty much every email service provider comes with a customizable mobile app to collect email addresses and push them to your lists. Campaign Monitor’s is Enlist, and MailChimp’s is Chimpadeedoo.
• Offer something valuable.
  One effective tactic is to offer teaser content via a blog, such as concept art or even posts on what you’ve learned during development. Smack a subscription form onto your blog posts or even in your videos (using a service such as Wistia), with the promise of useful content and updates via your email newsletter.
• Offer a discount on the app.
  If you’re building a paid app, offering a generous discount to early adopters wouldn’t hurt — if they agree to sign up to your email newsletter, that is. Slipping in an incentive is always a reliable tactic, especially when it demands very little effort.

Now that new subscribers are rolling in, let’s look at what it takes to send out emails.

Create Your First Email Campaign

Some time has passed and, after a little promotion, your pre-launch page has collected quite a few email addresses. You might have some cool teaser artwork to share now, or you might feel it’s time to invite some subscribers to join the beta phase — heaven forbid, you might be a week out from launch! Scary stuff.

At this stage, you might be tempted to obsess over the technical details of creating HTML email campaigns (which are important), but, ultimately, this is a marketing exercise. What matters above all is your message and ensuring that readers are hooked at first glance. Smashing Magazine’s “How to Raise Your Email Above Inbox Noise” is a great primer on how to creating relevant and all-round “sticky” email content.

Another thing that folks regularly obsess over is figuring out the best time to launch a campaign. While some (albeit conflicting) evidence shows that the hour or day of the week you choose does make some difference, I think the advantages of emailing at 7:00 pm over, say, 10:00 am are marginal, especially if your subscribers are international. Even public holidays seem to work for some creators, so relax and follow a schedule that suits you. Your content will make the big difference, after all.

Having gone through all of this heavy stuff, let’s take an inspiration break and look at a couple of email newsletters from app developers, sent at certain milestones prior to launch. Click on each design to see the large version and to view the source code.

“Visit Our Pre-Launch Page”

The Drowning, by Mobage.

Now that you’ve got a shiny new promotional website, what better way to drive visitors to it than by running a campaign for your existing email lists? As an established mobile game developer, Mobage is in the fortunate position of having an established community of dedicated gamers, many of whom would probably be interested in this title. This email’s narrow format makes it comfortable to read on mobile devices, too.

“Invitation to Beta Test”

Echograph, by Clear Media.

I like this invitation to beta test Echograph because it’s as clear as it gets. There’s no waffling about this awesome animated GIF builder for the iPad — just a couple images that show beta testers what they need, a sample GIF and step-by-step instructions for installing the app during the beta phase.

“Thank You for Beta Testing”

Dropmark, by Oak.

Once beta testing has wrapped up, it’s nice to say “Thank you” and offer a little something for the effort and feedback your audience has volunteered. Dropmark’s thoughtful email campaign does this with class, by providing a discounted upgrade for beta testers. It’s a great way to ensure that they keep using the service.

I hope you’ve enjoyed that visual interlude. Now, let’s discuss how to announce your app’s launch. Hold tight!

Launch Your App With Email

So, the big reveal is imminent. You’ve probably just submitted your app to the App Store or published it on Google Play. Either way, it’s time to focus on getting the word out.

Whether you announce the launch in a newsletter or via a standalone email announcement, you need to do two things: first, make an impact, and secondly, make it very easy to download the app from the newsletter itself. To achieve both, you’ll need to get the logo and branding for your app store of choice, as well as the link to the download page and, of course, some compelling content to get subscribers excited about the app.

One company that checked all of these boxes in a clever way is Campaign Monitor, which announced the release of its subscription form app for the iPad, Enlist, via its monthly newsletter:

You’ll notice that Campaign Monitor summarizes the core features of this app concisely: It’s a customizable iPad app for collecting email addresses. The images are crisp and inviting. But the real magic happens when you view the newsletter on an iPad. A “Get it from the App Store” link appears, allowing users to download the app to their device in two taps.

As you might have guessed, a pretty clever style sheet, with a media query, is used to reveal the App Store link when the email is viewed on an iPad. While I don’t want to go too deep into code, this neat trick is worth sharing. Below is an abridged version of the HTML and CSS.

CSS

    p.ipad {
    	font-size: 0px;
    }
    …
    @media only screen and (min-device-width : 768px) and (max-device-width : 1024px) {
    
    	a[id="reveal"] {
    		display: block !important;
    		background: url('http://yourdomain.com/images/appstore.png') no-repeat center center !important;
    		background-size: 232px 49px !important;
    		width: 232px !important;
    		height: 49px !important;
    	}	
    }
    

HTML

    <p class="ipad"><a id="reveal" href="http://campaignmonitor.createsend1.com/t/y-l-jidkuht-l-p/" title="Get Enlist from the App Store"></a></p>
    

You might be curious why Campaign Monitor uses font-size: 0px to hide the App Store link when the email is viewed on anything other than an iPad. This strange choice is explained in the blog post “How to Display Content on Mobile Devices Only.” It gives a taste of the quirkiness involved in designing HTML emails.

On to the content. Let’s go to the second launch campaign for Echograph, which features a prominent download link, plus a video and animated GIF that walk viewers through the app:

Second launch campaign for Echograph.

Nicely done. Overall, the best thing you can do with your launch email is have fun and be creative — while staying concise. And before any of you mentions it in the comments, TechCrunch reckons that Sunday is the best day to launch an app.

So, What Next?

Once your app has launched, you might be tempted to take a break from campaigns, but then you’d miss out on a big opportunity. By continuing to grow your email lists and stay in touch with subscribers — whether to collect feedback, announce updates or simply share your successes — you’ll find email to be a valuable tool in your marketing arsenal. If this sounds like work, consider going on autopilot with autoresponders, which are email campaigns that are automatically run when set off by certain triggers, such as a date (“send two weeks after visitor signs up”) or an action (“send whenever a user upgrades”). To learn more, read Smashing Magazine’s guide on “How to Market Your Mobile Application,” and, of course, talk to your fellow developers.

This post hasn’t been code-heavy, but it could have been — designing for mobile, let alone email, is a surprisingly demanding process, regardless of your aptitude as a designer or coder. However, I wanted to focus on helping you make the most of your marketing milestones by engaging with users via email. If you walk away from this post with one thing, it should be a desire to get your planning in the bag as soon as possible. Otherwise, you risk missing out on the opportunity to build an audience that is as committed to your project as you are. Best of luck with your email marketing journey. We’d love to hear from you in the comments.

(al) (ea)

© Ros Hodgekiss for Smashing Magazine, 2013.

Civilian GPS is vulnerable to being spoofed—and researchers are looking for ways to ensure the signals are legit.

University of Texas researchers recently tricked the navigation system of an $80 million yacht and sent the ship off course in an experiment that showed how any device with civilian GPS technology is vulnerable to a practice called spoofing.

With up to a million free push notifications, Amazon makes it cheap and easy for Mobile app developers to build their iOS and Android apps.