Admin UI has a set of CSS bugs, UX can be improved

[viktor-yunenko]

Apologies for raising it as a single ticket. My time is quite limited, yet I wanted to shortly publish a set of points that I'm going to handle on the next week within this fork. I'll try to submit it as a PR, although due to the time constraints most likely it would be a single PR as well.

Title and website select

The author select field

This input looks like it would accept an email, but there's no autocomplete and it rejects any email values. Its search button opens user model list - I was confused when I saw it. I thought that it was a bug, and some kind of select should be opened instead. As I later found out by an accident click the editor needs to click on a user model in the list. After selection the inputs shows a number - as a developer I understand why, yet it can confuse an editor.

Info section

Images section

Among the CSS bugs below there's the UX issue - image is one of the most important parts of a blog post, yet it's way below rarely used fields (sites, tags, etc) and hidden in a collapse class.

[yakky]

@victor-yunenko thanks for this through UX/UI check Just a few hints to provide an intiial feedback:

• author selection: it's the standard raw_id_fields django admin widget, I don't know how much it's worth to customize it
• css issues: admin css is limited to tag autocomplete widget, all the css layout is actually by djangocms-admin-styles, I'd rather fix the issues there instead of patching here, which is -according to my experience- really hard to maintain
• fields reorganization :+1:

I agree it's not worth to have individual issues or PR

[viktor-yunenko]

Thanks for the green light!

author selection: it's the standard raw_id_fields django admin widget, I don't know how much it's worth to customize it

In general I agree. There's that django-autocomplete (or something) package, with nice search and etc. Although so far I only got requests to hide the author field on the frontend, hence I probably wouldn't add it within the first PR.

all the css layout is actually by djangocms-admin-styles, I'd rather fix the issues there instead of patching here, which is -according to my experience- really hard to maintain

Indeed, I've been suffering from djangocms-admin-styles long enough :)

In short I would just set those fields to one column per row in ModelAdmin.fieldsets - that would already make them look better with minimal time investments 👌

[yakky]

ok, let's see how it looks, I would restrain from inlining all the fields as the changeform is really huge, so I think we should find a compromise, or coordinate an effort with angelo to fix the major issues in djangocms-admin-style

[viktor-yunenko]

Sure, to reiterate, my suggestion would be to simply replace:

        (_('Info'), {
            'fields': [['slug', 'tags'],
                       ['date_published', 'date_published_end', 'date_featured'],
                       ['enable_comments']],
            'classes': ('collapse',)
        }),

with

        (_('Info'), {
            'fields': [
                'slug',
                'tags',
                'date_published',
                'date_published_end',
                'date_featured',
                'enable_comments',
            ],
            'classes': ('collapse',)
        }),

[yakky]

after a second look, you are (rightfully) looking at 1.1 branch, in 1.2 we already inlined quite a few fields (https://github.com/nephila/djangocms-blog/blob/develop/djangocms_blog/admin.py#L127)

You probably want to check against develop branch, which I want to release as 1.2 very soon anyway

Plus you have unexpected failures due to the get_fieldset code (https://github.com/nephila/djangocms-blog/blob/develop/djangocms_blog/admin.py#L363) which adds or remove fields according to the configuration, and some tests (the TestAdmin.test_admin_fieldsets* ones) introspects the fieldsets structure to make check on optional fields

[yakky]

@victor-yunenko I am currently working on a documented and guided way to customize the fieldsets layout on a per project basis, I will post a preliminary PR soon, I think it will make your customization work easier and it will allow us to decide more freely which default layout to provide

[yakky]

@victor-yunenko see #621

[yakky]

@victor-yunenko I improved the custom tags css in #626

[yakky]

@victor-yunenko hi, any update on this? I would like to release 1.2 soon and improving the UX would be great!

[Honza-m]

To add to the discussion, this is a layout I've implemented in my project. It's by no means perfect, and some of the issues highlighted in this thread persist, but to me it's much more sensible than the current default layout. It can be implemented by simply updating the _fieldsets property and get_fieldsets function of PostAdmin.

(Note all categories are collapsed by default)