Re: [Tails-ux] Phrasing for the graphical interface startup …

Supprimer ce message

Répondre à ce message
Auteur: intrigeri
Date:  
À: Tails user experience & user interface design
Sujet: Re: [Tails-ux] Phrasing for the graphical interface startup failure (#14521)
Hi,

sajolida:
> Regarding the error message:


> - deb.li is case sensitive and that worries me a bit. There's also no
> relationship between 'NoX' and 'GDM'. What about instead
> https://deb.li/tailsgdm/?


> Or even https://tails.boum.org/gdm which is only 3 characters more but
> might be less intimidating or weird to our users by having a familiar
> domain name. And we'll have direct control over the redirection.


Sure. Done as part of implementing your proposal (commit 563afc2).

> Can we change the redirection afterwards with deb.li?


We cannot.

> In terms of strategy, in the current version we're asking people to
> report the error, whether or not the troubleshooting section was useful
> for them or the issue already known. I'm afraid of overloading our help
> with more reports that they won't be able to solve.


I see.

> If our goal is to lower the reports on help desk,


That's a long-term goal but the path towards it might go through
a transition stage during which help desk receives more reports.

One goal of my work is to make such reports useful and actionable, by
giving help desk the info I need them to forward me so I can improve
our known issues page: currently users who cannot start GNOME cannot
send a WhisperBack report, thus we have no reliable info about their
hardware, and then in turn we cannot document their findings, which is
very frustrating for everyone involved.

> we could only point to
> that web page and rely on it to be a better filter and ask the right
> people to report the right bugs (right now it's probably a catastrophe).


My goal is twofold:

1. help users find a workaround if we have documented one
2. gather information about what workaround works on which hardware,
so we can document it and make (1) work better for users
3. eventually users should need less and less individual help from us

For (2) we do need the user to tell us about what worked. I'll let you
handle this in whatever way you prefer. Please ensure we explicitly
ask the user to include in their bug report the full, exact error
displayed on the screen introduced by my branch (which is what my
previous implementation did). I'm concerned that if we don't tell the
user to save this info somewhere in the first place (my proposal did
that, yours does not), it'll be lost by the time we ask the user to
send it to us. Your call.

Cheers,
--
intrigeri