Ten Dot Five
September of last year I wrote a review of Opera 10, named the title of the article “A Perfect 10″, and proclaimed it to be “the best release of the software yet”. Does Opera 10.5x stand up to my praise of version ten?1 No. I’m mostly going to focus on the Macintosh release as it is the platform I mostly use, and therefore it is the platform in which I have spent the most time using the application. However, I will discuss other builds when necessary. This is going to be a long and exhaustive review of Opera 10.5x, so get some coffee; it might take a while.
Unlike most software releases it’s imperative to discuss this Opera version’s development schedule due to a staggered process. Opera chose to develop the browser by placing focus on the Windows platform first, and releasing the Macintosh and Unix versions afterwards. The graph above describes the schedule as it stands at the time of this writing.2 The graph is an SVG, and Opera is the only browser in existence at the time of this writing which can view it properly.3 I’ve also prepared a PNG image for those who use browsers which are behind in their SVG implementations.
In December of last year most of us Opera users received an early Christmas present — an early build of Opera 10.5. It was presented to us just a bit less than a month after the first alpha build of Opera 10.2, a version that never reached final because there was such a desire to get Opera 10.5 out. Only the Windows and Macintosh builds were released initially, and the Windows build was quite a bit further along than the Mac one because the Macintosh one was a complete rewrite, going from the aged Carbon API’s to the Cocoa API. The Unix build was nonexistent, but it was stated that it would experience an even greater and more difficult rewrite than the Macintosh release. This sort of staggered release of snapshots was rather normal. The first alpha Unix build was released just a bit over a week later; the true nature of the development schedule wasn’t stated at all.
The users’ first glimpse into the development schedule didn’t occur until a month later:
The current estimates for the remaining work for Opera 10.50, however, indicates that we will reach final product quality earlier on Windows than on the other platforms. As such, we have decided to not let Windows users wait for the other platforms to catch up, and rather push it out earlier than the rest. You will notice this in the near future as we will reach the beta milestone for Windows, while Mac and Linux will reach beta around the time Opera 10.50 reaches final on Windows. When the Windows version hits final we will focus our attention on bringing the other platforms to the same quality as soon as possible. We also expect this to be an exception from how we work, meaning we will once again ship final versions for all platforms at the same time in the future.
This news hit like a lead anvil. Opera’s always been accused of placing Windows above any other platform, and here we were slapped with convincing proof of it. Windows releases have almost always been polished while the Mac and Unix builds have traditionally been far from it. Significant strides have been made in improving the Macintosh releases’ interfaces because of outspoken criticism from Macintosh users about it. Even today with all the improvements the application still feels sometimes like a ported Windows program, and Opera is never going to gain a lot of Macintosh users by not catering to the platform’s aesthetics. The same can be said for Unix, and it’s not until 10.5 it’s even received the attention it deserves.
Staggered releases like this have been done before with less than appealing results. Adobe produced staggered releases of their software in the late ’90’s. Adobe decided to place more focus on Windows development, releasing versions of their Macintosh software on a slower schedule. The result of that experiment was Windows versions of their applications which were stable and Macintosh versions which were far from it, creating user backlash because the majority of the professionals creating quality artwork using their programs were on the Macintosh platform. When using common sense the reasons for this outcome becomes quite obvious. Upon release of the Windows versions of their applications it was only natural for the developers to feel a sense of obligation to get working versions of the Macintosh counterparts out as quickly as possible. Because of that the care which normally would have been taken during the development schedule was reduced significantly simply because there was a rush to get the work done. Opera 10.5 suffered a similar problem; the only difference’s being that it suffered the same problem on all platforms, not just the ones not given initial focus.
On June 11, 2009, Microsoft agreed to not include Internet Explorer in its bundling of Windows in the European Union because of a lawsuit initially filed by Opera.4 I was initially against this lawsuit despite the fact that I agreed with Opera’s complaints because there was no mention of a solution for end users as they would be getting an operating system without easy means to even get a Web browser, Microsoft or not. I wasn’t the only one who foresaw this problem.5 That decision didn’t empower users at all; it hurt users buying Windows alone as they had to resort to alternative and sometimes archaic methods of obtaining a browser. Eventually later that year the problem was solved when the EU agreed to allow competing browsers to randomly be listed on a browser choice screen; Eventually the decision was made to make the choice page finally be public on the first of March, 2010.
This browser choice screen created a deadline for Opera 10.5 as it would be beneficial for Opera to have their latest and greatest ready for download when that page went live, and that’s exactly what happened. It generated a mad rush and a lot of overtime work, but the build was finalized on time. Opera had 10.50 ready for download on the browser choice screen. While extremely fast, The build itself was quite unstable and contained numerous bugs which never should have made it to a final release. Many of these problems have since been attended to, but if my first time using Opera was Opera 10.50 I’d be hard pressed to ever download it again.
The 10.5x releases so far for the Macintosh weren’t devoid of any easily-caught bugs either:
The Mail panel bugs are extremely old bugs, having existed for several versions now — perhaps as far back as Opera 7 or 8. To make matters worse Gmail crashes Opera on the PPC build. The print preview problem and the Gmail crash especially should have never made it to the final. The Desktop Team did state that they would revert to their usual development schedule after 10.5, and I sincerely hope Opera never adopts a schedule similar to this in the future as I believe this release has suffered quite a bit due to the change in procedure.
The interface is at times the most important aspect of an application; this is most true for the Macintosh platform. If it is poorly designed and therefore hard to use that alone will doom any application no matter what it’s capable of doing. It’s how the user interacts with the program. Opera’s been accused in the past of having a rather atrocious interface, and I thoroughly agree with such sentiment. However, Opera has improved significantly because of the improvements made to its visage.
There were so many changes to the interface last time I had to pick and choose what I wanted to focus on. This time around there’s really only two major changes to the interface on the Macintosh — the unified toolbar and the thin panel separator. These are actually significant changes that are welcome to many Macintosh users, but I can’t help but feel some disappointment in the overall interface of Opera 10.5. After the quantum leap experienced by the change in appearance for Opera 10 I would have expected polish for this release. By polish I mean a significant continuation of the interface design by applying it to the platform’s specific design aesthetics. Aside from the two changes mentioned above Opera 10.5x is essentially devoid of any such attempts.
There’s so much to discuss about Opera’s interface that I could probably write a novel on it. What I’ll provide right now in the form of screenshots are a few obvious problems adjacent to examples of acceptable similar interfaces in other programs on the Macintosh. I hope to communicate these and other problems in more detail at a later date, but the few examples I do provide at present should showcase necessary improvement to Opera’s demeanor.
Aside from the panel’s background color it bears little resemblance to how a listing should be handled in a sidebar on the Macintosh platform; it looks more like a Classic Windows listing.
Opera’s interface is littered with rectangular, hard-cornered, and ugly buttons which look nothing like what end users expect buttons to look like.
Opera’s list headers are a noble attempt at appearing Mac-like, but they fall apart when examined next to an example of a native Finder window’s list headers. The Classic Windows-like margins are especially unpleasant.
These problems have existed for quite some time in Opera, predating the release of Opera 10. I didn’t choose to cover these problems in my last review as I foolishly expected many of them to be addressed. No matter what vast interior improvements are made Opera’s going to continue to be ridiculed on the Macintosh for failing to integrate with the platform unless it takes significant strides in actually integrating the appearance of its interface with the system. I cannot downplay the progress which has been made on Opera’s interface over the past couple of major releases, and I realize it’s difficult and requires an insane amount of obsessive-compulsiveness to do; it’s just extremely important to end users of the Mac platform to get this absolutely right.
In its initial post about Opera 10.5 the Desktop Team listed platform integration as an important aspect of this release. On the Macintosh this meant a rewrite using the Cocoa framework and usage of Core Text for all text in the browser. People with modern MacBooks will be able to use finger gestures to navigate Opera, and all Mac users with Growl installed will enjoy much better notifications.6
It’s hard to really describe the significance of Opera’s conversion to the Cocoa API. Programming an application with Cocoa automatically creates a particular look and feel — the look and feel Macintosh users expect out of their applications. However, due to Opera’s necessity to retain immense abilities for end users to customize the interface it doesn’t get to benefit from much of that automatic platform integration, and aside from the automatic basic visual improvements like the unified toolbar Opera gains nothing but perhaps a boost in speed from the switch to Cocoa. Its switch to Core Text definitely means an increase in speed, but it also means text appearance consistency between it and the majority of the rest of the platform — a very good thing.
I don’t have a modern MacBook or access to one, so I cannot say much about the multitouch gestures. I do own an iPhone, and navigating Safari using similar multitouch gestures is a treat. I assume this applies to working with the Magic Mouse as well, but again I don’t have access to one of those either. I’m rather sure they’re welcome, and I can see where they’d be extremely useful.
Growl notification support is something I absolutely never thought I’d see in a million years. It hit me like a bolt of lightning when I read it. Opera’s internal notifications have always been annoying, and aside from popup notifications I’ve always disabled every last single one of them regardless of platform. The reason why I never thought I’d see it is Opera’s tendency to use their own implementations of everything else. Opera uses its own address book, its own dictionary, its own password storage, et cetera. It’d be even better if Opera’s built-in notifications somewhat copied Growl as its way of handling application notifications is a prime example of ones which are not obtrusive.
On the Macintosh there’s a few more things which could be done to improve platform integration, and those would be interface improvements, Keychain integration, Address Book integration, Dictionary integration, and scripting support. I’ve already touched upon interface improvements earlier, so I won’t discuss that any further. Address Book integration is imperative. It’s ridiculous to have to refer to the Address Book application for an email address because Opera doesn’t link to it. That’s the primary reason why I won’t use Opera’s built-in mail client. All my contact information is in the system’s address book and can be accessed by my phone and most applications on the platform.
Keychain support isn’t absolutely imperative in my opinion, but it’s important to a lot of people. My brain stores my passwords, and I don’t want a computer storing my passwords for me. Storing passwords in the system is useful for a lot of people, and like the Address Book the Apple Keychain is used by most applications first party or not on the platform. It’d be quite useful if Opera did as well. Hell, the Subversion command-line client has Keychain support for crying out loud. In addition to this I know many people who absolutely refuse to use Opera because of their reliance upon Keychain or 1password. That’s their own stupidity in my opinion, but at the very least adding support for 1password would be beneficial for a large amount of people and not at all unprecedented now that Opera has Growl support.
Mac OS X also has its own built-in dictionary, and again the majority of the system’s applications utilize it. The system’s dictionary can learn words provided you manually teach the words to it. Doing such in one application would make the learned word recognizable by the entire system — except Opera and other applications like it which do not use the system’s dictionary. I don’t use inline spell check, and I don’t use spell checkers that often. I much prefer to use a custom search in Opera to spell check individual words for me, so like with Keychain support my call for Dictionary integration is more of a feature request for others than for myself.
Sometime during Opera 9.5’s development Opera added in basic AppleScripting support. It’s been difficult tracking down initial information such as an announcement about it. If memory serves me correctly it was originally announced on the Mac Team’s blog. Unfortunately its entire archive has been wiped, so all the informative previous content is no longer there. There’s not a single mention of it on the Desktop Team’s blog. In fact the only location on the entire domain I could find any information about it was a small post on Opera employee Michael Vacik’s blog about updating a TextMate bundle to support Opera. Its support was indeed basic, and on the surface it looks as if Opera 10.5x is bereft of any support at all as AppleScript Editor cannot find an AppleScript library for Opera — even when told to look for it manually. It must contain basic support as LittleSnapper uses AppleScript to grab the active tab’s URL for capturing, and it still works with Opera 10.5x. Opera could get ahead of the curve and implement a robust AppleScripting environment for end users to utilize, even going so far as to allow AppleScript to be used in buttons on its interface. I’ll admit this isn’t a very important feature to focus on, but Opera would indeed receive a lot of praise for it because aside from Safari its competition is nearly devoid of any support.7
There are five major new features and major feature improvements in this version. Opera has finally added in better inline searching and private browsing. Most uses of dialog boxes are now non-modal, and Opera now has a changed cache viewer. In addition, widgets are now handled differently, increasing their usefulness exponentially.
Opera has actually had inline searching for several versions now, but it’s been somewhat of a hidden feature — accessible only by pressing
.. It would pop up a small box at the bottom of the page to type the text in. It was clunky and not really that accessible. The functionality of the new method is quite welcome as it’ll show a bar for searching regardless of whether the
. shortcuts are used. Despite all this improvement the inline search bar still looks rather ugly, overly large, and doesn’t much at all fit Mac OS X’s axioms.
As far as I can tell in 2005 with the introduction of Safari 2 Apple invented private browsing. Since then every browser has created their own implementation of the concept. With Opera 10.5, Opera’s added in their own private browsing functionality. In the usual Opera fashion they’ve gone further with it, adding in private tabs in addition to private windows. On other browsers private browsing is toggled in the menus and makes everything you do from then on out private. Now in Opera private windows or tabs can be created, allowing for both public and private browsing to be performed simultaneously. It’s not a feature I’ll be using much as I rarely use Opera on public machines, but I’m absolutely sure it’s a welcome feature for a lot of users.
For quite some time now Opera has been accused of being too obtrusive in its use of dialog boxes. Every last one of them was modal, and on some websites which made use of dialog boxes a lot it could get quite old. Opera’s finally solved that with its change to using non-modal dialogs. However, from looking at this screenshot you can’t tell whether it’s modal or not as it looks identical to many modal dialogs on the system. In fact, if Opera didn’t even tell us I probably wouldn’t even realize I could navigate to another tab while the dialog box is open because I’m so used to being restricted.
The second image above shows the same exact dialog box in Windows, and it’s completely obvious that it’s non-modal from the way it behaves and looks. I believe Opera should have done something like that on the Macintosh build, and if I remember correctly it did at one point during the development process. It wouldn’t look entirely native; nonetheless, there are instances where it’s best and recommended to deviate, and I believe this is one of those instances.
opera:cache in the address bar the user is shown a location in which it’s possible to peruse their cache. Other browsers have had this for ages, and Opera’s no exception. Prior to this release
opera:cache was just a simple listing of files in the cache. It wasn’t that robust, but it worked well for what it did. In its present form it’s almost completely useless. The entire process of viewing the cache with it is counter-intuitive. By checking boxes and typing numbers in the form at the top it would be expected that by doing so the list at the bottom would automatically change to your specifications; it does not. Clicking on a list hyperlink for a particular domain is required, and then a separate page is opened with that content which depending on what criteria was selected might indeed contain nothing and be a complete waste of time. Everything should just be done within that page, and searching for particular filetypes should be able to be done without having to know what domain the files come from. It’s cumbersome, and to be frank it’s rather retarded in how it works. The old simple listing was actually more functional than this.
Like with private browsing and inline search widgets weren’t an original concept invented by Opera either. It’s actually the first one to go about it the right way, submitting and working on a widget standard with the W3C. Doing such creates a standard in which anyone can follow, meaning widgets created for Opera’s widget engine could some day work in a different browser or application which also follows the standard. This is quite unlike what we find today with Yahoo! Widgets and Apple’s Dashboard which have their own separate ways of doing things.
Prior to Opera 10.5 widgets ran while Opera itself was open. It was interesting, but it wasn’t all that useful in my opinion. I use Dashboard for simple stuff such as weather, delivery status, and the yellow pages. Dashboard might be proprietary, but it’s always there — available at the press of a button. Now Opera Widgets run as standalone applications and are installed in the Applications folder with everything else. This means that entire Web apps can be created and ran as widgets instead of relegating widgets to being little simple information gatherers.
Opera now has support for HTML5
video elements. WAV and Ogg Vorbis are supported for
audio while Ogg Theora is the only thing supported for
video. It will play neither video nor audio outside of an HTML document which is unfortunate even if you manually tell it to open the files in the preferences; that’s something which I believe needs to be addressed as it’s silly to call upon a plugin to handle something which it supports internally. A sort of format war has erupted because different browsers are currently supporting incompatible formats. Hopefully much of this will be alleviated soon if the rumors about Google’s open sourcing of the VP8 format are true; if so I hope Opera supports it as well as Theora is shit when compared to H.264/MPEG-4 AVC or any other more modern codec in existence. VP8 is very much comparable and would be a great way for the Web to escape having to use a patent encumbered codec. Even then it’d be an uphill battle which is most likely to fail.
Webfonts support has been vastly improved in this release, and I am absolutely overjoyed. Opera still has trouble with split fonts, and hopefully that will be addressed in due course as it is in violation of the CSS 2 and 3 specifications to handle the font stack it the way it does presently. Another feature I called out for in my last review was local font overriding, and it works except in user style sheets where it would be far more useful in. Opera is well aware of both of these issues.
Border radii are finally supported in Opera. Yes, finally. Safari started it off with support for it in August of 2005, and here nearly 5 years later Opera has added support. The earlier reasons for that delay are really unknown to me, but recently it has been because Opera was waiting to use Vega for it first — a good idea in my opinion.
Native JSON support has been added as well. That’s another thing to say a “finally” about as Opera 10.5 is the last major browser to support it. Opera’s saving grace on this has been because IE 6 and 7 also did not have native JSON parsing, meaning external libraries were required. Yes, Internet Explorer 8 supported JSON parsing before Opera.
Furthermore Opera has added support for numerous CSS properties such 2D transforms and transitions; multiple background images; and Web storage and database support. There are actually much more, and if interested in particulars and information about what I just listed above it might be best to inspect the three separate documents I had to read through to verify my information here; it builds character.8
I personally don’t find Opera 10.5x to be as good a release as Opera 10 was. Opera Software has definitely made significant improvements to its browser, but I think because of the scheduling the immense speed improvements, Web tech support, and new features all have been at a cost of stability and polish. Would I, personally, use anything else instead of Opera? Not no, but hell no. It’s just that if I think of it in terms of whether or not I would recommend it to my sister or someone not as familiar with the software or the technology behind it I wouldn’t recommend it at all. It’d be too cumbersome to have to describe to her that the browser is awesome, but Gmail crashes it on one of her computers.
I will refer to what I am reviewing as Opera 10.5x because there are multiple point releases included in this review. ↩
Opera Software also has a graph of their own, but it portrays predictions on releases. My graph also doesn’t acknowledge the “pre-alpha” releases because quite frankly calling something a “pre-alpha” is stupid. Seriously, what’s before alpha in the greek alphabet? Yeah. Nothing. ↩
Numerous parties eventually joined on Opera’s side. ↩
Opera received a lot of bad press on this issue. Aside from criticism on the users’ lack of a means to download a browser the rest of it was unjustified drivel. ↩
Anyone with a Macintosh should install Growl for unobtrusive and useful application notifications. ↩
And Safari’s support isn’t that great either. ↩
This fragmentation is due to the fact that there’s been three iterations of the browser engine since the previous desktop release of the browser. There are documents listing changes between desktop release versions, but they’re neither as complete nor as detailed as these. ↩