Forum for discussing general topics related to Couch.
34 posts Page 1 of 4
I've been working with couchCMS for over a year now, I've developed many sites from basic to complex and I really enjoy creating a couch site because you know you get to focus on designing without limits rather than worrying about what constrains the CMS you're using has.

This is one of many reason I have decided to further dig myself into couch and learn more about it. However, I do have some issues with couch that I feel need to be addressed in order for the CMS to really become popular and a viable choice.

Let's start with biggest first:

1) The admin panel. I know there's a re-design (looks beautiful) in the works for the next release and I've seen Cheesy's design. It really does look good and will bring couch forward - however there are still some issues that were not in my opinion adequately addressed. As somebody who allows my clients to login to couch and edit their website content (as they wish), they find the admin panel difficult. This isn't because it's not simple, it really is. But maybe it's too simple.

What I mean is, it's so simple that it becomes difficult to work with. Every template is listed on the sidebar and while you look at it from a small site standpoint, that really is okay - just a few links that allow you to manage your few templates easily. Well, what happens when you have upwards of 10 templates is that you have a very cluttered sidebar full of links to each and every template, not only this but those links click through to largely the same view of each page (Though this isn't really a con, it can become confusing).

Going back and forth between templates and cloned pages lists isn't so simple for my clients because the lists and the links are all largely the same (even when I've shown custom info on those lists). Also, this means the sidebar is full of links and often becomes difficult for them to use easily.

The new admin panel sorts out many issues with the current one: Mixing of templates that have seperate purposes like "Global Settings" "404 templates" etc, but it still lists every single template on the sidebar, which for larger sites is not good.

In my personal opinion, listing of the sites pages/templates should be on one page, not the sidebar - Within the new admin panel (Seen here) The "Miscellaneous" and "Administration" fieldsets are great - they offer distinction between the sites templates and the sites management. I think they should stay there however putting them under an expandable dropdown arrow would greatly improve the issue of too much information for those end-clients to see, which helps them navigate to the pages they want to get to.

One page for the listing of all of the site pages would help with user navigation, too. Mainly because it allows them to click through to a page showing them a list of templates, this table/list can display more than just the templates name, too. Which is another fallback - Just having the name is great for small sites but once you have 10+ templates it becomes difficult to find your way to where you want to go. Listing templates on one page allows users to see more than just the template name - the list could show the page title, the pages url and other information (as required).
Users would be landing on this page when they log into the admin panel, too. Which is very helpful to them - often times my clients site doesn't use nested templates and they login and find themselves on the edit page for the home template, this confuses them (and me too, sometimes) because they aren't always looking for that page. Being shown a full list of templates and some more details of each template helps them to figure out where they're going. (Look at wordpress: Although their admin panel is far too cluttered, the listing of the site pages is very simple).
Cloned templates would click through to another list of all the pages in that template - clearly showing the user where they are (through breadcrumbs e.g. "Templates > Blog" helps them understand where they are and where they've come from in the confusing admin panel.

Now, I know that I've written a lot here - and I know that creating front-end admin panels is almost upon us but, just a few small changes to the new admin panel could make it very simple to use for everyone and really improve the push that we can give to our clients to use couch and its admin panel to manage their site.

Also, I feel that some things could be better managed via the admin panel, rather than via config files. I don't have a problem with the config file myself, it's very easy to use but often times my clients want a content management system that lets them manage the site a little more than just it's content. This means being able to turn on maintenance mode (for whatever reason), or updating their paypal email address, or redefining the interval between comments. We don't need 5 different setting pages that let users manage the entirety of the site with no developer input and allows them to change everything. There is a fine line between functionality and complexity. But I feel that in some areas couch pushes to be far too simple. Far too bare-bones. It could benefit greatly from these things, allowing the end-user to change the comment interval because their new blog article is getting more comments than they expected and they wish to turn up the interval, it's a simple thing for the developer to fix but often times they want more control over the site than couch allows.

2) (Oh god, he's still rambling)
Couch is really wonderful at what it's designed to do: allowing developers to create a fully CMS'd website without writing a single line of PHP. While I understand exactly why KK doesn't do so, not having developer documentation makes it very difficult get into developing couch addons, which the CMS could benefit hugely from. I'm sure there are many more than just me on the forums here who would love to dive into addon development for couch.

3) User management and Access control is lacking - while extended users is an extremely useful addon that allows us to create user registration with some management on sites, we still cannot create, edit, or delete user roles. Not only this, we can't assign which role the extended users are by default. This is one of couch's few use-case difficulties and I'm sure it's well known, but as I'm listing the things I think couch needs most, I've listed it here.

4) Post drafts (I saw in Cheesy's new admin panel a page for drafts, so it's possible KK is already developing this) Creating unpublished pages allows us to mimic draft functionality when making a new page or post (Although explaining this and how to use it to end-users is difficult), editing already created pages means you must save your changes before you can see them on the page. This is a bit of a drawback when your client breaks something and has already saved the page, it requires either restoring from a backup or remaking the lost/broken data. Page drafts would solve this problem.

5) I know this one is going to be improved with Redactor (Thanks, Musman!!) But it needs to be said anyway - I HATE THE WYSIWYG EDITOR! It's a nightmare for me to create pages, let alone when my clients do it too! Random span tags with their own font colour and line heights are a nightmare and I often spend more time reformatting the editors content via the source tab than I do writing the pages content! My clients have it much worse, I've had a few that have pasted text from elsewhere and that is an even bigger nightmare, explaining to them how to use the "paste without formatting" option is very difficult. It's possible there's fixes for this already and I haven't looked hard enough (maybe pasting by default can remove all formatting) but it wouldn't fix the random spans placed everywhere. It's the worst. In fact, it's the one thing that makes me happy to work on a wordpress site from time to time!

Anyway, I've ranted a lot - I hope my ranting has helped with ideas, I really do believe the new admin panel can be improved further to be more user friendly. I look forward to writing more couch addons in the future as I delve deeper into the CMS' core :)
Image
I can agree with you, that said.. the most important things i need in couch are :

- native multi language support
- a way to turn on/off search on editable fields

Maybe someone could write some instructions to :

- create your on admin panel
- write plugins for couch
I load frameworks and write bugs on top of them, after that I rearrange the code so that it looks like a cool product.
hi Dave, the award for the longest ever posting on this forum is yours! I read it with great interest and agree with the you re the Admin Panel, you make some good points. I have just done a medium site (in my terms) and find that the sidebar list is starting to look unwieldy and difficult to scan and find a single link. For example I have an events template along with events categories and events offers - it would be great to have a single item EVENTS where these could be grouped leading to an Events management page. I am liberal with my advice to clients in the AP and would love to see help icons with hover pop-ups as an option. I know that the AP will be addressed in the next release of Couch - hopefully sooner rather than later!

And addons/plugins presented in an organised/categorised/searchable way (with ratings, endorsements, reviews?) would be great. I am about to do something for a site for a YouTube video embed in a lightbox - I will cobble it together from some existing code where I have these elements. But it would be good to have a repository of good and easy to apply such functionality.

I love working with Couch - it wouldn't be an exaggeration to say it has opened up whole new possibilities for me - and @KK is awesome - a powerhouse!
@Tomarnst

Native multi language support is hard to implement for many reasons but I'll list just two:
1) There's no easy way to incorporate it with the current admin panel/editable regions.
2) Even if it could be implemented, it would surely add multiple regions per language the user wants (As every text/editable would need to be inputted once per language) So even 1 extra language makes the entire admin panel twice as large, can you image having 5 of the same richtext editors for one block of text on a page, in 5 languages? It would be mayhem!

It is possible to add multilingual support with couch, but it uses methods I mentioned above by ways of creating an extra editable for that language. So if you have one richtext editable, you'd need to double that to allow for the second language. I see no easy way to avoid that huge clutter, I'd love to hear some solutions to that though!

What do you mean by "- a way to turn on/off search on editable fields" ?? I'm not sure I understand


@potato
Thanks! Yes, that is one of the specific issues I've ran into multiple times that made me realize how quickly the sidebar becomes difficult to navigate. I've had several templates for events (in 3 separate locations, each a cloneable calendar). This becomes difficult to distinguish and navigate for the user who has to create calendar events every month. If those were grouped into "Events" and then the templates inside of events shown, that would even be an improvement on the current list.

Though, I still think a single page listing the templates with detailed information is better (but could do with having template groups).

Another very good example is the use of related templates, we often use them to offer functionality to one main template. I have two examples on my own website of this: One being the support system I setup for clients to open tickets, this has a related template for comments on each ticket. Another (probably better) example is the very common blog template.
The only current way to create taxonomies is to use a related cloned page, each page being a separate tag. My client needs access to both of these templates (The blog to create posts - ofcourse.) and the "Blog Tags" template, for when they wish to add/remove tags. It's very confusing for them to have both links on the sidebar, you can place them next to eachother but that's the most you can do in the ways of coupling them together, but it also fills the sidebar up. Not to mention that template is not a 'Main' template - it's not a page on the site itself, so does it deserve to be alongside them in the sidebar?
We use dummy templates a lot in couch to create advanced functionality, and it lets us be creative and construct advanced functionality with just the basic tags, but they also add clutter to the admin sidebar. They may need to be accessed at some points, but not nearly as often as those main templates.
Image
... interesting - could you give an example of your usage of 'dummy' templates?
potato wrote: ... interesting - could you give an example of your usage of 'dummy' templates?


Again for me, the most relevant I can think of (bear with me, I haven't been to sleep yet!) is a client I setup a site for a few months ago. (Read about it here) He lists contractors on his website, each contractor has a cloned page listing his/her details, some of these contractors offer more than one of his desired filters for "contractor types" - One contractor may be "Painters and Decorators" but that contractor may also be listed under "Tilers". The important thing to remember here is that each contractor can have many types, and each type will of course have many contractors. Couch relations was perfect for this, we could create that relation easily and tick any contractor type that fitted when adding a new contractor page.

However, we had to use a second template for this, displayed in the admin panel as "Contractor types", this template is clonable and has only 2 editable regions - both of them are icons. Each type has two icons (one black, one blue). The template itself isn't executable, it has no code below the <cms:template> tag, it's a "dummy" template created to achieve specific functionality. Although we could've used the template to create list-views for each contractor type (listing only contractors in that type) we instead opted to use custom routes on the main template file, allowing us to manipulate the URL to our needs, optimizng the sites SEO.

So, this template in the admin panel needs to be accessible by the user, if he ever wishes to add or delete a contractor type from the site, or change the icons of an existing type. But it has no output on the front-end, it's not a page with richtext editables that are output to the front end, it exists solely to provide functionality to the contractors template. Essentially it should be a "childof" the contractor template it provides functionality to.
Image
ah yes, lots of post-election sleepless-night folk around today ... thanks for your explanation Dave, I see what you mean - this is how I have set up categories too.
@ Bartonsweb

What do you mean by "- a way to turn on/off search on editable fields" ?? I'm not sure I understand


All editable regions are included in the search results. So when you use the search on the frontend also data you won't like to show up will be displayed. Can you imagine when I have a product catalog with editable regions in the template like Supplier, buying price, my markup on the product and so on I won't like to have this info presented to my visitors of the site.

There's no easy way to incorporate it with the current admin panel/editable regions.


I'm not sure if things get unmanageable when having a support for more then one language as long as only one (the selected one) translation is shown on the admin side.

Added to the couch fields table a column lang-code and adding a table translation then a query to match those could be something.
I load frameworks and write bugs on top of them, after that I rearrange the code so that it looks like a cool product.
Thanks everybody for taking the time to pen down your thoughts.

It is a very interesting thread (I've taken the liberty to make it sticky for making it easier for others to chip in) and will definitely help in guiding Couch's development.

The most pressing concern seems to be about how the sidebar is structured.
The 'grouping related templates' part is already covered (though, perhaps, not obvious in the demo you linked to). Consider the 'TEMPLATES' and 'PAGES' groups shown there as user-defined (i.e. you can have any number of them with any title) where the templates shown below them are also user-configurable.

I think that should satisfy a part of what is being asked for.

The groups are, however, not collapsible in the original design.
Perhaps @cheesypoof would like to address this?

A user-configurable option to set the default status (collapsed/open) of the groups should be helpful too, I think (but this is not a design issue and will be handled entirely in code).

Would these two changes help in improving the manageability of the sidebar?
@KK

Ah, yes the mockup didn't illustrate that, in fact I had guessed it was a separation of cloned templates and non cloned/nesteds by the example.

Creating our own sections will be helpful (especially if we can choose to have them all closed, expandable sections).

Though, ultimately there will still be the issue of larger sites having too many templates. Once you get above a certain number the sidebar becomes very full and will always be somewhat difficult to navigate. Which is why I suggested a page for listing the templates > because it has added ability for being much more expansive.

Picture this for a second - you have your blog clone able template. Inside of that template you have a few tabs above it (for example, add new, manage folders). Now we have a related template to the blog for blog taxonomies. Being able to remove from the sidebar and add to those tabs on the template would allow us to flow the templates in a much more manageable way > adding blog tags would feel the same as managing the blogs folders.
Being able to put a template as a childof xxxxx template would allow it to fit properly into the hierarchy in the admin panel. Perhaps an added option of removing it from the sidebar so that important child templates can be placed in both the parent templates tab list and the sidebar, so it's fully configurable by the developer.

I do like that the sections will be configurable though, that will greatly help the problem I agree. But I think it could go a step further to be truly friendly and easy to use for non-developers who have to also navigate the panel
Image
34 posts Page 1 of 4