django admin: open popups as modals instead of windows

[Riccardo Magliocchetti]

Hello,

I've opened a ticket [1] to implement the popups in the admin as modal instead
of windows. I'm no UI/UX expert but modals are more or less the standard today,
windows looks like a relic from the 2000s.
Am also interested in decoupling the js from the admin to make possible for
downstream theme maintainers to use another implementation if they please [2].
So have been asked by Tim to ask feedback for the idea here, your opinions are
very welcome.

Rough, work in progress implementation here:
https://github.com/xrmx/django/commits/relatedcleanup

[1] https://code.djangoproject.com/ticket/24405
[2]
https://github.com/django-admin-bootstrapped/django-admin-bootstrapped/issues/103

thanks

--
Riccardo Magliocchetti
Software Tinkerer
@rmistaken

http://menodizero.it

[Florian Apolloner]

On Tuesday, February 24, 2015 at 3:23:23 PM UTC+1, riccardo.magliocchetti wrote:

I'm no UI/UX expert but modals are more or less the standard today,
windows looks like a relic from the 2000s.

That argument is based on what? I'd personally argue that windows are superior cause I can easily switch between the page and the window -- something that does not work with modals

Am also interested in decoupling the js from the admin to make possible for
downstream theme maintainers to use another implementation if they please [2].

Patches to make life for 3rd party easier are definitely on the table.

Cheers,
Florian

[Riccardo Magliocchetti]

Il 24/02/2015 16:18, Florian Apolloner ha scritto:
> On Tuesday, February 24, 2015 at 3:23:23 PM UTC+1, riccardo.magliocchetti wrote:
>
> I'm no UI/UX expert but modals are more or less the standard today,
> windows looks like a relic from the 2000s.
>
> That argument is based on what? I'd personally argue that windows are superior
> cause I can easily switch between the page and the window -- something that does
> not work with modals

Not really an argument, it's more an observation that ui frameworks like
bootstrap, foundations, etc.. usually have a modal component. In data entry UI
that may not be the case though but i have no clue. Personally I just want to be
able to use modals or whatever just by overwriting templates. I get that, I am
happy :)

[Stan]

 
On Tuesday, February 24, 2015 at 4:18:36 PM UTC+1, Florian Apolloner wrote:

On Tuesday, February 24, 2015 at 3:23:23 PM UTC+1, riccardo.magliocchetti wrote:

I'm no UI/UX expert but modals are more or less the standard today,
windows looks like a relic from the 2000s.

That argument is based on what? I'd personally argue that windows are superior cause I can easily switch between the page and the window -- something that does not work with modals

As the "helpdesk guy" for applications we develop and a "power-user" of Django admin, I strongly agree with Florian here.
The ability to open and switch to other tabs in the main window - which is not possible with modals, right ? - and to resize/move/scroll the popup window with native performance beats fancy modal windows IMHO.

--
Stan

 

[Marc Tamlyn]

I would suggest that a good modal implementation for these should still support "open in new tab/window" properly, with control/command click not detected by the overriding JavaScript. It may be possible to do this and keep the popup functionality passing the new id back to the parent window.

From a UX perspective, I have heard[citation needed] that modal windows are not ideal, mainly due to their blocking nature. However inline ajax loaded windows are much better. For "small" parent form objects, this would likely be ideal - click the plus icon, it reveals a 3-4 field inline form, fill that in or cancel it, by choosing an option from the dropdown etc. This concept of an inline parent form would be generally useful, I've written a few limited implementations but never had the time to consider all the edge cases to make a third party project.

There are definitely better ways to deal with raw_id_fields than the popup window in my opinion - utilising something like select2 with ajax loading and a hook on the ModelAdmin would be ideal.

In any case, it is fairly trivial to add options like this to the modeladmin and make them opt in if that is desired.

Overall, I'm probably -0 on morals, but +1 on supporting an optional alternative way to handle add buttons on related objects.

Marc

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8d65957b-6e57-4b7a-a8b1-7ce3a2ee8a18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Riccardo Magliocchetti]

Il 24/02/2015 20:12, Marc Tamlyn ha scritto:
> I would suggest that a good modal implementation for these should still support
> "open in new tab/window" properly, with control/command click not detected by
> the overriding JavaScript. It may be possible to do this and keep the popup
> functionality passing the new id back to the parent window.

uhm, that should be doable

[snip]

> There are definitely better ways to deal with raw_id_fields than the popup
> window in my opinion - utilising something like select2 with ajax loading and a
> hook on the ModelAdmin would be ideal.

Yeah, reusing existing libraries in the admin would be really nice

> In any case, it is fairly trivial to add options like this to the modeladmin and
> make them opt in if that is desired.

> Overall, I'm probably -0 on morals, but +1 on supporting an optional alternative
> way to handle add buttons on related objects.

-0 on morals sounds good :) So i think it'll be better to keep the windows and
focus on making experimentation with this widget possible for downstream users.

Thanks to everyone that partecipated in the discussion.

[Russell Keith-Magee]

On Tue, Feb 24, 2015 at 11:59 PM, Riccardo Magliocchetti <riccardo.ma...@gmail.com> wrote:

Il 24/02/2015 16:18, Florian Apolloner ha scritto:

On Tuesday, February 24, 2015 at 3:23:23 PM UTC+1, riccardo.magliocchetti wrote:

    I'm no UI/UX expert but modals are more or less the standard today,
    windows looks like a relic from the 2000s.

That argument is based on what? I'd personally argue that windows are superior
cause I can easily switch between the page and the window -- something that does
not work with modals

Not really an argument, it's more an observation that ui frameworks like bootstrap, foundations, etc.. usually have a modal component. In data entry UI that may not be the case though but i have no clue. Personally I just want to be able to use modals or whatever just by overwriting templates. I get that, I am happy :)

<rant>

Speaking entirely based on personal opinion - I *HATE HATE HATE* these browser-side UI elements. 

I have an operating system with a graphical user interface. The developers of that operating system spent an immense amount of time developing it, polishing it, making it behave in predictable ways, getting keyboard accessibility sorted out, and so on. The idea of a CSS+HTML+JS implementation of UI features that badly implement half of the behavior provided natively by the OS - and the idea that this implementation is somehow *preferable* to native UI elements - absolutely *boggles* my mind. 

Oh - and the "but you can't open native modal dialogs" counterargument? That's a *good* thing. No webpage can ever have a truly modal dialog, because I can open a new web page to the same URL, thereby violating the modality of your interface. Your server had better be able to handle non-modal interaction, or you're going to have a bad time.

</rant>

Yours

Russ Magee %-)

[Loïc Bistuer]

>
> On Feb 25, 2015, at 09:07, Russell Keith-Magee <rus...@keith-magee.com> wrote:
>
> I have an operating system with a graphical user interface. The developers of that operating system spent an immense amount of time developing it, polishing it, making it behave in predictable ways, getting keyboard accessibility sorted out, and so on. The idea of a CSS+HTML+JS implementation of UI features that badly implement half of the behavior provided natively by the OS - and the idea that this implementation is somehow *preferable* to native UI elements - absolutely *boggles* my mind.

While I agree on desktop OS, I find responsive HTML modals much more usable on mobile.

That said, HTML modals vs popups is hardly the biggest issue we have when it comes to usability on mobile platforms, which isn't surprising considering the admin look & feel was invented way before mobile was a thing.

--
Loïc

[Russell Keith-Magee]

On Wed, Feb 25, 2015 at 10:39 AM, Loïc Bistuer <loic.b...@gmail.com> wrote:

>
> On Feb 25, 2015, at 09:07, Russell Keith-Magee <rus...@keith-magee.com> wrote:
>
> I have an operating system with a graphical user interface. The developers of that operating system spent an immense amount of time developing it, polishing it, making it behave in predictable ways, getting keyboard accessibility sorted out, and so on. The idea of a CSS+HTML+JS implementation of UI features that badly implement half of the behavior provided natively by the OS - and the idea that this implementation is somehow *preferable* to native UI elements - absolutely *boggles* my mind.

While I agree on desktop OS, I find responsive HTML modals much more usable on mobile.

 

Weird - I've found the exact opposite, especially if you're talking about a site that doesn't have a mobile-optimised website. I've given up counting the number of websites that have popups that are larger than the screen size of the mobile device... and then helpfully keep the modal window centred on the screen so that the dismiss button is off the screen.

That said, HTML modals vs popups is hardly the biggest issue we have when it comes to usability on mobile platforms, which isn't surprising considering the admin look & feel was invented way before mobile was a thing.

Very much agreed on this point.

Russ %-) 

[Gordon]

I just wanted to add my 2cents worth as an opinion in favor of modals replacing popups for many of the admin links.

I am in no way claiming that a poorly implemented modal window is superior to a new window...  and there are certainly cases where a new window is preferable to the "perfect" modal.  Taking that into consideration, assume for the remainder of my reply that the modal popup is well implemented and addresses all raised usability concerns.

In my experience, modals can be very beneficial to users that are not technically inclined.  From a UX perspective, this is important to consider.  As long as the modal window is implemented using unobtrusive javascript, "power users" can be expected to know (or at least be taught/shown) that they can click with the middle mouse button to open a new tab or right click to select between new tab and new window instead of the default modal.  During my encounters with the fabled "technically challenged" user, I have observed that they tend to get confused (or at the very least have trouble navigating) when several windows are opened.  They are not proficient with alt-tab or any other window management techniques that you and I are comfortable with.  For this class of user, it makes sense to select the most appropriate default action for their click whenever possible.

I would counter the argument about native windows being superior with the following: the browser isn't aware of how tightly related the linked content is to the current page.  As such, it can't decide that the link should be opened as a modal inside of the current browsing context instead of a new window.  This means that it must fall back to the more generic of choices to cover all cases.  However, the content author does know the relation between the current page and the linked page.  Because of this knowledge, it makes sense that the author can make a better default selection than the browser when choosing a context in which to open a particular link.

For the sake of demonstration, I've found jQuery mobile to be an excellent choice when dealing with non-technical users.  Just to be clear, I am not advocating for JQM to be used in the admin with this reply.  With that being said, here is a link to examples of modal dialogs that I am fond of: http://demos.jquerymobile.com/1.4.5/pages-dialog/

[Thomas Leo]

I've opened a ticket [1] to implement the popups in the admin as modal instead 
of windows. I'm no UI/UX expert but modals are more or less the standard today, 
windows looks like a relic from the 2000s.

If it ain't broke don't fix it. The django admin is awesome, the reason it hasn't changed much is because it doesn't need to. Google.com's home page still more or less looks the same as it did in 2000.  

With that being said if the Django admin was "RESTfull" i.e. you can authenticate and make changes without the browser (application/json requests, for example) then "downstream theme maintainers" don't need to worry about how the HTML pages are returned so long as the API doesn't change. This also makes building native and client side applications easier IMHO. It seems to me that the django rest framework already accomplishes the criteria I mentioned above.

tl;dr I'm very much against adding modal's to the django admin interface.

On Tuesday, February 24, 2015 at 9:23:23 AM UTC-5, riccardo.magliocchetti wrote:

Hello,

[Chris Foresman]

On Thursday, February 26, 2015 at 10:25:02 AM UTC-6, Thomas Leo wrote:

I've opened a ticket [1] to implement the popups in the admin as modal instead 
of windows. I'm no UI/UX expert but modals are more or less the standard today, 
windows looks like a relic from the 2000s.

If it ain't broke don't fix it. The django admin is awesome, the reason it hasn't changed much is because it doesn't need to. Google.com's home page still more or less looks the same as it did in 2000.  

The admin isn't "broke" in that is still does what it was designed to do in 2005 or whatever. I don't believe that fact supports your assertion that it doesn't need changed, and even most of the Django maintainers agree the existing UI isn't "awesome." Functional, to a specific end, yes, but not "awesome." Nearly everyone I know that uses Django agrees that the admin interface could use improvement.

We simply stopped including the admin in every project we build—and I mean deleting every admin.py and taking admin out of urls.py—because it invariably causes more problems than it solves. If we have to do anything database-related, we either do it directly or use the Django shell. If clients want any kind of "admin"-like dashboard or whatever, we build it from scratch. 

[Thomas Leo]

> The admin isn't "broke" in that is still does what it was designed to do in 2005 or whatever.

The django admin was designed to do is basic CRUD operations. It does a good job of that.

> We simply stopped including the admin in every project we build—and I mean deleting every admin.py and taking admin out of urls.py—because it invariably causes more problems than it solves. 

What problems does the admin interface cause? Would these problems be solved with modals? I think explaining these problems you mentioned can shed light on what improvements can be made.  

> If we have to do anything database-related, we either do it directly or use the Django shell. If clients want any kind of "admin"-like dashboard or whatever, we build it from scratch.

What limitations does the admin interface have that requires using the Django shell or adhock "admin"-like interfaces instead?

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/b38JElfE3wk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/23deeacb-b344-4c32-a1d3-7ed2a4964ef2%40googlegroups.com.

[Fabio Caccamo]

Hi, 

I suggest you to try django-admin-interface