dW

Feb 15th 2011

Opera’s Interface, Part 2

About six months ago I wrote a long article showcasing my suggestions for improvement to Opera’s interface. I mentioned in my review of Opera I would be writing more on the interface, and here I go. I mentioned in said previous article about the interface I had no clue what was coming in Opera 11, and Opera 11 has indeed changed a few things. Like before I’m going to show an image or series of images followed by ordered lists of points which correspond to numbers placed in the images themselves. Also, like before clicking on the image will provide a larger unadorned image for perusal. First, something different, though.

Opera Mac OS X
Opera Windows 7
Opera Ubuntu Linux

Above are three images which showcase Opera on three separate platforms: Mac OS X, Windows 7, and lastly Ubuntu Linux respectively. Last time I touched upon this subject I only fleetingly mentioned how my suggestions could apply to other platforms. The images above show a bit of that. Unfortunately I don’t have the free time to mock these things up for three separate platforms, and this is as far as I’ll go this time to show how my ideas apply to platforms other than Mac OS X. What it does show clearly is that everything here can very well apply to multiple platforms while maintaining each platforms’ differences.

Diagram of a Typical Opera Toolbar Button

Before returning to the format present in my last interface-centric article I need to discuss possibly the biggest change to the UI that Opera hasn’t even addressed yet — the extensions’ icon size and its effect on everything else.

Extensions have the ability to add an additional button to the interface, currently restricted to reside on the right side of the Address Bar. Opera, in an extremely odd move, made the icon size 18x18. A standard small icon size is 16x16, and this is the general size of toolbar icons in Mac OS X — at least icons which reside in push buttons. Since Opera has chosen this oddball size for extensions it needs to stick with it for the rest of the application.

At present toolbar button icons are all sorts of sizes in Opera. There’s no consistency. This can easily be seen by simply adding a Print button or the Author Mode/User mode button to the Address Bar. The icons are far too big for the buttons they reside in. One of Opera’s best features is being able to add buttons practically anywhere, so it’s more necessary for consistency in Opera than most applications.

My proposal is something like the diagram above.1 All toolbar icons need to fit within an 18×18 container with the exception of panel selector icons. I’ll have an opportunity to explain just why later on.

Opera with Webpage Open and Close Button on Active Tab Hovered Over
Opera with Webpage Open and Open Panel Hovered Over
  1. Opera 11 changed a lot of things, and its tab stacking made my attached tabs used in my previous set of mockups impractical. These are more similar to what is used now in Opera. I didn’t illustrate tab stacks here. My idea for them is quite similar to what is available now anyway.
  2. One major difference on the tabs would be the close button. Presently the close button in Opera resembles Safari’s. I find that a mistake. Safari’s present close button first appeared in the Safari 4 beta where Apple experimented with putting the tabs on the top of the window. In their compressed state the square close button made sense because it followed the contours of the tab. It doesn’t today in Safari and neither does it in Opera; it’s a fish out of water. My proposal is to make it a simple “x” and a circular close button very similar to the Mac OS X standard close button when hovered over. It has the added benefit of being similar to what is used in the standard skin; it adds consistency between the platforms.
  3. Here I show the hover status of the Open Panel button. This is one of the few examples of a deviation of the strictly buttoned appearance I’m trying to impose, but I believe it is necessary. It looks like it belongs there. The icon still fits within the 18×18 bounds, so if it was placed by the user on another toolbar which uses the push button appearance it wouldn’t break layout.
Opera with open Mail Panel and Webpage Open
Opera with open Mail Panel and Unread Items Open
  1. The Panel Selector Bar as it is today simulates a triangle tab’s sticking out from the left side of the panel. This can only visually work if the pixels immediately to the right of the triangular tab is the same as what is contained within itself. This illusion is broken already when the first panel item is clicked on. The triangle isn’t the same color as the toolbar’s gradient. In addition there’s this unsightly vertical padding on the top of the bar that’s only there because of this need to preserve this false illusion. What’s best here is to make it point from the panel selector towards the panel.
  2. My icons are also much smaller than what is there now — a maximum of 16×16. They are that size because of Web panels. Today if a user were to create a Web panel the icon would be smaller than the rest of the panel icons, and the layout would break. If all the icons were the same size like they are here then the layout wouldn’t break. The default Web panel icon here is also shown in a style similar to the other panels’ icons. The consistency in design leaves Web panel authors open to design favicons for their panels which also uses the common style like what I’ve shown here with a CSS panel.
  3. Like the Panel Selector Bar the panel itself is BLUE. Sidebars in Mac OS X are blue, not grey. I chose to mock up the mail panel first because I believe what’s there now is complete garbage. It needs to change badly. As can be seen here section headers are capitalized and devoid of an icon. Everything doesn’t need an icon, and everything’s having an icon creates visual overload and hinders information hierarchy. In my mockup each section collapses and expands, and count badges only appear on section headers when the section is collapsed. Section headers should not be fixed positioned and the scrollbar should remain the Mac OS X standard scrollbar. The simplified scrollbar used now is useful in some situations (unfortunately I don’t have any of these mocked up this time), but it is out of place here. I’ve used the regular size scrollbar, but a mini scrollbar would be appropriate as well in my opinion.
  4. Typically in Mac OS X a sidebar’s toolbar is at the bottom of the window. In Opera I think it should be as well. Also, in keeping up with the design of the Address Bar buttons on this toolbar will have a push button-like appearance, albeit with a blue shade to them. Mac OS X buttons of this type typically do not have colored icons within them, but in Opera’s case it is necessary due to the sheer amount of commands Opera can perform; it would be foolish to make them all in a simplistic monochromatic style — indeed it would be monotonous. It’s a problem I see in some Mac apps today even with a small set of icons; they become difficult to differentiate upon first glance. An added benefit to using the push button style is that monochromatic icons like what is used for navigation in the Address Bar don’t feel out of place sitting next to full color icons like they do now in Opera.
  5. Selected items in sidebars on Mac OS X have this colored gradient bar behind inverted content. Opera should do this as well, and the selection should honor the user’s Appearance setting: Aqua or graphite.
  6. I’m demonstrating here that Opera’s current behavior of showing a menu icon on section headers upon hover is maintained in my vision for Opera’s mail panel.
  7. The Mail Toolbar shares the design of the Address Bar, complete with full color icons which have a maximum vertical height of 18 pixels. The mail search input hugs the right side of the toolbar and sticks with the OS native appearance and behavior of the search input on the Address Bar unlike what is there now.
  8. The list headers do not have a 1 pixel margin and do not have double borders between each header. This is a very basic thing in Mac OS X which shouldn’t have to be shown and demonstrated for correction, but here’s my demonstration for correction. In my mockup I have the received column’s being used for content sorting with the newest item at the bottom. This should either be the default or there should be a setting so the user can make it the default behavior. This is one of the major annoyances of the mail and feeds client.
  9. Rows in the list view should be zebra-striped, and the stripes should continue down the entire length of the view as demonstrated here. They also should honor the user’s Appearance setting. So if the user has the Aqua appearance selected there should be alternating rows of blue and white. I use Graphite so they’re grey in my mockup. It’s quite stupid to have a feed as a contact, so this ability should be removed. When feeds are viewed with mail the icon next to the name of the author should be a feed icon. This different icon can be used to give the user an instantaneous visual clue that the particular item is a feed and not mail.
  10. The Mail Header Bar here is mocked up to be a light grey to white bar. I feel as if what’s there now is too dark and too monotonous. This here — while very similar — is easier to read than what is in Opera today.
  11. The Quick Reply Bar has long been an eyesore. It’s one of the first things I disable because it is indeed so ugly. What I have made here is still expandable and has all the features the current one has. Everything is flush with the interface, and the button is iconographic rather than textual as it is presently in Opera. It’s still quite obvious what the button is supposed to do.
Opera with Open Feeds Panel and N+ Feeds Open
  1. With Opera 11, Opera allowed users to have a feeds-only mail panel. I say take it a step further and make it a feeds panel when there’s no mail account configured, complete with its own panel icon and header.
  2. The new feeds-only mail panel in Opera is incomplete. It only shows the feeds section, but users need to be able to filter and label feeds along with viewing deleted feeds. A user can view all of the feeds through a contextual menu item now, but there needs to be a simpler way to access that feature. That’s why I’ve added an “All Feeds” item.
  3. Attachments are pointless in feeds so when viewing a listing that consists only of feeds there shouldn’t be an attachments column. Like discussed earlier having a feed as a contact is equally as pointless, so there’s no contact icon next to the author’s name. In fact there’s no icon at all because the feed icon used when feeds are listed amongst mail isn’t needed when all the items are feeds.
  4. Currently the stylesheet used for feed viewing is less than ideal. A stylesheet with proper leading and with images’ scaling to fit within the viewport would be welcome. Something worth noting is that the Quick Reply Bar is missing. It’s pointless when viewing feeds, and it shouldn’t show up when viewing a feed when it’s listed amongst mail, either.

That concludes everything I have thus far. This is less than I would have liked to have shown as I was planning on showing my ideas for mail composing, the downloads panel, and the downloads view. I looked ahead at my schedule and saw I’d have little time to devote to this task for a while, so I thought I’d go ahead and showcase what I have now. I think it’s enough.


  1. The diagram is an SVG. The image is also a link to a traditional raster image so people who are using browsers which are behind the times can still view the diagram.