Allen Gilliland wrote: > > > Dave wrote: >> I could go either way on this, but Elias does have a good point. > > I would say that I am of the same mindset. I don't really care that > much which way we go, I am mostly concerned about picking what is truly > best for users. > > >> >> Allowing a tree hierarchy does make things more complex in the UI code >> and for the user. Look that the ugly category and bookmark management >> UIs (you really need a tree control to do them right). And I'm not >> even gonna mention the code that supports >> HierarchicalPersistentObject. > > Well, I don't want to go into that too much, but IMO those problems are > with the way it was implemented, not the fact that hierarchies are used. > Those are also cases of doing hierarchies in a relational database, > which the file management does not need. > > At the end of the day I don't think that what changed in the file > uploads UI really adds that much more complexity for users. As I said > before, I think that most users are comfortable managing files in a > hierarchy because that's how all file systems work today and so people > are used to it. I think that adding the "buckets and entries" idea will > add roughly the same complexity from a UI perspective. > > >> >> I think hierarchies are important to expert users, but other users >> generally don't use them. Look at interfaces like iPhoto or iTunes or >> GMail, they all have flat hierarchy of collections -- 2 levels like >> Elias is suggesting. > > I would agree that simply allowing users to create a single level of > directories would most likely be enough to accomplish what we need. I > would expect that most people wouldn't need to create multiple levels of > directories, and even if they wanted to they could probably get away > with a single level. > > Also remember that the main reason this work was done is so that > resource files (images/css/scripts) from our themes can be imported into > a weblog as part of a theme. I double checked all of the existing > themes and none of them use 2 levels of directories, so it should be > okay if we only allow a single level of directories.
So what do you think? I'm all up for only showing one level deep only for folders now (since it's just a matter of simplifying what we have) and opening up to n-deep folders if we have users threatening us why we didn't so in the first release in a future release. I'm for keeping the same vocabulary (maybe same interfaces too) just not allowing nested folders for now. I don't see how that can be so wrong when we had no folders at all before. > > >> >> What I'd like to see in the file-uploads area is metadata, we should >> be able to save title, summary, category and tags for each uploaded >> file. If you want a hierarchy, view by category. If you want >> collections, view by tag. > > ewww. to me that is a big leap, both in terms of UI complexity and > software complexity. i would be very hesitant about doing that because > IMO that borders on the kind of thing people should be doing in a > different service. > > my other hesitation here is usefulness. i can certainly see how > capturing that metadata would be useful to some people who are power > users, but my guess is that most people probably won't use it. i expect > that 95%+ of the uploads in peoples weblogs now are just photos which > they want to dump into an entry and will basically forget about within a > week or so. I'm fan numero uno of metadata (in case you didn't know), but adding metadata to weblog resources is a big leap as Allen put it and maybe we should discuss that separately from the WeblogResource structure discussion. > > -- Allen > > >> >> - Dave >
