Since the dawn of time there have been ads. Ok, not the dawn of time per se, but as far back as any of us can remember, there have been advertisements shoved in our faces, through our ears, and down our throats from one medium to the next. Be it a radio jingle, or a tv commercial skit, ads have existed for quite some time.
But as long as ads have existed, humans have found ways to get around them. TV and radio had a volume control and mute buttons, VHS players had fast-forward buttons.
We are in the dawn of a new era, where everything is digital; every move we watch, every tv show, every song, every newspaper, every piece of information you desire can be found online. And yes, there are ads. There are people wanting something from you – money, your email address, something.
Ever been reading a really interesting blog post when THIS happens?:
Yes, we’ve all been there! What impression does this leave you with? My first thought is “I need to join a trial to even read this?! Am I really required to give my credit-card info just to read an article, when you’ve got 3 ads in the first fold?”
Little do I notice the little “x” button. So small.
Brad frost illustrated this perfectly : “Welcome to our website, screw you!”
So what do I do? I go and install today’s version of a mute-button: yes, an adblocker. Because, let’s face it, people don’t like dealing with the things they don’t like. You wouldn’t willingly step in a pile of dog shit, would you?
There are far more elegant ways to make money through your website than shoving garbage down people’s throats.
This is not an issue of whether someone values your content or not; it’s a matter of how you justify your actions. Interrupting what I’m doing or trying to do isn’t going to make me want to pay for your services.
This is why user experience is key in every site. User experience matters – it affects your SEO ranking, it affects your revenue, and it affects how people perceive your brand. This is crucial to understand.
When a user lands on your site, what you present to them, whether you like it or not, sets expectations. It sets a tone. Your users aren’t stupid; they know your motives. They can tell whether you’re just the type of company that sees them as dollar signs, or sees them as people.
When you dive into building your next site, or launching your next optimization test, ask yourself if what you’re doing is genuinely useful to your visitors. Don’t try and trick them into buying something, or confuse them down a funnel. Don’t offer them content, and present them with distraction. If you say “click here to read more” then don’t give them something to read, why on earth do you think they’ll do anything but leave?
When we get fixated on “conversion rate” and “rpv”, we tend to view our users not as people, but as equations – statistics. As much as we’d like to pretend our users won’t notice – they do. And yes, they will use the mute button 🙂
WordPress’s functions.php could easily be considered the core of your theme. It adds unique, and often necessary functionality to your blog. You can enable features, or create new ones. In this article, I’m hoping to give some insight in not just making a custom functions.php file for your theme, but making it easy to manage.
How does WordPress the functions.php file work?
The short version – it extends what WordPress does by modifying existing actions – aka creating filters, or adding new ones, aka creating actions. This is done using WordPress Hooks.
Rather than have ME explain it all to you, you should consider reading WordPress’s explanation of the functions.php file, so you can gain a more detailed understanding of how it works.
Don’t hand-code it all
While you COULD hand code everything – and I encourage you to learn – a good starting point might be to…well..cheat! www.wpfunction.me is a handy website that lets you pick your own functions, and it gives you the code for it. Post thumbnails enabled? No problem! Want to load a custom CSS file to theme your admin area? No sweat.
The nice thing about this tool is it can be a great way to familiarize with the logic behind the functions.php code. Not sure about code snippet it generates? Google it or search the wordpress codex to learn about it. Once you learn about it, tweak it, play with it until you get it exactly how you want. Maybe make your own custom function!
Make it a plugin
The functions.php file is relative to your theme, so you want to be sure that whatever functionality you add to it specifically works to enhance your theme, but doesn’t take away from the core functionality of your blog should you ever change themes, because if you ever switch themes, your custom functions are gone unless you manually copy them over to your new theme.
One way to bypass this caveat is to make a plugin for every function that isn’t theme specific.
To do this, create a new folder for your plugin, and create a new php file inside it. In this PHP file, insert the required plugin information headers need for WordPress to recognize the plugin, followed by your custom function, like so:
* Plugin Name: Name Of The Plugin
* Plugin URI: http://URI_Of_Page_Describing_Plugin_and_Updates
* Description: A brief description of the Plugin.
* Version: The Plugin’s Version Number, e.g.: 1.0
* Author: Name Of The Plugin Author
* Author URI: http://URI_Of_The_Plugin_Author
* License: A "Slug" license name e.g. GPL2
//custom code here
//you can find this example here:
//I strongly recommend reading WordPress’s documentation
//because it’s relatively easy to follow, and it’s
//quite informative : )
Now, take your new plugin folder and place it inside wordpress’s ‘plugins’ – or, ZIP the folder and upload it from the plugins section of the admin area.
If all works well, your function is now a plugin that you can enable, disable, and modify from within the admin area, no matter what theme you use![/az_column_text][/vc_column][/vc_row]
The web is constantly evolving; the HTML language is expanding, CSS is getting more advanced, and we are finding more and more ways to make the web interesting. However, for some reason, some people don’t upgrade their browsers, making it very difficult for us to share that creativity with others; so how do we deal with people who are running IE8, or even worse, IE6?
In this article, I’ll give you some tips and practices in no particular order that you can use to make life a little easier for you and your users.
Probably the most common method of dealing with those pesky Windows XP users running Internet Explorer 8 or older (only joking XP users! Windows XP is great, really it is.)
#2 Know your audience
Legacy browser support can be a massive pain in the butt; but as a web designer, your biggest concern should be to give your audience the best experience possible regardless of what browser they use. So, spare yourself the headache and know your audience. Use tools like Google Analytics to figure out how people are accessing your content, and develop your own standards & practices.
If you don’t know your audience yet, you can do 1 of 2 things.
#3: Test on older browsers
Never rely on just the latest version Google Chrome or Firefox to test your code. Unfortunately, while browser “manufacturers” try to render code accurately and consistently, no browser is 100% equal. People tend to rant and rave how IE is the absolute worst it comes to rendering code, but they aren’t the only ones you should worry about.
And sometimes, it’s not the browser alone, but the operating system. Every operating system handles application text differently, not one is the same. When QAing your work, you should test every version of every browser you intend to support on every operating system you intend to support. How?
You could setup a virtual machine, but that can be tricky, expensive, and impact your computer’s performance. I like to use BrowserStack. BrowserStack let’s you choose between multiple versions of Windows, OSX, or choose different iOS or Android Devices, and multiple versions of the many browsers each operating system can run. Need to test IE9 on Windows 7? Easy! Need to test Firefox 10.0 on OSX? No Problem! BrowserStack will give you remote access to a machine with the OS and browser of your choice through your browser, making it easy to test your website’s browser compatibility.
#4 Be Responsive
When building a web experience intended to reach people on multiple platforms, browsers and operating systems aren’t the only factor. Consider the device your users are using, and the monitors they are viewing content through. Different screen sizes, resolutions, etc., all play a huge role in your website’s usability.
Whenever possible, test your website in various resolutions. A good start is to just shrink the size of your browser window. Or, again, use BrowserStack. Along with choosing the operating system and browser, you can set the desktop resolution all the way down to 800×600, or view your site through various devices, inheriting their viewport/resolution.
#5 Consider the fallbacks
As mentioned before, Modernizr can be used to determine what various CSS and HTML features a browser can support, and will add classes to the <body> tag for each unsupported feature. Utilize this tool to create fallbacks.
Hopefully the above tips and practices above will help ease the strain of supporting older browsers. How do YOU deal with older browsers? What do you support, and what tricks do you use to support them? I’d love to hear your ideas in the comment section below![/az_column_text][/vc_column][/vc_row]
In PHP, there’s a handy dandy little function called ‘include’ that basically allows you to run a php script from another file in your current script. There is also a handy dandy little function called ‘require’ that basically does exactly the same thing. Basically. Likewise, there’s ‘require_once’ and ‘include_once’ which both due the same thing, but check the current document to see if its been included or required already, and won’t do it a second time. So…which should you use, and when should you use it?
It all depends on the application. With ‘include’, if an error occures in the included file, the remainder of your application can still function. At most, you will see get a warning, but nothing more. With ‘require’, if there is an error in the required file, the remainder of your application will not function, and your scripts will stop running. Sounds scary, right? Off the bat, it may seem like, from a usability standpoint, you should use ‘include’ or ‘include_once’ as a default – but this really isn’t the case. Think of what you are implying.
If you use include over require, you are doing a few things:
As best practice, you really shouldn’t be including code that doesn’t need to exist. At the very least, it can impact performance of your application. ‘include’ should really only be used for ‘optional’ code, but…how often is code you write used only part of the time? Very rarely.
Using require throws errors – which is a huge benefit in spite of how scary it may look. Checking your server logs, or getting immediate feedback as to what broke in your code is crucial when developing. If your required file patches a security loophole of some sort, it is obviously essential that your application stops running if the required file breaks.
So, best practices?
PHP is a widely used language, but is full of security holes. It is important to understand some of these basic practices as your develop your websites and/or applications in PHP to keep you and your users safe, and to make sure your code is running optimally.