Re: Moving keyboard shortcuts list from help to app (was: Retiring app menus - planning for 3.32.0)

[Jeremy Bicha]

On Sun, Dec 9, 2018 at 11:16 AM Jeremy Bicha  wrote:
> I've been adding the Keyboard Shortcuts dialogs to several games as
> part of the 3.32 app menu updates and I've run into this duplication
> issue. I'd like to remove the Keyboard Shortcuts page from the help
> for these games.

Here's what I'm doing now. I am removing the link so that the Keyboard
Shortcuts help page doesn't show in the default help view. (It will
still end up showing if you search for it.)

I did this so that we don't lose translations in case we end up
deciding we do want to duplicate the help after all.

I am doing some 3.31.3 tarball releases now since I know it's easier
for some people to test from a tarball than from jhbuild or bst or
whatever. So I think this will help the discussion.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Moving keyboard shortcuts list from help to app (was: Retiring app menus - planning for 3.32.0)

[Petr Kovar]

On Sun, 9 Dec 2018 11:16:28 -0500
Jeremy Bicha  wrote:

> On Thu, Sep 20, 2018 at 7:22 AM Andre Klapper  wrote:
> > Personally I've always wondered how the "Keyboard Shortcuts" item
> > potentially duplicates dedicated pages in some user docs, such as
> > https://help.gnome.org/users/gnome-help/stable/shell-keyboard-shortcuts.html
> > https://gitlab.gnome.org/GNOME/evolution/blob/master/help/C/intro-keyboard-shortcuts.page
> >  [1]
> > https://help.gnome.org/users/five-or-more/stable/shortcuts.html
> > https://help.gnome.org/users/iagno/stable/shortcuts.html
> >
> > Maybe agreeing on a skeleton (strings to translate only once across
> > repos if you use software with a translation memory) / guidelines for a
> > shortcuts Mallard help page (and page name) is an option?
> 
> I've been adding the Keyboard Shortcuts dialogs to several games as
> part of the 3.32 app menu updates and I've run into this duplication
> issue. I'd like to remove the Keyboard Shortcuts page from the help
> for these games.
> 
> Especially with the GNOME 3.32 app menu design, it's really easy to
> find Keyboard Shortcuts now.

Good point. 

Technically, you can still reference the page from gnome-help in your app
docs, for example:

  

This might invalidate the Mallard syntax (yelp-check won't be
able to find the resource locally), but it won't break the build. The
reference will work locally only if gnome-user-docs is installed, and
it won't work online (no implementation for it in library-web.

Cheers,
pk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Moving keyboard shortcuts list from help to app (was: Retiring app menus - planning for 3.32.0)

[Jeremy Bicha]

On Thu, Sep 20, 2018 at 7:22 AM Andre Klapper  wrote:
> Personally I've always wondered how the "Keyboard Shortcuts" item
> potentially duplicates dedicated pages in some user docs, such as
> https://help.gnome.org/users/gnome-help/stable/shell-keyboard-shortcuts.html
> https://gitlab.gnome.org/GNOME/evolution/blob/master/help/C/intro-keyboard-shortcuts.page
>  [1]
> https://help.gnome.org/users/five-or-more/stable/shortcuts.html
> https://help.gnome.org/users/iagno/stable/shortcuts.html
>
> Maybe agreeing on a skeleton (strings to translate only once across
> repos if you use software with a translation memory) / guidelines for a
> shortcuts Mallard help page (and page name) is an option?

I've been adding the Keyboard Shortcuts dialogs to several games as
part of the 3.32 app menu updates and I've run into this duplication
issue. I'd like to remove the Keyboard Shortcuts page from the help
for these games.

Especially with the GNOME 3.32 app menu design, it's really easy to
find Keyboard Shortcuts now.

Thanks,
Jeremy Bicha
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Britt Yazel via desktop-devel-list]

Just my 2 cents

I think one of the bigger issues isn't necessarily the difference between
close and quit (though disambiguation would be great), it's instead that
since we retired showing appindicators there is now no way of visually
knowing if an app is still running or not. Granted, not all apps used
appindicators, but most apps that continued to stay open in the background
did have some sort of appindicators (chat apps like slack/discord etc).

My suggestion is *not* to bring back appindicators, but rather to make
better use of the dash to show all running applications, even the
background apps. Right now the dash does a good job showing running apps
that have a visible window, but background apps are invisible to the dash.
This would at the very least give a visual indicator of background running
applications, so in the case of quit/close ambiguity, it would only last as
long as until they see the dash and notice that the application still shows
running.

On Sep 28, 2018 7:33 AM, "Allan Day"  wrote:

Florian Müllner  wrote:
>
> With regard to dropping the 'quit' action, is there any guidance for
> background applications? That is, apps where closing all windows does
> *not* exit the application, but the explicit 'quit' action does.

Sorry for the slow reply - it's been a busy week.

This question is something that has been on my mind too. Having an
explicit way to stop an app from running in the background is
interesting, but then I wonder how desirable it is to have an action
to completely quit just once. I also wonder how obvious the function
is. How does someone know that quit stops the app completely, whereas
close doesn't? And would we just show quit in the case that an app
runs in the background...?

Another issue about quit which has occurred to me is that we show it
in the dash context menus...


Allan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Allan Day  wrote:
...
> > With regard to dropping the 'quit' action, is there any guidance for
> > background applications? That is, apps where closing all windows does
> > *not* exit the application, but the explicit 'quit' action does.
...

GIven that this is only relevant to apps that run in the background, I
don't think it makes sense to show it as a standard menu item. Third
party apps can provide their own Quit item if they want to, since I
know there's some different behaviours out there for that.

In general I think I'd probably go for no Quit item in GNOME apps that
run in the background, mostly because I think it's cleaner and easier
to understand if you separate the running state from whether a window
is open. For example, a chat app can be online/offline as well as
open/closed.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Tristan Van Berkom via desktop-devel-list]

Been on vacation and amused with this thread...

On Fri, 2018-09-21 at 15:54 +0200, Bastien Nocera wrote:
> On Fri, 2018-09-21 at 14:26 +0100, Allan Day wrote:
> > > > On Fri, 21 Sep 2018 at 12:54,  wrote:
> > > 
> > > On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera 
> > > wrote:
> > > > It's faster to access for users, has terser explanations (no need
> > > > to
> > > > create sentences to describe actions) and it's usually better
> > > > updated
> > > > as it lives in the code, as opposed to being separate in the
> > > > docs.
> > > 
> > > It's also larger, well-designed, easier to read and use.
> > 
> > But what if the docs were similar...? This is a hypothetical future,
> > not what we have today.
> 
> Still takes you out of the application itself.

I would just like to add my 2 cents to this, and basically point out
that having a user manual is by no means an excuse to make primary
features non discoverable in the UI proper.

I consider keyboard shortcuts for a video player to definitely be a
primary feature (at the very least pause, play, fullscreen, next scene,
are things you don't want the user to have to bother with clicking
around on a regular basis).

User manuals are great for the few people who like to read them and get
the hang of the app, or for a fairly complicated app, but if your user
is reaching all the way to the manual because they are unable to figure
out how to perform a basic function, then the user is already
frustrated and the application UI has already failed.

When you buy a DVD player, a TV, a game console, a power drill; you
plug it in, look at the buttons, and expect it to just work. I think
people expect (and deserve) the same out of the basic apps that people
use on a day to day basis.

Cheers,
-Tristan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Bastien Nocera]

On Fri, 2018-09-28 at 16:53 +0100, Alberto Ruiz wrote:
> 
> 
> 2018-09-28 15:32 GMT+01:00 Allan Day :
> > Florian Müllner  wrote:
> > >
> > > With regard to dropping the 'quit' action, is there any guidance
> > for
> > > background applications? That is, apps where closing all windows
> > does
> > > *not* exit the application, but the explicit 'quit' action does.
> > 
> 
> FWIW, the app menu "Quit" does not quit Telegam, so this is worth
> exploring though a bit orthogonal to the question of removing the
> menu.

Probably because it doesn't actually have an app menu, so gnome-shell
adds one with a single entry, which would do the same thing as closing
(all of?) the app's windows.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Alberto Ruiz]

2018-09-28 15:32 GMT+01:00 Allan Day :

> Florian Müllner  wrote:
> >
> > With regard to dropping the 'quit' action, is there any guidance for
> > background applications? That is, apps where closing all windows does
> > *not* exit the application, but the explicit 'quit' action does.
>

FWIW, the app menu "Quit" does not quit Telegam, so this is worth exploring
though a bit orthogonal to the question of removing the menu.


>
> Sorry for the slow reply - it's been a busy week.
>
> This question is something that has been on my mind too. Having an
> explicit way to stop an app from running in the background is
> interesting, but then I wonder how desirable it is to have an action
> to completely quit just once. I also wonder how obvious the function
> is. How does someone know that quit stops the app completely, whereas
> close doesn't? And would we just show quit in the case that an app
> runs in the background...?
>
> Another issue about quit which has occurred to me is that we show it
> in the dash context menus...
>
> Allan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>



-- 
Cheers,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Florian Müllner  wrote:
>
> With regard to dropping the 'quit' action, is there any guidance for
> background applications? That is, apps where closing all windows does
> *not* exit the application, but the explicit 'quit' action does.

Sorry for the slow reply - it's been a busy week.

This question is something that has been on my mind too. Having an
explicit way to stop an app from running in the background is
interesting, but then I wonder how desirable it is to have an action
to completely quit just once. I also wonder how obvious the function
is. How does someone know that quit stops the app completely, whereas
close doesn't? And would we just show quit in the case that an app
runs in the background...?

Another issue about quit which has occurred to me is that we show it
in the dash context menus...

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Alexandre Franke]

On Fri, Sep 21, 2018 at 9:47 PM Bastien Nocera  wrote:
> On Fri, 2018-09-21 at 21:08 +0200, Tomasz Torcz wrote:
> 
> >   Going extra mile to “find” shortcut is never gonna fly.  Years ago,
> > we
> > had a perfect solution for discovering shortcuts  – relevant letters
> > were underlined in the menus.  In some cases underlining appeared
> > only
> > after Alt was pressed, which was less discoverable, but still many
> > times more easy to find than shortcuts popup easter egg.
> >   Please bring back underlined menu items.
>
> Those are not keyboard shortcuts, they're mnemonics, used for
> navigating menus using the keyboard, not launching keyboard shortcuts
> without opening the menu.
>
> Feel free to start a new discussion about those, but they're really not
> the topic.

And also they are actually not gone, so there is no discussion to even
have. Open Nautilus, press F10 for the menu to open, press Alt,
mnemonics are underlined as expected.

-- 
Alexandre Franke
GNOME Hacker
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[mcatanzaro]

On Fri, Sep 21, 2018 at 2:47 PM, Bastien Nocera  
wrote:

Those are not keyboard shortcuts, they're mnemonics, used for
navigating menus using the keyboard, not launching keyboard shortcuts
without opening the menu.

Feel free to start a new discussion about those, but they're really 
not

the topic.


And we still have them (you have to press Alt).

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Bastien Nocera]

On Fri, 2018-09-21 at 21:08 +0200, Tomasz Torcz wrote:
> 

>   Going extra mile to “find” shortcut is never gonna fly.  Years ago,
> we
> had a perfect solution for discovering shortcuts  – relevant letters
> were underlined in the menus.  In some cases underlining appeared
> only
> after Alt was pressed, which was less discoverable, but still many
> times more easy to find than shortcuts popup easter egg.
>   Please bring back underlined menu items.

Those are not keyboard shortcuts, they're mnemonics, used for
navigating menus using the keyboard, not launching keyboard shortcuts
without opening the menu.

Feel free to start a new discussion about those, but they're really not
the topic.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Christian Hergert]

On 09/21/2018 12:08 PM, Tomasz Torcz wrote:
>   Going extra mile to “find” shortcut is never gonna fly.  Years ago, we
> had a perfect solution for discovering shortcuts  – relevant letters
> were underlined in the menus.  In some cases underlining appeared only
> after Alt was pressed, which was less discoverable, but still many
> times more easy to find than shortcuts popup easter egg.

Not all shortcut gestures correlate to a menu item, so that increases
the number of places users would have to look to locate them.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Shaun McCance]

On Fri, 2018-09-21 at 11:59 -0700, Christian Hergert wrote:
> On 09/21/2018 11:43 AM, Shaun McCance wrote:
> > Can you elaborate on this? One of the goals of Mallard is to allow
> > plugin docs to integrate into the main app docs. Is there something
> > we
> > could be doing better?
> 
> Advertise the feature? :)
> 
> Does it work when they are installed into different directories like
> ~/.local/share/$app/plugins vs /usr for the app?

The help would have to be in ~/.local/share/help/$lang/$app, mirroring
the layout in /usr/share/help, but you can indeed add pages under your
home directory.

And it's only for adding pages, not for adding content to an existing
page. So while a plugin can add lots of pages about how to use it, and
have those pages appear in the docs navigation, it couldn't add content
to a single "Keyboard Shortcuts" page.

(There are Mallard features in the pipeline that could allow adding
content to existing pages, but they're low priority at the moment.)

(Also, I have yet to sit down and figure out how plugins and plugin
docs play out in the world of Flatpak. So there's that.)

> I'm still not in favor of users having to open help and scan for
> shortcuts when we have a very simple way to find what you're looking
> for
> via the search window (and discover new things you didn't know
> about).
> 
> But I'm biased, given that I wrote it.
> 
> I'm also skeptical that users will think to open help to find
> shortcuts
> when the dominant platform (web) has gone with the shortcuts overlay
> route (albeit their only option).

I actually like the in-app shortcuts reference. The more guidance we
can provide in-app, the better. I do think we can explore better ways
for users to be able to get to the docs when needed, but that's another
conversation.

I just wanted to see if Mallard is falling down on one of its key
features. Thanks for the feedback.

--
Shaun

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Tomasz Torcz]

On Fri, Sep 21, 2018 at 11:59:54AM -0700, Christian Hergert wrote:
> On 09/21/2018 11:43 AM, Shaun McCance wrote:
> > Can you elaborate on this? One of the goals of Mallard is to allow
> > plugin docs to integrate into the main app docs. Is there something we
> > could be doing better?
> 
> Advertise the feature? :)
> 
> Does it work when they are installed into different directories like
> ~/.local/share/$app/plugins vs /usr for the app?
> 
> I'm still not in favor of users having to open help and scan for
> shortcuts when we have a very simple way to find what you're looking for
> via the search window (and discover new things you didn't know about).
> 
> But I'm biased, given that I wrote it.
> 
> I'm also skeptical that users will think to open help to find shortcuts
> when the dominant platform (web) has gone with the shortcuts overlay
> route (albeit their only option).

  Going extra mile to “find” shortcut is never gonna fly.  Years ago, we
had a perfect solution for discovering shortcuts  – relevant letters
were underlined in the menus.  In some cases underlining appeared only
after Alt was pressed, which was less discoverable, but still many
times more easy to find than shortcuts popup easter egg.
  Please bring back underlined menu items.
 

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Christian Hergert]

On 09/21/2018 11:43 AM, Shaun McCance wrote:
> Can you elaborate on this? One of the goals of Mallard is to allow
> plugin docs to integrate into the main app docs. Is there something we
> could be doing better?

Advertise the feature? :)

Does it work when they are installed into different directories like
~/.local/share/$app/plugins vs /usr for the app?

I'm still not in favor of users having to open help and scan for
shortcuts when we have a very simple way to find what you're looking for
via the search window (and discover new things you didn't know about).

But I'm biased, given that I wrote it.

I'm also skeptical that users will think to open help to find shortcuts
when the dominant platform (web) has gone with the shortcuts overlay
route (albeit their only option).

-- Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Shaun McCance]

On Fri, 2018-09-21 at 10:36 -0700, Christian Hergert wrote:
> On 09/21/2018 04:24 AM, Allan Day wrote:
> > This would reduce
> > the number of menu items, allows cross-linking, and so on.
> 
> This doesn't work well for situations where plugins are in play
> because
> those don't integrate cleanly into the documentation. However, the
> keyboard shortcuts window can handle this relatively okay (albeit
> more
> complex than it should be).
> 
> And we have a lot of apps that have plugins.

Can you elaborate on this? One of the goals of Mallard is to allow
plugin docs to integrate into the main app docs. Is there something we
could be doing better?

Thanks,
Shaun

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Florian Müllner]

With regard to dropping the 'quit' action, is there any guidance for
background applications? That is, apps where closing all windows does
*not* exit the application, but the explicit 'quit' action does.

Cheers,
Florian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Florian Müllner]

On Fri, Sep 21, 2018 at 4:00 PM Bastien Nocera  wrote:
>
> On Fri, 2018-09-21 at 12:24 +0100, Allan Day wrote:
> > To be clear, I'm still thinking this through but, if you had a page
> > in
> > the user docs which was a simple table of keyboard shortcuts, which
> > was one click away in the user docs, there wouldn't be all that much
> > to separate it from the keyboard shortcuts windows.
>
> The docs would still show up in a separate application, and you'd be
> mixing writing styles. The user docs are usually more verbose, and the
> keyboard shortcuts are terse.

Also: If a shortcut is changed or added, the shortcuts window will
reflect that for
all users (albeit some bits show up in English until translations catch up). The
user documentation will be outdated until translators pick up the changes.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Christian Hergert]

On 09/21/2018 04:24 AM, Allan Day wrote:
> This would reduce
> the number of menu items, allows cross-linking, and so on.

This doesn't work well for situations where plugins are in play because
those don't integrate cleanly into the documentation. However, the
keyboard shortcuts window can handle this relatively okay (albeit more
complex than it should be).

And we have a lot of apps that have plugins.

-- Christian

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Bastien Nocera]

On Fri, 2018-09-21 at 12:24 +0100, Allan Day wrote:
> Bastien Nocera  wrote:
> ...
> > > Putting aside the issue of outdated user docs,
> > 
> > Well, it's a pretty big factor here.
> 
> Can't we just remove out of date user docs?

We certainly can, though that means there's no place to put the
keyboard shortcuts then ;)

> I realise that my line of reasoning is somewhat hypothetical here,
> but
> if there are issues with the user docs, we ought to fix them.
> 
> > >  do you experience any
> > > advantages having keyboard shortcuts in the shortcuts window, as
> > > opposed to the help?
> > 
> > It's faster to access for users, has terser explanations (no need
> > to
> > create sentences to describe actions) and
> 
> To be clear, I'm still thinking this through but, if you had a page
> in
> the user docs which was a simple table of keyboard shortcuts, which
> was one click away in the user docs, there wouldn't be all that much
> to separate it from the keyboard shortcuts windows.

The docs would still show up in a separate application, and you'd be
mixing writing styles. The user docs are usually more verbose, and the
keyboard shortcuts are terse.

Their terseness and searchability make them pretty good to discover
application features, compared to menu item searching for example.

>  And the advantage
> would be more integrated user documentation (I think that's
> essentially what the keyboard shortcut windows are). This would
> reduce
> the number of menu items, allows cross-linking, and so on.

Obviously, cross-linking would be useful, but I wonder how much there
is to gain having "Pressing the Play button will start playback" in the
docs.

I guess whether saving space is useful might depend on the
application's menus, I don't think that's a major problem for Videos,
maybe it's a different problem for apps like Web.

> > it's usually better updated
> > as it lives in the code, as opposed to being separate in the docs.
> 
> I can see how that's an advantage, but it also feels like a bit of a
> workaround, if we assume that we need up-to-date user docs one way or
> another...

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Bastien Nocera]

On Fri, 2018-09-21 at 14:26 +0100, Allan Day wrote:
> On Fri, 21 Sep 2018 at 12:54,  wrote:
> > 
> > On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera 
> > wrote:
> > > It's faster to access for users, has terser explanations (no need
> > > to
> > > create sentences to describe actions) and it's usually better
> > > updated
> > > as it lives in the code, as opposed to being separate in the
> > > docs.
> > 
> > It's also larger, well-designed, easier to read and use.
> 
> But what if the docs were similar...? This is a hypothetical future,
> not what we have today.

Still takes you out of the application itself.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

On Fri, 21 Sep 2018 at 12:54,  wrote:
>
> On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera 
> wrote:
> > It's faster to access for users, has terser explanations (no need to
> > create sentences to describe actions) and it's usually better updated
> > as it lives in the code, as opposed to being separate in the docs.
>
> It's also larger, well-designed, easier to read and use.

But what if the docs were similar...? This is a hypothetical future,
not what we have today.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[mcatanzaro]

On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera  
wrote:

It's faster to access for users, has terser explanations (no need to
create sentences to describe actions) and it's usually better updated
as it lives in the code, as opposed to being separate in the docs.


It's also larger, well-designed, easier to read and use.

Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day via desktop-devel-list]

Christian Hergert  wrote:
...
> > "There is no need for the Quit menu item and the recommendation is to
> remove it from all locations."
>
>  - What about applications that have multiple windows? It seems
> cumbersome to track down all your windows to ensure the application exits.

My answer right now is, well, users will have to close each window
individually, and that's probably a good thing. For one thing, it will
help to prevent accidental closure.

However, if there are specific cases where closing multiple windows at
once is important, that would be good to explore.

>  - If we were to do this in conjunction with systemd/cgroup2 CPU
> priority for foreground/background applications (like Android) I'd feel
> a lot better about it.
>
>  - I'm also concerned due to how many applications we've had over the
> years that get themselves into various types of spin loops. Do we want
> to rely on the compositor/shell for force quit?
>
>  - Perhaps this also should be attempted in conjunction with
> save/restore session APIs like the old days of SMClient so that we are
> more free to kill/freeze background applications on constrained devices?

These all sound like good things to investigate, and if this change
pushes us to do that, then all the better!

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Alexandre Franke]

On Fri, Sep 21, 2018 at 1:25 PM Allan Day  wrote:
> Bastien Nocera  wrote:
> > It's faster to access for users, has terser explanations (no need to
> > create sentences to describe actions) and
>
> To be clear, I'm still thinking this through but, if you had a page in
> the user docs which was a simple table of keyboard shortcuts, which
> was one click away in the user docs, there wouldn't be all that much
> to separate it from the keyboard shortcuts windows. And the advantage
> would be more integrated user documentation (I think that's
> essentially what the keyboard shortcut windows are). This would reduce
> the number of menu items, allows cross-linking, and so on.

The integrated search that filters relevant shortcuts is probably not
something that could be achieved easily in docs. Try it in totem: open
the shortcut window (hit ctrl+shift+?) and start typing "forward".
That kind of workflow is selling it for me.

-- 
Alexandre Franke
GNOME Hacker
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Bastien Nocera  wrote:
...
> > Putting aside the issue of outdated user docs,
>
> Well, it's a pretty big factor here.

Can't we just remove out of date user docs?

I realise that my line of reasoning is somewhat hypothetical here, but
if there are issues with the user docs, we ought to fix them.

> >  do you experience any
> > advantages having keyboard shortcuts in the shortcuts window, as
> > opposed to the help?
>
> It's faster to access for users, has terser explanations (no need to
> create sentences to describe actions) and

To be clear, I'm still thinking this through but, if you had a page in
the user docs which was a simple table of keyboard shortcuts, which
was one click away in the user docs, there wouldn't be all that much
to separate it from the keyboard shortcuts windows. And the advantage
would be more integrated user documentation (I think that's
essentially what the keyboard shortcut windows are). This would reduce
the number of menu items, allows cross-linking, and so on.

> it's usually better updated
> as it lives in the code, as opposed to being separate in the docs.

I can see how that's an advantage, but it also feels like a bit of a
workaround, if we assume that we need up-to-date user docs one way or
another...

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Nathan Graule via desktop-devel-list]

My main hesitation to having the app level menu items (preferences,
keyboard shortcuts, help, about) always available is that it could
make the menus unpredictable - there is a clarity in having a definite
place for those items. Also, given that many of them are infrequently
used, requiring the user to navigate up a level to access them doesn't
seem all that terrible.
A visual separation would indicate the different meanings of the menus. 
Icons denoting primary/secondary menus would also work as the user 
would implicitely learn which icon-button hosts which menu. But to me 
the best solution is to place them in a consistent way. Right now when 
disabling the top bar application menu, it finds itself on an extreme 
end of the window bar (or header bar, if the app supports it). This 
properly indicate to the user, even though the menu button icon is that 
of the app itself, that there's an application menu there. With a 
visual separator the primary menu could be separated from the secondary 
menu.


We could definitely maintain clarity and consistency and still allow 
both menus shown regardless of application state.

Nathan Graule


Le ven. 21 sept. 2018 à 12:33, Allan Day  a écrit :

Nathan Graule  wrote:
...
 I feel like having the primary menu hidden in an in-window 
navigation app would be a regression from current, as a primary menu 
may apply anywhere, and having the user modify (and especially here, 
undo) application state in order to access a particular menu item 
(that, again, by its definition can apply anywhere in the app) would 
lead to end-user frustration.


That's a fair point. For example, it's certainly possible that someone
would want to change a setting in Videos while they're playing a
video.

My main hesitation to having the app level menu items (preferences,
keyboard shortcuts, help, about) always available is that it could
make the menus unpredictable - there is a clarity in having a definite
place for those items. Also, given that many of them are infrequently
used, requiring the user to navigate up a level to access them doesn't
seem all that terrible.

That said, what we could do - and this has been discussed a little -
is expose some of those items in the secondary menus, as necessary. In
the video playback example, you could have a "Video Playback Help" in
the secondary menu, for instance.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Bastien Nocera]

On Fri, 2018-09-21 at 11:05 +0100, Allan Day wrote:
> Bastien Nocera  wrote:
> ...
> > ... The keyboard shortcuts dialogue in Videos is invaluable.
> > 
> > Its contents used to be in the README file, which users wouldn't
> > see,
> > the user documentation still shows the old interface (from 4 years
> > ago), and I'd rather not rely on user docs if I can help it.
> 
> Putting aside the issue of outdated user docs,

Well, it's a pretty big factor here.

>  do you experience any
> advantages having keyboard shortcuts in the shortcuts window, as
> opposed to the help?

It's faster to access for users, has terser explanations (no need to
create sentences to describe actions) and it's usually better updated
as it lives in the code, as opposed to being separate in the docs.

> I can see the advantage for a large and complex app, where you might
> want to regularly check shortcuts, as a quick reference. In the case
> of a simple app, it's less clear to me what the advantage is over
> having shortcuts in the docs.

Having a quick access to searchable shortcuts is a good way to learn
those shortcuts little by little, or get to know about specific
shortcuts without taking you out of your task. Opening a separate, more
verbose, documentation breaks that immersion.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Nathan Graule  wrote:
...
> I feel like having the primary menu hidden in an in-window navigation app 
> would be a regression from current, as a primary menu may apply anywhere, and 
> having the user modify (and especially here, undo) application state in order 
> to access a particular menu item (that, again, by its definition can apply 
> anywhere in the app) would lead to end-user frustration.

That's a fair point. For example, it's certainly possible that someone
would want to change a setting in Videos while they're playing a
video.

My main hesitation to having the app level menu items (preferences,
keyboard shortcuts, help, about) always available is that it could
make the menus unpredictable - there is a clarity in having a definite
place for those items. Also, given that many of them are infrequently
used, requiring the user to navigate up a level to access them doesn't
seem all that terrible.

That said, what we could do - and this has been discussed a little -
is expose some of those items in the secondary menus, as necessary. In
the video playback example, you could have a "Video Playback Help" in
the secondary menu, for instance.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Bastien Nocera  wrote:
...
> ... The keyboard shortcuts dialogue in Videos is invaluable.
>
> Its contents used to be in the README file, which users wouldn't see,
> the user documentation still shows the old interface (from 4 years
> ago), and I'd rather not rely on user docs if I can help it.

Putting aside the issue of outdated user docs, do you experience any
advantages having keyboard shortcuts in the shortcuts window, as
opposed to the help?

I can see the advantage for a large and complex app, where you might
want to regularly check shortcuts, as a quick reference. In the case
of a simple app, it's less clear to me what the advantage is over
having shortcuts in the docs.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Christian Hergert]

On 09/20/2018 02:19 AM, Allan Day wrote:
> I've written some updated guidelines for the initiative
> ,
> and I'd appreciate it if people could check them over.

>From the link:

> "There is no need for the Quit menu item and the recommendation is to
remove it from all locations."

 - What about applications that have multiple windows? It seems
cumbersome to track down all your windows to ensure the application exits.

 - If we were to do this in conjunction with systemd/cgroup2 CPU
priority for foreground/background applications (like Android) I'd feel
a lot better about it.

 - I'm also concerned due to how many applications we've had over the
years that get themselves into various types of spin loops. Do we want
to rely on the compositor/shell for force quit?

 - Perhaps this also should be attempted in conjunction with
save/restore session APIs like the old days of SMClient so that we are
more free to kill/freeze background applications on constrained devices?

-- Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Nathan Graule via desktop-devel-list]

I feel like having the primary menu hidden in an in-window navigation 
app would be a regression from current, as a primary menu may apply 
anywhere, and having the user modify (and especially here, undo) 
application state in order to access a particular menu item (that, 
again, by its definition can apply anywhere in the app) would lead to 
end-user frustration.


The "apps with sidebar" example is IMHO best as both menus are 
displayed and have a position that makes sense, and most importantly, 
both are visible at all times.
3.28 with app menu displayed in the application top bar best describes 
what to be would be a good behavior for primary menus.

Nathan Graule


Le jeu. 20 sept. 2018 à 11:19, Allan Day  a écrit :

Hi all,

As previously discussed, we're planning to retire app menus this 
development cycle. The aim is to remove all application menus by 
3.32.0.


I've written some updated guidelines for the initiative, and I'd 
appreciate it if people could check them over.


We're also hoping to sneak in a couple of other UI changes at the 
same time. I wanted to flag these here, in case there are any 
objections. They are:
Grouping the Preferences menu item with the other "app" menu items 
(Keyboard Shortcuts, Help, About).
Changing the name of the about menu item from "About" to "About 
".
If this all seems OK, I'll announce the initiative more widely and 
start filing issues against the affected applications.


Thanks,

Allan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Bastien Nocera]

On Thu, 2018-09-20 at 15:07 +0200, Alexandre Franke wrote:
> Hi,
> 
> On Thu, Sep 20, 2018 at 12:52 PM Allan Day  wrote:
> > To be honest, I'm not sure how successful the keyboard shortcut
> > windows
> > have been and I suspect that they're not being used a great deal.
> 
> What are you basing this on? Did you get specific feedback about
> that,
> or was there a user testing session that showed this? I have the
> exact
> opposite feeling, solely based on my own experience: I do use the
> shortcut window often and I find it very valuable.

I also think that the least amount of user documentation is necessary,
the better. The keyboard shortcuts dialogue in Videos is invaluable. 

Its contents used to be in the README file, which users wouldn't see,
the user documentation still shows the old interface (from 4 years
ago), and I'd rather not rely on user docs if I can help it.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Alexandre Franke  wrote:

> Allan Day  wrote:
> > To be honest, I'm not sure how successful the keyboard shortcut windows
> > have been and I suspect that they're not being used a great deal.
>
> What are you basing this on?


Anecdotal evidence, primarily - my own usage, talking to other designers
and developers. It would certainly be good to have more reliable data.


> I have the exact
> opposite feeling, solely based on my own experience: I do use the
> shortcut window often and I find it very valuable.
>

That's interesting! Let's talk some more about it.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Alexandre Franke]

Hi,

On Thu, Sep 20, 2018 at 12:52 PM Allan Day  wrote:
> To be honest, I'm not sure how successful the keyboard shortcut windows
> have been and I suspect that they're not being used a great deal.

What are you basing this on? Did you get specific feedback about that,
or was there a user testing session that showed this? I have the exact
opposite feeling, solely based on my own experience: I do use the
shortcut window often and I find it very valuable.

Cheers,

-- 
Alexandre Franke
GNOME Hacker
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day via desktop-devel-list]

Andre Klapper  wrote:
...

> Personally I've always wondered how the "Keyboard Shortcuts" item
> potentially duplicates dedicated pages in some user docs
>

It would certainly be good to have a coordinated strategy. One obvious
question is whether to list shortcuts in a separate section or sprinkle
them throughout the docs (or both). The other question is the issue that
Adrien brought up - where to document gestures (could be touchpad or
touchscreen).

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Andre Klapper]

[on documenting keyboard shortcuts]

On Thu, 2018-09-20 at 11:51 +0100, Allan Day wrote:
> Adrien Plazas  wrote:
> ...
> > What about updating the name ofthe "Keyboard Shortcuts" entry?
> 
> To be honest, I'm not sure how successful the keyboard shortcut
> windows have been and I suspect that they're not being used a great
> deal.
[...]
> I realise that you probably have an interest from a Games
> perspective, but I think it would be fine to special-case that and
> come up with a bespoke solution.

Personally I've always wondered how the "Keyboard Shortcuts" item
potentially duplicates dedicated pages in some user docs, such as
https://help.gnome.org/users/gnome-help/stable/shell-keyboard-shortcuts.html
https://gitlab.gnome.org/GNOME/evolution/blob/master/help/C/intro-keyboard-shortcuts.page
 [1]
https://help.gnome.org/users/five-or-more/stable/shortcuts.html
https://help.gnome.org/users/iagno/stable/shortcuts.html

Maybe agreeing on a skeleton (strings to translate only once across
repos if you use software with a translation memory) / guidelines for a
shortcuts Mallard help page (and page name) is an option?

andre

[1] Can't link to a rendered version due to
https://bugzilla.gnome.org/show_bug.cgi?id=785522
-- 
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Allan Day]

Adrien Plazas  wrote:
...
> What about updating the name ofthe "Keyboard Shortcuts" entry? The
windows they trigger also contain gestures and in Games they also contain
gamepad controls, making them being about way more than keyboards.
>
> "Shortcuts" is a simple replacement but any other idea is welcome.

To be honest, I'm not sure how successful the keyboard shortcut windows
have been and I suspect that they're not being used a great deal.

The main problems as I see them:

   - They're a special place you have to go to with the specific intention
   of learning shortcuts. This isn't something that a lot of people do,
   especially for simple apps.
   - They aren't playing the role of a quick reference, since we haven't
   successfully advertised how to quickly open them (ironically, this is
   through a shortcut).
   - They're often available in simple apps where keyboard shortcuts aren't
   that interesting. This negatively reinforces how people perceive their
   usefulness.

One option would be to reframe the shortcut windows as purely a quick
reference for keyboard shortcuts. As part of this, we'd need to publicise
the shortcut for raising the shortcuts window (possibly by exposing it in
the menu).

I realise that you probably have an interest from a Games perspective, but
I think it would be fine to special-case that and come up with a bespoke
solution.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Retiring app menus - planning for 3.32.0

[Adrien Plazas via desktop-devel-list]

What about updating the name ofthe "Keyboard Shortcuts" entry? The 
windows they trigger also contain gestures and in Games they also 
contain gamepad controls, making them being about way more than 
keyboards.


"Shortcuts" is a simple replacement but any other idea is welcome.

Cheers,
Adrien Plazas

Le jeu. 20 sept. 2018 à 11:19, Allan Day  a écrit :

Hi all,

As previously discussed, we're planning to retire app menus this 
development cycle. The aim is to remove all application menus by 
3.32.0.


I've written some updated guidelines for the initiative, and I'd 
appreciate it if people could check them over.


We're also hoping to sneak in a couple of other UI changes at the 
same time. I wanted to flag these here, in case there are any 
objections. They are:
Grouping the Preferences menu item with the other "app" menu items 
(Keyboard Shortcuts, Help, About).
Changing the name of the about menu item from "About" to "About 
".
If this all seems OK, I'll announce the initiative more widely and 
start filing issues against the affected applications.


Thanks,

Allan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Retiring app menus - planning for 3.32.0

[Allan Day]

Hi all,

As previously discussed, we're planning to retire app menus this
development cycle. The aim is to remove all application menus by 3.32.0.

I've written some updated guidelines for the initiative
, and
I'd appreciate it if people could check them over.

We're also hoping to sneak in a couple of other UI changes at the same
time. I wanted to flag these here, in case there are any objections. They
are:

   1. Grouping the Preferences menu item with the other "app" menu items
   (Keyboard Shortcuts, Help, About).
   2. Changing the name of the about menu item from "About" to "About
   ".

If this all seems OK, I'll announce the initiative more widely and start
filing issues against the affected applications.

Thanks,

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list