MODx UI Wish [split from: Treasure Chest 2: Scalability vs End user convenience]

Quote from: BobRay at Aug 14, 2008, 03:43 PM

I sometimes wish for a WYSIWYG tpl editor with a drop-down list of placeholders, though, and I’d love to see a tool that would let you type in a Ditto or Wayfinder call, click a button, and pop up a window showing the output. And a GUI that would build a basic snippet call for you (that you could edit later to fine tune) would be be great for MODx newbies (much like an SQL query builder) both as a learning tool and as a way to eliminate the common beginner errors around backquotes, missing ampersands, etc.

Someone could probably make a GUI for Ditto/WF pretty easily that hooks into TinyMCE, and would be like a ’Insert Ditto Call’ with a popup GUI.

Of course, you’d have to learn TinyMCE coding...and make it dependent on TinyMCE and Ditto/WF.

Quote from: BobRay at Aug 14, 2008, 03:43 PM

I sometimes wish for a WYSIWYG tpl editor with a drop-down list of placeholders, though, and I’d love to see a tool that would let you type in a Ditto or Wayfinder call, click a button, and pop up a window showing the output. And a GUI that would build a basic snippet call for you (that you could edit later to fine tune) would be be great for MODx newbies (much like an SQL query builder) both as a learning tool and as a way to eliminate the common beginner errors around backquotes, missing ampersands, etc.

The bottom line, IMO, is that you never really know how much a GUI is worth to you until someone builds it and you try it out.

A drop down list of all the parameters available for a snippet would be great, with fields and/or drop downs for values, along with a note about the paramaters’ function. It would be a snippet builder in essence. We feel we need something like this for our clients (who are not idiots but at the same time, do not need to be PHP/XHTML/CSS programmers). The level of complexity would be optional. Take eForm for example. That, together with a form builder would be wonderful for clients who need to create new forms and templates for forms could be created and packaged or downloaded accordingly. Some of the stuff in Concrete5 for example is pretty nice. But again, it’s not an either/or situation, it’s a supplemental feature that could be of use to those maintaining the site, rather than have their web developer have to come in and create new forms each time they need one. Some of the GUI stuff in concrete5 for example, is very nice.

I personally love MODx because of it’s modular structure, the fact that you can use straight CSS for what people call templates or themes, and the wonderful community support. Getting the absolute fundamentals down is absolutely the right thing to do, but some secondary elements would be nice, such as a Snippet builder.

rx2, splittingred:
Can Read about the power of xPDO?

Can correct me if I am wrong:

You can create endless tables in phpMyAdmin and export them as XML.
Or from a structure already armed, another CMS, etc..
Apply reverse engineering for tables with a code already set up, now would be objects and classes as an HTML CSS.
Apply relationship to objects and classes, which would make it ideal as the image that got an example.
Build forms for data entry.
Add code for custom applications, accountants, sums, calculation of dates, etc.. And consultations, high and low amendment also added the example of phpMyAdmin.
Define custom templates for objects.
Defining the output to Modx or a Smarty template.

And harness the power of cache on objects, which ofrese xPDO.

A form builder would be nice, I agree. I just think that a GUI for snippets would limit what you could do. It may make it easier to do the simple things, but would really get in the way of going beyond.

As for adding snippets via a wysywyg, I think that you are confusing MODx for a ’site builder’. I do not want my clients or content editors to be messing with snippets. I consider snippets as development tools.

You can easily provide options to add snippets to content in various different controlled ways, by using TVs and logic snippets (or phx) if you want to. The article on using a tv to select what chunks to display, that is in the wiki, illustrates a way that you could easily create an interface for adding snippets to a page in predetermined spots.

Yes, we use TV’s for some snippet functionality but some of our developers find it incredibly tedious to do the &whatever=`` thing, look up all the parameters, recall all the parameters, etc. and build them into, in some cases, huge long calls, but it’s clearly a matter of preference. I’m not advocating one way over all, just another optional aspect.

As for limiting what you could do. I really don’t see it if you allow either method. One does not cancel the other out or vice versa.

Definitely not confusing MODx for a site builder, it’s a content management framework. As for clients messing around with snippets, that’s easily controlled. You can lock away those that are not to be touched. The line between development tools and production tools is a fine one I suppose, and different people draw that line differently. I’d love it if my clients could easily login and change the email message that is sent out from a particular form through a forms manager type page with a nice interface. Of course we teach them how to edit the chunk but the chunk page, we’ve found, isn’t particularly friendly for some, nor is the term chunk.

+1 to form builder for sure.

Not so sure about a GUI for a snippet call thing ... tons of decisions to make there, but you could probably do code-completion libraries for things like eclipse with snippet syntax/parameters baked in.

Quote from: rthrash at Aug 14, 2008, 05:53 PM

+1 to form builder for sure.

Not so sure about a GUI for a snippet call thing ... tons of decisions to make there, but you could probably do code-completion libraries for things like eclipse with snippet syntax/parameters baked in.

Perhaps with options type HTML editor with auto complete with the correct syntax would be a great help.

You can use config files to keep the long calls under control (or wrapper snippets).

And you could easily create a module to allow editing settings like email addresses or messages. Modules seem a bit tricky but with them you can add some very cool interface enhancements tailor built for you r projects. I just figured out modules recently and it opened up a whole new avenue for adding interface features. It is worth checking out.

I understand your points, they do make sense.

Quote from: rthrash at Aug 14, 2008, 05:53 PM

+1 to form builder for sure.

Not so sure about a GUI for a snippet call thing ... tons of decisions to make there, but you could probably do code-completion libraries for things like eclipse with snippet syntax/parameters baked in.

Code-completion would be nice too. I’ve just found some of our developers (and we all have different personalities and preferences) respond to a nice visual summary of what the snippet is doing rather than a series of &property blocks linked together. So I’d have to say it would be nice for those types and not even clients necessarily. Just a different way to work that some other CMS’s offer.

But on the client side, take typical things like adding Flash movies, be they videos or traditional .swf content (and yes I know one should avoid Flash at all costs but that’s the beauty of SWFObject, the alternative content). You have to remove the nonsense from FCK/TinyMCE as it buckets out of date as a method for embedding Flash and setup TV’s for the SWFObject snippet, make sure the snippet call is in a chunk or the template so it doesn’t get corrupted by the RTE (and turning off the RTE is not an option since the client wants to update content without knowing HTML) and make sure the chunk is in the correct place or they’re taught how to place a chunk in the area they wish to put new Flash content in.

If the snippet had an interface that the developer could control to lock off certain parameters if necessary, then when the client gets the latest Flash and alternate content, press a button to insert the Flash content, input the name of the swf into the appropriate box, input dimensions if necessary, input the name of the alternative content or input the alternative content right there, be warned if they miss inputting the alternative content, preview it, and then they’re done. The developer doesn’t have to create a TV for each parameter, which saves time. The client can have their Flash guy do his thing, their designer guy do their thing for alternate content, and use the CMS to put make it live in a simple way.

As it stands, we’re just going to build all these sorts of things ourselves which is a great thing about MODx and we have a project that has the time and budget to it.

As it stands, we’re just going to build all these sorts of things ourselves which is a great thing about MODx and we have a project that has the time and budget to it.

Keep us posted on how it works out, sounds interesting.