Aug 26, 2010

Progressive Enhancement: Explained

Phil Powell Accessibility, Web 0 Comment

Webdesigner Depot have a really well-written feature on the oft-misunderstood subject of progressive enhancement:

A lot of designers think progressive enhancement only benefits those users who are using outdated browsers, but other users benefit, too. Mobile browsers are the most likely to take full advantage of progressive enhancement. The reasons for this are two-fold. First, mobile browsers that don’t support CSS or JavaScript can still display the content of your site. While most modern smart phone browsers support at least one of those, not all browsers for basic cell phones do.

It’s worth reading the whole article, which includes some very clearly explained advice, including how to sell the benefits of progressive enhancement to clients:

When working on your own, personal website projects, progressive enhancement is something you can implement without a problem. When dealing with clients, however, it can get a bit trickier. A lot of clients are still stuck on the idea that their website needs to appear exactly the same in every browser they’ve ever used. Ever.

Explain the benefits of progressive enhancement to your clients. Tell them that it’s faster and less expensive for them to have you design the site with progressive enhancement in mind, and that their visitors likely won’t care either way, as long as the content is available.

It’s worth noting that progressive enhancement is not the same thing as graceful degradation. This article from A List Apart explains it best:

Progressive enhancement focuses on the content. Note the difference: I didn’t even mention browsers.

Content is the reason we create websites to begin with. Some sites disseminate it, some collect it, some request it, some manipulate it, and some even do all of the above, but they all require it. That’s what makes progressive enhancement a more appropriate paradigm. It’s why Yahoo! swiftly adopted it and used it to create their Graded Browser Support strategy.

Aug 26, 2010

Motorola acquires 280 North. But why?

Phil Powell Applications, Mobile, Web 0 Comment

280 North wowed people with the creation of their web application framework Cappuccino, which is built on an impressive new programming language, Objective-J. The whole framework is modelled on desktop development with Objective-C for Mac OS X, and it can do some pretty amazing stuff – it’s like Cocoa but for the web.

Techcrunch report that 280 North has been acquired by Motorola for a whopping $20 million, quoting a Motorola spokesperson:

“I can confirm that Motorola acquired 280 North earlier this summer. The transaction provides Motorola with specialized web-app engineering talent and technology that will help facilitate the continued expansion of Motorola’s application ecosystem. We believe 280 North will be instrumental in helping us continue to foster the Android ecosystem with innovative web-based technologies and applications.”

I really don’t understand the logic behind this acquisition, and suspect it could mean the end of the great open-source work that 280 North have done.

Motorola are committed to developing for the Android platform, so why acquire technology which is so intrinsically tied to the Mac platform? Objective-J is essentially a webified version of Objective-C; the look-and-feel of Cappuccino’s UI elements are based on the Mac UI, and the development tools feel just like Mac apps.
Cappuccino’s aim was to bring the ease of developing desktop applications to the web: it’s about creating web applications which feel like desktop applications. Motorola have very firmly positioned themselves in the mobile market, so why the interest in web applications which feel like desktop applications? Even if they are branching out into the development of tablet devices for the home, surely it makes sense to develop technology for a touch UI? Touch is not what Cappuccino is about – Sproutcore is way ahead of the game in this area.

I’m ready to be proven wrong, but this seems like a knee-jerk acquisition. This isn’t about acquiring 280 North as a viable company, or Cappuccino as a platform for further development – it’s about acquiring the clever brains behind this web app framework for Motorola’s bespoke purposes. It’s right there in that Motorola statement: “the transaction provides Motorola with specialized web-app engineering talent”.

Aug 24, 2010

Further Thoughts on CSS, Experiments and Icons

Phil Powell Accessibility, CSS, Design, Web 0 Comment

Matt Ward has written a follow-up to the really good article he posted last week, expanding on his thoughts and responding to some of the discussion which has been raised. He talks about the distinction between experimental techniques intended as an educational resource, and commercial resources which encourage bad practice:

Yes, I don’t think that (most of) the CSS experiments are meant to be practical. I also agree that they are have entertainment value, though I think they have even greater value as an educational resource. As long as these things are generally understood, then there’s really no issue, and if things had stayed that way, I would probably not have written the article at all.

However, when we actually start charging money for these icons – as with the Peculiar set – that places everything in an entirely new light, which I have termed the implication of cost. As long as everything remained in in the experimental stage, all this unique CSS work remained could be understood as primarily theoretical and conceptual. The moment we put a price tag on it, though, the implications change.

Charging people for the icons is essentially a means of sanctioning their use in a production environment and are stepping firmly across the line between the experimental and the implementable. When this happens, I think that there is an argument, because we are no longer just in the realm of the experimental, and the message we are sending is the wrong one.

I totally agree, and any web developer worth their salt will be wary of implementing any of these experimental techniques in a production environment. Font replacement techniques like Cufón and sIFR have their detractors, but at least these techniques degrade gracefully – even @font-face is designed to degrade so that it doesn’t interfere with the browsing experience served up by unsupported technology. But as soon as you start to use wild CSS for the design of graphical icons, or start fudging dingbats to convey visual context where it doesn’t belong, you create horrendous accessibility problems and degrade the user experience ungracefully.

Aug 21, 2010

Pure CSS Icons: Make The Madness Stop

Phil Powell CSS, Design, Web 0 Comment

Faruk Ateş on the impracticalities of CSS as a tool for designing icons:

During the design phase, being able to tweak the pixel look and dimensions of an icon should be as simple as possible; adjusting many lines of CSS code to do this is not it, especially if you didn’t write the CSS originally. You want that icon a little bigger? Tough luck, it was created by someone else at 32 by 32 pixels, now it’s up to you to figure out how to make it all work for 36 by 36. Similarly, implementing an icon should be as simple as writing a CSS background property or adding an <img> tag. It shouldn’t involve adding six meaningless HTML elements nor twenty lines of CSS per icon.

Aug 21, 2010

Are We Taking CSS Too Far?

Phil Powell CSS, Design, Web 0 Comment

Matt Ward has written a wonderfully insightful and informed post asking whether some recent CSS experiments are pushing the technology beyond what it was designed for.

Each of these experiments takes a different approach. Some, like the line graph, have some practical applications in the real world, while others like the CSS fail whale are completely and entirely impractical. It’s certainly interesting to know that it can be done, but that doesn’t necessarily mean that it should be done.

This trend for the use of CSS as a design tool has been bugging me for a while now, and Matt hits on the very heart of the problem, drawing parallels with table-based layouts:

If you’ve been around the web design and devlopment industry for very long, you probably already know how much of a faux pas table-based design is considered. Well, when it comes to CSS icons, consider these thoughts:

Bloat – All the necessary CSS declarations will really bloat up your style sheets, making them an absolute nightmare to manage. Wait, didn’t I just write those same words? Also, depending on how the icons are achieved, you might find your HTML bloating up with extra elements too.

Inflexible – Again I admit that people have done some really incredible things with CSS, but compared with a real graphics program, CSS generated graphics are incredibly limited in what they can do.

Purpose – As we’ve already discussed at some length, CSS wasn’t designed as a tool for creating graphics, despite the fact that people are able to do some pretty amazing things with them, like the Peculiar and social media icons we’ve already looked at. Impressive? Yes. The right tool? No.

Many of these CSS experiments are very worthy exercises to show the possibilities and extremes of what the technology can do – but most aren’t practical for production use. CSS is a technology for defining rules about how content should be visually presented; it’s not a tool for generating graphics.

Aug 17, 2010

Pictos: scalable web icons using fonts

Phil Powell Accessibility, Design, Web 1 Comment

Pictos is an interesting concept in web icons, which has been released by Drew Wilson.

Instead of the traditional method of using images to display icons on web pages, Pictos uses a font, in the style of Dinbats or Webdings, which can be implemented using @font-face.

It’s an interesting concept. The main advantages appear to be improved speed and better scalability (the icons will scale just like any font). But there are some serious accessibility flaws. Since the font characters appear to be mapped to the standard alphabet (i.e. the “refresh” icon is mapped to the letter “C”), using this technique is a horrendous headache for anyone using a screen reader, and will be very bad for your SEO. One of the examples shows an example using CSS :before selector to prepend an icon to content, which kind of gets around those problems, but still feels a bit clunky to me: the whole HTML/CSS stack seems to be broken.

A good effort, but I’m not sure this technique is ready for the mainstream.

UPDATE: The guys at Filament Group have done some casual testing of the accessibility of this technique with a range of proposed solutions. Sadly, the results aren’t promising – even the “:before” technique breaks things. My gut feeling is that this still isn’t a particularly graceful technique, and the only viable fix is to map the Pictos “alphabet” to appropriate unicode characters. But, even then, the implementation would be tricky for anyone who lacks a rudimentary grasp of unicode.

UPDATE 2: Looks like the very talented Jon Tangerine has come to similar conclusions: the only way this can really work is by mapping the icons in the font to sensible Unicode code points. But identifies still more problems with the technique, even if the semantics discrepancies were dealt with: more accessibility gripes, the reliance on @font-face support and the difficulties of a graceful fallback.

Drew suggests you can kind-of wrangle the markup into something sort-of semantic. However, it starts to fall down fast. For example, a check mark (tick) is mapped to ‘3’. There’s nothing semantic about that. Clever replacement techniques just hide the evidence. It’s a hack. There’s nothing wrong with a hack here and there (as box model veterans well know) but the ends have to justify the means.

Jon explains things far more eloquently than I can, so I suggest you read his balanced and reasoned post.

Aug 17, 2010

Adobe fonts come to Typekit

Phil Powell Design, Web 0 Comment

Bryan Mason announces a partnership with Adobe which brings a set of popular Adobe fonts to Typekit:

Adobe and Typekit are teaming up to bring some of the world’s most popular, recognizable, and respected fonts to the web. Starting today, you’ll be able to use classics like Adobe Garamond, News Gothic, Myriad, and Minion plus many more on your website — all of them newly optimized and hinted for the screen.

Although there are only twenty-six fonts being added to the collection, they include some of the most popular and elegant fonts in use today. The fact that Adobe have taken the effort to ensure they are properly hinted for screen use is another bonus:

We’ve been using these fonts internally here at Typekit for a few weeks and the quality is simply amazing. These are the original cuts of the celebrated typefaces you’ve been waiting for, not reproductions or knockoffs of their designs. That means you can use them with the assurance that your creative work is being presented with all the accuracy and technical detail the print world has known for decades.

I’ve been watching the evolution of Typekit for a while now, but haven’t used it in any production work yet. This may just be the tipping point where many people take a second, serious look at Typekit as a viable tool for bringing elegant typography to their web designs – $49 per year is a pretty good deal, particularly when you compare the cost of the average font license.

Aug 14, 2010

Announcing the jQuery Mobile Project

Phil Powell Mobile, Web 0 Comment

John Resig on the forthcoming jQuery mobile project:

The jQuery project is really excited to announce the work that we’ve been doing to bring jQuery to mobile devices. Not only is the core jQuery library being improved to work across all of the major mobile platforms, but we’re also working to release a complete, unified, mobile UI framework.

This looks great, and with a track record of delivering solid, well-documented code, this is going to be a welcome addition to the jQuery family. A unified approach to mobile web UI is desperately needed, and sounds like they are going to be targeting a wide range of platforms:

The critical difference with our approach is the wide variety of mobile browsers we’re targeting with jQuery Mobile. We’ve been working hard at bringing jQuery support to all mobile browsers that are sufficiently-capable and have at least a nominal amount of market share. In this way we’re treating mobile web browsers exactly how we treat desktop web browsers.

And, they’re approaching the visual design in a good way: talking in terms of “design language”:

From a design perspective, we have a unique challenge because we need a universal design system that will feel “right” on a broad range of devices instead of directly mimicking the design style of a particular platform.

To that end, we aim to synthesize a touch-friendly design language that can work well across a range of form factors from smartphone to tablet and a range of mobile platforms. A new ThemeRoller tool will be developed that will allow designers and developers to quickly design a custom theme that fits their color scheme and style to make a highly branded experience possible across all devices and browsers.

It’s worth reading the entire strategy statement.

Aug 13, 2010

The re-introduction of real URLs on Twitter

Phil Powell Web 0 Comment

MG Siegler on the re-introduction of real URLs on Twitter:

The link shortening revolution that has taken place the past few years has been interesting for a number of reasons. But one of the most interesting aspects is that we’re all now trained to click on a URL even if we have no idea what it actually is. Sure, you may be visiting TechCrunch.com, but in Twitter’s stream, it has been hidden as http://bit.ly/lkowieofi or the like. Twitter Tweet Button changes that.

The new Tweet Button, which was officially unveiled by Twitter earlier today (and is already up and running on TechCrunch), by default wraps all links in Twitter’s own t.co URL shortener. But this shortening is only for the pop-up tweet box and so Twitter can make sure the URL isn’t a malicious one. When it is sent out to your tweet stream, you’ll now see the actual URL (though abbreviated).

The obfuscation of URLs due to widespread use of Twitter has been a real annoyance, as it essentially breaks one of the fundamental features of the web: simple structure and context through a human-readable address. It’s encouraging to see that Twitter is finally making efforts to fix this: being able to see where a link leads will enrich the service and allow for easier filtering of useful links by users.

Apr 15, 2010

Apple’s iPad: easy reading for the blind

Phil Powell Accessibility, Design 1 Comment

Here’s a really interesting piece on Forbes about the iPad being hailed as a great e-reader for the blind.

Ask any PC-loving computer nerd why Apple products have become the de facto choice of the masses, and you’ll likely hear something like, “People buy Apple products because they’re pretty.” That may be true for many, but one group of consumers who care little for Apple’s prodigious aesthetics are the blind.

They care more about how Apple products actually work. And while the iPad may be Apple’s most controversial launch in recent memory, the blind community is unanimous in its support.

This resonates with what I wrote recently in a piece about adaptive accessibility. Apple really do take accessible, functional design seriously – not just as an afterthought, or a secondary consideration. Accessible functionality is built right in to the very core of their design of software and software interaction. The very fact that Apple invested time and energy in making Voiceover a core element of OS X at an early stage, has allowed the technology to improve and proliferate, so that it can be seamlessly integrated into cutting-edge devices like the iPhone and, now, the iPad.

I would even go so far as to say that this kind of attention to accessibility for all is what makes Apple’s mobile products so successful as market-leaders: the benefits of accessible design are experienced and appreciated by all; accessible design enhances everyone’s experience.

First, consider what an e-reader represents to the blind community. The concept of an affordable, portable device that allows the visually impaired to consume media easily and without special consideration is an exciting proposition, but one never fully realized.

The iPhone and the iPad are both adaptive devices. Most people will never use the accessible features they provide; probably never even know that they exist. But the ability for users to adapt their use of the device to meet their own specific needs is what is so empowering. These aren’t specialist, assistive devices: they are desirable, cutting-edge consumer products. They make disabled people feel included; perhaps even makes them no longer disabled. This is a really fantastic thing.

Computer nerds, tech columnists and the general public may not know where the iPad fits into the existing media consumption landscape–but the blind and visually impaired see it as the only e-reader worth owning. Call it further proof that Apple is more than just a pretty face.

And I don’t think it’s just blind users who are going to benefit from these kinds of advances in consumer technology – touch interfaces might be a huge win for people who have been constrained by having to use a mouse and keyboard. Gestures can be a much quicker and more intuitive way to navigate within a digital space – why do you think the scroll-wheel became so popular?

« 4 5 6 7 8 9 10 11