Slick parallax scrolling One Pager with an interactive project list for designer, Tom Treadway.
by Rob Hope via One Page Love
Thursday, April 27, 2017
5 Technical SEO Traps to Dodge
This article is part of an SEO series from WooRank. Thank you for supporting the partners who make SitePoint possible.
Search marketing can bring lots of benefits to your business and provide great marketing ROI. If you do it right, organic search provides you with a high-quality source of qualified traffic. However, SEO is much more than keywords and links. There are lots of technical aspects to SEO that, if you’re not careful, can trip you up and keep your site from performing as well as it could.
Here are five of the most common or trickiest to diagnose technical SEO mistakes you should avoid on your website.
Overzealous Robots.txt Files
Your robots.txt file is an important tool for your website’s SEO, and an integral part of making sure your website is properly crawled and indexed by Google. As we’ve explained in the past, there all sorts of reasons you wouldn’t want a page or folder to get indexed by search engines. However, errors in robots.txt files is one of the main culprits behind SEO problems.
A common technique to mitigate duplicate content issues when migrating a website, disallowing entire servers, will cause whole sites not to get indexed. So, if you’re seeing a migrated site failing to get traffic, check your robots.txt file right away. If it looks like this:
User-agent: *
Disallow: /
You’ve got an overzealous file that’s preventing all crawlers from accessing your site.
Fix this by getting more specific with the commands you issue in your file. Stick to specifying specific pages, folders or file types in the disallow lines like so:
User-agent: *
Disallow: /folder/copypage1.html
Disallow: /folder/duplicatepages/
Disallow: *.ppt$
Of course, if you created the original robots.txt file as part of your website migration, wait until you’re done before you start allowing bots to crawl your site.
Inadvertent NoIndex Tags
The meta robots tag goes hand-in-hand with the robots.txt file. In fact, it can be wise to double up by using the meta robots tag on a page you’ve disallowed via robots.txt. The reason is that robots.txt won’t stop search engines from accessing and crawling a page it finds by following a link from another site.
So it could still wind up indexing pages you don’t want crawled.
The solution to this is to add the meta robots noindex tag (also known just as the noindex tag) to pages you really, really don’t want indexed. It’s a simple tag that goes in a page’s <head>:
<meta name="robots” content=”noindex”>
Again, there are plenty of times you’d want to use the meta robots tag to prevent a page from getting indexed. However, if your pages aren’t getting crawled (you can check this using the site: search operator in Google), this should be one of the first things you check.
If you’ve used the site: search operator to check the number of pages you have indexed and it’s way below the number of pages you actually have, it’s time to crawl your site. Use WooRank’s Site Crawl feature to crawl your pages. Then, click on Indexing. Pages that are disallowed via the meta robots tag will be listed here.
No problems with meta robots here. Nice.
Unoptimized Redirects
No matter how much you try to avoid using them, 301 redirects are sometimes necessary. 301s (and now 302s) enable you to move pages to new locations and still maintain link juice, authority and ranking power for those pages. However, 301s can only help your site’s SEO if you use them correctly. Implementing them incorrectly, or setting them and then forgetting about them completely, will deteriorate your user experience and search optimization.
Continue reading %5 Technical SEO Traps to Dodge%
by Stephen Tasker via SitePoint
How to Set CSS Margins and Padding (And Cool Layout Tricks)
This article was peer reviewed by Dave Maxwell, Adrian Sandu, and Panayiotis Velisarakos. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!
When I was just starting to learn CSS, the margin and padding properties always confused me. They seemed very similar and in some cases appeared to produce the same result.
In this tutorial, you will learn the difference between CSS margins and padding and how these properties affect the space between elements on a webpage. We will also discuss margin collapsing, the effect of using different units while creating responsive websites, and conclude with some layout tricks you can do with CSS margins and padding.
The Box Model
Elements in CSS are represented as a rectangular box. The size of this rectangular box is determined by the element's:
- Content
- Padding
- Border
- Margin
The content area of an element lies in the middle of the element. The padding surrounds the element's content . The borders in turn surround the padding. The margin of the element is its external layer, i.e., it lies outside the element.
The following diagram should make the arrangement clearer.
As apparent from the diagram, the padding of an element is the layer that extends from the outer edge of the element's content to the inner edge of its border. This property is used to control the spacing between the element's border and its main content. The padding applied on an element affects its size on the webpage. It does not affect the distance between different elements on a webpage.
When you want to increase or decrease the amount of space in-between elements, you should use the margin property. The margin applied on an element won't have any effect on its size.
One important thing related to boxes that you should keep in mind is that the sizes of all the boxes on a webpage depends on the box model being used. There are two different box models:
- W3C box model
- Traditional box model
See the Pen Choosing a Box Model by SitePoint (@SitePoint) on CodePen.
The W3C box model considers the width of the element to be equal to the content of the box excluding its padding and border. Padding and border are added on top of whatever dimensions you set for the element, which could have some unpredictable consequences on your page layout.
For example, let's consider a box with a width of 200px and a height of 200px, padding of 10px on all sides and a border of 2px all round. The browser does not see it simply as a 200px box. Rather, the browser calculates the horizontal space necessary to display the box as being 224px: 200 (width) + 2 (left border) + 10 (left padding) + 10 (right padding) + 2 (right border) = 224px. Given that the element is a perfect square, the height will also compute to 224px.
On the other hand, the traditional box model considers the width of the element to be equal to the sum of the content, padding and the border applied to the box. On the layout front, this means that, if your box is 200px wide, the browser computes the horizontal space it needs to display the box as being 200px wide, including padding and border. This yields more predictable results and it's easier to work with.
All browsers use the W3C box model by default. You can choose to specify the box model explicitly by setting the value of the box-sizing property to either content-box (W3C box model) or border-box (traditional box model). The traditional box model, being more intuitive, is the most popular approach among web developers.
Here is how you can set the box-sizing property to follow the traditional box model on your web project:
[code language="css"]
html {
box-sizing: border-box;
}
*, *:before, *:after {
box-sizing: inherit;
}
[/code]
If you learn best by doing, try experimenting with this fun interactive demo by Guy Routledge.
Setting Margins and Paddings
You can control the padding applied to the four sides of an element using the padding-top, padding-right, padding-bottom and padding-left properties. You can also specify the padding using the shorthand padding property.
-
When a single padding value is present, CSS uses this value to determine the padding of all four sides:
[code language="css"]
/* all four sides */
padding: 10px;
[/code] -
When two values are present, the first value determines the top and bottom padding and the second value determines the left and right padding:
[code language="css"]
/* vertical | horizontal */
padding: 2em 4em;
[/code] -
When three values are present, the first value determines the top padding, the second value determines the left and right padding and the third value determines the bottom padding:
[code language="css"]
/* top | horizontal | bottom */
padding: 1em 20px 2em;
[/code] -
When all four values are present, they set the top, right, bottom and left padding in this exact order:
[code language="css"]
/* top | right | bottom | left */
padding: 10px 10% 2em 15%;
[/code]
In the following demo, the orange background represents the content area of different elements and the white area between the borders and the content area represents the padding that we applied on each element:
See the Pen Setting Paddings by SitePoint (@SitePoint) on CodePen.
Just like with padding, you can control the margin applied to the four sides of an element using the margin-top, margin-right, margin-bottom and margin-left properties. You can also specify the margin for all the four sides of an element using the shorthand margin property.
[code language="css"]
/* all four sides */
margin: 10px;
/* vertical | horizontal */
margin: 2em 4em;
/* top | horizontal | bottom */
margin: 2em auto 2em;
/* top | right | bottom | left */
margin: 10px 10% 2em 15%;
[/code]
Things to Keep in Mind
Continue reading %How to Set CSS Margins and Padding (And Cool Layout Tricks)%
by Baljeet Rathi via SitePoint
Functional Programming with Phunkie: Funky Parser Combinators
Phunkie is a library with functional structures for PHP. In this tutorial, Phunkie creator Marcello Duarte, head of training at Inviqa, explains how to create Parser combinators using the functional library. This post first appeared on the Inviqa blog, and was republished here with their permission.
Learning functional programming
Functional programming really matters. Pure functions (or functions with no side effect) are the perfect units of behaviour because we can rely on them to build larger and more complex systems. The greatness of functional programming relies on this power of composability.
That’s something I first came to believe back in the days of my licentiate degree on Computing for Management, during a semester in AI with Lisp. My course curriculum was mostly focused on C/C++, therefore I had to stay focused on where the skills demand was.
Thankfully, I’ve been able to reignite my love of studying functional programming here at Inviqa where we’re delivering more and more projects based on Scala, the general purpose programming language.
I’ve read "the red book" about three times (the Chiusano & Bjarnason one, not the Vaughn Vernon’s one). I took all the Martin Odersky’s Coursera courses, and I spent hours of my weekends watching videos and reading papers.
And I set myself a challenge: to do with functional programming what I did when I was learning TDD and created PHPSpec (a BDD testing and design tool for PHP developers) to help me learn; I decided to write my own functional programming dialect in PHP. And so Phunkie was born!
Now over to you. Learning functional programming means immersing yourself in a new paradigm, which can be challenging. It requires a totally different mindset for approaching problems.
So, by the time you can use functional programming to solve real-world problems, you’ll have spent hours grasping the new thinking or getting clued-up on the theory.
In this tutorial, my aim is to help fast-track your journey by going over my implementation of Hutton & Meijer’s Monadic Parser Combinators. Hopefully you will be able to see both the thinking and the usefulness of functional programming.
And, by using Phunkie, you can eliminate the need to learn Haskell to understand the topic. All you should need is some familiarity with PHP.
So let’s get started!
Continue reading %Functional Programming with Phunkie: Funky Parser Combinators%
by Marcello Duarte via SitePoint
6 Unexpected Mistakes That Keep Developers from Getting a Raise
Good performance is never enough.
Imagine working hard. You have an "above average" track record. You've never heard complaints — you even won the coveted "best employee" award last month.
So, your company decides to reward you by...
Demoting you.
Sounds bizarre and untrue, doesn't it? Who'd be thick enough to punish an employee for doing a great job?
Doing a Great Job Isn't Enough
AntarcticGorillas, a StackExchange user, shared the story above. He was genuinely frustrated because he did everything he was supposed to do, but ended up getting demoted instead.
Another StackExchange user dishes out some advice.
"Wow sounds like you failed to play the office politics game effectively. Good performance is never enough. You don't play the game and you lose, 100% of the time if you are in management."
He takes his bad advice even further.
"Ok now you have to salvage what is left. First, and I know you are going to hate this one, you have to make friends with your new boss. You have to get him to mentor you. You have to help him and not show your resentment. Yeah I know you resent him, you wouldn't be human if you didn't. But this is the time to take the high road. This guy clearly has the office politics down pat, you need to learn from him."
His advice is partially true. Good performance isn't enough. It's the baseline.
His advice to lie and manipulate? That stinks. But it isn't the worst part. It's the belief behind it.
I'm a _ Worker, I Deserve a Raise
As employees, we have the tendency to think we "deserve" it.
Developers do a great job. Most of us do everything we're supposed to do. Still, many are disappointed with the money they're making.
We know that many employers do their best to underpay. They walk a fine line, giving just enough to keep us on board, without affecting the profit margins they want.
It seems like your boss takes advantage of you.
You're working your hands to the bone. You're doing everything you're asked to do and more. When your company's in a bind, you deliver. Last minute updates? You get things done. Issues with scope creep? You handle it masterfully.
When you don't get the raise you deserve, it feels like an insult.
More often than not, the issue has less to do with your work performance and more to do with the intangible details. Behaviors and counterproductive decisions that alienate allies, partners and opportunities. These mistakes make it harder to get the raise we're hoping for.
Social conditioning leads many to ignore this stuff. "Ugh! Soft skills," you might say. But these unexpected, common mistakes impact raises every day.
Mistake #1: What I Deserve vs What I Want
There's a growing problem that's slowly eroding good will in the developer community.
Entitlement.
Open source entitlement is a great example. It goes like this:
- Developer needs code to solve a problem
- Developer finds open source code. It solves the problem
- Code creates problems
- Developer becomes angry, demands authors fix now. (For free!)
It's an oversimplification but it conveys the point. These open source authors aren't at our beck and call. It's a terrible idea to demand extensive tech support, then write angry letters when we don't get our way.
Mattias Petter Johansson over at FunFunFunction dives deeper into "developer entitlement."
When we feel entitled, we overestimate our abilities and our contributions. We swallow the lie our ego feeds us. "You deserve this. You're a senior developer after all." Developers with this mindset are bargaining on the wrong side of the tracks.
Here's how your boss thinks about raises.
"Holy crap, this is the guy that 10x'd our leads and sales in 18 months. The app he developed turned things around for us. We're going to need to spend more if we want to keep this guy."
See the difference?
They're not operating from an entitled mindset. They're approaching your raise from a transactional mindset, namely...
What am I getting for my money?
We're not entitled to a raise. We're not entitled to a promotion. Yet developers continue to approach salaries and promotions from an entitled mindset. I did a good job this year so, you "owe me."
They usually make their approach like this.
Which is the part where managers give their blunt and unsatisfying answer.
Nope.
Mistake #2: Being Right vs Being Respectful
Justin Keller, entrepreneur, developer and founder of San Francisco startup Commando.io wrote an open letter to the mayor. He was upset about the homeless in his community.
He didn't want to see them on his way to work.
"The wealthy working people have earned their right to live in the city. They went out, got an education, work hard, and earned it. I shouldn't have to worry about being accosted. I shouldn't have to see the pain, struggle, and despair of homeless people to and from my way to work every day. I want my parents when they visit to have a great experience, and enjoy this special place."
Maybe he didn't mean to convey feelings of contempt and condescension. But, his words were still hurtful and disrespectful.
He had a point.
No one wants to live in a neighborhood filled with homeless people. Homeless people don't want to live the way they do. We're human, it's normal to dislike these things.
Those who can avoid it, do so. Those who can't, endure it.
The general thrust of his argument is this: He doesn't want to deal with the problems that homeless people bring. Okay. But that's not really the problem here.
It's the othering of a group or type of people he views as beneath him.
That's the problem.
Developers struggle with the very same issue. As a developer, you're typically sure about your views. You're logical and precise. You're right and you know it, which is part of the problem.
You have a choice to make.
- Be right. You can show everyone that you are, in fact, correct. That your way is right. This comes at a steep price if it's handled poorly.
- Protect the relationship. You can treat others with respect, avoid humiliating them and allow them to save face when they're wrong.
Developers who focus on being "right" tend to be disrespectful. They burn allies and earn enemies.
Developers who focus on relationships first, discover their influence grows with those around them. They're viewed as trustworthy, and more people listen when they have something to say. Being right is easy when everyone values your feedback.
Getting that raise or promotion is tough if you're viewed as a snobby, know-it-all jerk.
Mistake #3: My Career vs My Loyalty
Google has been at the top of Fortune magazine's list of best companies to work for every year since 2007. The job perks are legendary. For many, a spot at Google is a dream come true.
So why is Google struggling to keep its employees?
A recent report by PayScale states the median employee tenure at Google is a little over one year. Its workforce has grown, but it's struggling to keep its people.
It's not because Googlers are unhappy.
84 percent of their 28,500 employees state they have a high level of job satisfaction which, as you'd expect, is one of the highest among the Fortune 500.
Other tech firms aren't having the same problem. The average tenure at Yahoo! and Microsoft is 2.4 and 4 years respectively.
Yikes.
The problem is loyalty. Loyalty is quickly becoming a thing of the past.
Employees are loyal to a fulfilling career, not a job — 78% would stay if they knew they had a career path. #HR #EmployeeEngagement https://t.co/TgHqkxS69Q
— Mercer (@mercer) December 9, 2016
It's not entirely our fault; We're given bad advice. The strategy is:"Don't ask for a raise, get a new job instead."
It's a destructive strategy that results in less trust. Employers limit the responsibility they give you because they believe you won't be here that long anyway...
Work has become this cutthroat environment where we all pretend to look out for the team, when in reality, we're looking out for ourselves.
If you're a sophisticated developer, you know.
At many companies, project managers and other developers are all too eager to throw each other under the bus for more money. When an opportunity comes along, these employees will eat each other for the chance to win.
Jumping from job to job only works for so long. Disloyalty catches up with you as your market value drops. There's no reason an employer should go out of their way to keep a disloyal developer.
Here's what loyalty looks like to them.
Continue reading %6 Unexpected Mistakes That Keep Developers from Getting a Raise%
by Andrew McDermott via SitePoint
6 Tools to Stop Your Devs and Designers Strangling Each Other
If you've been working in product development, web development, web design or most other areas where designers and developer work together, you've probably seen or heard at least one of the following (or something similar to it):
From the designers:
“We came up with a really beautiful design, but the developers really mucked things up. It's nowhere near what we designed.”
“How can we create a beautiful design if the developers will just screw it up?”
And from the developers:
“This design is impossible to replicate in HTML/CSS, this is as close as we can get.”
“Designing in Photoshop is easy, you don't have any limitations imposed by code. We can't fit this design into the development framework we are using”
Although you'll frequently hear comments such as the above, in my eyes, they're stemming from two main problems
- A lack of good tools / communication frameworks in place leading to …
- …a serious breakdown of communication between the designers and developers
In reality, designers and developers are very different from each other. Designers are right-brained, developers are left-brained. Those who think creatively need to establish a way to communicate correctly with those who think rationally / logically.
A way which works well for both.
The communication problem is made that much harder in today's environments, where remote working, different geographies, cultures, and languages, different timezones are all business-as-usual.
Having designers in one country and developers in another is the order of the day.
But designers and developers need each other. They need to communicate well if you want to create a good end product.
Start dating before living together
So, let's think of the developer-designer as a relationship.
Partners in a relationship need to understand what works (and what doesn't) for both of them before they can make more serious commitments.
The key to a good end-result: developers and designers need to start working together from the get-go.
Simply put, if a designer creates a design without the involvement of a developer, they're bound to have to go back to the drawing board often and get frustrated that their work as been ‘destroyed by the developer”.
If a developer is given a design which they had no involvement in, they're going to say that this design is impossible to implement and will have a hard time achieving the required end-result.
To create a design that works the developer should be present during the design brief to make sure that things are designed to an appropriate developer specification.
The following questions (and no doubt others) need to be figured out during the design brief and require input from both the developer and the designer.
- What responsive framework (grid) system will be used to implement the design?
- Are there any design elements which cannot be implemented using the selected framework?
- Which elements can afford to be hidden at smaller screen sizes and what will that look like?
- What text styles and fonts sizings are to be used?
- Create actual videos or specifications of micro-animations to be used.
- What imagery will be used and what kind of cropping will happen on smaller screens?
This is an exercise which needs to be done internally by your team. Figure out where you communication breakdowns are happening and then develop a set of questions which need to be fully specced (from the designer to the developer).
In essence, your designers and developer need to ‘date” such that they both understand each other, before actually committing to a design which needs to be developed.
As the design is being created, the developers should get involved frequently, such that potential development problems are identified early and resolved during the actual design.
Now that we've defined the theory, let's actually show you the tools we actually use to improve our communications between designers and developers.
How to get designers and developers to start working together
1. Use a constant communication process
Continuing with the need to have constant communication, you should implement SCRUM or another agile methodology.
Agile methodologies like Scrum emphasise the need for constant communication. All stakeholders agree on what is going to be built and they meet regularly to ensure everything is being developed to specifications.
We're not going to recommend or go deeply into the methodology to use, but, one thing is surely necessary.
Develop a process of constant communication.
For example, in Scrum, you have Daily Scrum 10 minute meetings which are meant to show the progress of the previous day and set a path for the current day. Any issues will be identified immediately and resolved separately from the daily meeting.
The Sprint Review – usually when a sprint is complete is a milestone – where both the developer and designer can actually see that progress on the design/development is according to the original vision.
By having both the designers and developers in constant communication, problems are identified and resolved quickly, before they get out of hand.
2. Use a good mockup tool
While PSDs are going to be necessary for the development, you won't be needing pixel-perfect designs for each and every screen in your project.
When the basic designs have been developed in Photoshop, you can then hurry things along with a good mockup tool.
Now, let's make one thing clear, mockup tools may be used by designers, but they're more likely to be used by your UX guys and developers. The favorite tool of choice for designers is an actual design tool, not a mockup tool.
Your mockup tool should be used as a bridge, between the people designing the requirements, the developers and the designers.
One thing to keep in mind - let everybody use their own favorite tool, don't force anything down anybody's throat.
Let the designers use their favorite design tool, Photoshop or whatever they prefer. Let the UX designers, the product managers, the business analysts use their favorite tool (typically a mockup tool). And then let the developers do their thing with whatever they want.
As long as there is a good line of communication, the tool they use is not very important.
Balsamiq
[caption id="attachment_153147" align="aligncenter" width="947"]
There are plenty of good tools out there, but the one we absolutely favor by far is Balsamiq.
Balsamiq has a full library of components and design elements which can be used to quickly create screens which need to be sent to the developers for implementation.
Balsamiq is available both as a desktop application for Mac or Windows and a cloud-based service.
UXPin
[caption id="attachment_153148" align="aligncenter" width="1200"]
If you're looking for a cloud-based service which is pretty much good for mocking up any design, UXPin has all of your bases covered.
Again, based on a comprehensive library of elements, you can web designs, Android or iOS apps, Bootstrap based screens, Material Designs, interactive UIs or micro-animations. It's as comprehensive a tool as it can get.
Moqups
[caption id="attachment_153145" align="aligncenter" width="1200"]
Whilst my preference is still with Balsamiq because, honestly, I like my mockups be just that - mockups, rather than near pixel-perfect designs, Moqups is another great wireframe tool.
With Moqups, you can create very high-fidelity mockups. Using the extensive libraries available within the tool, just like UXPin, you can go into quite a lot of detail into the design of your actual mockups.
3. Manage your project + tasks
Once your designers, developers and all the stakeholders have agreed on a way forward, it's time to actually start doing the work. When your start the actual job, job management software is great for quoting, time-tracking, billing and all the essentials of tracking your job.
Besides the actual job management (the easy part), you need to manage your project and the work which needs to be done.
It's during the actual project work where the problems often start to crop up, so there another few things which are critical to the success of a project.
First of all, each project must be broken into its parts and each step must be monitored for completion.
Secondly, your management tool of choice must be a single point of contact.
The biggest headache you can get is having ‘decisions” spread over multiple means of communication, email, Slack, your project management tool, face-to-face communication, phone calls. Always make sure that decisions taken anywhere all eventually end up in noted ‘in writing” on your project management tool.
Project Management Tools: Asana, Basecamp, and Trello
Ok, so rather than waste your time going through all of the most popular project management tools out there, I've bundled them all up into a single paragraph. Diving deeply into any of these specific tools has been done to death, so we'll leave this up to you to decide which tool is best for you.
All of the above tools have their strengths and drawbacks – it's a question of choice.
I've used all of them to varying degrees and all of them work well as long as you apply them well to the problem at hand.
Continue reading %6 Tools to Stop Your Devs and Designers Strangling Each Other%
by David Attard via SitePoint
Subscribe to:
Posts (Atom)