It’s important to get yourself working in a way that makes sense for you so that you remain organized, working efficiently and well-connected. Here are a set of recommended tools for doing just that while you work remotely. These are, admittedly, the ones we use or that I like best, but I’ll list a few alternatives with each, too.

Slack

This recommended tool is probably not a surprise. Communication, in my book, is the most critical aspect of any successful relationship—work or personal—it makes no difference. Slack is an excellent chat-like environment for teams. It permanently removes the needs for email and internal interaction via any other forms of communication.

Slack is broken down into channels, which can organize related discussions. It provides the ability to have group and private chats as well, although I imagine these won’t be necessary for most companies. Slack also provides VoIP calling, screen sharing, and interactive desktop sharing (meaning I could interact with your screen).

Additionally, the platform offers a fairly robust search functionality, reminders, and integrations with an extensive database of productivity tools like Google Docs, Jira, GitHub, and more. Slack is a must for teams, but several others aim to connect your and your workforce in similar ways. A few of those are: HipChat, Mattermost, and Flock.

Zoom

Zoom is one of the better options out there for voice and video chats along with some minimal screen sharing features. Slack offers a voice, video, and screen-sharing options. However, Zoom does do a better job of handling a more significant number of people at any one time with minimal issues on slower internet speeds. There are also options for scheduling and reoccurring meetings, which can be helpful for those weekly scrums.

Zoom tends to be the industry standard, but many alternatives exist. Those include, but are not limited to: Skype, Join.me, Google Hangouts, or GoToMeeting. It’s all about what you need and how many people you need to host at any given time.

Project Management (PM)

This one was hard for me to nail down. Project management tools aren’t one size fits all. Slack and Zoom tend to be “industry standard” for communication, but each company handles projects differently. I’m going to recommend a few of the most popular along with a few less-common alternatives.

Jira

Jira is one of the largest and most popular productivity tools made by Atlassian. It has planning and tracking tools and integrates directly into a large number integrations they offer via their Marketplace. Jira offers multiple views of the same data, one of which is a Kanban board, similar to Trello.

Trello

Trello is another bit of productivity/organizational software made by Atlassian which offers a Kanban board-style group of lists and task. Trello offers integrations as well, but is far less robust compared to Jira.

Asana

Asana is a bit more geared toward timelines and goals. Like Jira or Trello, it offers multiple views for handling and assigning tasks as well as support for many different workflow solutions. Asana doesn’t have the same sort of integrations, but with all that it tries to accomplish, I doubt you’d need it.

Monday

Monday is a bit of a newcomer to the PM game. Monday claims to make collaboration and organization as easy as pie, offering multiple ways to view data, plan projects, and track progress. Monday integrates with Slack, Trello, Google Docs, etc. and boasts a large number of uses, which can be viewed here.

Other PM Tools

I use Notion to document, track, plan and organize my work. Though it’s not for everyone, it markets itself as an all-in-one work space for planning, writing, collaboration, and organization. If anything, it’s downfall might be that it’s got too much going on.

Several other tools are out there with varying accolade including Float, Basecamp, Zenkit, or Ora. My advice would be to check them all out, figure out what you need, what you want to accomplish, and what will work best with your team’s workflows.

Simple Task Management

If you do not need to track entire projects or aren’t in the market for a project management tool, something like Notion is excellent for keeping thoughts organized. There are others out there for simple task management/assigning like Todoist, Wunderlist (acquired by Microsoft, and will eventually be shut down in favor of Microsoft To-Do), or MeisterTask. Evernote is a trendy option for organizing thoughts and notes but doesn’t do a super great job with tasks in my opinion.

Code Management

We are all probably aware of BitBucket or GitHub for managing full repositories, or “repos,” but we don’t always want to house our code in a repo if we’re only working through ideas or need to save a bit of code we reuse over and over. For that, we can leverage a bunch of different tools to keep our working repos clean and troubleshoot and problem solve along the way—not to mention keeping track of cool code snippets that we might want to refer to later.

Gist

Gist by GitHub is my preference both because I fully back the open-source community and also because it is a reasonably simple way to keep bits of code and dev notes in a place I’m fairly sure I’ll find it a year from now or two. Sharing and keeping track of edits is as easy as a single click. It’s super helpful when someone might ask for a bit of code in short order.

CodePen

CodePen is fantastic for working out more complex proof of concept ideas, or just testing a feature before implementing it. I tend to take advantage of CodePen to work through a problem quickly or without all of the other features that might already exist on a working project. Alternatively, you might find JSFiddle just as useful, although CodePen has the bonus of a development community and other developers doing the same thing, which can come in handy for inspiration.

Others

Cacher (formerly GistBox) along with SnippetsLab (macOS only) are standalone apps that provide a desktop code snippet functionality, although I personally prefer a web-hosted service so I can access my snippets anywhere without relying on needing an app or a certain operating system to do so.

Documentation

Documenting and sharing is exceedingly essential when working remote since you can’t just sidle up to your office mate and ask their opinion on something. You need to send screenshots and citation to make questions and answers easy. There are a lot of services out there that make this a little bit easier, but here are a few below.

Screenshots

Skitch by Evernote is a screen capture and notation app which makes the ability to point out specific elements, changes, or points of interest a snap.

Screen Captures

My top votes are for Kap (macOS) or ShareX (Windows) for recording your screen and/or screen interactions.

Password Management

1Password is an excellent solution for storing and securely sharing passwords with your team and clients. 1Password is available for personal use, families and teams, which makes keeping track of all that sensitive information (not just login information) safe and secure.

Alternatively, you can check out LastPass for Teams.

Summation

There’s a lot more out there to keep yourself organized and accountable while working remotely. There isn’t one right solution for everyone. Research, test, and try things out. Get feedback from your team, too, as they’ll be using the productivity tools you’ve selected. Perhaps that next big thing is right around the corner.

The post Tools to Boost Remote Work Productivity appeared first on WebDevStudios.

None of these considerations are outside the realm of common sense, but the excitement of redesign opportunities that become available when building a fresh website can make us tend to forget why we need something new or who we’re doing it for. So, let’s get into it. These are the rules for your redesign.

Rule 1: Have a Reason.

Have a valid reason for your redesign. “I want something new,” isn’t a valid reason. “Our current website is not accessible,” and, “We don’t have a mobile responsive design,” are valid reasons.

Keep in mind that the level of redesign should be in line with the weight of the reason. For example, “We’ve completely changed our identity and branding,” would carry more thought, weight, and work compared to, “We have accessibility contrast issue on our current site.” You must address accordingly.

Rule 2: Do Your Research.

Do the research first. You don’t get a new site design until you know who it’s for and what that group of people expect. The younger your demographic, the more you might skew social or mobile, whereas older generations might have accessibility concerns or expect something more “traditional.” Everything that happens in the design will be influenced by this data.

Rule 3: It’s Not for You.

You have clients, investors, subscribers, and consumers of your content. The website is for them. Leave your preconceived notions of what is “good” or “bad” about your new design, and think about your demographic.

Rule 4: You Probably Don’t Need That.

There are a lot of new trends. Every day, I find at least one new thing that someone is trying out. The difference between those companies and you is that their brand is defined by cutting-edge progress in web development. I imagine you need something to inform and support your users long term. So before you request a feature, ask yourself, “Do I need it?”

Rule 5: There Is Such a Thing as Too Much.

You don’t need to fit everything on the homepage, above the fold. You need a plan—small bits of calculated targeted content to get the job done. You have seconds to funnel your users, not minutes. You have a whole website in which to put that extra content.

Rule 6: Unless You’re Amazon, Your Navigation Doesn’t Need To Be That Complex.

Unless you’re selling loads of products that require complex search algorithms and boundless numbers of categories and organizational strategy, you don’t need 90 pages and 14 drop-downs in your navigation. I imagine your core business could be summed up in a half a dozen parent pages, which is a clean and simple alternative. If you’ve done your research, you should know where your users are expecting to go and what they’re expecting to find.

Now You Know.

Rules one, two, and three are really the holy grail of design rules, although all of these are heavily based on common sense. So instead of reiterating the importance of them, I thought I’d expand a little on rule two, which often gets forgotten or ignored—partially, perhaps, because of time, but most often because the task itself can feel overwhelming and you may not know where to start. Here is a fantastic set of places to get you started on your research journey.

• Optimizely: Use simple A/B testing.
• Similarweb: Compare your website to similar websites in the industry.
• Google Trends: Analyze trends in your area.
• Consumer Barometer: Determine how people use the web.
• Google Analytics: Analyze your user interactions and way points.
• Typeform: Gather survey data quickly.

The post Dev Shortie: Rules For Your Redesign appeared first on WebDevStudios.

In my private time, I’ve been building a starter theme from scratch to better educate myself about what is required by WordPress to build a theme-repo-approved theme but also to make my own informed decisions based on what others are doing, how people typically use the internet, and what of WordPress core feels antiquated.

I started writing this blog post to try and build a custom theme from scratch, but that proved too problematic for a few reasons. The time commitment wasn’t small. Any theme I built would require more than just one blog post and there’s a world of information out there to help you on your way already. Also, before any opinionated decisions had been made, the outcome was essentially any other theme out there already. The biggest reasons I thought I’d circle back and rethink this post was because a lot of those opinionated decisions I was making were very much outside of what is traditionally accepted and/or removes items required to be in the theme repo.

There are plenty of articles that will walk you step-by-step in building a theme, but I’m not going to do that because I think it’s important for aspiring developers to take some general knowledge and explore and implement on their own, really learn by doing rather than learn by emulation. So instead of building a theme from scratch, let’s keep it high-level and talk about what is required, what’s new in 2019, and some of the ways I think we could clean up WordPress for the frontend and for users.

For Starters

I’m going to assume you’ve setup a WordPress install already.

When building a theme, you can reference the WordPress codex for Theme Development and the Anatomy Of A WordPress Theme cheat sheet so that you can ensure you’re using the proper coding standards and anticipated elements. This will give you an idea of what WordPress would be expecting.

We’ll set up a new theme folder inside the wp-content > themes directory in which we’ll put all of our files. Name it whatever you’d like, but that folder name should match your theme’s text domain.

To function, a theme really only needs two things: a style.css with your theme details and an index.php file. You can learn more about the required files from WordPress directly here in which they also suggest comments.php and screenshots.php as requirements. Really, aside from the theme information in the style sheet, you don’t need any markup for WordPress to successfully activate the theme, though it won’t do anything at this point.

Success!

From there you start adding template files and extend your new theme. Those files might include:

• 404.php — handles our content not found
• comments.php — handles your commenting
• footer.php — the ending place for your theme, closes all of our tags
• functions.php — adds some default setup for our theme
• header.php — opens our tags and handles meta data and navigation elements
• index.php — the default home or blog river template; this will also handle our archives
• page.php — the page template
• screenshot.png — your 1200 x 900 px screenshot for the theme dashboard.
• single.php — the singular post template
• style.css — styles our theme, but also contains the theme description and info

These would give you a pretty bare-boned and well-rounded WordPress theme. Take a look at any of your favorite themes to make decisions about how those templates should look and what content and markup those might include.

Moving On

From there, your theme requires several functions and declarations to add support for various things. The easiest place to start is inside the functions.php and set up our _theme_setup function which hooks after_setup_theme action. This gives us the ability register default functionality, add theme support of certain things, and allows child themes to overwrite any of your theme functionality.

So let’s go through that setup briskly. We’ll take a look at the Twenty Nineteen theme setup since it’s a WordPress core theme. We’re setting up support for various site functionality out of the box. We’ll define our text domain for translations, set up RSS feed support and lets WordPress handle the meta title. It goes on to add support of post thumbnails, custom navigation areas and output valid html5 markup for various elements, editor styles and widgets.

WordPress 5.0+

The main elements to take note of here are the addition, since the release of 5.0 and the formerly-known Gutenberg framework, is the theme support for a few items to enhance this new editor for your theme.

add_theme_support( 'wp-block-styles' ); which allows your theme to add to the default set of core block styles.

add_theme_support( 'responsive-embeds' ); which allows embedded media to retain its aspect ratio.

add_theme_support( 'dark-editor-style' ); if your theme has a dark background, you can turn on the dark editor styles to help match your front end more visually. Typically utilized with add_theme_support( 'editor-styles' );.

add_theme_support( 'align-wide' ); offers the ability to add class names to the image wrapper for those elements that offer wide or full-width images.

Without this feature, those elements aren’t available in the editor.

add_theme_support( 'editor-font-sizes', array() ); sets the editor font sizes which correspond to editor styles and are available within the block settings where applicable. The defaults are the same as what’s defined in the theme here, but any font sizes or uses could be added in your custom array.

add_theme_support( 'editor-color-palette', array() ); does the same thing, setting your theme’s main color palette.

The default, sans this function, looks like this:

You can read more about those in the Gutenberg Handbook here, but the point is that with new editor comes new support that we’ve not seen before and, from my internet deep dive, hasn’t really gotten the exposure it deserves, even if the new editor has only been met with minimal praise thus far.

Planning Your New Theme

This next bit is about user expectations. There are a couple different types of themes out there—those that expect the users to have a specific setup and utilize the theme in a specific way (a photographer’s portfolio, for example) or those that are more general and are intended to be used the way WordPress was intended to be used, as a standard blog. So, it’s important to have a game plan to determine how involved you’ll need to be in your new theme development project.

Here’s where I went down a rabbit hole: I have certain assumptions about, based on internet research and practical experience, how users typically use a website vs what typically comes with a default WordPress theme. WordPress makes its own assumptions about how users utilize their themes and websites. It is my opinion that these assumptions and reality don’t align, but that doesn’t mean that we shouldn’t at least look at the industry standard before making changes. Learn the rules before breaking them.

General Assumptions

I’ve mentioned many times in the past that every WordPress theme since Twenty Ten is essentially the same as each that proceeded it. Of course, functions were added and deprecated and standards changed to accommodate the changing internet landscape, but for the most part the core guts of the default themes have been more or less the same. It could be argued that the Twenty Nineteen theme is the most different but its core guts are still essentially the same. It’s the biggest area of note is the absence of the sidebar.php template which would be a bit more, but all of its content has just been moved to the footer.

In nine years, the internet, the way people use the internet, and the expectation of its users have changed quite drastically, though the WordPress Core themes have not.

I’m not saying that WordPress is wrong. They do set the standard and their goal has typically been to build something for the majority which their themes do accomplish. I’m just saying that when building a new theme, we might think about users a bit more specifically.

My Personal Assumptions

My assumptions about what a website, and as such a theme, should be can be summed up in three words: simple, clean, and focused. With the inundation of media and content at every waking hour, our attention is divided too thinly to make any real impact on the user if it requires work to filter through all of your content without some help.

Simple

For a basic website, unless you’re an eCommerce store, you don’t need drop downs or more than a few pages. There’s a lot of default information that isn’t typically relevant for most users either, such as post author, tags, number of comments, etc. A user probably only really needs to know when a post was published and maybe in which category it was published. Unless your website has carved out a section specific to authors and their content, the author is unimportant. They’ve come to your website because of your brand or already understand that the content is of a singular entity.

Clean

Clean, like simple, is about keeping things concise. But in this case, ‘clean’ references your design and layout. If users can’t find what they’re looking for, you’re probably overthinking your design and muddying the layout waters. Think of a website like a set of step-by-step instructions.

1. Find page
2. Click link
3. Read article
4. Sign up
5. Repeat

If at any point users get distracted or lost, your mission isn’t clear enough and needs to be readdressed.

Focused

Your website and your theme need focus. They have a goal in mind. The goal can be as simple as, “This is JUST a blog,” to “People NEED to see the most recent blog post,” to “Images are the MOST important thing.” Your intended focus will determine the structure of your website. The main point here is that if your theme is intended to focus the user’s eye and content in a certain place, make sure that your execution is clear. And don’t try to over complicate that goal.

As We Continue

If I had my druthers, I would completely remove things from WordPress Core. But I don’t want to maintain my own fork of WordPress; and for all its flaws, it’s pretty solid as it is. This means we need to support things in our theme even if we don’t feel they’re necessary, specifically if you plan on submitting your theme to the Theme Repo. I personally don’t find widgets or certain archive templates necessary for most people, and I certainly have feelings about WordPress comments, but I still support their functionality because I am not every person.

Be as opinionated as you want and push those boundaries, but know your audience.

The post Building a WordPress Theme: Things to Consider in 2019 (And Beyond) appeared first on WebDevStudios.

Truth be told, there are probably dozens of reasons that the styles may not be as organized or clean as they could be. We can’t see the future and we can’t always be in constant communication with one another, but I’ve learned a thing or two over the last decade that I think might help keep things clean, organized, reusable, and readable.

Before We Start

A few setup notes here: I write my styles with SCSS. This is my preference. There are many other options out there—Less or Sass to name a couple—which will work in more or less the same way. I also typically use webpack or Gulp on older projects to compile and minify, auto-prefix, and concatenate my style sheets.

Organization and Breakdown

The organization is really up to the user. There is no one right way to organize your style sheets, but I’m going to share how I organize styles and why. The why is the more important aspect for the sake of reusability.

As far as I’m concerned, there are three parts of styling a website: utilities, global elements, and unique elements.

Utilities

Utilities are things like variables, functions, or Sass mixins to help you in building your website fast and efficiently, but is rarely utilized effectively. This is the most important area for improving our processes, but we’ll come back to that.

Global Elements

Global elements are parts of your website that are used universally across the site, or in my opinion, anything that may exist on two or more pages of your website in some capacity. These are things like your typography, your grid, input or button styles, card/graphic styles, icons, etc. The large majority of your website’s styles will fit into this category.

Unique Elements

Unique elements are exactly what they sound like: some part of your website that may only exist on one part of your website. This might be something as small as that one element that shows up only on the homepage or something bigger like all single post template—shared elements that only exist in one area of your website. They can, in this case, be reusable, but aren’t part of the global scope.

Here’s where we tend to get messed up. Things that exist on a single post template, to continue the example, will also exist in the Global Elements and will probably be rendered in part by Sass mixins or variables in use. In fact, most of that template will probably be informed by the global styles unless, for some reason, it’s completely different. We might start to dirty up our code when we don’t clearly acknowledge inherency and don’t take a larger advantage of our utilities.

Styles start to get a little dirty because there isn’t sufficient effort to educate incoming developers about how things are built or what elements are used, which is why it’s infinitely important to document your code.

Comment and Document

I don’t mean you need to write up a Github Wiki for every bit of code you write, but DocBlocks are important just as they are writing JavaScript or PHP, etc. At the very least we need to explain why things might go against the typically expected standards, overwrite global styles or if an !important is required, for example.

I take advantage of VSCode’s snippets to ensure that all of my SCSS start with a comment. At the least to determine what selector is used. We can’t always adhere to a BEM style structure, or inherently understandable class names, so it’s important to define what’s being styled if, at the least, there’s nothing else special about that block of code.

I might document minimally like:

// h2.
.title {
	font-weight: bold;
} // .title.

If there’s something more involved in the block of styles, I might add a more specific note like this:

// Post Title. Overwrite parent theme.
.entry-title {
	color: $color-red !important; // Force override parent theme.
	font-weight: bold;
	text-decoration: none;
} // .entry-title.

Of course I would do my best to style a selector in a parent theme before deciding an !important is required, but hopefully, you get my point.

I also find myself styling some object with multiple elements nested together; I separate those by an element comment to ensure each bit of styles are covered. This is a slimmed down example. Normally, I’d only implement this strategy on larger chunks of SCSS, but as an example.

//-----------------------------------------
// BLog River Post
//-----------------------------------------

//--------------------------------------------------------------
// Post River Card
//--------------------------------------------------------------

// article.
.post {
	border: 1px solid $color-gallery;
	background: $color-white;
	padding: 1.5625rem;

	//-----------------------------------------
	// Post Title and Meta
	//-----------------------------------------

	// header.
	.post-title {
		font-weight: bold;

		// span.
		.date {
			color: $color-alto;
			font-weight: 400;
		} // .date.
	} // .post-title.

	//-----------------------------------------
	// Post Entry
	//-----------------------------------------

	// div.
	.post-entry {
		margin-bottom: 0;

		// p. Inherits global styles.
		p {

			// Links in post entry.
			a {
				color: $color-sunshine; // Color differs from global link color.
			} // a
		} // p.
	} // .post-entry.

	//-----------------------------------------
	// Post Footer
	//-----------------------------------------

	// footer.
	.post-footer {
		font-size: 0.875rem;
	} // .post-footer.
} // .post.

This isn’t an immense amount of extra work in order to make sure that all of your selectors, class names and styles are documented and anything that differs from the global scope are noted. Anyone coming in after the fact should be able to gain a fairly decent understanding of what this is styling and of each element.

Intermission

At this point, we’ve organized our styles simply and documented our code fairly well. The level of organization and documentation will be dependent on your company’s code standards and general workflow and preference, but this is generally pretty simple and clean so far. The next missing element in creating a more efficiently styled website is the use of built-in and custom Sass functions and mixins.

Mixins

Mixins allow you to declare some SCSS that you want to reuse throughout the website. You can tie in Sass loops or functions to increase its extendability or functionality, but a general mixin might look like this:

@mixin card-style {
	border: 1px solid $color-gallery;
	background: $color-white;
	padding: 1.5625rem;
}

And then it is used by simply calling @include card-style. This is a quick and easy way of adding easily-reusable styles to ensure that cards are consistent from page to page on your new website. I personally believe that you really shouldn’t vary from these styles for consistency’s sake—you shouldn’t have more than one similar-looking card styles on your site. But in the event that you want to extend this mixin, you could add some additional options, variables, or checks and take that simple mixin to something like this:

@mixin card-style($border: $color-alto, $background: $color-white, $padding: 1.5625rem) {
	border: 1px solid $border;
	background: $background;
	padding: $padding;
}

This will output the same value as the card-style mixin above, but it also offers the ability to provide a custom border, background, and padding values if we like.

The goal here would be to create mixins for global elements or globally-utilized styles and document their usage. This ensures that styles for like elements are consistent, but it also cuts down on the amount of code actually needing to be written; and therefore, cuts down on the amount of time required for a project to some extent.

Extending Your Markup

Mixins are quick and easy, but there are many other ways that you can help quickly style your website by leveraging more complex mixins. Let’s take a look at a mixin that can be used to output presentational background and color classes that we can utilize directly in the markup.

I’d start by creating a new Sass map. Something like this:

$theme-colors: (
	alto: $color-alto,
	black: $color-black,
	gallery: $color-gallery,
	white: $color-white,
);

This gives me an iterable list of colors we can loop through in our mixin, which would look like this at a very simple level:

@mixin colors($colors: $theme-colors) {

	@each $name, $color in $colors {

		// Create background color classes.
		.background-#{$name} {
			background-color: $color;
		}

		// Create color classes.
		.color-#{$name} {
			color: $color;
		}
	}
}

This can be called once and, for each color, generate a background class and color class name for use anywhere in your markup.

<footer class="site-footer background-gallery"></footer>

This would render a selector with a background color that matches our variable.

I should note that my recommendation is that only colors that will be used should be added to this Sass map. Otherwise, you’re left with unused styles in your style sheet just taking up precious bytes of space.

Summation

Really the use of mixins or functions is endless. The goal here is to create as much reusable code as possible. The more you reuse, the more consistent your website will be when it’s built and when you inevitably add or update features in the future. Incoming devs can now leverages a well-documented pre-existing library of styles in which to pull from to help avoid adding new or redundant code into your repo and keeping things clean.

The post Dev Shortie: A Better Process for Styling Websites appeared first on WebDevStudios.

The Basics

Every company should have a style guide. If you don’t, get on that. Within your company, you need to regulate your brand’s outward appearance, but you should also set the guidelines for external companies to use your brand properly. Even more importantly, you need to have a style guide for incoming and existing users and customers alike. Brand recognition is what drives sales and spreads your content around the web and material world.

All brand guidelines should include, at a very basic level, your brand colors, proper use of your logo, icons and images. It should also include any typography or fonts utilized by your company for web and printed materials. These can be as broad or as micro and specific as you would like. But the rule of thumb is the more specific the better, and the few outliers or one-off situations you may have can be resolved when the time comes.

I typically see two types of style guides, although they share many of the same parts. These are print and web style guides. A print style guide will include guidelines specific to the use of logos, colors, type, etc. for print media, billboards, pamphlets, business cards, and other print collateral. A web style guide will be presented the same, but the guidelines are specific to the web. This is because web and print are treated differently in units of measure, how colors are utilized, resolution, etc.

Always take both your print and online presence into consideration. Colors and fonts usually won’t look the same on digital devices as they do on printed materials.

Your Content

The design and execution of your website hold weight, but the content on your website carries more weight in order to properly communicate your brand. The message that you spread to your users or customers needs to be consistent and work to improve and strengthen your company or product image. When people say that something is “on brand,” this is what they’re referring to.

If your content works against your brand or could potentially hurt your appeal in the eyes of your users or just doesn’t apply to your mission, it’s off brand. Users expect consistent content that is fresh or new and information from your company that reflects progress and forward momentum. I’m not talking about tweets or Instagram posts, but blogs, advertisements, reviews, testimonials, or any other content-driven brand exposure.

Keeping in mind that your content reflects your brand accurately, the design that accompanies it and delivery should also be in line with all of your basic design principles. Content is what keeps people around, but the design is what keeps your brand in the zeitgeist, which is especially marked in the world outside your website in places like social media.

Social Media

Social media is a full-time job. It might not seem that way to someone not directly involved with internet communities, but it requires a lot of precision and dedication to grow your online presence and retain interest effectively.

Knowing what to post is less critical than knowing who you’re posting for and why you’re on the particular platform to begin with. Your brand is your brand and that won’t change, but the way you advertise to the public will be based on who you’re targeting. Facebook, for instance, is primarily comprised of women between the ages of 30-49 years, which has drastically shifted older in the last decade. So your strategy will need to accommodate that generation and group.

Twitter’s largest demographic are Millennials, who need a different marketing strategy and perhaps a different brand approach. To skew even lower, if you were to feel the need to advertise on Snapchat, you might find that you need to adjust even more, as their primary demographic is under 34 years of age with the vast majority being 18-24 years of age. Needless to say, you can’t expect the same strategy, content, or brand expression to affect every demographic in the same way.

Do your research and keep in mind that social media is targeted.

Imagery

Imagery is, of course, a must. With the attention of most users being under seconds on average, imagery is a requirement to get a user’s attention and keep it long enough for your content to take hold. There are now dozens of free stock photography websites out there like StockSnap, Pexels, and Unsplash which can help provide a sense of consistent imagery on your website, but I’m inclined to recommend that these be avoided for the sake of your brand.

If your brand is reliant on some sort of imagery, that should be something handled within your company by hiring a professional photographer with a consistent photographic aesthetic. Your brand identity is what makes you memorable, but for general brand aesthetic (business, lifestyle, fun, serious, etc.), your imagery says a lot. That translates over to places like Instagram, if your company utilizes the platform. Consistency and quality are key to providing a great experience for your consumer that informs the content and extends your brand aesthetic.

Clarity

Is your brand then, after taking into consideration your brand guidelines, target demographics, and brand aesthetic, accurately represented on your website? If not, contact us.

The goal to a consistent brand is really having your guidelines set in stone. There should be no wiggle room when your company’s reputation is on the line. Content, imagery, and social media help strengthen your brand aesthetic, memorability, and recognition only as much as your identity is managed properly. If you take only one thing away from this post, it should be that your brand’s style guide is a requirement for successful long-term branding.

The post Website Branding Basics appeared first on WebDevStudios.

Myth: Sliders and Hidden Content Are a Must

At some point in the 2000s, movement became popular in websites. The increasing adoption of JavaScript and libraries like jQuery and MooTools made things like carousels, modals, sliders and other hidden and dynamic content possible. At that time, the internet was concerned with making a splash and pushing the boundaries, not with user experience or accessibility.

Let’s make a resolution right now: no more carousels, sliders, modals or accordions. Think harder about how users interact with the web and your website and make things a little easier for everyone involved.

I often get requests for these elements with the concern that there isn’t enough room on the homepage, or that a user won’t scroll so clients want to add as much information as they can right at the top of a page. Or, they don’t want to muddy up other aspects of the website with the information they deem as less important. It’s not just sliders; it’s modals, accordions, or anything that hides content from the user initially and then reveals it with an action or timeout, or renders content directly with JavaScript.

Here’s the thing—you’re just making a mess for yourself and here’s why:

• These things split user focus. The goal of your website is (or should be) to lead your users to some kind of conversion. Sliders, for example, split the potential funnel from one to many, lowering the potential for direct conversion.
• Your SEO will suffer. Search engines rely on the idea that important website content exists “above the fold.” That is to say that Google’s algorithm expects the important content on a page to be the first thing it “sees” when it crawls your website. Shoving a bunch of mixed content into the top of a page will cause problems as search engines may not be able to determine the focus. Anything being rendered with JavaScript or hidden on load won’t even be seen by Google, and that in and of itself should concern you.
• JavaScript and images take their pound of flesh. Things that load heavy assets like images or JavaScript libraries will, no doubt, hurt you on mobile devices. Unless you know that 100% of your users are all on the best wireless networks with the fastest speed (you don’t know that), you should worry about how much you’re asking your users to load initially. Sliders and large decorative images are just unnecessary assets preventing users from getting to your website. I’ve mentioned this many times in the past, but you have seven seconds for your website to work and just as long to load your website before users will bounce.

You really don’t have to take my word for it. The research is out there. Users never like hidden content and never want to have to hunt for something. The internet would blame designers for these choices, and perhaps that’s true to some extent, but you shouldn’t need to suffer just because “it’s cool.” Before you think you NEED to play hide and seek with your content, let’s think about how else we could accomplish the same thing and save your SEO, load times, conversion rates, and users’ sanity.

Myth: External Links Should Open in New Tabs

All external links should open in a new tab.

Not only is that false, but it’s also bad practice. You may read many other posts online that suggest that this is actually the best practice, but I offer the only two reasons you should have a link open in a new tab:

1. When initiating media like a YouTube video, podcast, or some event that will start a process that moving pages wouldn’t stop.
2. If some function of the website requires it to function properly, and even this is a stretch. Why are you building a funky website that would require that?

The biggest reason I hear that clients want to open external links in a new tab is so that users never leave their website. The problem with that is that bounce rates are part of normal web life, and if your goal is to keep users interacting with your website, you’re actually doing the opposite.

Let me explain:

Opening a link (any link) in a new tab does a few things. It takes control from the user, disables the back button (since you’ve started a new session), removes focus from any conversion funnels you may have started a user down and you end up with a user away from your website anyway. Your website might still be open in another tab or page, but chances are that if they were just checking you out and not a returning user, you’ve lost a conversion because tabs are expendable.

Giving people the ability to return via the back button provides fewer steps to return to your website. And remember, users have the ability to open any link in a new tab, so we should give them that choice. Like I said, this is ultimately up for debate. You’ll find many people saying the exact opposite, but as someone who develops for users with accessibility considerations, this practice feels almost necessary and not something up for debate.

Browsers also behave differently by default. Some may open a new tab in the background which, for visually impaired users, means that they may not know that they’ve been redirected. Some older browsers may open target="_blank" link in a new page altogether and you might have a similar issue. From a purely business-driven sense, if your website doesn’t generate conversions or user interest organically, chances are you have other issues to resolve first.

Myth: Design First, Content Later

If you think content can come after design, you’re automatically setting yourself up for long-term failure. I often hear the words, “let’s get the design flushed out and then we write the content,” and I die a little on the inside. Design should not inform content—content, your users, conversion goals, and all of those things should influence the user interface and all aspects of design.

I wrote about ways to Plan a Website Design Your Users Will Love and content is one of the most important things to consider. Second would be knowing your users, why they are coming to your website, what they expect to find, where they expect to find it. If you try and add content to a preexisting design, you’ll always end up with a website that either doesn’t look as good as the initial design when it launches or ends up having restrictions and issues within the year, guaranteed. Content first.

Myth: Everything Needs to be Above the Fold

I mentioned above that Google expects content “above the fold,” but Google doesn’t see your website in the same way you do. They see a series of strings and markup. No visuals. They DO expect that the your headings hierarchy is set up correctly and that content appears (as far as they can tell) pertinent to the page you’re on.

There are other potential performance considerations around the idea of “above the fold,” but user interactions have changed. People scroll and have a “browse” mentality, which will typically mean that the default behavior on a website is to load and move immediately. Check your analytics and heat maps and I expect you’ll see this.

It is still important to make a big impact for your users when they visit your site for the first time, but you don’t need to inundate them with so much information. Which brings us to the next myth…

Myth: Users Don’t Scroll

They will. It’s natural. All users, even the Luddites, are curious and will scroll or move around your website.

Myth: You Have to Like Your Website

The website isn’t for you. You don’t have to like your website. The website serves a purpose for your company and is targeting your user base. You may not agree with the layout, or design elements, or other aspects of the build, but you need to look at the data. If you’re in your forties and your company intends to appeal to teens, chances are your expectations and sensibilities will differ greatly.

Look at Snapchat. The app is poorly designed. Its interface lacks intuitive markers and requires a steep learning curve, but I’m not the target demo. At 35 and male, I fall just above the vast majority of its user base of females under 34 years of age. Think about your users first and your own personal design preferences very, very last.

Myth: Web Design Is Cheap

Think about all of the services you provide your clients. Think about how you charge, how much you charge, and why you charge those amounts. You’re not giving away your products or services for any less than they’re worth. Good and considered design is the same. A UI/UX designer considers not only the design aesthetic but how users will interact with your website with purpose and help make sure that your company’s goals are taken into consideration. Sure, you can start a website with pre-built templates for a small fee, but will your users get the most out of that experience? Probably not.

Don’t be deterred by the cost of design. Have that conversation nonetheless and hear them out. It will be well worth the cost. I’m sure of it.

The Takeaways

Not all myths are made up. Several of these items above were, at one point in history, common or even best practices. Times have changed. More emphasis has been added to user experience and accessibility. Constant exposure to technology has provided everyone with a default set of interactions and expectations around your website and how it should work. This is one of the main reasons we suggest a website be redesigned or rebuilt every two-five years.

Certainly there are always exceptions to the rule, but hopefully, these myths will no longer impact your website design decisions or expectations and we can all move forward building a better internet for all.

The post Web Design and Development Myths: 2019 Edition appeared first on WebDevStudios.

In Part 1 of this series, we set up a simple app to display our posts using React and Next.js alongside our WordPress install. We left it lacking some extra functionality that would take us from a simple test to a real browser-accepted website. So, let’s get to work on that and really round this thing out.

First up are single posts. We’re going to continue to work in our posts.js and get some links and such working first.

Our main update, like in Navigation.js, will be to import our Link component and wrap each of our post titles.

import Link from 'next/link'

and then

<li key={ post.id }>
    <Link href={ `/posts/${ post.slug }` }>
        <a href={ `/posts/${ post.slug }` }>
            { post.title.rendered }
        </a>
    </Link>
</li>

From here we have links, but they won’t go anywhere.

In fact, if you tried, you’d get the default 404 error from express.

Dynamic Routing

This is where things get a little complicated. Out of the box, Next.js handles direct routing, but dynamic routing is a little bit more complicated. You don’t want to have a component for each of those posts; you want one to handle them all. We’ll need a custom express server to serve the routes and handle all of that for us. Next.js is handling a lot of that for us already, but we’d still need a custom server for the dynamic routes. We could fully integrate React Router into the build, but we’re building something pretty simple here and that might be a bit of overkill.

I’ve decided to utilize a middleware for Next.js called next-routes alongside a custom server to make things a bit easier to understand and less complicated if only a little. So let’s install that:

$ npm install express next-routes --save

From there, let’s create a couple of new files at the root of your project named routes.js and a server.js.

In our routes file, we’ll just import next-routes and add our routes. In this case, we’ll have, as we’ve set up, our index, our posts page, and our new dynamic route for our single posts.

const routes = require( 'next-routes' );

// Setup router.
module.exports = routes()
  .add( 'index', '/' )
  .add( 'posts' )
  .add( 'single', '/posts/:slug' );

Inside our server is a little more complicated. We’ll end up with this:

const express = require( 'express' );
const next    = require( 'next' );

// Import middleware.
const routes = require( './routes' );

// Setup app.
const app     = next( { dev: 'production' !== process.env.NODE_ENV } );
const handle  = app.getRequestHandler();
const handler = routes.getRequestHandler( app );

app.prepare()
  .then( () => {

    // Create server.
    const server = express();

    // Use our handler for requests.
    server.use( handler );

    // Don't remove. Important for the server to work. Default route.
    server.get( '*', ( req, res ) => {
      return handle( req, res );
    } );

    // Get current port.
    const port = process.env.PORT || 8080;

    // Error check.
    server.listen( port, err => {
      if ( err ) {
        throw err;
      }

      // Where we starting, yo!
      console.log( `> Ready on port ${port}...` );
    } );
  } );

From the top:

• Import express (our server environment) and next (important)
• Import our new route file, our middleware
• Set up our app, set environment, and handle our requests—both boilerplate
• Add our handler which utilizes our routes middleware imported above
• Everything starting at app.prepare() will be also pretty boilerplate
  • Set up the server with const server = express();
  • Make sure we utilize our handler with server.use( handler );
  • Add the default route—important for the server to work.
  • Get our current port—not required, but I like setting a default so we don’t have to set a port in our package.json file
  • Add our listener to output errors so we still get errors in our logs
  • Finally, a little message when we start the server to let you know where we should be opening the browser to, in this case http://localhost:8080/

This is generally a pretty light server setup. Google around and check out the express docs, and you’ll probably find something very similar. Play around with it, and you’ll start to get an idea of what’s necessary and what can be updated.

Now, this isn’t going to work yet. We need to make a few updates to our project as it stands already.

In our package.json we’re going to update our dev and start scripts.

"scripts": {
  "dev": "node server.js",
  "build": "next build",
    "start": "NODE_PATH=. NODE_ENV=production node server.js"
},

We’ll just want to run our server directly instead of relying on the server that comes with Next.js. And for our start command, make sure we’re running in “production” mode.

Now running npm run dev will get our app going the same way it did before, but you may find that clicking any of the posts will still 404. This is because we need to add our new single post file.

Single Post Template

Let’s add, inside the pages directory, a new file named single.js. This will just need to match whatever you named your route in the routes.js file:

.add( 'single', '/posts/:slug' )

I’m just going to copy our index.js file just to make sure everything is working as expected:

import Navigation from '../components/Navigation'
import { Fragment } from 'react'

export default () => (
  <Fragment>
    <Navigation/>
    <h1>Your soon to be single post!</h1>
  </Fragment>
)

And they are!

NOTE: If this doesn’t work right away, you can stop and restart your server and that may resolve any issues.

Obviously, we’re not done here. We need to get our current route slug and display the data from a new API request. I’m going to make an additional API request here, just like we did with the /posts page, but get only the post data we need. Typically on a full-blown, React-based website, I’d probably do more to store and check for already-existing data, but in the interest of simplicity, here we go!

From our existing API we know we can get a post, “Hello World” for example, using the slug from our URL: https://wordpress.test/wp-json/wp/v2/posts?slug=hello-world.

So, what we’ll do is make this request and simply save that to props using the same getInitialProps function. Inside that function, we have access to context which we will use to get the current queried slug to make our API request.

So in single.js I’ll do this:

import Navigation from '../components/Navigation'
import React, { Component } from 'react'
import axios from 'axios';
import { Fragment } from 'react'

export default class extends Component {

  // Resolve promise and set initial props.
  static async getInitialProps( context ) {

    const slug = context.query.slug

    // Make request for posts.
    const response = await axios.get( `https://wordpress.test/wp-json/wp/v2/posts?slug=${ slug }` )

    // Return our only item in array from response to posts object in props.
    return {
      post: response.data[0]
    }
  }

  render() {
    return (
      <Fragment>
        <Navigation/>
        <h1>Your soon to be single post!</h1>
      </Fragment>
    )
  }
}

I’ll convert my standard exported function into a class that extends the React Component, set up getInitialProps using context to get our slug, make an API request for our single post, and save that to our post prop. If all went well, nothing on the page should have changed, but we’ll have now successfully made a request for that data.

So, let’s get it rendered. In our renderer() function let’s make some updates, similar but not exactly the same, as our posts.js class using this.props.post for our data.

render() {
  return (
    <Fragment>
      <Navigation/>
      <h1>{ this.props.post.title.rendered }</h1>
      <article
        className="entry-content"
        dangerouslySetInnerHTML={ {
          __html: this.props.post.content.rendered
        } } />
    </Fragment>
  )
}

I’ve outputted my title into the H1, and using the dangerouslySetInnerHTML function, output the rendered content from our data. You’ll find if you just output { this.props.post.content.rendered } directly the content will not be rendered as HTML, so you would see this:

 

As long as we know where our content is coming from, we should be good to go here. So with those updates, we can refresh the page and should get this:

Perfect! What’s next?

Metadata

The one thing missing that will make this experiment a full-fledged website is metadata in our <head>. Things like page title or description, and things like the charSet or device-specific elements (width, name, content, etc), and whether or not we want search engines to see your site are required. Luckily, Next.js has an option for this. The usage is pretty easy.

I’ll do the work in our index.js file, but the same work can be replicated in posts.js and single.js respectively. First, I’ll import Head from Next.js. This gives us access to a new component in which we can add our meta information.

import Head from 'next/head'
import Navigation from '../components/Navigation'
import { Fragment } from 'react'

export default () => (
  <Fragment>
    <Navigation/>
    <Head>
      <title>This is our page title!</title>
      <meta name="description" content="This is an example of a meta description. This will show up in search results." />
      <meta charSet="utf-8" />
      <meta name="viewport" content="initial-scale=1.0, width=device-width" />
    </Head>
    <h1>Your new server-side rendered React.js app!</h1>
  </Fragment>
)

Nothing may look like it would have changed, but you’ll notice a couple of subtle changes.

We now have a page title in our tab:

And our meta description and information show up in the code:

Using next/head this will now render both client- and server-side, so our status as a fully-functioning SSR is intact. We could go one step further and add support for Twitter or Facebook/Open Graph meta also, but that will be on your plate for now.

Where Do We Go from Here?

If all you need is a homepage and some posts, you’re done. Granted, we could refactor and clean things up. Perhaps introduce caching or a data store to make things a little faster, but all in all, this is pretty lightweight as it stands with a pretty nice lighthouse score.

And tackling those deficiencies in performance, accessibility, and best practices wouldn’t require that much more work—just a matter of configurations and a few other files to include.

Past all that, however, you may want something a little more robust to fully replace your existing website. Well, just like any other part of this site so far, you’d need to build it. All of that WordPress functionality, like tag or category archive, search, etc., that’s on you. That would all take time and effort. If you have a plan and the know-how, go for it. I always feel good having built something that didn’t otherwise exist.

There are also plenty of existing frameworks out there with React.js or Vue.js that can accomplish more with varying levels of quality and varying depths of included functionality. So take a look around, and I’m sure you’ll find something that works for you and save some time. If you do find something, remember, it’s always a great idea to give back to the Open Source community and share any new ideas you might have.

WordPress + React Starter Kit

While we’re on the subject, might I recommend the WordPress + React starter kit from Postlight? This framework works in much of the same way that the app we just built does, although it supports more pages and functionality. At the base level, though, it’s a simple Headless React-based website with server-side rendering which supports proper SEO.

Return to Basics

Building an app this way really requires that we return to the basics. My feeling is that a lot of websites include features that are really great in a UX/UI perspective, but also unnecessary for the user to actually navigate or absorb the site—clutter, for lack of a certain term. Not to say that widgets or some of this extra functionality aren’t nice or sometimes useful, but my opinion is that a website should be discussed and planned and executed with finality. Knowing the who, what, why, and how of a website comes in handy when building a React-powered frontend website. Certain decisions need to be made as they’ll most likely be hard coded or the flexibility of the CMS (WordPress in this case) will be ignored.

Want to check it out for yourself? I’ve thrown everything up in a repo you can play around with that you can find here.

What do you think? Is the future of the internet JavaScript? Do you prefer a different framework for building your Headless website? Preact? Vue.js? Do you prefer a different setup altogether? Let us know in in the comments below.

Happy coding!

The post Headless WordPress with React and NextJS (Part 2) appeared first on WebDevStudios.

A little disclaimer: I refer to some of the things below as “easy.” To clarify, none of this is “easy,” but relative to the alternatives they could be considered “easier.”

The future of web development is JavaScript. It’s only natural when you consider the advancements in technology, device speed, and general user desire for more of an all-around, app-like experience. Libraries like Vue.js and React, among others, are leading the charge. You might be thinking that this sounds great. Why aren’t we all doing this? Let’s make the internet better, faster… we have the technology.

Limitations

There are, as is the case with any new technology, limitations. Using JavaScript to build an app for something like a Google Chrome extension or an iPhone/Android or Desktop app is fairly simple all things, considered.

1. You have an idea.
2. You build the thing.
3. You use something like Electron or React Native to get your project in the hands of users.

I say “fairly simple” because you don’t have to necessarily worry about things that are required for a website to exist and for Google or Bing to find it, index it, and validate it.

Currently, Google requires a website to render on the server side in order to crawl the site for content, images, etc., which a pure JavaScript application does not do out of the box—although admittedly, Google is making strides to accommodate JavaScript apps. Also required are metadata, descriptions, title, etc., which isn’t available in the framework by default. I’m of the opinion that reactive JavaScript technology never intended to be used to build a website and only ever expected to be used as an application.

The Benefits of Headless

Other limitations are time and money. We don’t always have the ability to completely rebuild a website infrastructure and database(s) from the ground up. In an ideal world, a clean slate would be the way to go, but for the website that’s been around for 10 years and only needs a face lift, you’re going to spend more time trying to clean up the database than it’s probably worth, truth be told.

Enter the “headlessness” of it all. A headless website means just that—unlike a WordPress website handling the content and site rendering, the database and backend are decoupled from the frontend. More simply, your data lives in one place; your website lives in another. This can be a fantastic way to use your existing website data with a brand new shiny JavaScript website on the frontend. Most web platforms have an API that can be used to access your website’s data, from there, it’s a matter of manipulating that data to your whim. WordPress, for example, has its own Rest API baked into the core which makes it easy to display posts and pages without much fuss.

Of course, downsides exist with a headless setup. Let’s talk WordPress: widgets, themes or settings inside the admin for modifying your website are now void. If you want that feature, you have to build your own thing. If you want access to a plugin or menu data and those don’t have an API endpoint already, you need to make one. Those devs on GitHub that came before offer solutions, or plugins, or code snippets to help you along, but you can say goodbye to a simple ready-to-launch website out of the box. This will now take work.

Is It Worth the time?

I would argue yes. It’s ultimately up to you. If you’re not getting a lot of website traffic, or the entirety of your website consists of four pages and five blog posts, then the answer is no. If you’re consistently looking to improve your ever-increasing site traffic, user experience, speed, and interactivity, then yes.

In either case, if you’re thinking about going headless and decoupling your website in favor of a more future-proof, app-like website, then you should work smart, plan everything, and know what you’re getting into. So, let’s get started.

The Setup

We’ll be building a super-simple decoupled headless website using WordPress and React. In building a website, we have a couple of requirements we need to meet before pressing forward.

• Must be server-side rendered so that our website is relevant to Google
• Needs to be able to route pages the same way we would on any other website
• Needs to be efficient and pass Google Lighthouse testing

Anything else I realize up front, like SEO considerations, we will need to build. I’ll touch on that a little bit, but we’ll save that for another blog post.

Given these requirements of the project, I’ve decided to use WordPress as my decoupled backend CMS and React alongside Next.js to handle the frontend app, SSR, performance, and routing. It’ll be a bit of work, but the payoff will be more than worth it.

Let’s Get Started

First things first, you’ll need to set up a WordPress install either online or locally. You can do that fairly quickly using Local by Flywheel. I won’t get into details here, but there are many options for doing this and many hosting providers that allow you spin up a new WordPress website in a matter of minutes, like WP Engine, for example.

For our new app, we’ll make a new folder so that we can get everything running in a different location from our WordPress install. There are repos and frameworks out there that have been pre-built or pre-configured to handle all of this setup for you, but we’re going to walk through the app step-by-step so that we can fully understand what’s going on.

Let’s get started! Create a new folder and install everything we need and then jump into that folder:

$ mkdir nextjs
$ cd nextjs
$ npm init
$ npm install --save next react react-dom axios

After running those commands you should see a package.json, package-lock.json file, and a node_modules folder.

We’ll replace the test script with some simple scripts inside our package.json file to allow us to easily start our project and build our necessary files.

"scripts": {
    "dev": "next -p 8080",
  "build": "next build",
  "start": "next start -p 8080"
},

NOTE: The -p 8080 specifies that we’ll be using port 8080 instead of 3000 to make sure our app is secure.

At this point, we basically have everything we need to get started. In the next few steps, we’re going to set up our folder structure, set up routing, configure our API request to get posts, and finally toward the end, talk about dealing with metadata.

Folder Structure

Anything inside a pages directory will be treated as a page. Anything inside components will be treated as a component (a non-rendered element). So, let’s add both.

Similarly, although we won’t set this up today, the styles folder could be used to add and compile any new CSS, SCSS, Sass, or LESS files on the fly.

Inside pages let’s add an empty file named index.js which we’ll use as our entry point. At this point, let’s test things out and make sure they are working as expected. Inside that file, let’s add one line of code (longhand):

export default () => {
  return <h1>Your new server-side rendered React.js app!</h1>
}

From there, let’s run the command npm run dev that we added above and visit http://localhost:8080/. If all went well, we should see:

Excellent! Now, let’s move on.

Routing

We’re going to make this pretty simple and just shove everything into a single component for now. Inside our components folder, let’s add a new file and name it Navigation.js. Inside this file we’ll setup our routes. For now, we’ll just provide access to our homepage, our index.js file, and our page of posts that we’ve yet to create. Let’s do that now. Inside pages let’s add a new file called posts.js and add a similar bit of code to separate it from our index.js file.

export default () => {
    return

}

We’ll change this up later, but for now, we’ll use this to make sure our routes are working once they’re set up.

Here’s the final result for our simple Navigation.js router.

import Link from 'next/link'

export default () => (
    <ul>
        <li><Link href="/"><a href="/">Home</a></Link></li>
        <li><Link href="/posts"><a href="/posts">Posts</a></Link></li>
    </ul>
)

We’ll import Link from next/link which is already baked into Next.js. It operates in much the same way that Link from react-router-dom would. We’ll wrap the <a href> in the Link component as directly adding a string to a Link was deprecated, so we avoid some errors here, although, omitting it would still technically work. This is pretty simple now, but we’ll get a little more complicated later on.

Now that that’s done, let’s go back to our index.js and posts.js files inside the pages directory and make some updates.

import Navigation from '../components/Navigation'
import { Fragment } from 'react'

export default () => (
  <Fragment>
      <Navigation/>
      <h1>Your new server-side rendered React.js app!</h1>
  </Fragment>
)

and

import Navigation from '../components/Navigation'
import { Fragment } from 'react'

export default () => (
  <Fragment>
    <Navigation/>
    <h1>Our Posts Page!</h1>
  </Fragment>
)

I like to use Fragment whenever I can to avoid unnecessary extra markup. The function only needs a wrapping parent element, but a div would work just fine.

We end up with something like this:

Not pretty, feel free to add some style objects to make that a bit nicer, but for now, it works, so we’ll go with it. If you’re still running your project via npm run dev you’ll find that if you click “Posts” you’ll see your posts page you created earlier:

Our URL is updated and our content is dynamically updated. This is a fairly simple use of routing and all we need to get things working. I’d suggest, however, to avoid having to call your Navigation component on every new page you make, look into the React Router Docs to see how you might be able to extend its functionality.

Let’s Get Our Data

So we’ve set up our simple app, we’re rending both server- and client-side and we’re routing, very simply. Before we can get into building our app further, we need to get our data from our WordPress install we set up at the top.

Now, I’m going to use a package called Axios to make API requests. React docs recommend using fetch, but I’m not a huge fan specifically since there are some compatibility issues and some extra steps involved in those requests. Axios has graceful fallbacks for older browsers and takes the guesswork out of making an API request. It makes things more, for lack of a better term, simple.

We’ll be making our API request inside the posts.js file we created.

First, I’ll import axios and react:

import axios from 'axios'
import React, { Component } from 'react'

If I were building a more complex website, I’d probably think about writing reusable functions for things like this, but for sake of clarity, I’m going to have each route make a request.

Next, I’m going to convert my default function into a class that extents React.component so that we can set our initial props (our API data) and render our component—the stuff we’ve already built.

import Navigation from '../components/Navigation'
import React, { Component, Fragment } from 'react'
import axios from 'axios'

export default class extends Component {

  // Resolve promise and set initial props.
  static async getInitialProps () {

    // Make request for posts.
    const response = await axios.get( 'https://wordpress.test/wp-json/wp/v2/posts')

    // Return response to posts object in props.
    return {
      posts: response.data
    }
  }

  render() {
    return (
      <Fragment>
        <Navigation/>
        <h1>Our Posts Page!</h1>
      </Fragment>
    )
  }
}

I’ve moved my original default function into the render function.

Let’s break down the API request.

// Resolve promise and set initial props.
static async getInitialProps () {

  // Make request for posts.
  const response = await axios.get( 'https://wordpress.test/wp-json/wp/v2/posts')

  // Return response to posts object in props.
  return {
    posts: response.data
  }
}

I need to make sure to make an async request, and resolve the promise we’ll get via axios and then assign that data value to a prop that we can access inside our render function.

We will then access that data inside our render function as this.props.posts. And we’ll use some JSX to output each post title into a list.

render() {
    return (
      <Fragment>
        <Navigation/>
        <h1>Our Posts Page!</h1>
        <ul>
          {
            this.props.posts.map( post => {
              return (
                <li key={ post.id }>{ post.title.rendered }</li>
              )
            })
          }
        </ul>
      </Fragment>
    )
 }

For now, we’ll just output a simple list of rendered titles and end up with something like this:

Fantastic! So let’s take a look at our final posts.js file:

import Navigation from '../components/Navigation'
import React, { Component, Fragment } from 'react'
import axios from 'axios'

export default class extends Component {

  // Resolve promise and set initial props.
  static async getInitialProps() {

    // Make request for posts.
    const response = await axios.get( 'https://wordpress.test/wp-json/wp/v2/posts' )

    // Return response to posts object in props.
    return {
      posts: response.data
    }
  }

  render() {
    return (
      <Fragment>
        <Navigation/>
        <h1>hOur Posts Page!</h1>
        <ul>
          {
            this.props.posts.map( post => {
              return (
                <li key={ post.id }>{ post.title.rendered }</li>
              )
            })
          }
        </ul>
      </Fragment>
    )
  }
}

What’s Next?

From here, we’ve done what we aimed to. Headless application? Check. Server-side rendered? Check. Routing? Check. That said, what we’ve built really doesn’t provide a final product, something like what you would expect to see. You might, for example, expect to be able to click one of those posts and read the content or expect the title in the tab to change based on your route, or for the head description to change, or for any content that exists behind the scenes update as we navigate through our app.

We’ll take a look at that in Part 2.

The post Headless WordPress with React and NextJS (Part 1) appeared first on WebDevStudios.

The future of WordPress is in flux right now and the platform that was introduced to us in 2003 is barely recognizable by comparison. It’s taken fifteen years to get us to Version 5.0. Arguably, progress has been slow.

It could also be argued that perhaps the internet landscape hasn’t changed as much as it sometimes appears to have changed in that time. I thought it’d be good to examine the future of WordPress, how it got started, how it evolved, and to see where we’re going and why.

2003

The year was 2003, 5-hour ENERGY had just hit the market and WordPress was born from the ashes of a dying/dead B2 Cafelog, a super-basic-early-aughts blogging platform. It was nothing fancy, although a lot of the original functionality exists to this day like posts, categories, templates, etc. I found nothing to suggest at this moment in history Matt Mullenweg or Mike Little had any mission with WordPress other than to resurrect and improve upon the B2 Cafelog platform.

2004

It was the year of “Napoleon Dynamite” and progress. WordPress starts to take off and become the platform we know today. The ability to add and create plugins was added to the WordPress Core and seemingly made open-source look cool. A few other features were added like drafts and private posts, but the main takeaway from this year’s releases was plugins.

2005

Gwen Stefani gave us “Hollaback Girl” and this was the year I got involved with WordPress. Early that year, themes were introduced. This was what set WordPress apart from the other players in the game—the first real and legitimate ability for developers to customize their new blog at the code level. Before this, there was some minor ability to customize, but not to the extent that Kubrick did.

2008

From 2005 to this point in history, there were minor updates but no major movement. I consider this three-year gap the first lull in WordPress progress. The internet changed a lot, but was also still in its infancy and getting its footing during that gap and was waiting for something new to happen. 2008 was the first introduction, with the help of Happy Cog, of the WordPress admin dashboard the way we think of the admin dashboard today… although very much Web 2.0, which was fitting because it was the release of WordPress version 2.0 that added this new interface.

This was the first real shift toward WordPress as a platform and a company as we know it working toward a WordPress as a CMS which, as of this point in history, WordPress was insistent it was not.

2010

A lot happened in 2010, but the main takeaway from this year was the release of WordPress Version 3.0. This version of WordPress introduced more CMS-like features like custom post types, taxonomies, etc., and the previously separate Multisite functionality was officially available in Core. This release also came with the first year-branded WordPress Core theme: Twenty Ten.

2011-Early 2017

From to 2011 to early 2017, any releases were essentially updates, such as feature improvements and new functionality all geared toward making WordPress more robust and developers’ lives easier. Things like mobile-responsive interfaces, TinyMCE/Post Editor updates, and the Theme Customizer were added, but nothing that really shook the foundation of WordPress. This was what I consider to be the second lull in WordPress history.

Mid 2017 and Beyond

In June of 2017, WordPress released Version 4.8 which brought us a taste of the Project Gutenberg, a new post editing experience that has me a little conflicted. Gutenberg provided a new and more modern writing experience, something that I believed that WordPress so desperately needed. Nothing much more changed with the admin or other aspects of Core, per se, other than this. Gutenberg wasn’t yet part Core at this point but was provided as part of an optional plugin, and messages to try it out began with Version 4.9 since it was set to be merged into Core with Version 5.0, which released on December 6, 2018.

The Response

Gutenberg was met with generally unfavorable reviews and currently has about 2.5 stars with over 1,500 reviews. Shortly after it’s announcement, articles like “Please Don’t Include This in WordPress Core” and “WordPress, What Were You Thinking!?” spread like wildfire. I found far fewer positive reviews of Gutenberg, though they did exist, calling Gutenberg the long overdue update WordPress needed.

The main criticism was (and perhaps still is) that it was riddled with bugs and just wasn’t ready for public review yet. I have my own personal opinions about Gutenberg. For example, its use of React, its abstraction, and the way things have gone down with WordPress and organization of that project caught my attention, but I chose to reserve my comments until after WordPress version 5.0 was released.

As far as I can tell, there are two perspectives of Project Gutenberg: the user and the developer. The user will experience a better, more modern interface for writing content. Assuming it works as expected, this should be quicker, more visually in-line with what exists on the frontend of the website (something that was never all that easy to achieve for users in the past).

For developers, such as myself, we are viewing this as the first real and major shift in WordPress Core history. Up to this point, WordPress has more or less remained the same for nearly fifteen years, improving for sure, but there hasn’t been a fundamental change in the way developers would build or interact with websites in this way.

What is Gutenberg?

I touched on this briefly, but the goal of the project is to “impact the entire publishing experience including customization,” and as Matt Mullenweg explained:

The editor will create a new page- and post-building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery. — Matt Mullenweg

The updates only really affect the post editing experience as of now, but anything I’ve read up until this point suggests that Gutenberg could influence every aspect of WordPress into the future.

Gutenberg provides users with “Blocks” that allow various out-of-the-box functionality that gives them more control over how information is laid out and what information a user has access to. Gutenberg comes pre-installed with several “Common” blocks:

• Paragraph — standard WYSIWYG field.
• Image
• Gallery
• Heading
• Quote
• List
• Cover Image — essentially a hero image.
• Video
• Audio
• Custom HTML
• Table
• Pull-quote
• Verse
• Preformatted Text
• Button
• Columns (beta)
• More Link
• Page Break
• Spacer
• Separator
• Various Widgets
• Various Embeds

Everything that comes out of the box with Gutenberg can currently be added in the standard WYSIWYG/Tiny MCE editor that exists in WordPress Core. The only real difference is that instead of writing and adding elements in-line you’d need to add a new block. This makes the writing experience, in my opinion, a little more disjointed, but also forces a bit more consistency from post to post, which I also believe is infinitely important and needed in current web design.

The Controversy

Nobody likes change. When Apple changed their 30-pin connector to the lightning port people were in an uprise until they actually used it with any regularity. It ended up being a good thing. I think that’s where we’re at with Gutenberg right now. I think the controversy is mostly centered around accessibility. This idea of “WordPress for all” no longer seems to apply to Gutenberg. As far as I’m concerned, it’s still a work in progress. That said, I can understand the concern of the current state of the platform.

The Future of WordPress

The future of WordPress’ growth will come down to the next several months and how public outcry about Gutenberg is handled. No doubt they have the best intentions in mind and have goals they’d like to accomplish, but determining whether or not this step is the right move for the future of the platform is up in the air. It’s obvious to me that people are itching for a change. WordPress as a platform is far less robust than something like Squarespace or Weebly, as far as user interaction is concerned, but those platforms are also proprietary and closed-source, not to mention far more complicated than they probably need to be.

Gutenberg is for sure far more complicated than any previously-proposed feature of WordPress and that will take some getting used to. Nothing anymore is as simple as it used to be. The internet is far more robust and complicated than it was in 2003. This may, and I’m banking on it, be the beginning of an internet that no longer allows for just “easy,” but rather strives for “better.”

The post The Future of WordPress: Where We Started and Where We’re Going appeared first on WebDevStudios.

Here are 13 reasons why it’s time.

1. Your Branding Has Changed

The most obvious reason for a redesign is that your company’s identity has changed.

Circumstance: You throw some dollar bills at a new logo or a new suite of fancy printed materials. That’s fantastic, congrats, but your website still reflects your old logo or brand materials.

New identity updates are a great time to unveil a sparkly new website to go along with it. In an ideal world, you roll out everything all at once. But in the real world, you can roll your brand updates out in phases. Either way, get it done; update your brand 100% or not at all. Discrepancies can hurt your bottom line and brand awareness. If you’ve made any updates to your brand that fundamentally changed the way the public perceives your company, you need a new website.

2. You Didn’t Think “Internet on Mobile Devices” Was Going to Be a Thing

Let me tell you a little story. Back in 2007, I had a client that had just rebuilt their entire website—spent the time and money to re-infrastructure their entire site from the ground up with a new design, new sitemap, and new SEO efforts. The thing looked pretty good. Despite the fact that responsive internet had been a thing for a few years at that point, he was certain that “mobile internet was just a fad.” A few weeks later, the first generation iPhone was released, cementing mobile internet and the need for a 100% responsive website.

Don’t be that guy. You don’t have to chase trends, but you need to be aware of how and where your website is used. Having a mobile-ready website has never been more important than it is today. As of Q3 of 2018, mobile traffic represents more than 52% of all internet traffic. You cannot afford to not have a mobile-ready website. If your website looks the same on your smartphone as it does on your Windows 95 desktop, you need a new website.

3. I Have a Collection of Snails Faster Than Your Website

I’ve mentioned this before on previous blogs of mine, but you have, at most, seven seconds for your website to load and grab your user’s attention before they’re likely to just bail altogether. With mobile traffic being so important, that number is even more important on slower mobile internet speeds—3G for example. Internet that slow really depends on your target demographic, but you get the point.  Google’s Lighthouse will test for this. I really don’t feel that I need to get into the details; it’s pretty self-explanatory. If I can sing the entire Wicked soundtrack before your website loads, you need a new website.

4. Half of Your Pages 404

I get it. The older your website ages and the more content you add, change, or remove, the more of a mess you make. It’s inevitable and expected. You can only do so much. The problem is that most users don’t understand or even care about the finer points of URL redirection or what a 301 code is. If your URL, according to the search engines, directs users to a web page that doesn’t exist, your website is broken and needs an audit. Nine times out of ten, you can resolve and redirect those URLs just fine without much problem. But if you have more 404s than you have pages, it’s time to burn your website down, treat yourself to a new one, and account for all of those 404s in your rebuild.

5. I Just Can’t Find Anything!

I’m talking specifically about organization and flow. Current website design trends take into consideration the philosophy that “less is more,” and the direction/navigation/call-to-actions should be clear and easily accessible. Ten years ago, it was popular to use fifteen content sliders, forty-seven modals, and paragraphs for days. Today, that’s not the case. I might argue that your website content needs an overhaul before you get a website redesign. It’s important to make sure that your users are finding what they need and are spending time on your website. If your Google Analytics tell you that your bounce rate is high (roughly 56-70%+), you might need to take a good hard look at your website. Pour yourself a celebratory glass of shandy because you need a new website. And… it… will… be… glorious!

6. You’ve Been Hacked More Than Zero Times in the Last 10 Years

Okay, that’s a low bar. Chances are that everyone has been hacked in one way or another over the years. Security and vulnerabilities pop up on the regular. However, if your site leaves you at risk of any privacy or security intrusions, you should take a look at your setup. Technologies that are typically considered “legacy” often slow down on active development or security patches. Look at what your website is built on and whether or not there are reported issues with it. Even older versions of WordPress can leave you vulnerable, so always err on the side of updating. They’re constantly looking to keep you safe with fairly-continuous active development, especially when security and privacy are concerned. If you:

• Can’t update your website’s framework
• Don’t know what your website is built on
• Have been hacked in any way in recent years
• Are unable to find a security statement from your host provider
• Require a 3.5″ floppy disk to save your new blog post

You need a new website.

7. TL;DR

Your website has too much content. No way I’m going to get through all that. Too long; didn’t read, and I guarantee that most of your user base is in the same boat. The only acceptable place for larger amounts of content are white papers, articles and blog posts, and even then, within reason. I’m busy. I have things to do, important things; I don’t have all day to absorb 22 pages of your thoughts on spreadsheet data entry. Your content really needs to be quick, targeted, well-articulated and broken into easily digestible parts.

*Pause for digestion.*

Your About page doesn’t need a 52-page dossier on your company’s history. I need to know simply: who, what, when, where, why, and your goals for the future. I might need a little info on each of your “notable” employees or information about your location, if that’s important. But if a page on your website takes more than five minutes to read (fifteen for articles), it’s too long. You need a good hard look at your content and to think about a new website.

8. I Can’t Find You on Any Search Engine

We all know that search engine results rankings are important. If you don’t show up on the first page or two, you’re likely to get lost on the internet. But choosing the best inline-keywords only goes so far, and in fact, I’ve still seen websites that utilize meta keywords which were deprecated some time ago. The truth of it is that so much more goes into determining where you fall in search results and how search engines find your website in the first place. As long as you’re updating your content continuously, you should be considered relevant to search engine spiders.

If search engines can’t find you, my bet is that your website doesn’t adhere to web standards, isn’t accessible, or isn’t set up in such a way that search engines can make sense of the content enough to properly rank you. This is probably more than a content issue. This could be a systemic issue that needs to be resolved. If you’re doing all you can to boost your rankings and are failing, I think it’s time you rebuild your website.

9. Your Goals Have Changed

This one is less obvious if you’ve been looking at the same website, or been with the same company for a while, but still important. You might have a relatively up-to-date website, maybe to match your new branding, but perhaps your demographic shifted after that rebrand, or you’ve pivoted to combat market changes. Either way, if your website is no longer effective at capturing users, it might be time to redesign or rebuild. There are lots of platforms out there to test before you commit, like Optimizely for A/B testing, and dipping a toe in the internet waters to find the best solution for your target. The important thing is that you keep an eye on your analytics and conversions, test, and if you’re not able to achieve the results you need with what you have, you might need a new website.

10. Your Website Looks Like a Vision Board

We all made those when we were kids, right? A collage of magazine cutouts and old receipts from Chuck E. Cheese’s would declare our intentions for the future. It works in that setting, since the idea of “putting it out into the universe” is all that’s required. We could make it as messy and overlaid as we wanted. On the internet, however, clarity is key. If your website resembles a vision board, you’ve got some issues to resolve. Chances are you’re dealing with “bad code” or “old code” that can be fixed with a little TLC and some elbow grease. Take some time to organize your content a bit better, reorganize, and clean things up. But if despite your intervention, your website just ends up looking like a Jackson Pollock painting, you have deeper problems that would probably take more work to dig through and fix than it would to start over. It might be time for a new website.

11. Your Website is Almost Back in Style, and Not In a Good Way

We all remember the old Geocities websites. No real conventions had been set in place yet, and the options were quite literally endless—tables and GIFs and Marquees, OH MY! Design trends have evolved over the years quite a bit, though we’re starting to see a trend into brutalist websites, which really plays off of what is acceptable and unacceptable on the web and challenges the currently accepted conventions. It does what any art movement does, questions the status quo. That said, your crappy website is not back in style, even though it looks that way. Under the brutal exterior, these sites utilize the current trends in code development, understand security and performance, and follow the rules required for search engines and users to find the site in the first place. Your website belongs back in 2001, but if you just LOVE that style, rebuild it right and get on the brutalist train.

12. Your Website Is More Than Four or Five Years Old

This one’s simple. Things change. Quickly. If your website is more than even a couple years old, I’d consider giving it a face lift. If it’s older than that, it’s time for a redesign and rebuild. At a certain point, band-aids, patches, and face lifts, like with people, don’t turn out great. You most certainly do not need all those flashy bells and whistles that you saw on the Awwwards website, but you do need to catch up, stay current, and rebuild your website to last you another several years, at the least. You owe it to your brother’s bratty children.

13. It Just Looks Old. You Know It’s Time.

Sometimes you just know. Maybe you don’t know why, but you know it’s time. It could be a combination of any of the things above, or it just feels outdated. Maybe it is heavily skeuomorphic circa Apple 2003 or just hasn’t been touched in a few years. I personally revamp my code base or website design every year. Things change way too fast to keep up with the current trends, and frankly, why would I want to? I don’t need a fad website, I need a future-proof website.

So, Let’s Get Going…

Before you take a drive to rebuild-town, use your best judgment. Audit your website, your content, and your sitemap. Take a look at your goals, your SEO, and your bounce rates. Compare your brand and your website. If you don’t like what you see, feel confused or uncertain of what you’re looking for, or you just need a second pair of eyes, we can help. Just give us a shout.

It might be time to rebuild your website.

The post 13 Reasons Why It’s Time for a Website Redesign appeared first on WebDevStudios.