As much as I wish we’d move on and get Apple off our radar, its decisions have a rippling effect in the industry and the future of various technologies. The next issue on the list? The Web versus App debate. This can be framed more specifically as a Mobile Web vs. Objective-C Web debate in the context of Apple’s mobile landscape, but as early discussions arise, it’s transforming into an interoperability vs. superior user experience debate. Cameron Moll, author of Mobile Web Design, writes:
At one point in time, J2ME (now Java ME) and WAP were the starting points for a discussion on mobile strategy and the web. Then, for a brief period of time, you talked about HTML/CSS. Now, for a growing majority of mobile strategies that don’t require a global presence on widely varying devices, the discussion begins with iPhone. Smart client is now iPhone app, and in many cases, the app is primary to the experience, not secondary to the browser. And iPad app may soon replace iPhone app as the starting point.
Frankly, as the adoption rate of iPhone increases and if iPad follows suit, it will become increasingly difficult to argue in favor of a starting point other than iPhone OS. The NPR iPad app, for one, provides a much more pleasant user experience than NPR.org.
Peter-Paul Koch steps in and plants himself firmly on the interoperability front, maintaining allegiance to the Web:
This is a total no-brainer when we’re talking about games and other entertainment apps. When it comes to complex, graphic games, vendors will opt for superior UX, and once you’ve done that, starting on iPhone OS makes excellent sense.
But if you build an integrated social media client, is superior UX still so important that you can afford to ignore non-iPhones? I don’t think so. I think creators of such apps would do better to create one in web standards so that it runs on all (well, many) devices. There’s stiff competition out there, and the wider your reach, the better chance you have of prevailing.
Meanwhile, Faruk Ates goes the complete opposite: rooting for UX, lamenting the existence of multiple browsers, and emphasizing the need to make a buck. The debate expands further and we see clashing ideologies of democracy vs. walled gardens, free vs. paid business models, and so on. All these further reinforce how Apple’s philosophies go against those of the Web.
With all its new moves, Apple has been targeting all sorts of corporate entities for its own gain: Adobe, Google, the whole porn industry…but now is it also hurting developers? consumers? the Web? itself?
Hostility towards competitors is, I suppose, all part of the game. But this action is also hugely hostile towards developers themselves. The banned development environments offer things that Apple’s Xcode doesn’t. Sometimes it’s just a different choice of language, one that a particular deveoper might feel more comfortable in. But often the advantage is simplification—the use of higher-level programming languages (like Lua, or JavaScript, or C#) and frameworks that take out a lot of the grunt-work of software development (like writing a 3D engine). In turn, developers get quicker development cycles, easier development, fewer bugs, and overall, superior applications. Banning these tools doesn’t just hurt competitors. It hurts developers on Apple’s platform, and in turn hurts the platform itself.
Apple’s done a lot of things to stir the pot, and while such stringent practices have been known to yield revolutionary results, its actions continue to seem awfully ruthless. Choosing a more favorable approach to mobile development could very well be tainted by the company’s values.
So Mark Boulton decided to release his book, A Practical Guide to Designing for the Web, online and without cost. It’s not the only web design book available for free on the web, which this list and a previous encounter with two other online books prove, but all of them make me wonder, again, about the electronic book format.
In the examples above, said “books” don’t adapt official e-book formats, but stick with plain old semantic HTML and PDFs. Joe Clark, in an A List Apart article, explains that both standard and proprietary e-book formats are just more specialized versions of HTML/XHTML, so is there anything gravely wrong with creating webpages instead of actual e-book files?
As one who knows her way around HTML, taking an extra step into e-books (e.g. ePub) feels clunky and unnecessary. However, that is hasty judgment without first considering factors like audience. For web design books, perhaps it makes more sense to not bother with anything else and keep them as webpages because web designers work on sites all day long. That’s not to say they wouldn’t enjoy reading web design books in their e-book readers, but they may mind less having a book in one tab alongside other web design resources in other tabs.
Using proper formats also seems like a natural extension of web standards philosophy. If one were to publish a book online, why not go for the suitable format? There are scripts, extensions, and converters available. And with the ePub Zen Garden following in the steps of the CSS one, it may become the next worthy cause to root for.
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?
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?
Or as a like to call it: podcasts that have caught my eye in the past week or so. And they differ in several ways, so there’s sure to be something for everybody. Take your pick:
Confession: It took me a while to realize that this podcast is actually the previously-named You Suck at Web Design, relaunched as a new brand with a new site design. This show isn’t so much a bag of tricks on web design as it is a quirky, personal storybook told by Matthew D. Jordan, but still a must-listen.
This is not just one but seven shows tackling different topics, from photography to Ruby programming, founded just last year by Dan Benjamin. I love the idea of a whole network of shows about the internet, on the internet, and here we have a whole suite for people who make websites. I can think of few things better than that. More networks and more topics, perhaps?
In light of the “circuses” happening in both the Hollywood late night talk show circuit and the web working groups, standardista slash comic strip creator Kyle Weems aka CSSquirrel announced this:
I am in the process of devising a “late night” talk show that the Squirrel will host, featuring interviews with cartoon representations of various web designers/developers/standardistas. It’ll draw from the mighty traditions of the Tonight Show, The Daily Show and Space Ghost: Coast to Coast, and in theory will be a plug-in free experience brought to you in part by HTML5, JavaScript and vector tree-climbing rodents.
Check out the podcast over at SitePoint, titled HTML5 is a beautiful mess:
The podcast touches on that matter, and spins out to the state of the actual implementation of HTML5 itself, whether there’s a challenge in getting designers and developers to start using it, the issues of accessibility in <canvas>, and how delightful it’d be to move past plugins.
Truthfully, I’m trying to avoid getting caught in the sticky details of how HTML5 is developing at the moment because it only adds to the anxiety (isn’t stressing over Internet Explorer enough?) and diminishes hope (we’re supposed to be moving forward with these technologies already). But it also helps to stay realistic not just idealistic, and drawing back the curtain on how the working groups are actually working on the HTML5 standard is a good way to do that.
I started with this article about the decade that was in web design. (Note: an earlier version of this was done here.) It was not much more than a before and after look at the most popular websites out there. Of course, ten years is a long time in web design so the showcase is a satisfactory way to see how far we’ve come, but not quite enough. There was no discussion on the notable features from the different websites. We don’t redesign sites just because we want a different look, do we? We want them to improve. Answering how those sites improved over the years would be a worthy reference for all the web designers out there. This other one almost nails it, though it focuses on the business of these companies, not web design itself.
I hope the likes of Smashing Magazine or some fabulous curator of web design history would come up with an in-depth study illustrating how web design has evolved over the last ten years. Timelines like this and this could help with that, but still needs mention of developments like:
- the downfall of
<table> layouts in favor of semantic markup
- CSS sprites
- the growth of web typography, from sIFR to
@font-face
- Art Direction in web design
- mobile web design
- the HTML 5 Superfriends
- which website or company popularized which design pattern, from the glossy, candy-colored “Web 2.0 look” to the sleeker, more dramatic “Apple look” (though something tells me Apple is responsible for both)
Here‘s another approach to the timeline, and is more of a Q&A over the years, and anybody can ask and answer. It also hasn’t been updated since ’04, as it was part of the 2005 conference, A Decade of Web Design. Jakob Nielsen also did a backtrack that same year.
I’d also like to look forward. This prediction post is quite adequate (with pictures it would be perfect). I think this passage sums up what’s happened in the past decade and what will happen in the next:
While most these technological improvements tend to make the web a more and more homogenous place, at the same time, there is a tendency to create highly curated design setups that use different designs for each article.
There will always be a dichotomy between standardization and specialization on the Web but it’s only lately that we’ve been able to do so with less crap, more elegance. And I can’t wait to see how doing those two things evolve into even more exciting things in 2010 and beyond.
Need more crystal balls and time capsules? See also:
And by jQuery-esque I mean easy! The premise of Jetpack, Mozilla Labs’s latest creation, is that anybody who knows HTML, CSS and JavaScript can create Firefox add-ons.
It takes 80 lines of code to block ads on websites as shown in the demo above, and 14 lines to edit images from within Firefox. Granted, it just sends the data to Pixlr which does all the hard work, but lowering the obstacles to develop some fairly nifty scripts is a commendable effort, just as what jQuery did with JavaScript, Sass with CSS, and HAML with HTML. It’s made even more compelling with Bespin, Mozilla’s HTML5-powered web-based code editor.
Perhaps I’m still in a “standardize everything” mood, or envy this new doodad since I’m now using Chrome as my default browser, but don’t you sometimes wish all browsers could do this? Do the same set of things? We’re getting to a point where the level of HTML and CSS support is the same across every browser, so it makes me wonder what’s the next step for the idea of cross-browser compatibility.
It will probably depend on what the web browser means to its various makers. Google has unveiled the Chrome OS, which will run on a specialized version of Chrome. Opera is focused on its “web servers for everyone” feature in Opera Unite. (And Internet Explorer is playing catch-up, mostly.) Browsers are basically the gateways to the whole Internet, but they’ve become more ambitious than that and their vendors will attend to those ventures first before convening to create new cross-platform goodness.
Harry Roberts a.k.a. CSS Wizardry tweeted a certain tutorial by CSS Aid (page is dead now), which was enclosed with four little words (“Good lord, wrong much?”) that echoed such alarming levels of horror and shock (considering he tweets about poor examples of HTML/CSS code everyday), that I had to check it out.
First, the tutorial was entitled “Tables Without Tables”. If that doesn’t trigger warning bells in your head, then consider the opening paragraph:
It’s the year 2009, CSS rendering has vastly improved from when it was released, so there is no reason for any website to use tables as layouts. Although you can ditch the table tag when it comes to layouts, you may someday need to use it for what it was made for…or do you? I am going to show you an easy way to make a table with a simple unordered list.
No. Just no. Yes, <table>-based layouts are considered wrong because HTML is supposed to properly represent data. Lists should be lists. Tables should be tables. Layouts that look like tables (grids) can be done in CSS. That’s semantics, the core principle of web standards.
But avoiding the use of <table>s at all costs is no better. Perhaps it’s even worse, since it demonstrates not only ignorance but false expertise, feigning arrogance over an HTML element that has been shuddered at because of its misuse and abuse.
The page has gone down in between the time that I read the tweet and wrote this post. Fortunately the forum thread that seems to be the source of the link is still up, and shows us the author’s reasoning for writing the tutorial. Take post #7:
Because I hate the <table> tag
Is this the extreme dark side of web standards, where we’ve been conditioned to hate <table>s so much that we can’t even think to use them for what they were meant for anymore? A sad, sad turn for us all.
By post #15 he’s already backed down and promises not to use the experiment for real-life cases, but this summarizes things nicely:
It’s a pointless experiment though. It’d be like experimenting making a house out of tampons. Doable but just plain wrong.
It’s bad enough that we have to deal with preaching proper web standards, dropping crusty old browsers from, and adding newfangled technologies to our web design arsenal. Let’s not get sidetracked by punishing HTML elements by twising them into things they weren’t meant to be.
Andy Clarke of For A Beautiful Web has presented a stylesheet for the web browser we haven’t been able to push off the provebial cliff: Internet Explorer 6.
When I asked myself why people visit my sites, and the ones that I make for other people, the answer was always “for the content”. Content that is almost always written words and that means type.
That is why I’m now advocating to my clients (and to you), that where feasible, not to waste hours in time and a client’s money on lengthy workarounds in an unnecessary attempt at cross-browser perfection. Instead, you and I should provide simple but effectively designed HTML elements. This means just great typography for headings, paragraphs, quotations, lists, tables and forms and no styling of layout.
But this idea is not new; this Universal IE6 CSS file contains just enough rules for a practically unstyled but easy to navigate website. You’re basically giving websites loaded in a low-fi browser a low-fi experience. Examples here, here, and here.
Despite its waning popularity, we seem to have amassed a whole buffet of solutions to the shortcomings of IE6, ranging from the hostile upgrade messages and campaigns to the subtle conditional stylesheets and scripts.
I can just imagine someone creating one of those personality quizzes out of this whole debacle: which IE6 compatibility fix are you? There’s an idea.
But really, dealing with IE6 and somesuch boils down to principle and circumstance. Can your clients and your conscience accept barely recognizable version of their sites in twentysomething percent of their audience? Is your sanity more precious than squishing mysterious bugs? Or do you feel like throwing some humor in?
Let me know if someone’s actually made a personality quiz about this; I’d love to take it.
Everything old seems to be new (and hip?) again. And I’m not too sure I’m happy about it.
Short URLs
Shorter URLs are all the rage these days because of Twitter and its 140-character limit. If you’re one of the top sites on the web is practically mandatory for you to roll out your own URL shortening system. Ars Technica, for example, whose official URL is arstechnica.com, also has arst.ch. If you’re on a CMS like WordPress, you’re advised to give out the post ID permalink instead of the keyword-rich permalink of your blog post for the same reason.
Not too long ago, SEO and usability experts were on the same side and recommended readable URLs. Now that Twitter is the new internet marketing (I think they call it social media now) battlefield, the rules changed. When the next killer Web 3.0 app comes out, will we compromise and adjust once again?
But then again, has the Web ever stood still? Maybe I just thought it was beginning to.
WebKit’s CSS animations and scrollbars
You can now style scrollbars and perform animations using CSS in WebKit browsers.
I remember when Internet Explorer started to support scrollbar styling and almost every personal site took advantage of it. But then they grew out of it and were told by the gurus not to mess with the browser chrome.
I also remember <blink> and <marquee>.
But then again, “styling scrollbars isn’t messing with the chrome anymore than styling a button is.” Would the world be a saner place if browsers behaved the same way and all looked alike?
DiggBars
Digg has come out with its own version of the external page framing mechanism which they call the DiggBar.
Said mechanism is nothing new, and never really died out even to be considered a comeback, but Digg has a powerful following by all that which is noisy in the blogosphere to build a considerable amount of buzz. And no matter how you look at it, framing external pages is still framing, reminiscent of the era when HTML framesets were considered cool.
But then again, perhaps in this new era listening to the clamor of the crowd is no longer a fluke, but a very real way to improve one’s business.
*/
