Feature #6078
openExplore Adding Network Blog Metadata Plugin
Added by Luke Waltzer over 7 years ago. Updated over 7 years ago.
0%
Description
This is the plugin Shawn Rice wrote for B@B: https://github.com/shawnrice/wp-network-blog-metadata
Could add some complications to the site launch process on the Commons, but the goal of tagging new sites seems a good one.
Related issues
Updated by Boone Gorges over 7 years ago
I definitely agree that the goal of tagging sites is a good one.
wp-network-blog-data doesn't look like it's in a state that's usable for the Commons. It has a bunch of decisions hardcoded into it that wouldn't work for our purposes. See, eg, the columns in its database table: https://github.com/shawnrice/wp-network-blog-metadata/blob/c14efdccb27b4b1e1870250cdeee3f953009604d/install.php#L29
I can't find an existing plugin that is lightweight and flexible for this purpose. That's strange to me - it seems like it'd be a solved problem. Ray, have you ever seen one? We could build something basic pretty easily, especially with WP_Site_Query in WP 4.5 or 4.6 or whatever it was. A custom taxonomy on blog 1 + some UI in the dashboard.
Updated by Raymond Hoh over 7 years ago
JJJ has a plugin:
https://github.com/stuttter/wp-blog-meta
Updated by Boone Gorges over 7 years ago
Oh, interesting. That's probably a good technical foundation for a certain kind of user-facing tool, but I'm not sure it's ideal if our goal is to have a controlled vocabulary of site types. We could use some discussion about the uses to which we see this metadata being put.
Updated by Matt Gold over 7 years ago
Hi Boone,
Here are a few use cases that have come up for the potential teaching tag:
-- we need to pull together a list of teaching-related sites on the Commons for a presentation or report; being able to pull up a list by search for sites tagged "Teaching" (or whatever) would simplify that process
-- when a user is creating a site, we could potentially make suggestions for themes/plugins or point people to documentation (about, say, assignment design on a site like the Commons) depending on what type of site they are creating
Updated by Luke Waltzer over 7 years ago
I think we don't know very well what sites are being used for on the Commons right now... this kind of data will help us prioritize features, tune support, and target outreach.
This discussion could dovetail with coming discussion of OpenLab abstraction... can we piggyback the collection of this data onto the downstream configuration that happens when you launch a course, project, portfolio, or group? I assume this functionality will be abstracted into CBox?
Updated by Boone Gorges over 7 years ago
- Category name set to Blogs (BuddyPress)
- Assignee changed from Boone Gorges to Luke Waltzer
- Target version set to Future release
Thanks for the use cases, Matt and Luke. They give me a sense of how the data probably ought to be stored so that it's available for easy querying.
This discussion could dovetail with coming discussion of OpenLab abstraction... can we piggyback the collection of this data onto the downstream configuration that happens when you launch a course, project, portfolio, or group? I assume this functionality will be abstracted into CBox?
On the OpenLab, site types are inherited from group types, which works because all sites belong necessarily to a group. This won't work for the Commons.
To move forward, I think we need a sense of what a minimal user-facing interface and workflow would look like. Broadly speaking, there are three ways that this kind of data appears in UIs (I'll use "site type" to describe the content we're talking about):
1. Displaying existing site type. This could be in site directories, on single sites, in the Network Admin, etc.
2. Providing an interface for filtering by site type. This could be either public facing (commons.gc.cuny.edu/sites) or Dashboard-only (Network Admin)
3. Updating site type for a given site. There's a handful of places where this might happen: site Dashboard, Network Admin, somewhere in the BP interface
If we want this information to be fully public - kinda like "profile" data for a site - then all three items would have to be user-facing, probably somewhere in the BP interface. If we are primarily interested in internal data, at least at first, we might make it Dashboard-only, and we may even skip item 1.
These sorts of things are best built with one or more specific use cases in mind. A couple of brief narratives would be useful. Here's an example, totally off the top of my head:
The CUNY Academic Commons team wants to run periodic reports on how many groups are in a given category. Users will volunteer the "type" of their site during site creation, but thereafter the data will only be available to the Commons team. Queries will be in the form of an admin panel summarizing "type" statistics, which can be exported to CSV. Existing sites can be categorized only by network admins, via the WP Network Admin dashboard.
More could be said about this example - how should the summary data be displayed, for example? is the "type" vocabulary hardcoded or free-entry? etc - but it provides a framework for us to think about an inital implementation. Having two or three of these that are realistic (rather than plucked from thin air by yours truly) would help us to get a sense of what would constitute an MVP, etc.
Luke, can I ask you to think about this? If you can sketch a couple use cases - it's fine if they're invented, as long as they're realistic and specific - I'll be better positioned to estimate scope and so forth.
Updated by Boone Gorges over 6 years ago
- Related to Feature #8836: Redesign site launch process added
Updated by Boone Gorges over 5 years ago
- Related to Feature #10987: Site/group creation portal added