Merge Tabs & Bookmarks Into One
I hope this signals the merging of these two concepts. Really, for me, bookmarks are a place where websites go to die and I use tabs like i would imagine bookmarks were intended for: keeping track of ideas i want to keep as a reminder. Tree Style Tabs allows me to organize those ideas in ways that would be too time consuming to replicate with bookmarks.
Watching that demo made me realize that the two concepts should be merged into one. The TabCandy concept seems to be a great way of accomplishing this.
The only suggestion I have is to move older tab groups out of memory, either after a set time, set usage of memory, manually, or better yet: all the above.
Jason Boyd commented
My immediate thought upon seeing tab candy was 'I hope they integrate this with bookmarks'. The two are doing almost the same thing after all. Bookmarks organize sites thematically (I believe most users would say they organize their bookmarks this way) while the tab candy is about organizing sites based on a task or workflow. Plus, even though some people may not prefer it I would love to be able to organize my bookmarks spatially.
After some deliberation, though, I realized that it just isn't necessary to merge the two, at least not completely. When meta-grouping and saving are inevitably implemented the tab candy end user can take it upon themselves to create top level meta-groups 'bookmarks' and 'workflow' and essentially achieve integration of bookmarks within tab candy without foisting the integration on users who don’t desire that behavior.
There are, however, some ideas for loosely coupling bookmarks and tab candy that I would like to see implemented. First would be a way to import bookmarks into tab candy on demand. This would import them in such a way that each bookmark folder would be a meta-group. Also, I would like an option to continually sync my bookmarks with a meta-group in tab candy. I believe these options would satisfy the people who want the two merged and those people who prefer to keep them separate.
That wouldn't work for me.
My bookmarks are for references, more long-term.
(Although I would be open to seeing ideas for alternate presentation of bookmarks, as accessing them can be awkward sometimes. But logically, they serve a separate purpose.)
Tabs, and proposed tab groups, if savable, would be good for me for short and medium term, but not long-term references.
So please keep them separate.
By the way, tabs can already be saved as bookmarks, and bookmark groups. And a tab can be saved into an existing bookmark group as well. I use those features from time to time.
I think that this idea (and TabCandy) are going in completely the wrong direction -- having hidden pages and confusing open/non-open page states is exactly what is WRONG with TabCandy. Merging these two completely different concepts of a page that is open (tabs) and a page that you might want to come back to in the future (bookmarks) even further just causes the confusion to get even worse, and the work-flow to get even messier than it already is.
A better solution would be to completely separate open and non-open pages (as logicaly done in FF3 and all other web-browsers), and introduce a separate view for your bookmarks ("bookmarks panorama") which would show the same TabCandy-like spatial desktop-like view for bookmarks. I have described how this would work in more detail here:
Ethan Sisson commented
I completely understand your concept, Emrys. Like anon said, it would be a much more organic way of understanding, organizing, and consuming web content, but I think it is a great shift in thinking. I would be all on board, and honestly that is probably how I will use Tab Candy as it gains more features like nested sets (in conjunction with BarTab to retire old tabs out of memory and onto the disk).
In the end, though, I do believe there is still a place for "Bookmarks." When I finally do happen to close a page, but I still find it important enough that I may want to refer back to it at some point in the future, I need a way to mark it so that it doesn't expire from my History and so Firefox knows it is important to me. This is what Bookmarking currently does, but I would rather call it "Starring" or "Flagging," or something to that effect. I suppose it all depends on how each individual uses the features though.
In the end I have to disagree with completely merging them. I believe no matter how organic the process of managing pages we visit becomes, there will always be considerable value in being able to "bookmark" a page in some way.
You post a great list of the biggest differences between tabs & bookmarks currently. And, I think TabCandy already nullifies most of those differences. For example:
>Bookmarks have user content fields.
=TabCandy allows you to name a tab group, it would be simple to extend that functionality.
>Bookmarks are not necessarily a singular content document, eg LiveMarks.
=This would actually be an interesting application of TabCandy: you open your LiveTab group and it autopopulates with the latest items.
>Bookmarks can be organized into further abstractions, such as folders.
=That is exactly what makes TabCandy so powerful, its spatial "folders".
I agree that the "Tab" metaphor doesn't hold up when used spatially (as tab refers to the shape of the user interface element). "Bookmark" makes much more sense to describe the kind of semi-persistent organizational behavior of Tab Candy.
It is a good idea, but as I have outlined above, TabCandy addresses most of your issues; I think the future is here.
Ultimately both are an abstraction of the same thing -- a content document; however, the context of that abstraction, the interfaces for each, and the unique properties thereof render the abstractions considerably different despite abstracting the exact same thing.
Bookmarks are unopened pointers to content, and need not correspond to a specific tab instance. Bookmarks are tagable. Bookmarks have user content fields. Bookmarks are not necessarily a singular content document, eg LiveMarks. Bookmarks can be organized into further abstractions, such as folders. Bookmarks can be opened in a tab instance. Bookmark content cannot be searched. Bookmarks still exist even if the source tab (if there was one) has been closed. Etc...
Tabs contain an instance of the content document. Tabs can be organized relative to other currently open tabs. Tabs can be bookmarked. Tab content can be searched. Etc.
The challenge would be to balance the persistence of bookmarks with the temporality of tabs in a clean sensible UI. For this to work, the tab and bookmark metaphors would likely have to be superseded by a "more organic" implementation encompassing both concepts.
Good idea, but seems distant future.