Help the Eclipse people make an awesome EPIC Drupal site

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

The Eclipse foundation is relaunching their Eclipse PlugIn Central (EPIC) plugin repository site in Drupal. Help them make it rock by analyzing their requirements document and giving them the best tips possible. A large number of Drupal developers use Eclipse as their IDE and we owe them a debt of gratitude. Help make EPIC rock!

See here:
http://www.eclipseplugincentral.com/
http://ianskerrett.wordpress.com/2009/02/18/epic-20/
http://wiki.eclipse.org/EPICModernization

EPIC Modernization Requirements Document V 0.1

The Eclipse Plugin Central (EPIC) is a popular and successful resource for the Eclipse community. It lists over 1100 Eclipse based products and drives thousands of click-thrus per month to some of the top rated products. Unfortunately, EPIC is hosted on an older content management system (CMS), so it is difficult to maintain and update. Therefore, we are starting a project to modernize EPIC and re-host it on a more modern updated CMS.

This document is to capture and prioritize all of the requirements for a new EPIC. The goal is to finalize the requirement by the end of March and begin implementation shortly thereafter.

Below is a draft version of the document. We encourage people to submit their suggestions for this bugzilla entry. We will update the document based on the input from many sources.

Goals

  • Dramatically increase the usability of through improved navigation and graphic design.
  • Make it easier for solution providers to manage their product entries.
  • Provide better linkage between EPIC site and the vendors’ update sites.
  • Host EPIC on a new content management system.

Requirements

Usability and Navigation

  • Need the ability to tag products and navigate via a tag cloud.
  • Products should be able to have multiple tags and product owners should be able to select and define tags for their products.
  • A product needs to be able to be in multiple categories. Currently a product can only be in one category
  • For plugins that have not been updated for a long time, we need to show that the information might be old and out of date.
  • Allow cross linking to other similar products by the same vendor and/or category
  • Allow cross linking to Eclipse Live content

Management and Administration

  • Remove the moderation queue for plugin / service listing updates.
  • Host the click thru reports for member plugins on EPIC itself allowing for realtime data.
  • Allow plugins to upload their plugin image icons directly to the server.

Social Networking Ideas

  • We should allow a product to be voted up or down, similar to digg. Remove the vote 1-10 system in place now. Need to allow people to add a 'vote' graphic onto their site. We could introduce aging of votes, so votes expire after ### days or categorize the votes by time to provide rankings for "this week"/"this month"/"this year" similar to the way YouTube and others social sites do.
  • Need to maintain the RSS feeds for new and updated products
  • Allow users to specify their favourite products and then produce an RSS feed that shows them any changes for that plugin.
  • Be able to show the list of most 'favourite products' across all users

Update Sites

  • Integrate a p2-compatible catalog for the product listings and provide an electronic feed for that catalog
  • Can a list of favorite products be used to aggregate a personal catalog for an individual

CMS Issues

  • Current thinking is to host EPIC and Live on a single shared Drupal install.
  • We should integrate sign-on with existing Buzilla accounts
  • The current install of PostNuke places a large load on the database. We should be sending SELECT queries to the slave and INSERT/UPDATE queries to the master.

Support for Training and Service Providers

  • Need to be able to search/tag by geography and expertise
  • Training calendar for Eclipse public courses

Migration Requirements

  • Plugin information should be migrated to new EPIC without requiring intervention from plugin owner.
  • Username and password information should be migrated to the new site. We should try to delete any usernames that aren't being used.
    -- (Gunnar) Q: Should EPIC get rid of it's own password storge and use the global Eclipse.org login?
    -- (Gunnar) Support for additional authentication sources (eg. OpenID) should be added.

Naming

  • We should consider referring to 'products' or 'projects' and not plugins, since a lot of the solutions listed on EPIC are not actual plugins.
  • Should we rename Eclipse Plugin Central to something more generic; maybe Eclipse Solution Center?

Other Ideas

  • I think it would be interesting to show what Eclipse projects are

Comments

A collection of voting modules

robertDouglass's picture

It's been a while since I've evaluated voting modules. Which of these seem like the best fit for the Eclipse people?

We should allow a product to be voted up or down, similar to digg. Remove the vote 1-10 system in place now. Need to allow people to add a 'vote' graphic onto their site. We could introduce aging of votes, so votes expire after ### days or categorize the votes by time to provide rankings for "this week"/"this month"/"this year" similar to the way YouTube and others social sites do.

http://drupal.org/project/vote_up_down
http://drupal.org/project/plus1
http://drupal.org/project/pop_links
http://drupal.org/project/radioactivity

Anybody have other suggestions for the state-of-the-Drupal-art Digg-like voting?

For "Favorite products" - the Flag module?

robertDouglass's picture

Allow users to specify their favourite products and then produce an RSS feed that shows them any changes for that plugin.

http://drupal.org/project/flag

Then you have a view (does it already exist) of a user's favorite products, and this view can be expressed as RSS as well.

Yes

Alex UA's picture

...and if they need drag and drop ordering of their lists:
http://drupal.org/project/weight

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Search and discovery very important

robertDouglass's picture

Since finding things on the site is going to be very important, I suggest you check out Solr based faceted searching with http://drupal.org/project/apachesolr

I trust the Eclipse people will have no problem setting up Solr ;-)

What about discovery?

Alex UA's picture

Solr is great for search, but what about the discovery piece? Some potential directions for related content (outside of just plain ol' Views magic) are:
http://drupal.org/project/context + http://drupal.org/project/spaces
This looks promising: http://drupal.org/project/recommender (is this what's being used on the upgraded d.o. to give forums where a module is being talked about?)

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

ApacheSolr has a content recommendation feature

robertDouglass's picture

Which I always forget to talk about... even though it's one of the best features! It can appear as a block on any node and recommend similar items. You can configure the fields it uses for calculating similarity.

Oh, sweet

Alex UA's picture

I haven't really had a hand in our Solr testing, so I had no idea.

--
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Yes. Recommender = Pivots "the next generation"

robertDouglass's picture

Recommender is more full featured than the ApacheSolr content recommendation (though AS is still very effective).

OpenID and Drupal 6

robertDouglass's picture

Eclipse people... I don't know what version of Drupal is running your Live site, but I highly suggest using Drupal 6 for the EPIC development.

One advantage:

-- (Gunnar) Support for additional authentication sources (eg. OpenID) should be added.

OpenID identity management and login is part of Drupal 6.

Drupal

Ian Skerrett's picture

We definitely want to use the latest and greatest version of Drupal. Thanks for the recommendation.

Training Calendar

robertDouglass's picture

Best solution: Views + Date + Calendar modules.

Read the recipe in the sample chapter from this book: http://oreilly.com/catalog/9780596515805/

Training calendar for Eclipse public courses

Splitting INSERTS and SELECTS

robertDouglass's picture

http://drupal.org/node/147160
http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/crackerjm/r...
http://tag1consulting.com/MySQL_Replication_Tips_And_Tricks

I think we'll have to do some more hunting to find the best patches for splitting reads and mutators between databases.

General performance

robertDouglass's picture

I've had good luck with the cacherouter module: http://drupal.org/project/cacherouter

You're probably using APC or Xcache already (if not you should be), and those provide opt-code caching by default. That means the PHP code is parsed into something more machine friendly and stored so that it doesn't have to be parsed and compiled every page request.

Less well known, though, is that both APC and Xcache can do generic object caching as well, and this is where cacherouter comes in. Drupal's caching is usually done in the database, but moving it into memory instead makes a site a lot faster and reduces load on your database.

Do you recommend using APC

kyle_mathews's picture

Do you recommend using APC or Xcache for ram caching over memcache?

Kyle Mathews

Kyle Mathews

How many webservers?

robertDouglass's picture

The question comes down to how many web servers are you running? If you're running one, then APC and Xcache object caching will kick memcache's butt because a) the data is in the process memory space and requires only a simple lookup, like any other piece of data (global $user for example), and b) there's no network protocol to be dealt with. Memcache is ideal if you have more than 1 server because you don't end up with redundant (or out of sync) caches on your various web servers. It is slower than Xcache or APC caching though (but still WAY faster than database caching).

I hadn't realized the

kyle_mathews's picture

I hadn't realized the distinction. I'm running a single-server site using memcache for object caching but hadn't realized that APC would be faster. I'll have to make the switch. Thanks for the reply.

Kyle Mathews

Kyle Mathews

.

robertDouglass's picture

Allow plugins to upload their plugin image icons directly to the server.

Do you mean "plugin" as in the code, eg "Let an Eclipse plugin post an XML-RPC call to the EPIC server"? Probably not. You more likely mean "Let plugin owners upload images..."

For the latter use CCK + Imagefield. Let the plugin owners be the authors of their plugin nodes and then they can self manage the plugin images. Use imagecache for image resizing and manipulating.

I should mention that the Acquia Drupal distribution has a lot of these modules already included, so you may want to start there. http://acquia.com/downloads

We mean plugin owner is able

Ian Skerrett's picture

We mean plugin owner is able to upload their image directly.

Usability

Alex UA's picture

There are a few items which point to the need for a more "usable" site, so I'm thinking that we should probably point them in the direction of some easy usability improvements. Here are some that we use on the sites we build:
To improve node creation/edit forms: http://drupal.org/project/vertical_tabs
To improve field descriptions: http://drupal.org/project/beautytips
To keep your users from screaming bloody murder after they navigate away from a page: http://drupal.org/project/autosave
To allow people to add some sort of content without leaving the page: http://drupal.org/project/popups

And for the developers, this almost always is helpful: http://drupal.org/project/rules

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology

Thanks for the suggestions

Ian Skerrett's picture

Thanks for these great suggestions. You have definitely given us some great pointers.

Come back and get more when you're ready =)

robertDouglass's picture

As soon as things start moving into the actual design and implementation phase make sure and come back to 1) validate your ideas and plans, and 2) get over any development humps that might come along. As you can see, Drupal loves Eclipse, and we're dedicated to making your site rock.

Back for more!

nathangervais's picture

Nathan here from the Eclipse Foundation. I'll be the one doing most of the heavy lifting on the new EPIC 2.0 site. Thanks for all the feedback so far on this thread. Its given me a great head start at looking for modules that should suit our purposes

Here's a preliminary list of modules I've put together that I think are the best fit for us.

Drupal 6 (Latest)
CCK + imagefield
Views
Tagadelic (For Tag Clouds)
Flag (For Favorites + Out of Date)
Extra Voting Forms (+/- voting)
ApacheSolr (for search + Recommendation Engines)
Views Datasource (for RESTful API for P2 Clients)

Any feedback you have on this setup would be greatly appreciated!

Looks good. Services module?

robertDouglass's picture

I don't know exactly what your requirements are for the RESTful API for P2 Clients, but you should evaluate the Services module as well. It abstracts the underlying service from it's protocol, so you can have RESTful, SOAP, JSon, XML-RPC etc, all on top of the same underlying API. I'm frankly not terribly familiar with the Views Datasource (though I know the author and remember the GSoC project that gave birth to this module).

The site is launched!

robertDouglass's picture

Congrats to the EPIC team on your awesome new site: http://marketplace.eclipse.org

Thanks for choosing Drupal =)