The devil is the details for real world usage on your data and it's relationships.
It was definitely not intended to be ugly — the first version was designed by Wilson Miner, a great designer. In fact, an argument could be made that a key reason for Django's early success was that the admin was so nicely designed. Same goes for the framework's website in general; the standard open-source project website in that era was really plain and uninspiring.
To answer "Why is the Django admin ugly?", I think there are two separate issues:
* A gradual bolting on of admin features without enough thought given to visual consistency and elegance. Particularly, the left sidebar (in the screenshot of the original article) was a later addition and looks unpolished.
* A misunderstanding of the Django admin's goals. It's meant to be for "internal use" — that is, it's meant to be used by people who operate your website, not by people who visit your website. Ever since we open-sourced Django, many people (through either laziness or lack of understanding) misunderstood the point of the Django admin, thinking it's meant to be for end users. It is not and never was.
And it isn't! I started using Django in the days when it was in perpetual Beta - back in 2008. It was not ugly by the standards of those days.
After over a decade's hiatus, I'm back to using Django for paid work. And I still find it "not ugly". Sure, it doesn't have bells and whistles, but it's pretty functional, and doesn't offend my aesthetics at all!
PS. I owe a lot to you, Jacob and Simon - thanks for Django! My funding in grad school was drying up, and I needed a side job out of my department to help pay bills. And fortunately, one team at the university was looking for a Django programmer. I was not a CS major, but knew enough programming to get that job.
I use Django exclusively for all my product work and it's... amazing...
... and I was recently consulting on a project where we had to make extensive additions to the Admin views and it was amazingly versatile, flexible, and pleasantly surprising in supporting everything we needed.
Is a cast iron skillet beautiful? Probably not, yet it has stood the test of time and people swear by it. I feel the same way about Django Admin. :)
We now have a new generation of developers who learned on fancy JS frameworks, SaaS dashboards, A.I.-enabled tools, etc. These new devs learning Django now in 2023 have never seen anything like the Django admin.
So with this article I'm just trying to pass on the tribal knowledge as to when to use it, and why it is what it is.
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).
This just confuses me. It's called "admin" for a reason...
I found one great middle step is a `simple_form.html` template and using Django Forms to quickly and easy generate a lot of CRUD views. You can also use a `simple_delete.html` confirmation template to handle that. These templates can be used on any number of pages.
Then, as your app matures, you can add more custom templates and maybe eventually switch to Django Rest Framework and an SPA, if it fits.
If you want an admin wrapper around your database, you have better many modern alternatives (I use directus). If you want low code and easy platform, you have bubble.io. If you want an easy api for your database, you can use things like hasura. If you want python frameworks, try fastapi (its third party admin is great). If you want an orm, sqlalchemy gives you more bang for your buck.
Many of Django's third party packages are out of date. The data science python community has settled on Gradio.
The sweet spot of Django seems to have disappeared. Jobs for Django are lower paying, and often more high stress than .net or other languages.
Django has a great outreach with it's Django Girls, Afro-Django and Django Foundation. However I feel like it's technical side needs far more love, the source code needs some major refactoring and cleanup.
I thought about this indepth on whether to send my daughter to django girls, or just train her in .net and c# myself.
If it's able to survive other 3 or 5 years, I'd argue the pendulum will just swing back to the "django's way".
> If you want an admin wrapper around your database, you have better many modern alternatives (I use directus). If you want low code and easy platform, you have bubble.io. If you want an easy api for your database, you can use things like hasura. If you want python frameworks, try fastapi (its third party admin is great). If you want an orm, sqlalchemy gives you more bang for your buck.
And your requirements.txt or poetry.lock file grows and grows. The thing I really like about django is that I don't need any external packages to start. I have basically everything I need to start inside a single package and don't need to bother about how to integrate sqlalchemy with flask, how to add auth and authorization to my stack or how to check that all of my tens of dependencies are safe and regularly updated.
The only thing I really miss is something like LiveView. I know there's htmx and similar, but i hope they will be some "official way".
Having used Django on and off for ten years or so I don’t perceive the ecosystem to be dying–the last large project I worked on used dozens of third party Django plugins and only one or two were unmaintained, and even those had some active forks happening.
can you please expand upon this argument? you didn't really try to convince anybody.
You’ve also entirely missed the point of Django admin. It is not your app. It is not your project. It’s intended as a crutch. The fact that it integrates with your ‘front-end’ code, in a way that a no-code platform popped in front of your database does not, is literally its main selling point.
Broadly speaking, corporate jobs offer a higher salary relative to startup jobs.
This is by design. Being engineer #0 at a startup is far less stable (i.e. riskier) than being engineer #65535 at BigCorp. The salary is somewhat lower because the company simply doesn't have the cashflow to pay more. Startups have one thing to offer employees to offset that lack of stability and lower salary: equity.
The vast majority of the time, that equity ends up being worthless. Every once in a while, it becomes worth a life-changing amount of money. It's not fair to say that Django jobs pay less. Those types of jobs are an opportunity to trade a portion of your earning potential for a few years for a chance at a much larger prize.
I don't have numbers in front of me to be able to prove it, but I'm of the opinion that when you include this in your calculations, the expected value of your labor is higher working for startups than at large, established companies. While the chance of any given startup succeeding is relatively low, it's not unreasonable to think you'll be able to join up to a dozen or so over the course of your career. The chance of _one_ of those having a successful exit is high enough that I've staked a big part of my financial future on it happening.
I've worked in the industry for over 20 years now, skills are transferable only to a degree. If you are applying to a corporate job, the person with c#/.net has the edge over someone with the equivalent experience in python/django.
Developers hate admitting this, but tech stacks matter to your hiring potential. My daughter can learn teamwork and other skills from the billion other kid oriented groups, for programming skills I'm going to help her get the easiest best paying job.
My perspective is that we have a new generation of Django devs among us, who grew up using fancy JS frameworks, SaaS dashboards, A.I.-assisted code tools, etc. So for a newcomer seeing the Django admin for the first time, it's a bit different.
My goal of the article was to capture the tribal knowledge that seems to have not gotten passed down to this new generation.
You don’t just submit a pull request called “Redesign”. The with is more political and organizational in nature
Not sure if English is your native language, but quotation marks usually land on the outside of any other punctuation. (Yes, it does look goofy.)
Now, the quote above is kind of special because you have a portion of it quoted within a statement. However, if you are paraphrasing all but the "ugly" part. In that case, I would drop the outer quotations marks.
> why is the Django admin so "ugly?"
Bring on the downvotes.
Question marks are a little different. If the question mark is part of the quote, place it inside the quotation marks. If the question mark is not part of the quote, and instead the quote is part of a question, place it outside of the quotation marks. This rule also applies to exclamation points.
- https://www.grammarly.com/blog/quotation-marks/
Place a question mark or exclamation point within closing quotation marks if the punctuation applies to the quotation itself. Place the punctuation outside the closing quotation marks if the punctuation applies to the whole sentence.
- https://owl.purdue.edu/owl/general_writing/punctuation/quota...
Different varieties and styles of English have different conventions regarding whether terminal punctuation should be written inside or outside the quotation marks. North American printing usually puts full stops and commas (but not colons, semicolons, exclamation or question marks) inside the closing quotation mark, whether it is part of the original quoted material or not.[14][15] Styles elsewhere vary widely and have different rationales for placing it inside or outside, often a matter of house style.
I'm soooooo sick of React doing completely hostile things like flashing incorrect information for empty widgets or completely breaking page location when hitting the back button.
Seems like every few years it becomes accepted to make the web worse for users because of front end fashions.
This isn't really React's fault. Avoiding the things you mention is entirely possible when using React. It's all up to the developer to handle such scenarios, just as it was without React.
Either way, it's a lot of text that shows up in a consistently stylized and clean way, which is tough to achieve for something like an admin panel.
Mission accomplished?
It's purely visual though. It's a great piece of software to get out of the box.
All joking aside, I like that the Django admin still looks the same after almost 20 years. Cannot begin to impart how much value that thing has provided me.
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.
> The admin’s recommended use is limited to an organization’s internal management tool. It’s not intended for building your entire front end around.
Cue someone used to working in “scale until you die” startups telling me that any time not spend on juicing MAU is time wasted. I like working in sustainable businesses.
I’ve worked with Django for a decade. I’ve done ungodly things with Django admin. Things most people wouldn’t dream of. I am completely over doing any of that. This isn’t a fault of Django admin. It’s very good at doing what it’s intended to do. It’s just a very common beginner’s trap to try to push it further than it wants to go.
There’s plenty to critique Django admin for. I fought with it just last week. At the same time, most complaints I see about it tend to be people (IMO) misusing it. It’s the service panel. And yes, people other than the engineers that built the thing have reason to pop open the service panel. These are your mechanics. But, and especially for SaaS products, don’t conflate “user” with “customer”, and not think about your other audiences.
An aesthetically pleasing interface is a side effect of someone fluent in that language working hard to figure out how to communicate information, action, cause and effect, etc to the end user. It's not an easy language to learn, it's important even in relatively trivial cases, and developers trying to wing it are about as good at it as designers cargo-cult assembling PHP to modify a WordPress deployment: It might get the job done in a very basic way, but nobody should convince themselves it's a real solution. Just like a developer might look at their interface and say "read the docs" or "design is subjective," that designer might see how slow their 5-deep for looped set of database queries is and say "this server is too slow" or "why can't those damned developers make WordPress faster?"
I agree with what you say somewhat, but I believe about the massive difference between UI/UX. If I have to sign up to something for the first time or have to buy something, I want pretty pictures. If I have to work with something often (all day let's say), I want UX and I couldn't give a shite about UI; I want things easy to find, fast (not latency) etc. Combined would be great, but tell me what has that, because I always see one, never both done to perfection. If there is a 50/50 mix, it's usually annoying as hell on both sides.
My most productive interfaces are ugly as hell ; no animations, no overhead and everything crammed on a screen and very fast. I would never 'sign up' for an application like that seeing it first, but I would never use any application long term for productivity like most people say is 'beautiful' because it's inefficient.
Are they settings that Meta wants you to change?
Really though? Does your web browser interface look the same as your sms/messaging interface, look the same as your car's annoying infotainment interface, look the same as your mail client, look the same as this website, look the same as your search engine? Do all of those things really look the same as they did 10 years ago? We use so many interfaces that are subtly shifting and being improved that the ones that work well for right now don't even stick out to us, and that's part of the problem. If you don't really notice that you're using an interface and are entirely focused on solving the problem you need to solve with that tool, then that's probably a really well designed interface. It's probably so smooth and intuitive that it seems like designing it that way would be obvious, but it's really, really not.
> If I have to work with something often (all day let's say), I want UX and I couldn't give a shite about UI; I want things easy to find, fast (not latency) etc. Combined would be great, but tell me what has that, because I always see one, never both done to perfection. If there is a 50/50 mix, it's usually annoying as hell on both sides.
You don't have an particularly accurate understanding of these roles. If a UI doesn't let advanced users solve their problems efficiently, then it's a shitty UI. "Pretty Pictures" where not appropriate is bad UI design no matter how pretty it is and people who don't think so are visual designers (at best) trying (and failing) to be UI designers. A well designed UI is an effective UI. All of those pretty UI mockups you see on sites like Dirbbbbbbble and behance are nothing more than aesthetic explorations. There's no way you could even know if they were good or bad UIs because you don't know exactly what problems they were trying to solve, for whom, and in what context.
UX encompasses the entire experience. If you have a great UI but the world's shittiest email confirmation workflow, then you have a UX problem with a great UI. This misconception is why developers think adding the ability to select color themes in their application with a horrible UI will address UX problems-- which to any actual software designer is complete nonsense.
> My most productive interfaces are ugly as hell[...]
A couple I'm friends with had a broken kitchen faucet handle for ages-- it would just fall off unless you held it on while operating the faucet. Unfortunately, one of the necessary connector pieces was no longer available, so it wasn't a trivial fix. Once, when I was pet sitting their rabbits, I got so annoyed by the thing that I went home and made a wooden piece to fit in where the missing part went, and fixed it while they were still on vacation. It was supposed to be a surprise but I totally forgot about it, and a few months later my wife said to them "hey do you like having your kitchen faucet fixed?" They looked at her, perplexed, walked over to the kitchen faucet, tried to pull it off, and it obviously didn't come off. They were shocked! Why? Because they were so used to holding that damned handle on the faucet that it just became an part of their using that faucet.
So not to be flip, but, the sky is blue, water is wet, and technical people are tolerant of and used to using shitty interfaces. Open source user interfaces are almost exclusively used by technical people; there are a few exceptions like Firefox, but Firefox's interface is managed by a team of foundation-funded full-time professional designers, (actually they do a lot of really great open usability work.) One exception I can think of is Inkscape. Most open source interfaces are absolutely awful. Why were they designed that way? They weren't. In fact, they weren't designed at all. They were assembled, ad hoc, to expose functionality in a way that made sense to whoever was creating the functionality. Those interfaces, more often than not, are more representative of their implementation than the problem they're solving, and unless you have a working mental model of how software works, and often specifically how that exact process works, the interfaces are practically useless.
There's a big difference between harder-to-learn-but-amazing interfaces-- vim, emacs, oboe, airbrush, airplane, etc. -- and interfaces that are entirely unedited. People are always going to be most productive using interfaces that they're used to, and that often mistakenly leads them to believe that what they're used to is objectively good. If you ask nearly any group of professional photographers how many hate Adobe, most will raise their hands. Ask them how many have used Gimp, they'll almost all raise their hand. If you ask them how many used Gimp more than once, they'll almost all lower them. Ask them why, and they will almost guaranteed cite the poor interface. While many dedicated and experienced FOSS developers (which I am) will cite Adobe's marketing practices as the reason people use Photoshop instead of Gimp, I call bullshit. You'll find many more photographers using Affinity Photo than Gimp, and considering Gimp is free, that says a lot. Who will you find using Gimp? Developers that need a photo editor. Why? They're so used to holding on the faucet that they don't even recognize when they see a properly working one. (And they'll often get really mad for even implying it needs to be fixed.) You also don't see that split with Inkscape. Most people who professionally work with vector art choose Illustrator as their primary tool, but most of them cite exactly the reasons developers assume people continue to use photoshop: overall smoothness, ecosystem integration, file type compatibility, etc. There are some legitimate shortcomings in Inkscape-- the type tools are just not as good which matters for graphic designers, for example. But lots of people who do vector art professionally do use inkscape.
Regarding Instagram et al, before you question whether or not the interface designer did a good job communicating, you need to know what they were supposed to be communicating. I'll bet they did a fantastic job at surfacing what what marketing people thought was useful for marketing, sucking in people's attention, and funneling them into profitable paths. The problem isn't that they're bad at it— the problem is that they're good at it while working for an organization that has shit motives. Similarly, the developers that make Instagram are still very very good developers even if a lot of their energies go into making super shady privacy-smashing telemetry. The problem isn't developers or software development, it's the goals handed to those developers.
There's bo difference. The GUIs have started rapidly going downhill right after some idiots decided they are different and the rest of idiots believed it to be true.
How can you have a UI without understanding how it functions and how it's used?
I think there is Trader UI, and VC UI. Trader UI, built for wall st packs every bit of information into every pixel possible. VC UI has rounded corners, nice fonts, drop shadows and half the information on the screen. Django UI actually splits the difference nicely.
Look at this screenshot of a Bloomberg terminal
https://www.investopedia.com/thmb/trBFMDD8xeZkhLiLscngql3FV_...
Django Ninja is a breath of fresh air.
It being ugly is a feature. Don't fall for the temptation of giving non-devs access!
(But it could have kept it's look while still being more friendly to use, though. So many huge selects and difficulties to fill in valid data in some cases)
It's not uncommon when starting a new project that I pick Django just to have Admin, and then ignore its usual views altogether.
Very easy to get started though, and even comes with stuff like cron jobs and email sending triggers built in and able to use in super simple manner https://pocketbase.io/docs/js-jobs-scheduling/
according to his benchmark you can serve 10,000 realtime connections on a 4 dollar a month server https://pocketbase.io/faq.
my basic deployment was just rsyncing my pocketbase folder into my vps and creating a systemd service. i'm now adding some github actions and docker files but it might not be necessary https://www.programonaut.com/pocketbase-as-a-framework-deplo...
The simplicity also makes extension simple. I could add a few features.
Is it the shiniest UI? No, but a well configured Django admin is a power tool that stays out of your way.
When clients ask me re-design it, I will deny it.
I did the re-design of admin panel once, and what we produced was better in design yes, pretty even, but not usable, people got lost in it thinking it's still the main site and not admin panel, and there were only 3 admins, 2 of which were management.
In my opinion, it's good as it is.
One of the eye openers for me personally was the realization that the Mastodon organization contracted a UX engineer firm. It shows.
Grappelli was OK for a short time, but even it's too dated to use now.
The number of "What if I used Bootstrap made everything look like a horrible Bootstrap site?" packages is hilarious.
If yes, it's probably better than 95% of other admins.
Only one rounded button?
