Open pjcj opened 10 years ago
By author would be great. It would quickly let me see which of my releases have the worst coverage and need improvement.
I probably won't have the time to implement this, but here's a sketch of a UI design that would probably work decently well:
Stuff all of the data you have right now into a JSON array containing hashes for each dist. Have a search field people can type into, for example something like "Catal", then have an onChange event that searches through the JSON array and gives all entries where the dist name, module name, or uploader name match /._C._a._t._a.l./i and then render those as HTML.
Include a button for "render everything".
Maybe include additional number fields to filter out and display dists that have total/stmt/branch/... values above or below a certain value.
Maybe also include a button for "show all dists with N/A".
If it turns out that any of these options still result in excessive rendering times, do the filtering and gathering of the result, and display something like "20 hits in 30000 dists, click here to render" and have it render immediately if the hit count is below a certain number.
(@Tux_) Mithaldu, having a top-level (static) JSON would be nice to download and do statistics on :P
(@pjcj) Tux_, Mithaldu: something more than http://cpancover.com/latest/cpancover.json, or had you not seen that?
(@Tux_) exactly that.
(@Tux_) include the author pls
(@pjcj) yeah, I have an open bug for author
(@Mithaldu) one obvious thing i see missing is a single flag noting that a dist has no coverage data whatsoever
(@Mithaldu) and if possible a field for the main module it provides
(@Mithaldu) so people who search::with::colons get results
(@Tux_) yes, including the dist would be a requirement too
(@Mithaldu) i'm also a little confused as to why there's total in coverage and total in total :)
(@pjcj) the idea is that is it a subset of a number of more detailed files such as http://cpancover.com/latest/cpancover.json
(@pjcj) er, such as http://cpancover.com/latest/Text-CSV-Field-1.01/cover.json
(@Mithaldu) feels like each one should have an entry with a link to the full version
(@pjcj) yeah, could do
Since http://cpantesters.org/ covers much the same territory as cpancover.com, couldn't we borrow some of their approach to search via Distribution vs. search via Author?
Today, the top level page has distributions by first character, and for each character all items are listed for each version.
Ignoring the author thing, which sounds interesting, I'd like to propose changing the per character pages to show the first word only (treating -
as a word break).
I'm not quite sure the value of showing coverage for lots of versions, so I'd be inclined so have the page that actually lists modules only show the "newest" version and have it link to a page that has the other versions.
Now that coverage is displayed on metacpan this ticket is less important and has a lower priority, but it would still be nice to make improvements. Thanks for your proposal.
There are now over 25,000 CPAN modules for which coverage is available. Sticking them all in one table on the front page of http://cpancover.com has not scaled ;-) Something needs to change.
The table could be broken into separate pages. This could be by author (P/PJ/PJCJ etc) or by module name (G/Gedcom etc). I'm not particularly happy with either of those, but implementing one or both would be better than what we have now. Perhaps there are better solutions?
At the moment, all of cpancover.com is static. This brings many advantages, and also disadvantages. I am not averse to adding a dynamic component, or even making the whole thing dynamic, but we need to ensure that performance is reasonable.
We should also consider metacpan integration, which may take some of the pressure off having a cpancover interface which supports searching, for example.
The code starts somewhere around https://github.com/pjcj/Devel--Cover/blob/master/lib/Devel/Cover/Collection.pm#L286