Closed Bug 587616 Opened 14 years ago Closed 14 years ago

[UX] Create new per-site cluster pages

Categories

(Input :: General, defect, P2)

Product:
Input
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: wenzel, Assigned: wenzel)

References

(
URL
)

Details

The UX Overhaul has two new pages for the sites clusters:

1) All clusters for a specific site
http://people.mozilla.com/~chowse/drop/mozilla.com/input/style/site-themes.html

For a given domain, this page shows all clusters associated with this domain.

This is supposed to show up when you click on a domain name from the Sites main page.


2) All messages in cluster
http://people.mozilla.com/~chowse/drop/mozilla.com/input/style/theme.html

When clicking on a "prototype" message on the Sites main page, this takes you to this page, showing all messages in that same cluster.
(In reply to comment #0)
> 1) All clusters for a specific site

I got an initial page up for this one:
http://github.com/fwenzel/reporter/commit/913d41b

There are still some caveats.
a) CCing Chowse: Chris, the smilies seem to indicate that each of the clusters is of type issue or praise only. That does not seem to be true with the current data. Clusters can contain either. CCing mkurze to confirm.
b) Michael: Is it true that the same site has multiple IDs in the database? It seems, that breaks the buttons in the sidebar :( For example, if I am looking at site=1, then click on "latest beta" instead of "7 days", nothing is found anymore. Do you have a suggestion on how to fix this? If it's too hard to do, we could remove all buttons but the ones that are currently active.
(In reply to comment #1)
> There are still some caveats.
> a) CCing Chowse: Chris, the smilies seem to indicate that each of the clusters
> is of type issue or praise only. That does not seem to be true with the current
> data. Clusters can contain either. CCing mkurze to confirm.

I was told that clusters were exclusively praise or issues at the moment, and designed the UI accordingly. If clusters can include a mix of both, the places we use smilies will change slightly. There are certain UI elements I'd be interested in resurrecting (e.g. sorting/filtering by praise/issue ratio), if not necessarily for 1.7.
Comment 9 a) The clusters selected by "both" can contain either. The clusters selected by praise/issues respectively are made up by only those. Sorry if I miscommunicated this or if I misunderstood the requirements. Would it be more useful to change this? Or should we leave it this way and change the UI?

Comment 9 b) Yeah, that is not factored out into a different table (for that reason I called the model SiteSummary, not Site). I guess we could fix this by using the url for links instead of SiteSummary.id -- this would also make links more permanent, as all the ids are regenerated over night.
comment 9 a) addition: I think I had the clusters separated originally and changed that after talking to chowse and aakashd about that we could also combine them. But maybe that was not really intended and I was jumping a step too much ahead there.
Aakash, what is more useful to QA?
It'd be more useful to triagers that it's separated. It'll be easier to find issues when the context is set around happy and sad for clustering.
Okay, I'll update the generate_script accordingly and add a new field to the cluster-model to make it possible to actually distinguish happy and sad clusters from code.
(In reply to comment #6)
> Okay, I'll update the generate_script accordingly and add a new field to the
> cluster-model to make it possible to actually distinguish happy and sad
> clusters from code.

Just to clarify, does this mean that each cluster will be composed exclusively of happy messages or exclusively of sad messages? No mix of happy/sad messages in a single cluster?
Yep, it should be. The clustering is a lot less useful when we incorporate happy and sads within the clusters. With that said, the "All" part of the site will still show happy and sad clustered opinions in the same list, but those clustered opinions are only strictly happy or sad. The entries should be ordered by the number of similarities.
Okay, I changed the clustering so that each cluster contains either only praise or only issues. This is all handled when generating, nothing has to be changed in the using code.
There is a new field Cluster.positive to help decide which Icon should be used.
Another followup to Comment 2 (answer to a)):

The way the database is designed, might benefit from an explanation so that it does not appear arbitrary, and might be easier / more satisfying to work with:

The method is "dimensional modeling" (not traditional ER modeling, I *do* know about normalization :), and is often used for analytics databases (build once, query often). 

Basically, a row in the sitesummary table is not a website in any way. It stands for "all clusters that share the same coordinates in the search space". The search space has 3 "dimensions" in this case: 
- 'version' (e.g. "<day>", "<week>", "4.0b3")
- 'positive' (True, False, "Both")
- 'url' ("http://google.com", "https://google.com")
The other fields in the table (the so called "facts") are just precomputed aggregate values over the matching comments / clusters. Now, of course a cluster can be at multiple coordinates in the search space (latest beta and latest 7 days, or happy and "Both"), so it is aggregated into multiple sitesummary records. For that reason, version and positive always need to be specified in queries (urls do not need that, as they are disjunct).

So the reliable way to link to a search result is to use the actual search parameters for *all* dimensions (e.g. with three get parameters, maybe with defaults). This will also yield the most useful (if not the same) results if the link is shared and reused in the future. 
The SiteSummary.id is intended to link clusters to their search coordinates, not to reference these search coordinates.

In the future, a "locale" dimension could be added (where the "all" coordinate-component maps 1:1 to the current site summaries), which would allow to also cluster by locale, and filter by them.
All right, I am now converting the site.id to a search for the URL automatically: http://github.com/fwenzel/reporter/commit/2f050d8

On the single-site page, the buttons on the left hand side will then result in a new search for clusters, but that's how the data is currently set up. If we want to change this eventually, we'll need to have a single ID per site in the database, but that's out of scope here.

I also added the smilies to the "all clusters" page: http://github.com/fwenzel/reporter/commit/c66208d

The "single site" page (comment 0, no. 1) should be done.
Assignee: nobody → fwenzel
Comment 0, no. 2 is actually the same as bug 586925.
Depends on: 586925
Priority: P1 → P2
If you want to show a different page when a single site is selected, maybe that should be a different view.
Or at least you could use a parameter that says "show single site". I think that is the true function of the site.id here. The search parameters identify individual sites just as effectively.
(In reply to comment #13)
> If you want to show a different page when a single site is selected, maybe that
> should be a different view.

It is: http://input.stage.mozilla.com/en-US/sites?site=1

(Currently 500-ing due to a typo, oops. Already fixed.)
Hmm, judging from the urls.py 

http://input.stage.mozilla.com/en-US/sites and
http://input.stage.mozilla.com/en-US/sites?site=1

Seem to be the same view, just including a different template depending on whether the site parameter is set. 
I would imagine a different URL-pattern (e.g. /sites/site/url instead of /sites), where the URLs generated by the button clicks stay on that pattern. Because the URL-textfield is hidden and fixed on that page, there will always be the right thing shown.

Of course you don't necessarily need separate django-views (helps with generating URLs though), but a different URL pattern + search coords would be just as good (and more permanent) than a site id.
(correcting myself: if the url is included in the pattern, no hidden field is necessary, only if the pattern was like /sites/site&q=url)
I like your suggestion.
Target Milestone: --- → 1.7
Blocks: 588053
(In reply to comment #0)
> 2) All messages in cluster
> http://people.mozilla.com/~chowse/drop/mozilla.com/input/style/theme.html
> 
> When clicking on a "prototype" message on the Sites main page, this takes you
> to this page, showing all messages in that same cluster.

I added the view for this:
http://github.com/fwenzel/reporter/commit/a9b3cf9
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Blocks: 589758
Component: Input → General
Product: Webtools → Input
You need to log in before you can comment on or make changes to this bug.