Currently, the functionality requires that I be on a blank (or unused) page, then select the RSS feed item I want to read. Ideally, I could run through the dropdown list, selecting several stories to read in sequence that would already then be open.

Hope that makes sense.

I don’t like tabs too much. Normally I have tens of them open, some are less used, some have dynamic content that I want to periodically revisit, some I don;t want to lose and when I lose them (too many bookmarks anyways), I don;t care much until I need them again a few months further.

With the flood of content, tabs don’t seem to me the right way to access it neither logically, since they have absolutely no logic associated to them, nor physically, because, well, I don’t really know to define that yet and don;t want to think about further.
Following the example of “micro-blogging”, one may refer to tabs as “micro-web”/”micro net”, or “micro-search”, reflecting the status of one’s content interests. If that’s true, then why not handle it as such?
(I wonder - do I have 140 open tabs?)

I believe the solution should handle both levels. To handle the logical associated to it as well as the visual access.

Perhaps I can refer to what I want from tabs as a simple change. Make them “tags” instead.

For example, this “micro-web” may refer to the keywords and tags, or even the whole text, inside the pages and/or the link names. Another way to “logicisize” them is to allow the user to add keywords, tags or even links between them. Then access this user-entered meta-data. Another way is to create logical trains according to the “threads” of which tag opened which tag (and back-tracing of course). Timestamps of when the link was opened may also be helpful. There are probably many other logic criteria/rules that may be applied to content, tags included. So support them all, let the user decide.

On the visual side, there are also several alternatives. For example the old nested file system/folders/threads representation. Another is a color/icon map of the logical criteria/categories (such as red for all tags marked under “human interface”). Another may be some graphical display such as perhaps bubbles or graph-bars etc. Yet another may be “desk roller” kind of display, or several of them, indexing the tags according to the various logics associated to them. All such graphical designs may enjoy graphical attributes to rely information, such as bubble size or color “strength” to reflect number of links under that category, color hue to reflect association between different categories. Best is to support all - like “skins”.
Separating the logics from the physical has another advantage that developing “logic engines” on one hand, with standard APIs to all of them, and developing “physical skins” on the other, can be done independently and continuously by the community at large, each one working on what he likes more.

These are my of-the-sleeve thoughts. I apologize if I repeated prior thoughts here or elsewhere which I have neglected to read. I’m not a follower of open source development etc.

Thanks for reading,
Baruch

Instead of only looking at the clipboard, why not look at all selected text? If I select text (mouse), then copy it (keyboard), then make a new tab (kbd or mouse), I have to switch between keyboard and mouse. If I select text, then click the new tab button, I avoid the keyboard.

Searching for text and mapping it should be on separate lines. As it is, the “map” button is beyond the reach of my non-maximized window. I suggest something like:

[G | Search] 123 Main St. Anytown, CA 12345
[Map] 123 Main St. Anytown, CA 12345

Where the G part of the Search button is a pulldown menu where you select your search provider (populated by search plugins).