sajolida:
> segfault:
>> I don't like the idea of removing favorites which we had for a very
>> long time. It forces users to change their workflow, and there is no
>> easy way for them to change it back, because we don't have a
>> persistence preset for the favorite apps. This seems like bad UX.
>>
>> IMO, if we want to remove apps from the favorites list, we should also
>> support to customize it.
>
> I kindly disagree :)
>
> For me, the Favorites submenu is most of all a discovery tool for new
> users and a convenient shortcut for returning users. So if an
> application in there is only seldomly used by our user base at large,
> it's a benefit for everybody else to remove it and simplify the list.
>
> Unfortunately, we don't have data about which apps are more used so we
> can't really make good decisions based on data here. We could use our
> personas but I'm afraid to run into unsolvable debates regarding whether
> their would use Pidgin or Thunderbird for example.
>
> I also don't want to block improving this list until we have a way of
> customizing it because I think that it will be technically complicated,
> controversial (intrigeri really wants to get rid of this whole
> Applications menu), and way less important than other things that we
> want to persist (starting with Keyboard and Language). In other words,
> I don't think that supporting customization of this menu should be a
> priority for the near future.
>
> But I'm fine with not removing anything for the time being if it makes
> it easier to move this discussion forward.
>
> The list could become:
>
> - Tor Browser
> - Configure persistent volume (new)
> - Tails documentation (new)
> - Report an Error (new)
> - Tails Installer (new)
> - Thunderbird
> - KeePassXC
> - Pidgin Internet Messenger
> - Terminal
> - Files
>
> Total 10, which still fits without displaying a scroll bar.
Ok, I'm fine with that.
> Michael Gerstacker via Tails-ux:
> [...]
>> Rationale:
>> I never really understood why exactly these two icons are on the
>> desktop too and getting rid of them was one of my thoughts too:)
>
> :)))
I assume the reason for having the Documentation and Whisperback
shortcuts on the desktop is to ensure that new users are aware that
those essential features exist, and to make them very easily
discoverable and accessible. They are different from the other
applications in that they can (hopefully) help the user when they are
having problems with Tails.
> [...]
>
> Teqleez Motley:
>> If no customization is possible, IMO this menu should be renamed to "featured" or the like.
>
> Why not.
>
> @segfault: How hard would it be to change the title of this submenu?
I'm not sure where the string in the menu title comes from, but
consistently changing the name "Favorites" whenever it's used to refer
to this list of applications would at least require a GNOME Shell
extension, which is not worth it IMO.
>> 2. Menu filter and descriptive menu item names:
>> Both for visibility, for newcomers and efficiency (filtering), I think the menu should have a search filter at the top, which would filter among the menu items and even among all the possible software file names in "bin" etc. The "match" should be against both sotware file names but also against any parts of the menu titles.
>
> I'm afraid that this new feature would be quite some work to implement,
> so I'd rather not consider it for now.
Agreed. That's what the activities overview is for - which we should
make more discoverable IMO.
>> For example, the "KeepassXC" could be named "KeepassXC password manager", both to make it more obvious for newcomers, but also to make a filter on "password" find it. Likewise, "Thunderbird" could be renamed to "Thunderbird email client", and GtkHash to "GtkHash checksum tool"
Note that most applications already include a list of keywords by which
they can be found. Try typing "password" in the search in the activities
overview and you will find KeePassXC.
> I like this idea. Some apps already do so "Pidgin Internet Messenger"
> but not all of them. I wonder whether it's worth reporting bugs upstream
> about this
Most applications already add an attribute "GenericName" to their
.desktop file, which is a description of the type of application. So
from the application's perspective, it already provides what is needed,
and GNOME *could* display that information next to the name. But I don't
expect them to change that behavior.
> or whether diverging from the Debian package would be costly
> in terms of maintenance.
>
> @segfault: Any clue on this?
That should be possible by patching the respective .desktop files in
/usr/share/applications/. I don't expect much maintenance cost, because
I don't think applications change their title or the name of the
.desktop file often.
> Here is a list of the apps I could spot but don't have transparent names:
>
> - Dasher
> → Dasher Text Input System
>
> - Brasero
> → Brasero CD/DVD Burner
>
> - Sound Juicer
> → Sound Juicer CD Ripper
>
> - Audacity
> → Audacity Sound Editor
>
> - OnionShare
> → OnionShare File Sharing
>
> - Thunderbird
> → Thunderbird Email Client
>
> - KeePassXC
> → KeePassXC Password Manager
>
> - Inkscape
> → Inkscape Image Editor
>
> - GtkHash
> → GtkHash Checksum Calculator
I like those proposals!
Cheers
