I’ve sung praises over the Flash-based multimedia suite Aviary, but what’s more disruptive than an company using Adobe’s own technology to compete with them? Perhaps something that erases Flash from the equation altogether, which is what you get with Sketchpad. If enough effort is poured into this project down the road, taking desktop tools to the web browser may no longer need plugins like Flash and Air.
That still seems like a far away future, though. Even this ReadWriteWeb report, where HTML5 has been found to be sometimes more CPU-intensive than Flash, indicates it doesn’t even have that advantage in the bag.
Then there are others who can’t see how HTML5 and Flash can even be comparable, but here’s a compelling point for that argument: where are the tools for creating in HTML5? John Nack from Adobe has a few answers. Though as an Adobe guy, he advocates for Flash too.
Finally, there’s browser adoption as the biggest and most obvious issue of all. And sadly, that one might not even be resolved.
All of these beg the question: “Is it irresponsible to advocate using HTML5 before it is ready?” But when, pray tell, will it be ready?
Remember my complaint about all the CSS3 syntaxes differing from one browser to another? It’s now addressed with CSS3 Please, a jQuery-based, in-browser editor that replaces multiple attribute values of the more complicated CSS3 syntaxes (from border-radius to rgba to @font-face) all at the same time, so you don’t have to.
In addition to syncing and normalizing changes across the necessary properties, it also sneaks in IE support for a few features via IE filters. Right now it helps you write the rules for: border-radius, box-shadow, linear-gradients, rotation and @font-face. A few more transforms like skew and scale are on their way, stay tuned.
You can preview your code on the box at the right side by toggling it on and off. When you’re done, click on the clipboard icon to copy the code.
This is a smart solution to a growing problem. However, even though I’m thoroughly grateful for this tool, I still want to axe the real problem, which is the inconsistent browser syntax. It’s unreasonable for a programming language to have redundant code, and while CSS isn’t really one, it’s still code. We’re still supposed to pride ourselves with efficiency, conciseness, and standards with any kind of code. We like to kick IE for constantly breaking standards; should we tolerate the same thing for other browsers just because they’re implementing cutting edge features?
Here’s an interesting sneak peek of Adobe’s project called “Rome”, shown at the MAX 2009 conference. It’s an application written in ActionScript that combines the features of Photoshop, Flash, Fireworks, Dreamweaver, and lets you work with different content types. It runs on Air, meaning it’s cross-platform and even works inside the browser.
I certainly like the idea of a mashup app of Adobe’s most indispensable tools and perhaps this is the real sort of integration people have been looking for in the Creative Suite. It’s quite smart too: the interface is not as cluttered as other Adobe programs, and the contextual palettes appear according to the currently selected object.
That it can run inside a web browser is also another golden feature; I wonder what Aviary thinks of it. If Photoshop.com isn’t enough for you, this will certainly be more than enough.
My only question is performance. Small widgets created in Adobe Air work fine (TweetDeck, for example), but can a full-blown app work better than native code? Should Adobe be building programs like this on Air? Some of the bigger questions when dealing with Flash-based apps and its cousins.
It’s been a couple of years since the height of the “kill IE6″ web campaigns, and it took that long to hold a funeral that finally seals its fate.
Of course, the IE6 Funeral is an arbitrary event held by the Aten Design Group last March 4, and this doesn’t really eradicate the browser on computers that can’t upgrade.
Over at TechCrunch, commenter Jeff Carlson jokes: “So if someone uses IE6 to browse the web tomorrow, will their web browser be a Zomb-ie6 browser?” You could say that. After all, IE6 is way past its expiration date, sucking the brains out of web designers and developers with its buggy, unstable, insecure features from an ugly past.
Even Microsoft acknowledges it’s time for IE6 to go, as it actually sent over flowers and this note:
Thanks for the good times IE6, see you all @ MIX when we show a little piece of IE Heaven. The Internet Explorer Team @ Microsoft
On March 13, Google will end IE6 support on YouTube, following the March 1 pull-out for Google Docs and Google Sites. Gmail and Google Calendar are next on the list, slated by the end of the year.
Combined with the European government security warnings to upgrade browsers, could Google’s systematic phase-out be the final nail in the IE6 coffin, or is this slow death going to take at least another year?
I really hope this is it.
It’s a disappointing day when you find a single serving site that generates the comprehensive syntax for the border-radius property, aptly named border-radius.com. Because not all browsers (and browser versions) support the latest and greatest things CSS3 can do, one has to resort to browser targeting yet again. Only this time, one browser’s syntax is different from another browser’s, and becomes a chore to write CSS for each.
There’s a pretty obvious explanation for the existence of browser-specific properties from SitePoint:
Vendors—browser makers—are free to implement extensions to the CSS specifications that, in most cases, are proprietary to their browser. They may do this for a number of reasons, such as adding new features for users, or for experiments and debugging. Most often, though, the extensions are used to release and test browser features that have been developed in the preparation of W3C drafts that have not yet reached Candidate Recommendation status—the extensions allow these new properties to be widely tested before they become available as standard CSS properties.
So for starters, the browser-specific CSS has prefixes like:
-moz: Gecko-based browsers like Firefox-webkit: WebKit-based browsers like Safari and Chrome-ms: Internet Explorer-o: Opera-khtml: Konqueror
(The complete table is listed at the W3C.) That’s fine, but what I don’t get is why the syntax following the prefix isn’t always the same as the standard CSS syntax. The border-radius property is just one example, which is peanuts compared to the gradients syntax. Compare:
-webkit-gradient(
linear,
left bottom,
left top,
color-stop(0, rgb(0,10,148)),
color-stop(1, rgb(45,58,246))
)
-moz-linear-gradient(
center bottom,
rgb(0,10,148) 0%,
rgb(45,58,246) 100%
)
Sure, we can turn to generators like WestCiv’s and Damien Galarza’s—and we’ll probably be increasingly dependent on them in the future as CSS capabilities and their corresponding syntaxes grow more complex. But why must browser vendors insist on that when it only multiplies the code and maintenance necessary? Does it have to do with the way their engines parse the code, or something less significant?
Coming Together is a font consisting entirely of different ampersands designed created by 400 artists and designers to help the Haiti earthquake victims. It’s available for $20 from leading font distributors and all proceeds go to Doctors Without Borders.
The “Coming Together” font contains over 400 glyphs and is supplied as a single, cross-platform OpenType font. All glyphs are accessible using OpenType-savvy applications, Unicode-savvy utilities, the Character Map utility on Windows, and FontBook on Mac OS X.
This is the fourth Font Aid initiative by the Society of Typographic Aficionados, the first one in 1999.
While it’s a bit late to write about this, it’s never too late to help Haiti out. What is unfortunate, however, is that another major earthquake has struck, this time in Chile. Tsunami warnings have been hoisted across the Pacific as well. I hope the Type Society and other groups extend their help for this particular disaster too.
No, this is not about plagiarism.
Imagine my surprise when Jeffrey Zeldman blogged about a list of 60 WordPress themes. A few minutes before that, I found Douglas Bowman bookmarking another list, also from Smashing Magazine. It’s like my feed reader was trying to tell me something: yes, a list article can bring an interesting discussion if you’ll just let it.
Back to Zeldman’s post, which started a discussion on whether you should use existing themes for your own design:
…Even if you are a designer, you may ask yourself if you really need to perform that next site redesign from scratch.
Every once in a while I get clients that specifically want existing themes to be customized instead of starting from scratch, so clearly there is a demand for the practice. If clients have enough initiative to choose it as a solution, then why not? Does it take more effort to find and customize than start from scratch? Depends on how comfortable you are with someone else’s code, how much you trust the other designer’s expertise, and how much you need to customize.
The bulk of the debate will probably lie mostly in this situation, but to me it boils down to don’t reinvent the wheel, but don’t get complacent either. While it is a shortcut for building a website, it is not a shortcut for conceptualizing the website.
So the other situation is this: Sometimes I envy all the beautiful themes and templates out there because I don’t really get an opportunity to use them for myself. Does choosing to use someone else’s work for a web designer’s own website make sense? It seems counterintuitive but a real problem: sometimes we barely have time to dedicate to our own projects. Sometimes we just want to use something ready-made and have fun with it.
Although there are frameworks for practically level of development these days, from CSS to JS to PHP to whole themes, they are created specifically as tools for designers; they aren’t really products for designers as consumers. What I’m talking about are the real themes that are smart enough, beautifully-designed enough to meet your discerning needs. It could be as stark as Cutline or as detailed as WordFolio: compare this and this. (Now that would be good idea for a list article: websites that are highly customized versions of existing themes. Not to mention a good source of inspiration. A niche gallery, even!)
We could probably exclude portfolio sites since web designers would prefer to show off their skills on them—but even that argument can be ruled out if the customization is custom enough. Take blogs, tumblelogs, and other secondary sites that still belong to a web designer but don’t necessarily need a design from scratch. The issues with the client scenario website still apply, but there’s the added pressure of being your own worst critic.
Would you be confident enough to use one, or would you lose sleep at night without customizing at least some bit of it to keep your design cred intact? It doesn’t have to be a bad thing; it could be a different type of challenge.
Whether experienced first-hand or heard of in cautionary tales, everybody is familiar with the horror of not being compensated for one’s work and not being able to do anything about it. Enter a possible solution: a remote kill switch, which gives web designers a back door into a client website via PHP, AJAX or CSS to disable it in case something goes wrong, i.e., one doesn’t get paid.
Avoiding the technical details and instead focusing on the general idea of a remote kill switch, let me say this:
It’s a sad, sad reality that people have to resort to these methods, but it’s just a symptom of a bigger problem. I also see it as designers and developers defending themselves with tools they are familiar with, rather than legalese that could only throw them for a loop and might not even work. Which isn’t to say they should abandon the usual way of going into a project altogether; the kill switch can just be an additional safety net.
Is it unethical? There is no reason to use a kill switch underhandedly, or consider it as a sign of distrust or respect. It’s not about having the upper hand or treating clients unfairly, it’s about protecting one’s business. But to earn your keep you need to stay professional, not paranoid. Integrating a kill switch into a contract, where the client is fully aware of the consequences should it be breached, sounds fair and should achieve those two things. One must remember, however, that once both parties complete their respective deliverables, the kill switch must also be killed.
I wonder what percentage and type of web professionals incorporate this into their business process. This is a controversial issue for sure, but I think people can avoid the unnecessary drama if their intentions are sincere. What do you think? Apart from a contract and this kill switch, are there any other ways to protect web professionals from clients running off with their work?
I find it very intriguing that Microsoft chose to redesign its new Windows Phone 7 Series interface this way:
The design and layout of 7 Series’ UI (internally called Metro) is really quite original, utilizing what one of the designers (Albert Shum, formerly of Nike) calls an “authentically digital” and “chromeless” experience. What does that mean? Well we can tell you what it doesn’t mean — no shaded icons, no faux 3D or drop shadows, no busy backgrounds (no backgrounds at all), and very little visual flair besides clean typography and transition animations. The whole look is strangely reminiscent of a terminal display (maybe Microsoft is recalling its DOS roots here) — almost Tron-like in its primary color simplicity. To us, it’s rather exciting. This OS looks nothing like anything else on the market, and we think that’s to its advantage. Admittedly, we could stand for a little more information available within single views, and we have yet to see how the phone will handle things like notifications, but the design of the interface is definitely in a class of its own.
Curveball thrown. While the look has been in Zunes for sometime now, the real challenge lies in whether this will take off for mobile phones. I have to commend their bravery for taking this step, going the complete opposite of Apple’s love for rounded corners, gradients, and shadows. It also looks open and airy compared to all the boxes (no matter how rounded) on the iPhone.
It definitely changes the game a bit, and like several others I’m starting to feel like the Apple interface looks dated next to this one. Pretty big deal if you ask me.
This move could backfire. People tend to shy away from minimalism, not to mention it could actually be underdesigned, lacking in visual cues and icons. It falls short of the unified look Apple has built over the years, and I doubt it could start a UI revolution the way OS X did. Would Microsoft even use this for its desktop OS?
We’ll also have to find how it really measures up in real-world testing because the interface alone won’t determine success, but also performance and features (IE and Bing instead of Safari/Mozilla and Google? What apps will it have?). Still, bold is better than half-baked, and in the mobile space this look definitely sets them apart.
I can’t help comparing Twitter Images (tweetimag.es), which extract a user avatars with just a URL to the more established universal avatar provider Gravatar, which is dependent on an email address.
While there are certainly more email users than any web service out there, Gravatar isn’t quite as buzzworthy as Twitter; it’s a more specific service after all. However, because of this Twitter Images service, extracting an avatar is much easier than Gravatar’s implementation and could gain more traction as a legitimate avatar solution on blogs. I won’t be surprised if Twitter scooped up this little project for itself.
On the other hand, being dependent on Twitter—whose popularity still causes downtimes to this day—may not be such a good idea for critical endeavors, and it may be more advisable to go for the service whose sole business is avatars (or if possible, identity management).
Gravatar and Twitter don’t have to be adversaries. I’d want Gravatar to take the high road and embrace all the popular identity channels, be it Twitter, Facebook, Google, Yahoo, MobileMe, OpenID, etc. Or should one leave the multiple avatar sources feature to the developers just like you can have different login and identity options on blogs and web services? Perhaps Mix Online’s Incarnate is the right way to skin the cat.
