Some new [??] arguments on the nested folder debate

doublemeat

I know the "multiple nested / hierarchical galleries" debate with smugmug reps is old and endless. But in the years of lurking I've done, I haven't seen some of these (to me) obvious counterpoints to the smugmug rep's arguments against arbitrarily nested nodes. (That doesn't mean the arguments don't exist...and I have done a cursory search before writing this. Surely one or more of these points have been made but hopefully one or more are "new" or more succinctly put [?].)

Smugmug arguments against arbitrarily nested nodes, and counterpoints:

1) "Can you explain to me why you need multiple hierarchies and why categories/subcategories can't address it?"

I hope this doesn't sound smug or rude, but I find that (clearly rhetorical) question patronizing, smug, and rude. The people asking for that feature are paying customers. They should not have to make a reasoned argument or impassioned plea. If enough people ask for the feature, if they are paying you, if the request bubbles high enough in your feature queue, and if it is reasonably feasible to implement (and the empirical evidence overwhelmingly shows that it is)...then give it to them! (Rather than endlessly debate against the request's merit and dismiss your customers' arguments...or worse--insist they make good ones!)

2) "Our users generally don't like drilling down into multiple levels to get to see glorious photos."

There are multiple problems with this argument:

• We must agree on this (at minimum with pro accounts): They are not your users! They are your users' users. They are the ones advertising and driving people to their site (with some help on general smugmug searches and other bonus handoffs from smugmug...which is one reason people pay you so much). Let your customers decide how they can best serve their customers, in their own opinion (not yours). Please?
• This argument also carries with it multiple assumptions, such as deeply nested hierarchies being the only way your customers wish to provide navigation to their customers. Maybe they just want to administratively organize their photos more like they do on their own computers, and expose photos on the UI in other ways (e.g. simple hyperlinks with tag searches, or smart galleries).
• I dare propose that your customers (pro accounts at least) are not paying you to be a design nanny or make morality calls for them. I believe they (like me) just want an easy way host photos, and provide a pretty, highly customizable, and "brandable" framework for that.

3) "Drilling down to multiple hierarchies is too slow."

A categorically false statement (due to an implicit "on any website"). This may be true with current smugmug infrastructure/frameworks, and/or with just your current navigation scheme. But it is certainly not categorically true of all websites. To wit:

• Whether limited to three steps deep, or unlimited--the fact is that your current push/pop form of FIFO queue navigation is inherently sequential. The same hierarchy could instead be (perhaps optionally) represented as a tree. Benefits of tree navigation:
  • Is inherently "random access". You can get from any node to any other node arbitrarily higher, lower, or sideways--in one click.
  • Gives user a variably and arbitrarily more expansive view of your site all at once.
  • Does not need to be "ugly", with yellow folders and right angles, like Windows Explorer. Its behavior can also encompass any variation of auto-expanding (and/or collapsing) nodes, spring-loaded nodes, auto-expand/collapse-all nodes, and-or manual drill-down desired.
  • Is empirically demonstrated to promote end-user curiosity and linger time.
• Technology DOES exist to allow the web-based presentation of "deeply nested node navigation" that is nearly as fast as a local native folder manager, even in sequential push/pop mode. There are many enterprise stacks, app frameworks, plug-ins, portable libraries, and/or more lightweight insertable javascript functions that help provide this functionality. Many implement variations of a dynamic read-ahead/cache behind model, that make navigation appear "local speed". (I'm sure you guys already know this.)
• And again, even if you couldn't (or didn't want to) make it faster, you are still assuming that deeply nested nodes are actually the way your customers want to present photos to their customers, rather than as a way for administratively organizing, with some other way of exposing the photos.
• Even if your (paying) customers want to nest their photos in deep, slow push/pop layers, that should be their mistake to make, if they so choose.

4) "We are concrned with 'feature bloat'."

I'm going to make this counter-argument short and sweet. "Nested nodes / arbitrary hierarchy" is not feature bloat, at least to your customers and their customers. On the contrary, the way smugmug currently manages categories, subcategories, and galleries is the very essence of confusing feature bloat. And, paradoxically, "feature limitation". (Aka more simply put, just poor design choice.) As further argument:

• You can't move a "node" somewhere else, and have its children follow! (Much less move it up or down in the hierarchy.) How crazy is that?
• We (your customers) may know that they are "categories", "subcategories", and "galleries"...but our customers don't know what they are, nor do they care. All they care about is being able to drill down, and pop back up (as that is the only direct navigation metaphor offered), like any other FIFO stack from of navigation they are accustomed to on the web. For all they know, each level is exactly the same kind of "thing"--that is, if they cared to think about it...which, they don't.
• Everyone already knows how to work with nested folders. You can't really use a computer at all without the basic concept...not to mention that hierarchies and related concepts (parent/child/sibling) are ubiquitous in nature and society.
• We've got to understand and agree on this, and quit propagandizing the opposite: The current smugmug gallery setup and management screens would be vastly simplified by using arbitrarily nested nodes that are all the same type of object. As it is now, there are countless screens devoted to the convoluted management of categories, subcategories, and galleries--each with their own behaviors and way of managing. Why? Why not just have one way to manage it all: a node manager.
  • Note: I don't mean to imply you--smugmug--are purposely obfuscating and propagandizing the issue. I tend to believe that you have latched on to your own concept (understandably after having spent years developing and refining it), and are unwilling to seriously consider alternatives. As a result of that, your communication with your users looks like "1984"-ish propaganda. ...At least to me.)

5) "Have you tried using keywords and smart galleries?"

Actually this argument works much better when turned around. Keywords and smart galleries are a great way to consolidate photos from a wide range of folders, including deeply nested folders. I use this very metaphor with my files on my own network. In fact, your customers might very well choose keyword links and/or smart galleries to be the only way to present their photos to their customers, even though they organize their photos administratively in deeply nested folders on your site. When this argument is turned around, the onus is then on smugmug to explain why users couldn't ameliorate smugmug's fears of nesting, by providing navigation with keyword links and/or smart galleries.

OK Jim we (smugmug) are sold. Give us a high-level features/solution brief!

• Data model
  • There is only one "node" entity type, with these basic attributes:
    • ID
    • Name
    • Parent node ID. (Each node needs to know which node it belongs to [unless it's the--or a--top-level node].)
    • Inherit attributes from parent?
    • Virtual node ID.
      • Allowing one or more nodes to be mapped virtually to one or more other parent.
      • Similar in design and function to "junctions/reparse points" in NTFS, hard or soft links in Linux, shortcuts, etc.
    • Hidden? (Can still get to publicly but need to be told name/URL...as unlisted galleries work now.)
    • Password protected? (Or a more complex ACL model but hopefully one based on common, proven models.)
    • Smart gallery tag search list
  • Your existing model would need to be tweaked to map photos into this model, in one of the following generalized ways:
    • Include all attributes of a photo entity into the node entity. Not very modular or efficient.
    • Add a node ID field to your photo entity, to map unique photos directly 1:1 to unique nodes. In this way the photo/node mapping would serve as a proxy, allowing photos to behave exactly like any other node (in both attribute management and UI behavior), in addition to the photos having their own regular photo attributes that only belong to the photo entity.
    • Add a parent node ID to your photo entity. This would be the simplest, and possibly (but not necessarily) the easiest/quickest to build a UI for, depending on how you do things now.
• User Interface
  • With just one or two main object types, it seems to me your application model would become significantly simpler and easier:
    • For smugmug to maintain and enhance.
    • For your direct customers to manage and administer.
    • For the end users to use.
  • The highest node (or sibling nodes) in the hierarchy that are not hidden or password protected, could be exposed by default, in a default section on the home page (a section which your direct customer may reorder, hide, and/or style as they can currently with other home page sections).
  • Alternately or in addition to, your direct customers may embed one or more node icons in other sections (e.g. header or bio...or for heaven's sake provide an arbitrary and unlimited number of "free-form HTML" section and whole sub-page types). This would be accomplished via an embedded tag in HTML that smugmug intercepts while rendering (or whatever other embedding method you might be using). At your users' discretion, this might be a single top-level node icon, or multiple node icons pointing to different arbitrary branches in the hierarchy.
  • Rather than having a large number of screens and a limited and cumbersome process to manage categories, subcategories, and galleries--ditch that and provide (or offer in parallel as an opt-in) one simple, admin-only, tree view for your direct customers. Doesn't have to be fancy or pretty, because the end users will not see it.
  • Custom hyperlinks to keyword searches, and smart galleries would work the same as they do now.
  • The representation of folders (categories/subcats/galleries) for the end user could remain the same as now, until a beautiful, super end-user-friendly tree navigator could be rolled out. (Which your direct users may optionally include in their interface for their end users.)
  • WebDAV access to this hierarchy, so that your direct may quickly and easily upload photos right from Windows Explorer / Mac Finder / Nautilus / etc., and/or very easily keep their photos in sync with their own local hierarchy. (Including updating IPTC metadata locally with their own favorite, more powerful local keyword tool--and then simply overwriting the remote files. Smugmug already generates keywords from IPTC keywords, why should an insert via WebDAV be any different than from any of the other upload/update methods?)

Since this "new" model would be a superset of the existing one in terms of flexibility and capability, it would be relatively straightforward to migrate your existing customers' accounts to the new model, with it being completely transparent to the end user (if not also to your direct customer albeit with some additional work to mimic the old model management screens for some temporary transition period). (And if you also implemented a continuous release model, the change could be made--no matter how severe the change to the underlying data model, framework, and/or code--without a moment of downtime.)

Look, this is just my opinion as a businessperson and entrepreneur, but the only argument that really should matter is this: I don't pay smugmug $200 something per year to have a smugmug-branded site with a look and feel consistent with smugmug, or other smugmug users. (I use Picasaweb for that kind of simplified and branded experience.) I pay for a smugmug pro account for photo hosting. I work hard to provide a look, feel, and navigation style consistent with my other sites, not smugmug's. The lack of hierarchical navigation, if even as an "advanced" option, impedes that effort.

I hope this helps.
-Jim

doublemeat

Oh, forgot to include the most obvious option for expanding the current smugmug data model to work with nodes: an intersection table. (Many nodes to many photos.)

Andy

We actually want to do this Thanks for your thoughtful post! I'll make sure the right folks see this.

doublemeat

Thanks and that's good news! :-)

Malte

doublemeat wrote: »

... Surely one or more of these points have been made but hopefully one or more are "new" or more succinctly put...

Now that's a feature request! D

Malte