See the proposed moveBefore API [1] which is meant to solve those issues at the platform level. In the meantime, htmx has their morphdom extension, which I’d say is a must when replacing any page content with interactive elements within. Aside from that one major gotcha, the main issues with htmx are the poor accessibility of the examples in the docs [2]. In particular seeing so much ARIA without the corresponding keyboard support.
Thanks for chiming in! Do you think it’s desirable for it to stay "ugly" then if it’s for "internal use"?
I can understand the admin isn’t meant to have a "consumer" UI but it still feels like there are lots of user experience & accessibility improvements needed to bring it in line with modern standards (WCAG for example).
I see three quotes from past contributors in the article, that seems like valuable knowledge to me? Anecdotally as someone who contributes to the Django admin I see the interest is there. I’d say it being clunky is for other reasons (for example there being more back-end developers contributing to the project than other skillsets).
Text contrast is actually one of the most common issues with the Django admin. Just on the screenshot in the article, the white text against the light blue breadcrumb and nav headers background is too low contrast as per WCAG 2.0 calculations.
Yep, the different button styles for no clear reasons is one. This is even more apparent on other views. On that screenshot, you can also spot questionable alignment between e.g. checkboxes and the title text in the table. Contrast issues with text against different background colors. And I’d also question whether UPPER CASE TEXT is necessary.
It is certainly simple but I’d disagree it’s functional _enough_, because of the numerous basic accessibility issues with the fundamental UI components.
On extending the admin – perhaps there’s something to be said about the admin coming with more UI components built-in? For example it lacks any dialog / modal window implementation, or an "accordion" / disclosure pattern. Or things like support for keyboard shortcuts.
"Ugly" might not be the best one-word description but there are a lot of basic accessibility issues with the Django admin. The general user experience could also really benefit from using more modern design patterns (for example modal windows over pop-up windows).
I’d say because you can lose context more easily when having to move to a separate browser tab / window to complete a task? And I suspect the multi-window paradigm is also harder to navigate for keyboard / screen reader users (as opposed to an in-page modal which correctly captures the keyboard focus while open).
Is that a real problem for professional users or just a kluge to work around the ever-decreasing IT skills of today's generation that can no longer do basic things such as window management?
I think an OS-managed popup window is superior to a page-managed modal since it allows you to move the window out of the way or even switch away from it, where as a page-managed modal is generally fixed in place, blanks out the parent page, and the only way to get back that parent page would be to dismiss the modal which discards your input.
I'm also not sure whether the accessibility concerns are substantiated - surely window management would be a well-trodden path for any screen-reader user and whatever you build yourself in-browser would have different and unexpected semantics that would require the user to get used to it.
Sorry I’m not sure I understand your question? I wasn’t on the internet before web 2.0, by modals I mean things like custom-styled <dialog> element[1] and the `dialog` ARIA role, which I would say are a more recent pattern than pop-up windows. "Modern" might not be the best term here, I should have just said more "usable" perhaps.
The HTML <dialog> element is used to create both modal and non-modal dialog boxes. Modal dialog boxes interrupt interaction with the rest of the page being inert, while non-modal dialog boxes allow interaction with the rest of the page.
The modal dialogs are easier for the programmer to use but they're quite inconvenient because generally, they ask you a question you can answer only by looking at/interacting with the rest of the page. Which you can't do (the modal dialogs on web also almost never can be dragged around).
The term "modal" pre-dates <dialog> by a huge amount, and generally refers to a popup within the same window that prevents interacting with what's behind the popup (I believe the term comes from how you "change modes" when it appears). On the web they used to be implemented using <div> and CSS, often with some sort of javascript library so you didn't have to do it yourself.
I think you remembered it wrong. Going from pop-ups was earlier than modals. Pop-ups were supported by things like window.open() which has been around forever (perhaps NetScape 2.0?). In contrast designing a modal requires some slightly more recent CSS like absolute positioning (I believe CSS2 so still within the previous century).
I’d be really interested in this as well (disc. – I work on Wagtail). This feels so similar to our vision for the CMS aside for the fact the project has been running for a while and is in Python land.
Wagtail core developer here – here are our sprint notes [1] that demonstrate what this funding means for us in practice. The TL;DR; is being able to address long-term technical debt in the UI, improving accessibility throughout, having proper UI customization capabilities – as part of a redesign & new features.
[1] https://htmx.org/examples/move-before/ [2] https://github.com/bigskysoftware/htmx/issues/1431