GNOME Bugzilla – Bug 705585
The documentation don't mention the "New tab" button
Last modified: 2014-12-02 21:46:35 UTC
In the Epiphany's documentation (file browse-web.page, line 46), the advised way to open new tab is using the "gear menu". I believe this should be rewritten to take the "New tab" button into account.
I couldn't use the button in the user help instructions because it has no menu and no tooltips, so it cannot be described. (The same problem exists for the "gear" menu.) I will try to add tooltips for 3.12 and, if the patch is accepted, then I can update the help.
Ahem, that should say "no label and no tooltip".
(In reply to comment #1) > I couldn't use the button in the user help instructions because it has no menu > and no tooltips, so it cannot be described. (The same problem exists for the > "gear" menu.) I will try to add tooltips for 3.12 and, if the patch is > accepted, then I can update the help. This sounds like a more general problem that needs to be discussed with the design team!
(In reply to comment #3) > (In reply to comment #1) > > I couldn't use the button in the user help instructions because it has no menu > > and no tooltips, so it cannot be described. (The same problem exists for the > > "gear" menu.) I will try to add tooltips for 3.12 and, if the patch is > > accepted, then I can update the help. > > This sounds like a more general problem that needs to be discussed with the > design team! I have briefly spoken to the design team about this (in general) on IRC and the response indicated that the team had no interest in including tooltips in the designs. To be honest, this is also something that developers should pick up when implementing the designs. Unfortunately, there is no design mailing list, so I cannot give you a link to the discussion and the view may not be shared by the whole team as not all of it may have been on IRC or awake at the time. For now, when I come across a problem, I provide a patch. It is a bit difficult to generalise for the gear/menu button because it means different things in different applications.
(In reply to comment #1) > I couldn't use the button in the user help instructions because it has no menu > and no tooltips, so it cannot be described. Why it cannot be described? Can't a screenshot of the button be used to refer to it, for instance?
(In reply to comment #5) > (In reply to comment #1) > > I couldn't use the button in the user help instructions because it has no menu > > and no tooltips, so it cannot be described. > > Why it cannot be described? Can't a screenshot of the button be used to refer > to it, for instance? That fails the instant a user has a different theme or is blind. The best we can do right now is "that button in the top right of the screen which might be a gear, but could be something completely different depending on your theme", which is not particularly helpful and cannot be used inside a GUI sequence (menu->menuitem). <guiseq> are tags that we use to describe the UI in Mallard. They are most often used to describe interactions with menus and contain a number of GUI elements inside them (most commonly text from labels). As a quick fix, the next best thing that I have come up with is to add tooltips to the buttons (these help with accessibility all round), and to use the tooltip to help describe the button. I would like to see something added to yelp that would allow us to request icons from the theme, but someone would need to implement this.
There are shortcuts for both actions. F10 for the gear menu and Ctrl+T for new tab. That could help. As for the theme issues, the same are present for all existing screenshots.
(In reply to comment #7) > There are shortcuts for both actions. F10 for the gear menu and Ctrl+T for new > tab. That could help. Yes, I will add these to the keyboard-shortcuts.page when we write one and the tab page when I split it off from the browsing (as per our conversation at GUADEC). If you can think of any others, please let us know! > As for the theme issues, the same are present for all > existing screenshots. Which is why we don't use the screenshots to describe actions or steps :) If I remember correctly, there is currently one, traditional, screenshot of the main window in the introduction and one showing that the private browsing looks different from normal browsing (which needs to be improved, as you mentioned). Both pages are as useful without the screenshots, but users apparently appreciate some visual feedback occasionally and I can see how knowing what to expect when starting up an application is nice.
(In reply to comment #8) > Yes, I will add these to the keyboard-shortcuts.page when we write one and the > tab page when I split it off from the browsing (as per our conversation at > GUADEC). If you can think of any others, please let us know! All the keybindings are specified in the ephy-window.c sources: https://git.gnome.org/browse/epiphany/tree/src/ephy-window.c#n102
New page about tabs added in commit 4f9a7ef36c77cdfef7dc45b2e6359c70518d9b79 which mentions the "new tab" button. (Keyboard shortcuts were added in commits 7c38eeaeed2c87d94689ef35a38ff1fa874b66fc and a0953d9cacb99f0f6d409ec5f20ef08e59914a94)