Kingdom Bookmarks

Any browser experiences a terrible shortage of instrumental space - each button, icon - its weight in gold (not the icon itself, of course, a place for it), to build many toolbars is awful and to create a complex hierarchy with the drop-down menus - is not always convenient, etc. etc.

On other hand, although each bookmark is relatively small entity, the entire "Bookmark Kingdom" is so big, that its size is a main contributor to slow browser startup and even of browser slowness at all, even memory usage etc. So, actually we have two big issues with "Bookmarks Kingdom" - management and shrink. The ideas below are aimed to solve or reduce the acuity, pain of them

I. Kingdom Bookmarks Management

Any novice user when he finds such a thing as bookmarks bar, starts intensively to use it and in just a few hours discovers the lack in space in it. He begins to compress the names, even just to give them up, (or opposite, removes favicons), but after a few days discovers almost the same lack in space. Then he begins to create folders in bookmark bar - this helps him, but as soon, as he created a folder - he lost such luxury as "Clicked - got", because he just can not directly click on bookmark - he clicks on folder, gets drop-down menu and then clicks on bookmark or subfolder to get submenu etc. if he built hierarchical tree.

1. "Clicked - got" together with complex hierarchy.

The first idea is to combine the luxury of "Clicked - got" with the presence of a complex and branched tree of folders with hundreds or even thousands of bookmarks in the bookmarks bar. The existing mouse usage of bookmarks is very wasteful. Currently with a left click on the folder, we get a drop-down bookmark folder menu and with a right click - drop-down tool menu (Cut/Copy/Paste/Add Bookmark Here, etc.) - this is impermissible poor, almost nothing relatively we really can get. The mouse click is composed of three phases: Press (P), Hold (H) and Release (R), where the second phase (H) is negligible. The fact that the operation is called by first phase (P) and not the last (R) practically does not win in time compared with the enormous benefits to be gained by implementing an "Execute by Release" (ER) approach. Also note that in the second phase (Hold) you can move the mouse. So, the idea is follows: the first stage (Press) on the icon will call drop-down bookmark folder menu, but Releasing the button on the icon will call the predefined menuitem of this menu. So, with one button we can have two actions - some bookmark on click (Press-Release = Click) or "travelling" among drop-down menu: Press -> leave the icon -> (here we can release the button and follow the standard protocol of drop down menu or release the button on drop-down menu itself - it will call the appropriate bookmark). I want to note that the drop-down folder menu can be also called by icon hovering even without Press

2. One icon - several folders

The described above approach relates only to one mouse button, let say Left for instance. But the same can be done for Right mouse button (for another folder) and for Middle mouse button (for third folder). So, one icon (or some text) can represent 3 folders and not only one. Moreover, even the hovering can be also implemented - in two variants:

• Only one from 3 folders will drop down its menu (let say, assigned to Left button)
• All three drop-down menues will appear by hovering, but as soon as on of these drop-down menues will be hovered, the retained two of them will dissapear

This idea will encrease the efficiency of such icon (the "gold" place) by 3 times. Taking into account, that each button has now 2 actions we just have efficiency increasing by 6 times!

3. Adding bookmarks

The standard way to add a bookmark to particular folder is follows: go to drop-down menu, right click -> getting tool menu and clicking on "Add bookmark here". But this way is a little bit boring and slow, I think. It is more elegant (I hope) to use the same mechanism as call bookmarks here: short click will call predefined bookmark from appropriate folder and long click (let say, more then 500ms (the time is ajustable) - will add the current page into appropriate folder. This approach will increase the efficiency twice, so, by 12 times totally.

4. Adding bookmarks dialogue.

There are two possibilities to add bookmark - with and without dialogue. It is reasonable, because sometimes the user needs to add bookmark as it is, i.e. without dialogue, but sometimes he needs some editting, correction etc., i.e. needs dialogue. Moreover, when he wants to add some page/site as bookmark, sometimes he doesn't know what will be a title and other attributes, so in these cases he needs a dialogue tentatively - maybe yes, maybe no. But the dialogue itself is a little bit boring thing... Moreover adding bookmark with dialogue requires one action, and without - another action. In other words currently adding bookmark "eats" two different clicks - one - with dialogue and another - without dialogue.

The idea below allows to use one standard way: tentative dialogue Let assume, that "Add bookmark" action will always open the dialogue box, but only on 500ms (or 1000ms - the time is adjustable). If the user needs the dialogue he must hover this dialogue box and it won't dissapear, if he doesn't need - the box will dissapear in 0.5/1 second and won't hinder. This approach removes two ways of adding bookmark and only one standard universal way will be.

So, finally: each bookmark related icon can serve 3 folders, call one bookmark per folder and add one page as bookmark with or without dialogue, i.e. 3 x (2 + 2) = 12 times relatively current bookmark folder.

II. Kingdom Bookmarks Shrink

The right way to shrink the Kindom Bookmarks is to remove 90% of bookmarks (avearge user has from 2 to 5 thousands bookmarks, and uses intensively about 1-2% of them, occasionally - 3-5%, rarely - up to 10%, and the rest of bookmarks were used only once - when bookmarked :). But to convince the user to remove them is almost impossible, only most advanced users can keep a small amoumt of bookmarks and this is a real art. But even average user can remove 90% of his bookmarks if he will able to recover them in "rainy days". Actually he will never recover them, but he must have such ability... Below I'll speak about recovery mechanism and some accompany things.

1. Tagging and merging/sync

• Let assume we have some predefined tag, let call it "Archive"
• Let assume that user will tag some bookmarks with this tag
• Let assume that he'll create json file, containing all bookmarks (with and without tag "Archive") and we call this file "Big" (for instance)
• Let assume he'll be able to delete all bookmarks with "Archive" tag, the empty folders also will be deleted
• Let call this set of Bookmarks "Small"

From this point the user will have a really small set of bookmarks (we assume, that most of his bookmarks he tagged with "Archive") and our purpose is to keep in synch "Big" and "Small". We don't want that adding or deleting any new bookmark will cause the synchronization, so we need to define some rules, when sync is really necessary (autosynch) and when it can be done on user's demand. Evidently, the sync is necessary when user decided to rename "old" folder or move it. By "old" I mean the folders and bookmarks, that are in "Big". The "new" folders don't need immediate sync, but if we don't want to mark folders we can say that any folder renaming/moving should cause immediate sync. Later I will describe more the sync mechanism, but so far we need to take this point into consideration.

Now let assume, that we didn't rename/move any folder in "small", but added a lot of bookmarks, deleted some of them or moved into another folder and now want to recover "big" and merge it with "small". We should also remember, that "big" cantains also "old" "small". So, let speak about rules of merging.

• The moving particular bookmark from one place to another is equal to deleting bookmark in one place and creating it in another one.
• The renaming bookmark is equal do deleting it and creating new one.
• If some bookmark in some folder exists in "new" "small" and doesn't exist in "big" it should be created in "big" in appropriate place.
• If some bookmark without tag "Archive" exists in "big" and doesn't exist in new "small", it should be deleted from "big"
• If some folder exists in "new" "small" and doesn't exist in "big" it should be created in "big" in appropriate place.
• If some folder that doesn't contain any bookmark with tag "Archive" in it or in its subfolders exists in "big" and doesn't exist in new "small", it should be deleted entirely (with all its bookmarks and subfolders) in "big".

Following these merging rules we can merge "big" with "new" "small" and even replace the "small" with "big" in case when user wants to recover "big". The merging without replacement will only update the "big".

Now: what is the folder moving/renaming in "small"?

We can say, that this is the following sequence of actions:

• 1 Merging "big" with "small" (before moving/renaming)
• 2 Replacing "small" by "big"
• 3 Moving/renaming folder in "big"
• 4 Creation new "big" (after moving/renaming)
• 5 Deleting all bookmarks with tag "Archive" and all empty folders - creating "small"

As you can see, the moving/renaming folder isn't a "piece of cake" - it is enough heavy operation. But taking into consideration, that "small" will be really small set of bookmarks, the necessity of folder moving/renaming will be very rare. Moreover, if user definetely knows, that he wants to rename/move new folder, he should be able to do "light rename/move" without all this heavy sequence.

This will give to user ability manage small amount of bookmarks and be able to recover a big one.

2. How to tag bookmark with "Archive" tag?

The question itself seems as fully stupid - what the problem to tag particular bookmark as "Archive"? Of course there is no problem to tag any bookmark with any tag. The problem is - how to decide that this bookmark should be archived. I want to remind, that an average user doesn't remember about what are the 50% of bookmarks, but wants to know.

Currently we can bookmark page with inserting the selected text into Description field of bookmark. The addon Add Bookmark Here - https://addons.mozilla.org/ru/firefox/addon/add-bookmark-here-2 allows to do this.

So, if the user is able by some way briefly to wiew these fields, he can refresh his memory. The question is how to do this.

We can use the slightly changed mechanism of virtual bookmarks for this purpose. The addon "Fast Dial" - https://addons.mozilla.org/ru/firefox/addon/fast-dial-5721/ can represent every folder as a grid with thumbnails. The addon owner showed me how to change the addon, that it'll show the description field text in the grid instead thumbnails. By this way the user can briefly view his bookmarks and refresh his memory regarding every bookmark folder. This will help him to decide what to archive and what - not.

3. Additional things that can shrink the Kingdom Bookmarks

1. Bookmark Duplicate Cleaning

There are few addons that do such cleaning, but they have some disadvantages. For example they recognize url as SomePath and SomePath/ as different urls, and it is wrong.

2. Only one folder as host and the rest - as tags

Sometimes user wants to have some bookmarks in few places and doesn't want to remove such duplicates. Currently it causes redundant bookmarks. My proposal is to have in addition to conventional tags also "folder as tag". Such tags shouldn't be listed as tags, but the bookmarks should appear in appropriate folders. By this way we won't have redundant bookmarks and will be able to have one bookmark in different places. By the way the Bookmark Duplicate Cleaning should also give such possibility when detects duplications. Obviously, the folder as tag shouldn't be considered as duplication.