Hi all,
Here is feedback and suggestions that I originally sent as an email, but was asked to additionally post it here in ye olde suggestion box.
So here it is....
==========================
Suggestions after 5 months of use...

Warning: Longish email ahead, but it contains about 5 months worth of observations and suggestions gained from continuous use of Surfulater, by a Ph.D. student who basically wrote his dissertation using Surfulater.

I'm sure you will have heard some of these suggestions before, but I think what I can offer is a unique perspective on Surfulater, from the point of view of someone who has used it as a note-taker rather than as a bookmark manager.

I'm a ph.d student in the humanities and while Surfulater is supposed to be primarily a bookmark manager, I've actually used Surfulater almost exclusively as a text/snippet manager, because funnily enough, *I could not find a better product than Surfulater for taking notes and organizing them, despite extensively searching for one.* And I found Surfulater to be the best product for that despite some limitations in Surfulater in this regard; limitations that are perhaps understandable since it was designed primarily as a bookmark manager and not as a notetaker, but limitations that are perhaps easily fixable and by addressing them you may be able to expand and extend the target market for Surfulater.

I've basically used Surfulater for its text notes, to basically use it as a substitute for what in the old days researchers/students/academics/journalists used to do on 3"x5" index cards. That is, to collect a very large amount of information (in card-sized snippets), and then organize and arrange that information into what will become the narratives (books, articles, novels, and in my case a dissertation) that they write. After I collected and arranged and organized my snippets using Surfulater, I then ported the snippets to MS Word (with some difficulty - see below), but for the collecting-arranging part of the process, Surfulater was absolutely unique - and - indispensible). I'll try to explain why I think it was so unique, and then go into a short list of suggestions.

For the record, I have sung the praises of this program to all my academic friends, all of whom are in desperate need not only for a competent bookmark manager (which honestly does not exist at the present time) but also in need of the kind of notes manager that I believe Surfulater really is. Why did I find it so useful as a notes manager? Couple of reasons: Unique User Interface, and Unique Snippet-based Database Design.

First of all, the 'article/snippet' organization of the data in Surfulater lends itself intuitively and immediately to the "index card approach" of data collection. On the left side of the screen I had my folders (categories of information in the knowledge tree) and their subfolders; on the right side I had my "index cards"; and with simple drag and drop I could move the cards between the left pane and the right pane and thus organize my incoming snippets of information freely and quickly into their rightful place in the narrative.

The large real estate that the UI provides, helped enormously - the views one gets on one's data are very impressive, not cramped views like you find in Zotero or Treepad or other "3 pane" tree-structured organizers.

The innovation here is that Surfulater managed - somehow, but very effectively - to become a 2 pane system without sacrificing usability. I think this is because on the left pane, you can see a article list of your snippets within the folders; while simultaneously seeing the expanded snippets in the right pane. So that third window that most tree organizers use, was no longer needed. The UI helped make this 2-pane system very usable. For example, the ability to turn the article list in the left pane on/off; or the "linkage" between the two panes (click on an article in the right pane, and the left pane scrolls down to the right folder: perfect). And so on. Many such small details in the interface allowed a 2-pane system to work as well as a 3-pane one, while giving back much needed screen 'real estate' to be able to view and work with much greater amounts of data in a single view on-screen.
Thus, on a 19" LCD monitor set at a high resolution, I can view and quickly work with an enormous amount of 'index card information' in front of me, and organize them quickly, almost as intuitively as manual index cards laid out on a bed or on a very large table.

In addition, other features helped enormously as well in terms of efficiency of the collecting/organizing process: Ability to cross-link the snippets; Ability to "clone" snippets across multiple folders. These are again absolutely essential features one does not normally find in your average 3-pane knowledge tree organizer.

The real strength of Surfulater is, of course, that it offers ALL these features in one single software package. Some of your competitors (like Evernote) offer SOME of these features, but not all of them. No one out there offers this full package of efficient features like Surfulater does.

And on top of all this, Surfulater also offers ability to mark up index cards, highlight things, add comments, and so on; again features that taken together help with the usability of the program for note-taking and arranging. Perfect.

Or nearly perfect. *Tagging is desperately, desperately, desperately needed.*
Desperately. It would be a deal-sealer if you had tagging. For many of my academic friends who liked the product, it was the lack of tagging alone that made them hesitate to buy it. Its one of those features that - in an age of de.licio.us and simpy and yahoo bookmarks, everyone simply expects to have now.

Again, some of your competitors offer tagging - but then they don't offer other crucial features. With tagging, Surfulater would have as complete a feature set as I can think of.

Or nearly complete. Also desperately needed is the ability to start typing immediately when the user inserts a free form note. At the present time, the user has to laboriously click on the note in a special way (or on the edit icon) before they can start typing. Can you believe that that's what I did - laboriously - for nearly 2 thousand text entries?! (I initially came across Surfulater mentioned in a review at donationcoder.com; If you recall, in the review of Surfulater at that website, the reviewer had similarly found this to be one of the big problems in an otherwise highly flexible product, this inability to just start typing when a note template was inserted). When I right click and say 'add new note', I should be able to type immediately! That would eliminate one curious and somewhat disruptive flaw in an otherwise highly efficient program.

Or almost highly efficient. The user should have a keyboard shortcut to insert a note article! Can you believe I right-clicked 2 thousand times to get a note template each time?!* User assignable keyboard shortcuts for inserting each of the different article templates -- are desperately needed. Imagine the efficiency a power-user of this product could enjoy if those were available.

---------------------------
Also desperately needed, in this otherwise unique, efficient, and amazing product:

-A "shortcut toolbar", that would sit along the top of the program along with the other toolbars, where the user can place quick shortcuts to their most commonly used folders or articles in the knowledgebase. In a huge knowledgebase such as the one I work with, its an incredible pain to always hunt through all those folders to find the 10 or so most common ones that I used. Changing the icon on the folders helped slightly to locate them, but a bookmark/shortcut toolbar (exactly like the links toolbar in IE7) would have been incredibly, incredibly, incredibly helpful.

-"TXT or RTF format export": To be able to export a folder (or subfolder or node) as TXT or RTF format. Right now, its only by additional cutting/pasting, or excruciating data scraping, that I can get my snippets into MS Word. Exporting to HTML format has its limitations; people also interface Surfulater with Word processors, and for that an export to TXT (or better, RTF) would be very, very helpful and eliminate intermediate steps that require additional cutting and pasting from html into text files. (It would be hyper-helpful if you could export not just in txt/rtf, but in doc format with the folder/subfolder heirarchy translated into Word style "headings"; but I would happily settle just for TXT for now; because even just that would be *immensely* helpful).

-ability to export to IE7 Favorites/abilty to synch with ie7 favorites.
Netvisualize offers this ability (it even allows you to synch with ie7 favorites folder) (but then it doesn't do cached local copies of the urls it bookmarks, so it has other limitations). The reason for wanting the ability to export/synch back into ie7 favorites, is simple: What if you are bought out or go under or whatever? You will leave a LOT of people who invested their time and data with no failsafe way back into IE7's favorites. Will the html export preserve the heirarchy of the bookmarks? Will it preserve cached copies? Or ratings? Synching with IE7 Favorites folder may atleast ensure that Surfulater's knowledgebase can be translated back into a windows explorer file structure readable by IE7. That would be ideal, and give LOTS of peace of mind to people considering "the great move" to Surfulater. I know Surfulater has an open data structure with XML, but few of its users would have the skills to do something with that; would be excellent to build it in. It also would allow people to access their bookmarks directly from within IE7.

------------------------------

For the pie-in-the-sky wishlist: (ie, not immediately needed, but would be great to have):

-saved search folders. Ability to conduct a search, then save that search results folder as a saved search folder that auto-updates itself whenever it is accessed. Along with this, a more fully featured search ability may be in order (for instance, does the search bar currently process quotes and parenthesis? Also, how about an option to "search in folder titles only", for quickly locating a folder?). Saved search folders would be great, would fill a number of different needs that people have in using all the info they are collecting. This could be implemented in conjunction with the tags feature, since people could then search on their tags and save those searches.

-"filter by article-type": Ability to filter the knowledge tree view (in the left pane) to show only certain types of articles and hide the others.
Among the useful filters you provide, you don't provide the ability to "show only note articles" or "show only code snippet articles" or "show only todo list entries" or "show only music catalogue" and so on, in the knowledge tree. Wouldn't that be a useful filter on a massive knowledge base? At the moment you only allow the option to show/hide articles as such, but not show/hide specific types of articles.

-"saved views" - ability to save the filters/views in the knowledge tree (left pane) to a button on the views toolbar . Why not allow people to set up their own views on the knowledge tree, and save that view as a button on the 'views' toolbar immediately above the knowledge tree? there is some extra room there. SO the user could filter the tree as they like (show this and that, don't show this and that, show these types of articles but not those; close these nodes, etc) and then save that view to the views toolbar. Then with a single click they can get that particular view back.

-"knowledge base statistics" : Should have a menu option that provides basic statistics on the knowledgebase, such as a) word count b) character count, c) number of articles, d) number of folders.

-------------------------

In closing, I AM also considering using Surfulater as a regular bookmark manager. (I currently use spurl.com for that purpose; Spurl offers both tags and folders as well as cached copies, and for a long time was unique among online bookmark managers in offering all three features. (And incredibly, there is not yet any desktop bookmark manager that offers all three of these very basic functions.) However, spurl.com (like so many other bookmark manager companies) seems to be going out of business and so I'm looking for a solid desktop version that offers similar features, and have not found one yet. I really hope Surfulater will be that one (as soon as you offer tagging, it will be!). You'll also be the only one. And I can assure you, in the academic world, there is an enormous pent-up need for such a bookmark manager that offers all three features (tags, folders, cached local copies). Everyone is storing their bookmarks in incredibly sloppy and haphazard ways right now; we don't have a choice because there is no program out there that lets us do all three things. We're desperate for such a program. All writers, everyone who works with information and who write, are desperate for such a program. I talk to these people every day. (I also happen to work in tech support on campus).

I hope the above information helps! I hope it helps give you an idea of how your product is being used and how you might be able to tweak it to attract and acquire new users and new demographics.

It's a credit to your basic design and to your skills that Surfulater is such a flexible program to begin with. None of the information managers/bookmark managers out there have efficiently implemented both of these functions - the collecting AND the organizing of information, together in one piece of software. (For example, look at Evernote. It does an excellent job of collecting information in a strip (or "scroll"), but as a program for organizing and arranging large amounts of information into a sequence, it falls well short: it doesn't use the screen real estate efficiently for that. Or consider Microsoft's Onenote - its excellent as a 'notebook' metaphor, but lousy if you want to stitch together a few hundred snippets of information into a narrative. Surfulater fills that need perfectly with its 2-panes and drag-and-drop.)

I've looked at virtually every information manager on the market today, and I can honestly say that Surfulater has come the closest so far to filling that vital need that all writers have, to make that transition between collecting information and organizing information. Surfulater has come through for me in that regard, and I thank you. : )

=================

Hi Jai,
Thanks again for your comprehensive 5 month in, review of Surfulater and for your suggestions. And thanks for posting the e-mail here for everyone to see, as I requested. I'll touch briefly on as many of your comments as time permits.

First I don't think of Surfulater as a Bookmark manager, but as a Web and other content Clipper, plus a general purpose note taker and personal information manager. That said folks are using it for tasks I'd never considered, which I touched on, on my recent blog post. Also its use as a note taker is a ways beyond what I'd envisaged.

Being able to see the content for all articles in a Folder is crucial for many SUL users and is core to SUL's design. Equally important is the ability to view the Knowledge Tree in various ways, store the same article in as many folders as you want and cross-link articles to build a web of related information. There is little point gathering lots of information without the tools to manage, organize and find it again.

Tagging is way up near the top of the todo list, I'm pleased to say. I've been reading up on various tagging systems and toying around with a few and am close to locking down the initial design.

Immediate editing has indeed been discussed. Surfulater treats each field as an individually editable item, which may, in hindsight, not have been the best design. One item I have on the todo list is to enable Tab and Shift+Tab to edit the next/previous field when the current field is in edit mode. This in conjunction with an option to commence editing the first field in a new article may well meet your need?

Keyboard shortcuts for new Articles for the various templates is planned.

The ability to Bookmark articles and folders is planned. I'm not sure of the UI to access the bookmarks yet. Most likely a drop down list like the History toolbar button. I'm also thinking of including these Bookmarks/Favorites as a Folder in the Tree.

Export. Can you be more specific about what you want here. For a Note which just has one field do you want that written to a file or its contents copied to the Clipboard. For other article templates with multiple fields what would you want. How would the individual fields be handled. FYI MS Word has Edit|Paste Special.. which can paste plain text from SUL.

IE7 Import. I don't see how this is useful in moving SUL content to another application. IE Favorites and Firefox Bookmarks only hold a Title and URL so none of the content from SUL, other than this would come across. As you point out SUL stores its main content as XML. Other Export capabilities are planned such as exporting all images and attached content along with a flattened XML Tree + Content. Unfortunately it can be difficult to migrate data in applications like SUL to other applications automatically as the differ considerably in their data, its organization and storage. At least with SUL the data is available in the form of standard plain text XML.

Saved Search Folders. I plan to enable Copy & Paste to be used with the Search Results Folder. You can select all articles in the SR Folder and use copy/paste now. Can you explain more about "auto-updates itself"? Would this be like a live search which when you selected the folder a fresh search would be done using the original search text? See the Help Topic: The Basics|Searching for info on search operators. More advanced search capabilities are planned.

Filtered Tree Views are planned. Saved Tree Views will likely be part of this.

KB Stats. Added to the todo list.


I have to say that getting detailed, well thought through and well written feedback like this, is truly invaluable. All the more so because you have been heavily using Surfulater for some time now. Most of the time we hear from folks when they are just starting to use Surfulater and they aren't yet aware of all of its capabilities. Once they get up to speed they happily chug along quietly in the background and we tend not to hear from them.

Surfulater is steadily evolving and feedback tells me we are doing a good job of heading where our users want. Of course everyone would like to have everything on our todo list ready tomorrow or the day after, but this simply isn't possible. So we keep weighing up the requests and juggling priorities and move forward to the best of our abilities. All the while staying true to our design goals of simplicity and ease of use while still delivering capabilities power users want is all important.

__________________
Neville Franks,
Author of ED for Windows and Surfulater

I am not Jai, but this sounds very close to the way I would like Surfulater to handle editing of entries.

Specifically, I'd like the entire item (all fields) of an item to be editable or locked as a whole - in other words there would be a since 'edit' icon for all fields of the KB entry as a group instead of one for each field (this sounds like something similar to what you propose above). The difference that I’d like to see is that that mode would be a persistent toggle that was remembered for each KB article - even across open/close of the KB.

Ie., I have KB articles that I edit on an on-going basis, and having to do the special double-click or zero in on the edit icon for each time I want to update the article is a bit of a nuisance. Clearly, for new, blank articles this state should be initially in the editable mode. For articles created from clippings or clipboard I’d personally be OK with either mode being the initial state.

@Neville:

Thanks for following up on this conversation! You're absolutely right that not all features can/must go in. My general feeling is that, so long as SUL is a research tool, certain 'features' can be shared across its 'research' uses (whether it is used as notetaker, bookmarker, snippet collecter, image collector, or whatever, there are some basic functions that all of the above types of collect-and-organize work would share.) Among such shared functions, SUL already has implemented many of them, such as cloning/linking and multiple views on the collection and so forth. Other functions are already on the todo list for SUL, it looks like. And still other common functions might yet come to light, through this great process of conversation that you're so willing to engage in!

Regarding your post above, some quick responses below:


Re: SUL as a Notetaker:
Indeed in truth notetaking would just be one component of a 'general purpose' research tool (which I'm glad to hear you see SUL as being). I just happened to use that one feature extensively, but I too see sul as a more general purpose research tool. Notetaking is, i think, certainly an important component of such a tool, though one component among many.

Re: immediate editing of text notes:
your suggestion of a)cursor being in first field, b) tab/shift-tab to move between fields -- would be a great improvement over the existing method, I think. I could certainly live with that for a long time. Please move that near top of wishlist!

Re: Bookmarks for articles and folders:
You mentioned possiblity of a bookmark list WITHIN the knowledge tree -- but I'd suggest that having access to such a list OUTSIDE OF the knowledge tree may be important. The reason is because when one is working with folders/articles in the knowledge tree, one may not like to "lose one's place" in the tree, in order to scroll away from what they have on the screen, just to be able to click the next bookmark.
For example, a UI where the bookmarks are along the top as a toolbar (just like, exactly like, the links toolbar in internet explorer which can be made visible or turned off, complete with the back/forward buttons (which SUL already has)), would allow one to switch between knowledge tree views without scrolling/hunting in the knowledge tree. Such a toolbar would be outside the knowledge tree. It would have everything on it quite logically, I think, from a user's point of view, and in the familiar UI that people are already used to in ie7 and firefox: favorite shortcuts buttons, back/forward buttons, and even the 'trail' of 'recent articles' that you can see in sul (again, just like in IE) when you pulldown the arrows next to the back/forward buttons.

Re: Export to TXT/RTF
What i'm thinking of is an ability similar to the html export you have now, except it would be an export to a TXT (or, RTF) file.
In such a scenario, the articles within the selected folders would simply be converted to text, nothing more, with the fields being piped out sequentially in the order they currently are being viewed in, in SUL.
Each field of each entry would simply appear sequentially in the current order in which they appear within SUL.
Why is this useful? The reason for this is simply to be able to thus open such a file in WORD with one's SUL articles appearing there in more or less the correct sequence that one wanted to see them in. This would allow one to, for example, export (from SUL) selected folders/articles into a text narrative that one could then "continue working on within MS Word."
After all, after one has collected and organized all that data in SUL, one wants to wind up in MS word eventually in order to polish it and email it to one's publisher or to an academic journal or whatever, to be printed and distributed in usual traditional ways.


Re: Import of bookmarks back into IE7:
This one - i guess i wouldnt consider it a priority for the moment -- but at some point before you retire, i think it should be thought about, because the rest of us will still be using SUL and we may need something like this when you're not around anymore!
I do have to think about this some more, because as you say, what would happen to all the other 'fields' if one imports just the url back into IE7? Well, all the other types of info -- code snippets, text, images, etc - would not necessarily go back into ie7, of course. Instead, one way I thought this data might be saved, is with a two folder "parallel folder" approach, one containing the url info that ie7 can import directly, and the other containing related info such as tags, cached copies, ratings, etc. The bookmark folder (the first folder) might perhaps contain a file pointer to this additional data which is in the second folder (and which would, when clicked, open in separate windows or programs).
Just brainstorming; I need to think about this some more. Basically I guess I'm suggesting that SUL, in this way, would in effect make up for what is really a deficiency in ie7 itself: the fact that ie7 cant save (a) cached copies (b)ratings (c)tags and etc, for the urls that it saves to its favorites folder. And the idea being that atleast the bookmarks would thus get back into IE7 (a standard browser, that is), in the event that SUL is bought out or you retire! ;D Its ultimately a data-security issue, and so I do think at some point it would need to be thought about by someone, somewhere; and it may as well be by you!


Re: "saved search folders"
By 'auto updates itself' (bad langauge/description on my part, sorry!) I do mean a 'live search' when accessed. Basically this would be what zotero does, (zotero offers live search, that is, folders that contain the results of a search request and can be saved "as a folder within the folder tree", in effect, being a "live saved search" but at the same time being an integral part of the knowledge-tree, treated like any other folder, can be moved around and "placed" anywhere in the tree just like any other folder). I believe Microsoft Vista also was supposed to offer this feature, I believe it was in the beta but I dont know if they implemented it in the final version. It was supposed to be a feature where, when you used the search function in windows explorer, you could save that search as a 'live search folder', and refer back to it simply by double clicking the folder and seeing its (live) contents, which are the search results that run when the folder is double clicked. And you could place that folder whereever you wanted in windows explorer.

The reason this is a good idea, I think, relates back to the next question on implementing tagging. Because I've always thought that, at a very basic level, live search folders/tagging/knowledge-trees were all closely related UI elements. The firefox plug-in called "Scrapbook" actually implements tags and folders together: In scrapbook, as I understand it, the folders in its folder tree, ARE MERELY LIVE SEARCHES ON TAGS (the folder name simply being a special kind of tag that is applied to any content that is dragged/placed into that folder).

So you see, could it be that tagging/folders/'live search folders' are all implementable with the same core code base? Any article in the knowledge base can get tags -- If you create a folder in the tree and place the article in that folder, the folder name is merely a special tag for that article, gets attached to it "automatically"; and thus the "folder contents" are merely the 'live search results' on searching for that tag.

You see what I mean?

It might get a little more complicated, but at a basic level, "live search folders" and "tags" and "knowledge trees" (ie, a folder system) thus could be seen to be fundamentally related in terms of the code they share, if they are implemented in this way, together.
And if it works, then you get all three functions "for free" (or rather, for the price of one).

Atleast, thats something to think about, I think.
Scrapbook, I believe, already implements the relationship between folders and tags by making folders merely a live search on a special folder-name tag. As one review put it: SCrapbook's folders are "Based on 'Tags hierarchy', Not like normal tags-supported application, the tags are organize into a 'Tree', to make navigation more fast and exact".

I'd argue that by implementing tags-&-folders in this way, scrapbook also got the 'live search folder' feature "for free," tho it did not provide the UI element to call that feature, did not implement it. But the basic functionality is "already there."

Anyway, I'm not a programmer (though I dabble a bit , but it seems to me that conceptually this makes sense and if it works, may significantly simplify the code required to get all three features: tags, folders, and live search folders.

Hi Michael,
Having all fields in an article editable at once is a fairly major change in design and coding. My idea with Tab/Back Tab is that each field would toggle in and out of edit as you moved through it. This fits into the current design and comes quite close to having all fields editable at once.

Note that I'm not opposed to having an option to have all fields editable and may add this in a future release.

__________________
Neville Franks,
Author of ED for Windows and Surfulater

Hi Jai,
Thanks for the follow up post and extra info which I've taken on board.

A quick note on Bookmarks. I said earlier: "Most likely a drop down list like the History toolbar button.". So there will definitely be toolbar access with a drop down list of Bookmarks. In addition there may be a folder in the tree containing bookmarks. This would make it easy to delete and reorder bookmarks. Prime access would be via. a Toolbar though.

__________________
Neville Franks,
Author of ED for Windows and Surfulater

Hi Michael,
Surfulater V2.20.0.0 is out and gets a big step closer to what you'd like. See: Surfulater V2.20.0.0 Released Comments on the blog would be good. And/or here.

__________________
Neville Franks,
Author of ED for Windows and Surfulater

Hi Jai,
Surfulater V2.20.0.0 is out and covers a number of the issues you raised. See: Surfulater V2.20.0.0 Released for more information. I hope it gels well with your workflow. Comments on the blog would be good. And/or here.

__________________
Neville Franks,
Author of ED for Windows and Surfulater

Hi Nev, downloaded it, it looks great -- the new edit UI is like a glass of cool water on a hot day Many thanks for that! You've materially improved the quality of my daily life
One quick question -- while playing with the UI, I was wondering if there was any particular reason why you didnt choose "double click" to be the way to edit a field (rather than slow click).
(I know this question is not as relevant as it might have been before, since now you've also provided hotkeys and other enhancements to edit field text). But it just seemed to me that in comparison to the infamous slow click, double-click-to-edit seemed intuitive (and if there's no reason why it couldnt be there, perhaps you could consider including that in a future version as well to round out the edit-field enhancements). Thanks!! I think a double click to edit might be another small enhancement (replacing slow click altogether perhaps).

Hi Jai,
Good to hear you like the changes in this release.

The standard for double click is to select the current word, so this behaviour would be different in SUL if it were used to commence editing. You aren't the first to suggest this though.

__________________
Neville Franks,
Author of ED for Windows and Surfulater