New Canadian Bill C-32 AMV and Anime Convention Unfriendly

AMVs or Anime Music Videos, artistic compositions of various clips from Japanese animations on a montage of music, are a popular aspect of the Otaku culture, that is the culture of Anime (Japanese Animation) fans around the world.

AMVs grew to be surprisingly important in the Anime world. They make some of the biggest events of Anime conventions around the world that count as much as 560,000 people in attendance (Comiket). Canada has a much smaller Anime community than Japan or France’s, which both surpass 100,000 in attendance for their biggest conventions, Canada ranking under 50,000. Nevertheless, it is big enough to garner considerable attention, and AMV contests in Canada see participants from around the world.

But since AMVs were already of questionable legality, there was a lot of questions as to whether AMVs would become officially illegal under the new Canadian copyright amendment. Continue reading

Posted in Uncategorized | Leave a comment

So you thought Google was Java-friendly

With the release of Google Chrome as a non-beta for all three major platforms (5.0.375.55), Windows, Mac and Linux, one’s thing for sure. The shipping, non-beta version of Chrome on Mac OS X does not support Java.

This sad realization makes the browser a tad less useful on that operating system. Whether this is just unwillingness from Google or pure forgetfulness, it’s gravely irritating.

Until Google fixes this, I will consider them as potentially hostile towards plugins of lesser importance. Google seems to use Chrome a bit too much self-serving to my taste, and the fact that it still doesn’t support Java makes it feel very beta-ish. Mind you, I’ll probably keep using it anyway, so I guess Java was just declared dead?

Posted in Uncategorized | Leave a comment

How Apple got your pocket and will soon have your kitchen

The success of Apple’s iPhone is often attributed to its apps, but in reality, the iPhone started becoming popular way before the App Store ever existed. So how did the iPhone manage to snag away so much market share from crown holder BlackBerry? The answer is simple: Apple figured out something fundamental to the success of any future smartphone platform before RIM (Research in Motion), BlackBerry’s maker, could figure out its own sales were plunging.

Owning your pocket

It’s all about owning your pocket. In our increasingly digital-dependent regime, mobile devices that take a place in our pockets are becoming a crucial part of our life. We don’t need them, granted, and we always did without before, but like other communication inventions, we create the need for them.

You can live years without a cell phone, never realizing you truly need one. In fact, you’re absolutely right. You don’t need one. It’s not a necessity at all, at least not yet (some other parts of the world like Japan practically require you to have a mobile phone to live a normal everyday life).

But once you get a cell phone and start using it, chances are you’ll get accustomed to having one. It’s like the Internet, or TV. Once you have it, you cannot go back. And one processus telecommunications companies master in terms of sales is the fact that few customers ever get less than they previously had. The taste for features is endless, which is why salesmen at these institutions try so bad to embark you on dozens of trial, because they know you’ll eventually subscribe to them once you tried em.

The mobile phone is creating a need. A need for a constant communication device. The smartphone could do more though, and could create more needs, which is something RIM capitalized on. They created a need for every business man to manage their life digitally. They don’t have to, and sometimes it’s even less efficient than with a good old paper agenda. But the practicality of a smartphone is what creates the need. Once you get to use a real good smartphone, its features will become a new need.

Where is Apple in this?

Apple had already caught an ear on that amazing sales principle. That is, the creation of new needs.

They quite mastered it with the iPod. The iPod fulfills the role of having music everywhere. Granted, nobody even needs to listen to music, although research does prove it can soothe your mind, etc. But it’s not a real need. It’s again, another superficial item of our modern societies.

However, music, unlike mobile phones, has long been entrenched in our societies. The need to create and listen to music is as human as the need to communicate, and portable music players do exactly what mobile phones do, they extend on human needs.

It’s the ingenuity of Apple in all this, to marry both music and communication in one device. However, when the iPhone got out, many came to the realization that the iPhone was not as efficient as a BlackBerry for organization, and questioned whether you needed an all-in-one platform when you could just get a cell phone and a portable music player. In fact, the argument was that a BlackBerry and a DAP (Digital Audio Player) combined were better, and often cheaper, than an iPhone.

And this is exactly what RIM mistakenly took as true, as well as many other contenders that took years to capitalize on what Apple is. The problem is, most of them didn’t and probably still don’t understand why the iPhone model works so well.

It’s all about your pockets

What Apple realized is this: It’s all about your pockets.

In today’s modern societies, the men have two places to tuck in things conveniently, no matter what season; that is, two pockets in their pants. One pocket is already occupied by the wallet. Men don’t carry purses around like women, so their pocket space for electronic devices is reduced to one. This is very important, because instead of being a issue of fashion, the pocket is an issue of comfort for a man. Less fashion-conscient, what’s important here is comfort versus practicality.

This explains why men tend to have smaller wallets. It also explains why men pay with cash instead of change, because change is too cumbersome to carry, or would make wallets to big for appropriate levels of comfort. Equally, mobile devices must not take too much space because they will occupy an entire pocket. Even worse, because mobile devices are fragile, men will often have to put up with shoving away both keys and wallet in one pocket. It’s thus a bit exaggerated to think both a BlackBerry, which were known at the time to be bulky, and in the majority still are in comparison to regular mobile phones, and a DAP would go in the other pocket of a men.

And there, my combining both mobile phone and music functionality in once device, Apple had created a formula for success; that is, a way to have a smartphone that fulfilled more roles than a BlackBerry or Windows Mobile device could.

Of course, women are important too, and although most will carry mobile equipment inside a purse, where many, many things may go, the reduction in the quantity of devices, and hence weight of the purse, as well the ability to have a single all-in-one device fit in a tight pants pocket, thus the importance of the iPhone’s slimness and form factor, are also appreciated.

Video Games

Although probably something Apple didn’t quite expect to fire up as much it did, video games are also a crucial aspect of the platform that allowed it to gain popularity over every other device all while eating away at BlackBerry’s market share.

Because of video games, and advancement in the organizational capabilities of the iPhone (namely Microsoft Exchange compatibility), it is now one of the most universal mobile platforms in existence, capable of fulfilling the role of an agenda, mobile phone, music player, video player, camera and handheld video game machine in one go.

Tablets?

Granted, mobile operating systems have come a key target into the “new” tablet computing devices. While technically something really old, tablets weren’t hot, or usable for that matter, before a few months past when Apple announced the iPad. The iPad runs the iPhone OS but it’s not a mobile phone.

The question is now to find out exactly what the need is for such devices. Lazy couch-based Internet surfing? Full-size applications anywhere in the house?

The key to the success of these devices is all about creating a new need, and surpassing what current devices that try to fulfill that need do in their efficiency. Many argue Netbooks with Windows or some flavor of Linux are better than the iPad, after-all, they have have a physical keyboard. They can also do more and blah blah blah. Sounds familiar? Indeed, because it’s exactly the kind of discourse that could be heard when the first iPhone launched in the United States.

“It’s slicker, but is it more capable/useful?”

The truth is, it is not. The iPad is neither as capable or as useful as any laptop or other portable computer with a physical keyboard you’d put in your kitchen. But just like the iPhone, Apple is aiming at a whole other thing that is much more important: convenience.

How convenient was it to carry two mobile devices in order to make phones calls and listen to music on the go? More functional, but less convenient than the iPhone.

How convenient is a Netbook in comparison to a simple tablet like the iPad? It’s more functional, but it’s far from being as convenient.

Lots of people argue tablets like the iPad are useless devices that don’t have a place in our digital life. I beg to differ and I’m sure that in two to three years, the tablet development craze for applications will be on fire. I didn’t say the iPad would be on fire though, as it does have a few upcoming contenders and nearly all other technology-related companies against it (Google & cie.), but those companies better act fast because Apple is already selling the iPad like crazy.

Posted in Uncategorized | Leave a comment

Google Pacman

Google has released today probably the coolest doodad you can make for a logo. It’s a JavaScript version of Pacman, along with the original sounds, although these use Flash.

I’ve managed to save a local copy of the game for the sake of keeping such a cool piece of JavaScript code. I hope Google or Namco don’t mind. In any cases, it doesn’t run directly on my server, for reasons I still ignore (I have to go through minified JavaScript from Google and it’s a real puzzle), but this copy should manage to run from your hard drive.

I’ll probably be releasing the JavaScript code in human-readable form soon so that we can all learn from this cool piece of JavaScript. Additionally, with the <audio> element, HTML now has a sound API (kinda), so I believe it would be possible to implement this game without having to use Flash at all. Google didn’t do this, but it’s understandable as the game works as well on IE.  A pure HTML5 solution probably wouldn’t be so cross-browser for now. With the launch of WebM however, I have a vested interest in exploring the possibilities.

Posted in Uncategorized | Leave a comment

WebM and VP8 Implementations After Day 1

Note: these tests were conducted on very early unstable product releases and the very first WebM YouTube encodings from Google. Other WebM encodes not covered in this article are substantially better, both being scrollable by Firefox/Opera and less glitchy, as well as considerably smaller in size.

Current WebM implementations in web browsers are of course in early alpha stage and it shows. Namely, there’s a lot of work for Google to do on its codec before it can tackle H.264 properly. However, like anything Google, what is seemingly not menacing and insignificant is then developed at break-neck speed and becomes a major product in little less than a year. Truthfully, browsers also have quite a bit of implementation work to do on HTML5 before an HTML5 YouTube with JavaScript controls that work across browsers is possible.

Note that the videos are played directly from a local copy of a 720p WebM music video I grabbed off YouTube. Take note that the WebM version is ~122 MB, while the H.264 version of the same resolution is 55 MB, with no perceivable difference in quality. There is a possibility the source file simply isn’t that much higher quality either, which explains the lack of differences. When encoders which do not require compiling your own FFmpeg build come to existence, I will make a better unbiased review of how same-size VP8 and H.264 encodes compare.

Firefox / Mac OS X

Mozilla has done quite a good job on the CPU side. On my Core 2 Duo, the Firefox 3.7a4webm build manages to eat only about 35% of my CPU on average. That’s really good, except the video playback isn’t as smooth as I’d like, frames are obviously being dropped here and there.

There are also some bugs where moderate to heavy pixelation appears in the form of literal giberish blocks of pixelated “snow”. These aren’t random however, they always appear in the same place in the video, so they’re probably easy to track down and fix. Chromium does not have these bugs, so it’s not the encode.

Firefox cannot scrub the WebM video and heavily glitches while trying to do so.

Opera / Mac OS X

Opera’s version 10.54 build 21874 for WebM isn’t bad either. It’s CPU usage grinds 55% on average but the video playback is much smoother and doesn’t look like it’s dropping any frames. In fact, it probably isn’t.

However, Opera suffers from the same pixelation issue Firefox does. What’s peculiar here is that the glitches are at the exact same place in both browsers. Mozilla and Opera are probably using very similar implementations.

Opera cannot scrub the WebM video but unlike Firefox, it simply does nothing and keeps playing the video normally.

Chromium / Mac OS X

Google Chrome’s nightly release, Chromium, here version 6.0.411.0 (47762) is the worst contender in terms of CPU usage. Its average is just over 80%, going as high as 90% frequently. It also drops frames like crazy.

Despite the staggering performance issues, Chromium has arguably the most complete playback implementation to date as it features no pixelations glitches and is the only browser capable of scrubbing the video.

Windows, Linux?

I won’t be covering those now but will add them to a more complete article in a week or two in which I’ll also update the Mac OS X tests as things might have changed, especially on Chromium.

How does it compare with H.264?

Now, of course, hardware accelerated H.264 cannot be compared with non-hardware accelerated VP8. Although practically all major hardware companies announced in Google I/O 2010 will be bringing hardware acceleration to VP8 for the WebM format, it’s gonna be a while before everyone gets it. If I’m not mistaken, you cannot magically infuse hardware acceleration in devices that don’t support it. In other words, I don’t think it’s possible to hardware acellerate VP8 on current hardware, which makes every older computer obsolete for that, but I’m not sure of what I’m saying. All I know is it took 7 years for H.264 to achieve its widespread availability since its launch and a good bunch of computers still don’t support hardware accelerated H.264.

Nevertheless, for stats, here it is. On my Mac, I manage to use only 15% of CPU on average with QuickTime or VLC, and around 20% with MPlayer OSX Extended. All of these are hardware-accelerated. Note: Safari on the Mac uses the native Core Video APIs to play back H.264, so unlike its PC counterpart or Google Chrome for instance, its video is silky smooth and hardware-accelerated.

So, when Google Chrome plays back H.264 on my Mac, without any hardware acceleration, it only achieves about 70% of CPU usage. That’s a lot in comparison of course, but at least the video playback is smooth and bug-free, not surprising. Nevertheless, 70% of CPU usage is much more than 35 or 55, respectively Firefox and Opera, which already prove it’s possible to playback VP8 with considerably less CPU than H.264 requires without hardware acceleration, and with Firefox closing in on numbers just about twice to actual hardware-accelerated H.264. Note however that Flash does use less CPU for non-hardware-accelerated H.264 decoding. It’s just about the same than VP8.

There’s still lots of optimizations to be done with VP8 and the WebM format. It’s arguably still a very alpha solution, but I used to say HTML5 video was only a gimmick last summer. Things change really fast in the web industry and I believe it won’t take much patience to see VP8 outpacing H.264. It’s already on a good start in terms of resource usage anyway.

Posted in Uncategorized | 1 Comment

In the wake of VP8; The World vs Apple

Apple has really put itself in a pinch here. Steve Job’s assurance of its platform’s power may well bring its demise if he doesn’t turn around quickly enough.

Today, May 19, 2010, just as I and many others had predicted and wished for, Google released as Open Source the VP8 video codec. If that wasn’t enough, they’re also introducing a video format called WebM to go with it that is based on Matroska, along with using Vorbis as the audio codec. It’s as if Google just made love with open source, really.

Looking like it can’t get better, Google also announced an impressive list of partners, amongst which a very surprising fellow called Adobe is listed. This means Adobe does plan on supporting the WebM format in future versions of the Flash Player. Can this get any better? Sure, a bunch of hardware partners are also following suit, notably important video card makers AMD (ATI) and NVIDIA, crucial players here because they are thus bound to provide hardware accelerated VP8 to WebM on various platforms that use their chipsets. Mobile chipset manufacturer Qualcomm is also in the fray, ARM, a major mobile chipset manufacturer responsible for many of today’s mobile hardware (Nintendo DS, BlackBerry, HTC) as well as many other more or less important hardware companies.

In the software arena, Google’s own Android and Chrome, as well as Firefox and Opera are on the map, all promising support for WebM. Skype is not surprisingly there, currently using VP8′s predecessor VP7, and also a bunch of video encoding companies like Sorenson are there. The Xiph foundation, responsible for the Theora codec, is of course part of the equation.

What’s funny is that Theora is actually based on VP3, a codec made by On2, the same company bought by Google that has developed VP8. So WebM really is, in all aspects, Theora’s spiritual successor.

A number of important players in the online video space are also there, like Google’s YouTube, but most importantly Brightcove and other important high profile Online Video Platform companies are listed, meaning their customers will get integrated solutions for WebM, much like they just got integrated solution for the iPhone OS following the launch of the iPad.

And, just later in the day after Google’s announcement, Microsoft has decided it would also support WebM in Internet Explorer 9, on top of supporting H.264, except users will have to have the VP8 codec installed on their Windows machine to play it back in Internet Explorer 9. That’s not much of a problem though, as most new Windows machines come bundled with many codecs that wouldn’t be otherwise installed, and telling the user to install a simple codec isn’t much more complicated than installing Flash, and they only have to do it once.

What just happened?

What just happened is that the WebM format just got a whopping 95% of browser market share support (not counting the ability to play back WebM within the Adobe Flash Player), that is every major browser except Safari.

What just happened is that the WebM format just got support for nearly every mobile platform in the world, that is every major mobile platform except iPhone OS.

What just happened is that while Apple was bumming out its developers and declaring H.264 supremacy, the rest of the world joined hands with Google and unleashed WebM.

WebM is a completely open format. Nobody has to pay for it and anyone can do anything they want with it, even implement it in proprietary platforms because its open BSD-like license. WebM is like a nuke for every other video codec on Earth. H.264 may remain for a few years still, but the future is WebM, and unless Apple decides support it as well, it’s going to sink with H.264. Trust me, any company out there not capitalizing on WebM, VP8 and Vorbis will eventually just sink with the rest of the consumer-aimed video/audio codecs out there.

This is the true ability of open source software; this ability to crush anything in its path because it is not encumbered by patents. It’s also a testament to Google and how the company is far from becoming a Microsoft under the rise of Facebook. Google shows no sign of slowing down as its technology and inventions are still ahead of what most of us can predict.

Unless, of course, this is valid. But on the question of whether the codec will get its implementation fixed, my answer is Google Chrome. How fast and how many times did this not-even-2-years-old browser outpace its own performance? Google is Google, not Microsoft, let’s not forget that. On the question of patents, although relevant, the time for such lawsuits to come to an end or even start can be counted in years, and the outcome is questionable. Also, with stuff like TPB and the Piratepartiet, patents are becoming increasingly irrelevant in this day and age. Whether H.264 will block WebM’s road is very, very doubtable.

Posted in Uncategorized | Leave a comment

Answer to Martin: Problems in the Adobe CS5 UI

A reader of mine recently wrote this in an email:

I like your blog but couldn’t leave a comment.
Do you have an opinion on the UI design of CS5 applications on
Windows? It’s very disturbing for me that they didn’t follow the
Windows UI Guidelines. And it’s not very consistent because Premiere
and After Effects doesn’t have those ugly window controls like all the
others. Just take a look at Photoshop CS5 and look how they could add
something with jaggy rounded corners and imitate the standard Windows
Vista/7 look so badly.

I’m also very upset for years because Adobe forces MDI and all
document windows are child windows so this way the open documents in
Photoshop or Illustrator are much harder to find. I know that at least
it’s possible to drag Photoshop child windows out of the main
application window but oh god, they are dog slow when you move those
windows… What an ugly hack! Why? Oh, why? I wrote feedback on Adobe
several times but it seems they don’t listen because there are not
enough people whining. I use Mac and Windows as well.

When you feel like expressing your thoughts on these issues I’d be
grateful to read them.

cheers,
Martin

Well, here I go. This article is an answer to Martin’s request. Thanks for reading my blog by the way.

Non-Native Looks

For some reason, there is a tendency in Windows application developers to steer away from the operating system’s native UI. This probably became a trend in the late days of Windows XP before Vista came around. It was understandable, and even Microsoft did so; the Windows XP shell was so ugly that companies started to invent their own shell or chrome for their applications.

The reverse happened on the Mac. The birth of the Delicious generation apps and the design-centric community of the Mac world pushed developers to create ever more native apps on the Mac. The majority of Mac apps even employ native Apple APIs such as Cocoa on the Mac because developers know the more “native” their app looks, the more chances of success they have with the Mac community. Java-based apps for instance have seen lots of difficulty getting acceptance on Mac OS X, where they stick out like sore thumbs in an array of similar-looking applications.

Even Adobe has to a certain degree sticked with more native looks on the Mac than on Windows, but it does make for a more inconsistent experience as some applications like Flash simply don’t respect Mac OS X UI conventions, like not quitting the app when you press the X button to close the window.

Adobe is really amazing for its lack of consistency. Although Microsoft has been blamed for the same, Adobe probably reaches new heights in terms of consistency issues with native shell looks. It even goes further than the application chrome, with Adobe using different dialog windows and even icons that share the exact same functionality in two different applications.

Icons

Icons are probably the most flagrant thing in CS5, and they’re proof Adobe’s teams of developers and designers don’t communicate with each other very often. The sheer interface differences observable between Photoshop and Illustrator are baffling for two pieces of software that share such a close relationship.

This picture clearly demonstrates how three different apps all in the same Creative Suite 5 from Adobe, in order: Flash Catalyst, Photoshop and InDesign, share two different icon sets and even different chrome color. Why did only Photoshop get the new icons and not the rest of the suite? Why does InDesign have a lighter chrome? No one knows, but one thing is for sure, there is a major communication problem between GUI designers at Adobe.

Chrome

Of course, remember that when we talk about the “chrome” of an interface, we’re not talking about Google Chrome here, we’re talking about the user interface chrome. Note however, that just for facts, Google Chrome’s name is based upon the metal called “Chrome”. Its nightly version, which is less refined and more buggy, is called Chromium, a small pun on the fact that the raw metal element for what is commonly known as chrome (or chrome plating) is called chromium (number 24 on the periodic table).

The chrome of an interface encompasses everything that is not content, or what is generally known as the GUI. That means dialog windows, the main application window, menu bars, etc. That’s something Adobe succeeds in wonderfully making different from anything that could be called native for an operating system. The problem is there’s no reason to do this. Windows Vista and 7′s chrome is much prettier than Windows XP’s or Adobe’s current chrome in CS5. Photoshop for instance would feel much more at home if it would respect the user interface conventions of Windows, and to a lesser extent Mac OS X since the case is not as work on the Mac. Instead, CS5 strays even further away from native interfaces by introducing a variety of chromes and dialog windows that don’t fit with each other.

This is just an example of Flash Builder, Bridge, Photoshop and InDesign, which all share a different chrome for their GUI. It’s actually impressive at what point the inconsistency is in-your-face.

Functionality

Additionally, Adobe applications even have inconsistent functionality, like the zoom tool which has been changed in Photoshop, but not in the other apps of the Creative Suite.

On and on and on

I could on and on about how inconsistent Adobe is with its software, but the truth is, if you were to work with other solutions, namely open source alternatives, you wouldn’t get any more consistency. The benefit of making every Adobe app match one another is questionable, which is why Adobe probably doesn’t put too much effort in doing so.

The reality is, despite the inconsistencies, still few things come close to what you can do with the Adobe suite, and much of the annoyances like the tabbed (MDI) interface can be fixed by tweaking the preferences to your liking. The new Photoshop zoom functionality can even be turned back to the original, and the single-column buttons introduced in later iterations of the Creative Suite can be turned back in two columns if you want.

Point made, if you’re familiar with these professional tools, there’s no actual real reason why the newer version should make your life harder. The default settings may, but the preferences are always there. Adobe does not remove ways to work with their software, they know they mustn’t, but they do expect its users to be capable of tweaking the apps to their preferences; after all, it’s not Microsoft Office we’re talking about here, it’s professional creative software.

I’m not saying Adobe isn’t at fault for very stupid decisions, I’m just saying lots of the claims against the software are largely irrelevant.

By the way, for those who the MDI, a.k.a. tabbed interface of Photoshop make nuts, simply go to Preferences > Interface, and then uncheck “Open Documents as Tabs” and “Enable Floating Document Window Docking”. This should be considerably less annoying for Windows users, but the Mac works considerably different and the whole docking thing completely disables the ability to work with Exposé, so it should help. For those who the Scrubbing Zoom renders nuts, simply uncheck “Scrubby Zoom” in the Zoom Tool options right under the File Menu when the Zoom Tool is activated. You might think this should have been a preference, but it’s a better idea to learn to check and uncheck the option so to use the zoom tool as a multifunction tool for more efficiency. I do so myself and I find I spend less time zooming somewhere. The Scrubby Zoom is really fast! For those of you without a good video card or fast computer, you might want to disable Hardware Acceleration and Animated Zooms.

Also Martin, I think you need a faster computer. My windows never lag like you say on both Windows and Mac when I drag them out of the dock. You might want to turn off hardware acceleration too or simply not use the tabs at all.

Posted in Uncategorized | 1 Comment

My biggest complaint for Adobe CS5: Help

Sometimes, companies who have to back up their own technology by making things with it shoot themselves in the foot, unaware that although their technology is seriously brilliant, it’s just not good at what they used it for.

Adobe is one of those companies and in that way, they screwed up Creative Suite 5′s Help application.

The way it used to be

Before CS4 I believe, when looking up ActionScript references for instance, one had to go through this very painful Flash help pane that used to pop up and take all the place within Flash. The problem was obvious, it could have been a separate application that didn’t go in the way of actual programming or art.

The fix in CS4

Brilliantly, a while after Adobe acquire Macromedia, they transfered all of the help to an HTML-based online reference, essentially something they called LiveDocs. One problem of course was that the help was difficult to obtain as an offline version. I personally never found this very problematic, as I don’t remember developing anything on Adobe Flash without an Internet connexion. In fact, I’d be stoked to see who actually develops web applications, or even regular applications for that matter, without Internet access nowadays.

In any cases, Adobe’s help solution was brilliant for one reason: HTML.
HTML is like a proof of concept really: It’s the best documentation media out there, and for very good reasons. Hyperlinks are one good reason. The ability to exploit browser features is one too. For instance, with Google Chrome, it’s possible to view the help files from Adobe really quickly. With all major browsers today, it’s possible to open tabs in order to save content for later. You also benefit from a direct link to the Internet, meaning you don’t have to open another application to search elsewhere for documentation and tutorials. I also like that HTML help benefits from native operating system font rendering. With a PDF, or Flash, for instance, you’re stuck with what the developer wanted you to see, or how Adobe Acrobat renders text in PDFs. It can be modified, but hardly in any beneficial way. In HTML, you have the choice, and you can read smooth fonts on a Mac or benefit from enhanced legibility with Microsoft’s ClearType and other subpixel rendering methods on Linux.

I think most of all, HTML has become very light. Unlike PDFs or other methods of rendering documentation, the HTML media is very light on CPU resources. It takes considerably less memory and CPU to render and navigate HTML than it takes for a PDF or some other text media, because browsers have become increasingly good at it. Another thing only possible with HTML in regards of speed is the ability to partially render elements. This means HTML documents can be scrolled, read, etc. all while they’re loading.

Whenever you put CPU intensive elements like Flash, Silverlight or a Java Applet in a web page, or use a PDF to view documentation, that ability is lessened and in some cases like the PDF’s it’s also completely gone, making for a sluggish reading experience.

Wikipedia’s agnosticism towards plugins and heavy JavaScript is purposeful.

The grave error in CS5

But now, in the brand new Creative Suite 5, Adobe has made its help in the form an AIR app. Unlike web browsers and HTML however, Adobe’s AIR app does everything wrong, proving once again, probably to the demise of and to the contrary of Adobe’s expectations, that HTML is a superior media for text. It’s highly ironic however, as the Adobe Help app is actually an HTML parser, parsing the very same HTML documentation previously available in CS4. However, unlike a web browser, it does the following wrong:

  • It takes ages to open
  • It doesn’t progressively load pages; you have to wait until it’s done to start scrolling the page
  • It can’t open tabs
  • It can’t use the features of a web browser, such as selecting a few words, right clicking and clicking “Search ‘***’ with Google/Bing”
  • It probably isn’t multi-threaded; Windows thinks it stops responding while it’s actually loading a document
  • The download of new help files take an amazing amount of RAM and often simply does not work

Adobe should care less about its platform and more about its usability. Using Flash for everything is not a good idea. It’s a good platform, it’s just not good for everything.

Flex is good for Apps, not web sites, and Adobe should capitalize on that instead of digging their own graves.

Posted in Uncategorized | Leave a comment

Screwing up my brain for no apparent reason;
The New Wikipedia Design

Screwing up our brains is something developers of much used tools seem to like to do. While key design changes are important, they aren’t when they simply make something new; that is, when they have no reason for something people are used to to be different.

A Good Example

A good example of such a key design change is how YouTube changed its search bar. Instead of being docked as a third-class citizen on the right part of a menu, Google simply decided to put the search bar completely on the top, being the second thing you see after the YouTube logo.

This is good because YouTube’s main usage is based on search. On vary rare occasions I will see people hit their favorites when they want to show me something on YouTube, or even go through some Facebook link, but 99% of the time, people search on YouTube. Hence, there is a reason to emphasize the search.

Additionally, research has proven our brains place much more emphasis on content that is on the left and towards the top when reading a page. Even more surprising, the tendency carries out even in right-to-left languages such as Arabic, and modern uses of Chinese, Japanese and Korean, which are traditionally right-to-left languages read in columns instead of rows, have been converted to left-to-right and row-based reading to adapt to computer technology invented in North-America.

Thus, it makes sense to put important functionality/content to the left.

A Bad Example

A bad example of such a key design change is how Wikipedia very recently overhauled its interface. Although much of it is very welcomed and makes Wikipedia a more Web 2.0 reading experience (although its use of XHTML 1.0 Transitional remains puzzling after all the goodness about HTML5), there is still one thing I find exacerbatingly aggravating; the search box.

First, they changed the location of the search box. When in a page, I was used to go to my left to find the search box. It’s easy and it’s a key functionality amongst all the junk in the left menu I at least appreciated. Now, where is it? It’s on the far-end to the right. I will apologize in advance for my use of this word, but seriously, WTF!?

First, with the previous statement about research and how Google exploits this, it’s obvious what Wikipedia’s UX designers have done is horribly wrong. Putting the search box on the right, despite it being a key part of the Wikipedia experience, is like saying they don’t want people to use it.

Second, since there is no apparent benefit to putting it elsewhere, it shouldn’t have been changed. Instead of bringing better ease of use, all they’re doing is mixing up the millions of long-time users and confusing new comers.

Face the facts: Amazon, Google, Bing and YouTube, to name a few, where search is at the core of their business, put the search box towards the top and towards the center or the left.

Face the facts: Engadget, Ars Technica, TechCrunch and Gizmodo, to name a few, where search is highly secondary to their business, news being their core, put the search box somewhere along the top of the page, and often on the right, and not very big.

Wow, wait, isn’t Wikipedia’s “business” centered on the search for content of encyclopedic nature? That’s right, Wikipedia’s new search bar is both small, and right-aligned, which follows exactly the opposite of what a search-centric web site should do.

Even worse, what’s on the left of Wikipedia’s design could be easily qualified as site junk that would have had a better place somewhere on the bottom of the page or in a right hand-side menu. Is Random Article, About Wikipedia or Contact Wikipedia a link you’ll click on? Chances are you said no.

What to do?

Well, unless Wikipedia’s chief UX designer happens to read this, there’s not much you can do except complain everywhere you can.

But if you are a Wikipedia UX designer, take a good look at the critics in this article, at your design, at other’s designs, and at lots and lots of web usability theory, and then make the necessary changes to your interface.

I could ramble on and on about all the things that are so wrong about Wikipedia’s interface and haven’t been the least fixed if not worsen in the latest design iteration, but the truth is all you have to do is fix the few nagging things (hint: search bar and left-hand-side menu) that are still boggling down the Wikipedia UX. The rest is already considerably fantastic for a web site that has to be accessible on hundreds of devices to fulfill its purpose.

Edit: A testimony to our ability to adapt

This article was published on May 16, 2010. It has thus been about 3 months since I’ve started using Wikipedia’s new design full-time, and let me tell you that in this little time, I have already become accustomed to where the search bar is.

This is why we call these things Interface Conventions. They’re “ways of doing” rather “absolute musts”. It’s by following so-called interface conventions that we ensure all of our designs remain original all while following some of the same rules. This allows users to easily translate from one application to another.

Break these, and even the most expert computer geek will be completely lost.

It happened to me in Gimp, a photo editing software rivaling with the well-known Adobe Photoshop. Being a longtime Photoshop user, I have never been able to switch to Gimp, despite many efforts. Things are so different they feel unintuitive and make the experience very frustrating. They may be better, but I would have to spend a considerable amount of years making day-to-day work on Gimp to observe this, at which point I would probably be biased because I would have forgotten about Photoshop.

This makes any designer reflect on whether the conventions are as important as many, including me, fervently claim, because to a completely impartial user, one who knows nothing about computers, your interface will be as confusing as any other, similar or different, because conventions are a human thing. People have to adopt them before we can safely call them conventions.

Should you rewrite the wheel? Do different because you can? No, not necessarily. Conventions still stick, and because more than half the world uses Windows XP, more than half the world expects computers to function just like Windows XP, and because 30 million iPhone and iPod Touch have been sold by Apple, 30 million users expect touch interfaces to function just like an iPhone, and 30 million users are already familiar with the iPad despite having never used it.

In other words, Wikipedia’s move is acceptable and quickly forgotten, but I still believe it shouldn’t have been done. In other, other words, you should try not to re-invent stuff people already know, for the sake of the success of your software. Note that in some cases however, re-inventing can be a necessary evil, such as for Windows Phone 7.

Posted in Uncategorized | Leave a comment

HTML is Fundamentally Flawed

The dream that HTML would one day be perfectly implemented across browsers is Utopian at most. That’s because the way HTML works is fundamentally flawed in the first place.

Lack of a Reference Implementation

Unfortunately, in the HTML world, the reference implementation is the one the browsers make. W3C makes at most only paper definitions of its standards, so there’s no definite render engine to which everyone must match themselves. And for some reason, all those companies can’t get to an agreement and customize the way the HTML appears, such as form overlays, etc. as they see fit.

No real sense of version

HTML5′s move away from document types with versions is problematic, not beneficial. The reason is that without version numbers, the web cannot be a standardized platform you can “support”. If HTML would have very well defined references for various versions, such as 5.0, 5.1, etc. it would become much easier for browser manufacturers and developers to develop for the web. With reference implementations, it wouldn’t create a mess, unlike what the open source community has fun believing, it would organize everything. You could target a specific version of HTML because certain browsers support it. This would in one fell swoop relieve the web of much of its compatibility problems, because browsers could keep separate render modes that accurately always respect the version of HTML the developer is targeting, much like Internet Explorer’s compatibility view, only better.

The CSS box model is fucked up

If you read my article on the box model, you’ll quickly realize the reason CSS is so hard is not because you suck. In truth, CSS is so fucked up that I truly believe we should just trash the current specification.

Pre-defined styles have got to go

If HTML is to get truly better, one thing that has to go is predefined styles. Believe it or not, if it weren’t for pre-defined styles, much of the rendering problems with Internet Explorer versus more standards compliant browsers would go away. Why? Because the problem with Internet Explorer is in large part its default values that differ, not its support for features. Now, this has been mostly remedied in Internet Explorer 8 going forward, and the Internet Explorer Platform Preview (a.k.a. IE 9 dev releases) is actually more standards compliant than other browsers today in certain areas. Digressing aside, even though having 0 pre-defined styles would make development longer, it would fix much of the rendering problems.

JavaScript

I think it doesn’t have to be explained further. For the future of the web to truly compete with RIA frameworks, JavaScript has to become Object Oriented and implemented in a much faster way, a.k.a. compilation.

Posted in Uncategorized | Leave a comment