Cutesy snippet names?

I think it’s a little task to find "what the hell this Ditto-named thing does".

Objection! As a newbie who discovered MODx only 3 days ago I on the contrary can affirm what jbjones suspects in his initial mailing: I did not find out easily what this Ditto-named thing does! I wondered why this snippet? modul? plugin? is top ranged on the download listing, what this is about and was puzzled - annoyed in effect - by its description, which does not say anything about its basic functionality:

Description
Ditto takes advantage of an external class, language files to work with multi-language installs, and uses templates extensively for the ultimate in output formatting flexibility and control. And while it has more than 40 configurable parameters in it’s current implementation, you only need for great results (although telling it explicitly where to start probably wouldn’t hurt).

Read this Description with the eyes of a newbie who wants to inform himself what extensions MODx has to offer. I understood: Ditto is great, it is a must-have - but I was completely clueless what it is about. It took me 3 or 4 trials until I detected the revealing sentence (put in extra small fonts):

Ditto: the nimbler, faster, better-named and even more flexible offspring of NewsListing.

Ahhhhh!  Okay - I could have detected this sentence earlier but consider that web pages (which are cluttered with information) are scanned - not read sentence by sentence.

For the sake of user friendliness: Please provide an description to your extensions that states its basic functionality as clear as possible!

BTW: As a newbie I quickly learned that MODx uses snippets, modules, chunks, plugins etc. But its quite difficult to figure out what kind of beasts the downloads are. My suggestion is to clearly annotate the downloads as snippet, module etc.

I know, when you’ve been immersed in something as we have been in MODx for over a year now, it gets very easy to forget that "newbies" don’t have the slightest idea what we’re talking about. We do try, though!

And yes, I do need to rewrite that description. Thanks for reminding me of that.

Wow, sottwell, Mark, the fastest reply ever! 

when you’ve been immersed in something as we have been in MODx for over a year now, it gets very easy to forget that "newbies" don’t have the slightest idea what we’re talking about.

I do understand this very well. That has been the reason for my feedback.

Just a little suggestion:
The description of a "beast" should contain hints to what other (non-MODx) beasts it is comparable with. (could be more than one, of course). So, for instance, if the "addition" provides a functionality which can be found in Wordpress, it should be noted.
Would be useful if we could use a kind for "form" here. Would also be good for the "You and your sites" section: basically I’m not so much interested in how a MODx-site looks, since I know that MODx does not require a special kind of look: I would be more interested to know which additions are in use, if they were modified, how the calls look like in the template, if there are home-grown components, if database-tables were modified, how much time it took to set it up, how many webusers it has - and so forth.
This would also foster re-usability of MODx experience and solutions in the community.

Quote from: Mark at Aug 21, 2006, 07:35 PM

We have a policy of releasing software "when its done". Rumors are just that--- rumors. Not facts.

Software is never, ever, ever, EVER "done." You can however release incremental successes, like they do outside happy-modx-land.

And why call it Ditto? ’I don’t want to write a paragraph and have some stupid piece of code copy and paste my paragraph endlessly.’ Why not call it Publisher? It publishes content.

Why call it Wayfinder? ’I prefer Google Maps over other mapping software, plus I already have navigation in my car anyway.’ Why not call it Lister? That’s what it does, it takes things, and spits them out in a list.

As someone with less than 2 weeks of MODx under his belt, I think there are very good points on both sides of the fence.

Catchy names can be useful from a marketing standpoint, as long as...

• they don’t get in the way... CMS’s are notorious it seems for trying to give their own spin on things... blocks, mambots, modules... sometimes you need to simplify, and sometimes you at least have to provide good explanation and description on what something is if you give it a unique name... but there will always be differences in vocabulary, semantics, and perceptions.
• especially for items with unique names, very detailed descriptions need to be given... for those who have been working on these for awhile, they may forget that their purpose isn’t always obvious to world, even with a descriptive title... like the idea of having a list of possible uses, comparisons to others, and better yet, some detailed examples of common applications.
• beware name bloat... Drupal (my only other, and limited, CMS exposure) is certainly feeling the confusion, where even those deeply integrated are having a hard time distinguishing ThisName, ThatName, OtherName, DifferentName, etc. apart. This of course can be a concern with having logical names even more so than cutesy names and is really the other side of the coin, but this also seems closely related with....
• beware addon bloat... I’d hate to discourage independent development, but it also seems a risk of over-development, where you end up with 20 one-offs that all do nearly the same thing. For ease of use and maintaining, it would be great to see more "core modularity" (this coming from a designer, not a coder) where the best snippets become the foundation for other snippets that merely extend or modify the functionality of the core snippets. I think this is being done to some extent, just would be great to see it continue and be encouraged. This seems more like the MODx way anyway, just extended beyond the core code.

I think MODx is doing a great job in most of these areas, just room for improvement and also, as MODx grows in more popularity and attracts more and more people, all the better reason to have plans laid out and thought out ahead of time to before they become a monster to manage.

Software is never, ever, ever, EVER "done." You can however release incremental successes, like they do outside happy-modx-land.

You’re quite right - software should never be done and in happy-modx-land, we have betas, release candidates and minor and major version releases - perfect celebrations of incremental success.

On the names thing, I have to say that I don’t agree with your argument. Name generalisation, IMO, can be just as bad as having overly abstract names - for me, both Ditto and Wayfinder reflect the multi-functionality that is offered by both snippets without drifting too far into the realm of tenuous links between the names and the actual features on offer. What is important is that the names form associations and make them distinct enough that they can be remembered and referenced within the community. Having a pool of ’Publisher’ and ’Lister’ snippets floating around just isn’t going to help anyone.

Like identity says, you need to have descriptions as well (I wouldn’t install a snippet just on name alone, I’d like to know what it can do for me first). Where the functionality of resources starts to converge, I would definitely agree that developers should start looking at collaborating - the impetus there is with the developers but as a collective the community can certainly encourage it. Saying that, I certainly wouldn’t recommend, for example, merging all ’menu’ related snippets into one large ’swiss army knife’ of a snippet - most people won’t require the full range of functionality on offer and then it becomes unnecessary bloat. Having resources that can fit together and work in tandem, like piecing a jigsaw together, is how I see it but not everything needs to be part of the core - having a small core and the ability to import resources easily (easy as in one-click remote installs for example) when you need them is more ideal.

Using the swiss army knife analogy, MODx would actually be the swiss army knife while the snippets are the various tools that can be used.

I think one thing I would like to see improved is an easier way to browse the download repository section other than the Tag Cloud which is rather messy. The tag cloud would be easier if it were in columns I think. But second, perhaps all the core snippets/modules could be put at the top of the page for easier access. Or at least a "core" tag at the top of the page.

That last idea probably belongs in another thread.

having a small core and the ability to import resources easily (easy as in one-click remote installs for example) when you need them is more ideal.

I would really like to see this taken to the extreme, even having user management (except for the most basic manager user validation) extracted to modules and plugins. How many MODx sites are there that don’t ever use document groups or user groups at all, just a manager login to manage the content. Then the web developer could add whatever modules he needs: manager user groups, roles, and document groups for controlling manager access to various documents, if that’s all he needs; web users if he just wants a single web login system, web groups and document groups if he needs different kinds of web users. You don’t wear pinstripe wool jumpsuits, you buy shirts, slacks, vests and jackets to mix and match as required!