Katherine Losse, Facebook’s 51st employee, has recently left after spending five years at the company. Rising from customer service representative to ghost writer for Mark Zuckerberg, she’s recently left Facebook to live on a farm and write a book: The Boy Kings: A Journey into the Heart of the Social Network. I haven’t read it yet but found the interview — Facebook Refugee Unplugs From Social Media : NPR — upsetting enough.

LOSSE: Yeah. I think that one thing people should understand about any kind of technology is that these are constantly evolving technologies. The products change all the time. And so I think that’s one of the tricky things for users, is that the product can change. And so you might have put your – you know, posted information when it – the product looked one way, and then the product changes, and the user has to adjust.

I think that’s a difficult thing for users to deal with sometimes, because sometimes it means that the privacy settings end up being slightly different than what they anticipated. And that’s just sort of the nature, I think, of how these things develop. And it’s something that users should be really conscious of as they’re contributing to the system.

This is a very diplomatic way of saying that Facebook doesn’t really care about what it says its settings will do. It can redefine them at any time. I think it’s ridiculous to blame users claiming that technology is evolving so therefore it’s okay to expose sensitive information. If Facebook would like to know why no one really trusts it anymore. This is why. When a privacy setting describes that it will do X then it stops doing that that is a breach of trust, not evolution of a product.

A caller, Alex, expresses his concern that corporations are buying his personal information…

LOSSE: Yeah. I mean, it’s – that’s a tricky thing. You know, the company has to make money to run the servers and grow, but also, it needs to keep in mind that users want their experience to be, you know, protected and respected. So I think that’s something that is going to be really tricky for any of these companies as they become, you know, big and seek out profits.

This is the other reason why people don’t trust Facebook. It may be noble to not want to charge for the service, but I think that users would prefer paying for a better service over having their information bought and sold. The major difference between Google ads and Facebook ads are that when people use Google their intent is to discover products and services. To learn things. When people are using Facebook, the user intent is very different. There is a lot of power knowing your customer’s demographic, but honestly the products I “like” now are no clear depiction of my demographic. The only things I really “like” are products of friends, to show support. Honestly, because I saw how Facebook clearly did not respect my privacy, by changing the settings, I didn’t trust them to not share my personal information with companies that I “like”.

Honestly, today, I rarely share on Facebook. I use Facebook as a glorified address book, mostly because of the points above. I stopped trusting them. LOSSE is not to blame for what I discuss above. What shocks me most is how she diplomatically explains these things, as she herself has left the social network and is critical of it herself, but doesn’t seem to hear quite how bad these explanations sound.

With the rise of the new “Retina Display” monitors screen resolution is now miniscule. With is awesome for watching HD movies and browsing HD photos, but reading… is difficult.

In the past I found myself clicking CMD+ on most sites just so I could comfortably read the screen. But that’s usually a bad idea of you’re a fan of beautifully designed sites. Changing font size from the original tends to throw things out of whack.

Now that there is the “Reader” button I no longer have to CMD+ the sites I visit. The downside is that all reading experiences are the same. If I like the typeface a site’s designer chose. Too bad.

I recently stumbled across this nifty gem in the WordPress Codex: Debugging in WordPress.

Basically, php has ways to suppressing errors, and by default WordPress will do this for you as well. Why? Well, you don’t want everyone who stumbles onto your site to see all the errors your code is making. The problem is that with these settings a less experienced developer may be lead to believe that their code is fine, when it’s not.

Usually I keep my apache error log file open when developing. But with a few basic changes to your WordPress config file you can have all the errors you life, and more, right on the page.

NOTE: Do NOT do this on your production site. Only on your development/local server.

Find in your config.php file the line:

define('WP_DEBUG', false);

Change the value to true.

As the codex explains

Showing all PHP notices and warnings often results in error messages for things that don’t seem broken, but do not follow proper data validation conventions inside PHP. These warnings are easy to fix once the relevant code has been identified, and the resulting code is almost always more bug-resistant and easier to maintain.

Basically, your code may work, but if you don’t fix these errors you may run into problems.

define('WP_DEBUG_LOG', true);

This is a companion to WP_DEBUG that causes all errors to also be saved to a debug.log file inside the /wp-content/ directory.

The debug mode includes many more warnings and errors than in your apache error log, so if you care about your site working, do it.

Finally, if you don’t want the errors to display on the page, but still to be logged in the debug.log file add the following:

define('WP_DEBUG_DISPLAY', false);

The only problem with this is that you’ll soon see many mistakes by others. I make sure to promptly send my fixes to the authors, with a kind thank you of course, but not all listen. Some even upgrade their plugin and NOT include my corrections. Their plugin, their choice. But that does mean that I need to keep a log of my own to keep track of plugin fixes for when there are upgrades.

For further reading also check out 5 Ways to Debug WordPress.

In case you missed it, there were 60 people on the waiting list… Here’s the talk I gave at WPNYC in April about Responsive Web Design.

I spliced out my piece from the full video, but if you’d like what you see here, Sonja did a great job canvasing the Responsive Design conversation.

My talk covered the following:

The Pros and cons of Responsive Design

• What people are saying about Responsive Design. Is it right for you?

Progressive Enhancement vs Graceful Degradation

• The essence of Adaptive Design: If you want to use the cool stuff, build it up right so you don’t shoot yourself in the foot.

Implementing Adaptive Theme Design

• Concrete steps you can take to make your theme Adaptive.

As always, I love your input. Please comment below and let me know what you think.

One of the biggest complaints I’ve heard about Responsive Web Design is that sites built to be responsive take too long to load.

We may have reached the age of broadband with our desktops but with bandwidth throttling and pay-per-byte mobile plans we really need to consider every pixel and every bit of code we send to our users… If we expect them to frequent our sites that is.

One popular approach to building a responsive website is to take an already designed theme, then hide each element that doesn’t look good on a mobile until a minimalist theme remains. While that technique may leave you with a decent looking site it will wreak havoc on your users’ experience.

The ideal is to plan a minimum viable product — focus on your user’s needs, design for your content — and you’ll have the perfect mobile-friendly site. Just add a few media queries and you’re good to go.

But sometimes you NEED that awesomely cool heavy animation loading on your desktop theme, but want to spare your mobile users. Or you’d like to add some extra navigation, which just doesn’t work with the mobile experience.

What do you do then?

Introducing: php-mobile-detect

Let’s say you have a WordPress theme that you’re adapting to be Responsive…

Download the php-mobile-detect script and upload it to your theme folder.

Require it in your functions.php file.

    require_once('Mobile_Detect.php');
    $detect = new Mobile_Detect();

Then when you have to urge to apply a “Display: none;” in your stylesheet for something that is particularly heavy.

    global $detect;
    if ($detect->isMobile() && !$detect->isTablet()) {
        // code for mobile only
    } elseif ($detect->isTablet()) {
        // tablet browsers
    } else {
        // everything else
    }

Voilà!

But User Agent Sniffing is BAD?!

Browser Detection is a double edged sword. Here’s a great summary why you shouldn’t do this. But this solution, while technically IS browser detection, is more in the spirit of capability detection. We’re not singling out all iPhones and building a special theme for them, we’re finding all mobile devices that aren’t tablets and hiding/showing elements consequently. This is more akin to the media queries we so dearly love and rely upon for our responsive site.

Disagree? Please share your thoughts!

Kudos @victorstanciu for a great job on the php-mobile-detect script!

To prepare for my presentation at the WordPressNYC Meetup this past week — aside from getting to play with a tons of cool web toys and techniques — I read a lot of articles and books.

While there are a lot of articles out there, these books really cover the core issues and flesh out the concepts. In fact, many of the best articles are just chapters from these books. I’ll be sharing some of the articles as well as tools in future posts so stay tuned!

Books

Continue reading …

I had the privilege Tuesday night of speaking to some of the greatest WordPressers in the world at the Official WordPress New York Meetup. It was a true honor.

If you missed the performance or  would like to review the slides, feel free!

Use keyboard arrows to advance from slide to slide.

Note: Ironically, while it is viewable in Chrome and Firefox with all the fun JS bling, it is best viewed in Safari. When choosing a medium to build my presentation in I wanted to use impress.js because it provides a solid fallback, hence jiving with my preaching… Unfortunately, browsers aren’t quite up to all the 3d graphic rendering they claim to be. Even the bleeding edge ones… Except for Safari. (Although Chrome seems to be best for video… especially YouTube.)

Disclaimer: I am in the process of going through my live sites to implement the concepts I spoke about in my talk. I am not walking the walk 100% yet…

I will be posting notes for the slides over the weekend, and over the next few weeks I’ll be expanding on the ideas I shared in full blogposts. If you don’t want to miss any I’ll be tweeting them as they come out.

Please comment, share your ideas. If you think I’m talking $#!T call me out on it.

Cheers!

TL;DR Why does IE still have a market share? It’s the fault of your IT department…

I’ve been doing some research for my upcoming talk at WPNYC where I’ll be discussing Responsive/Adaptive Web Design. While preparing to talk about why it’s important to be inclusive with your design I checked the daily browser distribution from statcounter and noticed a very interesting pattern…

Do you see the funny blue/green fish at the top of the chart? Continue reading …

Responsive Web Design, which is built on the principals of Graceful Degradation.

Whereas…

Adaptive Web Design is built on the principals of  Progressive Enhancement.

Whhahaatt?

Graceful Degradation is when you build your site for modern browsers, then find solutions to make the experience passable for people using Internet Explorer or Mobile Browsers.

Progressive Enhancement starts with a solid base, designing as for the lowest common denominator, then adding enhancements for a better experience for the more fortunate visitors.

This is a somewhat of a watered down analysis. But essentially, it’s a difference of approaches. Who is your audience? are you targeting, mostly, people who use modern browsers and you just want to make sure it just works OK elsewhere? There’s nothing wrong with Progressive Enhancement… when it’s intentional. Personally, I’m a fan of inclusive thinking.