Hey Mark, I'm happy to take this on though I won't have much bandwidth until November. If you have string suggestions ready I can take a look now and offer my 2 cents.

I'm going to mark this as won't fix: 1)UX focus is on string improvements on surfaces seen by most users - chrome://crashes isn't one of them; 2) it's not clear to me that the page is in bad shape or what a better state would me. If you feel strongly otherwise let's chat more.

The only problem I've had with strings on this page is that users, when asked for the "Server ID for the crash" very often give us the local crash ID GUID (which is worthless). It might be nice if we explicitly reiterated that the crash hadn't been uploaded or whatever.

The timestamps and confusing set of IDs are pretty unfriendly to non-power users.

The server IDs ending in long strings of zeroes are remarkably unfriendly and make it pretty difficult to transfer numbers around (copy-paste doesn’t always occur to people, or we get screen shots instead of something more usable and we’ve got to count zeroes on our end). We’d need to fix that on the server side.

Regarding #6.

I agree that it will be nice if we can support report IDs with arbitrary lengths (we can append the missing 0s on the server side).  We haven't implemented it yet, because it was not very easy and it didn't seem very important.

This is not very easy because:
 - There is a search field in the crash UI that accepts random strings.  There is a heuristic to check  whether the given string represents a valid crash report ID or not.
 - In addition, crash report can be loaded by http://crash/<report_id>, where we also try to recognize whether <report_id> represents a valid report ID.
 - When all report IDs have the same length it is easier to properly recognize report IDs.

Given that this is causing real problems (difficult to count the zeros when transferring number) we should probably try to resolve it.

For reference, the issue with the trailing zeroes in report IDs is tracked by http://crbug/583406

Re comment #4: Do chrome:// pages require UX design and review? Or if there's something we can change to make this more usable, can we just do it?

Unless they are linked to by UI (the way //help is), no UX review necessary. I'm happy to consult on it though.

Would it help to include a "Copy this ID" link that copies the full/correct ID to clipboard?

c#5 Could we change the page to show ONLY the server ID and not the crash ID, if the crash ID is "worthless"?

Here's a quick stab at putting the info into tabular format, as suggested in c#1, and making the strings a bit clearer: https://docs.google.com/spreadsheets/d/1hn0WvTdtSSBeo-CBauuVHH0e0W94N4CZcuVIBgl-ec0/edit#gid=0

The local ID is somewhat helpful to power users even when a report’s been uploaded, because it identifies the filename of the report on disk.

I like srahim's proposal in #11. Can an engineer familiar with this area please help us iterate into a proposal that satisfies all use cases? 

re #12: I suggest we put the server ID alone in the bold title string, and include the crash ID in the smaller text and rename it something like "local crash ID"?

I’d like to see a designed proposal of that. Un-uploaded crashes don’t have a server ID, so I don’t know how you’re planning on presenting them.

"Crash not yet uploaded"?

I don't have bandwidth to lead this, but if someone else starts I'm happy to provide some usability advice along the way.

keep in mind too that any strings shown would have to go through localization.  so that adds a little bit of friction to the process.

We are hoping to implement an externally visible Crash UI (probably in Q3-Q4 timeframe) that will show very limited data for a given report ID (e.g. the symbolized stack trace, source code, and a some white-listed fields).  This will need privacy and security approvals first so it is not clear whether it will happen.

If we build it, then we can provide links to the processed crash reports directly on chrome://crashes.  This should resolve some of the issues discussed here (e.g. copying and pasting of report IDs).

I've just run into this, as I asked a user for a crash ID and she replied (understandably) with the report ID: https://twitter.com/soylentqueen/status/869378948815355911

We've had similar confusion in the recent past regarding these. And I'm hoping we can make it easier for users trying to help us with crash reporting. 

Here's a UI proposal for the crashes page. It features the "server id" (now back to being called "crash id") very clearly.
The report ID's UI presence is much smaller.

How does this look to folks?

Deleted: Screen Shot 2017-05-30 at 10.53.24 AM.png 54.3 KB

	Screen Shot 2017-05-30 at 10.53.24 AM.png 54.3 KB View Download

Re #19: Maybe drop the words "Report ID" entirely, unless there's some reason that this needs to be there? Having multiple things named "ID" seems unnecessarily complicating.

What about hiding the report ID and timestamp of its upload entirely? Behind an expandable line like "More info"

Also, the crash ID is still harder to find since it's not at the start of new line.  Something like 
Crash:
Crash ID: 
>More info

both of those suggestions sgtm. 

Re-raising this issue. Users providing the *local* crash ID instead of the server crash ID is an extremely common issue for teams doing triage of user issues. Independent of any planned rework to this page, can we please remove or rename the local crash ID? Something like "Local basename" would be fine - literally any string that does not contain "crash ID". See  issue 852403  for one example but there are many others.

I'm not sure ivanpe@'s team owns the client side code for this? Honestly if the suggestion is to just rename the string as you say - I suggest just doing it and sending the CL to review (e.g. to mark@ who might have most opinions on it?).

Local basename lgtm, please submit the change.

yeah, i don't think ivanpe@ et al are responsible for client side UI like this

The externally visible Crash UI that we were hoping to implement won't happen, so we should just rename the strings to whatever makes the most sense so that we avoid the confusion between the *local* and the *server* report IDs.

I just looked at my Chrome about:crashes page and I don't see this issue anymore.  I only see the *server* report IDs, so maybe someone already fixed in Chrome.  Attached a screenshot.

Deleted: about_crashes.png 124 KB

	about_crashes.png 124 KB View Download

It might be a Mac-specific thing that it shows a local id?

I see:

"Uploaded Crash Report ID b3a2101106dbe9d8 (Local Crash ID: a7f93054-0bbe-4f95-8d5f-4267559a2f34)"

Maybe we could change the wording a bit? Instead of "Local Crash ID:", we could use "Local Context:" or something else that does not contain "ID".  This way, end users won't be confused which one is the ID.

I think Linux is broken. Displaying "Local Crash ID: Chrome" is of course totally useless for everyone involved.

(I'd guess it's probably Breakpad vs. Crashpad related? Not sure.)

Local context sgtm (upthread it was suggested "Local basename" but I like context better)

I'm happy to do this string change if nobody objects; this is a constant irritant in bug reports.

Sounds great! Over to you then. :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/069ebe2bea6dbde0e9c33cb8d6be8358f7d15da0

commit 069ebe2bea6dbde0e9c33cb8d6be8358f7d15da0
Author: Leonard Grey <lgrey@chromium.org>
Date: Thu Dec 20 21:51:44 2018

Rename Local Crash ID to Local Context in chrome://crashes

This causes confusion in bug reports, since the local ID isn't actionable for us.

Bug:  646455 
Change-Id: I342893cc1f42a5a6cc011d97d5b20fd278a925f0
Reviewed-on: https://chromium-review.googlesource.com/c/1387046
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#618341}
[modify] https://crrev.com/069ebe2bea6dbde0e9c33cb8d6be8358f7d15da0/components/crash_strings.grdp

Able to reproduce this issue on Windows 10, Mac OS 10.13.6 and Ubuntu 17.10 on the build without fix 73.0.3642.0 and the issue is fixed on the latest M-73 build 73.0.3647.0.

1. Launched Chrome and induced crash on browser
2. Navigated to chrome://crashes and can observe that 'Local Context' is displayed instead of 'Local Crash ID'.
Attached is the screen shot for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

Deleted: 646455-M73.PNG 49.8 KB

	646455-M73.PNG 49.8 KB View Download