Outliner Software Forum RSS Feed Forum Posts Feed

Subscribe by Email

CRIMP Defined

 

Tip Jar

Sohodox Review

< Next Topic | Back to topic list | Previous Topic >

Posted by 22111
Sep 10, 2013 at 08:26 PM

 

I am very much interested in DMS, and it has been mentioned here today or yesterday in another thread. I don’t think Sohodox is a serious contender, and here is why.


Today on bits, my question:

Would you like to comment on this aspect on your program:

The database (db) is just for the index, the files stay within the file system (I think that’s very good; I lost thousands of photos by Adobe Lightroom, for its way of storing your files under new names, I never understood where and how, and I cannot bear to happen the same thing with my other files, so I must know what’s going behind the scenes before buying.)

1 In your screenshots, I see “Public folders / private folders”; may I assume these are virtual folders within the db, and do not correspond to the file system and to the names of the physical folders?

2 So what about the folders and files in the file system? Does your software check for moves/renames of the physical folders and/or files, made outside your program (within any file commander)?

3 In both cases, is there a way to rename/move physical folder and/or files within your program? By what commands? Can we see a screenshot for the dialog doing this? Is moving files only possible by drag and drop, or do you have some file commander gui for doing this, with two panes, source and target?

4 Is the “Document title” within the pane “Documents”, right to the pane “Workspace”, the original title of physical file, or is it something other? In other words, can this “Document title” be changed, within your program, and then appears as a renamed physical file within the file system, just like you renamed it in “Douments”? Or is it possible that the title here is / becomes something else then the name of the physical file represented by this “document title”?

5 With respect to 1, can one virtual sub-folder appear in more than one virtual parent folder?

6 Ditto for files, can one file (“document”) appear in more than one virtual folder?

7 If “yes” for questions 5 and / or 6, does a “delete” just delete the reference, or the physical folder/file? Even for the last instance of that physical file? Is there a warning for this delete, when it comes to the last instance/reference, and thus it would delete the physical file, instead of just a reference?

I am sorry I am so technical, but serious buyers will need to know the answers to these questions before going to administer their files with such a system where a db is an overlay to the physical file system.

and the “answer” of the developer:


Yes, you can move a document in Sohodox from one folder to another. You can also import your existing folder structure that is on your drive to Sohodox by simply dragging and dropping it.
Yes, the indexing information is added to database and the documents are added to normal Windows folder. The files names are not changed in Sohodox unless there are two documents of the same name, in this case a suffix is added to the file name.

 

This is ridiculous for an answer, and this part here, “You can also import your existing folder structure that is on your drive to Sohodox by simply dragging and dropping it.” looks good as first sight but seems to indicate LOTS of trouble, since it indicates that there is no real concept in this tool, for the interaction between the file system and the overlaid “virtual folder system” by database.

From what I understand, this “DMS” is a database tool that does two things, and two things only:

1) It has your comments stored in a database, instead of in the file names or in the “comment” part of the “additional data stream” of the files, making easier access to these than by the Windows dialogs, BUT several file commanders give easy, instant access to these, too, both for viewing and for entering/changing; xplorer2 is especially good for this.

Of course, a “data stream” comment system is not “exportable” to FAT32-formatted usb sticks, but then, most file managers will warn you whenever you try to copy/move to one, so risk of data loss by inadvertancy is inexistant, and the Sohodox system is even less “exportable”, since you would have to export the whole database, together even with only parts of all your data, and you will quickly become inconsistent databases and create chaos for yourself.

2) It puts your files into any virtual folder you might it to be; this could be done by a file commander, just using real, additional folders in your file structure, and Windows links. Of course, doing this this way means either lots of manual work, or then, some macros within the file manager, but those macros would be very easy (“create link file, then rename the link file (to your standards; any file commander names those links created there in some other way, when you will want to have it named by your own standards), then (different macros for each) put the new link file into one of several “ToDo” (or delegation or some other standard) folders” - done! Then, deleting the link file there is even simpler.

Of course, in such a “file system” system, you will work within your preferred file manager all the time, but then, in a system like Sohodox, you will work in Sohodox all the time… and you will quickly run into trouble, having to distinguish between your file system and the virtual Sohodox folder system at any moment… you will quickly create chaos here, too.


Have it file-system-based, or have it database-based, but for any hybrid system, as Sohodox is one, be more specific about its interaction between file system and your tool. And answer serious questions serious buyers have. (I had indeed been very interested in this thing, before getting my “answer”.)

 

 


Posted by 22111
Sep 10, 2013 at 08:58 PM

 

I just had another look into the bits forum:


jakobfries says:

I added a folder with PDF-Files into a Sohodox-folder and assigned each file a document type. Now I noticed first, that when I delete a document inside a folder in Sohodox, the document isn’t gone but still seems to exist under its document type. So if you really want to delete a document with an associated document type you have to delete it twice. That’s very inconvenient.

Then I noticed that in the “Default File Store” there are two folders which both contain those pdf-files I added to the Sohodox-folder, I suppose one folder is for my folder in Sohodox and the other folder is for the document type. If that is correct it means that when one adds files to Sohodox and assigns them a document type the files are acrually stored twice in the “Default file store”.


That’s what I explained above, without having had installed this program even for 1 minute. Such programs that pretend to make life easier for you just create chaos. Tabbles is another program I wouldn’t even have for free. Have a good file commander with some macros and work from there; or do it with a real DMS like ELO Office or such, with lots of expensive additions, but with total integration of it all, and forget your file system; seemingly cheap commercial “solutions” can become a trap.

 


Posted by 22111
Sep 11, 2013 at 07:10 PM

 

I don’t know if readers here are interested in this topic, since it has not got any commentary, and it’s about a DMS, not an outliner, but it had not been myself who brought this up, and I don’t want to leave a loose end.

Just “one hour ago”, on second day of bits offering, the developer added a second, now very serious answer to my questions which I would like to paste here in full; I do not think it’s copyright infringement of my part since it can savely be assumed the developer will be more than happy to see his comments near what I wrote:


Apologies for the earlier brief reply from us. As your message was long it got truncated in the comments sections and we completely missed the latter part of your message :) We appreciate you having taken the time to send in your questions. I am sure other users would also have such questions and am hoping that you and other users find our replies helpful.My reply is long so I request our viewers to expand it to view the entire message.

The database (db) is just for the index, the files stay within the file system (I think that’s very good; I lost thousands of photos by Adobe Lightroom, for its way of storing your files under new names, I never understood where and how, and I cannot bear to happen the same thing with my other files, so I must know what’s going behind the scenes before buying.)

You are right about this. We chose this approach because apart from
other advantages, customers tend to be most comfortable with it.

1 In your screenshots, I see “Public folders / private folders”; may I assume these are virtual folders within the db, and do not correspond to the file system and to the names of the physical folders?

Yes these are virtual folders in the DB that do not correspond to the physical folders in the file system.

2 So what about the folders and files in the file system? Does your software check for moves/renames of the physical folders and/or files, made outside your program (within any file commander)?

We designed Sohodox to be a Document Management Software for small
businesses. Its design, pricing and feature set are aimed at making it easier for small businesses to adopt document management. In our experience price and complexity are two of the main reasons which prevent small businesses from adapting document management even though they have a definite need for it and are usually clear about how it would benefit them. Though there is some overlap between a File Manager and a document management system (DMS), both types of applications are designed to solve different problems. Sohodox aims to create a single, centralized and well categorized repository of
documents which can be searched from multiple machines. One of the
main goals is to be able to find documents quickly based on different criteria (for e.g. All bills paid last month). A DMS like Sohodox therefore has very powerful indexing/categorization features. An area that File Management applications are not very strong at.

When you add files to Sohodox they are copied to a folder which Sohodox refers to as its File Store. Paths to these files within Sohodox’s File Store are added to the Sohodox DB. Like most DMS software we do not recommend direct access to the File Store via Windows Explorer or via any application such as a File Manager application. Monitoring for and responding to external changes to File Store would add needless complexity to Sohodox.

3 In both cases, is there a way to rename/move physical folder and/or files within your program? By what commands? Can we see a screenshot for the dialog doing this? Is moving files only possible by drag and drop, or do you have some file commander gui for doing this, with two panes, source and target?

No there is no way to rename or move physical files or folders from within Sohodox. You can change the names of virtual folders and document titles.

4 Is the “Document title” within the pane “Documents”, right to the pane “Workspace”, the original title of physical file, or is it something other? In other words, can this “Document title” be changed, within your program, and then appears as a renamed physical file within the file system, just like you renamed it in “Douments”? Or is it possible that the title here is / becomes something else then the name of the physical file represented by this “document title”?

The “Document Title” of file is initially generated using the file name and it can be changed within Sohodox. However changing the “Document Title” does not change the name of the underlying physical file. This ensures that any external backup programs being used work correctly. However when you export the file from Sohodox (for e.g. via Drag and Drop) Sohodox will name the exported file using its current Document Title in Sohodox.

Please note that we have received request for renaming of the physical file and may implement this in a future version.

5 With respect to 1, can one virtual sub-folder appear in more than one virtual parent folder?

No virtual sub-folder can have only one virtual parent folder.

6 Ditto for files, can one file (“document”) appear in more than one virtual folder?

No a file can appear under only virtual folder. However if a file requires multiple categories we suggest the use of tags. In fact our users have found the combination of tags and folders extremely powerful.

When it comes to indexing and categorizing documents, the real power of Sohodox lies in the Document Types feature. This lets you store different pieces of information along with each document and later use that information to search, sort and group documents. For example with each invoice you could store the Vendor Name, date, amount and payment status. And then quickly locate things like “all unpaid invoices from a particular vendor”. You can even save such searches. Such saved searches act as dynamic folders.

7 If “yes” for questions 5 and / or 6, does a “delete” just delete the reference, or the physical folder/file? Even for the last instance of that physical file? Is there a warning for this delete, when it comes to the last instance/reference, and thus it would delete the physical file, instead of just a reference?

You can delete the actual physical file along with all its references (Del key) or just a particular reference (Shift+Del). Appropriation confirmation/warning dialogs are displayed.

P.S. Because of the offer there has been a large volume of questions over
email, chat etc.. and our replies have sometimes been shorter than
normal.

Now, if you are interested in DMS and read all this carefully, you will see that this perfect answer (you simply could not be more specific, it’s really a treat and sheds some good light on this software development in general), it’s almost incredible how much this software is lacking in functionality): No synching between file system and files in the DMS, both ways: Renames in the file system will not be monitored by the DMS, and renames there will not be replicated into the file system; let alone for moves.

Then, the big advantage of a virtual folder system is not brought into play: No file into more than one folder, no sub-folder into more than one parent folder. So, what I explained for the file system, and what I thought was realized easier in this DMS, can’t even be done here.

So the developer speaks of tags, and as we all know, tags can be put into file names, and into file comments (see above); also, good file commanders are able to search for such tag combinations, and easy macros will do the “stored searches”, too. Also, good file commanders are able to search over several folders and their respective sub-folders (scope of search).

So, this DMS adds “complexity”, in the way that you must replicate any rename, and any move of a file or folder manually, be it in the DMS or be it in the file system, and this is tremendous work, and will cause de-synch, by typing errors, by simply working on groups of files, then forgetting to replicate the changes here and there… Also, it should be expected that moving a folder, together with its files, will cause very big problems, even for manual synching.

So you see here that any of my considerations above, without really knowing this software, but from a conceptual point of view (meaning I know a little about the problems of such systems in general), have been met by the missing functionality here (and yes, it is not easy to program all this).

But also, let’s note this DMS seems (?) to have some reporting capabilities as for the respective file contents; let’s hope this is not only by your tagging and by the date (which both would be realizeable by a good file commander).

Now a personal word. On bits, most software offered is crap, and I would never give my advice on such, I just let it pass before my eyes. Here, I had really been interested in perhaps buying, and so I thought about its possible shortcomings. And now a respectable developer finds himself (because he didn’t take my questions serious, early up) with a rather not so good (and as we see, justified) review.

So let me say that I would be happy to recommend this software as soon as he works on those points I put into the light when in fact I had hoped that I would get almost all “yes” to my questions - if not, I would not have asked them to begin with.

For the time being, my advice above stands: Buy something expensive and integrated, or do it within a file manager, but don’t try to mix up file system and DMS in a non-synched workflow.

 

 


Posted by Tomasz Raburski
Sep 11, 2013 at 07:59 PM

 

Very interesting thread. Thank you for sharing your thoughts.

 


Posted by 22111
Sep 13, 2013 at 05:34 PM

 

Thank you!

My review was triggered by a mention of this Sohodox bitsdujour offer on page 5 of this DMS thread

http://www.outlinersoftware.com/topics/viewt/4713/15

when in fact, on page 4 of that same thread, there are highly interesting posts of both MadAboutDana and Slatibartfast that both I cannot recommend enough.

As I have said today in the “other” thread, totally off-topic there,

http://www.outlinersoftware.com/topics/viewt/5083/30

there is a life-long discrepancy between a “natural/systematic position” of almost anything in your data repository, and your “processing needs”, and (without this being an answer to the question how to divide it all up), perhaps I can say that a good start for every system would be:

- have physical folders / ranges of folders for your taxonomy

- then have virtual folders for processing; you could replace those virtual folders by tagging structures if you prefer

Clear distinction between “position within the taxonomy” and “processing” is certainly a very good start, and is mandatory as I see things at this very moment. I am aware that this means LOTS of referencing, and of cutting up, but then, I have never seen any working system in which “filing by processing needs” (which theoretically should avoids lots of clutter) does not create total chaos.

It goes without saying that in very standardized environments, “taxonomy” and “processing” could be more or less synonymous, for a good part, but in every workflow where some elaborate, individual processing is done, strict compliance of taxonomy for the repository seems to be mandatory in order to avoid your getting lost in your data, be it physical or electronic, hence the need to overlay that taxonomy by a second, process system, that multiplies the first system several times in its various virtual levels.

 


Back to topic list