Posted by JohnForsythe on September 23, 2008 at 6:55am
I took some time today to draw up my vision for the project pages..
It's a mix of my current work, some future plans, and some ideas I had for harnessing Drupal.org's data. More details over here.
So, what do you think?
Comments
I would like
Looks very useful to me. The
Looks very useful to me. The available space is far better used than currently on D.O project pages. I'd like to see the issue queue and project links in a section of its own called Project Links above the Related Content section.
--
My Drupal Articles
I think this would be a
I think this would be a great way to go but would make drupalmodules.com less useful.
Acquia and drupalmodules.com
Well drupalmodules.com was created because there was lack of such functionality on drupal.org. If this would all be implemented, perhaps we could import all current data from drupalmodules.com. I noticed that Acquia is sponsoring drupalmodules.com so I wonder what they and John have in store for it. I'm sure there's a masterplan behind it all, and I welcome it.
That looks great
It could be further refined by tailoring the data displayed by the desired drupal version rather than all versions that exist since most people are only interested in information related to the drupal version of their choice. This could be handled using the current drupal version selector they have on the site and would reduce the need to display about 25% of what you've shown. It would also allow for more fine-grained ratings since, as we all know, different versions of modules can deliver wildly different experiences and a global rating over all different versions could be misleading.
One thing missing!
Direct and clearly labeled links to documentation. One of my hopes for the redesign is that project pages become more tightly coupled with the documentation that exists for a module, and that it is easy to add new documentation pages that get linked to from the module project page.
The link between a project and its documentation should be automatic!
It's a beautiful proposal, and I hope we manage to build something this nice.
I think it's good but..
With Drupalmodules.com, as a user who might not instinctively know what a module does or how it can be used, I always have to go back to drupal.org to find documentation/examples/demonstration sites/screenshots.
This design above also puts the emphasis hugely on ratings and statistics, when for most people the most important thing is what the module does, whether there are alternatives that do it differently and how to make that happen on their site. While I like to see that lots of sites use a module, it's not that important to me. What I do want to see is the module in action...see it doing what I need it to do.
So priorities for me are:
Full description
Full documentation
Demonstration site
Examples of the module in use on other site
Screenshots of the module in use
And I can't second robertDouglass' comment enough: the documentation should be an integral part of the project page. (to which end I think projects should have dedicated documenters as well as maintainers - maybe a good way of getting non-coder Drupalers more involved)
Yep, I'd say that I agree
Yep, I'd say that I agree with @thomasmuirhead. I find the ratings and reviews somewhat useful but since so many modules usefulness really depends on your use case, I'd rather see a focus on what they do and documentation. Some ratings and reviews are not how I would rate them after I use them, so I am definitely wary of making decisions based on them. Demos would be cool but very few people actually set up demos. No reason to not encourage them, but I just don't see that being a component on many project pages. So if I had a switch up on the wireframe, I'd drop the ratings and stats lower, by the review, and replace them with docs links and screenshots.
Lullabot loves you
Learn Drupal online at Drupalize.me
Consumer
This looks a bit like consumer stuff to me - take it and be happy. I'm missing the community involvement stuff - researching the issue queue and the CVS commits are an integral part for me both as user and as maintainer of a module. The project page needs to make it clear that we need the user's involvement for making the module better, simply downloading and rating it is not enough for drupal.org. Imho.
more stats.
I'd like to see the statistics from http://drupal.org/project/issues/statistics included here - it helps alert users that there are existing known issues which they might be experiencing, and gives an idea how active the module is for developers (and developers are consumers of modules too). See http://drupal.org/node/310446 for removing the 'create' links and changing them to 'view' instead to encourage more participation other than posting dups.
I also agree with the comments about documentation - installation instructions and general documentation should be really, really prominent.
I'm not going to go into the voting/reviews issue here - that's been discussed in depth in many more places, but a quick heads up for http://groups.drupal.org/node/14606 - adding a flag for 'I've used this module' - you could get all kinds of customised tracking with that, as well as 'users who use this module' and 'users who use this module also use' etc. etc.
Also - very far in the future, we're likely to have continuous test runs and coder reports on modules via testing.drupal.org - would be good to integrate that at some point too.
dependencies
We should also be displaying dependencies based on .info files rather than people hardcoding them into their project descriptions: http://groups.drupal.org/node/11998
Another question - what about themes, translations, install profiles etc.?
metrics that are not easily gamed - and flexibility
I'm concerned that the stats/reviews are easily gamed. The Joomla site used to have recommendations on modules and then they did analysis and found that something like 80% of the reviews were from the module authors :( Ever since I started publishing download statistics there has been a clear increase in shady behavior to inflate downloads for projects. So, we know this is a problem elsewhere, we know that it's starting to be a problem in Drupal, and I think placing those metrics in such a high priority place would increase the problem within the Drupal project.
I'd rather see metrics that are less easily gamed and which represent a more objective measure of quality: does it pass the coder module? how many errors are produced when it's run through potx? How many open issues? How quickly are open issues closed? Does it have simpletests? How many of the simpletests pass? What is the code coverage for those simpletests? Have there been recent commits (could be good or bad...)?
I'm also concerned with the lack of space for module authors to exercise control over the page. There's no place for a screenshot nor enough space for a real description of what the module does or any important notes to potential users.
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
knaddison blog | Morris Animal Foundation
exactly
We already have much of this information, and some of the rest will be on it's way soon - it's mainly a case of exposing it properly.
I'm also concerned with the
I'm very nearly -1 to this proposal simply because of this exact problem.
While there's certainly a lot of wasted space on the current project pages, this design goes from allowing project maintainers direct control over 70% of the visual space down to about 15%. That's a problem for me. I've talked quite a bit about being a fan of having additional metadata on project pages, but a careful eye needs to be turned to not just harvesting existing metadata, but putting more things in place that encourage the author/maintainer (who presumably knows the module best...) to convey useful information about the module. And then that gets put up front and center.
Many of the things already mentioned in this thread constitute the sort of stuff I'd like to see more of: links to developer's blogs, links to documentation, etc. - but the extent to which the developer is being squeezed out - by metadata some of which is questionable utility, again for reasons that greggles has highlighted - makes me really uncomfortable.
Whitespace is good. Not
Whitespace is good. Not because module maintainers can customise their project pages, but because it looks less busy to potential users. Even though John Forsyth's example image makes good use of the available space it's not good for usability.
Statistics on number of
Statistics on number of downloads or page views are easily gamed, that’s true. The number of installations would be an alternative, maybe displayed as a percentage, e.g. 2% of all tracked sites have module x installed.
For developers information on test coverage, compliance with code conventions etc. is very useful. But we need to take into account that many people looking for modules are not developers. Maybe we could integrate some 3rd party statistics too, for example number of bookmarks on delicious.
--
My Drupal Articles
installations and interpretting results
Installations are also easily gamed. Sadly.
The things you feel are only of interest to developers will, I hope, be of interest to others. A large part of what Acquia/SpikeSource are selling is QA on the modules. Maybe they don't understand how to write a simpletest, but everyone downloading a module should understand "100% of tests pass, tests cover 80% of the code, this is good."
knaddison blog | Morris Animal Foundation
I also want to have this
I also want to have this information displayed. If there is some form of evaluation like "this is good" it can be helpful for non developers too. Still we should not solely rely on developer centric information if Drupal.org wants to become more friendly towards all end users.
Number of installations can also be gamed, but it's more laborious and so hopefully less people are inclined to take the effort to do so. By using a value relative to all tracked installations you would need to have lots of dummy update information requests to end up with an impressive number.
You can also game the number of commits and thus pretend development activity so there may be the need of some form of automated detection of such pseudo activity.
If we want to provide valuable information to the end user, we will need to make life hard for those who don't want to play fair. If we exclude any metrics that can potentially be gamed, we will end up with no metrics at all.
--
My Drupal Articles
Developer Blog
One of the things (as an active module developer) that I'd REALLY like to see is a way to link a project to an external blog (via aggregator) or an internal one dedicated specifically to a given module. As it is I manually put links to my newest blog posts and use the project page as a mini-update section w/ descriptions on how the module works and what's coming down the pipe. I'd REALLY like to not have to deal with it that way in the future. I maintain a VERY active blog on my company website about my modules and it'd be nice to just point the project at that, and have updates appear on the project page. Just a thought, but I think it'd also help to show the activity of the module.
Eclipse
Re-use Planet Drupal aggregates
I've just to say: Whoa - Awesome idea! Consider Earl Miles writing about major Views API changes on his blog, tagged with "Views" - directly appearing on the project page. Raincity Studios writing about image galleries, tagged with "Image", "ImageField" - directly appearing on those project pages. Wow - THAT would be a fantastic community and eco-system involvement!
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
...and combine this with flags to create a mashed-up planet view
Well, the title says it all.
I flag some modules of interest, say views, content, admin_menu, ...
...and get a personalized view of Planet Drupal!
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
nice!
I've already wanted to have additional tags for Planet so you could subscribe to sub-feeds. This is a much, much cooler use for it though. Would be really nice.
Groups implementation
I think it would be nice if projects were a g.d.o implementation with a block specifically for the downloads, issue queue, etc. I think g.d.o offers the widest amount of functionality and allows a project maintainer more control of their projects. Maybe documentation, downloads, and description should be required in a certain location for consistency, but other blocks could be added to the project.
Metrics not Reviews
I posted a long comment at
http://flickr.com/photos/_leisa/2837572708/comment72157607176186876/
in relation to the download page, but it probably applied here even more.
The quick version:
When I examine a module page I want to know:
1. What does it do? ie Will it solve my problem now?
2. How 'good' is it? Is it a quality module.
And just as important?
3. Is it likely to be maintained and developed going forward?
This is a critical element for me, and indeed all open source users.
How sure can i bet that it will be further developed, bugs squashed etc.
The longer version: quoted from that link
A quality score for the module is much more important than subjective ratings by end users, but those ratings could help too.
In terms of qualitative measures, some things I look for in a module to determine it's worth.
In order of importance.
I've been around long enough to know that something developed by merlinofchaos will be better that something developed by alanburke.
How is that reputation earned?
Some factors
How long has the developer been around?
Do they contribute to core?
How many modules have they got?
Do their modules get updated for each version of Drupal?
Are they active on mailing lists?
Do their blog postings make sense :-).
I'm not sure how we could 'measure' all this though.
Many times, reputation is enough for me.
Activity.
Are there plenty of commits to CVS?
Does it have multiple maintainers? - this is a biggie. A project with multiple maintainers is much more likely to be active in the long term.
Code quality.
Does it pass Coder review?
Does it list other modules as dependencies?
Do other modules rely on it as a dependency?
Popularity.
Is the module in active use on other sites?
Do I read lots of blog post about it?
Is the issue queue active?
In general - all I'm trying to gauge is that the project is "healthy", "living" and "growing". If I think it is, I'll use it.
It was the same question I had when I evaluated Drupal in the first place. It's nice to be right sometimes :-)
I could not agree more
Hi,
Seriously.
I maintain Drigg, which is a 12000 line monster. It has basically no bugs, and am going through the short list of issue requests, which should go down to 0 in the next couple of months.
I want, I desperately want a page that states that. The "trick" to keep Drigg so healthy is simple: tons and tons of hard work. However, I can see how less maintained, less cared for projects will be picked by users who are not really able to distinguish an unkept issue queue from an immaculate one.
So, yes. +1 +1 +1
Merc.
Valuable metrics
Things I would like to see on the project landing page:
1 - Integrated documentation
2 - How many open bug reports are there?
2a - How many have been responded to by maintainer (vs. ignored)
3 - Average duration bug issues are open.
4 - Rate of bug reports
5 - % of bugs solved for each release.
6 - # of commits
7 - Duration between stable releases. (? less sure about this one)
8 - Activity metrics on maintainers (all of them)
* How many projects maintained
* How many commits
* How long on Drupal.org
These things tell me more about a module than ratings or popularity. This list is a first take and should be reworked and massaged, but it's the kind of metadata I feel is important and right now is buried.
Also, meaningful taxonomy would help. For example, there is a CCK term but no SEO term. The terms seem to come from a "what is it" perspective rather than a "what do you want to do" perspective. This last thing should be part of the IA for the redesign, imho.
Laura
pingVision, LLC (we're hiring)
PINGV | Strategy • Design • Drupal Development
Project module's hidden project metrics
What project issue metrics can tell us about quality - I posted a write-up some time ago, but it is still valid IMHO: http://groups.drupal.org/node/10629
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
project taxonomy
For taxonomy - I opened a discussion here (and just got the required permissions to mess with it on d.o) http://groups.drupal.org/node/11996 - any ideas on that would be great!
While we should definitely do it as part of the redesign, it's probably out of scope for Leisa/MBD's work in the process.
ratings and downloads are
ratings and downloads are really not the measurements we need to see a modules value. as said before this things can begamed easily and they are subjective.
publishing statistical data about the module seperated by versions perhaps is for me the better source of information about the state of a module. i already look at the issue queue when evaluating a module but having this on first sight would save a little time.
what i really miss is the ability to comment a module. i would like to see - much more than ratings - personal opinions about users which tried to or actually work with the module. this is a good thing where documentation can be expanded.
Remember: I compute you!
What I often want to know most...
is whether a dev or beta or RC version will indeed work WELL ENOUGH. Sometimes there's not final release even though the module is working basically fine because there hasn't been enough review or the developer has been busy or he has additional features planned that he hasn't gotten to or UI changes, etc. but it can still be installed without killing a site.
Since contrib modules are so often behind Drupal core releases, I and many others live 99% of our lives seemingly waiting on and fussing with dev versions of modules. We just need more input. Issue queue searching and drupal search in general blows. Part of the problem is that developers tend to spend their precious time fixing problems rather than reporting on them (and that's completely understandable) but the more info we can make available the better. I want one page to look at that will show me all info from everywhere on the module in question and I want to be able to intelligently search and sort the results (6.0 only or Views and CCK only, or bugs or patches only or whatever).
And I strongly echo the need for better module descriptions and examples. Numerous modules do not really explain what they do, what they are for, whether they are being actively maintained, whether they even work, etc. I don't care whether a module is popular so much as whether it works.
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
Totally agree! It would
Totally agree! It would really help when some one who tries to fix a issue but fails, write down along side that particular issue, where he is getting stuck. We could then leverage from his experience while fixing the same issue.
Netlink Technologies Ltd
http://shyamala-drupal.blogspot.com/
Shyamala
Unimity Solutions
I would recommend: Linking
I would recommend:
Linking modules to a Taxonomy system to make them more easily search able
Having a link to the documentation would greatly help!
It would be great if there was a small architecture/ flow chart diagram explain the module form a developers perspective. This would speed up expansion or improvisation of many of our expanding modules.
Netlink Technologies Ltd
http://shyamala-drupal.blogspot.com/
Shyamala
Unimity Solutions
Great feedback
Hi,
Thanks for all the great feedback so far, this is some of the most interesting discussion I've read about the redesign yet. Here are a few responses to some of the issues raised so far:
Gaming download/pageview stats
Yes, it's possible. Gaming download/pageview stats is easy, but filtering the results by IP is also easy. If you only count 1 hit per day/week/month from an IP, you make it 10x harder to game the stats to any significant level. Drupal.org has a great advantage of being a huge traffic source, so even someone going to the extreme, spamming from 200 different IPs, may not even make a 1% increase on the download stats of most modules. The same goes for reported installs.
Issue Queue Stats and CVS
Some people have suggested using issue queue stats. I believe the issue queue tells you a lot more about the module users than the module quality, for all the reasons I've outlined here. And if you believe people will game their download stats, you also have to believe they'll game their issue queues, too.
Placing high importance on issue queue stats gives module developers incentive to prematurely close issues, both as a way for unscrupulous people cheat, and as a general result of the pressure to keep your stats up.
I'm not against exploring this idea further, I just don't think it's as useful or as bulletproof as it might look at first glance. It's possible we can come up with a set of stats that are really useful without pressuring the issue resolution process, and that aren't heavily influenced by the knowledge level of the module's audience.
On a similar topic, CVS activity stats could also be gamed, but it seems less likely. I'll have to think about this more. It would be useful to have some numbers to look at. Anyone want to make a case for some good stats to evaluate, or share any example data?
Reviews
Reviews are another concern when it comes to gaming, but I don't think it's nearly as big an issue as it might look. The key to making reviews useful is to make it easy to evaluate who is writing the review. You need reviewer transparency.
I've taken steps towards this on DrupalModules by introducing a reviewer profile and quality score. Whenever you see a review, you can click 'info' to see when the user joined, their entire review history, and their overall review quality score/reviewer ranking.
Quality scores/reviewer rankings are automatically calculated by an algorithm I developed, based on a number of different metrics. Drupal.org has even more metrics that would be useful in this regard, plus you get the added benefit of having the reviewer's entire post history, commit history, cvs history, etc. It's much easier to evaluate the quality of a reviewer, both visually, and algorithmically with access to this data.
Essentially, the usefulness of reviews can be dramatically increased by simply increasing reviewer transparency.
Alternatively, I wouldn't rule out removing the "ranking" section, and simply leaving a review/comment area. The problem with this is you run the risk of blurring the line between issue queue/support forum/and comment area. By including a ranking, you make it clear to the user they're writing a review, not asking for help. (I've only had 3 or 4 people use the review area to ask for support in the entire history of DrupalModules).
More developer input
Excellent point. This design needs more space for developers to reach out to users. A developer RSS/blog feed section is an excellent suggestion. Also, making the links section more prominent is a good idea. Screenshots, too. I'll see what I can do to incorporate these ideas into a new mockup.
Documentation
My goal for the links section is to allow developers (and users with the right permissions?) the ability to easily link to documentation, whether it's handbook pages or off-site tutorials. The current problem with the project pages is there's often 6 paragraphs of text between the user and the downloads, and every usability study will tell you users don't read text. That's one of the reasons why I show a teaser, and let the user expand the area (via jQuery slide down) by clicking [read more], if they're interested.
Some module maintainers use the project description as a place to dump all their documentation (and security warnings, which are another issue..), when it should really be moved to a handbook page. I think this model will encourage better documentation, and more succinct project descriptions.
gaming
There's a few interconnected issues here, I think this is worth going into (although I'm pretty sure there's an older thread with much more depth).
We've got two reasons to expose metrics on project pages:
For 1., simply displaying the information is probably not going to invite a vast amount of gaming - we already rank modules by issue queue statistics at http://drupal.org/project/issues/statistics - and I don't think anyone's trying to get to the top of that particular chart on purpose ;)
For 2. if there's any kind of ranking system, and this would certainly be useful within individual module categories if not contrib as a whole (which mapping solution should I use, as opposed to 'what's the most popular drupal module') - then we'll surely get people trying to game things. However, if rankings are spread around issue queue metrics, cvs commits, number of maintainers(?), split between major core versions (or module branches), ratings, reviews, dependencies etc. etc. - then we make it a full time job to keep up with the hydra of metrics which contribute to an overall ranking.
In terms of implementing these, I think we should concentrate on the least controversial first, or ones we already have stats for (issue queues, number of installs via update status, maybe a couple of others I'm not aware of) - and work on ways to get those aggregated and displayed. Once that's done, work on the more complex tasks, and look into rankings. That way we get quick wins fast, and leave the way open for many enhancements as time goes on.
Nice Layout
This looks good, and I want to say the same as many other comments: finally someone uses horizontal space, which makes up for much more information that can fit "above the fold".
Though there is one area, that I believe is kinda wasted:
By leaving out the extensive statistics (that look nice, but do not tell me much IMHO) in the top right section you would gain space that you could use for more relevant information. Simple download statiscics would be enough, and, if we got that, pingbacks of installed and active modules. Small but meaningful numbers are enough to express that ;) A third number might be the ranking of all Drupal modules with the other numbers weighed. Especially taking into account, that "the fold" in your layout is somewhere in the middle of your layout (most people run 1024x768), so on first sight, only the upper half is visible.
Life is a process
Life is a journey, not a destination
Prior threads worth considering and other comments
First of all, I'm glad to see John contributing to the discussion of projects on drupal.org. I hope he continues to be involved at all levels of the effort... we always need as many "hands on deck" as we can get. ;)
In terms of metrics, gaming, etc, there's no sense duplicating what's already been discussed here:
Project Quality Metrics on Drupal.org (meta document)
Folks should really read that thread and see if they have anything new to add to that discussion...
In terms of the screenshot and UI, there were also a lot of good ideas over here:
Project node UI redesign
I definitely agree that the proposed design puts too much emphasis on stats and reviews, at the expense of maintainer-provided value. Themes need screenshots. Modules need good summary descriptions about what they do (and in many cases, screenshots, too). Sure, some project descriptions are way too long-winded and push the download table too far below the fold. However, the care a maintainer puts into their project node is a fairly good indicator of their project's overall quality. A two sentence, misspelled and hard-to-understand "description" is even more of a red flag than a bunch of open issues in the queue. As many folks have pointed out -- tons of open issues could mean a deadbeat maintainer, but more likely, it means a huge fleet of users who don't always search for duplicates, make lots of feature requests, etc, etc. If the layout was such that the really important stuff (download table, screenshot, quicklinks, etc) were over to 1 side, and the description could flow down as long as necessary, that'd let maintainers use the space as much or as little as they wanted, without sacrificing the usability of their project node.
In terms of documentation for projects, IMHO it's totally stupid and weird that they live in "the handbook", completely detached from the projects themselves. Documentation should always be close to what it's documenting. That's why we like inline code comments to document the API, instead of having it live in a totally separate "handbook". The same principle should apply to projects. It'd also make it easier to have an implicit quality metric for projects about how much and how good the documentation is. If the "documentation" tab is empty on a project node, that would tell you a lot. ;)
I was going to write a bunch of stuff right here about why projects should be organic groups, but I didn't want to hijack this thread with that whole debate, so I posted it as a separate discussion: drupal.org projects as Organic Groups. Please give that a look, too.
Anyway, it's great to see so much interest and good ideas around how to improve the project nodes. I'll be the first to admit that the existing pages are pretty sucky for all sorts of reasons, and, with a few small exceptions, I've spent very little time/effort improving them...
Cheers,
-Derek
.
Funny, I was just thinking this morning that I wish the docs were more connected to the project. I was also thinking it would be cool to have project pages use panels like here on g.d.o. Making them a group is a great idea. I'll go over and read that post.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Themes need other considerations
Themes vs Modules: This mock up is not intended for themes, although parts of it could certainly apply. Themes have an entirely different set of needs not addressed by this layout.
About documentation: The download page should make documentation easy to find, but it shouldn't be the documentation. It's hard to define where the project description ends and documentation begins with the current setup. Creating a separation of description and documentation will encourage people to create documentation in the first place.
Documentation visibility is important, and my initial design didn't address that very well. I'm thinking about ways to improve it. Moving the links section up to the top is one step, but it's probably not enough. I initially started with two documentation blocks: "handbooks" and "external links", thinking the documentation links could be spread between them, but then I consolidated them into "links".
How docs are connected to the projects, in terms of IA, is another issue, and probably one for Mark and Leisa to tackle. If the current handbook model doesn't make sense, and I agree it's a bit odd, the redesign needs to address that.
Just for modules -- gotcha
"This mock up is not intended for themes, although parts of it could certainly apply. Themes have an entirely different set of needs not addressed by this layout."
That wasn't clear from your post (title is "... project pages", etc). But cool, glad you agree that different kinds of projects need different kinds of stuff on them. If all of project* was re-implemented or converted into CCK fields, we could have separate node types for the different kinds of projects, and have slightly different fields for theme projects than for module projects (for example).
"The download page should make documentation easy to find, but it shouldn't be the documentation."
Agreed. What I said here (and in my post about projects as OGs) is that each project should have its own mini-handbook, basically a whole "documentation" tab right on the project node itself, not that the project description should be a full-fledged user guide. I do think the description shouldn't be limited to a teaser, or at most a couple paragraphs -- we should let people use as much space as they need to describe their project. In many cases, 1 paragraph would be enough, but we shouldn't have a design that forces that to be the case.
That said, I'm not convinced that the project page should be considered "the download page" as its only role. For example, I think we're still going to want all sorts of project browsing views that let you quickly find what you want and download from there. To me, the project node is the "homepage" for the project. It's a download page, for sure, but it's also the central hub for that project for both end-users, contributors, and maintainers alike. I think it's important not to view these simply as glorified "download pages", since they have to serve a bunch of other roles, too.
So I had this thought while
So I had this thought while answering a support request in the Panels queue today, and had a thought...sorry if this has been posted somewhere already, I don't have time to scan through atm :)
I'm thinking of something that'd be a bit of a cross between a 'dev tracker' and an Amazon.com-style 'Was this review helpful?'. The response I wrote made me think of this because it's a moderately common question, and one that's easy enough to answer in a couple sentences. I chose to write a longer, more detailed explanation basically b/c it was my first post of the day, but I realized that the reason I tend to shy away from writing more detailed responses in issue queues is that those responses generally don't seem to get seen by people.
So, if we were to implement dev trackers - that is, nuttin more than a view which tracks all comments by the module developer on issues in that project's queue, sorted by how recent the comments are - then it'd help people to more quickly jump to such comments. If people were able to +1 these comments, though, then we could pop out another view that sorts on +1 scores.
Hmm...having written this out, it really seems to be the same as more general calls for allowing +1-ing of comments. The dev angle may or may not actually be that helpful - in many cases, it could ensure that you're getting the best, most accurate information, but it also might mean you miss some really useful stuff. Earl and I are hardly the only people who post useful information in the Panels queue...
The next step...
For anyone interested, it looks like Mark has taken my proposal, and some of the other suggestions from this thread, and put them into an HTML prototype:
http://drupal.markboultondesign.com/iteration2/project.html
More details here
OMG, that is beautiful!
OMG, that is beautiful! I love it!
-Mike Schinkel
http://mikeschinkel.com/
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
Here's my take
Love the start, just have 2 simple suggestions though I saw at least one of them earlier at least mentioned.
"Plaguing the world with Drupal; One Plone, Moodle, Wordpress, Joomla user at a time since 2005." ~ btopro
http://elearning.psu.edu/
http://elearning.psu.edu/projects/
http://elearning.psu.edu/drupalineducation/
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
No collapsible boxes
I'm not a big fan of collapsible boxes, I'd much prefer to be able to disable the blocks at the user profile instead. What would be ideal is something like iGoogle where you can add new blocks and move them around, but I guess that's not something we'll see in the near future.
Collapsible boxes that stay collapsed
What if the boxes stay collapsed when you collapse them for next time? It seems to me that we could do both, have boxes you can turn on/off on in the user profile, and using the collapse/expand button on the form itself.
Dave
Extremely Helpful
Fantastic! This information gives Drupal users sufficient information to make good module selections. We will all benefit from the information. John - good job and please let me know if I can help.
"Life is a fast strange trip, good thing we all have seats" (author unknown)
Great Idea, I think!
Overall, I think it's a great idea! As a new user, I definitely found the similar layout at drupalmodules more helpful than most of what was listed on the Drupal Project pages at drupal.org
I've now been using Drupal myself for a couple months at most, and I don't have a lot of time to spend on web design, currently - unfortunately. So having a more visual interface, where things are easier to find with the eye is most helpful.
Many of the ideas listed, I think, would also be great as well, but I'll not delve into repeating all of that. ;0)
I'm not so keen
Count me among the people who are not so keen on this approach. It's not that the review and download stats info is not useful - I do want to know that stuff - but I don't need to have it dominate the project page and I strongly agree that raising the profile of the documentation is way more important.
I would also suggest that there should be a set of tabs at the top:
Issues and docs as tabs is a
Issues and docs as tabs is a nice idea - it'd also be possible to do with the existing organic groups/panels support (once that's integrated into project.module).
Reviews shouldn't dominate
Reviews shouldn't dominate the project page, but I think a fivestar rating should. It gives a quick overview of how usable people think the module is.
Screenshot
Hi.
Perhaps the upper-most left block can be a large screenshot?
Nice! Beatiful! :)
Nice! Beatiful! :)
standard popularity statistics on every page?
About the popularity statistics of modules:
They are every 2 weeks calculated or so? Then it must be possible to integrate/copy that info only every two weeks after update, to all projects pages and wikis and other info pages about projects? Think copying (or caching) is better, in order not to load the latest statistics at every request.