Skip navigation.

OperaBook

leaving thoughts

May 2006

( Monthly archive )

Future Opera: Five points for Strategy

, , ,

There are a lot of aspects to keep in mind and it is a hard way not to use strong marketing actions for a commensurable increase in market share. Operas way has ever been mostly to be better in technical terms, however IE's market share and the Lessons from the Browser Wars are strong signs that technical leadership is only a weak point towards higher market share. Alike the hype about Firefox is more about media driven marketing towards the likeable open source software than the respectable work of the developers (ie it is not the effect of the one big ad in the newspaper but of the many reports about that ad and its volunteer financing).

But I strongly believe I have some good points to increase the market share of Opera without advertisement driven marketing and thus within the philosophy of Opera ASA. And I don't count on an Opera hype.

My five strategic points are:
  1. focus end-user – this point is about keeping the technical leadership for the best internet experience
  2. focus web-designers – they are responsible for pages working in Opera and can make more webpages work in Opera
  3. focus be open & first choice – use Opera for different reasons
  4. find Opera in different places – use Opera because it is just there
  5. focus www.opera.com – as business card for the Opera products it should deliver the best internet experience as well

I will explain one after another in the following posts.

Originally I wanted to increase the market share by 10% six months after the release of the new version in my responsibility (which will need at least one year from now) as product manager for desktop Opera. After some more time seeing the topic with the special focus towards market share and checking the single points I now think 10% has been too tough to be reached without advertisement and without external effects. Well, I think the following points are enough for maybe 5-6% - what would be an enormous growth already. And I don't think that Opera could not get higher by any technical improvement.

Future Opera: Labels (3)

, , ,

You should read the previous posts Labels and Labels (2) for description and details.

This post is the ending summary about alternatives, dependencies and commercial / strategical impacts.

Alternatives
None of the alternatives deliver the same big improvement towards a more intuitive and overall equal UI. They are also less capable to provide the basis for other features that need easy convertibility.
  • The easy alternative is to go on with the current mainly folder based user interface.
  • Adding some more or less independent functionality of simple labels.
  • Adding semantic labels only to some of the places described and not everywhere in Opera.

Dependencies:
  • Redesign of UI (Magic will be the topic of a following post) will have some synergy effects.
  • Redesign of the internal indexing / database structure to solve the system immanent problems (get more independent from the unreliability of the OS file system; problem about possible inconsistency in the indexing itself). This problems should be solved anyway and are pretty much needed to make the semantic labels work properly.

Impacts (rough estimations):
This estimations are towards a solution that is only inside Opera (especially without conversion to online bookmarking). All panel-functionality is affected, tab-grouping will probably be separate.
  • Costs will be major to more than major, 500-700 FTE, 50% (or more) pre-projecting and functional design, 20% coding (or less – this and the total costs could be higher when there is a very different handling of the different places in current implementation) and 30% (or more) testing (I feel kind of crazy writing this numbers not knowing the development process at Opera)
  • Time needed: 9-12 month
  • File size of Opera might be about the same (depending on current implementation - it could be smaller, if there are currently different modules for the different places), rendering core untouched
  • Performance is not critical (as the current performance of M2 with much more data is very good), but performance is probably affected by the redesign of internal indexing / database.
  • Security issues are not critical (not higher than with other UI changes)
  • RAM usage depends on current implementation (same as file size)
  • Market share would probably increase by +1-2% points (ie from 2% to 3-4%) in a (pretty long) period of 12 month. It will be not as much make people change towards Opera but making people stuck with Opera because of the outstanding UI. I expect very good reviews in magazines. The effect will be lower when Firefox or IE have similar functionality at this time.


Closing words
From users view this feature is mainly a change of the UI. As the current UI is already kind of old fashioned (although still very effective) there probably have to be major changes. Semantic labels are only a smaller part of that.
The bigger impact of this feature will come when it is used to interact with other online and offline storages (strategical focus to be open).

Future Opera: Labels (2)

, , ,

You should read my first post on labels before you start to read this post.
The topic is continued here.

4. Labels everywhere in Opera
You probably think I will start to claim to have labels in every panel. Well, far too short. I think of labels everywhere in Opera: for the tabs and the settings even for any button. You probably think that's strange. Let's say it is new and it is keen.

I see two major advantages in this idea:
  • It is easy for the user to find things working the same way in any place.
  • It could keep Opera's download size small and probably reduce the complexity of the hard coded software. One module for all. The disadvantage of this point is the customising: it will be hell of complex to find the right defaults and to define the restrictions of the user.

I assume Opera has already a reused index based data-base functionality for most of the following parts. This could be the core for the methods to store semantic labels by adding another index-level (or maybe it is already the way needed). And labels are just entries in the indexes and the database. What will be more difficult is to fill the indexes. I suppose there are some pretty smart experts at Opera to manage this. And there will be quite a lot of work for the design of the user interface. Maybe that point is easier if Merlin does some magic – that will be the topic of a following post.

I don't claim all should be done at once or done at all, although it is really appealing to me and the idea is worth to be thought about.

Let's start with the simple: the panels:
a. Searches
Searches could be clustered and several search engines asked in one. User could have a label “prices” and with a click he'll get all his price comparison pages opened with the result of the search.
Additionally some people may have a lot of search engines with the new option to generate your own searches with just three clicks – means to sort and find will be urgently needed.

b. Bookmarks
I already talked about bookmarks when I introduced semantics in labels.
Additionally I want to mention that with the possibility of easy conversion to labels it will be easier to export bookmarks to online bookmark services and maybe even import and synchronize them (though this will be different features).

c. Mails
Currently emails can be viewed with several filters scattered all across the UI.
With the panel and with the big button in the mail-toolbar you can access your folder like views.
With right click you can choose to show messages from all accounts or from one special account (the first answer from support when user is horrified about lost emails to switch to all accounts here).
Whether to show spam, deleted etc and which time should be shown has to be selected with the view button in the toolbar.
There are some more specials. Actually I couldn't find the option to show only the messages with a special label – has to be somewhere around (found it – in the panel).

The same time there are all that options somewhere in hidden space the list of entries in mail panel grows pretty long with time:
  • one entry for every IMAP-account
  • Newsfeeds
  • Mailing lists
  • Attachments
  • Searches (where sub-folders are opened with every new panel-search with all the for me useless old searches)
  • Labels
  • Active threads
  • Active contacts
  • Filters (with the option either to view all or none)
  • All messages - with the normal folders for email (including almost useless drafts, because more and more sent mails go there and could only be deleted in both – drafts+sent – well, that's another topic)
  • The Mail Panel could be splitted on the bottom to see the status of the single accounts (what is quite a list on my M2).

There are very little possibilities to change this panel with the means of the UI. And inside the categories in the panel there are only simple labels that cannot be organised further.

Summing up we have on the one hand different viewing options that are scattered across the UI (toolbar, panel, right-click on panel folder) and at the same an overcrowded mail panel with very few possibilities to fit it to the personal preferences. Hence UI has hard to find options and a lack of options at the same time. That's neither surprising nor unusual because it is just the gap between mighty and feature rich software and the need to have a usable and clean user interface – and too many options could be confusing, too.

Yet another call for semantic labels. All problems could be solved (generating some new). They will enable to have a consistent usability that is customisable for most of the special needs of users, hiding options on demand and giving easy to see and easy to understand access to all options at the same time. The user has to understand the hopefully intuitive way to handle semantic labels.

But what will it look like and how could it work: as in bookmarks you can have folder like view. But unlike folders with a lot more flexibility.
A normal click on a label will work to view the emails that are selected with the label. With an small arrow at the side of the label or with double click or with a “+” in front of the label or with context menu the structure of the label is shown and gives access to the sub-labels. A normal click on such a label will show the according emails.
Highest flexibility will be reached by having the possibility to select/deselect every label. Deselected labels on the top level shouldn't be shown and can be accessed by a special sign (ie double arrow) or a separate label (“more”) where it can be accessed directly or be selected to show up on top level.
Deselected sub labels exclude the according emails from being viewed, working like the current option view – show - show spam/show trash/etc. This option will for example allow to view the mails of all accounts except one (ie the one with all the unimportant newsletters).
Deselected labels could be visualised greyed out and the selection could be done by click on “+” or “–“ inside one edge of the label.

My proposal to show labels is to have “+” and “-” in front of the label to show the structure/sub-labels (like in windows folders) and inside the label at the right end a different “+” and “-” or an arrow to deselect a label or to make a greyed out (deselected) a selected one (or on top level to show it on the panel).

There has to be the same possibility to manage the labels as in bookmarks.
It may be reasonable or even necessary to reduce the set of possibilities to sort labels.

Simple examples – yet without the complete means of semantics in the labels:
Panel or toolbar show on top level following labels (user defined):
+.unread (9)
+.spam
-.important (4)
. . . +.personal (1)
. . . +.work (3)
+.threads

+.more

The numbers show the quantity of unread messages.

With click on personal following subfolders could appear in following kind:
.accounts
. . . mynewsletters@for.me (deselected)
. . . me@work.org (selected)
. . . formyfriends@home.me (selected)
.sent (deselected)
. . . accounts
. . . . . . mynewsletters@for.me (deselected)
. . . . . . me@work.org (selected)
. . . . . . formyfriends@home.me (selected)
.received (selected)
. . . accounts
. . . . . . mynewsletters@for.me (deselected)
. . . . . . me@work.org (selected)
. . . . . . formyfriends@home.me (selected)
. . . filters
...


I put the accounts there tree times to show the principal possibilities of the idea of semantic labels and the complications that might come with unrestricted use. But technically this is simple to solve. The semantic rules for system labels are not subject to be changed by the user. Therefore accounts will always be subset of sent and received (or vice versa but not both).

It has to be thought through and tested whether it will cause problems to allow advanced users to have a user label with the rule same as a system label and have rules for this user label that are opposite to the normal rules for the system label. If this is allowed it will be very difficult for the user to handle this chaotic complexity but if it would work – why not leave the choice to the user (there could be a warning when user starts to do so).

The labels do not only have to be accessible in the panels but also on the toolbar and maybe on right click, too.

Personalised and or automatic contact views could be shown instead of Active contacts.

d. Contacts
It is possible to group contacts with labels and using semantics it is easy to access bigger groups build upon subgroups – to view mails of this group or to send email to the group like with the current folder structure, but much more usable. Rest is similar to bookmarks.

It will be possible to integrate contacts panel completely into the mail panel/toolbar.

e. Notes
- similar to bookmarks.

f. Transfers
Transfers could have system delivered labels for source URL (site) and date similar to the new history in Opera9. Additionally there can be labels for type and size of file and even for the state of the transfer.
Allowing to organise the labels in semantic structure user can put long running torrents in another view than the small security updates that should be installed as soon as possible. There could be a splitted window to view several sets well organised at once. Splitted windows can also be an option for other parts of Opera.

g. History
Besides the possibility of automatic labelling using Bayesian filters (where I don't think the results will be satisfying in the first time) the history can be organised like in Opera 9 giving easy access via labels with the enhancement of the possibility of multiple filtering and predefined views using semantic labels.
Additionally manually provided labels can be shown here – see Windows + Tabs below

h. Links
Could be visualised and organised with labels according to type of file, type of connection (https, ftp etc) and search strings delivered by user.

i. Windows
With the windows panel the whole idea of organising tabs is affected – as it is just another place besides the tab-bar to have access to the tabs. The additional Opera windows could be handled the same way, if technically possible. Windows can have a (temporarily) label that is shown in the OS-taskbar instead of showing the title of the just active tab in the window.

Take the next step: labels in tabs
It should be possible to change the name of a tab and let's call it label. The name of the label is displayed instead of showing part of the title. Similar to bookmarking a label could be proposed by Opera. Since there is the possibility to lock tabs and have them open for weeks this would be of great value – especially if there isn't an unique and easy to recognise title and if there is no easy to recognise favicon. This option can be misused as well for hiding the meaning of an open tab – maybe the boss is close :wink:

It could be consistent to have multiple labels for a tab – then there is the need of an attribute for one of the labels that this should be displayed on the tab-bar (and in the windows panel). It would be consistent and easy towards bookmarks: tabs may be opened from bookmarks so the label could be delivered at once. If a page that has a bookmark is opened from a different place it should show the label, too.

The hierarchy of semantic labels on the tabs could be used for grouping tabs, too. User can have the choices
  • no grouping (default, no user action required)
  • manual grouping (with proposal for the shown name derived from bookmarks or from Bayesian filter)
  • automatic grouping of tabs belonging to one site
  • maybe automatic grouping of tabs according to the user defined bookmark system and maybe supported by Bayesian filters

The member-tabs of groups should be visualised and have more easy access than the tasks that are grouped automatically in task bar of Windows XP. It will be some work to make UI smart and fast to work the Opera way. The issue of how to cycle/switch tabs – groups – and grouped tabs is only one of the open questions to be answered.

Somehow it feels it is not the time yet to have such capabilities in the tab bar (and the windows panel). I'll wait for other opinions.

In the end: labels for settings and for every button
Well, this must sound strange. But it isn't, mainly because this is different to the things before in one point: not the normal user interface will show labels. It is only showing up when changing the preferences and besides that is a way of internal organisation. The easiest way to describe it is from users view: save settings and give them a name – the label. This will be inherited down to the single buttons. In the easiest way there will be a complete profile having this name – quite similar to the existing setups for skins, menus, keyboard etc grouped by one name similar to the one-click-setup, what already existed in Opera for a short time, but as far as I know only for loading and not for saving and transferring setups.
As technical backend the hierarchical label mechanism could be used. There will probably be only one type of rule: is subset of that will go from the general to the more special:
toolbar-labelname is subset of setup-labelname
menu-labelname is subset of setup-labelname
button-labelname is subset of toolbar-labelname
icon-labelname is subset of skin-labelname

etc, while labelname is replaced by the different names of the setups.

This rulesets and the according labels and database-entries are only needed, when loading the several settings and of course when this settings are changed or saved.

The user can have easier control about the settings by sorting the labels in the semantic label style and easy can have setup-labeldefault together with toolbar-labelwebdev and button1-labelmyown. Well, on button level it will be a little bit detailed and I haven't made up my mind yet how to take care about how to store the place of the buttons on the toolbars.

With the possibilities of semantic labels for setup it will be easy to add some really useful and outstanding functionality. To have undo will just be adding another label with date and time and an corresponding entry for the setting before-change (could be done by a label with the same name and a system-postfix).

It sounds somehow too easy to make use of a matrix-profile (having the possibility to mix different things of different setups). But when the storage can follow the general rules for semantic labels it should be not too difficult to make the merging of the different settings work properly. An easy way could be to have complete setups in a ini-file where the steps for loading the single settings are stored: ie after the skin-header there will be the place and name of the skin-file and if there is an icon from another skinfile it is a second line in the skin section of the ini with the place and name of the different skin file and additionally with the place of a single icon in the skin.

[setup name]
my own

[skin]
main skin=%opera-path%/profile/skin/skin1.zip
icon=%opera-path%/profile/skin/skin2.zip,chat.png
button=%opera-path%/profile/skin/skin2.zip,chat.png
...

Every icon etc which is not especially declared will be taken from the main skin.
You can also take the notation of the skin.ini, expanded by path and file.

There could be one seperate ini-file for every label=setup, also for the date-driven undo-labels (date+time could be coded in file name). But I believe we will find smarter ways in handling those settings in a database more similar to bookmarks and history storage (it is even possible to take the labels only for the user action in the UI, but it will be more difficult and will not easily allow further improvements).

The main advantages will be again having the same modules for the software and having the same way to do things for the user. And it will be quite unique to have the most advanced and same time easy to handle features in Opera – and would perfectly fit the philosophy of Opera.

Some animated gif for Opera Desktop

, , ,

When I found the possibility to add own icons to the tags in this blog I played around with this. I looked for something nice, found cool stuff from SerbianFighter and added the dear Opera animated gif for the tag "Opera" from WhyOpera.

Then I wanted to have something different for "Opera Desktop" and found the idea from SerbianFigher appealing to have some of the main additional features visible in the icon - but I missed the red "O" in it so I changed the magnifying glass looking more like Opera - and added some blue to the world:
When uploading it to the Tags Properties it didn't look good at all, because it had been resized to 48x48px :frown:

I started completely new with the nice looking Opera Widget clock, the official RSS Feed Icon and some icons from Opera Standard Skin and made things more compact. This time I finished with a pretty nice animated Opera-gif. But it is still too big for the tag. The icons looked unrecognisable at 48x48px.

So I rearranged things and I created this a little bit different animation.

I think the two icons are pretty nice for my first animated gifs :cool:

Created with Gimp


Edit:
Pictures in this blog which are right or left are not shown in my Firerfox1.503/WinXP SP2 (works fine in Opera8.54+9w + IE6) - CSS validates and images are loaded and I couldn't find the fault in the source (I didn't search very long, looked pretty straight). Maybe it is a bug in Firefox?

Edit:
I just realized that I didn't tell you how to add own icons to the tags:
click Preferences on the top of your my.opera page, there Tags is the last right option (at least with my layout, maybe this is different somwhere else). There you can edit your tags - and add icons = images, which are displayed instead of the tag text (which are restricted / resized to max 48x48px).
Sorry for the confusion gabydewilde.

Future Opera: Labels

, , ,

Yet another call for labels for Opera's bookmarks? Yes, but that is only a very small piece of it.

Opera already has labels. In M2 you have 7 labels for emails from Important to Valuable. Well that is not quite what I thought of. But in M2 there is also another kind of labels, although it is not called labels. It is views and filters. In Gmail the same thing is called labels what filters are in M2. And I think Opera should start with just renaming filters and views to labels, as it is probably easier to understand. But I would like to have that really great philosophy of M2 everywhere in Opera – and enhance it a little bit.

Yet a different approach to labels all over Opera!

The main points:
  1. Have semantic labels in Opera
  2. Have automatic proposals for labels
  3. Have system labels
  4. Have labels everywhere in Opera


1. Semantic Labels
There is something pretty big coming up in development of WEB2 with Semantic Web, Semantic Wiki, Semantic Labels and so on. At least chances seem to be pretty good that there will be some major impact on some parts of WWW.
There is some Semantic Web Activity of W3C, standards like RDF as Resource Description Framework for Semantic Web and even Semantic Web at Opera.
I think of this as a development in a future some years away. And although it will be a vision for Opera to have advanced semantic web capabilities in the browser I see far less effort reasonable in the near future. But the technical implementation should be with foresight of further enhancements.
Following rudimentary semantic rules will provide a hierarchic and flexible system to have an array for the labels:
  • label a is subset of label b
  • label b is superset of label a
  • label a is equal to label b

Additionally there should be attributes on label level to trigger actions (which could but don't have to be realised with attributes=labels or rather attributes=system labels).

Probably you already have some ideas what this semantics is good for. I'd like you just to keep it in mind or write it down and give your ideas as a comment after reading this post. I did only few research on this topic but I have the strong impression that this will become something really big in aspects of usability and functionality.

For illustration I give just a few of my considerations:
Today bookmarks are sorted in hierarchical folders. Taking labels allows to have the same bookmark in different folders without storing and managing it twice (or more). With (hierarchic-)semantic labels there will be both possibilities in a consistent and easy system. Conversions from folder based bookmark systems (ie from other browsers) is equally complete like the possibility to use the labels as folders. In the other direction it is the same if every bookmark occurs only once in a hierarchy. If labels are used with full functionality conversion from label to folder system will either result in multiple entries of same bookmarks or have a certain loss in information about those bookmarks (not the bookmarks themself). If the user has the choice it will be no loss compared to normal folder based bookmark systems. Bookmark systems based on simple labels (I suppose they already exist in browsers and they will be widespread in near future like they already grow in online bookmarking) could easily be imported. Exported to simple labels will again result in a loss of information but will be no drawback in comparison to normal bookmark systems based on simple labels. Combined systems using folders and labels the same time should be transferable pretty good, although there might occur problems when folders and labels have equal names.
The same idea does not only apply to bookmarks but in quite the same way to emails, notes and file-systems (latter may be a topic for Opera in the long run).

Furthermore semantic labels should allow easier access to the hundreds and thousands of bookmarks. In folder based systems there are either long lists of bookmarks and / or folders or the need to open several levels of subfolders. Both will take time. Using simple labels will have pretty similar results either to have a lot of labels or labels with a lot of entries or even both. To use a search functionality is not always the appropriate tool: it will not help if you don't remember a part of the bookmark-entry and it will deliver only part of the results, when you are looking for a number of related bookmarks with a search for a keyword not present in every bookmark.
In that case I use either my systematic folder-structure, sometimes combined with a search (mostly if I think it is faster than climbing through the folders and sometimes if I don't remember the exact place of the subfolder). And all is even more complicated if the searched bookmarks are in several subfolders. The first label I will give to the bookmarks is probably update for all the the update and download pages for software bookmarks I organized in different folders.
Well, this special thing I could already do with simple labels. But with semantic labels it will be easier to find things – assumed there is an appropriate UI. It is hard to describe what this appropriate UI will be and which advantages there will be with the possibility to use the hierarchic structure of labels (with the power of categories) and free labels the same time. I'm thinking of the possibility to have several ways to reach the target – similar to views in M2.
One of it would be to have the folder like view, another is the access through label clusters and another is to search.
To one label the superset and subset labels should be shown (each show the number of bookmarks that have this labels), ie with outset and inset visualisation of the labels. While the subset label would intuitively lead to the intersection of actual label and subset label, there should be the possibility to reach the whole set of bookmarks of the subset label easily as well. For example hovering will lead to the intersection and a click will give the whole label entries.
For the first view on the bookmarks there should be shown a certain number of levels of labels (customisable or automatic). For example if all bookmarks are below two top labels each with 5 subsets of labels, then it seems to be a good idea to show the first two levels. If there are 10 top levels with numerous subsets then only the first top level should be shown. It is important to have a clever selection of starting points (labels shown at the start) to avoid the need to climb through numerous levels or are overwhelmed by big lists.
Additional there have to be means of managing the labels, to make them semantic.
The UI and exact working of labels is a point for further discussions and research.

2. Have automatic proposals for labels
To have the labels really useful there have to be labels on each entry - with a higher total number of entries there have to be more labels. Adding them by hand is work. In a hurry it is easily forgotten. This is pretty similar to emails that have to be put in folders. M2 delivers a great impression about the way it could be much simpler.
I guess it is not yet the time to have fully automatic labelling for bookmarks in the real world of not semantic webpages and with different habits of users. One possible way to make it easier to put a number of labels when bookmarking an URL is to offer labels that are most likely to fit to the content of the webpage and the label-habits of the user.
It will be quite a bit of work to have Bayesian filters select good proposals for bookmark labels, but it will be much easier than to predict the winners of the Sundance Film Festival. POPFile, which was used for the prediction (but originally is a Bayesian filter system for spam and more) performs more accurate than the automatic filters of M2 until now, probably because it uses the mail headers with special weights besides the mail body. With the information of headers and URL besides the HTML-page I assume there is often a direct hint for good proposals for fitting labels.
And with the semantic labels there often will be already a set of labels, when the fitting label is a subset of one or more superset labels.
The UI for automatic proposals for labels may show several proposals for labels (with their superset labels visible) which the user has to click in or out, including a de/select all. Proposals with high probability could be selected by default and those with lower probability deselected. Additional labels could be entered manually in an extra field (including the possibility to manage the label hierarchy / label rules).

3. System Labels
System labels will be automatic labels that don't need user action. They don't have to be technically the same type of labels, but this would be most appealing to me. Examples for system labels could be last used and most used (referring to single bookmarks and or referring to labels).
There could be also a system label for the history besides the bookmark labels (it would look like a folder in the root) – Firefox2.0 wants a more visible place for the history because a lot of users don't know about history or don't use it – and an unobtrusive place besides the bookmarks seems to be ideal to me – and it would deliver a first step towards automatic bookmarking. Additionally Opera's notes could find a place in the bookmark panel (because they are bookmarks).
Further system labels could show all bookmarks from top level domains or of sites with a certain number of single pages in bookmarks (I'm sure we can find more useful things for system labels).

4. Labels everywhere in Opera
to be continued

change log
edit 11. May 2006:
+ Semantic Web at Opera
+ importance of good starting points
splitted point 2. Have automatic and system labels in Opera into
2. Have automatic proposals for labels
3. Have system labels

rewrote and clarified point 3. Have automatic proposals for labels
+ notes in bookmark panel

+ some minor changes to clarify language