Archive for August, 2011

File Under: privacy
Aug
31
2011

Flickr’s New ‘Geofence’ Settings Protect Your Geoprivacy

By

Fencing in the range with Flickr's new Geofence features

The popular photo sharing website Flickr has introduced a new way to geotag your photos without revealing your location to the entire web. Flickr’s new “Geofence” settings give users more granular control over their geotagged photos.

Perhaps the best part of the new Geofence features are how dead simple they are to use — simply draw a circle on a map, choose a geoprivacy setting for that area, and you’re done. Your new fence will apply to any future photo uploads and Flickr will offer to update the privacy settings on any existing images that fall within your new fence.

To get started head over to the Flickr Geo privacy page.

These days geotagging isn’t just something for nerds. In fact, chances are your camera (especially the camera in your phone) is recording location data in your images whether you know it or not. Like other location-aware services, geotagged photos are fast becoming a big part of the current cultural debate about who should be able to see which parts of your life on the web.

“A few years ago, privacy controls like this would have been overkill. Geo data was new and underused, and the answer to privacy concerns was often, ‘you upload it, you deal with it,’” writes Flickr developer Trevor Hartsell on the code.flickr blog. “But today, physical places are important to how we use the web. Sometimes you want everyone to know exactly where you took a photo. And sometimes you don’t.”

Previously, Flickr limited its geotagging options to a simple yes or no — either you shared location data with everyone or no one. Now you can share location data with only those people you trust. For example, you might leave the geodata for your vacation photos visible to everyone, but limit the location data of photos around your house to only your friends and family.

In those cases where there might be overlap between two geofences Flickr will default to the more restrictive of the two. For example, if you draw a circle around your house and limit it to the most restrictive group, “Family,” and then draw a circle around your whole neighborhood and limit that to “Friends,” any areas where the two overlap will still be limited to only the Family group.

Flickr’s new Geofence settings are among the best implemented privacy controls we’ve seen, striking a nearly perfect balance between genuine control and simplicity. And while we’re glad to see Flickr taking the lead, here’s hoping Facebook and others will copy these features into their own privacy controls.

See Also:

Tags: ,
File Under: HTML5, Visual Design, Web Basics
Aug
31
2011

Faviconist: Create Beautiful Favicons with HTML5

By

Every website needs a favicon, if for no other reason than to avoid littering your server logs with 404 errors. If you still haven’t got a favicon on your site, check out Faviconist, a new favicon generator from developer Michael Mahemoff.

Faviconist is built on two basic premises, that you shouldn’t need Photoshop just to create a favicon, and that most favicons are just a letter on a background color. As Mahemoff writes on his blog, Faviconist is for “the 95% of people who don’t want to micro-design their icons; the rest will still need to resort to PhotoShop.”

Once you’ve got your favicon looking the way you’d like just click the “save favicon” button on Faviconist will generate some cut and paste code you can drop into your pages. If you prefer to host the image yourself, just right-click the image and save it.

Even if you don’t need to generate a new favicon, the site is still well worth exploring just to see what can be done with the HTML5 Canvas tag and client-side processing. In fact, the only thing that’s done server-side is converting a .png file to the .ico format favicons use. Node.js, Kaffeine, JQuery and Google Fonts are among the other tools Faviconist relies on to design and generate icon files. Be sure to check out Mahemoff’s blog for more details on how Faviconist works.

See Also:

Tags:
File Under: Backend, Location, servers, Web Basics
Aug
31
2011

OpenDNS and Google Working with CDNs on DNS Speedup

By

A group of DNS providers and content delivery network (CDN) companies have devised a new extension to the DNS protocol that that aims to more effectively direct users to the closest CDN endpoint. Google, OpenDNS, BitGravity, EdgeCast, and CDNetworks are among the companies participating in the initiative, which they are calling the Global Internet Speedup.

The new DNS protocol extension, which is documented in an IETF draft, specifies a means for including part of the user’s IP address in DNS requests so that the nameserver can more accurately pinpoint the destination that is topologically closest to the user. Ensuring that traffic is directed to CDN endpoints that are close to the user could potentially reduce latency and congestion for high-impact network services like video streaming.

The new protocol extension has already been implemented by OpenDNS and Google’s Public DNS. It works with the CDN services that have signed on to participate in the effort. Google and OpenDNS hope to make the protocol extension an official IETF standard. Other potential adopters—such as Internet ISPs—are free to implement it from the draft specification.

It’s not really clear in practice how much impact this will have on network performance. It’s worth noting that GeoIP lookup technology is already used by some authoritative DNS servers for location-aware routing. The new protocol extension will reportedly address some of the limitations of previous approaches.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

File Under: Mobile, Programming, Web Basics
Aug
30
2011

Build Faster Mobile Websites With ‘Adaptive Images’

By

Responsive design is no longer just something you’ll find on the portfolio websites of the designers and developers who pioneered the idea. These days using media queries to adapt to varying screen sizes is well on its way to being a mainstream design goal.

Head over to a responsive design showcase like Media Queries and you’ll find plenty of “real world” websites — like Opera or Arizona State University — using media queries to build responsive websites.

But while media queries are a big part of responsive design, they don’t solve every challenge the small screen presents. For example, many otherwise great responsive websites still serve full size images to mobile browsers. Many responsive sites use the max-width image scaling technique which dynamically re-sizes your image to fit the screen, but sadly that doesn’t downsize the actual image file.

Using the max-width trick neatly handles images on varying screen sizes, but, by itself, it doesn’t address the bandwidth issue. In fact, loading big images and forcing mobile browsers to scale them is the worst of both worlds — large image downloads and processor-intensive downscaling. And, not only are large images a waste of bandwidth for mobile users, with mobile data caps becoming more common, you may well be costing your visitors money.

A far better approach is to use the max-width trick, but also serve smaller images to smaller screens — that means less bandwidth and little or no downscaling. Mobile platform consultant Peter-Paul Koch has a nice overview of how JavaScript can be combined with media queries to swap out your mobile-size images for larger ones on larger screens. The developers at Filament Group refined this approach with the Responsive Images project.

However, as nice as the Responsive Images approach is, it requires maintaining two sets of images on your server. For existing websites with content management systems already up and running, and tons of images tied to existing content, it can be difficult and time consuming to go through and create a second set of smaller images.

The burden of an existing CMS led developer Matt Wilcox to take a different approach to the mobile image problem. The result is what Wilcox recently decided to call Adaptive Images. The Adaptive Images script works much like the Filament Group’s Responsive Images code, but Adaptive-Images manages its own image resizing so there’s no need to do anything to your existing website — just drop in the Adaptive Images code and you’re done.

There is, however, one other big difference between the two that’s worth noting — the Filament Group’s Responsive Images takes a mobile first approach while Wilcox’s Adaptive Images does not.

That is, if JavaScript is disabled, Responsive Images falls back to using only the small image. Adaptive Images on the other hand will fall back to the large image. While we generally suggest taking a mobile first approach, in this case the convenience of slipping Adaptive Images into an existing site outweighs the advantages of a mobile first approach. However, if you’re building a new site from scratch and your CMS can’t handle tracking separate image sizes, chances are you’re using the wrong CMS.

To get Adaptive Images up and running on your website you’ll need to have an Apache 2 server with PHP 5.x installed. For more info, head on over to the Adaptive Images website or you can grab the code from GitHub.

See Also:

Tags: ,
File Under: Browsers
Aug
26
2011

Firefox to Keep Version Numbers After All

By

Good news Firefox fans, that whole tempest in a teacup about version numbers being removed from the Firefox About dialog was, apparently, a misunderstanding. Firefox will continue to list its version number in the About Dialog box for the foreseeable future.

The problem started when Asa Dotzler, director of Firefox, filed a bug that would remove the version number from the about dialog. Dotzler believed that Mozilla’s user experience team had already made the decision, but as it turns out, they had not.

Alex Faaborg, a Principal Designer on Firefox and head of the UX team, jumped into the controversy surrounding the disappearing version numbers to say that, for now, Firefox would not be dropping the version number from the dialog box. He went on to address the real issue, why anyone cares whether or not Firefox has a version number at all:

I think the reason this debate became so emotional is that some people want to change client side software to behave like the Web (where the user has no control over version), and some people simply aren’t comfortable with that model. The existence of version numbers is functionally kind of peripheral to that debate, but nonetheless served as an effective lightning rod for a growing storm of controversy.

Indeed few users, even those against the proposed change, really care whether the version number is in the About dialog or elsewhere, the real vitriol was directed at the idea that Firefox might not have a version number at all.

The versionless software model works just fine for web apps like Gmail or Facebook, but most people seem uncomfortable with the same idea applied to desktop apps like Firefox. After all, no one controls the web — no one cares which version of Gmail they’re using because no one has any control over it anyway. Desktop software on the other hand has always been something users can control and removing the version number feels to many like removing some of that control.

Web developers in particular have bristled at the idea of a versionless Firefox. One of the easiest ways to track down problems that Firefox users might have when they access your website is to start by asking which version of Firefox they’re using. Without that information it can be difficult, if not impossible, to reproduce and solve the problem.

Couple that with the fact that the new rapid release cycle is causing considerable pain for users by frequently breaking add-ons, and it’s clear that Mozilla is stuck between a rock and a hard place. On one hand the new rapid release model means version numbers are bumped every few weeks, sometimes breaking add-ons. On the other hand, removing the version number from the equation makes life more difficult for web developers (and add-on developers and anyone else who is trying to support Firefox users and needs to be aware of version numbers).

The simplest answer seems two-fold. First Firefox needs to rework its add-on system so that version number bumps do not break add-ons (this has been partially addressed for add-ons hosted by Mozilla). Then Firefox needs a more appropriate version number system, perhaps, as Faaborg suggests in his post, something based on dates. In that scenario the upcoming Firefox 7, scheduled for release in September, would be Firefox 2011.9 or something similar.

While a real solution to all of the issues created by Firefox’s transition to a rapid release cycle remains elusive, at least for now those upset by the loss of version numbers can rest easy.

See Also:

Tags:
File Under: Browsers, Mobile, Web Apps
Aug
24
2011

Mozilla’s WebAPI Wants to Replace Native Apps With HTML5

By

Mozilla has launched an ambitious new project aimed at breaking down the proprietary app systems on today’s mobile devices. The project, dubbed WebAPI, is Mozilla’s effort to provide a consistent, cross-platform, web-based API for mobile app developers.

Using WebAPI, developers would write HTML5 applications rather than native apps for iOS, Android and other mobile platforms.

Mozilla isn’t just talking about WebAPI, it’s already hard at work. It plans to develop the APIs necessary to provide “a basic HTML5 phone experience” within six months. After that the APIs will be submitted to the W3C for standardization.

Among the APIs Mozilla wants to develop are a telephone and messaging API for calls and SMS, a contacts API, a camera API and half a dozen more.

If those APIs sound vaguely familiar it might be because the W3C’s Device APIs Working Group is covering similar ground.

So, why the new effort from Mozilla? Well, Mozilla’s WebAPI is a part of its larger Boot to Gecko Project, which aims to eventually develop an operating system that emphasizes standards-based web technologies. With that end goal in mind, WebAPI may end up somewhat different than what the W3C is trying to build.

It’s also possible that Mozilla simply doesn’t want to wait for the Device APIs Working Group. Mozilla wants WebAPI up and running in a mere six months, the W3C’s Device APIs Work Group is unlikely to move that fast. But “the idea is to collaborate with W3C and all players and together form a good solution, and not just dump it on them,” says Mozilla Technical Evangelist Robert Nyman in a comment on his post announcing WebAPI.

The dream of write-once, run-anywhere software is nothing new and, if history is any guide, Mozilla’s WebAPI efforts may well be doomed. The open source giant does have one thing going for it that most other efforts have not — the open web. Most write-once, run-anywhere attempts have come from companies like Adobe and were built around proprietary frameworks. WebAPI doesn’t suffer from vender lock-in the way some projects have. WebAPI’s main roadblock is convincing other mobile web browsers to support the APIs.

For WebAPI to appeal to developers, Mozilla will need Apple, Google and other mobile browser makers to implement the APIs so that WebAPI can compete with native applications. Before you dismiss that as an impossibility, bear in mind that Apple’s original vision for iOS app development was based around HTML applications, and you’d be hard-pressed to find a company more eager to embrace web apps than Google. Whether either company will devote any resources to implementing WebAPI remains to be seen. But if Mozilla can get WebAPI standardized by the W3C other browser makers would likely support it.

Mozilla’s plans for WebAPI are certainly ambitious, but the company is putting its money where its mouth is — Mozilla is currently hiring several full time engineers to work on WebAPI.

See Also:

Tags: , , ,
File Under: UI/UX, Visual Design
Aug
23
2011

Creative UX Designs to Improve Web Forms

By

Extra options in Gowalla's login form

We’ve looked at how the new HTML5 form tags improve the process of building web forms, but you don’t need to wait for better browser support to improve your forms today. Luke Wroblewski, web developer and co-founder of Bagcheck (which was recently acquired by Twitter), has a great post over at Smashing Magazine detailing various ways of improving the ubiquitous login form.

Pulling examples from Gowalla, which helpfully provides your user id photo, Quora, which immediately offers to create an account if your e-mail isn’t found, and his own Bagcheck, which is experimenting with a drop down list of usernames as you type, Wroblewski’s post is an excellent tour of some of the best UX login forms on the web.

There is one important qualification for these forms — the assumption is that your site has public, searchable profile pages, otherwise exposing user data (like username or photo) would be a privacy no-no. Of course it’s worth considering that, while exposing usernames in the login forms might not actually violate anyone’s privacy (any more than a public profile already does), that doesn’t mean your users won’t perceive it as a privacy violation.

For those worried about security the same caveat applies. If your site already has public profile pages then you’re not exposing any data that can’t be found with a simple Google search. Provided your backend security protocols are built correctly, making a more usable login form won’t make your site any less secure.

See Also:

Tags:
File Under: UI/UX
Aug
22
2011

Audit Your Site’s Content with ‘Page Trawler’

By

Need a 50,000-foot overview of your website? Page Trawler is a new web service that will crawl your site and give you a bird’s eye view of your content. While the service is currently limited to crawling the first fifty pages of your site and offering up a .cvs summary of those pages, the developers hope to turn Page Trawler into something much more useful.

If you’d like to try it out, head over to the Page Trawler site and plug in a URL. Note that you’ll need to give up an email address to download the report.

The Page Trawler project, which lists itself as alpha software, began life as part of a contest to build something in a week, but the developers have big plans to turn the site into something more. Among the ideas are integrated analytics, heatmaps, detecting orphan content and, our personal favorite, unlimited bourbon. We’ll be sure to let you know when that last one becomes available, but in the mean time if you’ve got ideas for Page Trawler, head over to the UserVoice page and let the developers know.

See Also:

File Under: Browsers
Aug
19
2011

Firefox: The Emperor Wears No Versions

By

Mozilla has created a stir in the Firefox community by suggesting that the version number ought to be eliminated. The version number currently shown in Firefox’s "About" dialog has been filed as a bug. Instead of a version number Mozilla simply wants the box to read something like "Firefox checked for updates 20 minutes ago, you are running the latest version." Mozilla believes that eliminating the version number will reduce user confusion.

As is witnessed by an increasingly hostile thread in the mozilla.dev.usability group, pretty much everyone outside Mozilla seems to think eliminating the version number is a bad idea. After all, even Google Chrome, the browser from which Firefox has borrowed much of its new look and its new rapid release cycle, still offers a version number.

So why does Mozilla want to ditch the version number? In the words of Asa Dotzler, director of Firefox, "we’re moving to a more web-like convention where it’s simply not important what version you’re using as long as it’s the latest version. We have a goal to make version numbers irrelevant to our consumer audience."

We have a news flash for Mozilla: version numbers have always been irrelevant to your consumer audience. They have, however, always been very relevant to your developer audience. And version numbers are, whether it’s Windows, OS X or Linux, found in the About dialog. As Barry Able writes at one point in the now very lengthy thread, "I’d like to paraphrase the country song and ask, ‘What part of ‘about’ don’t you understand?’ This box is named ‘About’ because it provides information ‘about’ the application."

Developer Dave Garrett responded to Dotzler writing, "I don’t claim that showing the version number is the most important thing in the world, just that the about dialog is where it belongs and trying to change that feels to some of us like a fight…that doesn’t need to be."

Indeed removing the version number from the About dialog isn’t the point, but that small change is part of a larger goal — burying the version number so that Firefox users never know which version they’re using — and that goal is angering many Firefox users. The versionless software model works well for web apps — like Gmail or Facebook — but Firefox is not Gmail. No matter how much Firefox wants to ape web apps, it’s not a web app. In the eyes of most users installed software is judged by a different set of standards.

Even many who aren’t bothered by the move to the rapid release schedule Mozilla has adopted from Chrome, stop short of embracing a completely versionless Firefox. "While I understand that the UX team wants to make version numbers less important," writes Tyler Downer, "removing them from the About window is not the answer."

So what is the answer? Maybe the Chrome web browser.

Increasingly that seems to be where web developers are going, leaving Firefox for Chrome or Chromium (the open source version of Chrome). According to StatCounter, Firefox’s worldwide usage stats have been slightly, but steadily, declining since September 2010.

Here at Webmonkey Firefox has been falling much faster of late, losing roughly 3 percent every month for the last three months (with Chrome picking up the majority of those users). Three months ago happens to roughly correspond to Mozilla’s first rapid release cycle offering, Firefox 5.

With Firefox losing ground to Chrome across the board, snubbing anyone, let alone the web developers who were no small part of Firefox’s initial success, seems like a misguided strategy. But misguided or no, it seems to be the strategy Mozilla is embracing.

See Also:

Tags:
File Under: HTML5
Aug
17
2011

A Quick Guide to Using HTML5 Forms

By

Web forms are everywhere—contact forms, comment forms, sign up forms—these days you’d be hard pressed to find a website without a form. Sadly, HTML wasn’t originally developed with forms in mind and working with forms on the web is more difficult than it should be. Even something as basic as adding a date-picker to a search form requires JavaScript. But HTML5 forms will change that.

In HTML5 forms get a shot in the arm with dozens of new tricks, including, yes, a built-in date-picker. As with much of HTML5, the new form elements are designed to make developers’ lives easier by off-loading tasks like rendering a date-picker to the web browser.

If you haven’t had a look at the new HTML5 form elements, Robert Nyman, a Technical Evangelist for Mozilla, has a very thorough post examining all the new input types, attributes and elements for HTML5 forms. Even better, Nyman has plenty of examples, demos and sample code to show how each element works. As you can see from the screenshot above (taken in Opera) the default datepicker is pretty ugly, but fear not Nyman covers how to style the new elements as well.

Of course, as with all things HTML5-related, the new form tags are not supported in every browser. In fact, when it comes to HTML5 forms, Opera is the only browser that’s anywhere near full support. The developers over at Wufoo have a page devoted to tracking HTML5 form support in browsers, which is well worth checking out before you decide to dive in with both feet.

Like much of HTML5, support for the new form elements is uneven and it might be a bit early to rely solely on HTML5 form tools in production sites, but it’s never too soon to learn the basics.

See Also:

Tags:
« OLDER POSTS