Usability improvements

Goals

• Improve the Merengue admin index usability.
• Define how many management actions should be done in public interface.
• Improve the content management usability.
• Improve the visual block reordering.

Improvement proposals

Merengue admin index improvement

Actual screenshot

Problems

• Merengue should focuse the more frequent action: content management.
  • Other actions like role management is less frequent.
  • Some plugins has content management inside its admin interface.

Proposal 1: change admin index to a tabbed interface

• Default tab will be "Content management" tab.
• Other tabs:
  • User management.
  • Site configuration.
  • Plugins administration.
• The multimedia block will be inside "Content management" tab.

¿About editing actions in public or admin interface?

Problem

All edit actions will be by default in admin interface, separating public and admin view. Other CMS like Plone does not split management and the public site, but now are switching to split those views using deliverance, because these two reasons:

• The efforts to make a good look&feel mantaining all usability (for managers) inside this skin are enormous.
• You have a lot of flexibility and independence when creating a fancy public interface.

In Merengue we have decided to split both views, based on same idea in Django interface (and using its code as base code). But there are some features that will remain in public view:

• Feedback from users (comment).
• Visual block reordering.
• ... (( complete ))

We have to define a "law" for in every new feature, decide if should be in admin or public interface.

Example doubts:

• ¿Where is the user preference view? I think should be in public view.

Proposal 2: to be completed

(( to be completed ))

Content management usability

Problems

1. For a section, the child contents are not usable, and we mixed section childs and other stuff. Look at this screenshot:

2. If you click away in a admin change form view, you will not save the content.
3. Translation forms are very long because the translatable fields (look at  this example), but usually content is created in only one language.

Proposal 3: Avoid to click away in a content with a confirmation popup

• Problems related: problem 2.

Like plone does. You have to detect any modification action in a form field and ask for confirmation to the user, with a message like this:

Are you sure you want to navigate away from this page?

Your form has not been saved. All your changes will be lost.

Press OK to continue, or Cancel to stay on the current page.

Proposal 4: Separate section child from rest of section related admin

• Problems related: problem 1.

Implement a ChildrenAdmin to let plugins add new contents inside a model. This will be similar to RelatedAdmin with different semantic.

The plugin configuration would be:

from plugins.foo.admin import FooModelAdmin, BarModelAdmin
from plugins.foo.models import FooModel, BarModel

class PluginConfig(Plugin):
    ...
    @classmethod
    def section_models(cls): # section childs
        return [(NewsItem, NewsItemSectionAdmin)]

    @classmethod
    def related_admins(cls): # other related admins
        return [
            (FooModel, FooModelAdmin, Section),
            (BarModel, BarModelAdmin, Document),
        ]

Proposal 5: Change translation widgets

• Problems related: problem 3.

Look at this plone translation product:  raptus.multilanguageplone, or see next screenshot:

The translatable widgets are viewed using same space, because in 90% of the sites editors only creates a content in one language.

Proposal 6: Put related admins in a tabbed interface

• Problems related: problem 1.

The final results will be similar to this screenshot of  djangolfc:

The related admins will be:

• Edit, the change form.
• Children, for all section children. It needs to implement a ChildrenAdmin, to control all child types. See proposal 4.
• Permissions, that would be also a related admin.

The children related admin will list all the actual contents which are addable into this content. This improves usability because it split child contents (and content management) and other things like custom css, permissions, etc.

There are two problems with tabbed interface:

• If we implement the proposal 1, there will be two tab levels. This could be ugly, and we have to find a good look&feel for that.
• Plugins can add new tabs (related admins), and we have to think in tab scalability. The way to solve is limiting a tab number and when this number is passed, put a "More" tab, with extra tabs in drop-down menu.

Implementation note: The tabbed interface will cover to main-content DIV.

Visual blocks reordering

Problems

1. There are three kinds of blocks reorderable independently, but many times are in same place, like this:

   {% render_blocks "leftsidebar" %}
   {% if content %}
      {% render_content_blocks "leftsidebar" for content %}
   {% endif %}
   {% if section %}
      {% render_section_blocks "leftsidebar" for section %}
   {% endif %}
   

   This causes to have three blocks container where place blocks, and the resultant is to have three places for every block movement. Look at this screenshot:

2. The block place is not showed when you move the block. Then you cannot recognize the block place in admin interface.

3. Every blocks need to have a description for know what is it.

4. The UI effectiveness depends a little on the active theme. For example if all the blocks are floating, the border in its block container will not visible, because the blockContainer have no dimensions.

Proposal 7: Hide block containers when the block you move don't match the type

• Status: done.
• Problems related: problem 2.

If you look at previous screenshot, you will see blockContainer for plain blocks, content blocks and section blocks. If for example you are moving a contentblock (like feedback) Merengue should hide blockcontainer of plain blocks and section blocks.

Proposal 8: Provide an show a description for every block

• Problems related: problem 3.

Create a description in BaseBlock and show it in admin interface.

Proposal 9: Show "drag here" when block container has no dimensions

• Status: done.
• Problems related: problem 4.

When you have all blocks as floating in a block container, its dimensions is zero. Then you cannot see the border and you cannot drop other blocks in the middle of this container.

You have to add "Drag here" text when the container has no dimensions.