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
. . . [email protected] (deselected)
. . . [email protected] (selected)
. . . [email protected] (selected)
.sent (deselected)
. . . accounts
. . . . . . [email protected] (deselected)
. . . . . . [email protected] (selected)
. . . . . . [email protected] (selected)
.received (selected)
. . . accounts
. . . . . . [email protected] (deselected)
. . . . . . [email protected] (selected)
. . . . . . [email protected] (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 😉

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.