The new case studies page at http://drupal.org/case-studies is awesome. However, as implemented, there's no way for readers to tell what year a particular case study was written, or to view/sort case studies by year written.

One continuing issue that we've had with case studies over the years is that they get outdated over time. Sites get redone, upgraded to new versions of Drupal, and some sites even move off Drupal (gasp!). Despite this, many older case studies are very well written and have continuing value to the community and to evaluators because they go into great detail about the site building process. One good example off the top of my head is Moshe's excellent NY Observer case study, which is a great read, but has been unpublished simply because the Observer no longer runs Drupal: http://drupal.org/nyobserver

If we were able to identify the year that a case study was originally written, it would enable readers to place case studies within a particular historical context and to view Drupal's evolution over time. Certain case studies could be marked as "outdated", but they'd still be available for people to read because of the value their content has to the community (we could even have a special section for this kind of content). By just unpublishing old case studies, we sets a bad precedent and deprive the community of some very valuable historical and educational resources.

Comments

tvn’s picture

tvn commented
Issue tags: +drupal.org case studies

Great ideas! Tagging.

gdemet’s picture

gdemet
he/him
Primary language English
Location Chicago, USA
commented

Thinking about this further, older case studies that are outdated and still have value should probably be tagged as "Classic" or "Hall of Fame" and grouped on a page that has a description of what kind of material this includes, e.g.,

"The Classic category is for older Drupal case studies that contain outdated information, yet are still of value to the community. While some of the sites listed below may no longer exist, or may not even be running Drupal any more, these document some of Drupal's most significant success stories and milestones in the project's history."

lisarex’s picture

lisarex commented

What criteria should we use to determine if they still have value? And where should we put these? I'm concerned that we will either confuse people if we link them from the main case studies, yet if they're hidden away, they won't be viewed anyway.

I'm not disagreeing but it's a lot of work to push / promote new case studies...

gdemet’s picture

gdemet
he/him
Primary language English
Location Chicago, USA
commented

This shouldn't be too much work; once a case study is identified as being outdated, an issue would be created to gather consensus on whether this should be unpublished or added to the "classic" or "hall of fame" category. If it's not deemed worthy, it gets unpublished; if it's worthy, then it gets marked as "classic" or "hall of fame" or whatever and put in its own category that doesn't get promoted to the home page, but is still available for posterity.

jredding’s picture

jredding commented

Not to muddy the waters even more but I noticed that the case study content type doesn't include Drupal version making it difficult to find all Drupal 6, Drupal 7, Drupal 5 implementations.

This simple addition might hold more value than evaluating the year the site was created.

gdemet’s picture

gdemet
he/him
Primary language English
Location Chicago, USA
commented

Agreed; we should definitely identify version of Drupal used.

lisarex’s picture

lisarex commented

We had some feedback that it wasn't necessary to include Drupal version number, because sites get upgraded etc. I have no strong opinion either way but I would like to see the existing filtering get sorted out before we add more filtering criteria if possible.

jredding’s picture

jredding commented

@lisarex I understand that argument. Do you have a link to that thread?

I am on the side that the case study is written against a very specific version of Drupal since you're asking and displaying information on modules, etc. When the site is upgraded the type of modules, etc. used will be outdated and thus the case study should either be updated or be a report of a point in time in history.

gdemet’s picture

gdemet
he/him
Primary language English
Location Chicago, USA
commented

When the site is upgraded the type of modules, etc. used will be outdated and thus the case study should either be updated or be a report of a point in time in history.

This is exactly my point. Realistically, it's rare that case studies get updated, so we need the ability to let readers know that these are artifacts that were created at a specific time and place in the site's lifecycle.

tvn’s picture

tvn commented

It will be really easy to add 3rd "status" to case studies (we have 2 now Community and Featured) - Outdated, Old, Classic or whichever will fit best and show such studies on separate page. However right now we have too many valid case studies to be migrated to the new section and too few volunteers to do so. I do think it is better to spend their time on migrating valid and up-to-date case studies (or writing new ones) than migrating old/outdated ones, even if they are really well written.

So for some time new case studies section will consist of (supposedly) valid case studies. Later in time when the need will arise we can always introduce "classic" section.

Between year/version having Drupal version on case study makes more sense to me. When I see version Drupal 5 - it tells me that case study is indeed old and I probably won't be able to use same modules as they used etc. When I see year 2010 - it does not tell me that much. Besides we have posted date on case studies and probably year will often be the same.

And agree with Lisa Rex, let's first deploy basic redesign and fill Featured section with some high quality case studies before we will add more fields/filters.

gdemet’s picture

gdemet
he/him
Primary language English
Location Chicago, USA
commented

That approach makes sense to me; I just want to make sure we aren't unpublishing or deleting old case studies that still have value to the community.

RE posted dates, the problem is that when case studies get migrated to the new system, their posted date gets reset. For example, http://drupal.org/popular-science and http://drupal.org/node/1497168 are both case studies from 2008, yet they now appear to be from March 2012 in the new system, which is confusing and misleading.

I agree that a Drupal version field is most important, but for older case studies that are getting ported over, we need to somehow preserve the original date, even if it's just a note in the body text.

kingandy’s picture

kingandy
he/him
commented

Privileged users are able to manually change post dates, if it's appropriate. I think "migrating case studies from one content type to another" would be such a case.

lisarex’s picture

lisarex commented

gdemet, we could use another sprint where we ensure the migrated case studies have their original author and publishing date. :) I can do that, but don't know when.

I don't think there was a thread re: Drupal version number, just some conversation in IRC or at the sprint between drumm, myself and some others. I think it's expected that the version number will be mentioned in the body. Overall, we didn't want to introduce to many fields. For what it's worth, I don't see version numbers on many "competitor" showcase/case study sites.

Good points regarding why version number would be useful. if we have consensus on this, we should update the title.

lisarex’s picture

lisarex commented
Title: Case Studies should be sortable by year, and older case studies should be identified as "outdated", not unpublished. » Case Studies should be sortable by year, and older case studies should be moved to an Archive section
Project: Drupal.org site moderators » Drupal.org customizations
Version: » 6.x-3.x-dev
Component: Redesign » Code

Per #1899898: Under.me no longer using Drupal we have a superb use for creating an Archive section. Updating title & project. This requires updating the case study feature.

Tezza’s picture

Tezza commented

There's value in version number, but I can't think of a good use for a year field; the migration process notwithstanding.

lisarex’s picture

lisarex commented

The year the case study was published might be useful; George can you clarify?

tvn’s picture

tvn commented

I've added "Archive" value to "Status" field and moved one case study there: http://tvn-drupal.redesign.devdrupal.org/case-studies/archive

I agree with Tezza about year field. We have taxonomy vocabulary for Drupal versions, so I'd just add that to case study content type.

lisarex’s picture

lisarex commented

tvn, thanks for integrating it on your test site. However, I think we need to ensure folks can navigate to the Archive, so it needs a tab or some other navigation (if a tab is too prominent).

I don't recall the discussion about keeping the word 'showcase' in the navigation but in this case I think the tabs would be 'Featured case studies' 'Community case studies' and 'Archived case studies'. Thoughts?

Sounds good re: Drupal version; will this just be an exposed filter at the top of the list, for now? Longer term, it might be nice to have it off to the side where the term filters are.

tvn’s picture

tvn commented

I do think tab is too prominent. How about a link in the right sidebar?

http://tvn-drupal.redesign.devdrupal.org/case-studies

I've also added Drupal version navigation below Categories.

Tezza’s picture

Tezza commented

Works for me.

Just added a few more version numbers to community and archived on dev site.

I wonder if Browse by version might be better sited above Browse by category. In theory there should only ever be two options in the version list

Also, when, for example, masses of D6 case studies suddenly become archivable, will we have something to automate that process?

lisarex’s picture

lisarex commented
Status: Active » Needs review

I'm not a huge fan of the Archived case studies link in the right sidebar. It comes right below the link that takes them elsewhere. A more consistent treatment would be to add an Archived tag, so the case studies would remain in the community section, accessible from the top.

In the case of Under.me and NY Observer, the case study might still be valuable to folks, so hiding it away was the wrong thing to do.

I would love to hear from folks who have utilized the these case studies.

Also, the Drupal version will show all the Drupal versions that have case studies associated with it, unless we can programmatically restrict it to only the current ones.

Tezza, I don't think we'd want to mass-archive the D6 case studies. Some of the sites will still be running D6 well into D8-time. I guess the answer also depends on how many D6 case studies we have. If it's in the hundreds and we have a lot of D8 ones to round out our case study section, then maybe we can do something with VBO. I'm sure when the time comes we'll have some sort of discussion.

lisarex’s picture

lisarex commented

so the case studies would remain in the community section, accessible from the top

Oops, what I meant was "so the case studies would remain accessible in a consistent manner, in a tab next to the community tab"

leighcan’s picture

leighcan commented

Is this something that we're still interested in doing? I think an archive is definitely necessary, especially as we move towards a Drupal 8 release and an increasing number of Drupal 8 websites. Do we want to do tabs or tags? It would be great to get some feedback on this as we work through the Drupal.org content redesign.

drumm’s picture

drumm
he/him
Location NY, US
commented
Version: 6.x-3.x-dev » 7.x-3.x-dev
Status: Needs review » Postponed (maintainer needs more info)