10. It’s Leopard Done Right The release of Mac OS X Leopard was fraught with peril. It was late, it ran a bit slow, and it offered amazing new features — some of which weren’t fully ready for prime time. Snow Leopard is all about performance, optimizing features to deliver a great experience. It takes what you know today and makes it perfect.
On Monday I linked to the announcement of RIM's acquisition of Torch Mobile, developers of a WebKit-based mobile browser, and briefly mentioned that more and more, it seems that WebKit is becoming the de facto browser for the mobile platform—and rightly so. The iPhone has long proven that with the right browser and user interface, you can have (almost1) the entire Internet in your pocket in a highly convenient and usable manner.
Today, the news broke that Maciej Stachowiak, Manager of Apple's WebKit team, has become one of two new co-chairs on the W3C HTML Working Group, together with Paul Cotton, who manages the Microsoft Web Services Standards team. This is significant in a couple of ways:
It acknowledges the tremendous innovation that WebKit has brought to and continues to bring to the Web and to Web Standards;
It places WebKit in an even higher profile position, particularly so for the desktop platform where, unlike with the mobile platform, Safari is still often considered as a "less important" browser to test for when the reality is that web developers should be developing in Safari, first, and test in other browsers after that;
The HTML Working Group is now represented by people from IE and WebKit, as opposed to only IE before (and Sam Ruby, who has no direct affiliation with any of the browsers). No Mozilla/Gecko representatives, despite Firefox's larger market share compared to WebKit's.
Maciej has played a key role in the creation of a lot of innovation on the browser landscape; as co-chair of the HTML Working Group he'll presumably bring more of that kind of progress to the standards body as a whole, rather than just WebKit, which would be beneficial for everyone—browser vendors and web users alike.
I'd like to discuss #2 a little further, as it's bound to solicit some strong disagreements from various Firefox fans.
Why develop in Safari first?
As any good Standards-aware developer should know, the best way to build a website is to build and test your ongoing progress using the most Standards-compliant browser available. Today, that is Safari. Firefox 3.5 is a formidable browser and, thanks to its extensions, has a lot more to offer that can help in your development efforts, but when it comes to support for HTML5 and CSS3, Firefox is still lagging behind Safari in a number of ways. For instance, try loading up Modernizr.com with the two browsers; the green checkmarks behind each feature listed on the front page indicate that the current browser has native support for these. Safari supports all of them; Firefox 3.5 supports about half.
As far as browser bugginess and standard CSS handling is concerned, the two browsers perform about equal, but any designer or developing taking advantage of native implementations of certain CSS3 features in the browsers that have them will simply have to use Safari to test the full range of them, no matter what.
Additionally, knowing what your site looks like in Safari means you also know—more or less—what it'll look like on the iPhone and iPod Touch, which combined make up for 66% of mobile browser usage.
Chrome currently has @font-face embedding disabled "pending security review", meaning that if it weren't for that, Safari could be read as "Safari or Chrome". Until that changes, or for those who launch Chrome with the command line switch --enable-remote-fonts.
WebKit's rapid rise from being a decent browser (Safari 2.x) to the absolute leader in cutting-edge technologies and innovations (Safari 3.1 and beyond) has clearly been noticed by both mobile and desktop industries. The fact that they have built such a fantastic mobile browser, however, gives it a tremendous edge over all other browsers for the foreseeable future. People are browsing the Web more and more on their phones nowadays, and WebKit really is becoming the de facto standard for the platform.
What this means is, Web Designers and Developers will get increasingly more tempted to start using HTML5 and CSS3 features because WebKit's share of the market will grow steadily, more so than Firefox's, and the more people start building sites with these features, the more people we'll get using browsers capable of rendering them.
So here's some claim chowder for Gruber: I predict that within 10 years, WebKit's market share will rise to as much as 50% among all browser usage in the US. That's for both mobile and desktop combined.
Disclaimer: I'll also be doing whatever I can to help WebKit get there, simply because I love the Web, and WebKit lets me enjoy the Web in the best and most beautiful way available today.
Let the Age of WebKit begin.
With the except of Flash content, which many people—myself included—consider a feature rather than an omission. ↵
An unsettling change. Futura has been an elegant and fitting part of IKEA's brand identity throughout the years; seeing them switch to the largely unappealing Verdana is a shame. The reason:
In an interview with swedish design magazine CAP&DESIGN the reason for the change is to be able to use the same font in all countries, including asian countries. Also they want to be able to give the same visual impression both in print and the web.
Torch makes a WebKit-based mobile browser. If the BlackBerry platform switches to WebKit across the board for its future products—a wise move, I would say—it means that WebKit will soon be the de facto standard for mobile browsing. This may (and hopefully will) lead to more web designers and developers taking advantage of HTML5 and CSS3 features that WebKit already supports, such as Animations, Transitions and 3D Transforms.
We’ve been watching a lot of Clicktale recordings of form usage and we noticed that just about everyone scrolls down to the bottom of the form, then back up, before they start filling out the form. So we wanted the redesigned form to be markedly shorter than the one it was replacing.
By moving instructions, shifting the header to the sidebar, widening the form field content area, rewording long blocks of text, and hiding elements that were infrequently used, we were able to save a good bit of vertical space. We also redesigned the error states and moved most of the error checking to the client side to prevent unnecessary reloads.
[…] if you’re currently using a Linux distribution or a version of Mac OS X, Windows 7 isn’t going to offer much to get you to switch.
Even though I've left Apple, I'm still getting reports in from friends who have gotten their first Mac. They tell me elatedly how excited they are about their switch. From where I'm sitting, Microsoft has long lost the mindshare game—something which John Gruber recently pointed out is the much more important factor.
It begs the question: how many people still really care about Windows at all?
I had my second kidney stone seven years later, in Paris. It was ten o’clock in the morning, and after looking at my options in the phone book, I took the metro to a hospital in the 15th. Two minutes after walking through the door, I was in a private room. Delicious, mind-numbing drugs were delivered to my blood stream by way of a tube and life was beautiful. I was in the hospital for four hours, and as I was leaving, I asked the receptionist how I was supposed to pay.
“Oh,” she said, “We’ll send you a statement.”
“But you never even asked me my name.”
“Really?”
A few weeks later I got a bill for the equivalent of seventy dollars, this because I’m not a French citizen, and am therefore not entitled to free care.
I got my third kidney stone a few months ago, while on a lecture tour of the United States. The hospital I went to was in Westchester county and the service was outstanding. Maybe I arrived at the slowest time, but, like in France, I was waited on immediately, and the doctor and nurses could not have been more pleasant. Again I was there for four hours, though this time the bill came to $5,800. Not including medicine.
Coming from Europe myself, The Netherlands to be precise, what strikes me as most bizarre about the U.S.A. is that so many people in this country seem to believe their healthcare systems here are any good at all. They're an absolute disaster and the lack of proper competition is keeping it disastrously bad.
Comparing the U.S.A.'s healthcare to a third-world country's is, sad to say, much more apt than considering it as belonging to the world's most powerful nation.
After not having spoken at SXSW Interactive since 2006, I'm hoping that this presentation (created together with Crush+Lovely designer Jina Bolton) will draw enough interest in votes to become part of the lineup.
Subjects we'll cover in Next-Generation Web Technologies, Today:
What are these new Web Technologies?
Why would I care to use these technologies?
Which browser supports what?
How can I use them?
How do I keep things simple and easy to maintain when I do this?
What is the best way to use the new technologies?
What are the best practices (and why are they "best")?
What's wrong about using shortcuts in my development process?
What are the tradeoffs when doing this?
How can I convince my clients that the tradeoffs are worth it to them?
If this sounds interesting to you, please go and vote for us.
The L.A. Times‘ Mark Milian has been watching Flickr stats like a hawk, but he says the spike in images uploaded by iPhone users is unclear. We think it’s pretty obvious: Unlike most cameras, the iPhone is internet-enabled, meaning shooters can share their pics just seconds after taking them. Combine that factor with the new iPhone 3GS’ improved 3.0-megapixel camera (up from 2 megapixels), which includes an auto-focus lens, and bam — rapid growth.
Speaking of big website overhauls, ThinkGeek redesigned today as well, in honor of their 10th Anniversary. Overall, the changes are pleasing and on the whole the site feels more polished and clean, but what's particularly cool is their clever background image. Tip: scroll to the bottom.
In yesterday's (inaugural) installment of A Closer Look, I explored the color palette of the new farukat.es and explained the decisions behind the grayscale design. Today I discuss the typography in a little bit, focusing solely on the use of px for font-size units instead of a relative unit type.
First, I'll explain the repercussions of using either approach, for those not widely familiar with the matter. When specifying font sizes in your CSS, you have a number of unit types to choose from, each behaving differently. More importantly than how the unit type itself behaves, however, is how browsers behave differently when dealing with the different types.
For instance, Internet Explorer—up to and including version 8—does not scale any text that is specified with a font-size property using the px unit, e.g. font-size: 12px. The pixel unit scales up and down in all other browsers when the user chooses to increase or decrease text size, which can be done via a simple keyboard shortcut (cmd and +/- on the Mac, ctrl and +/- on Windows or Linux). Yet because Internet Explorer until version 7 offered no way of scaling text that was specified in pixels, it was considered a serious accessibility and usability concern to use that unit type. After all, not everyone might be able to read the small type of your body text, and if they're unable to increase the type, well, it's a problem and you might lose visitors.
Then Internet Explorer 7 came around and offered what is by now available in every major browser, something called Page Zoom. The difference between Page Zoom and Text Zoom is subtle but important: rather than scaling only the text on the user's command, Page Zoom will scale the entire page as a whole—images, text and embedded media alike.
This solution offered a lot of benefits to users, as oftentimes text was embedded in a web page as an image, and thus wouldn't scale alongside raw text in the page using the Text Zoom method. With Page Zoom, that problem was solved and the design remained intact—more or less, anyway: there are small pixel-precise difficulties with zooming image-heavy page designs, but these are mostly minute issues and few casual observers ever notice them.
Until Page Zoom came around, Web Designers that were conscious of these accessibility and usability concerns for Internet Explorer users were using relative font-size units, such as em or percentages. These units, however, proved to be somewhat frustrating and problematic to use; most every website is designed in a pixel-based manner, and translating from 12 pixels to an em unit value that matched it precisely sometimes led to values like "0.825" or "1.6666"—suffice it to say, not the most convenient of values to work with. Being relative units, these values were calculated based on whatever their parent element's specified font-size was, and so the inheritance and cascading nature of CSS meant that designers and developers writing CSS had to keep track of these things very carefully and precisely.
Today, the situation is that Internet Explorer 7 and 8, along with every other browser that has any notable market share, support Page Zoom and will scale pixel-based font sizes just fine. The question that Web Designers are now asking themselves again, but coming from the opposite side, is: What unit should I use, px, em or %?
This discussion is very much alive right now among web designers, and will continue for some time. There is no exact "right" answer to that question, as the answer varies from website to website. If you have to support IE6, still, and want to make a more accessible and user-friendly site, you should stick to relative units so that text can scale in that browser. If you don't (have to) care about IE6 much at all anymore, there is no usability concern to using pixel units for your font size specifications.
But again, the discussion about this is ongoing and not everyone agrees with my point of view. One such example is Drew Mclellan, who recently argued that relative units for font sizes are better, so that they scale along to any base-level changes you make. As he puts it:
Take that H1 as an example. If the design dictates that the H1 is three times the height of the body text, you might specify the body text as 12px and therefore set the H1 to 36px. If, six months down the line, user feedback tells you the the text size is too small, you might come along and tweak the body text to 13px. In doing so, you’ve compromised the design, as the H1 is now not three times the height of the body text, so you have to adjust that up to 39px. And the H2s are no longer twice the height, so you adjust those to 26px, and the sidebar and footer text is no longer… and so on. A nightmare of changes and recalculations for an extra pixel on the text size.
The problem I personally have with this rhetoric is that just because the body text proved to be a touch too small in his hypothetical example, doesn't mean that the headings were proportionally too small as well. It's entirely possible that the headings were fine and that they were proportionally too big for the original body text.
Changing a base text and having all text headings scale along can have problematic and unintended (or unexpected) side-effects. For instance, your design might involve headings in a sidebar or column that are nicely tailored (visually) to cover most of the entire width of the column. Now you go and change the body text for improved legibility, and what happens is that some of these headings start wrapping to two lines because they no longer fit their containing column.
Ironically, Drew claims that:
When I want to tweak the body text, the integrity of the design is maintained, as the CSS is expressing the rules behind the design, not just the execution of the design.
It's true for a site where all text exists only in one single column and the design is predominantly minimalist. However, even here on my own site's minimalistic design, certain things would break if I were using his approach, and the integrity of my design would actually fall apart as a result.
I can appreciate the thinking behind Drew's argument, but it's simply not how I make my design decisions for type at all. He argues that with pixel units for fonts, you have to manually adjust each heading accordingly, but in all of my website designs thus far, the opposite has been true for me.
He does point out something that I completely agree with, which is this:
Regardless of the way you choose to scale text, the most dangerous assumption you can make is that what you’re looking at will never change.
To understand [why] page zooming is a complete red herring you have to understand this: the property of being able to cope with resized text is more important than the size of the text.
Drew nails it with those two bits, as the most crucial thing to keep in mind as a web designer and developer is that you simply cannot control all aspects of the site you're creating. Web Design is an inherently flexible industry and the products are unquestionable going to be adjusted and controlled, to some extent, by the end user themselves.
In the end, what's far more important than whether you choose to use pixels or relative units for your type is that you design and build your site in a way that is flexible to the user as well as to yourself, with regards to maintaining it as time goes by. Make sure you consider that a top priority; meanwhile, Drew, myself and others will continue discussing this subject until there is a clear consensus. If ever.
Three days ago, Steven Frank wrote about his iPhone boycott and listed a series of changes that Apple would have to make which would, in response, make him reconsider his boycott. Today, Steven writes that, much like John Gruber only a week ago, Phil Schiller, head of Apple marketing, has responded to his blog post with a direct, personal email.
Two bits from his post today that, I think, highlight the power bloggers have and which really justify even the smallest of rants someone might post to their own blog:
What I do have is a comment from Phil that Apple has read what I (and others) have written recently, and that they’re taking it very seriously. Realistically, what more could I hope to achieve from my puny blog posts and arm-flailing?
⋮
If nothing else, I am very grateful that Phil actually took the time to contact me. As I’ve said repeatedly, communication will solve this problem — not silence. Let’s push that communication down from executives-to-bloggers to app-store-to-developers and I think we’ve really got a breakthrough.
As I mentioned in yesterday's post, I'll be writing about all the various design decisions and techniques that were used in creating the new FarukAt.es design (markup, CSS and back-end included). I'm dubbing this series of posts with a prefix title of "A Closer Look", as I suspect there will be a variety of unrelated posts along the way (links to other sites I think are interesting, photo posts and so forth).
To start it all off with, I'll discuss the thought that went into the color palette of the site because the color palette of a website design is one of the most important things in conveying a first impression to the visitor. Research has shown that visitors take only between 50 and 500 milliseconds after first seeing a website to decide whether they like the look of the site or not. That's as little as 1/20th of a second—a timeframe in which no amount of fancy animation you might have come up with matters. Have a beautiful Flash-animated header banner? Rest assured that it won't help in making up the user's mind for that very important first impression.
Now, if you're reading this on FarukAt.es itself you'll have noticed that this site is not exactly a cocktail of colors: most of the design is a soft blend of grays with text in contrasting white or black. The reason I chose a grayscale scheme is two-fold.
First of all, my goal with the design of the new FarukAt.es was to bring the content forward as much as possible, highlighting it in the eyes of the viewer without being obnoxious about it. The content of the site—my writings and the occasional photo—were to be presented as prominently and elegantly as possible. That meant, no distractions. I also wanted to have the content on a mostly-white background, a canvas as blank as the one I stare at each time I create something new. With the content area in white, and wanting to have as little distraction around it as possible, I decided to put no real color in the other elements of the design.
Nonetheless, I had already long settled on the idea of having all of my main social networks prominently listed with their icons alongside the content, so in the end my mostly monochrome design became interspersed with little specks of color here and there:
Above the fold in most user's browser configurations, the only real design element with color is the little feed icon next to the Subscribe link. The icon itself has a largely meaningless connotation but the fact that it is so vivid and colorful makes it stand out and grab just enough attention to draw wandering eyes to the Subscribe link—something that many of those eyes are wandering for:
In Safari (and Chrome), the small photo of myself is given approximately 12% of color, and when hovering your mouse over it, it'll transition to have 82% color. In all other browsers, the photo stays entirely grayscale and only the About page will show you it in (full) color:
The social networks' icons, or "Web 2.0 icons" as I tend to call them, are mostly very bright and colorful. I reduced their opacity in all browsers that support it (~95% of my current audience) and only bring them forward in full strength and with their associated tab background color when you hover over them. In Webkit-based browsers, this comes with a nice animation. In browsers that support rgba(), the background color is 82% opaque, allowing you to see through and notice the edge of the sidebar and its shadow just a little bit around the icons. It's a small, subtle effect that's real easy to do thanks to Modernizr:
The second main reason for the grayscale design is my plan to do daily photo posts. I want these photos to really "pop" on the screen, and to support that I wanted all surrounding colors reduced to a minimum. You can see the effect quite clearly with yesterday's photo post.
Color is a powerful communicator; people associate most colors with specific emotions and feelings, with the seasons of the year or the things they dream about. For this design, I chose not to communicate anything specific with color, and instead let my content do all the work. It's a challenge to have my content do all the communication for me, because it puts each word, each photo, on a pedestal in front of my audience. But perhaps that's what I like about it so much: it forces me to try and make every single word I write count.
Next in the Closer Look series: exploring the Web 2.0 tabs on the right-hand side of the design and the painstaking work that went into making them usable for my purposes.
About six weeks ago, I left the comfortable confines of the computer company’s campus. Apple is an amazing company to work at, but there’s a difference between a great place, and the right place. Apple, right now, is not where I should be spending my time; not someone like me who has far more ideas for products and projects than he has time. For me at this very moment, Apple is not the place where I can exercise on these ideas.
One of the things I thought, three and a half years ago when the email from Apple came in, was that it would be “so much easier” to make a difference on the Web for millions of people while working at a corporation like Apple. This was certainly true when taking into account that I got to work on sites with millions of visitors a day, but over time I realized that the way I envisioned myself having an impact on the Web was neither through Apple nor through working on its high-traffic websites. No, it was instead with ideas for tools and techniques that would help push the Web forward as a whole, by convincing web designers and developers to use cutting-edge techniques and common-sense design principles. And that’s exactly what I aim to do from now on.
Shortly after leaving Apple I launched Modernizr, a small JavaScript library that detects native availability of HTML5 and CSS3 features in your browser. Now, using an HTML5 structure, a plethora of CSS3-based enhancements and—of course—Modernizr to power a design I’d been working on, revisiting and revising for almost as long as I’ve been writing this new blog, I’m finally launching my own site for real. If you’re reading this in a feedreader, come and take a look at the actual site. It’s quite a change from the Wordpress-with-some-default-theme setup that was here before.
I’ll be writing about the many design decisions that went into this site in greater detail over the coming days, discussing aspects like the Elsewhere links (one of the most-complimented features already) and the Social Networks’ icons, the use of Microformats and how they occasionally forced my hand in the markup of the site.
Before I do that, however, I want to briefly mention that I am—after a three-year hiatus—available again for writing and speaking engagements. It’s something I’ve definitely missed doing. All things considered, it’s an exciting time for me. Adventure looms ahead, and I could not be happier about it.
