<a id="blog_header" href="http://mowser.com/web/http%3A%2F%2Fwww.webmonkey.com%2F" name="blog_header"> Webmonkey

File Under: Programming, Software, UI/UX, Visual Design

Feb

2012

Video: Inventing on Principle

[ http://player.vimeo.com/video/36579366?byline=0 ]

We just had a moment similar to the time we first saw content-aware scaling in action, but this time it’s even better — we’ve seen the future of programming tools and it looks awesome.

Check out the video above of Bret Victor‘s recent talk, “Inventing on Principle.” Victor has worked on experimental UI concepts at Apple and also created the interactive data graphics for Al Gore’s book, Our Choice. The video above of Victor’s keynote at the Canadian University Software Engineering Conference, captures a wonderful talk on living your life based on principles, but for many developers what’s most arresting are the software development tools demoed.

Do your current tools suddenly feel incredibly outdated? Perhaps you thought you were using a well-tuned coding machine but suddenly realize you’re really just hitting two stones together? Thought so. Sadly, the apps demoed in the video aren’t available. That’s all right, though; it just means someone needs to build them. Be sure to let us know if you do.

Tags: video

File Under: Web Basics

Feb

2012

A Guide to Understanding Page-Speed Tests

Photo: tobias.munich/Flickr

Anyone who’s ever tried to optimize a website has faced the very basic question — how long does your site take to load?

The answer seems like it would be easy to discover: Load your site in a page speed crawler like WebPagetest and soon you’ll have your numbers. But that’s just it; you won’t have a number, you have numbers and figuring out which numbers to listen to is trickier than you might think.

Strangeloop’s Joshua Bixby recently tackled the performance metric question in a blog post titled a Non-Geeky Guide to Understanding Performance Measurement Terms. The whole article is well worth reading, but perhaps the best advice is to make a video of the page load. “If you want to get a ground-zero look at your siteâ€™s performance,” writes Bixby, “capturing videos and filmstrip views of your pages’ load times are one of the best ways to go.”

The filmstrip view Bixby refers to is part of the WebPagetest results and shows what the visitor sees in a progressive series of page captures. To create a filmstrip or video test of your website, head over to WebPagetest and select the “visual comparison” tab.

Some common performance mistakes Bixby cautions against include using “response time” and “load time” interchangeably and “not realizing that ‘response time’ can mean any number of completely different things.”

To help those unfamiliar with the nuances of loading metrics, Bixby then breaks down and defines all the terms, including what exactly is meant by “start render” or “time to first byte,” as well as some caveats to bear in mind when going over the numbers for your website.

While Bixby’s post can be extremely helpful, especially to those who are just starting out in the often confusing world of website optimization, bear in mind that testing sites like WebPagetest are no substitute for real-world tests. “As a matter of due course, you always need to gather large batches of data and rely on median numbers,” writes Bixby, “but you also need to periodically get under the hood and take a real-world look at how your pages behave for real users.”

Tags: performance, speed

Post Comment | Comments (1) | Permalink

File Under: Browsers

Feb

2012

Mozilla Building Metro Version of Firefox for Windows 8

By Jon Brodkin - Ars Technica

Mozilla developers are planning to build a dramatically different version of Firefox for Windows 8, a change necessitated by Microsoft’s use of the touch-friendly “Metro” user interface for PCs and tablets.

Mozilla describes its Windows 8 plans as part of a 2012 Strategy & Roadmap document updated yesterday. A technology proof-of-concept demonstrating the feasibility of Firefox in Windows 8 is planned for the second quarter of this year, with timing dependent on the release of Microsoft’s Windows 8 consumer preview and developer documentation. A Metro version may be necessary for Firefox to avoid being shut out of Windows 8 tablets running on ARM, which will have only a limited “traditional” Windows desktop. But Mozilla is apparently planning Firefox builds both for the traditional Windows desktop environment and Metro.

“Windows 8 contains two application environments, ‘Classic’ and ‘Metro,’” Mozilla notes. “Classic is very similar to the Windows 7 environment at this time, it requires a simple evolution of the current Firefox Windows product. Metro is an entirely new environment and requires a new Firefox front end and system integration points.”

Metro Firefox will be a new Gecko-based browser focused on touch interactions, with both full-screen and partial-screen modes, with the possibility of a live tile so that users can see updates on the Start screen. There are several unanswered questions, such as which programming language to use for building the Metro front end. Firefox product manager Asa Dotzler further notes that “This proposal depends on Microsoft providing the same capabilities for Firefox as it does for IE—running at the Medium level integrity process that allows us the full use of the Win32 API and what we need from Metro, or a set of APIs that allow Mozilla to port Gecko to the WinRT. For the purposes of this feature proposal, I’m assuming we’ll get the first and we won’t have to port the bulk of Gecko and instead will use the win32 dlls from within Metro.”

Firefox accounts for about 20 percent of worldwide desktop browser market share, but has lost ground to Google Chrome over the past year. Chrome will presumably have a Metro version for Windows 8 as well, but Google has made no official announcement.

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

Tags: firefox

Post Comment | Comments (1) | Permalink

File Under: Browsers

Feb

2012

Mozilla Experiments With Fancier New Tab Page in Firefox 13

The proposed new tab page in Firefox 13

Mozilla is considering a fancier new tab page that will replace the current blank page presented when users create a new tab in Firefox. Like other browsers, Firefox will soon offer users a set of thumbnails on the new tab page with website recommendations based on the most frequently and recently visited pages in Firefox’s history.

If you’d like to see the new page in action you’ll need to download the Aurora channel build of Firefox. (Alternatively you can use the Nightly channel.) The new tab page will be enabled by default in Aurora until Feb. 16 for testing purposes. After that the feature will be hidden away while more work is done. Head over to Firefox Engineer Tim Taubert’s blog for details on how to re-enable the new tab page if you’d like to keep using it after that date.

The new tab page in Firefox looks similar to what you’ll find in Chrome and Opera. Indeed, every web browser’s new tab page is essentially a variation on what Opera pioneered with its “speed dial” page. The basic idea is to provide a quick way to access sites you frequently visit. Mozilla’s take thus far is to pull a mixture of your most frequently and most recently visited sites and display them in a 3-by-3 grid of thumbnails.

The goals for Firefox’s new tab page are ensuring that the page loads instantly, that it isn’t distracting and that it requires zero configuration. The latter explains why, thus far, the new tab features don’t offer much in the way of customization.

There are options to “pin” a site permanently to the grid, delete a site and rearrange the order of the sites. Each site will display a thumbnail once you’ve click on it. Or at least that’s the theory. As the screenshot above demonstrates there are clearly still some bugs in the screenshot feature.

The new tab page may be a little bit of a me-too feature at this point, but for those who have been wanting it, rest assured it’s coming. Firefox 13, which is when the fancier new tab page is slated to arrive is due in June 2012.

Tags: firefox

File Under: CSS, Web Standards

Feb

2012

Web Developers Sound Off on WebKit Prefixes

Photo: Ariel Zambelich/Wired.com

Yesterday we told you about a disturbance in the web standards force, a supposed rash of websites that work in one and only one web browser. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit, the engine that powers Safari, Chrome, iOS and Android web browsers.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

We aren’t the only ones who think that spells disaster not just for web standards but for the long-term viability of the open web. In fact the response from the web community has all but drowned out everything else in our RSS and Twitter feeds.

Here’s our round-up of what’s being proposed, what it might mean for the web and how we might go about solving the problem:

First and foremost read the minutes from the CSS Work Group meeting, which is where all of this started. The legend for the names is at the top of the page, though you’ll need to scroll about half way down to get to the actual meat of the discussion.

The second must-read post on vendor prefixes comes from CSS Working Group Co-Chair Daniel Glazman who calls on other browser makers to not implement the -webkit prefix and asks developers to make the extra effort to build cross-browser apps. Glazman has since followed up that piece with two more, one clarifying the original post and one defending the CSS Working Group against those who argue that the reason prefixes exist is because the standards process is too slow. If you believe that the CSS spec moves to slowly, this post is well worth a read (spoiler alert: it’s typically browser makers arguing, not the standards process, that creates the hold up on new features).

Remy Sharp of HTML5Doctor fame, weighs in with a series of rough ideas, neatly summarizing the issue and looking at it from both sides. In the end Sharp seems to conclude that just about everyone is to blame, from the browsers to the working group to developers.

Rachel Andrew of the web standards project generally agrees with Glazman writing, “once again we run the risk of having sites built only for one platform, and [will] find it very hard to get that platform to go away if things move on.”

The ever-humorous Bruce Lawson, who works as a web standards evangelist at Opera Software, writes: “Personally — PERSONALLY — I’m pretty depressed about all this. I’ve spent 10 years — pretty much since IE6 came out — evangelizing cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.”

Over at Quirksblog mobile expert Peter-Paul Koch argues that vendor prefixes are just plain wrong: “Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.” He goes on to propose an interesting idea of vendor-neutral prefixes like -alpha and -beta for experimental features.

Aaron Gustafson, a member of the Web Standards Project, has started a petition to ask Mozilla, Microsoft and Opera to not implement -webkit. Gustafson also has a one-line bash script you can use to search your code for any instances of the -webkit prefix so you can double check to make sure you’re supporting other browsers as well.

Mozilla developer Christian Heilman believes that “this mess has partly been created by developers, the least we can do is help fix it.” To that end Heilmann’s Pre-fix the web project is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

JavaScript developer Peter van der Zee has some other possible solutions: “Either we strongly limit the life span or availability of the prefix by making them only available in beta versions of a browser. Or we force other vendors to pick up on the slack by giving them a certain time to come up with their own implementation of a certain feature, or forfeit that possibility after a certain amount of time.”

Finally, if you read through the CSS WG notes you’ll notice that Tantek Ã‡elik cites developer Lea Verou as an example of web developers who use just the -webkit prefix. In fact that’s completely untrue and Ã‡elik has since corrected his statement. Verou has long advocated using all prefixes and even created prefixfree to help automate the process.

Tags: CSS, CSS Working Group, Webkit

Post Comment | Comments (5) | Permalink

File Under: CSS, Web Standards

Feb

2012

WebKit Isn’t Breaking the Web. You Are

WebKit may seem like the only game in town, but it's not. Photo: Ariel Zambelich/Wired.com

It sounds like something from a galaxy far, far away, but in truth it was not that long ago that the web was littered with sites that proudly proclaimed “works best in Internet Explorer.” Thankfully those days are over. IE6 no longer dominates the web.

But, while IE6 may be a thing of the past, the root problem â€” websites that work in one and only one web browser â€” sadly, remains.

This time the culprit is WebKit, the rendering engine that powers the browsers on the iPhone, iPad and Android phones. But what’s different about this round of monoculture is that, unlike IE 6, the WebKit developers haven’t done anything wrong. It’s web developers that have created the WebKit-only web.

Instead of writing code that will work in any browser, which might mean adding an extra three lines of code to their CSS rules, some of even the largest sites on the web are coding exclusively for WebKit.

The problem is bad enough that on Monday at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren’t.

The danger is that if other browsers implement -webkit prefixes then the entire CSS standards effort will be broken. Instead of coding against a single CSS specification developers will need to code against changing vendor prefixes. As CSS Working Group co-chair, Daniel Glazman, says, “I don’t think this is the right way. And this is the first time in this WG that we are proposing to do things that are not the right way.”

Vendor prefixes like -webkit and -moz were designed to help web developers by allowing browser makers to implement CSS features before the official standard was published. Prefixes were intended to help speed up the process of adding new features to the web and, used properly, they have worked. Unfortunately they’ve also been widely abused.

WebKit is currently the dominant mobile browser in the mind of most web developers (that Opera is actually the single most widely used mobile browser). But even the perceived dominance of WebKit is not the real problem. The problem is — just as it was last time — that web developers are developing exclusively for WebKit.

To be clear, Firefox, IE and Opera also support these features. In most cases, the -webkit properties being used have -moz, -ms and -o prefix equivalents for use in the respective browsers. Popular CSS 3 features like border-radius, transforms, gradients and animations work in all modern browsers. Developers simply need to add those three additional lines of code to make their websites compatible with Firefox, IE and Opera. But they aren’t doing that.

That the problem lies with web developers, not the browsers, led Glazman, to put out a call for action, asking web developers to “stop designing web sites for WebKit only, in particular when adding support for other browsers is only a matter of adding a few extra prefixed CSS properties.”

Neither Glazman, nor anyone else is suggesting that Apple and Google should stop innovating or stop implementing new features as fast as they can. As Tantek Ã‡elik, a Mozilla representative in the CSS WG, says in the minutes of Monday’s meeting, “I think it’s great that Apple wants to innovate as fast as they can…. I don’t want Apple to slow down in innovation and implementing new things. That helps the Web grow and innovate.”

At the same time both Apple and Google have set some bad examples by building a number of WebKit-only demos that might be part of what lead some developers to conclude that only WebKit supports such features. That has also spilled over into the world of tutorials where even sometimes even standards advocates showcase -webkit in their sample code while ignoring -moz-, -ms- and -o-*.

What makes the current -webkit-only epidemic all the more depressing is how easy it is to solve — just use prefixes they way they were intended. Thanks to modern toolkits you don’t even need to write any extra code. Preprocessors like SASS and LESS make it easy to output five lines of prefixed code with a single mixin. Not a fan or SASS or LESS? No problem, just use cssprefixer, which parses your CSS and adds any prefixes you need before you publish it to the web (there’s also a client-side auto-prefixing solution if you prefer).

That’s fine for your website, but what about all the rest of those top 30,000 sites you don’t control? Well, you could email the developers, let them know that their site isn’t working in the most popular mobile web browser; let them know that you can’t use their service. If you’re a programmer or web developer you can help out with Mozilla developer Christian Hellman’s effort to Pre-fix the web. Pre-fix the web is looking for developers willing to seek out projects on Github that only work in Webkit and then fork the project, adding the missing prefixes to the CSS, extending JS code to do proper feature detection and then sending a pull request. In other words, literally fixing the web.

We at Webmonkey hope it’s obvious that building WebKit-only sites is a waste of time. If you’re only interested in iOS users then take a tip from Instagram and build a native app. As Peter Linss, Hewlett-Packard’s CSS WG representative says the CSS WG minutes, “there’s no advantage to the Web to have someone write a platform-specific website.” There’s also no real advantage for the developer, especially when an automated prefixer can do all the work for you. If you want your site to embrace the web, take the time to learn the craft and embrace all of the web. Be good at what you do and do it right.

Tags: CSS, internet explorer, Webkit

Post Comment | Comments (2) | Permalink

File Under: Browsers

Feb

2012

Chrome 17 Released, Will Preload Autocompleted URLs as You Type

By Ryan Paul - Ars Technica

Google has just released Chrome version 17, which brings several minor enhancements to the company’s web browser â€” including a new web address preloading feature and improved protection against malicious downloads.

The new Chrome introduces a “preemptive rendering” feature that will automatically begin loading and rendering a page in the background while the user is typing the address in the omnibox (the combined address and search text entry field in Chrome’s navigation toolbar). The preloading will occur in cases when the top match generated by the omnibox’s autocompletion functionality is a site that the user visits frequently.

When the user hits the enter key and confirms the autocompletion result, the pre-rendered page will display almost instantly. The feature extends Chrome’s existing predictive page loading functionality to autocompletion results. Unlike Chrome’s instant search capability, however, the autocompletion preloading waits until the user hits the enter key before displaying the rendered page.

Google has also added some new security functionality to Chrome. Every time that the user downloads a file, the browser will compare it against a whitelist of known-good files and publishers. If the file isn’t in the whitelist, its URL will be transmitted to Google’s servers, which will perform an automatic analysis and attempt to guess if the file is malicious based on various factors like the trustworthiness of its source. If the file is deemed a potential risk, the user will receive a warning.

Google says that data collected by the browser for the malware detection feature is only used to flag malicious files and isn’t used for any other purpose. The company will retain the IP address of the user and other metadata for a period of two weeks, at which point all of the data except the URL of the file will be purged from Google’s databases.

Users who are concerned about the privacy implications of this functionality can prevent the browser from relaying this information to Google by disabling the phishing and malware protection features in the browser’s preferences. You can refer to the official Chromium blog for additional details about the malware detection feature.

Chrome 17 is available through the browser’s automatic updater and can also be downloaded from Google’s website. More information about the new release is available in the official Google Chrome blog.

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

Tags: chrome, Google

File Under: CSS, Visual Design, Web Standards

Feb

2012

Responsive Design Tricks: Fluid Typography With CSS 3

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. That there is no such thing as “pixel perfect” has long been a maxim of good web design, but nowhere is this more true than when you start working with percentage widths, em-based type and other flexible techniques of responsive design. While fluid grids, adaptive images and other tools help, sometimes even basic things like the flow of type can look wrong without a little extra help.

One common problem when designing for multiple devices is handling the changes that happen when the user rotates the screen. It’s frustrating to see your elegant portrait-oriented designs fall apart as the device moves to landscape mode (or vice versa). Frequently the problem is that images, videos and other embedded content in your page is sized in relation to the pixel width of the viewport, but the type is not. That means that the type fails to adapt to layout changes, leaving ugly gaps, whitespace or hard-to-read, overly long lines.

There are a number of ways to solve this problem, but one of the simplest and easiest is to use fluid typography in addition to your fluid grid. BBC developer Mark Hurrell wrote up an excellent tutorial some time ago that shows how, by specifying font sizes in rems, you can “adjust every font-size on the page by using media-queries to change the font-size set on the BODY or HTML element according to viewport width.”

To find the right size type for various screen widths, Hurrell calculates a resolution-independent font scale based on target widths. That is then applied using a series of media queries and the new CSS 3 unit rem. The rem unit means ems relative to the root (the HTML) element. That means your type gets proportionally larger overall, rather than in relation to its parent element as would happen with a simple em. As Hurrell notes, support is pretty much universal on tablets and phones (browsers that don’t support it will fall back to px sizing, so all is not lost).

In the end what you get using rems and media queries is fluid typography that scales just like a fluid grid. That means that when the device rotates the type resizes to fit the new screen dimensions. For more details on how to make it work on your site be sure to check out the Responsive News blog post, which also has a few links to websites already using this trick.

Tags: CSS 3, typography

Post Comment | Comments (3) | Permalink

File Under: Browsers

Feb

2012

Adobe Confirms: No Flash for Chrome on Android

By Ryan Paul - Ars Technica

Google issued a beta release of Chrome for Android earlier today. The browser provides support for modern web standards and includes a number of compelling features that aren’t available in the Android’s default browser. One noteworthy Chrome desktop feature that isn’t included in the mobile port, however, is the integrated Flash runtime.

Adobe has issued a statement confirming that Chrome for Android does not support Flash content. The company also indicated that it does not plan to work with Google to add Flash support to the new mobile browser. Adobe will, however, continue supporting Flash in the current default Android browser.

“Today Google introduced Chrome for Android Beta. As we announced last November, Adobe is no longer developing Flash Player for mobile browsers, and thus Chrome for Android Beta does not support Flash content,” wrote Adobe’s Flash Platform product manager Bill Howard.

Adobe struggled for years to make the Flash player plugin viable on mobile devices. Though it was able to make Flash work reasonably well on Android phones, results were mixed on other systems. Due to Apple’s unwillingness to allow the Flash plugin on iOS and the difficulty that Adobe faced bringing the Flash player to new devices, the plugin never achieved the same ubiquity on phones that it has historically enjoyed on the desktop.

These setbacks caused Adobe to abandon its mobile Flash player strategy last year. The company announced that it would phase out development of its mobile Flash player plugin and not support it on new platforms. Adobe instead focused its mobile Flash efforts on developing tools for deploying Flash content as native mobile applications. It also strengthened its commitment to native web standards and acknowledged HTML5 as the way forward for building rich mobile web experiences.

When Google eventually moves to replace the default Android browser with Chrome in future versions of the Android platform, devices that run the operating system will likely no longer be able to play Flash content in the browser.

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

Tags: chrome, flash