Exploring Solutions: Better Product/Project/Module pages

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Product/Module pages are the entry point to the issue queue for many people and one of our opportunties to both increase the quality of the additions to the queue (bug reports and feature requests), to direct support queries appropriately, and also to recruit new contributors and recognise existing contributors - to that end they definitely qualify for some Prairie Initiative attention.

I saw a great post on this topic here: http://growingventuresolutions.com/blog/module-owners-how-make-your-modu... and another one here: http://www.drupalmill.com/blog/thomas/2011/02/17/projectapp-store-and-fu...

Would be great to collect some thoughts/ideas etc. on this page and how it could work better here?

(including posts from other parts of Drupal.org and I know there were a few good suggestions on this already in this group)

Tasks

tsvenson - I am working with Thomas Moseler on a mockup based on the outline in the Drupal Mill blog post linked to above, as well as incorporate ideas presented in the other post and in this group. Our intention is to have something ready to be posted in this group within a week or so.

Prototypes

Consolidate your visual ideas by attaching your mock-ups/prototypes here
Proposal by @tsvenson and @eigentor: Mockup with tabs

Comments

Non-GNU/GPL on Drupal.com/org

MGParisi's picture

I would be greatly against an app store that is in anyway associated with Drupal.org or .com! Developers spend thousands of hours giving away their work for free only too see someone else come and then post their module for money. Joomla has gone this route and as I see it, it is failing and will tear their community apart.

I don't want to see Support Issues being REMOVED from Modules. What I would like is to offer support in the Module sections. But to do this we must provide tools for people to view unanswered support issues across all modules and to provide a subscribe to support issue query to the modules that you use and know.

I think support and documentation directly linked to a project rather then in some random post provides users with the best chances to find answers they need. But I do not want to dump these support issues on the module maintainers, so we should provide tools to allow the community to provide this support


--Sig--
Owner of Toastyart a Drupal based High Quality Art Gallery.

See it more as a product store

tsvenson's picture

I take it you are referring to my Drupal Mill blog post?

If so, it is not about making an app store in the sense that users will have to pay to download the projects. It is more about how we can take ideas from app stores and use them in a way that suites an OS project.

Nor is support taken away, there is a tab for that. But the idea is to make the project pages better so less support will be needed. Focus is meant to be on what the project can do and the documentation available for it. Giving users a better overview of what documentation, screencasts, howto's etc that is available, then they will be less likely to use support as their easy way to find out things.

--
/thomas
T: @tsvenson | S: tsvenson.com

Modules

MGParisi's picture

Understand that a place for Q&A is going to be necessary. Now we can push this into a general forum and/or IRC channel, or we can associate these support requests with the modules themselves. Yes I beleive that Documentation should ALSO belong to a module, but I think attaching support to a module will allow people to find issues already asked. It will also help with future development of Search.

Part of the problem is that documentation is version specific. If I am running Drupal 6, I do not want Drupal 5 documentation. IT goes the same way with modules. Allot of documentation is written for Views 2, but now that views 3 is out, We need to be able to keep view 2's documentation but be able to continue to develop documentation for newer versions.

What plagues us is the inability to remove versioning from our Querry. I was looking for help and used the search and came up with a bunch of stuff from back when Drupal 4 is out. That documentation is important if your running a legacy system, but I am working with Drupal 7.

What you want to do is associate content with objects. Content with Modules, Content with Groups or Content with Users.


--Sig--
Owner of Toastyart a Drupal based High Quality Art Gallery.

Separating versions with big switch

tsvenson's picture

Yes, separating major versions will be in the mockup. Hopefully it will be something that can be made sitewide as well so you don't have to do it on every section separate.

The basic idea is that when you set it to D7, then all tabs will be filtered and only show information that is for D7.

I do understand that parts of this, especially version filtering, can be tricky due to how things are now, but if this mockup is of the liking to the community, I hope it will help pushing things in that direction.

--
/thomas
T: @tsvenson | S: tsvenson.com

Oh how I would love for

davidhernandez's picture

Oh how I would love for documentation to have tabs by Drupal version, like api.drupal.org.

Good thought

wfx's picture

I like the Integrated Fundraising idea. Policing that could be a headache but worthwhile to inspire developers to port their modules or fix bugs if not otherwise inclined to do so.

Fundraising partner

tsvenson's picture

I have done a little more research about it and I think the best way would be to partner up with a third party that can provide that kind of service. DA would then be able to negotiate and agreement and get a cut of the fee that service would take.

It will be important to find the right partner though, especially making sure they can cover as many countries in the world as possible.

Kickstarter for example currently requires a US bank account:

I’m not in the US. Can I fund my project on Kickstarter?
Currently a US bank account is required to start a project. This is a restriction by Amazon Payments, our payments processor. If you don't have a US bank account and are interested in starting a project, we appreciate your patience (we’re working on it!). Please note that anyone, anywhere (with a major credit card) can pledge to any project on Kickstarter.

As you can see they are working on it, but that would be a limitation at the moment, unless DA can work something out and be a middleman here if that is possible.

I know that things like ChipIn and other have been used before and not really worked well. However, having an official partner in this would make a big difference and also make it official. Therefore I believe it would have a much greater chance of succeeding as well.

I also see this as something that can be really useful for both Drupal Core and the *.d.o infrastructure to raise funds to be able to quicker implement new features or major initiatives on *.d.o that are needed.

I will include it in the mockup, but since it will be on its own tab it is of course also easy to take out from it.

--
/thomas
T: @tsvenson | S: tsvenson.com

"App Store"

MGParisi's picture

Be VERY carefull how you use the term "App Store" in an association with Drupal Apps. I understand what your attempting to do, but come up with a plan, and then associate its SUCCESS in references to an App Store. I will warn you that you wont get far with your ideas if you come across as making profits for Drupal.

You will have too spoon feed some of us.


--Sig--
Owner of Toastyart a Drupal based High Quality Art Gallery.

...

Jeff Burnz's picture

Any attempt to monetize Drupal core or contrib development will experience push back like you never knew existed. This is unpalatable to an enormous sector of our community and far too controversial concept to be discussed or even considered in the scope of project page do-over. I suggest you drop this aspect of the original plan and focus on the support issues as they stand now, introducing radical new things like funding services is a whole other issue, and not one I or thousands of other developers would support, in fact I will fight it with every ounce of my being to keep this out because ultimately it will rip the community in two.

This is a design discussion!

yoroy's picture

Jeez, talk about getting a discussion of to a false start. Could you all please not get too riled up about a couple of words please? And think about what we can do to improve our Project pages? This is a design discussion where we want to come up with multiple ideas for improving a visit to a drupal.org project page. For this we need many ideas. Good ones, bad ones, silly ones, small ones and plain impossible grandiose ones. This is not the thread to discuss business models or how bad marketing smells or whatever.

This is a brainstorm, where we generate multiple ideas for improving project pages. The most important rule for a brainstorm is that you do not say "No" or "impossible". Anything goes.

We start selecting ideas when we have a sufficient amount of sketches. If you don't have ideas to add, just refrain from commenting for a bit instead of killing the conversation before it even got started. Thank you.

You're welcome.

I think you have your answer,

MGParisi's picture

I think you have your answer, just mentioning store + drupal.org derails the conversation and makes any progress you where attempting to make near impossible. It may not be the answer you wanted. expected or like... but it is as real as it gets.

I am really sorry that your response is not what you wanted, but thats the way it is. The idea is not dead, however the word "store" will probably derail the conversation and kill the topic. I hope this is not the case, but even if it doesnt kill it, any purposal based on this thread may equally be as damaging.

It is extremely political, and extremely tough to get reform past. best hava a bullet proof approach as you will be knocked around in every conceivable manor.


--Sig--
Owner of Toastyart a Drupal based High Quality Art Gallery.

No censorship

leisareichelt's picture

As @yoroy said, we are here to explore ideas and good ideas and inspiration comes from all kinds of places. We are not here to implement an app store or create a business model for drupal developers - that may or may not be a good idea but we have quite enough on our plate here with out discussing that.

It is not acceptable to come into a discussion like this and dictate to the community what they may and may not discuss. You are entitled to share your view as vigorously as you like - frankly, I've come to expect and mostly respect that from the Drupal community, but please don't come here and attempt to shut down a conversation. That's not how the Drupal community operates.

It's a timely reminder to all of us to be thoughtful about the language we choose to use. You may be passionate, busy and right, but by using aggressive language and tone you make it much less likely that other people will come and partipate in helping us get to the outcomes we want to which - if you recall - are all about getting more people to participate!

Now, let's get back to work.

leisa reichelt - disambiguity.com
@leisa

Dictating?

MGParisi's picture

I am sorry, I guess I was a bit harsh. I would like to see improvements being made and discussions being successful. You are correct, and I do my best to keep things friendly. Please excuse my post, it was meant to express concern, but failed miserably!


--Sig--
Owner of Toastyart a Drupal based High Quality Art Gallery.

And we have specific goals...

leisareichelt's picture

Also, we've set out some fairly specific goals around collaboration, increasing efficiency and community building for this project.
(That's a reminder for any one both pitching and responding to ideas!)

leisa reichelt - disambiguity.com
@leisa

Project metrics

leisareichelt's picture

just came across this discussion which is v relevant : http://groups.drupal.org/node/86819 (Issue tracking and software releases: Project metrics for drupal.org redesign)

leisa reichelt - disambiguity.com
@leisa

Blog

wfx's picture

On your blog you mention that this idea is modeled in part on Quora and Open Ideo. How do those systems compare to StackExchange? My first impression is that Stack seems the most fleshed but maybe I'm looking at all the bells and whistles they throw at you when you log in. I haven't extensively used any of those systems though StackExchange frequently comes is in my Google results.
Other thoughts - the "call in the troops" or Call to Action alert is a good idea and would be a nice feature if it isn't over used as to be ineffective.

Stack & Quora have a lot in common...

leisareichelt's picture

In terms of the solutions I'm suggesting we take inspiration from, Stack Exchange and Quora have many similarities. I think Quora is more subtle in the way it rewards you for participation and possibly handles the folksonomy (tags/topics) more elegantly. I'm always put off by SE's blatant karma model, but that may just be me - perhaps it provides a lot of value to the system/communities.

The inspiration from Open IDEO is more the idea of phasing the project and making those phases visibly different and supporting different kinds of activity/interaction.

Btw- I had forgotten that Quora still requires an invite - if anyone needs/wants one, email me and I'll hook you up :)

leisa reichelt - disambiguity.com
@leisa

I don't think it requires an

davidhernandez's picture

I don't think it requires an invite. (?) I signed up without any problem, unless I'm missing features, or something.

Thanks for the rundown of

wfx's picture

Thanks for the rundown of services. I can see how the Karma point system could get out of hand though I'm still a little unsure on how to reward participation.
I hadn't seen Open IDEO until this post but I really like it. It's a a very well thought out process for project development.

Easier to add Screenshots or even "customer images"

heather's picture

Easier to add Screenshots or even "customer images"

Screenshots add considerable value to a project description, and I think Lisa Rex actually glosses over how crucial they are.

At DrupalCon Chicago, I proposed to ArianeK to do a screenshot sprint. I think her first response was a slumped "oh nooooo!" and she said it was going to create a mountain of work 'for her'. Which I didn't understand... She thought she would have to ad the screenshots herself via documentation.

I said, no, my proposal was to get screenshots for projects created and then submitted via the project's issue queue. Ariane still was not satisfied saying that module maintainers don't have the necessary privileges to add the screenshots. And it would still create 'work'.

I found the conversation frustrating - because the system seems utterly broken.

Amazon leverages readers to be able to add their own 'customer images'. I think making it easier to show a module/theme in use on a project page, and giving the maintainer any veto power needed would be a boon to this broken process.

Breaking the project pages

markwk's picture

Breaking the project pages into more discreet sections is a good idea.

One of the problems I run into when I see a project page is how often some developers turn their pages into a nightmare of what it is, what it will be, and a roadmap. I think is important for the project to simply display what it is and how to use for an end-user looking to build sites, not develop them.

It would be good to restrict developer commentary to tabbed sections like "development" or "roadmap."

Sometimes really great and stable modules might appear like a "work in progress" based on how the project page is displayed.

Yes - more prioritisation and structure

LewisNyman's picture

I personally think we need to look at the most common tasks and stick some calls to action front and center.

We should also think about hiding content that is not commonly used.

I'm going to have a bit of a think about the architechture and see if I can do a mockup based on the Views page.

Drupal Module Page prototype

gdzine's picture

I have done one simple prototype (Draft Version) and want to share with you all for comments, I can complete the rest of it if you all feel so.

Mockup is available for view at Google Doc

Looking for your comments/suggestions.

~~~~~~~~~~: http://gdzine.net | http://twitter.com/gdzinenet |info@gdzine.net :~~~~~~~~~~

Another mockup

yoroy's picture

projectpage - Justinmind Prototyper

See the big version Here. Click the right button (cursor with comment balloon) in the top left of the screen to see the comments.

You can respond to existing comments or add your own there. Use the link above and you can comment without logging in but that will be under an email adres of mine. Go have a look! Thanks.

Need More UI discussion

BeWhy's picture

also check out the UI with input from none other than webchick and Miles back on 07:

http://groups.drupal.org/node/6186#comment-17797

what you don't know will inspire you

Prototype #3

LewisNyman's picture

Prototype number three. Based on the Views project page.

Key changes

  • Clear call to action, an obvious addition.
  • I've updated the font size of the h1, there is a gap in the current style guide. It assumes that the h1 is always the logo, which is not the case.
  • I've attempted to bring a solid structure to the main content section, this is focused at site builders and early Drupal users. This should be consistent across all projects.
  • The project page is completely split into each version of Drupal, ideally Drupal.org would remember the visitors preferences
  • The sidebar is now the 'hub' for issues and development, people are only window shopping for modules can completely ignore this section.
  • The 'Popular Issues' is intended to act as the 'hook' for returning Drupal users look for an issue or a fix. The common or major ones will no doubt be here. If they can't find them in this list, the user is encoraged to search in the block below it.
  • Advertising Section: This is me dipping my toe in some kind of reward system for module maintainers. They get one block where they can enter an advert to display on their project page. This must conform to the current Drupal.org style guide. Repeat offenders should get a slap and advertising priviliedges temporarily or permanently removed. This could be potentially huge in terms of sponsorship. I am aware this is a controversial subject.

I've gone for a html/css prototype here because:

  • It allows me to work with real content.
  • It allows us to work with what we already have, I don't believe this is problem needs complete overhaul, just an optimisation/realignment
  • I can easily conform to the current branding style guide.
  • Others can build off my work.

If there is interest I'll put this up in a Drupal.org Sandbox or on github so others can fork this prototype and add to it. I'd have to figure out how first ;-).

Some initial comments

yoroy's picture

Thank you for taking the time to set this up!

  • It's not clear to me if those green 7 / 6 / 5 links are download buttons or tabs? As tabs for pages per version I'm not sure that is a good idea. Views or any other module largely solves the same problems across core versions, right? I think that split (if necessary at all) should not be top-evel like this. Right now it is especially confusing because the actual content of this page has info about multiple versions of the module still.
  • This design does not fix one of the main issues with the current design, which is that the actual download links get pushed far far down the page. (Ah, now I see the big 'Downloads' button jumps to the downloads section. Sort-of-nice but still a bit of a workaround instead of an actual solution imo)
  • Maintainers info in the content? Seems ideal sidebar material to me.
  • Project information at the very bottom? Quite important info that communicates project health at a quick glance.
  • I think this design doesn't really work to direct support questions to the right place. Do you have thoughts on this?
  • Are issues ever 'popular'? :) 'Active' seems better.
  • An advertising block would be good. Don't worry about the rules too much, and keep this focussed on the design ;-)
  • Could also think about how maintainers can communicate 'available for paid custom work' (ties in with routing support requests as well)

All in the spirit of constructive critique! Thoughts? Thanks again.

Differentiate between anonymous and logged in visits

yoroy's picture

It is probably a good idea to think about what info is relevant to everybody, which to anon visitors (evaluators?) and logged in visitors (support, issues, contributions).

Great Stuff

LewisNyman's picture

Thanks for the comments, it's all golden.

First off, we obviously need to get this up so others can edit this collaboratively.
It took me a good hour to figure it out but it is up as a drupal.org sandbox.

For now to keep the ball rolling I'll go through the issues you raised.

  1. Maybe they aren't obviously tabs, this might actually be a site wide issue. The styling has not been changed. What I did just do is add the secondary links to make the primary tabs appear more tab like. I do think that spliting up the information per version of Drupal is a good way to go. Not only is it consistent with the UI for api.drupal.org but it allows us to hide information that the user really doesn't need or want to see.
  2. The current solution may not be enough but we don't want to go too far with this, we can't assume that the user wants the current stable but at the same time we don't want to scare them off with too many choices.
    Didn't Firefox used to have a download button that was also a dropdown?
  3. I don't know why I moved it over the main content. It is now moved back into the sidebar.
  4. Project information is important, as least some of it. Let's not feel like it all needs to go up top, some of it is clearly more useful then others.
  5. Agreed, 'Popular' is a terrible word, I've changed the wording to more accurately describe the concept. I think 'Active' might get confused with 'Open' for new users.

This prototype is kind of focused on evaluators, at least at this stage. I think it's going to get to a point where we will have to admit that we can't get a layout that works for evaluators, support seekers and contributors. I think we will have to work very closely with the issue queue redesign to make sure all the good stuff bubbles up to the project page sidebar.

Let's call this Prototype 3 Version 2.

Tabs and Drupal versions

oadaeh's picture

After reviewing your layout, I had this thought. Most (if not all) modules are going to have some level of information that will be the same for all versions (like the Overview). It makes sense to me to have that information above the tabs, and only put the information that might actually change between Drupal versions (like the Requirements) below the tabs. That might end up putting the tabs significantly farther down the page (depending on the amount of information), but I think it will be confusing to click on a tab and not see any change, which is very likely in the current layout.

Potentially yes

LewisNyman's picture

You are right. It is possible that different Drupal versions will have the same content.

As long as module maintainers don't have to copy and paste dulpicate content I see this as an acceptable trade off. The main aim here is to remove as much information that is of no use to the visitor. The Views module is a great example of this, there are two previously versions of Views that just don't exist in Drupal 7.

Obviously this will differ from module to module. The overview and features are examples of fields that defnitely will stay the same through out. It might be worth looking at integrating a project information splash area similar to yoroy's mockup.

Progress

eigentor's picture

Thomas Svenson and me have our Mockup finished and will post it later today. Will be quite different from this one, sorry for that.

Life is a journey, not a destination

more different approaches = good

leisareichelt's picture

it's great to have a range of different approaches to the same problem area - this is how good design happens :)
having a range of different designs to review and evaluate is much better than fixating on the first solution we come up with.

I'm going to pitch in a wireframe when I get half a chance too, will probably be different again!

leisa reichelt - disambiguity.com
@leisa

New Mockup proposal based on tabs

tsvenson's picture

Finally @eiginator and I have managed to finish the first draft version of our proposal for how the project pages can be redesigned.

We have focused on trying to find a clean design that is easy to navigate and that puts focus on using the projects.

One of the main features with our idea is the ability to filter all tabs for the major version of Drupal the visitor is using. Once set to Drupal 7, only Drupal 7 related information will be visible in the tabs.

Another goal is to make it as easy to understand and navigate as possible and use a language that is not technical, but still explain what each tab, etc is about.

We will follow up with more mockups for each of the individual tabs, but wanted to give you all a glimpse on what we have been working on as well as get some feedback about what you like and/or dislike.

Head over and have a look at https://undpaul.notableapp.com/posts/64bb90be1ebd4ed73304352a5b7577614fc...

--
/thomas
T: @tsvenson | S: tsvenson.com

I'll comment here instead of

davidhernandez's picture

I'll comment here instead of there. I like the version drop down, and tabs with documentation, etc. I like the collapsed description. I find many are very long, and make it harder to get to the download link at the bottom.

I don't think you can make the screen shot mandatory. Not ever module has something to show. And I'm not in favor of limiting voting to only people that write a review.

Overall, fairly concise. Let's hope it doesn't get cluttered.

Very nice

wfx's picture

I like the design, here's my first impression.

The Good

I like the Nav bar at the top, that really encapsulates pretty much any aspect of a module you might want.

1) Keeping the intro short will prevent the Wall of Text problem we have now.

3) Collapsing a lot of the data makes for a cleaner page and you can see the info you need right way - How do I download it, Who maintains it, Where do I get support.

Challenges

1) Enforcing a character limit would work on a Private Sector site but in my experience Open Source communities go nuts when you tell them they can't do something like post over a certain number of characters.

My suggestion - I'd like to see a set character limit but if that can't be agreed to by the community an alternative is to set a character counter up that reminds that user that they are over X number of characters. I like your way better but I am dubious as to whether it will fly.

2) I guess my question about requiring Image Uploads is how can we fix the current process so it doesn't add overhead for the Docs team. I'm sure this is locked down at present to keep vulgar or inappropriate images off the pages. Or maybe there's another reason that goes back to the far gone days Drupal's past.

My suggestion - If process can't be improved for images a compromise would be let users upload, it goes into queue for approval but in the meantime a placeholder image goes up that says "There are screenshots for this module available. Promote this in the Issue Queue to get them published."
Again, a workaround for a currently broken process but I'm taking the perspective that what we will end up with will be a hybrid of what we want - the new design - and what we already have as far as process.

6) This is similar to the concerns in issue #1. People's heads will explode if mandated.

All said, I like this design quite a bit.

I LOVE this design. Very

cweagans's picture

I LOVE this design. Very nice. I agree with the anti-mandatory-screenshot sentiment previously expressed. That policy would not be good for things like Voting API or Entity API.

--
Cameron Eagans
http://cweagans.net

Good elements here

LewisNyman's picture

Like the idea of a dropdown box for Drupal version and the hidden content.

Now we are getting somewhere

sk33lz's picture

I really like the tabbed version. I still think that the download links need to be in the main viewport where the maintainers are listed. We are definitely on the right track with this sort of revamp to the project pages though.

.

Michelle's picture

I like it except for a couple things.

One is the limitation on the free text area. I understand wanting to avoid the "wall of text" but projects have a lot of text for a reason. Simply saying to the maintainer they are no longer allowed to give information they think is important isn't the answer. The popup mentions possibly having another tab for a full description, which would work as long as people got in the habit of using it.

The other is the requirement of a screenshot. While screenshots are nice, I don't think they should be mandatory. Some modules, especially API modules, don't really have a need for them. Maybe mandatory for themes?

Otherwise, I think it's quite an improvement.

Michelle


My blog, mostly about Drupal: Shell Multimedia

Tabbed Mockup comments to feedback and clarification

tsvenson's picture

Thanks @davidhernandez, @wfx, @cweagans and @Michelle for your feedback. Since you all have the same concerns I will respond to them here.

The 300 character limit - It is only for the bold blurb. This is to keep it in a controlled size so that it can be easily reused in for example the project search. 300 characters should be enough for any project to give a good "elevator" pitch about what it does. This would give us a great possibility to make the project search pages really good looking compared to the pretty awful trimmed SERP they consist of today.

This blurb will also be used at the top of the sidebar on all other tabs so that it quickly explains what the project is all about. Not everyone will land on the overview page so this will avoid the need of having to change tab just to get that info.

Mandatory image - I agree with your concerns here, but I think we could find a great compromise on this. How about having standard images for all types of projects that can be chosen from, plus a custom one. Then we can have default images for things such as API modules, themes, distributions, etc...

This is for me also important so that those images can easily be used in the SERP as well to make those look good. We could complement it with an option to not view the image on the project pages as well.

I believe that would be a good compromise that both gives the project owners freedom and make sure the SERP is looking good.

--
/thomas
T: @tsvenson | S: tsvenson.com

.

Michelle's picture

As long as there is a place for more freeform text, that's fine by me. I especially need a place to put news. I keep my project page updated frequently so people know what's going on with my modules. That's not something that goes in a "sales blurb" but needs to be visible and not stuck of in the docs somewhere.

Having a default set of images to choose from for the screenshot is fine by me. I just don't like the idea of people being forced to take a screenshot of their module, especially in cases where it doesn't make a lot of sense.

Michelle


My blog, mostly about Drupal: Shell Multimedia

BTW

Michelle's picture

If you want to see the kind of stuff I put in my "wall o' text" have a look at http://drupal.org/project/advanced_forum

Some of it will go away because there are now sections for it, so that's good, but some doesn't quite fit into neat boxes.

Michelle


My blog, mostly about Drupal: Shell Multimedia

There seems to be an

LewisNyman's picture

There seems to be an assumption that just having any old image is actually an enhancement to the page.

If a module doesn't need an image I think it will actually detract and distract from the more important information.

There are a ton of resources to back this up on uxmyths.

Description

MGParisi's picture

One of the problems with a 300 character limit or the idea that a description should be a "selling point" sounded very valid to Me. I made a recommendation to Merlin based on a new users input that he should sell his project. But Merlin took My Theory and put it right where it belonged. In the Garbage! http://groups.drupal.org/node/136294#comment-464964

So if you would let me purpose a slight change. Put an optional Warning field on the page. This warning could indicate a security issue, a bug or other VERY important information. I think this is a realistic solution to an otherwise beautiful design:) BTW, Security issues are set in a way that are recognized by the update module.


--Sig--
Owner of Toastyart a Drupal based High Quality Art Gallery.

Screenshots

eigentor's picture

I also understand the concerns.
So yes, use anything you like there: a logo, a photo of yourself, any symbol that fits the module.

This is aimed to make the Module listings more browsable and memorable.
In Firefox plugins or the android market you will not find a single app / plugin without a logo or any kind of image.
Ath the moment in Drupal there are even themes that have no screenshot (!). Thomas idea to provide standard
logos / symbols is also nice, even if we just create a node and drop a lot of icons / images in there, this could help.

The entire thing is a shift to a more outward-bound approach. Market your module so people will download it.
At the moment we concentrate almost completely on the needs of people that use, love and know Drupal very well.
The problem arises with people that are new. The entire mockup is geared at that audience.
Of course without making us regulars uncomfortable - everything we know and use is still there, even if in slightly
different places.

Life is a journey, not a destination

Just a heads up, but I'm

Josh The Geek's picture

Just a heads up, but I'm pretty sure that 'App Store' is an Apple trademark.

I go by Josh The Geek.
Drupal.org
GitHub

Excluding API Modules?

ccdechesney's picture

When searching for modules for a particular purpose I have always wanted a way to exclude API modules and other "helper" modules that are intended only for developers. From a developer's point of view, all modules belong in the same basket, but not so for users who do not code (or don't want to code in this instance). This seems to me to be a more basic split than the current set of module categories, which seem to be intended to find as many modules as possible. It seems that when I am searching for a module, I either have to wade through tons of modules or I come up with a handful, none of which have anything to do with what I'm thinking about.

This probably seems extraneous to a discussion of revamping the product pages, but I think it is germane. What I am suggesting is a module TYPE designation of some sort to differentiate between modules that stand alone and provide a solution without additional coding (even if they require other modules) and modules that make coding easier but do require additional coding before something interesting can happen. Since these two types of modules have a different "customer" base (by role if not by individual) the requirements for their product pages are different.

Levels or types of modules

BeWhy's picture

I agree that it is sometimes hard to differentiate between what I call "support" modules that do nothing for end-users and site builders (like ctools) versus "rubber-meets-the-road" modules

In addition, I'd also like it 'mandated' that on the project page the maintainer lists required modules and in some case modules that are extensions. For instance, the nodereference module is great, but there are a host of modules that sweeten the deal immensely, and it would almost be a shame if a user didn't get a taste of the greatness of extender modules because they'd have to do another search.

In an effort to move the discussion, when building sites I use the following folders to group my modules:
User (logintoboggan, etc)
Admin (admin, nodeaccess)
Support (ctools, token)
Content (cck, )
Media (wysiwyg, imagecache)
Layout (panes, display suite, views)
Theming (sweaver, skinr)

The easiest application of this would be to create a taxonomy to tag and categorize the modules which the maintainers would put in (based on issue queue requests perhaps.

For the above post from ccdechesney I would propose the 'roles':
developer
site admin
designer
content manager
end-user

what you don't know will inspire you

Good Ideas

eigentor's picture

@Michelle
News is a good idea. I often see people dropping that in somewhere in the module description and nobody ever notices if they do not happen to read through the entire wall of text.
We have a tab called "Roadmap" that could be well used for News and make more sense as such.
Also we could include some more blocks below the download buttons (and better format them :P )

There is such a lot of information on project pages that makes a lot of sense. Yet there is no recognizable structure. So if you know, news are bottom left, depenencies in the sidebar in the middle, I think this helps a lot for everybody that uses the project pages regularly.

@ccdechesney: Yes, we had the idea to mark API Modules as such. The same could go for Module Suites like Media Module with its Submodules and say Display Suites.
I thought about how to be able to bundle them for Download, but this would be a lot of work for the maintainers to always update the bundles.
Do you have an idea how we could do this optically? A flag, a big sign: "API-Module" "Theme" "Module Suite" "Addon Module" (like Views Slideshow).
This would be another kind of categorization than we have now.

@lewisnyman: an image may is good but maybe optional on the full project page. But it gets a totally different story in the various listings. The human brain has an incredible capacity of quickly recognizing and memorizing images. Not so with text. You can scroll a list with images at least three to five or even ten times faster when looking for something as when it has only text. So especially for teaser lists of modules and some-day-to-come module browsers from inside Drupal Images are really needed.

We have very high standards regarding code quality for modules. But we don't have any regarding presentation. So in order to make it not too hard for maintainers a good predefined structure could help. If you do not find a good screenshot or catchy text for your module, ask someone for help that ist better with that...

Life is a journey, not a destination

Category Flags

ccdechesney's picture

@ccdechesney: Yes, we had the idea to mark API Modules as such. The same could go for Module Suites like Media Module with its Submodules and say Display Suites.
I thought about how to be able to bundle them for Download, but this would be a lot of work for the maintainers to always update the bundles.
Do you have an idea how we could do this optically? A flag, a big sign: "API-Module" "Theme" "Module Suite" "Addon Module" (like Views Slideshow).
This would be another kind of categorization than we have now.

I'm thinking something about the same size as the version drop-down and on the same line but on the right flush with the right edge of the tabs. Each type should be a different color to promote instant recognition (helps all except color blind - different border treatment, too?). I think there should be no more than about half a dozen types - what about Module, API Module, Module Suite, Addon Module, Theme, Starter Theme?

Also, I'd like to see the rating stars with number of reviews/ratings and the number of sites using it on the same line between the version drop down and the type flag. These two should be smaller but I think there's room for both without crowding.

That puts all of the info above the fold that is needed to make a decision to take a closer look or move on.

Haven't read through

patcon's picture

Haven't read through everything, but justa quick suggestion: Standardize and crowd-source the "Similar modules" listing. We're all about reducing duplication of efforts on d.o, but we don't have a means to make sure both maintainers and developers have a simple means to alert one another when this happens.

Right now, I monitor the New Modules RSS feed, and if something comes up that sounds familiar, I search it out, and post a boilerplate heads up in each issue queue. I don't dig in-depth into each module, so sometimes I'm wrong, but at least they now know about one another. What I find frustrating is that while I often recommend the maintainers add something to the project description, many fail to do so. I'm not sure why. Maybe they forget, or maybe they disagree about similarities, but I feel this conclusion should be up for dispute. If the maintainer (knowing the code) thinks it's different, but the users (knowing only their use-cases) feel they're similar, then other users should still have a prominent place to show this.

I think it's be awesome to have a content type (or entity?) that allowed for a bi-directional relationship to be made between two modules. Perhaps any submission would be shown, but could be freely upvoted or downvoted. Maintainer could still disagree, but if everyone else thought they were similar enough, their opinions would count as well.

While I'm here, another suggestion along similar lines: Yeah, feature's fills a niche for packaging modules and config together, but not everyone is going to submit a feature when they figure out a cool way to have certain modules work together. Would be nice if there was a place to add "Use Case examples" for each module. So on the "Flag" module, I could submit a "use case" with a node-ref relationship to "View flag refresh" and "Views" and "Rules", and write a little description of how you used these to create a view for a content type with an "unpublish" flag, which could be displayed on a view as an ajax link, and have any view row disappear and be unpublished when you clicked the ajax link in the view. Yeah, I could write a whole blog post for that, but I haven't in the year since I figured that out :) Oh hey, and that "use case" would show up on the other module sidebars as well.

Sorry if that post was a bit of a braindump, but I've been sitting on it for awhile :)

Going further

eigentor's picture

I guess to get this ahead I should make Layouts for the various Module listings (Listing by category, default View when you click most installed and so on) to show how this all plays together and how wide and deep our plan really is :)

Life is a journey, not a destination

That's a different set of problems...

dww's picture

Thanks for the mockups, comparisons, and ideas. However, I'd really prefer to put all of this into a whole separate post/discussion. This current thread is about the individual project pages e.g. http://drupal.org/project/views -- not about the various project listing pages. Although they're somewhat related, they're trying to do very different things. The problems with the listing pages are considerably different than the problems with the "project home pages" themselves.

To facilitate progress here in the Prairie and to keep things from getting too confusing to follow (and meaningfully contribute to), I'd strongly encourage everyone to stay on topic for any given post in the group. If we're talking about the issue queue listing pages, please don't bring in all your ideas about the individual issue pages into that same discussion - either add those to the existing discussions on the individual issue pages (e.g. http://groups.drupal.org/node/137829) or start a new one. Similarly, if we're talking about individual project pages (like we're trying to do here), let's not also drag in the whole topic of project listing and search pages. Otherwise, we're going to try to have 3 or 4 separate conversations all at once. That makes it much harder to both follow what's being said and to actually accomplish anything actionable as a result of the discussion.

Thanks!
-Derek

I guess you are right, Derek.

eigentor's picture

I guess you are right, Derek. So keep it seperate. I moved the page over here http://groups.drupal.org/node/143629 and only included the module Listings and removed the part about Download & Extend landing page.
If someone wants to comment, please over there.

Can someone with administrative rights on this group remove my above post and just leave a reference to the other page? I cannot edit the comment anymore. Helps to keep the house clean...

Life is a journey, not a destination

unpublished it

yoroy's picture

The reference is http://groups.drupal.org/node/143629 indeed :)

Module owners: How to make

lisarex's picture

Module owners: How to make your module description useful got turned into an issue (http://drupal.org/node/997066) and also documentation (http://drupal.org/node/997024) so as ideas and best practices are solidified, modify the docs page, or comment on the issue.

Heather, I hear your point that screenshots are uberimportant. I've updated the docs page (It needs a whole style review at some point!)

==================================
http://about.me/lisarex

Opt-in mailing list

Michelle's picture

I was just discussing on IRC a major decision I need to make with AF and lamenting that I have no way to contact the 16K users and ask their opinion on it. What would be handy to have on project pages is a way to opt in to a project's mailing list and, for the maintainer, a way to activate having a list since not everyone needs/wants one.

If a mailing list per project is too much, maybe then just a way to subscribe to a project's news and you get all the news from all your subscribed projects in one go. This isn't the same as subscribing to the issue queue. It would specifically be for news blasts, not every issue.

Michelle


My blog, mostly about Drupal: Shell Multimedia

Projects as OGs

dww's picture

This is one of the many things we'd get "for free" if every project were an Organic Group. I'd link to my prior post on the topic but I'm on my phone right now and that's not so easy. But I have a whole write up from the time of the d.o redesign planning about this, and maintainer news that users could subscribe to (and/or browse) was high on the list.

.

Michelle's picture

http://groups.drupal.org/node/15295

I see I +10000'd it 2.5 years ago. :)

Michelle


My blog, mostly about Drupal: Shell Multimedia

Themes Versus Modules

BeWhy's picture

I think themes need to be able to show off their pizazz. Having the themes display as a module does, just doesn't do justice to the visual nature of themes.

I would propose that we design a different template/theme/ui for themes as different from modules. In specific, enabling themes to submit multiple pictures (for instance different color schemes and/or different layouts) would help non-designers get a much better look-see of each theme.

what you don't know will inspire you

Gallery

eigentor's picture

Well, if we generally think of adding a gallery possibility, this should be fine for themes.
(Hopefully) more visually oriented, theme authors should be happy to upload several Screenshots that showcase all the glory of their design.
Module authors just do not need to use it.

ccdechesney's idea of about six to seven categories of "module type" of which one could be theme (and another one for a base theme) could also solve the mandatory image problem.

If we implement default images for each category, say an API module would get a default image, that helps the user of d.o. in orientation.
If the module author does not like it, he can upload another. But if they do not want to bother, it is not empty.

Life is a journey, not a destination

Prairie Initiative

Group organizers

Group categories

Prairie tags

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week