Archive for the ‘Web Basics’ Category

File Under: Web Basics

Mozilla Aims to Build a Better Web With ‘Webmakers’ Project [Updated]

Mozilla Webmakers Summer Code Party, coming soon.

Mozilla has kicked off a new effort to do something that’s very near and dear to Webmonkey’s heart — helping people create cool stuff on the web. Mozilla Webmaker, as the new initiative is known, wants to create “a new generation of webmakers, and a more web literate world.”

Mark Surman, Mozilla’s Executive Director, calls web literacy “the world’s second language,” and goes on to say Mozilla believes web literacy is “a vital 21st century skill — as important as reading, writing and arithmetic.”

To help bring that literacy to more people around the world Mozilla’s Webmaker will offer a variety of different things to try, each aimed at different interests:

  • 1) Tools. Authoring tools and software, designed and built with our community. From supercharging web video with Popcorn, to remixing with Hackasaurus, to making your own web pages with Thimble.
  • 2) Projects. Practical starter projects, how-tos and recipes, designed to help people at all levels make something amazing with the web. From tweaking your blog template to building apps that change the world.
  • 3) Community. Bringing people with diverse skills and backgrounds together. Teachers, filmmakers, journalists, youth. From web ninjas to newbies. All making and learning together at events, meet-ups and hack jams everywhere.

Webmaker isn’t just Mozilla, either; the company has partnered with the likes of Tumblr, Creative Commons, Code for America, and dozens of others.

To get things started, Mozilla will kick off what it calls a “Summer Code Party” on June 23. And yes, it sounds a lot like Google’s Summer of Code, but with a focus on building the open web. Head over to the Webmaker site to search for something near you or start your own event.

For more info about Summer Code Party and other aspects of the Webmaker initiative head over to the new site, or check out the intro video below.

[Update: Several readers have asked about Thimble, mentioned in the Mozilla quote above. A Mozilla spokeperson tells Webmonkey, "Mozilla Thimble is the name of a web app we're building that provides a live side-by-side code editor for webmakers -- code on the left, live preview on the right." Thimble will also provide error checking and code tips find and fix mistakes quickly. Mozilla says the goal is to "give webmakers a tool to build and share web pages and also allows them to load in our pre-made project templates with guided content." Mozilla Thimble will launch as a beta in early June, in time for the Summer Code Party campaign.]

File Under: privacy, Web Basics

Twitter Improves Privacy Options, Now Supports ‘Do Not Track’

Photo: Only Sequel/Flickr

Twitter has jumped on the “Do Not Track” privacy bandwagon.

The company recently confirmed that it supports the Do Not Track header, a user privacy tool originally created by Mozilla that is in the process of becoming a web standard. That means if you visit Twitter in any web browser that supports the Do Not Track header, you can opt out of the cookies Twitter uses to gather personal information, as well as any cookies set by third-party advertisers.

Behavioral tracking, as such practices are often called, is a common on the web. Advertisers use cookies to track your clicks, watching which sites you visit, what you buy and even, in the case of mobile browsers, where you go. Often the sites tracking you are not just the sites you’ve actually visited, but third-party sites running ads on those pages.

And it’s not just advertisers tracking your movements, social networks like Facebook and Twitter also follow you around the web. You may not realize it, but Twitter has been tracking your every move for some time. The company doesn’t make a secret of it either. In a blog post announcing Twitter’s new “tailored suggestions system” Twitters Othman Laraki writes, “we receive visit information when sites have integrated Twitter buttons or widgets.”

To be clear, not only is Twitter able to set cookies any time you visit its own domain, whenever you visit a website (like this one) with a “Tweet This” or similar button Twitter can see you there as well. This practice is hardly unique to Twitter; Facebook, Google+ and others are doing the same thing.

Most of the time the information gathered is used to create a better experience for users. In the case of Twitter’s new “tailored suggestions” feature the information is used to build a profile of what you like and then Twitter makes suggestions based on that profile. You can read about exactly what Twitter does with your info and how long it keeps it in the company’s privacy policy.

The problem with such tracking is that it’s necessary for features we want, like smart, targeted suggestions — new users to follow, music you’ll likely enjoy, books you might want to read and so on — but it can also be used for decidedly less friendly purposes. As awareness of the downsides to such tracking become more well known a growing number of people are opting out of the tracking. The Mozilla Privacy blog reports that “current adoption rates of Do Not Track are 8.6 percent for desktop users of Firefox and 19 percent for Firefox Mobile users.”

To take advantage of Twitter’s new Do Not Track feature you’ll need to be using a web browser that supports the header. Currently that means Firefox, Opera 12+, Internet Explorer 9+ or Safari 5.1+. Chrome has pledged to add support for Do Not Track, but doesn’t just yet. For more information on protecting your online privacy, including tools like Ghostery, which go even further, blocking all tracking cookies, see our earlier post, Secure Your Browser: Add-Ons to Stop Web Tracking.

File Under: Visual Design, Web Basics

Google Embraces Responsive Design, Recommends You Do the Same

Responsive Book: Google's Chromebook site as seen by a phone (left) and a tablet.

If you’ve been waiting for responsive design to go mainstream, wait no more. While The Boston Globe‘s responsive redesign made a big splash in the developer community, The Globe has nothing on the latest web giant to throw its weight behind responsive design — Google.

That’s right, Google is now suggesting developers use responsive design tools like media queries to handle the variety of screens now accessing the web.

The Google Webmaster blog has posted a new article, Responsive Design – Harnessing the Power of Media Queries, that walks beginners through the basics of creating a responsive website.

It’s not the most thorough tutorial we’ve seen, nor is it the best — Google conflates breakpoints with device width, something we’d recommend against — but nitpicking aside, Google’s official blessing will no doubt help move responsive design to the front burner in many people’s minds.

It’s worth noting that while a tutorial is nice, Google isn’t necessarily making the leap to responsive websites for its own properties. Indeed, sites like Gmail or Reader are excellent arguments for maintaining separate mobile designs. If your “site” is actually a web app as complex as Gmail then we suggest doing what Google does — hiring a fleet of developers to build an maintain separate websites for different size screens.

Chances are, though, that your site isn’t that complex and doesn’t have the developer teams that Google can afford. Even Google uses responsive design when it makes sense. To go along with the new tutorial, Google offers up that the new Chromebook website is responsive, which shows off the company’s responsive design chops.

Responsive Web Design: What Not to Do

Testing a responsive site across devices (using Adobe Shadow). Photo: Adobe.

We’ve covered quite a few ideas on how to build more responsive websites — that is, websites that use flexible layouts, media queries, image scaling and other tricks to make sure that the site looks great and works well on any screen.

Sometimes, though, it’s helpful to see what not to do. Responsive design guru Brad Frost recently outlined five common mistakes responsive developers make over at .Net magazine. Frost covers responsive sins like relying on specific screen sizes to trigger layout changes (it’s far better to create design breakpoints based on a site’s actual design than to just use the screen sizes du jour) and avoiding a one-size-fits all experience.

Of the latter Frost writes:

Mobile is much more than just various small screens…. We shouldn’t sell ourselves short by only creating responsive layouts. For example, we sometimes forget that mobile phones can get user location, initiate phone calls, and much more. Hopefully soon browsers on all these gadgets will have access to even more device APIs, further pushing the boundaries of what’s possible on the web.

We should do all we can to make the entire experience respond to what the device is capable of. Addressing constraints first gives us a solid foundation to stand on, then we can utilize progressive enhancement and feature detection to take the experience to the next level.

The entire post is well worth reading, but we’d like to add a sixth rule to the list: Don’t assume that what you did yesterday will be the best thing to do tomorrow.

That’s not to imply that what you do today won’t work tomorrow, just that chances are there will be an easier way to do it.

Responsive web design is a very new challenge and the best ways of meeting it are still being worked out. That can be a pain, but it also means that some very smart people are solving some very hard problems and you can benefit from their work provided you know about it.

We see new things popping up all the time, whether it’s a new way to handle responsive images or a browser update that adds widespread support for a new CSS feature. We encourage developers to spend some time reading up on the latest tips and tricks before each new project. New responsive tools are being developed and refined so rapidly that the hack you used on your last project might turn into a stable, well-maintained JavaScript library by the time you start building a new responsive site.

File Under: servers, Web Basics

What to Do When Your Website Is Hacked

All it takes is one open lock. Photo: David Bleasdale/Flickr

One drawback to the otherwise awesome sauce of the do-it-yourself web is that you’re also responsible for fixing it yourself when something goes wrong — call it the FIY corollary to the DIY web.

For example, what happens if the bad guys attack your website?

In some cases your web hosting service may be able to help, but most of the time undoing the damage is your responsibility. Websites are attacked every day; well-tested though they may be, frameworks and publishing tools inevitably have security flaws and eventually you may be bitten by one. Or it might not even be the tools that end up being the problem, it might be something far less obvious. Developer Martin Sutherland’s server was recently hacked because one file on a shared server had the wrong file permissions.

Sutherland’s write-up of how he discovered and fixed the attack on his server is well worth a read and makes an excellent primer on how to handle being hacked. While Sutherland’s situation may be specific to the attack that his site suffered, his diagnostic steps make an excellent starting point even if you use a completely different publishing system. (Sutherland uses Movable Type.)

Sutherland’s strategy (once he realizes he’s been hacked) is to scan through all the files on his server to see which ones had recently been changed. He then filters that list, ignoring files that should have changed (log files, etc.) and narrowing it down to suspicious file changes.

How much this approach will tell you if your own site has been hacked depends on what the attacker has done and what your server setup looks like, but it should help you get moving in the right direction. Read through the full post for the specific command line tools Sutherland uses to inspect his files. If you’re not comfortable on the command line or don’t have shell access to your server you may be able to use something like Exploit Scanner (if you’re using WordPress) or a similar tool for your publishing system.

Once you know what happened and which files were affected it’s just a matter of rolling back the changes using your backups. You do have backups right? As Sutherland writes, “it’s not a matter of if something goes wrong, it’s a matter of when.” Remember: backups are only useful if you have them before you need them.

We sincerely hope your site is never hacked, however, it does happen all too frequently. As Sutherland’s write-up illustrates, one of the keys to making sure that you recover quickly is to have good backups. Do yourself a favor and spend a few minutes creating an automated backup system before something goes wrong. Now excuse me while I go make sure my pg_dump cron script is running properly.