Softvoile support forum

Tyushkov:

I've been using Clipdiary for some time now and I'm quite enjoying the new version. With the advent of the newer version it has crossed the line over to the point where I'm willing to actually pay for its functionality. I'll be buying the application as soon as I get around to it, probably right before the trial version expires knowing me.

Prior to making the decision to buy Clipdiary, I went looking for some competitors to see if there is something that worked better as far as I was concerned. I found something called "Clipstory" at http://www.iconico.com.

At first blush, Clipstory it seemed to be quite a bit more powerful then Clipdiary. In fact, based upon the descriptions, I had almost made the decision to buy it rather than Clipdiary.

But upon USING Clipstory, I found it to be less "efficient" in actual day-to-day use than Clipdiary by a long shot. To be honest, it does significantly MORE things than Clipdiary does, but unfortunately (for Clipstory) it does them in a very clunky and uncomfortable way. The extra features are really great, but it's not so great if those extra features get in your way every time you go to use the utility.

For example, the simple act of taking something from the clipping database and pasting it into the application at hand in Clipdiary (which, after all, is MOSTLY what you want to use the application for, for pity's sake) is about as efficient as you get. In Clipstory, it's always a few more keystrokes and seems to work in a less reliable way (it didn't always seem to work consistently and I sometimes had to try it more than once to get a paste operation to work).

Finding things in Clipdiary used to be rather clumsy and unpleasant (because the data was spread out across multiple "pages", and you had to eyeball dense text looking for what you were after). Now, it's a real pleasure. In Clipstory, however, rather than neatly removing all of the irrelevant listings in the result set, like Clipdiary smartly does, it simply highlights the answers matching your search criteria and so you STILL have to go paging through everything to find what your looking for. Bleah. I MUCH prefer Clipdiary.

In short, in actual day-to-day application, Clipdiary just works a whole bunch better in the way you actually use it. However, and this is critically important, Clipdiary could really benefit from adding some of the features that Clipstory has (it really NEEDS to do this), but it must carefully do so so that it doesn't compromise its usage efficiency. As it stands, a person deciding whether to buy Clipdiary or Clipstory, never having used either application, and maybe not taking the time to suss out the fine nuances, would almost certainly pick Clipstory over Clipdiary, due to Clipstory's greater PERCEIVED functionality, which is kind of a tragedy because Clipdiary works so much better in day-to-day use.

1. Clipdiary's "preview" (the information it shows you in yellow off to the side) is, at best, pathetic. Clipstory's ability to preview graphics and other items was almost enough, by itself, to pull me away from Clipdiary. I copy and paste a lot of graphics, and having to do it completely blind is appalling. Clipdiary needs to find a way to give a preview for absolutely every datatype it's reasonable to do. In my opinion, only being able to preview text, effectively, borders on criminality.

2. Clipstory has the ability to backup and restore the information in the clipping database. I've commented about this in the past and it's a pretty good idea from a disaster recovery standpoint.

3. Clipstory has a notion of something called "listeners". On a datatype by datatype basis, it "listens" to the items that you're clipping and, based on their datatype (text or graphic or audio or a file, etc.) it automatically outputs this clipping (as you copy it) to a specific place out on your filesystem. If you tend to go about copying a whole bunch of stuff all at once and want it collected to a specific place, this is a pretty killer feature. It also has a management page to establish and maintain these listeners.

4. As I've mentioned before, Clipdiary's search feature is absolutely killer. Simple, fast, straightforward and dropdead efficient. But it's inconvenient to have to use the MOUSE to go down to the single line edit to type in a search criteria and then have to use the mouse again to go up and pick the item you want in the result set. Personally, I have set control F11 to be the keystroke sequence that pops up Clipdiary. I would LIKE control F12 to pop up Clipdiary AND automatically place me in the single line edit search box. After I type something in the search box and hit return, the focus should automatically jump to the first item in the result set and set the focus there. I'd like to set control F10 to clear the search box and return the unfiltered collection to the main list box. If the result set that I got wasn't what I was looking for, hitting control F12 when I'm already in Clipdiary would put me back in the search box so I can correct my search criteria. In other words, there needs to be a lot more hotkeys in Clipdiary because Clipdiary now does more stuff. This sort of thing would make flashing in and out of Clipdiary, with its new feature set, as efficient as it has been up until now.

All the best.

Hi, Thank you for taking the time to write your opinion!




Thanks, I pay lots of attention to the usability of work and try to keep Clipdiary as easy-to-use as possible. About functionality, it is only first commercial version, we are in the start of a long way now . I am going to add a lot of useful features in Clipdiary in next releases.



Why don't you like an idea of spliting clips by pages? Theoretically, there is possibility to show all clips at one page, but this requires much more memory and I think is not nesessary 99% of time. Now Clipdiary shows 50 clips per page, this will be configurable in future.



Yes, you are right. It will be improved surely, but this requires time Probably in 2.4-2.5 version.




You can easy copy Clipdiary database, or switch to other database in Clipdiary options...
Extended database management will be added some time:)


I am not sure that I understand what is it and how it works. Do you really need such feature?:-)
I am going to add export selected data from Clipdiary, but exporting in real time seems to be very slow ... and why you need this feature?


No! No mouse, You can work with Clipdiary without mouse!
Tab - to jump from the clip list to the seach field. (or Ctrl+F to jump to it from any control)
Shift+Tab - to return back, from the seach field to the clip list.


I think that one more system-wide hot-key is not a good idea, it's a big spilth for such feature. Use F11, Tab.


These are really good ideas I'll realize them.


Thanks again:)

Tyushkov:

"Why don't you like an idea of spliting clips by pages? Theoretically, there is possibility to show all clips at one page, but this requires much more memory and I think is not nesessary 99% of time. Now Clipdiary shows 50 clips per page, this will be configurable in future."

Speaking as a programmer of some 25 years, I'm not exactly sure why it is that it would require "much more memory". Back in the days of 16-bit programming under Windows, with limited device context and devoted control memory and all that sort of stuff it might have been an issue. 3000 entries in a list box would not seem to consume that much memory in a 32-bit operating system (or dare I say 64-bit). You may be managing some sort of complex memory structure BEHIND the list box holding the actual contents of the clip items (the actual text or graphics or whatever it is the single-line entries in the list box REPRESENT) and maybe THAT consumes a lot of memory; I don't know.

To my way of thinking, the odd pagination adds a kind of "quirkiness" to the application that's unexpected. It LOOKS like some programming consideration bubbled its way up into the user interface rather than actually being some part of the user interface that was put there deliberately and specifically for the users benefit. It's like I'm using a device that has some of its wiring sticking out. I can think of no user interface reason why the collection of items in the clipboard database OUGHT to be broken up into 50 element chunks. So it feels as if the programmer did it for his own convenience rather than to make the user interface better, which it doesn't seem to do. It certainly doesn't seem to ADD any utility to the application. This makes it sort of stand out in a peculiar way.

However, at this point it's not really that important a concern to me. Frankly, I did find it to be a tremendous irritation prior to your nifty search facility, but at the present time it's much less of an issue. If there is some value to it other than making the programmer's life more convenient, I have no strenuous objection.

"Yes, you are right. It will be improved surely, but this requires time Probably in 2.4-2.5 version."

For me personally, I cannot stress this feature enough. If I could only have one thing, this would be it. Sorry about that.

"I am not sure that I understand what is it and how it works. Do you really need such feature?:-)
I am going to add export selected data from Clipdiary, but exporting in real time seems to be very slow ... and why you need this feature?"

I think my discussion of Clipstory did more to confuse this issue than anything else. Perhaps I should talk more about the WHY of this feature rather than the WHAT and HOW. I think I might best illustrate the usefulness of this with a use-case example.

Suppose my wife writes a weekly blog about nature subjects. This week her blog entry is going to be about springtime butterflies. So she asks me to spend a few hours searching the Internet for interesting and useful web links about butterflies, which I do. As I find each useful link, I simply select it in the URL address line of the browser and hit ctrl C. In the background, I know they are slowly collecting in Clipdiary. After a few hours, I've collected some 30 URLs, and now I would like to paste them into an e-mail to my wife for her to use. It is at this point that Clipdiary ceases to be really helpful and instead begins to get in the way. I now have to go back and forth tediously, 30 times, one-at-a-time, to put these 30 URL entries in my e-mail to my wife. What I WANT to do is simply select all 30 entries and hit one paste operation and POP! have them all magically appear nicely in my e-mail.

As Clipdiary functions at the present time, Clipdiary is really providing NO help in the above scenario. It would be better for me to open up a notepad and the browser side by side and simply copy/paste the URLs one at a time as I go along into the notepad. One could go so far as to say that Clipdiary is actually getting in the way because I have to go back after the fact and REMOVE the entries from Clipdiary.

I believe it is to address this sort of problem that Clipstory created their "listener" functionality. One needs to stand back a few paces and look at this overall issue from a much longer, wider view. There are essentially two fundamental issues at play here:

1. The world has always copy/pasted things one-item-at-a-time. Because of this our thinking is artificially confined to automatically continue thinking about it in these terms. As my butterfly link example up above shows, we SHOULD now have other options available to us because of the nice utility inherent in Clipdiary. Something like copy copy copy copy copy copy copy copy/one-big-paste.

2. When confronted with the prospect of multiple copy operations fused together as a single paste operation, logistical problems suddenly rear their ugly head. Primarily, the problem is that there are lots of different copy "types". Text, HTML, sound, graphics, and etc. Results might be "unpredictable" if one attempted to select multiple different "types" of items in the clipboard database and paste them with a single paste operation.

It's my belief that this is the thinking behind Clipstory's "listeners". They allow you to associate a particular directory location on disk with each potential copy "type". When you do a copy operation of one of your specified "listener" types, Clipstory recognizes the type and says "Ah, look at that. The user just copied a graphic. I know just what to do with that. I'm going create a file for that graphic over in this particular directory and write it out right now."

If we return to my search for a butterflies example above, what if I was searching for more than a single "type" of thing? In my example I was only looking for URLs. What if I was looking for URLs AND PICTURES of butterflies? With Clipstory's "listeners", when I'm done doing my searching on the Internet, everything is nicely collected and ready to go, all nicely collated into a couple of directories, no more extra work required on my part. When I'm done, it's done. And by doing it this way, Clipstory has avoided the logistical problem of trying to paste more than one "type" of copy item at a time.

While I don't think you need to implement this feature in this same way, the overall FUNCTIONALITY (the why) needs to be addressed by Clipdiary.

Standing even further back and looking at this problem with the widest possible view, I would say that you need to address the issue of handling items in the clipping database in groups or collections in the GENERAL CASE. Right now we can only operate on clipboard database items one-at-a-time. We need to be able to operate on the items IN GROUPS in LOTS OF DIFFERENT WAYS. Pasting, deleting, etc. need to be able to be handled in groups. Not that it's relevant, but Clipstory does allow this. They don't have "paging" of items and they DO allow group operations.

"These are really good ideas I'll realize them."

Thank you. I could probably live with the tab thing if I had this. Having to shift-tab to get back out to the list, though standard Windows procedure, is less than convenient..

Hi,

Thanks, I will think about this.
But I am not sure that this is really appropriate task for simple clipboard extender, it seems that some type of research tool is a better choise:) I am not sure that this can be added without breaking Clipdiary's simplicity and convenience...
But I am sure I'll add support of paste\import multiple clips at once, hope this will make such work easier.

Tyushkov:

Yes, I know... it can be hard to decide where exactly to draw the line in terms of feature bloat. On some software suites (like Adobe CSx), it can even be difficult to decide which application to use for a particular work activity since there's so much overlap.

I would, however, evangelize FOR including multi-item functionality for the very logical reason of "If not in Clipdiary, then where?". The Windows clipboard is ALREADY a one-thing-at-a-time sort of affair. WITHOUT Clipdiary, I can cut/paste cut/paste cut/paste away, one thing at a time, into a notepad or Word doc as a buffer, as mentioned above. Having Clipdiary be able to do operations on multiple entries gives you something to claim that one CAN'T do WITHOUT Clipdiary (COMBINING copy buffer entries without having to manage it by hand, if you see what I mean).

I'm not sure I can think of what other kind of app SHOULD have this feature if not something like Clipdiary, to tell the truth.

Besides, performing maintenance on the Clipdiary clipping database is a SOP (standard operating procedure) activity for life with Clipdiary. The DB rapidly gets out of hand if you don't (although the sexy new search features SURE helps ) maintain it. Having to do deleting activity one-at-a-time, one-at-a-time, one-at-a-time, gets real old real fast. Deleting DB entries SCREAMS for a group operation, and once you have it for THAT, well, one thing naturally calls for another, if you get my drift.

Not that's it's relevant, but Clipstory DOES have a multi-select facility for deletions, FYI.

All the best.

Hello

I will surely add a multi-select facility to Clipdiary.

i woultd like to see filters for applications and contents.
my application passwordsafe should never get to the clipboard-history on disc.
if i see passwords in the history, i want do say: never store this content again (maybe you must use md5-hashes to store the filters).

Hello

Thanks for suggestions. I'am going to add applicaton-based filters in next versions, but I am afraid that content-based filters will be very slow...