Closed Bug 768218 Opened 8 years ago Closed 8 years ago

[ia] Implement product models

Categories

(support.mozilla.org :: Knowledge Base Software, task, P1)

Tracking

(Not tracked)

RESOLVED FIXED
2012.13

People

(Reporter: rrosario, Assigned: willkg)

References

Details

(Whiteboard: u=user c=wiki p=2)

Attachments

(2 files)

KB Articles will be assigned to one or more (possibly none?) products. We are currently abusing tags mixed with hard coded product list (`PRODUCTS` in apps/wiki/config.py) to kind of do this. It's time to do it right.

At the very least, products need:
* Slug
* Display name
* Description
* Display order
* Image (this might just be by convention at <media_url>/img/products/<slug>.png or something like that)

Display name and description need to be localizable. See http://kitsune.readthedocs.org/en/latest/localization.html#strings-in-the-database.

For now (and hopefully forever), this will be managed through the django admin.
Blocks: 768210
Blocks: 768226
Blocks: 768244
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #0)
> KB Articles will be assigned to one or more (possibly none?) products.

Yep. If a KB article doesn’t have a product associated with it, then it’s something used to populate some other pages or for contributor’s use.

When you think about it, contributor could even be thought as another “product”. Doing this will put all contributor-related articles under a slug that exists parallel to the product-level, but this is taking things too far and breaks our implementation.

Display order will be needed, and I think there only need to be one that we can apply site-wide. We have several different look to the product picker, but each contains essentially the same items, in the same order, sitewide.
(In reply to Bram Pitoyo [:bram] from comment #1)
> When you think about it, contributor could even be thought as another
> “product”. Doing this will put all contributor-related articles under a slug
> that exists parallel to the product-level, but this is taking things too far
> and breaks our implementation.

I kind of like this idea, but it could be a topic too.

This makes me wonder if products (and possibly topics) should have an ON/OFF switch to show/hide in the UI. It could be useful for getting a product/topic ready to go but not visible yet. Also, it would allow us to have these special internal products if that is desired.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #2)
> I kind of like this idea, but it could be a topic too.
> 
> This makes me wonder if products (and possibly topics) should have an ON/OFF
> switch to show/hide in the UI. It could be useful for getting a
> product/topic ready to go but not visible yet. Also, it would allow us to
> have these special internal products if that is desired.

Yeah. Whether contributor-related items or special pages should be considered its own product or topic (or even document type!) is up to us. It’s something we should talk to Matt and Verdi about.

I like the ability to prewrite all the support articles for a product that’s not ready to release. I reckon that we will have such scenarios in the future with Marketplace, Persona and B2G, or new features that we will have (features will probably be related to a topic).

Doing this will allow us to prepare all the assets for a specific product, and hit one switch on launch day to make everything appear and activate.
That was one of my suggestions early on and how we prepared new products for launch. I always appreciated the feature. Now that we are creating more products, I think it will be more useful.
Priority: -- → P1
Whiteboard: u=user c=wiki p=
Whiteboard: u=user c=wiki p= → u=user c=wiki p=2
Made 2 pter after discussing with team. It is the typical django model creation along with admin.py and a db migration.
Contributor documentation should not be it's own product. Those articles should be normal articles and we'll assign topics to categorize them. Like: "Get involved" and "localization".
Target Milestone: 2012Q3 → 2012.13
Grabbing this one.
Assignee: nobody → willkg
(In reply to Kadir Topal [:atopal] from comment #6)
> Contributor documentation should not be it's own product. Those articles
> should be normal articles and we'll assign topics to categorize them. Like:
> "Get involved" and "localization".

What product are they assigned to then? One of our requirements in https://wiki.mozilla.org/Support/Kitsune/Features/Auto-Nav#Authoring: is:

[P2] You must select a Product before you select a Topic
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #8)
> [P2] You must select a Product before you select a Topic

This is correct. In the admin interface, this is done so that no KB article is an orphan with no product or a topic.

My argument for making contributor as a service is thus:

Note that the use of “Product” in SUMO actually encapsulates both products and services. It is designed in the wireframes like so. It’s even named like so. I think we can argue that contributor-related service is a special kind of service that Mozilla provides.

Let’s extend this argument to a hypothetical example: when a user is logged in as a contributor, one of the items under products and services will be called “contributors services” or “contributors resource”. I would argue that the idea may sound weird, but this item doesn’t necessarily look out of place amongst other products and services.

This goes to show that contributor-related articles can be viewed as a kind of service, and it won’t break our current model or requirement.

What do you think?
I think that works Bram. In the past I've also seen it done so that anything that doesn't belong to a specific product gets tagged to the top level product selection (all products) making it available to show on any page.
I haven’t really thought of something as having an “all product” topic. Would it work as its own distinct topic, or a lack thereof?
They way I've seen it before is that all tags are part of a tree. So it would look like:

Products/
   Firefox
   Firefox Home
   Firefox for Mobile
   Thunderbird

If you wanted something available for 1 topic, you only select that single topic. If it applies to more than one,  you can select more than one child topic. If you have content that applies to all products, you select the parent and all the children inherit that document as well. That way if we add a new product, anything tagged to Products would automatically show up in that new product. That way you don't have to go through and manually add those documents to the new product. 

That is one very common way I've seen it done. Does not mean that it's the best way!
I have a few questions:

1. For the kb, we already have categories. Seems like some of the use cases mentioned in this thread overlap with existing uses of categories.

Are we planning to ditch categories in favor of products/topics?

2. There's a requirement that all kb articles get assigned to one or more products.

Does that work for all the kb articles we currently have?

I think it's implied that the answer to this is "no" and that there are categories of kb articles presently where it would be awkward to assign them a product using Bram's definition of a product.

Is it really necessary to keep the "all kb articles get assigned to one or more products" requirement? What's the impetus for this requirement?

Could we work around the issues by creating a "No product" product?
I talked with Ricky, Kadir, Matt and Bram and here's the answers:

(In reply to Will Kahn-Greene [:willkg] from comment #13)
> I have a few questions:
> 
> 1. For the kb, we already have categories. Seems like some of the use cases
> mentioned in this thread overlap with existing uses of categories.
> 
> Are we planning to ditch categories in favor of products/topics?

No. The navigation category will go away in the future.


> 2. There's a requirement that all kb articles get assigned to one or more
> products.
> 
> Does that work for all the kb articles we currently have?
> 
> I think it's implied that the answer to this is "no" and that there are
> categories of kb articles presently where it would be awkward to assign them
> a product using Bram's definition of a product.
> 
> Is it really necessary to keep the "all kb articles get assigned to one or
> more products" requirement? What's the impetus for this requirement?
> 
> Could we work around the issues by creating a "No product" product?

This requirement isn't quite right.

The requirement is that all kb articles visible to users should be in one or more categories otherwise they'll never get shown to the user.



Given that, we're changing the requirement to this:

1. kb articles will have ZERO or more products

2. we'll add business logic in the kb/new and kb/edit forms that require the contributor choose at least one product for kb articles in specific categories, but enforcing that will be in the form and not the db

3. a small number of kb articles (< 20) will be in ALL products and every time we add a product, we'll need to update the kb article. there are a bunch of ways to do this, but none of them involve data model requirements.
Re-summarizing the bug at this point gives us this work:

KB Articles will be assigned to zero or more products.

Initial list of products is in apps/wiki/config.py.

Product data model needs:

* Slug
* Display name
* Description
* Display order

Display name and description need to be localizable. See http://kitsune.readthedocs.org/en/latest/localization.html#strings-in-the-database.

The image for the product will be located in a specific place in the file system and will be updated in git. So it doesn't need to be accounted for in the data model.

For now, adding, updating and deleting Products will be managed in code with migrations.
Jotting down notes so I don't lose them:

* making this its own app: apps/products/
* need to think about versions
* there's a bunch of code that figures out the product from the user-agent--that 
  should probably get moved here, too, at some point
* there's also django-mozilla-product-details which I should look at--no clue if
  that's related or not
(In reply to Will Kahn-Greene [:willkg] from comment #16)
> * need to think about versions

If this refers to the product’s version, might we need to think about OS as well?
(In reply to Bram Pitoyo [:bram] from comment #17)
> (In reply to Will Kahn-Greene [:willkg] from comment #16)
> > * need to think about versions
> 
> If this refers to the product’s version, might we need to think about OS as
> well?

True. We could easily make this over-complicated though by tying everything together tightly. Probably makes sense to find out exactly what the requirements are and then create the least-coupled architecture for Product, ProductVersion, and OS we can from that.
(In reply to Will Kahn-Greene [:willkg] from comment #18)
> True. We could easily make this over-complicated though by tying everything
> together tightly. Probably makes sense to find out exactly what the
> requirements are and then create the least-coupled architecture for Product,
> ProductVersion, and OS we can from that.

The new IA isn’t going to change the product/version/OS relationship that we have today. Plus, we found out that most users won’t need to switch version or OS. Contributors and admins will.

Thinking out loud:
* Upon document creation, user will need to pick one product at a minimum
* A list of topics will appear that relate to the products selected, user will need to pick one topic per product at a minimum
* Version and OS will be handled via {for}{/for}, as the way it works today
Imagine this to be the article creation interface. Note that the topic field is empty. It waits for a product to be selected.
Attached image Article topic selection
After a product is selected, the list of topics appear. To make things easy, I’ve visually grouped the topics.

For example, if I select “slowness” or “crashing”, it will go under the topic called “Fix slowness, crashing, error messages and other problems”.
Bram: This bug is just for implementing the product model specifically to use for the kb. The other bits are bits we were musing about because products will also eventually get used for the support forum where we currently have tags for operating system and product and version.

The screenshot for selecting a topic should get added to the "Implement topic models" bug.

Anyhow, this is just for implementing the data models. I've got the work almost done now.
Adding [ia] to title.
Summary: Implement product models → [ia] Implement product models
Pushed to production just now. Marking as FIXED.

Bram: I can't tell if some of the things you've said in the comments here suggest there are other things we need to implement that aren't accounted for in appropriate bugs or not. If there are things missing, we should probably write up bugs for them.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
(In reply to Will Kahn-Greene [:willkg] from comment #25)
> Pushed to production just now. Marking as FIXED.
> 
> Bram: I can't tell if some of the things you've said in the comments here
> suggest there are other things we need to implement that aren't accounted
> for in appropriate bugs or not. If there are things missing, we should
> probably write up bugs for them.

Will: the mockups attached here should be applied to the contributor-facing part of the Edit Article.

We know that the edit/admin interface will behave similarly to the way it works today, with a few streamlining to add/remove things that are frequently or never used. It will also look similar to Lee Tom’s new visual design.

If the product model is done and the topic model done soon, we can apply the changes to the current interface . If not, we can apply it to the interface post-redesign.

But you are correct, this is another bug to fill.
You need to log in before you can comment on or make changes to this bug.