Add new 'Functional area' taxonomy for case studies

tagging

Maybe I'm just dense. I'm not sure what "functional area" means. What are the kinds of terms in mind for this proposed vocabulary? Performance, Multisite, Development process and Design seem to describe different kinds of aspects of aspects. Kind of like Apples, Oranges, Plates and Gas Ranges. Maybe there's more than one axis?

So how to define? By skillset? By goals? By challenge? By component?

Maybe a fruitful step would be to define the UX goals of the case studies area. What do users want out of case studies? What are they looking for? How might a tool like this help them achieve their goals? Can we define some quick personas and user stories? E.g., As a systems administrator, I want to filter case studies by site performance, so I can learn how to tune my server to perform better. (Bad example, perhaps.)

A crazy idea might be to utilize entity reference to link to the modules used and discussed. (And the project pages could have references to case studies discussing them.) Sorry, I don't want to run this issue off the rails. Just thinking how case studies could become more findable and interconnected with other lore on the site.

Sorry for the delay...here's what I was thinking.

The comment that it's like "Apples, Oranges, Plates and Gas Ranges" is fairly on target. Basically, I thought it would be useful to have a vocabulary that helps viewers to find case studies that speak to their specific challenges or, in the case of a client user, specialty skills they need from a vendor.

For example, Developer A is looking for ideas on how to handle dynamic charting of data on a university site. While they can isolate a list of university site case studies, what they really need to see are examples of dynamic data charting. With a functional tag of "dynamic data visualizations" or something else relevant, they can find case studies that touch on the modules, tools and techniques others have used and go see what the execution looks like on the live site.

As a user client example, Client Z is a social advocacy non-profit that needs to find a vendor for a Drupal site. They can narrow down to see Social Advocacy sites, but because their site traffic tends to spike during certain types of news events, they really need to see examples of high performance projects. With a "Performance Optimization" tag, they can see a list of case studies featuring high performance sites, who did them, and possibly what approaches they used.

Likewise for the TV station that needs a hub and spoke multisite setup (tag: multisite), or the local government that needs an OpenPublic setup and customization (tag: distributions), or the community soccer league that needs to provide community tools to its teams and coaches (tag: community management).

(Example tags are just suggestions. There may be more appropriate terms.)

The intent is to increase the utility of the case studies as a research tool to find inspiration or providers to address the specific challenges/objectives the viewer is looking for. I don't know if "Functional area" is the right phrase or not, but the idea is to allow categorization based off of skills or solutions that are applicable across many types of sites or sectors.

Does that make sense?

The idea itself makes sense to me. I think we do need to find better name for this vocabulary than "Functional area". Maybe something along the lines of "main feature" or "strongest side" of the site, or "main challenge". Than we can include terms like: Performance optimization, Responsive design, Multisite setup, etc. I do see how it can be useful to be able to find sites by this specific terms.

"Key challenges and expertise"?

Yeah, this sounds much better! For the sidebar navigation though we will probably use: "Browse by key challenges" without expertise or it will be too long.

Let's now refine the list of terms for this vocabulary.
Proposed:
Performance optimization
Responsive design
Multisite setup

What else?

For consideration...

Section 508/WCAG
Data visualization
Legacy systems integration
Admin customization
Process automation
User training
Developer training/mentoring
Localization
Hosting architecture
Multiple languages
Multimedia platform
Application development
Stringent security
Alternative databases
Mobile-first design

Suggestions for taxonomy:

(1) Small, Medium, Large - that way a potential client can survey sites relative to the size of their own organisation and needs

(2) Three meta-categories

• for-profit
• non-profit and charitable organisations
• government

or else

• private sector
• public sector
• non-profits and charitable organisations

When we present a big blob of case studies, the filters we provide to sort through them should be relevant to the questions the audiences are asking. We can easily generate taxonomy that makes sense to us viewing things from the other side, but what of the end-user audience side?

For example, looking at this from the end-user perspective, I'm not sure how helpful the items in #12 would be. What does "Medium" mean? Do non-profit websites use different modules than for-profit websites? E.g., I wouldn't build a non-profit publishing site differently from a for-profit publishing site.

Going back to my earlier note about UX, what is it that these terms answer for people?

Goals of case studies

So I ask, semi-rhetorically: Why do case studies exist?

1. So other site builders can learn from successful projects.
2. So other site owners can see what's possible.

(Are there other reasons? I suppose we could add, "So the site developers can thump their chests," but I view that as a byproduct, not the goal of having case studies.)

Personas

Persona: Jane the site builder

What is Jane looking for in case studies? I feel she would be looking to see how others solved a particular challenge, or how others have been using a particular module, or perhaps finding site recipes from similar sites to her own.

Persona: Bill the site owner

What is Bill -- a prospective Drupal adopter -- looking for in case studies? Proof that it's possible, get a sense of the problems and solutions available, see the results....?

Solutions

We want filtering mechanisms to enable people to drill down or focus on things that potentially answer their questions. Thankfully we can skip anything pertaining to modules. The modules question is solved by the new content type's reference field, so we don't need to have taxonomy with module names.

But terms that help describe the others would be helpful. What kind of site is it? (Publishing, community, gallery...) What particular technical challenges were there? (Advertising integration, Salesforce, dynamic mapping, web services....) I like some of the specific suggestions, like 508 and multisite. I'm trying to think of taxonomy term links (or search facets) that end-users will find helpful towards finding case studies relevant to their needs and interests.

My apologies for this wholly oversimplistic UX analysis.

@ Laura S.

I am wondering if we are both feeling the process (methodology) for Case Studies could be more clearly defined.

For example:

- What is the purpose of Case Studies ? Why does it exist ?
- Who are the target user groups? (I like your personas)
- Can the visuals and UX on the landing page be improved before we start migrating (13,000+) case studies ?

Has the Case Studies Project defined its methodology?

Perhaps, we could imagine:

- Case Studies is a unique project within drupal.org
- Case Studies is "outsourced" to a talented Drupal shop

How would this Drupal shop create the solution?

In other words, what methodology has Case Studies adopted to

• identify the design problem
• design and build a solution
• migrate the case studies into the new "platform"

More questions:

• What is the "life cycle" and "scope of work" for the Case Studies project ?
• Who is the "client" and what are they trying to achieve ?
• For Cases Studies -- the web component within drupal.org -- how do the graphics, UX and development exemplify and showcase best practices ?
• What is the story Case Studies is trying to tell ?
• Hat tip to Laura S for introducing the concept of a website as a medium for "story telling"
• What is the maintenance plan for the project once it is completed ?
• Has a "Master Plan" for Case Studies been drafted and approved ?
• Where is it for newcomers to review and gain an orientation ?

My apologies if I am missing out on work that has already been done. I'm new to Drupal and drupal.org

Just noting related initiative: https://association.drupal.org/node/16223 -- The case study curation process is happening. I feel this issue here is a way to add value to this new component of d.o.

@Laura S

By small, medium, large --- perhaps I am meaning scalability.

In other words, how do I select a group of websites, within an industry sector, that are similar in scale.

@westend What's "large" to me may be only "medium" to you, or vice versa - that's the problem I have with those terms. What's more, scalability is really its own issue, and is affected by many things, including the site's technical architecture and the way it's used. (E.g., a site with high readership but low posting has different performance affordances than a site with less readership but very active posting.)

I would be +1 for including "Performance and Scalability" as one of the terms, though. If you're thinking about it and covering it in your case study, on whatever scale, that is what's important, imho.

@Sarah S

Small, medium, large --- are simplistic terms. I agree :)

What perhaps we mean then is the ability to select websites measured (quantified) according to certain critiera.

For example:
- performance and scalability
- cost of the website (eg, $5,000 ? $50,000 ? $500,000 ?)
- person-hours it took to design and build the website (40 hours ? 240 hours ? = to one full-time job for one year ?)
- the size of the client organisation served by a website (eg. small independent business, regional chain, national chain, globalized operation ?)

The taxonomies used from the case studies, and the views showing them, are defined in code.