Filesets simply fail as an organizing solution

Permalink
Filesets, while conceptually nice, don't work out for big builds. This seems to be a common complaint, I'm not sure why a solution hasn't been found.

We're currently developing a large university site (hundreds of pages, over 100 users). Our past sites have been of more medium sizes, so the file sets work out nicely. However, we're only halfway through development and the number of file sets has ballooned to over 50. By the end, we'll have well over 100.

Franz, I've read your philosophy on the matter and understand that you don't want people organizing folders (because that's too 1980's...). However, the alternative filesets provides is not pretty. For small-time users, we can limit the fileset present. This will work, though majority will wonder why we don't just have folders.

The real problem is with the top admins- having to scroll through a flat wall of filesets is not practical (yeah, i know there's a search box if you've memorized all 101) and bound to be a major complaint we'll get. Not to mention that the backend organization of the files is bizarre- in timestamp generated folders as opposed to a traditional label tree of folders.

It'd be beautiful to have the choice at install. For small sites, install with filesets. For large sites, I could install with a folder based file manager. A folder structure on backend would be perfectly reflected in the file manager UI. Folder permissions would drop down like the sitemap and backend FTP integration would be seamless and thoughtless.

I know we're talking about some extension development here, just a little christmas wish. Thoughts? I know others have built even bigger projects with c5, how do you manage with filesets?

warpol
 
frz replied on at Permalink Reply
frz
fail is such a strong word.

My philosophy is simply that it is really not how people think. Most things go into loose associative networks in life, not strict hierarchies. Yes, I know the same argument can be made for pages in a website and we choose to have a hierarchy there - but we were forced into that choice to manage permissions and theme settings in a sane way.

I posit if you look at most people's file systems you will see an utter mess of files spread in perhaps a dozen or two flat directories at most. It's rare to find someone who takes the time to keep their file system all nice and tidy - it's a time suck and while it certainly leads to efficiencies later it is not a solution in itself.

You are associating folders with cleanliness, and in reality its organizational work that creates cleanliness - not the folders themselves.

So there's a tad more thought behind it than "that's too 1980's." ;)

To address your concerns...Yes. Plenty of people including us use the file manager with more than 100 sets. Plenty of people use gmail with many many more than 100 labels and do just fine. All you have to do is use the resources already available to you, here's some thoughts:

1) Take advantage of cross sections. If you would normally make HumanResources/Forms and HumanResources/MeetingNotes - instead make three sets, HumanResources, Forms and MeetingNotes and put files in ALL the sets that match. Then you can find them in different ways when you want them in different ways. ie:
"Gee I know we have a form for that but does human resources own that or did marketing? Meh I'll search forms.."

2) There's tags too ya know. You could use tags for the above scenario as well.

3) get creative in naming sets. There's nothing wrong with HR-forms and HR-MeetingNotes as set names. With the ajax search you just start typing HR and you'll only see sets that match. That should be far more speedy that navigating up and down a folder tree.

4) There's public sets and personal ones. Check that out if you're worried about too many site editors messing things up.

The backend exists that way so we can manage versions. This is key. Much of what you are asked to do as a computer user in a folders setup is manage your own versions of files. That's insane. A computer should do that for you. Good folder management is ALL about keeping your files broken up into folders small enough that you can save a new version of that important proposal and always be able to roll back. Ideally you have a folders end up representing what should be a file, and what's stored in it are really just versions. Why would you ask a person to be responsible for that when a computer can do it so much more effectively?

You may not have noticed, but you can replace a file in the file manager and it will create a new version and keep the old one. To pull that off we had to treat the physical file system as a virtual store that concrete5 can manage so file names don't collide and accidentally overwrite one another.

Moreover, we're managing a lot of data about these files in the database, so the idea of making a /files/ directory that people put stuff in directly would create a lot of potential confusion instead of the incoming directory approach we have today.. eg "I dunno why its not there, I put it in the file system!!"


Soooo.. As you can sense this is not something we're revisiting. ;) It'd be a dramatic rebuild that would really gut the way the file manager works (and would take a lot more than two weeks, tho the christmas wish thing was nice ;) Moreover, I maintain that the the sets are truly a better way to solve the problem. I acknowledge there may be usability improvements we can continue to make so it's easier for people to understand and use, but this really is the way of the future.

ITunes started it, because the failure of folders is most obvious when you try to manage a music collection in them.
GMail is loved by millions.
GoogleDocs is taking on microsoft as the OS of the future (seen Chrome OS yet??) and even in there - no folders, file versions are managed within the file itself.

So with all that being said, one take away I have is I should do a screencast how-to on using sets in smart ways to help with the learning curve.

If there are usability improvements any one can suggest I'm all ears as well.
warpol replied on at Permalink Reply
warpol
Fail is a bit harsh, though I feel some change is needed. Thanks for taking the time to thoughtfully reply Franz. To your points:

1) and 3) Cross linking works and creative naming work- but have always felt like a partial solution. I prefer a solution that doesn't involve the search. Yes, the ajax search is beautiful and great, but finding/saving a file shouldn't always depend on searching- some like to browse.

2) Tags work, but also add complexity. I then have to explain tags AND filesets. Too much.

4) Public/private/permission based file sets do work well, no complaints here :). I'm focusing more on a solution for the top admins.

I am in agreement regarding not having to spend time dropping stuff in folders, especially when most users will have no respect for the folder organization one has in mind. So I don't mind a single directory, but I firmly believe that the label organization needs to be optimized.

And I love both Gmail and iTunes- I see what you mean. But concrete5 doesn't manage music nor emails, both of which are unique, more uniform file landscapes compared to the variety of files uploaded to concrete5.

My idea of a solution, and one I'll probably build out, is the creation of super labels. This relates to your point about cross linking labels, something we currently do. There are clearly some labels that are more general and important than others in particular situations (i.e. 'Photos' being more important than 'Sub-section A'). I'd like to set it up so that a user can click a super label (all super labels are kept at the top of the file set list for quick access) and have only associated cross-labeled set options appear below for further streaming. This fundamentally doesn't change the fileset philosophy, yet provides emphasis and organization (the designer me hates presenting users with too many choices).

I wanted to make sure this idea wasn't just my idea of what's best. So I did a quick usability study among some non-tech friends. I was surprised to find that most liked your label set-up as opposed to folders (this was a younger demographic though). But all agreed that a super label setup would be helpful. Having to scroll through the file sets was not easy- and none of them memorized the names of sets to search for them- though with time they might have.

The reason I'm making such a fuss about all this is because I get worried about using concrete5 for larger and larger clients. I'd love to see a solution that provides flexibility for higher organization schemes when needed with big clients, without over-complicating it for the small clients (it works magically for small clients right now btw.)
TheRealSean replied on at Permalink Reply
TheRealSean
I am finding a similar problem, with a site I am building now as the amount of file sets start to increase.

Its for a Photo Gallery,
So I create, a Set For the Gallery>Group>album

Thats 3 sets per album, then I am finding, that I can not have two sets, called Portraits, unless, when I call the filesets I check to see if they exist in both sets. This I can see fine on smaller number of sets but I have over 200 Albums to upload thats around 600 sets without global sets like core images, and those not in galleries.
I can deal with the naming issue just make sure names are unique, but a user adding uploaded images to a set may not know that the name has already been created and end up adding images to an existing set.

I too am one for the super labels solution.

I could then Weight my labels, to have say Users in step 1 then limiting all the sets to that user without having to do that initial search in the first place.

The main problem I think we have is end users, I am having to redevelop my previous solution for the fileset as the users did not like a select box with the possibility of 100+ options.

So the ability to filter those results would really make it easier to add images to the galleries or when selecting albums.

At some point I would like to allow, site users the ability to log in to the file manager and download user specific files, and I don't think that C5 currently allows this. I would not want, those users to be able to see all the Global sets, I would like them to be filtered. Maybe by category or user permissions.
warpol replied on at Permalink Reply
warpol
Exactly, super labels would really solve a lot of these problems. And I'm also a big fan of your 'user uploaded files' streaming idea. It'd work perfect for more novice end users who could just upload to a 'My Files' aliased to their user name. That way any files not put into a file set would automatically get put under their user label. Would love to see features like these built out.
frz replied on at Permalink Reply
frz
Interesting thought about super labels, my only concern is does this really make sense at a glanc or is it a complex solution to a complex problem... I tend to get excited about the simple intuitive ones.. One thought that jumps to mind is the idea of some simple color coding for labels... Making a few impotent ones red instead of blue mit be all you need, and it's the kind of thing you can explain to anyone without their eyes glazing over..

Another though is simply ui. Make it so you can hide labels from the default list, control sort order. And make it so those settings default for each user so when they are in the file manager it feels the same as the way they left it...like your desk would... In fact this seems like it should really be the way it behaves and frankly it doesn't today because of time limitations, not stategy

If I didnt mention it before, check out saved searches


Oh. The document library in the Add ons does just what you're asking with uploading files from the front end
Mnkras replied on at Permalink Reply
Mnkras
Hmm, i agree with franz that folders are not the solution,

but i like the idea of super labels, kind of a filter for sets,

so, sets in sets,
frz replied on at Permalink Reply
frz
The whole super set thing sounds geeky to me. What if it really was just that any set could include 0-n sets. You don't have to define it as super or anything, but you can essentially clump stuff up how you see fit... Make a hierarchy if you really want, but it's still really collections not categories at it's heart
warpol replied on at Permalink Reply
warpol
Sounds like a good solution. However it's executed, as long as it's a system that allows for some hierarchy/organization (read: limiting the sets viewable) when selecting a set. Keeping all sets as siblings would be fine.

And, I like geeky (and some clients have demanded it) ;).
TheRealSean replied on at Permalink Reply
TheRealSean
I agree, collections sound like a good solution.

Highlighted/grouped, either way I see as being a benefit.

Just a visual way to make certain labels/sets distinctive.

I have seen the saved searches but never really dug into them I think that I need to dig deeper.

Thanks for the heads up on the Document Library, it does seem to offer a good amount of what I am trying to achieve the rest I can ask about in a separate thread.
andyh replied on at Permalink Reply
Hi Franz

Just wondered if you'd given this any more thought? I love C5, but the idea of a method for grouping sets would enhance it a lot for me as I know users struggle once the set list get to a certain size.

Interestingly, I started thinking about this again while using Flickr, which has a capability to organise images by creating sets, sets can in turn be organised into collections and collections if required can contain other collections. This facility creates a simpe way of organising huge numbers of resources and could be a really useful feature within Concrete, especially as sites grow and editors need to keep track of large amounts of files.

btw: I hope you make it over to the UK at some point. I'm based in Staffordshire in the Midlands, but I'll make an effort to turn up to any event that gets organised and buy you a pint.