Folder in my documents?

ingo_knoch

Hi folks,
after my first hours in Onshape I would mention some enhancements.

With the amount of documents in the my documents section it will be fast confusing, so I guess structured folders would help on an easy way.
Also the commands like share, delete, .. should available for all folders.

Great work guys!
/Ingo

lougallo

This has been marked as an improvement. The current solution is to use search to find them. Some have appended the name with a project name or some common naming convention. Since the name doesn't cause issues like "references" you can rename without any adverse effects.

billy2

I know this might be controversial, but I prefer search over folders for finding stuff in a database.

lougallo

I agree. I live with search. Folders slow me down. Google finally added them and although it is nice for grouping/sharing, the organization of it I don't use. If anything most folders are only one deep. Now adding various tags would let me to the same without folders all together. I think the sharing aspect/security is where this might go..

caradon

OS is database driven. Doesn't that make folders pointless altogether?
Tags could be useful though... You could search for a combination of tags to narrow down searches. Or decide to delete/change tags for projects.

We use SolidWorks & EPDM in the office and always get into the discussion of 'to folder or not to folder'. I would say 'not folder'. Most EPDM users carry a history of working on a cluthered file server and still stick to folders in EPDM. EPDM (in my opinion) is really flawed by design: conceived as a FILE EXPLORER, using FOLDERS, with a DATABASE backend. no no...

Dries

Ben_

I think a visual representation of the files makes it easier for a visual program. I am not sold on the tags but at the same time I have nothing to offer as a substitute, soooo.... My 2cents...

ravi

I would prefer search over folders anytime. None of the modern apps use folders. Google has been experimenting with tags, hierarchical tags and folders across all their products but they never for folders right. Tags may be better

mark_biasotti

I prefer folders over search (and believe me if any of you know my background, you know that I've been very close to this controversial issue.) The reason that I prefer folders over search is that search only works well for our application if you have a good (relevant) filtering system. To have relevant filters, you need to tag your documents appropriately. This takes up-front time and effort to do. Also folders mimic the real physical world and hundreds of years of real-world practice is hard to beat. On the other hand, folders allows for organization "after-the-fact"; i.e. you can name your document anything you want and let it's location be the "filter". There is no technical reason I can see that online-cloud can not have folders; its just how the object oriented DB is presented to the user...
I don't know about you but a lot of my world initially is conceptual and I don't like to stop and think because it interrupts my train of creative flow. I like the flexibility of creating first then organizing latter. Just ask my wife about my workshop; in the heat of a project it is a mess with tools all over the place. It is only toward the end of my projects do I "clean-up" and make things tidy; the same is true for my CAD work.
Also correct me if I'm wrong, but with OS, no two documents can have the same name? This is the kind of restriction that irks me and why our industry wrestles with PDM when it comes to this issue. Don't get me wrong, PDM has it's place and is necessary, but we implement it only toward the production phase of our project.

stevehess

Hi @mbiasotti‌ , there is no restriction on document names. Many documents may have the same name.

BTW, that has many benefits. There are absolutely no dependencies on document name (or any other name for that matter). Everything has an internal ID which is tracked by the data manager.

lougallo

Search vs Folders. Good discussion. I am the opposite. Search is how I work. I stopped using folders for email, documents etc as I have moved from things that were very container-based to content based. Even when I moved to Windows Vista/7/8/8.1, the start menu was useless to me since search just was so much faster. I think many systems that would use tagging like Google Drive or even GMail have been successful using the search approach using tags but ultimately complemented it with folders for traditional approach as well and filtering reasons.

Folders can bring singularity to sharing, project management and even organization to data. There are plans to use these methods in OS as it matures. ~Lou

mark_biasotti

@‌steve Hess

Hi Steve. Good to know that isn't a restriction - although I'm baffled to know how the two documents ( if no tags are assigned) are differeniciated?

M

kevin_quigley

Got to say I side with Mark on this one. We are testing here with a tiny volume of files. Right now, on my main SolidWorks wokstation we have something like 25,000 SW files across around 40 customers and maybe 400 projects. To access this lot we use a file hierarchy AND search. But for search to work you need to know what to search for!

Who can honestly say they name and tag all their files appropriately? What if you store files by project number refence or by part part numbers? Then what if you have to store customer data saved using THEIR naming strategies? After 24 years of doing this we have settled on Projects>Customer>year>project>files (in other sub folders).

Fact is, we need both approaches. Let's make it simple for users and let them decide what works best for them so have great search with plenty of filtering options, and a comprehensive folder structure capability with nested folders, colour tagging of folders and ideally some way to share folders and files in a Dropbox style way.

As I understand it we can store other filetypes in the Onshape file/folders (or have I misunderstood that one)? Getting back to ISO design standards controlling and sequencing related documents is critical to that process. Being able to search and display results in a totally user defined way would be a major benefit (so search by project name, display by filetype, review date etc).

matt_hardman

Since you inevitably end up using a document as an entire assembly, not just a single part, the search must include all named parts as well. I think I'd like a way of seeing the parts in a document from within My Documents as well

matt_hardman

In the Bicycle Frame Design there's a Fox shock. Try searching for "Fox" though...

matt_hardman

If we're all collaborating on a project, in which we all contributed a workspace that we created, in what space should we be working? I think we would have to be able to create project teams within an organisation that come up in the side bar. So instead of just "Public" there would be "Mega-Corp", and under that "Mega-Bicycle Project". Team members could be added to the project instead of having to individually share files with them from that project.

matt_hardman

In that way the "Mega-Bicycle Project" acts as a folder, in a way

kevin_quigley

Matt, this is exactly why I was asking for integrations into established cloud based project management systems (Base camp/Wrike etc). That way we could set up projects in those apps and it would automatically tag to OnShape. Ideal for design processes where you need to track all decisions and versions for standards.

But at the very least, some kind of internal project based control would be perfect. Add some kind of GrabCAD Workbench type capability with Partner Spaces and you are flying!

CaptainBisquick

Users should have folder and search ability both. Not forced into one or the other. Each is appropriate for different circumstances.

For example, in my case, I have several public documents cluttering up the list of documents that I'm actually working with and presently concerning myself with, and having every document I've ever made, all in one place, is actually irritating. I'm completely in favor of avoiding feature bloat, but when taken to an extreme the result is just as detrimental as adding too many features.

_Ðave_

+1  @CaptainBisquick I agree 100% and won't consider paying for Onshape unless this is resolved.

   This is like having all your tools in one barrel and the screw driver you need is somewhere on the bottom.
   Could you imagine after a few years with 10000's of documents trying to find something you created a few months ago,.
   your best off just buying a new screwdriver,

    IMHO
   _Dave_
   
   

_Ðave_

Wow I just noticed that this discussion started a year and a half ago. Still nothing as been done.
With this and drawings dragging out looks like it may be a few years before I'll be shelling out $1200.

 I can't wait,  keep On Onshaping 

kevin_quigley

The rate of change in recent months is reducing. As functionality increases, complexity does too, as does legacy.  But there are still huge gaping holes in basic functionality. This is one big one and for the life of me I cannot see a reason not to simply introduce a folder structure. Personally, I could never switch to a system that did not offer user flexibility in how to organise projects. Folders work, they don't need any explanation. Just do it.

henry_feldman

By the way as a programmer I would say that in a non-filesystem implementation folders are just tags. Now how they are represented to the user is way different, but in fact in a non filesystem implementation they can be a special case of tags which have a parent tag. Even better if you implement all your tags to be hierarchical then even more awesome. That way you can tag the same file like customer->acme->weCoyote->rocketSkatesProject->2016->newRocket->nozzle123 and Parts->rockets->nozzles->nozzle123. This way you could easily browse a folder hierarchy starting by any arbitrary axis or just search for "nozzles". You can choose to have your tags flat (like regular tags) or hierarchical, simply by selecting a parent.

_Ðave_

@henry_feldman sounds logical except that if you wish to change a name in your hierarchical structure you'll have to change it in all the documents within that structure. Sorry I'm not buying into that.

henry_feldman

_Dave_ said:

@henry_feldman sounds logical except that if you wish to change a name in your hierarchical structure you'll have to change it in all the documents within that structure. Sorry I'm not buying into that.

Um, not sure what you mean. When you change the name of a directory (which is essentially an arbitrary tag in your b-tree of your filesystem) you don't have to do anything else to the potentially millions of files underneath because files in a file system aren't stored against the name of the directory, but the ID. I am not guessing that this is possible, I do this every day in our software (and lives hang in the balance in medical software, so yeah, we get this right). I change category names in b-tree entries all the time in our software (say the class of a drug or search class of a drug [what docs refer to it as]) and since NOBODY uses the actual name as the reference into a hierarchical structure of objects) nothing changes except the display term. The name is something for human readability, software should always use a thread-safe generated ID. You use ID's of the object for tags, so you can rename the tag, and nothing has to change. A typical structure for this type of object might be:

public class category {

Integer id; //note: generated by DBMS in thread safe way
String name;
Integer parentCategoryId;
boolean folder;
String color;
...etc...
}

henry_feldman

henry_feldman said:

public class category {

Integer id; //note: generated by DBMS in thread safe way
String name;
Integer parentCategoryId;
boolean folder;
String color;
...etc...
}

But wait, I hear you all cry, how can you search that using the name? Well you search in 2 ways, one extremely fast and one really slow. The super fast method is that you search the link table for the IDs since you only let the user search for known tags (e.g. you can only search drugs for NSAID or OPIATE) which you let them pick of a list. Apple's finder does this when you use the color tags you can put on files. You can't search any arbitrary thing, just the colors there are off the list. The alternative is to instantiate the tags (e.g. turn them into text) and then search. You of course pre-index this to make it less painful, but every time you update the tag name (in a hierarchy everything for that tag and the children tags) would have to regenerate the index.

Not that his applies to the CAD instance, but we do a mix in our software with some clever tricks to allow for fast and secure searching (we have to worry about reverse index hacks causing data recreation), but that doesn't apply here. The only reason we have to do both, is that in healthcare you have to be able to recreate the thing that was on the screen when the doc made a decision, so if it was NSAID when they wrote the order, but now 2 years later you change it to NSAIDs you need to be able to search on both, so we hold onto the instantiated name in a text tag base.

_Ðave_

 Henry, thanks for the effort you took to explain. Honestly most of that just flew right over the top.
I think Onshape is with you on this, I now just wish they would implement the darn thing so that I can decide if I want to send them a check or not.

3dcad

OR maybe we just need better search, if you think what is the biggest database we use everyday?? Yes, google - does it have folders? NO; tags? NO; just that one input box that sometimes makes you blush when it knows better what you are searching than you.. 
This would need a lot of data collecting for usual behavior, machine (home/office/etc), time of day, what else,  to match results with user intensions. 

_Dave_ said:

..
   This is like having all your tools in one barrel and the screw driver you need is somewhere on the bottom.
   Could you imagine after a few years with 10000's of documents trying to find something you created a few months ago,.
   your best off just buying a new screwdriver,

    IMHO
   _Dave_
   
   

@_Dave_  This is not true, current system is like having all your tools in vertical storage which will pick up any tool in seconds if you know what you are looking for. 
After 10 years folders feel just the same, there are so many of them that it doesn't make sense crawling through.
Making folders with dates in names is unnecessary since each doc has date info attached (and searchable).  

And if you think this true, we already have folders since Onshape docs are like folders but we are not able to quickly list the stuff what's inside 'folders'.

At current stage, I would begin with:
- enable tagging on tabs, versions and branches inside docs and docs themselves (in a way that @henry_feldman
 described),
- show tags in familiar folder like tree view but let 'one file belong to multiple folders' 
- search all descriptions, tab names, part names etc. (all user inputs)
- have checkbox to search only a) owned b) private c) private+public (remember default),
- create suggestive search with dropdown list updating with each letter
- show results in a way that you don't need to open doc to see what's inside

after this, keep on building so brilliant search that there is no need for tags anymore.

_Ðave_

 I think Onshape is after the big players in the manufacturing world and what is taking so long is that they need to determine if these players will buy-in to a tag and search system in which onshape appears to prefer. Honestly I think these metalheads will tell you exactly where your tag and search system should be inserted. Sorry maybe a bit graphic but honestly why not implement a tried and true system (file folders) first you can always do tag and search as well.

3dcad

@_Dave_
In database system, there are no files or folders. So that is completely out of question.

You can think it as single excel sheet where the only possibility is to create column with name folder and write 'folder name' on each row that you wan't to 'live' in same folder. Then you can filter to show only those rows that have specific value in folder column.

I'm not sure, but I suspect that all documents for all users live in same database, so difference between users is also only one column which has value of username. That is why you only see your documents.

This is very, very simplified explanation of database system and things can be build up in various ways. Yes, they can build it to look and feel like traditional folders, but behind the scene it's tags that act as folders.

With this IR we should think it in two parts: 1. system behind  2. view in front - I think it's been made clear that 2. would be folder like appearance.

tom_scarince

If they give us hierarchal tags, the tag people will be happy and the folder people can still have their folders.  

To prevent either side from getting smug and claiming victory, they could be called "taxonomies" or something. 

Alternately, have a checkbox that prevents you from using more than one hierarchal tag to an object and call it  "folder mode". 

I guess another subtle difference is what you see - suppose you have

Bicycle>Wheels>Spokes

When tag people look at Bicycle>Wheels they want to see everything in Spokes as well.  Folder people want to see everything in wheels, and a spokes subfolder but not everything in spokes yet. 

_Ðave_

I'd be happy to try anything at this point, anything is better than what we have now.