A website without search engine optimization is like a car without an engine or a computer without a mouse. Just like a car without an engine isn’t going anywhere, a website without SEO won’t be useful to anyone. In a nutshell, the goal of SEO is to rank as high as possible on page 1 of Google’s search results, so searchers can find your website. Not only does SEO help your website perform better in search results, it has other benefits that improve the way your website functions, too.

1. Title Tags & meta descriptions

Never underestimate the power of the title tag and meta description. Together, they make up the search result snippet, and they are the single most important SEO feature.

Tip: Every page on your site should have both a title tag (50-60 characters) and a meta description (up to 160 characters).

The title states the main thrust of the page, as well as your company name. The meta description is 1-2 sentences that describe the page’s contents in more detail. Keep in mind that they should compliment each other because they will be displayed side by side in the search snippet.

2. Crawlable URLs

Use hyphens (-) rather than underscores (_) to separate words in a URL. Google’s indexing bots treat a dash as a word-separator which helps it understand the context of the URL to list it in relevant search results. Additionally, it’s easier to understand for users in a situation where the link is underlined and underscores tend to disappear as part of the underline.

3. Alt Text on Images

Traditionally thought of in the context of accessibility, alt text is also one of Google’s primary criteria for image search results. Providing quality alt text on each image is a simple yet effective way to show up in image search results, and with almost 27% of all online searches centered around images, you don’t want to miss out on this huge source of organic traffic.

In addition to using alt text to index images, Google also takes file names, context and captions into consideration.

4. Semantic Markup

Is your page using semantic markup to structure its content? You might be missing out on one of the most important SEO signals if your pages don’t have heading tags, especially H1 tags. Each page should have one H1 tag that specifies the main content of the page and differs from the title tag in that it is more concise and inclusive.

5. Page Speed

Page speed is perhaps one of the most overlooked parts of SEO. Not only does it require thoughtful planning by the development team to create a lightweight site, it also needs the cooperation of content authors to prevent it from becoming a behemoth later on.

While this topic could be a blog post in itself, here are a few of the high points:

• Minify JavaScript and CSS files.
• Reduce the number of calls to the server (for instance, in the case of icons, use Glyphicons or sprites instead of individual images).
• Optimize images to reduce file size.

In particular, large images can be optimized to a fraction of their original weight without losing visible quality. This will prevent one of the biggest threats for future site bloat. Ensuring content authors are properly trained on image optimization will help keep the site light and fast. (If you’re losing visitors due to slow page load, call in the experts!)

6. Sitemap

A sitemap is an XML file that contains all the pages of your site. It lives in the root directory of the site and is used by search engines to guide the indexing process. Submitting a sitemap to Google Search Console is an invitation for Google to crawl and index your site and helps indicate the content you wish to be indexed.

7. Google MyBusiness

Google MyBusiness shows up alongside the standard search results, and highlights your business with pictures, basic information and access to your website. No development is needed, setup is quick and easy, and Google takes location into consideration to boost your listing for local searches.

Ready to Begin?

Let our experts help you get the most from your website. Contact us about auditing your site for on-page optimization opportunities and how a Findings & Recommendations report can help you determine what improvements would have the biggest impact to your page rank and traffic.

“Find the nearest gas station.”

“When will the next MacBook Pro be released?”

“How many touchdowns did Carson Wentz score last season?”

You’ve probably asked your phone one of these questions (or something similar) in the last week. According to Google, more searches take place on mobile devices than on desktop, and approximately 50% of the population uses voice search on a daily basis. There’s no doubt: voice search is changing the way we use the web. And the web is transforming to meet the challenge.

2 Key Factors for Google

Google seldom gives overt clues about what drives their engines, so when they do, it’s important. In the last couple years, Google has pushed two agendas:

Both trace back to the unique demands of voice search. But before we get into these two specifics, let’s explore some context.

1. Page-speed preferences
2. Mobile-first indexing

Context of Voice Search

Voice search is primarily used on mobile devices or in-home assistants, such as an Amazon Echo, and it takes the form of a question or command. Most users are no longer typing disconnected keywords, like “iPhone release 2018.” More likely, they are asking, “When will the next iPhone be released?”

Second, voice search is often used within a local context. Rather than typing in “McDonald’s Fargo ND,” most people are asking, “Where is the nearest McDonald’s?” or simply commanding, “Take me to the nearest McDonald’s.”

As illustrated above, voice search is often within a local geographical context, but regardless of location, users are looking for specific information – and they want it right away.

Page Speed

Since 2010, Google has used desktop page speed as a ranking factor. Within the last few months, they have cranked the standard up another notch. As of July 2018, mobile page speed will also affect ranking performance. This decision makes sense in the context of voice search. Without speed, voice search is dead in the water. Nobody wants to hear, “Please wait a minute while I find that for you.” Even 10 seconds is an eternity when you’re standing on the sidewalk waiting for a page to load.

Mobile-First Indexing

In March of this year, Google rolled out mobile-first indexing. This new approach uses the mobile version of a site as its main reference instead of desktop. The change came after three consecutive years of mobile searches out-performing desktop, due in large part to voice search.

So what does that really mean for your website? For a responsive design that uses the same url for both desktop and mobile displays, nothing changes. For sites that have a separate mobile url, Google now uses its mobile links as its primary indexing method. By the way, Sitecore one-ups these options with something called “Dynamic Serving,” in which the device is detected prior to serving the content; in other words, mobile and desktop load content specific for each display. With this ability, we can optimize mobile page speed, eliminate page bulk on mobile and get users what they need faster.

The Big Question Is … Are You Ready?

In short, voice search has driven recent mobile search trends, pushing Google to prioritize page speed and reshuffle their algorithms to base indexing on mobile over desktop. And the growing demands of voice search – and the impact on SEO – show no signs of slowing down.

Is your website optimized for the voice revolution? Reach out to our experts anytime, and we’ll make sure you’re ready.

A partnership announcement at Dreamforce 2017 is sending shocks around the world. Tech giants Salesforce and Google have partnered to integrate their marketing and sales features – creating a robust toolbox to help their customers work smarter, work faster and convert leads into revenue.

A Closer Look at the Partnership

At some point, you’ve probably heard the saying, “The whole is greater than the sum of its parts.” This partnership is the perfect example. Putting their capabilities together, Salesforce and Google will provide something mutually beneficial – and far more powerful than they had standing alone.

The partnership has two main components:

1. Salesforce Marketing Cloud and Sales Cloud integration with Google Analytics 360
2. Salesforce Lightning integration with G Suite

The Biggest Benefits of Integration

1. Smarter Campaigns

With integration between Google Analytics 360 and Salesforce Marketing Cloud, data from audiences and campaigns from 360 will be easily accessed in Marketing Cloud to help drive smarter email campaigns.

Conversely Sales Cloud’s data will be available in 360 to drive informed campaigns for specific segments.

2. More Productivity

The second main piece of the partnership is the integration between Salesforce Lightning (with Quip) and Google’s Gmail, Meet, Calendar, Spreadsheets, Drive and Docs. As the global leader in Customer Relationship Management (CRM), it’s easy to see how Salesforce’s integration with this productivity suite will be powerful.

Salesforce records and reports can be synced with a Google Spreadsheet, where data that is updated in either place will sync with the other. Meet by Google Hangout (a video conferencing tool that’s the enterprise equivalent of Google Hangout) will be integrated to provide in-app access to Salesforce data, helping businesses connect with customers uninterrupted.

Timeline for Rollout

Already, several of the Lightning integrations are available for customers to leverage. The integration with Google Analytics 360 is anticipated in early 2018.

What Does This Mean for Our Clients?

With these latest tool integrations, our experts here at Sundog can provide an even richer 360-degree view of customer data to our clients, finely-tune strategies and optimize campaigns that minimize cost and maximize effect. It’s the next step in helping our clients connect with their customers in even deeper and more meaningful ways.

Any other questions about what this partnership could mean for your company?

With upcoming legislation around website accessibility, it’s time to take a serious look at how your website stands up to accessibility requirements.

The WAI (Web Accessibility Initiative) categorizes web accessibility into three levels: A, AA, and AAA – from basic to most advanced. Proposed upcoming legislation is aimed at requiring mainstream institutions like financial, education and healthcare to meet a minimum standard of AA.

4 Areas of Importance for Web Accessibility

So how do you stack up? When it comes to accessibility, it’s important for your website to be:

1. Perceivable: That means using contrast, image text alternatives and information that’s legible.
2. Operable: Support mouse alternatives, such as keyboard navigation.
3. Understandable: Include clear instructions, purpose and action items.
4. Robust: In other words, your site must work reliably with assistive technologies.

(Further details are outlined on the w3C website.)

Of course, websites should already be applying many of these techniques, at least on a surface level. Not only are these best practices beneficial for all users, but there are many side benefits, too, such as improved SEO (particularly in the case of alt text). Everyone can benefit from good contrast, clear action items and straight-forward error messages. Even tab navigation can come in handy.

More About the AA Standard

While many of the surface accessibility features benefit all users, the AA standard goes much, much deeper. It calls for not just contrast, but high contrast, and specific criteria for ensuring that interactive elements like accordions and form inputs can be accomplished via the keyboard.

In addition to more rigorous interface requirements for the AA standard, the code itself plays a key role for the screen reader by notating each section of the website, so the audio outputs a sensible hierarchy and flow. The code also helps the screen reader distinguish between content elements, actionable items and media.

Is your website accessible? It might be time to give it another look. And if you want to learn more about the latest standards, let us know. We’ll be happy to help.

Have users who want to customize branding, colors and buttons in a Lightning Community? Design tokens are the key.

The brand panel in Salesforce Community Builder is equipped with five standard palettes and six color swatches to customize them. Using Lightning design tokens, we can tie these color swatches into a custom Bolt theme, giving users control over the colors in your theme.

This table documents the swatches and the design tokens that control them. Some swatches can have more than one token applied to them, as is the case with the Action Color.

Using the table above, we can start by applying the action color to the buttons in our template with the colorBackgroundButtonBrand token as seen below.

The t(tokenName) syntax designates a token reference. Note that Lightning is very particular that a token is used as it was designed. If you try to use colorBackgroundButtonBrand as a text color, your page will throw an error because it is meant only as a background property. To apply text color, you would need to use colorTextBrand or colorTextLink.

Next we could apply the Link Color design token to all our text links.

Lightning components are designed to be self-contained and independent. While this is great for modular development and encapsulation, it comes at a price. That price is JavaScript. JavaScript from one component can’t talk with another, and that’s why Lightning components use events. Events handle any interaction that needs to take place between components: button clicks, modals, etc.

Events are a twofold process: sending and receiving. The sending component (and controller) creates and then fires the event. The receiving component (and controller) intercepts and handles it.
Want to know more about how it works? Before we talk examples, it’s important to note that Lightning component events can be one of two types: component and application.

The example below is a component event. Here’s the component design used in the examples below:

Event Types

1. Component events are parent-child relationships, in which an event registered in the child component can be handled only by the parent and not other sibling components.
2. Application events, on the other hand, are for sibling relationships. They can communicate with any other component. The type of component is determined by the event file itself by setting the attribute on the <aura:event> tag to either COMPONENT or APPLICATION.

Example Events

productAddItem.evt products.cmp productsController.js productForm.cmp productFormController.js

productAddItem.evt

<aura:event type="COMPONENT"> <aura:attribute name="products" type="Products__c" /> </aura:event> 

Events are defined as separate entities from components and controllers, and they act as the go-between for the sending and receiving parties. The event definition also determines the event type: COMPONENT or APPLICATION.

productForm.cmp

<aura:component> <aura:attribute name="products" type="Products__c" /> <aura:registerEvent name="addProduct" type="c:productAddItem" /> <!—component form here—> <ui:button label="Add Product" press="{!c.clickAddProduct}" /> </aura:component> 

While stripped down to the essentials for illustration purposes, this form component has a submit button attached to the event. The component registers an event (registerEvent is your cue this is the sending component) named addProduct. Keep this name in mind, because the receiving component will call this same name. It’s the glue that binds the sender and receiver together. The button references the clickAddProduct function in its controller, which begins the event process.

productFormController.js

({ clickAddProduct: function(component, event, helper) { var products = component.get(“v.products"); var createEvent = component.getEvent(“addProduct"); createEvent.setParams({“products" : products}); createEvent.fire(); } })

When the button in the above component is pressed, it sends the action off to this function in the controller. Validation aside, this is pretty simple. It “loads” the event and then fires it.

products.cmp

<aura:component> <aura:attribute name=“products" type=“Products__c[]"/>  <aura:handler name="addProduct" event="c:productAddItem" action="{!c.handleAddProduct}" />  <c:productForm /> <!—rest of component stuff here—> </aura:component>

Just like we registered the event in the child component, we now handle it in the parent component with a handler. Note that the name, addProduct, is the same as when we registered the event. The action attribute defines the next step in the loop, which calls a function in the controller called handleAddProduct.

productsController.js

({ handleAddProduct: function(component, event, helper) { var newProduct = event.getParam(“products"); var action = component.get("c.saveProduct"); action.setCallback(this, function(response) { var state = response.getState(); if (component.isValid() && state === "SUCCESS") { component.set("v.products", response.getReturnValue()); } else { console.log("Failed with state: " + state); } }); $A.enqueueAction(action); } }) 

This is the receiving controller that handles the incoming event and communicates with the apex controller. The function, saveProduct, is a reference to the apex controller in which the upsert takes place (not shown here). The final line of code queues up the action (the call to the server), which upserts the form entry. And with that, the event cycle is complete.

Pixels and rems and ems and percents, oh my.

While there are several different methods for coding with font sizes, it all depends on what’s right for your particular project.

First Things First

Let’s take a closer look at every option:

• Pixels: font-size: 16px shows as 16 pixels in the browser.
• Rem: font-size: 1rem shows the pixel size set on the page’s root element, html. So if the html element is set to 16px, 1rem renders as 16 pixels in the browser.
• Em: font-size: 1em shows the pixel size relative to what it inherits from its parent element. This works similarly to rem in that it is a percentage of the parent, but instead of being influenced by the root, it’s influenced by its parent container – which can get tricky if that’s also nested within a grandparent container with a font-size value.
• Percent: works very much like an em in that if the parent is set to 16px, 100% will render as 16 pixels in the browser.

3 Methods to Consider

While there are a multitude of strategies for combining these to fit a project’s requirements, here are a few to consider:

1. Tried-and-true: 62.5% and ems

This method has been around for a while, and it’s a tried-and-true method for making em sizes easier to calculate. By setting the body to 62.5%, 1em becomes 10 pixels, 1.5em becomes 15 pixels, and so on. It’s easy to write precise font sizes with this method as it has a simple 1 to 10 ratio.

2. Combination of pixels, rems, and ems

This strategy was set forth by CSS Tricks for module-based sites, and it uses pixels as the base on the html element, rems on the module containers and ems for the text. The advantage of this method is that a module container’s font-size can be set with the result that it proportionally shrinks or enlarges the font size. For instance, a sidebar module container can be given a font size to proportionally shrink all the text inside it from <h1> to <p> to <span>.

Resource: https://css-tricks.com/rems-ems.

3. Bootstrap in the mix

Bootstrap uses a mix of pixels, ems and percents for their font-sizes.

• The html is set to 10 pixels, presumably to set 1rem to 10 pixels to make rems easy to calculate.
• The body is set to 15 pixels, a standard size for paragraph text.
• Standard text elements like h1 and p are set with ems.
• Font variants such as small are set with percentages such as 75%. Their heading classes (.h1, h2, h3, etc.), form input classes, and text class, .lead, are set with pixel sizes to ensure that, regardless of where they are nested within the site, they will take on the intended size instead of possibly inheriting an em size from its parent.

Go Forth

So which method is the best? It honestly depends on the project. Every project requires its own approach. Go where the project leads, and don’t be afraid to explore.

Did you know that there are three different ways that fonts can be implemented into a website?

Here’s the good news for designers: your creative juices don’t have to be stymied when it comes to choosing fonts for the web. You have options, and they go far beyond Verdana, Helvetica or Arial. Just keep in mind that simple sans-serif fonts are easiest for your users to read on the screen.

So what are your choices?

3 Options for Fonts

1. Standard fonts

It’s standard practice to use default fonts, since that’s the safest way to ensure that your users will see what you intended – and not what their computers decided to substitute when the fancy font you wanted wasn’t found on their computers. Standard fonts are typically the way to go, unless you really want to use a custom font.

2. Embedded fonts

One of the easiest ways to implement custom fonts in a webpage is through a CDN (Content Delivery Network), such as fonts.google.com. They offer a huge variety, they’re fast, and the fonts are simple to implement. (See the screenshot below.) The only drawback with this option is that your choices are limited to what’s available on their website.

3. Self-served fonts

This is the most flexible option. It takes a few more steps, but the sky’s the limit. With this method, the font is included in the project files and then referenced from the website’s own resources to ensure it can deliver the correct font wherever the website is viewed.

In other words? When it comes to choosing a font for a website, you don’t have to limit yourself to just Verdana, Helvetica or Arial. The world of fonts is available to you.

A good user interface (UI) is like a vehicle. You don’t even think about it when it works correctly, but when it doesn’t, it’s a nightmare. CSS effects should make your UI smooth and effortless.

In fact, here are three subtle effects you can do with CSS to improve the UI of your website:

1. Transition Button Hovers

This one line of CSS makes a world of difference in the impression of a UI. It takes the starkness out of a hover state, adding smoothness and polish to the general impression.

2. Shake Error Messages on Forms

Have you ever tried to track down a field you missed in a long form? Even if there’s an error message, it’s easy to miss – that is, unless it moves and catches your eye. It’s easy to add a few lines of CSS to give an error message a short, little shake to help your users identify what they missed.

3. Fade In & Slide Up

These two effects combined on an element make a nice entrance. Keep in mind you don’t want to slow download time by lengthy transitions, so use them sparingly on one or two elements you want to highlight above the fold and keep the transition relatively short. In the example below that fades in as it slides up, the margin controls the amount of slide and the opacity controls the fade.

Have fun experimenting with these effects!