One thing I forgot to mention in the nav bar conversation is removing “The web framework for perfectionists with deadlines.” tagline from the top nav would free up a substantial amount of space there. I like the tagline just fine, but I don’t think it needs to be as prominent as it currently is.
+1 for some kind of playground. I really like the SvelteKit playground Hello world • Playground • Svelte . I like how they have integrated the tutorial into the playground. It really makes a difference. Maybe not a full tutorial, but for showing some functionality. Web containers exist, and they have Python support, but there are some limitations. A proof of concept would be nice.
You can get a basic playground using Pyodide pretty easily in not a ton of JavaScript — I built a proof of concept for django-bird earlier this year. You can see the core of it here, where I’m actually able to install third party packages and load custom templates for demoing the library. The only issue is the load time is not great, which you can get around a little bit using a service worker. Link to the playground to see as an example.
No idea how @radiac built the nanodjango playground (IIRC the code behind it isn’t public? Could be wrong there), but I imagine it’s in the same ballpark.
On the playground front I also want to call out DryORM from XTerm (on Discord). Not quite the same technologies as the Pyodide stuff, but works very well! They have also spent some time getting some tutorials already as well
Don’t get me wrong, I’m all for a Django playground, but it definitely feels out of scope to me. It couldn’t be on the homepage itself because of performance requirements, so maybe a playground is a separate conversation altogether?
Yes, its sounds like the nanodjango playground has a similar approach to the django-bird playground - it uses pyodide (and a web worker and service worker, and a couple of wildcard domains for sandboxing).
It isn’t open source yet as it’s nowhere near releasable, and there are also still several bugs hanging over from its launch at DCUS which I haven’t had a chance to sort yet.
My goal with the nanodjango playground (and nanodjango itself) is to make it easy for people to play with Django and soften the learning curve. I think the single file approach makes that easier, but I can’t see why we couldn’t use it with full Django - the main difference is working with multiple files, but that should be solveable.
If there is interest I’d be happy to look at restructuring and releasing it, bringing in improvements from django-bird etc, so we could have some sort of unified django-in-the-browser project that could work for everyone - no sense duplicating work?
Load time is an issue though; I’ve not spent any time optimising it, but with pyodide and Django to load I don’t think a playground is ever going to be instant without running the code on a server (I think that’s what DryORM does?) but I worried about maintenance/costs so didn’t want to go down that route.
My hope is it shouldn’t take so long that people won’t wait for a loading bar to finish, and if it’s in an embedded iframe halfway down a tutorial it hopefully will have loaded by the time they get there. But, as Adam says, with its load time and resource requirements it’s maybe not something we want running on the homepage.
I love the homepage work by the way, admiring it silently.
I’ve got a half written “livedjango” JS library based off what I learned on the django-bird playground to do basically what you’re saying, put as much of Django in the browser as possible using Pyodide, designed for use in documentation sites. IIRC the loading time with the right amount of caching via service worker is acceptable for that use case, but nowhere near as fast as you would want for a homepage (though something below the fold where it could have time to init, totally possible).
Anyway, it’s all a bit tangential to the home page redesign so we can take this elsewhere to talk later if you or anybody else is interested.
I’m all for a Django playground, but it definitely feels out of scope to me
I suppose my original point was the homepage doesn’t need to be relaunched in one go. As a way to keep momentum, we can chunk the features/sections such as:
key Django features showcase
brands that use Django (might need approval/checking we can add these logos)
sponsors on homepage (may need to confirm with fundraising wg)
people quotes (requires gathering people quotes and approval to be on the website)
Django playground
New website styling (requires website wg/designer input)
…
Some sections require more work (whether that’s technical or through working with stakeholders). Different people can work on progressing each thing or they can be tackled one at a time
I feel each bit serves a purpose and will add value as an individual piece, be easier to review/approve as a smaller section, and help chip away at moving towards the complete design
Oh, yeah! Splitting this up in smaller pieces makes sense to me. I can create a PR for just the hero section with @FarhanAliRaza’s approach to show off key features? That seems like it would be immediately useful and isn’t too drastic of a change. What do you think, @sarahboyce?
This is cool! …but I wonder if a fresh forum post and getting those who have already built similar setups to build one together?
Currently I know of 4/5 different implementations, while generally I would say we want to have different opinions on a feature, I think a better route forward would be to pool interested parties on a single implementation. (Just my 2 cents!)
One thing I noticed is that some of the suggestions (listing key features and sites that use django) were on the homepage of a much earlier version of the homepage: https://archive.ph/mjxDt
Note that the key features still exist but they’re on the getting started page “Intro to Django” bottom section: Getting started with Django | Django
Seeing this I made a simple dark mode landing page for Django redesign. You can find it here at django.hallelx2.com
It’s based on the clean way Django handles your website, the green color for Django’s greenlight for all web enthusiasts and big companies.
The section for usage of Django was designed based on the top users of Django, companies that Django is their web framework.
Then we have the Core principles and it has a special hover animation that when you hover over each card, it raises up to expose what is under.
This is based on Django’s abstraction mechanism. It covers alot for you allowing you to focus on what matters while still allowing you to open it up and have your own custom contributions as apps or just Abstract classes in your application.
These are the little things I put to thought as regards this Django redesign
I’ve been following the discussion here about the homepage redesign and wanted to see if I could help move things along.
About a month ago, I submitted a Pull Request with a “Community” section as a first experiment. My thought was that it might be easier to tackle the redesign in small, manageable blocks rather than everything at once. This way, we can keep the momentum going without it becoming too overwhelming.
I haven’t had any feedback on the PR yet, so I wanted to check here if this ‘block-by-block’ direction is something that could work for the project.
