Drupal.org re-design prototype iteration 9

looking alright, logo still the same tho. dont see why they need to change it anyway, isnt that just going to confuse people - stop being like microsoft.

i personally like the search on the front page as i use it all the time. i am always on the d.o website and i am always searching for something.

perhaps a little less superfluous content and a smaller header would be cool. what is the point of it from a users point of view? i cant see anything of value to having such a large header. why not make it the size that the header is on all other pages with drop downs for the extra search bits?

anyway, nothing much has changed since iteration 8 as far as i can see except for the search results.

--
theamoeba
http://www.amoebasys.com
http://www.itsolv.net
http://www.espresso-online.info (blog)

I agree with xmacinfo on his critique of http://drupal.markboultondesign.com/iteration9/modules.html -- there needs to be ways to filter by drupal core version (which we have now), browse by date (both most recent release and new modules), search modules, etc.

http://drupal.markboultondesign.com/iteration9/modules_detail.html has some great qualities, but there are a number of things that concern me:

a) There should be an easy way when viewing a module's project detail page to search issues and documentation specific to that module.

b) Downloading the code for that module should be one of the most visible tasks when looking at the module page. Especially if you had a long description and lots of screenshots, you have to scroll way down to find the download links. That's already a problem on d.o with modules with long descriptions, but I was hoping the new design would make that better, not worse.

c) I don't know what the "Community Rating" header at the top of the right sidebar means.

d) I'm worried about displaying the N most recent issues on that page with only their titles (no status, version, etc).

e) Please see Remove issue creation links from project pages for some thoughts about making it obvious to people viewing a project page how we want them to submit an issue, while still encouraging them to search for existing issues first... iteration #9 doesn't give someone viewing a module any hint on how to report a bug or request a feature. See also Make link to report bugs more clear and prominent. After figuring out what the hell this thing is and how to download it, my guess is that this is the 3rd most important action someone viewing a module page would want to do.

f) What's the difference between the "Links" section and the "Documentation" section in the right sidebar? Currently, they're the same links -- is that just wireframe cut+paste, an oversite, or a flaw in your design? ;)

g) To be blunt, the format and text associated with the download table is All Wrong(tm). ;) If you want the whole background on what we have now and why, see these issues and documents: http://drupal.org/handbook/cvs/releases/types, http://drupal.org/node/176776, http://drupal.org/node/313090#comment-1030517, http://drupal.org/node/313827. I'll try to briefly summarize:

• there are fundamentally two kinds of releases: official releases (fixed in time, never changing) and development snapshots (a snapshot regenerated every 12 hours of the latest code). -dev snapshots are inherently unstable (the code is constantly changing) so end-users are strongly encouraged not to use them on production websites if at all possible. official releases also come in many flavors, with different degrees of stability ("unstable", "alpha", "beta", "rc" (release candidate), and real releases).

• contrib maintainers can provide multiple versions of their code that are compatible with a given version of core. for each "branch" they're working on compatible with some version of core, the maintainer can decide if that branch is "supported" (works at all, maintainer plans to keep releasing bug fixes or at least security fixes). of all the branches compatible with a given version of core, the maintainer can select which one (and only one) is "recommended". The latest release from the recommended branch is the quick-link to "download" when browsing projects by a given drupal version, etc. The point of the different branches is so that maintainers can keep one branch stable and only do bug fixes there, while doing new development and adding features in another branch for the same version of core. This way, folks that need the stability can use the older branch (e.g. 6.x-1.?) while folks wanting to try out the latest features can use the newer branch (e.g. 6.x-2.?). In this case, the maintainer might mark both of them as supported, but recommend that new users start with the most recent 6.x-1.? release (e.g. 6.x-1.4). [Edited to use '?' instead of '*' since markdown was screwing up the formatting]

So, this whole complicated situation is what we try to visually represent with the existing table, colors, icons and text. I'm all for making the download button standout like you have it. But, the rest of the changes in iteration9 (and earlier) just confuse the issue. For example, what does "Developer Snapshot (Not recommended)" mean above a table where all the rows in the table say their status is "Recommended"? Also, there can only be one "recommended" version for each version of core. So, in your example, 5.x-2.0-alpha3 and 5.x-1.9 can't both be recommended. In that case, 5.x-1.9 should be recommended, and 5.x-2.0-alpha3 should be "supported".

h) Aren't you worried about the "download" button being all the way at the other side of the table from the version? In core, we used to have a usability problem on the modules page where the name and description were left and center, and a checkbox to enable/disable the module was all the way to the right. People would constantly have trouble making sure they were operating on the correct module. The solution was to put the checkbox all the way to the left so that it was right next to the name. In this case, all the way left would be weird (seeing download before you see what it is). But, I think the order should probably be something like: version, date, notes, download, size, status. I don't mind status being all the way to the right if we continue to use colors to show the status for the whole row.

i) Others have mentioned this before, but I wanted to reiterate: for theme project pages, I think a screenshot should be above the fold, inline with the description text. There's been talk that theme projects need slightly different stuff than module projects, so it'd be great to see another iteration with some specific thought put into theme pages.

j) There's no way via the current iteration to view CVS activity for the project, other than the little totals next to the maintainer's names. You should be able to see all commits on the project, some commit statistics (total #, most recent, # in the last month?, etc).

k) I still think there are some great ideas from Project node UI redesign that aren't represented in this draft yet. For example, I really like the Issues box at http://groups.drupal.org/files/project-module-ui-3.png -- that's some incredibly useful functionality, both for insiders and outsiders.

l) There's been talk of having case studies that nodereference all the modules used for the site. Presumably, we'd want to link back from a module to all the case studies that refer to it. Any idea where that would go and how it'd look?

m) I'm worried that the tabs at the top of the module page show you a bunch of other kinds of projects. It seems like there's so much stuff for each project (especially if projects are groups, with their own wikis, polls, forums, documentation, reviews, blah blah) that it'd make sense to have a different way to navigate to other kinds of "D+E" items, and use the tabs at the top of the project to navigate to other things related to this particular project. For example, I could imagine "Documentation", "Issues", "Reviews", "Browse all releases", "Usage statistics" (details), etc all as tabs on the project pages. It doesn't have to work this way, but for example, I think the tabs across various group pages on this site are a good way to show people the kinds of things they can do/learn when looking at a given group.

n) I'm wondering if y'all have any thoughts or suggestions on how the issue queue pages should change for the new site. For example: http://drupal.org/project/issues/drupal -- this is one of the key pages that insiders use, and we're trying to get outsiders to make more use of it, too. This is where you land when you click on the bold "View all issues" link from your latest mockup. There are a few obvious fixes (like being able to filter on version and component directly on that page, instead of needing to use "Advanced search"). But, otherwise, any ideas to make that better, easier to use, fit in more nicely with the rest of the site's design?

Geeze, that's a lot. I better stop now so there's a chance folks will actually read most/all of this. ;)

Thanks,
-Derek

The documentation pages look awesome now, congratulations!

Another section I think needs help is the news section: http://drupal.markboultondesign.com/iteration9/news.html

I see that news from both d.o as the Drupal Planet are now mixed all on one page, with comments enabled for Drupal Planet items as well. I think it's best to keep separate pages for Drupal News (for instance: "everyone is able to edit documentation!") and aggregated content from the Drupal Planet. Also, comments on the aggregated content should go on the original article and not on the d.o aggregated content.
I started a discussion about this two months ago on the redesign group and set up a live prototype recently: http://groups.drupal.org/node/15332#comment-56774

I realize that this comment is coming from left field, but please bear with me :)

Seeing the different tabs on the project nodes (eg. D&EHome, Modules, etc.) made me think of something. I work in the medical field, and D&E is the very commonly used abbreviation for a type of surgical abortion (see, for example, http://www.webmd.com/a-to-z-guides/dilation-and-evacuation-de-for-abortion).

Given that Downloads and Extensions is a bit long, I suspect that D&E will be used frequently in various text on d.o (issue queues, etc.) as an abbreviation. It's also currently used on one of the tabs in the design prototype. I personally wouldn't be bothered that a Google search for "d&e" might result in a bunch of d.o hits mixed between several pages about the procedure, but this might be an association that we'd rather not have.

Just some food for thought.

I wish the docs wiki example page (http://drupal.markboultondesign.com/iteration9/documentation_article.html) had quality flags like wikipedia... For instance, if I'm reading a documentation page and notice that the documentation is out of date or not complete, I would like to edit that page and add "[notcomplete]" and on the page it would show a large banner stating that a user has noted that this documentation is not complete, urging the community to address this page.

I know the module sections are being worked on. It will be VERY interesting to see iteration 10.

Good job guys!

MJ

On http://drupal.markboultondesign.com/iteration9/download.html, the translations link is a "please click here" style link. Those went out of vogue in the late 90s. :-) Links should either be contextual text or a header, whichever makes sense in that case (or both).

On http://drupal.markboultondesign.com/iteration9/modules_detail.html, I'm still really digging this "group per module" concept. However, while there's a nice big button to join a group I don't see how to actually get to the group. There's a link to join it, there's links to a few recent new posts (but without an indication of how active they are; sometimes a post will get new comments months after it's created), but no equivalent of "view all issues". Coming from a more traditional OG setup (vis, g.d.o), I feel like there's another home page that's missing.

I'd also echo everything dww said above regarding the download table. There's a ridiculous amount of information to be captured there, and I think this iteration is still a step backward in that regard from the current design (although the current design still has huge problems with it, as have been well-documented elsewhere).

Are the screenshots intended to be thumbnails? Do those open in a new page? Do those open in a thickbox or lightbox popup?

Possibly the wrong time to be mentioning this, but "Drupal Homepage" as the top link sounds very, eh, 90s. "Drupal Home" seems more warm and welcoming rather than "see my homepage, it has kittens!"

I really appreciate http://groups.drupal.org/node/16950#comment-57894 and the picture at http://groups.drupal.org/files/project-module-ui-3.png, though IMHO it misses a few important things like View all releases and Related discussions and color separation of stable and dev versions.

The current way of presentation of Drupal modules to me is quite fantastic and I hope in this frenzy for something new and more user-friendiliness, the current friendiliness is not lost. For example, the current module pages present all the important data in a nice effective linear way ( and unlike the above png which pushes the download links on right hand side, which in many cases is the 'extra' area like area for ads, personal navi links etc ).

The backward compatibility of a new design should be there, that is, current users should not feel lost or expected to find unexpected location of links.

There is also need to survey are we losing the simplicity ? The current drupal modules pages are quite simple and yet immensely functional. Instead of "breaking" them what was needed was perhaps enhancements only.

About people not finding things or posting same things repeatedly, I posted these somewhere here before and will like to repeat :

There are people (and sometimes I may be one of those) who will jump at posting forum posts or issues without checking with the existing stuffs or docu.s. The best way to stop these is to have a knowledge-base type of thing, the one that is used when submitting support ticket to your webhosts. That is, while you type your issue/post or after you hit submit, instead of submitting directly it presents with relevant links of solution or posts related to the submitted question - its a great cool feature I have found handy and for webhosts it reduces ticket loads to at least by 50%.

The other thing that we lack in drupal is seeing stuffs on hover or reply on hover - this helps to read or reply certain posts or issues faster. Same is true if we could have personally star/flag a module/ issue or unstar/unflag we would not have to scrawl immensely long personal tracker always.

(The decreased font size is another -1 as we are accustomed to the nicely large, clear fonts, something should be better or keep same, don't make things smaller)

1. I think it is important for Drupal's long term success and health that we foster a test-driven development community. Therefore, I think it would be good if there was a test summary on the module pages (http://drupal.markboultondesign.com/iteration9/modules_detail.html). I hope that this can become an important metric to measure the quality of a module. Can we add a line "Test results"? The test results summary could read:

   • Module has no tests. Meh.
   • Module has x% test coverage and all tests succeed.
   • Module has x% test coverage, but x out of y tests fail.

2. Some modules have a really long description. I wonder how things look like when the description is really long.

3. The 'Join group' button is the most prominent item on the page. It is a bit of a mystery as to why you'd want to join that group. What is the purpose of this group? Joining a group is not among the actions I can think of. Actions I can think of are: download, request feature, get support, report bug, contribute, view CVS activity, browse the code, visit the API documentation, etc.

4. Being able to filter modules by version seems key.

5. What happens when I click on one of these tags? What does the resulting page look like?

6. I'm still not convinced the reviews will work. People will use it to report bugs and to requests features. Also, how does it scale? Certain modules will have hundreds of reviews.

I'm not sure I grok the difference between 'Docs home' and 'Index'. Also, wouldn't the index have thousands of links? I'm not sure I understand how we are going to build the index and how we keep it meaningful.

Should there be a contact form somewhere? I think there need to be a place for people to report certain issues (e.g. security issues).

I realize some may seek to dismiss the following comments because of my work role. But I believe my comments are not exclusively self-seeking, and are representative of an important voice in the community - the commercial voice. My comments, and the d.o site requirements they represent, are equally as valid as non-commercial comments because of the number of commercial companies contributing substantially to Drupal, and the unique relationship they wish to have with Drupal.org.

At the core of my core comments is an assertion that "advertising" (as in graphic slug placement) should not be the only way commercial organizations are represented on drupal.org. There are people who want to use Drupal who have more money than time, and are not seeking to "do it themselves," or become participating members of the Drupal community. Instead, they mostly want to build their own community within their interest group, and (instead) want to hire somebody who is. In addition, the very existence of a substantial commercial community around Drupal will make Drupal palatable to new Drupal users at companies who wouldn't adopt Drupal unless such a commercial community existed.

So links to commercial methods of doing things should also be shown in-line -- text with links -- at places where commercial "help" would be useful to see. One link to "Marketplace" at the top menu is insufficient; people's eyes won't magically gravitate to that link when they're in a given context searching for help on something. And one or two locations for banner ads isn't enough either; these same people who would otherwise buy help are generally subconsciously "trained" to avoid banner ads, often because they think it's only purchased by the higher bidder.

People seeking commercial help need in-context entry points to find a concentration of information about commercial suppliers, grouped into types. This may range from paid site development, to hosting, to commercial support.

To suggest how I believe this should be accomplished, I've marked up various pages from iteration 8 with screenshots / notes. Since they are all images, I've posted them on flickr, link to them here, and provide commentary here - including sample / proposed text (where appropriate). These are in an order that makes sense to me (not homepage-down order).

Get started page: http://www.flickr.com/photos/50231055@N00/3055462491/
A new blue (link-level) section: "Commercial support"
Text: Drupal also has a big commercial community ready to help you too, from web designers to commercial distributions and hosting providers.

About: http://www.flickr.com/photos/50231055@N00/3055462457/
New blue / heading section: "Industry"
Text: Drupal isn't just built for, or by do-it-yourselfer's either. Hundreds of companies around the globe make it their business to offer a wide variety of commercial services for Drupal. You'll find anything you need available in the Drupal.org marketplace, whether you're looking for well-capitalized companies providing global support or Drupal, or small individual web developers, larger web studios, or paid - or even free - Drupal hosting providers. This ever-growing community of commercial support means that choosing Drupal will be a safe, and powerful choice for your community, organization, or business.

Community & Support: http://www.flickr.com/photos/50231055@N00/3055491953/ and http://www.flickr.com/photos/50231055@N00/3055462399/
(No specific text here; general comments.) There are really two screenshots here that address the same issue. The general issue here is that there is a presumption that "Community = Support." Look, for instance, at the upper right corner - where it says "Where is our community," and that the only blocks on the side are places where self-help can be found. It (again) doesn't address the needs of Drupal users who have more money than time.

I think also that this page needs to act as a bit of a "landing" page for the rest of the tabs.

Suggestions to resolve this could include:

• The "home" tab of this page needs to make sure it provides summaries of, and links into all the other tabs, and not rely on people picking up the tabs as navigation into information;
• There needs to be a tab for Commercial Support. The contents of this tab could be either some text about it, and then a link into the Marketplace page, or it could be itself another "view" of the types of content in the Marketplace.
• This could alternately live in the lists of blocks in the right column, but since it is just one link, it seems to not match the structure of the rest of that column.

Download & Extend: http://www.flickr.com/photos/50231055@N00/3055462651/
Add a tab for "Commercial Distributions." This has precedence in other open source projects; the best example is probably Eclipse. See http://www.eclipse.org/downloads/ (click "Member Distros" tab). With many other open source projects, there is a company from which the project flows; Drupal is different, since there isn't one such company. However, this is why the Eclipse example is so instructive, since it (too) is primarily community-driven (despite an IBM genesis). Therefore, I assert that a Commercial Distributions tab here is additive, serves a substantial need for a non-trivial audience (those with more money than time), and deserves to exist here.

Footer menu: http://www.flickr.com/photos/50231055@N00/3056299344/
See "Get help" insertion. I think this should link to the either the "Community & Support" page, or to the "Support" tab of that page.

Does this help?

Would love to have "Documentation" highlighted somehow on the top menu here (and on all pages under documentation): http://drupal.markboultondesign.com/iteration9/documentation.html (And the same for all the other pages, of course)

Should make it a lot easier to navigate the top menu.

An alternative to logo looking mambo-ish - see attachments