Hi all! I think it would be fair to note that Dana's mock-up (http://cl.ly/0U2C1O20133i0U3d1s3X/o) seems to solve most of the tasks mentioned by Russell, while avoiding information overload and keeping visual hierarchy clear.
- If I seek to contribute to Django, the mock-up features a clear and visible “Contribute” link below. - If I'm a manager new to Django, the first thing I'd look for is which companies already use the framework, and how. The “Who's using” block gives a solid clue on that. (I'd only suggest that the logos were links leading to actual use cases.) - The DSF part is, however, missing: I'd suggest to place corresponding block below the quick start. I agree that Giovanni's design probably lacks some of the features and not as clear as Dana's original mock-up. However, I would argue with Russell's point about “equally important calls to action”. Yes, both proposals aren't optimized for all mentioned use cases equally well. The “Contribute” link is not visible enough, and the DSF block is below the fold, and there's not much community resources present. However, keeping clear visual hierarchy and limiting the number of calls to action according to use case priority is probably more important[1]. It appears to me that use cases for djangoproject.com clearly differ in their priority: - If you're a developer or a manager choosing what to use in a new project, you're a valuable visitor, as broader adoption is desired. There's also a high chance you bounce off and won't come back, since there's quite a variety of web frameworks out there. So it probably makes sense to optimise for this use case. - If you're a manager or developer who've already decided to give back to the community, you're probably more valuable, but it's also harder to drive you away. (Some time ago I remember myself searching current djangoproject.com on how to contribute to development, there wasn't any mention of that on landing page but I kept looking until I found relevant information.) - If you're a developer returning for reference, you're unlikely to drop Django because of landing page. Also, you'll just use Google to search for relevant information, which would land you directly on documentation pages and StackOverflow. Considering this, it probably makes sense to optimize for new potential users (managers and developers) first, then for those who seek to contribute. The Dana's mock-up IMHO would deal with that well with DSF / sponsorship block added at the bottom. Note: The above list may be incomplete, or I might've gotten wrong the priorities. I'd just like to propose more systematic approach to the problem. Regarding community visibility: It's probably impossible to place many community resources on landing page while keeping strong visual hierarchy and clear call to action. I'd argue Dana's design deals with this well: “Featured content” could expose one selected resource at a time, while the “Explore” block has the “Resources” and “Community” links that point to the rest. [1] The larger is the number of calls to action and the more use cases the page is optimized for, the harder it is for a visitor to make a decision. http://muddylemon.com/2012/03/creating-effective-landing-pages/ explains that. Although it perhaps deals with landing pages of different sort, IMHO some principles are still applicable to general landing page design. -- Anton Strogonoff PS. At first I thought of djangoproject.com redesign as a good opportunity to give back to the community and show off my skills as aspiring web designer, but after seeing Dana's mock-up I decided I can't really suggest anything significantly better. =) (PPS. It appears to be my first post here, please don't judge hard.) On Wednesday, May 2, 2012 6:52:10 AM UTC+7, Russell Keith-Magee wrote: > > Hi all, > > I have two reactions to Giovanni's design: > > * There needs to be more than one call to action. "Download and run > tutorial" is the call to action for new users; but there are several other > equally important calls to action: > > - I'm an active Django user -- how do I get involved in development? > > - I'm a manager considering Django - I don't want details, but I need to > know if Django will be suitable for my project > > - I'm a manager using Django - I want to give back to the community? > (i.e., where is the foundation?) > > Giovanni's proposal seems to have the same limitation as the current site > -- there's a call to action for running the tutorial, but not for the other > use cases. > > * One of my personal goals for this redesign is to give more visibility to > community resources. Over the last 6 years, we've had a number of > unofficial projects come and done great service for the community -- django > people, several packaging indices, and so on. However, many of these > projects have died on the vine. I suspect one of the reasons that these > projects has died is that they've never really been considered first class > members of the community, and so it's mentally easy to abandon them rather > than seeking to hand them off to a new maintainer. The only place I can see > in Giovanni's design for this sort of community content would be to bury it > in the footer, or on a separate part of the community page. > > Yours, > Russ Magee %-) > > > > On Tuesday, 1 May 2012 at 6:41 AM, Idan Gazit wrote: > > > Lovely to see fresh talent and energy applied to a long-stalled issue. > :) > > > > I think Giovanni's proposal has a strong, simple page structure, and it > does a good job of IA for our varied audience. Putting on my BDesignerFL > hat, let's use that as a starting point. > > > > Let's set aside the issue of restyling docs for now; we can't run in all > directions at once. > > > > > > Homepage Structure > > =============== > > > > > > News > > ~~~~ > > > > The major element elided from the proposal is some display of news. The > current homepage shows the most recent four entries; I think one is > sufficient for the homepage, but it does need to be somewhere on the page. > > > > > > Header nav > > ~~~~~~~~ > > > > There is no header nav in the proposal. I'd like to have some minimal > list of primary nav links, like the ones at the top-left of the page > fat-footer. On the homepage, they can appear very de-emphasized, I like the > spare look of the masthead and I don't want to break that by boxing it in > with a visual bar from above. > > > > > > Header actions > > ~~~~~~~~~~~ > > > > While I like the "quick start" mechanic, those buttons require some > love: > > > > * There's no obvious "get django" or "download" call-to-action. "Quick > start" is good but we're burying the download information in there. > > * The quick start drawer doesn't make mention of the other ways you can > get Django, for example downloading a tarball or a link to github. > > * There's no quick display of our most recent released version. It > belongs somewhere at the level of these buttons. > > > > My proposal is a button layout like: > > > > [ Get Django 1.4 v ] [ Quick Start v ] [ Documentation ] > > > > The get-django button can show a drawer like quick start, but show the > three common routes (pip, tarball, github) and supply a link to a page with > more details if need be. > > > > > > Who's Using Django > > ~~~~~~~~~~~~~~~ > > > > I don't know if we'll have case studies. If not, an attractive display > of some logos wouldn't go badly. If we do, then we can fade out the other > logos upon click and show a bit of teaser text about the company with a > link to "read more…" > > > > > > Footer > > ~~~~~ > > > > I like the structure. Need to give some thought to the six large > elements and make sure they're the best choices for what to show there. > > > > > > Responsive Structure > > ~~~~~~~~~~~~~~~~ > > > > A requirement for the new dp.com (http://dp.com) is that it be > responsive or adaptive. I'm not going to get hung up on the > technicalities—something which looks and works well on a variety of common > screen geometries. The proposed page layout would linearize well for > smaller screens, which is excellent. > > > > > > > > > > Non-homepage templates > > =================== > > > > I'm not sure what other pages we have in our current site, ignoring trac > for now. I suspect that we'll need one or two templates for non-home pages. > > > > > > > > Look & Graphic Design > > ================= > > > > I don't want to get off course with the IA work. Color and design stuff > can wait until we're feeling that the structure is mostly baked. > > > > If you have ideas and you want to get them down, I'd recommend you make > something like style tiles (http://styletil.es/). > > > > > > > > > > Thanks all for your brains on this matter. I am excited to see this > underway, and I can't wait to see what comes next. :) > > > > > > -I > > > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > > To post to this group, send email to > > django-developers@googlegroups.com(mailto: > django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com (mailto: > django-developers+unsubscr...@googlegroups.com). > > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/67nl3n6oPwIJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
