Closed Bug 540885 Opened 12 years ago Closed 12 years ago

New Statistics Dashboard Designs

Categories

(addons.mozilla.org Graveyard :: Statistics, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: fligtar, Assigned: chowse)

References

()

Details

This is the design bug for the new stats dashboard, as described in this doc: http://docs.google.com/Doc?docid=0Acwo2Bn17-PrZGZudHRobnJfMzBkOTZkdnNodg&hl=en
First iteration mocks:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v4/01_overview.png
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v4/02_downloads.png
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v4/03_users.png
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v4/04_contributions.png

(Please forgive the quality of the charts, these will improve once the content/layout is finalized.)

Feature complete, except:
* CSV export is missing, but should be easy to integrate. Need to determine which data points are exportable.
* No easy way to get an ADU breakdown by OS/locale/etc for anything except the current week.
* Selecting time periods except the last 7/30/90/365 days. I have a 'custom time period' UI planned, but wanted to get these designs out first.

Please feel free to comment on anything-- layout, completeness, usability, technical feasibility, whatever.

I'm not happy with the way the time period is selected and how it relates to other panels on the page. I'm working on a design alternative to fix this, which should be finished sometime tomorrow.
And here's the design alternative:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/01_overview.png

Upsides:
* Every kind of report/breakdown is now clearly visible, instead of scattered everywhere as in the previous design. Makes navigating to a specific report much easier. Also makes the extent of this dashboard's power much more visible.
* The time fields (Last 7/30/90/n days) in the top right corner now affect every part of the display. Changing this affects every panel on the page. Greatly improved consistency, and avoid replicating these controls in every panel.
* Plenty of good places to add Export controls, help text, etc.
* As new kinds of reports/views are added, this design will be easier to extend.

Downsides:
* Nav bar on the left eats up valuable horizontal space. Putting 2 cols (340px) or 3 cols (220px each) on one row doesn't leave much room for data. Not a problem on most of the pages, but on the Overview page, where you want to include a lot of different kinds of data, this limits the number of interesting things you can show.

As before, feedback is welcome. I will flesh out a few more of the pages using this design, and finish the UI for selecting an arbitrary time period.
Hey Chris,

These are looking good. I like your alternative overview better. I'm interested in seeing what you have in mind for the subpages in this format, and then we can decide on it for sure.

Also, let's replace the download sources box on the overview with top applications, like:
Firefox  90%
  3.6    5%
  3.5    75%
  3.0    20%
Thunderbird 8%
  2.0    90%

Thanks!
One thing we're continually plagued with is bad data - bogus operating systems, bogus versions, etc.  Maybe we want to group everything under 5% into an "other" category or something, or maybe do nothing, but consider that these lists and graphs will grow very long with sparse data.
Yes, I like that chowse's mocks show the real OS names and would like us to do a mapping for that and make the gibberish harder to find.
More mocks:

CUSTOM DATE UI
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/02_custom_date.png
Slide-down widget for selecting a date range different from the last 7/30/90 days. Also allows grouping by day/week/month. Like the other date options, this affects every chart/table on the active page.

SUB-OVERVIEW PAGES (example: Downloads page)
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/03_downloads.png
Similar to the Overview page, but focused on a single data series (e.g. downloads, adu, contributions). If an author is looking for straight-up counts (w/o breakdows), this is where they'll go. These pages feels a little light right now, so I either need to find more to add, or find a way to fold them into other pages.

BREAKDOWN PAGES (example: Downloads by source page)
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/04_download_sources.png
Stats broken down by different dimensions. While there are plenty of variations, they all follow this general template: a time series plot of the top 5 at the top, and a table of every value below. The author can change which values are plotted, and the table provides comparisons between the currently selected time range and all historic data.
(In reply to comment #3)
> Also, let's replace the download sources box on the overview with top
> applications

Easily done. Any reason for replacing Download Sources in particular? It seems like that would be more interesting than, say, OS usage (unless your add-on has binary components).

(In reply to comment #4)
> One thing we're continually plagued with is bad data - bogus operating systems,
> bogus versions, etc.  Maybe we want to group everything under 5% into an
> "other" category or something, or maybe do nothing, but consider that these
> lists and graphs will grow very long with sparse data.

No argument here. For time series, I believe we should only show the top 3-5 values, and leave any others user-selectable. For pie charts, anything that represents <5% of the total should be grouped under 'Other'. Tables could safely grow to any size, but any more than 3 pages of rows probably wouldn't be too useful.

Some other questions about the data we have:
* Do we have any geographic data about add-on usage?
* For some of the ADU data we have (language, OS, etc.), do we have the same data for downloads?
* Do we have a way of identifying new users of an add-on? or when someone uninstalls an add-on?
While download sources are really interesting to us, I think they're less interesting to add-on developers, who aren't that concerned about which page a download came from. However, they are extremely interested in who is using their add-on, so things like applications, locales, and OS tell them what they need to support in the add-on.

And yeah, I know what you mean about the pages being light, which is why in my sketches I ended up putting everything on the main pages. But I'm fine with either way.

> * Do we have any geographic data about add-on usage?
It's possible to associate the ping IPs with geo data, but that would mainly be work for the metrics team and I'm not sure it could be done in time for the launch. If you wanted to mock it up for later implementation that would be cool. We should probably stick to continents only and not drill down more than that.

> * For some of the ADU data we have (language, OS, etc.), do we have the same
> data for downloads?
We could potentially take it from the downloader's user agent, but again this is something that would mainly be blocked on metrics. I will file a metrics but for these but we should assume it won't be ready for the launch.

> * Do we have a way of identifying new users of an add-on? or when someone
> uninstalls an add-on?
We can't tell if the difference in ADU is because of new installs, uninstalls, or people just not using Firefox that day.
(In reply to comment #8)
> And yeah, I know what you mean about the pages being light, which is why in my
> sketches I ended up putting everything on the main pages. But I'm fine with
> either way.

I'm sure PRODUCT will find ways to weigh these pages down.  It's good to start light.
Some updates and new mocks available here:
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/

A few highlights:

DOWNLOADS PAGE
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/03_downloads.png

Moved the help text over to the right, and added some links to the bottom-center panel to flesh out the page more. Still feels a bit light, but not unreasonably so. One idea:

* Remove the help panel (or move it back to the left) and add a 'Top Download Sources' panel. This will look unbalanced (the right panel will easily be taller) but adds more data ink.


DAILY USERS 
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/05_users.png

Made similar changes as the Downloads page. This feels even lighter, since there's only one good running total we can show. If anyone can suggest others, please do. Compared to downloads, daily users have many more breakdowns. So:

* We could add one "user breakdown" panel where the help panel currently is, and 3 others in a row below it. This adds a lot more data ink, but feels even more lopsided than the Downloads example.
* Get rid of the "running totals" panel altogether. Put three (or even all 5) breakdown panels where it used to be. Maximizes data down, but starts to become a wall of text. 


CONTRIBUTIONS
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/07_contributions.png

Following the mold for these overview pages. With the list of recent contributions, light-ness won't be an issue with these pages. However, I think there could be some other interesting data we could add, like:

* Top 5-10 contributors by $ amount (one-time or cumulatively).
* Regular/frequent contributors (by date or amount contributed).
 

HI-FID EXAMPLE
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/01_overview_hifi.png

A quick glimpse at how these mocks would fit into the current AMO design. 


Not much left to do, except:

* Mock the remaining breakdown pages. Almost all of them will resemble the Download Sources page (http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/04_download_sources.png).
* Finish the UI for selecting what series to show in the plot (e.g. the 'Change' link in the upper-left corner of the Download Sources plot).
* Creating hi-fid versions, flows, and specs.

If anything seems to be overlooked or needing to be changes, please give me a heads up.
Looks good. A few comments:

* We should have CSV links for pretty much all the data on the detail pages, and it'd be nice to have the table with the actual numbers as we do in the current dashboard on the breakdown pages.
* In the hi-fi mocks, there's a noticeable lack of rounded corners like we have on the rest of the site. Is that intentional or was it just assumed they would be rounded?
* Keep in mind that most add-ons don't have contributions, so on the summary page that third spot may be empty.
(In reply to comment #11)
> * We should have CSV links for pretty much all the data on the detail pages,
> and it'd be nice to have the table with the actual numbers as we do in the
> current dashboard on the breakdown pages.

I can place these in a table at the bottom of each page, along with the export link. Is it essential that it be initially visible, though? For several pages (e.g. locale), loading the table really seems to slow performance. It also strikes me as data that would be more likely to be downloaded and used in a separate app, than studied directly in the browser. I don't want to remove functionality, just put emphasis on the things the dashboard's best for.


> * In the hi-fi mocks, there's a noticeable lack of rounded corners like we have
> on the rest of the site. Is that intentional or was it just assumed they would
> be rounded?

I did the hi-fid mock quickly in Omnigraffle, so I cut a few corners visually. The final mockups will fit the current site design more closely (rounded corners, multiple borders, etc.).


> * Keep in mind that most add-ons don't have contributions, so on the summary
> page that third spot may be empty.

I can live with that. I don't mind leaving a small gap there, but if necessary, we could leave some placeholder text (e.g. Contributions disabled), or just expand the remaining two items to fill the empty space. Contributions could simply be removed from the nav menu in such a case.
(In reply to comment #12)
> Is it essential that it be initially visible, though?

No, I think it's okay to hide them at first.
Updated wireframes w/ tabular data and export links:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/03_downloads.png
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/04_download_sources.png
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/05_users.png
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/07_contributions.png

Not too different than the current tables, but adding value bars when there's only 1 or 2 columns.

Also added a page for Users by OS:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/06_user_os.png

Only thing left to prepare is the series selection UI (e.g. how to pick what OSes get plotted). This opens up some questions about how things will get grouped (i.e. by minor release, point release, etc.), but I'll have the layout ready to go, regardless.
And here's the series selection UI:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/09_custom_series.png
http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/09_custom_series_alt.png

Two possible directions for it: 1) a huge list of check boxes for every option, with an unlimited number of series selectable; and 2) a few drop-downs for selecting a few series to display. I'm more partial to the latter, since it lends itself better to comparisons (i.e. pick a few series you want to compare) and doesn't risk exploding in options like the first option. I'm open to your opinions, though.
finance.google.com does it with some default checkboxes and an <input> to add more if you're looking for more ideas.  I'm fine with the dropdowns though.
(In reply to comment #16)
> finance.google.com does it with some default checkboxes and an <input> to add
> more if you're looking for more ideas.  I'm fine with the dropdowns though.

<input>s would work great for the larger lists (e.g. app versions), but would have to be auto-completing. Smaller, discrete lists (e.g. OSes, download sources) could simply be lists of check boxes. More powerful and probably just as usable, but certainly more complex development-wise.

On a related note, how difficult would it be to support clustering of series? For example, when breaking down usage by application, could we present it by app (Firefox), major release (Firefox 3.5), and/or point release (Firefox 3.5.6)?
I would like to see more trending data for instance a column with d/d-7% so basically a comparison in the daily view of that day vs the previous same weekday.  Should be red if negative and blue if positive.
(In reply to comment #18)
> I would like to see more trending data

Isn't that what the plot is for? ;)

Actually, I intended to include some comparison data in a previous design. For example, here's the Downloads page w/ a comparison to the 7 days before last. I also added the trend column you suggested:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v5/03_downloads_trends.png

But for this to work, I have to work out a few problems:

1) How does this work if the user chooses Last 30 Days? Does it compare each month to 3 months before? 1 year? all of the above? Similar question for Last 90 Days or any arbitrary time frame?

2) The label "Last 7-14 Days", meaning the 7 days that preceded the last 7 days, is very awkward. But I can't find a better label without getting very verbose. This problem affects a lot of labels: how to describe concisely/clearly what is being compared.
For the plot selections, I'd prefer the dropdown option to the checkbox. However, a third idea that I included in my sketches was just having a checkbox next to each item in the list below to show it on the graph. Since we're already listing them out there, I don't think it would be such a disconnect that no one would figure out how to use it. Especially if we automatically check the first few for them.
(In reply to comment #20)
> However, a third idea that I included in my sketches was just having a checkbox
> next to each item in the list below to show it on the graph.

This isn't a bad idea. But to be effective:

1.) This has to update the chart with Javascript/AJAX. Putting an update button at the bottom will go unnoticed, and a page refresh on check/uncheck feels awkward.

2.) It should add the appropriate color/maker beside the label.

3.) The initially-selected items really must be the first ones in the list. This means whatever algorithm we use to pick what series are first plotted (e.g. fixed order, top ranked), we need to use the same algorithm to order the list.
(In reply to comment #21)
> 1.) This has to update the chart with Javascript/AJAX. Putting an update button
> at the bottom will go unnoticed, and a page refresh on check/uncheck feels
> awkward.
> 
Yes, I assumed that the only page loads would be when switching between items in the sidebar.

> 2.) It should add the appropriate color/maker beside the label.
> 
Agreed

> 3.) The initially-selected items really must be the first ones in the list.
> This means whatever algorithm we use to pick what series are first plotted
> (e.g. fixed order, top ranked), we need to use the same algorithm to order the
> list.
Yes, we currently rank plots and lists with the most popular/used/downloaded at the top and then plot the first few.
5.7 development starts Wednesday -- Chris, do you think you'll have the final mocks ready for then?
If there's no other feedback or features to add, then I should have comps finished by Wed/Thu. If there's any sanity checks as far as completeness or feasibility goes, just let me know before then so I can make the appropriate adjustments.
Blocks: 543548
For the 7-14 day issue I'd just do what we do in the daily report where we could just have the columns named "week" and "week-1" and "d" and "d-7" respectively.
(In reply to comment #17)
> On a related note, how difficult would it be to support clustering of series?
> For example, when breaking down usage by application, could we present it by
> app (Firefox), major release (Firefox 3.5), and/or point release (Firefox
> 3.5.6)?

This would be not be too difficult, though there will always be crummy data that gets grouped into "unknown".

If this were implemented client-side (along with rules mentioned in comment #5), then we would be able to present the user more viewing choices without making additional requests for data. The downside to this approach would be unclustered-only CSV downloads.
Style guideline finished:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/style/

Hi-fid mocks of the 3 page archetypes, and an AI file with all the color/font information. Most of the design reuses existing elements from the Clearleft design. However, if there are elements you need backgrounds or sliced images for, just let me know. There are 3 elements I know off the top of my head, and will have images for them in the next few days.

I've not included styles for the charts yet. I will use a local copy of Highcharts to generate the necessary parameters, then post them when I finish. Until then, Highchart's default styles for line charts will work fine.

I will be creating annotated wireframes for each of the archetypes next (about 75% done now), then creating wireframes for every individual page, listing breakdowns and data series.
Page templates, with annotations:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/templates/

I had to back out a few changes we discussed above, due to some usability issues that became apparent when making the hi-fid mockups. Will try to revise, but want to get everything else published first.
Chris, outstanding job on the templates. The annotations are crystal clear.

I see a couple of sizable challenges for implementation:

1. Currently we do not have detailed OS data to create the desired breakdown - particularly for Windows. An example of our current data can be seen in the field headings here: 

https://addons.mozilla.org/en-US/statistics/csv/1865/os?group_by=date

Can metrics can give us more?

2. Computing all-time stats for break-down fields is very expensive. We'll most likely need to do this via cron/gearman for each add-on and cache the results somewhere.

We'll probably also need to determine a cut-off for custom date ranges where these break-downs won't be computed live.

Or maybe I'm being too pessimistic? I should have methods for generating this data ready later today. I'll report back when I have more than just anecdotal concerns about performance!
Yeah, this is really detailed, thanks chowse!

Comments for mccammos:
> 1. Currently we do not have detailed OS data to create the desired breakdown -
> particularly for Windows.

Good point -- we actually don't get that level of detail from the update pings, so metrics won't be able to help us here. That field is actually referred to as the platform, not the OS, which is why we don't have the specific version. I think we'll just need to map the ones that we do know to pretty names ("Darwin" -> "Mac OS", "WINNT" => "Windows", etc.) and if we don't have a pretty name for something, show the raw name.

> 2. Computing all-time stats for break-down fields is very expensive.

I think we need to do this for some fields, but not all. For example, in the current Download Sources dashboard, we have an "all time" column that's not actually all time. And all-time data really is useful in many places.

If you think we can optimize the way stats are stored to improve this, now's a good time for those changes.

-----

Comments for chowse:
I was going to comment with these items in the implementation bug once the mocks were finalized, but since your designs are so detailed, I'll mention them here in case you want to make the changes:

* On the overview, "Most Used Versions" should probably be "Most Used Applications". Most Used Versions would be the most used versions of that add-on.
* The Most Used Versions box still says "More download sources" at the bottom
* There's a fifth breakdown for active daily users -- "by Add-on Status" which is currently available in the dashboards and shows whether the add-on is enabled, disabled, incompatible, blocklisted, etc.

-----

I intended to blog about the revamped Stats Dashboard a few weeks ago and forgot, so I'll try to do a quick post today.
(In reply to comment #30)
> * On the overview, "Most Used Versions" should probably be "Most Used
> Applications". Most Used Versions would be the most used versions of that
> add-on.
> * The Most Used Versions box still says "More download sources" at the bottom

Fixed.

> * There's a fifth breakdown for active daily users -- "by Add-on Status" which
> is currently available in the dashboards and shows whether the add-on is
> enabled, disabled, incompatible, blocklisted, etc.

Added, though I could use some input on what this is for, when I spec the individual page. Is it possible for a version of the add-on that's been disabled/blocklisted/etc. to be in circulation? Is this something developers would want to prevent? Do these add-ons represent a tiny percentage of the add-ons in use? If the answer is yes, Add-on Status might warrant a slightly different page.

> I intended to blog about the revamped Stats Dashboard a few weeks ago and
> forgot, so I'll try to do a quick post today.

If this can wait until Friday, I can give you a high-fidelity version of the Overview with a chart.
(In reply to comment #31)
> Added, though I could use some input on what this is for, when I spec the
> individual page. Is it possible for a version of the add-on that's been
> disabled/blocklisted/etc. to be in circulation? Is this something developers
> would want to prevent? Do these add-ons represent a tiny percentage of the
> add-ons in use? If the answer is yes, Add-on Status might warrant a slightly
> different page.

Yes, add-ons that are installed check for updates, even if they are disabled, blocklisted, or incompatible. For most add-ons this is a small number, but there are certainly add-ons that have larger numbers. For example, an add-on that is only compatible with Firefox 3 would have a lot of disabled and incompatible pings, and an add-on that is only used once a year might be disabled most of the time.

I don't think a different page layout is really necessary -- we can just make the values prettier, so instead of saying "userEnabled" just say "Enabled" and instead of "userDisabled;incompatible" we would say "Incompatible (Disabled)", etc.

> If this can wait until Friday, I can give you a high-fidelity version of the
> Overview with a chart.

Sure, it can wait.
(In reply to comment #32)
Thanks for the explanation. I misinterpreted "Status" as the add-on's AMO status, not its status in the browser. That stat makes much more sense.

> I don't think a different page layout is really necessary -- we can just make
> the values prettier, so instead of saying "userEnabled" just say "Enabled" and
> instead of "userDisabled;incompatible" we would say "Incompatible (Disabled)",
> etc.

Good points, all. And what I was considering wasn't radically different. Basically, I was thinking of _not_ plotting the 'enabled' status by default. That way, identifying disabled/incompatible/etc. add-ons would be much easier-- especially if they represented a tiny percentage of add-on usage.

> > If this can wait until Friday, I can give you a high-fidelity version of the
> > Overview with a chart.
> 
> Sure, it can wait.

Aaaaaaand done: http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/style/98_sample.png
Awesome! thanks
Wireframes for individual pages:

http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/pages/

I've left most of them unannotated, since: 1) I need to take an inventory of all the different data series we have; and 2) I need to determine what breakdowns we'll be able to provide historic data for. But this should provide a starting point for discussion.
Hey Chris,

One thing I just remembered that I'd really like to see on the overview page is the number of users on the latest version of the add-on that's hosted on AMO. This was in my ugly sketch mocks, but it's basically just a link that says something like "37% of users on the latest version (2.2)" and goes to the version breakdown page.
Made a few tweaks and updates:

* Added a panel below the sidebar for "Users with Latest Version", along with "Users with Incompatible Versions". This strikes me as a good place for 'notifications': events and conditions that the developer would be interested in.
  http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/pages/1.0_overview.png

* Added help blocks below the sidebar on the Statistic and Breakdown pages.
  http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/pages/2.0_downloads.png
  http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/pages/2.1_download_sources.png

* Changed the sidebar's visual design to closer match the Clearleft updates (compare two links below).
  http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/style/98_sample.png
  http://people.mozilla.com/~fligtar/zamboni/designs/2010-02-15/SERP-TryCategory-100215.png
Chowse-

the contributions mocks show the name of the contributor- we actually don't retain this info and therefore can't show it.  We can show individual transactions but with no PII.
(In reply to comment #38)
> the contributions mocks show the name of the contributor- we actually don't
> retain this info and therefore can't show it.  We can show individual
> transactions but with no PII.
Updated: http://people.mozilla.org/~chowse/drop/statistics_dashboard/v6/pages/4.0_contributions.png

Speaking of contributions:
* Do we know if a contribution was one-time or monthly? Does a monthly-contribution show up each time its sent?
* Do we have a page for listing all contributions (like for reviews, e.g. http://bit.ly/dcGvAx)?
(In reply to comment #39)
> * Do we know if a contribution was one-time or monthly? Does a
> monthly-contribution show up each time its sent?

I don't know.

> * Do we have a page for listing all contributions (like for reviews, e.g.
> http://bit.ly/dcGvAx)?

Nope.

What's the status of this bug?  Any further design or are we done?
(In reply to comment #40)
> (In reply to comment #39)
> > * Do we know if a contribution was one-time or monthly? Does a
> > monthly-contribution show up each time its sent?
> 
> I don't know.

I will assume not, then. Will update the contribution page accordingly.

> > * Do we have a page for listing all contributions (like for reviews, e.g.
> > http://bit.ly/dcGvAx)?
> 
> Nope.

I can create a lightweight page for this (similar to the one for reviews: http://bit.ly/cvIzBR) if needed. Otherwise, I will remove the 'more' link from the contributions page.

> What's the status of this bug?  Any further design or are we done?

Except the 2 things above, everything's complete. I believe all the technical constraints on the design have been addressed, too. mccammos?
(In reply to comment #41)
> I can create a lightweight page for this (similar to the one for reviews:
> http://bit.ly/cvIzBR) if needed. Otherwise, I will remove the 'more' link from
> the contributions page.

IMO, it's not needed.
thanks chowse!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.