Re: GNOME HIG: Feedback Wanted
In the old days of mainframe computers, each application had a messages and codes manual. Each application received a three character prefix, followed 5 digit number beginning at 0, followed by one of I (informative), W(warning), E(error) and Q(question). We don't have to stick to three characters,for example, gedit00012Q Save or Quit? The use of the code allows for rapid search for debugging (bugzilla) and for user to perform corrective action, or even a disregard (in the case of I type messages). Perhaps the code could be displayed at the tail end of the message. Its just an idea to consider and to possibly implement over time. Regards Leslie Mr. Leslie Satenstein Montréal Québec, Canada From: Allan Day allanp...@gmail.com To: Alexandre Franke alexandre.fra...@gmail.com Cc: desktop-devel-list desktop-devel-list@gnome.org Sent: Monday, April 20, 2015 12:02 PM Subject: Re: GNOME HIG: Feedback Wanted Alexandre Franke alexandre.fra...@gmail.com wrote: ... https://developer.gnome.org/hig/stable/writing-style.html.en has nothing on error messages. Can we have guidelines on what is preferred between Cannot…, Could not…, Failed to…, etc. for a bit more consistency? Sure thing - can you file a bug for that? I'm hoping to get some time for the HIG at some point this cycle. 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: GNOME HIG: Feedback Wanted
Alexandre Franke alexandre.fra...@gmail.com wrote: ... https://developer.gnome.org/hig/stable/writing-style.html.en has nothing on error messages. Can we have guidelines on what is preferred between Cannot…, Could not…, Failed to…, etc. for a bit more consistency? Sure thing - can you file a bug for that? I'm hoping to get some time for the HIG at some point this cycle. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Mon, Apr 20, 2015 at 6:02 PM, Allan Day allanp...@gmail.com wrote: Sure thing - can you file a bug for that? I'm hoping to get some time for the HIG at some point this cycle. https://bugzilla.gnome.org/show_bug.cgi?id=748197 :) -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Hi, https://developer.gnome.org/hig/stable/writing-style.html.en has nothing on error messages. Can we have guidelines on what is preferred between Cannot…, Could not…, Failed to…, etc. for a bit more consistency? -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Hey Michael, Thanks for the excellent feedback! I've tried to fix all of these points [1]. Michael Catanzaro mcatanz...@gnome.org wrote: ... On the header bar page: Header bars are incompatible with menu bars. On the menu bar page: menu bars can still be an appropriate choice, particularly for applications that already incorporate a header bar. (So that's a contradiction.) That's weird - obvious mistake. Fixed. The menu bar page specifies that the menu bar should contain all of the functionality of the app, so surely items in the app menu should be duplicated in the menu bar. Is this the intended advice? (It's contrary to what we've been advised in the past.) Either way, it'd be good to mention this on the app menu page as well, so that it's more visible. I would consider an application menu to be part of the menu modal that the menu bar belongs to. Added some guidance on that. In the section on app menus, we really need more guidance on the Quit menu item. Some apps use Quit to close all windows of the app (which seems to be intended), some use it to close the current window only (to prevent the user from accidentally closing windows on other desktops, which is a real problem with the former approach), and others omit Quit entirely to avoid the issue. We discussed this in the past but didn't really come to any conclusion. Agree that there needs to be more specific guidance here. Added something. On the spinners page, you recommend not using spinners if the range is limited on both ends. Isn't that a little strict? What about, for example, the time control in the preferences of GNOME Chess? Yes, agree. (That was copied over from the old HIG, I think.) Updated. In the section on tabs: Use tabs that are proportional to the width of their labels. Don't just set all the tabs to the same width But nowadays, tabs actually are all the same width. Dynamic tabs always have equal widths, fixed tabs don't - which is what you're referencing here. I've tried to make it a bit clearer, but let me know if you think it's problematic still. Also, I'm not sure about the advice at the very bottom of the tabs page. For example, Epiphany surely needs a new tab button in its header bar, but I don't think it'd look good to display the tab bar when only one tab is open. Ah yes. Fixed. On the toolbars page: the first few buttons in a browser application should always include Back, Forward, Stop and Reload, in that order. That advice seems dated. Good catch! Thanks again, Allan [1] https://git.gnome.org/browse/gnome-devel-docs/commit/?id=33340f4563e996a7b22759c59010243c76977980 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Wed, 2014-09-17 at 12:02 +0100, Allan Day wrote: Dynamic tabs always have equal widths, fixed tabs don't - which is what you're referencing here. I've tried to make it a bit clearer, but let me know if you think it's problematic still. Looks good! One more question: should we use GtkStack and not GtkNotebook for fixed tabs (since GtkNotebook tabs all have equal width)? Using GtkNotebook in preferences dialogs is a common pattern, for example. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Michael Catanzaro mcatanz...@gnome.org wrote: ... Dynamic tabs always have equal widths, fixed tabs don't - which is what you're referencing here. I've tried to make it a bit clearer, but let me know if you think it's problematic still. Looks good! One more question: should we use GtkStack and not GtkNotebook for fixed tabs (since GtkNotebook tabs all have equal width)? Using GtkNotebook in preferences dialogs is a common pattern, for example. I don't know of a way to do tabs without GtkNotebook right now. We've spoken a fair bit about writing a new tab widget based on GtkStack though, and that's something that I'm hopeful we'll get around to for 3.16. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Hi Allan, I have a bit more feedback on the HIG. On the header bar page: Header bars are incompatible with menu bars. On the menu bar page: menu bars can still be an appropriate choice, particularly for applications that already incorporate a header bar. (So that's a contradiction.) The menu bar page specifies that the menu bar should contain all of the functionality of the app, so surely items in the app menu should be duplicated in the menu bar. Is this the intended advice? (It's contrary to what we've been advised in the past.) Either way, it'd be good to mention this on the app menu page as well, so that it's more visible. In the section on app menus, we really need more guidance on the Quit menu item. Some apps use Quit to close all windows of the app (which seems to be intended), some use it to close the current window only (to prevent the user from accidentally closing windows on other desktops, which is a real problem with the former approach), and others omit Quit entirely to avoid the issue. We discussed this in the past but didn't really come to any conclusion. On the spinners page, you recommend not using spinners if the range is limited on both ends. Isn't that a little strict? What about, for example, the time control in the preferences of GNOME Chess? In the section on tabs: Use tabs that are proportional to the width of their labels. Don't just set all the tabs to the same width But nowadays, tabs actually are all the same width. Also, I'm not sure about the advice at the very bottom of the tabs page. For example, Epiphany surely needs a new tab button in its header bar, but I don't think it'd look good to display the tab bar when only one tab is open. On the toolbars page: the first few buttons in a browser application should always include Back, Forward, Stop and Reload, in that order. That advice seems dated. OK, that's the last of my comments. Thanks! Michael signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On the buttons page: When several buttons are placed next to each other, ensure that they have the same width. This is particularly important for pairs of Cancel and OK buttons. And then: Often this will be the OK or equivalent button. And then: Label all buttons with imperative verbs But if I follow this last piece of advice, then my app would not have any OK buttons, correct? Unrelated: Linking is a common technique for sets of toggle buttons. I worry this wording makes it seem like linking is an inappropriate technique for normal (non-toggle) buttons. From the check boxes page: Clicking the box... (when confirmed) Clicking the box a second time... (when confirmed) Clicking the box a third time... (when confirmed) When confirmed seems a little ambiguous. Am I supposed to pop up a message dialog to ask the user if he wants to apply the action? By the way, you've done a good job with the HIG; thanks. :) Michael signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Lasse Schuirmann lasse.schuirm...@gmail.com wrote: ... Some feedback from me: Typography One thing that is missing IMO in the font size discussion is the uglieness of absolute font sizes. In the Universal Access menu you have the Large Text option: if you use absolute font sizes these wont scale to that making this an accessibility issue. So using something like font-size: 80% should be recommended IMO. ... Isn't this more of a coding standard than a design guideline? On long term it would be nice if the theme would provide some css classes small-text, large-text. Then we could recommend using those instead of having our application developers dealing with those issues which should IMO be solved by the theme. I have to admit that I haven't looked into the predefined text styles that GTK+ does provide, but that is something to mention here. I know there's a dim style... anything else? In the future it would be fantastic to have a wider range of text styles (heading, body, emphasis, etc) like on the web, so the theme can specify weights and font variants. Visual Layour - Margins -- I'd like to avoid numbers on long term here. Spacing could be done by the theme by providing spacing related classes IMO. I fully agree. The numbers are mostly a reflection of how GTK+ works today, but it would be great to move to pure CSS for spacing. Hardcoded Colors - Note that I didnt read the whole thing yet, but: I didnt find anything like dont use hardcoded colors they are evil and screw up your design if someone uses e.g. the accessibility theme. And I searched. So IMO it is either too well hidden or it should come in. I have a stub for a page on color [1], which I haven't managed to finish. I'll try to get around to it. Accessibility -- Although blind users are probably not the main target group I think GNOME is proud to provide one of the most accessible linux desktops. I think it would be nice to have an accessibility page somewhere. Some advise how to make the application accessible to everyone without throwing away the mouse screen one day, because noone really does the latter. The keyboard input page contains guidance on this. There's also the accessibility guide [2]. One thing I would really like to add to the docs is a page on getting your app ready to be distributed. This would be a checklist on things like documentation, translations and accessibility. I'm not sure whether this should belong to the HIG or should be a standalone document, though. Allan [1] https://wiki.gnome.org/Design/HIG/Color [2] https://developer.gnome.org/accessibility-devel-guide/stable/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Michael Catanzaro mcatanz...@gnome.org wrote: Another question. On the header bar menus page: Header bar menus are not a good choice for performing actions on selected content: when content hasn't been selected, the menu will contain unhelpful insensitive menu items, when it has been selected, possible actions will not be advertised. This makes me think that it would be good to remove the Undo/Redo/Cut/Copy/Paste items from the header bar menu in Epiphany, since they'll usually be disabled, and they're more accessible through a context menu or a keyboard shortcut. You then say: Selection mode or popovers are a better choice for this situation. Which makes me think, oops, maybe you weren't talking about selecting text in a text field after all. ... The ambition was to provide a popover that's shown when text is selected, as a generic part of how text selections are handled [1]. That's definitely a gap in the existing application designs. That said, that page should provide clearer guidance in this regard - I'll look into it. Thanks, Allan [1] https://wiki.gnome.org/Design/OS/Selections#Tentative_Design ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Thu, Aug 28, 2014 at 12:13 AM, Lasse Schuirmann lasse.schuirm...@gmail.com wrote: There's no need to clamor for css here - Pango has always provided markup and attributes to do relative font sizes, like this: normal span font_size=largerbig/span span font_size=smallersmall/span That's interesting. The theme uses percentages. I'd assume it allows the designers to more accurately tweak the thing. I'd try to use what the theme provides for consistency. In any case I'd like to recommend a way for devs to scale text relatively. It seems that pango markup only lets you specify relative sizes in geometric steps of 1.2. If you want to use arbitrary factors, you currently have to manually create attributes in code, like this: pango_attr_scale_new (0.83); ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Thu, 2014-08-28 at 12:45 -0400, Matthias Clasen wrote: On Thu, Aug 28, 2014 at 12:13 AM, Lasse Schuirmann lasse.schuirm...@gmail.com wrote: There's no need to clamor for css here - Pango has always provided markup and attributes to do relative font sizes, like this: normal span font_size=largerbig/span span font_size=smallersmall/span That's interesting. The theme uses percentages. I'd assume it allows the designers to more accurately tweak the thing. I'd try to use what the theme provides for consistency. In any case I'd like to recommend a way for devs to scale text relatively. It seems that pango markup only lets you specify relative sizes in geometric steps of 1.2. If you want to use arbitrary factors, you currently have to manually create attributes in code, like this: pango_attr_scale_new (0.83); 1.2 is a nice scale factor. Lots of people use it. Yelp uses it for its HTML rendering. Maybe the themes should switch to using 0.83, 1.2, and 1.44. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Hi everyone, first, thanks to the designers for putting so much good work into the HIG! Some feedback from me: Typography One thing that is missing IMO in the font size discussion is the uglieness of absolute font sizes. In the Universal Access menu you have the Large Text option: if you use absolute font sizes these wont scale to that making this an accessibility issue. So using something like font-size: 80% should be recommended IMO. In addition, to keep the font-size diversity small I'd for now advise to use 80% for small texts and some other value for large texts. There are two advantages about this and the 80% is not accidentally: - The adwaita theme uses 80% for some small texts so we should stick for this value for consistency. - Having a large text value makes applications more consistent to each other anyway. On long term it would be nice if the theme would provide some css classes small-text, large-text. Then we could recommend using those instead of having our application developers dealing with those issues which should IMO be solved by the theme. Visual Layour - Margins -- I'd like to avoid numbers on long term here. Spacing could be done by the theme by providing spacing related classes IMO. Hardcoded Colors - Note that I didnt read the whole thing yet, but: I didnt find anything like dont use hardcoded colors they are evil and screw up your design if someone uses e.g. the accessibility theme. And I searched. So IMO it is either too well hidden or it should come in. Accessibility -- Although blind users are probably not the main target group I think GNOME is proud to provide one of the most accessible linux desktops. I think it would be nice to have an accessibility page somewhere. Some advise how to make the application accessible to everyone without throwing away the mouse screen one day, because noone really does the latter. More may follow later. Lasse 2014-08-26 10:50 GMT+02:00 Allan Day allanp...@gmail.com: Michael Catanzaro mcatanz...@gnome.org wrote: ... I'm about halfway done reading. I have a few suggestions, all minor: * The Visual Layout page discusses how many pixels to use as margins. This is easy for developers to use, but it caused some confusion on LWN given that on hidpi displays twice as many pixels will be used. Maybe this should be clarified. I'm a bit reluctant to do that. The guidelines don't generally comment on technical details. * On the Dialogs page: In particular, it is currently not recommended to make the Close button the default in an instant apply window, as this can lead to users closing the window accidentally before they have finished using it. I think you can remove the word currently, unless you're planning to change your mind. :) Fixed. * Regarding the keybindings page: Ctrl+Alt+Delete is power off, not log off, and it is not disabled default, although it shows up in g-c-c as log off. [1] Fixed. * Throughout the HIG, you're mostly consistent in using ' and instead of the ' and characters that are mandated by the Typography page. Some search and replace might be appropriate here, to set a good example. :) Indeed! Fixed. * On the index page: If you have never read the Human Interface Guidelines before, it is recommended that you start with the essentials section, in particular the design principles page, before continuing to learn about the design patterns. But this text is in the description for the Interface elements section, not the Patterns section. Missing markup to break the paragraph - fixed. Excellent catches, Michael. Thanks so much. 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: GNOME HIG: Feedback Wanted
On Wed, Aug 27, 2014 at 12:55 PM, Lasse Schuirmann lasse.schuirm...@gmail.com wrote: Hi everyone, first, thanks to the designers for putting so much good work into the HIG! Some feedback from me: Typography One thing that is missing IMO in the font size discussion is the uglieness of absolute font sizes. In the Universal Access menu you have the Large Text option: if you use absolute font sizes these wont scale to that making this an accessibility issue. So using something like font-size: 80% should be recommended IMO. In addition, to keep the font-size diversity small I'd for now advise to use 80% for small texts and some other value for large texts. There are two advantages about this and the 80% is not accidentally: - The adwaita theme uses 80% for some small texts so we should stick for this value for consistency. - Having a large text value makes applications more consistent to each other anyway. On long term it would be nice if the theme would provide some css classes small-text, large-text. Then we could recommend using those instead of having our application developers dealing with those issues which should IMO be solved by the theme. There's no need to clamor for css here - Pango has always provided markup and attributes to do relative font sizes, like this: normal span font_size=largerbig/span span font_size=smallersmall/span ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Am 28.08.2014 00:55 schrieb Matthias Clasen matthias.cla...@gmail.com: On Wed, Aug 27, 2014 at 12:55 PM, Lasse Schuirmann lasse.schuirm...@gmail.com wrote: Hi everyone, first, thanks to the designers for putting so much good work into the HIG! Some feedback from me: Typography One thing that is missing IMO in the font size discussion is the uglieness of absolute font sizes. In the Universal Access menu you have the Large Text option: if you use absolute font sizes these wont scale to that making this an accessibility issue. So using something like font-size: 80% should be recommended IMO. In addition, to keep the font-size diversity small I'd for now advise to use 80% for small texts and some other value for large texts. There are two advantages about this and the 80% is not accidentally: - The adwaita theme uses 80% for some small texts so we should stick for this value for consistency. - Having a large text value makes applications more consistent to each other anyway. On long term it would be nice if the theme would provide some css classes small-text, large-text. Then we could recommend using those instead of having our application developers dealing with those issues which should IMO be solved by the theme. There's no need to clamor for css here - Pango has always provided markup and attributes to do relative font sizes, like this: normal span font_size=largerbig/span span font_size=smallersmall/span That's interesting. The theme uses percentages. I'd assume it allows the designers to more accurately tweak the thing. I'd try to use what the theme provides for consistency. In any case I'd like to recommend a way for devs to scale text relatively. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Michael Catanzaro mcatanz...@gnome.org wrote: ... I'm about halfway done reading. I have a few suggestions, all minor: * The Visual Layout page discusses how many pixels to use as margins. This is easy for developers to use, but it caused some confusion on LWN given that on hidpi displays twice as many pixels will be used. Maybe this should be clarified. I'm a bit reluctant to do that. The guidelines don't generally comment on technical details. * On the Dialogs page: In particular, it is currently not recommended to make the Close button the default in an instant apply window, as this can lead to users closing the window accidentally before they have finished using it. I think you can remove the word currently, unless you're planning to change your mind. :) Fixed. * Regarding the keybindings page: Ctrl+Alt+Delete is power off, not log off, and it is not disabled default, although it shows up in g-c-c as log off. [1] Fixed. * Throughout the HIG, you're mostly consistent in using ' and instead of the ’ and “ characters that are mandated by the Typography page. Some search and replace might be appropriate here, to set a good example. :) Indeed! Fixed. * On the index page: If you have never read the Human Interface Guidelines before, it is recommended that you start with the essentials section, in particular the design principles page, before continuing to learn about the design patterns. But this text is in the description for the Interface elements section, not the Patterns section. Missing markup to break the paragraph - fixed. Excellent catches, Michael. Thanks so much. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Fri, 2014-08-22 at 08:47 +0100, Allan Day wrote: Hi all, A new version of the HIG is in the works, to be released along with GNOME 3.14 [1]. I'm currently looking for feedback. I'm about halfway done reading. I have a few suggestions, all minor: * The Visual Layout page discusses how many pixels to use as margins. This is easy for developers to use, but it caused some confusion on LWN given that on hidpi displays twice as many pixels will be used. Maybe this should be clarified. * On the Dialogs page: In particular, it is currently not recommended to make the Close button the default in an instant apply window, as this can lead to users closing the window accidentally before they have finished using it. I think you can remove the word currently, unless you're planning to change your mind. :) * Regarding the keybindings page: Ctrl+Alt+Delete is power off, not log off, and it is not disabled default, although it shows up in g-c-c as log off. [1] * Throughout the HIG, you're mostly consistent in using ' and instead of the ’ and “ characters that are mandated by the Typography page. Some search and replace might be appropriate here, to set a good example. :) * On the index page: If you have never read the Human Interface Guidelines before, it is recommended that you start with the essentials section, in particular the design principles page, before continuing to learn about the design patterns. But this text is in the description for the Interface elements section, not the Patterns section. [1] https://bugzilla.gnome.org/show_bug.cgi?id=675005 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME HIG: Feedback Wanted
Hi all, A new version of the HIG is in the works, to be released along with GNOME 3.14 [1]. I'm currently looking for feedback. I'm particularly interested to know if anything is missing, confusing, or incorrect from a technical point of view (like if any of the recommendations are impossible or very difficult to do with current GTK+). To read the latest version, just clone gnome-devel-docs and open hig3/C/index.page with Yelp. Thanks! Allan [1] https://blogs.gnome.org/aday/2014/08/21/new-human-interface-guidelines-for-gnome-and-gtk/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Hi. On Fri, Aug 22, 2014 at 08:47:50AM +0100, Allan Day wrote: A new version of the HIG is in the works, to be released along with GNOME 3.14 [1]. I'm currently looking for feedback. I've pushed an HTML version here for your convenience: http://people.gnome.org/~tobiasmue/hig3 Please note that this a one-shot effort and will likely not see any updates. Do we have automatically compiled versions somewhere? Cheers, Tobi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Fri, 2014-08-22 at 08:47 +0100, Allan Day wrote: Hi all, A new version of the HIG is in the works, to be released along with GNOME 3.14 [1]. I'm currently looking for feedback. I'm particularly interested to know if anything is missing, confusing, or incorrect from a technical point of view (like if any of the recommendations are impossible or very difficult to do with current GTK+). To read the latest version, just clone gnome-devel-docs and open hig3/C/index.page with Yelp. Thanks! Allan [1] https://blogs.gnome.org/aday/2014/08/21/new-human-interface-guidelines-for-gnome-and-gtk/ Please note that while I plan to write a small app in near future I have 0 experience with GTK+ and even less with the design so I might simply misunderstood something: - Code samples or links to the GTK+ documentation would be nice as I imagine some UI elements are named for their role rather then the GTK+ widget. Probably the samples are too much work in 3.14 timeframe but links to documentation would be nice (for example should sidebar be implemented by GtkPlacesSidebar?) - Sidebar lists image shows primary windows and application menu - I guess different image was intended. - Possibly middle mouse button should be discouraged as well due to confusion with scroll events some mouses have. I had 'fun' using one application (not in Gnome) where some basic operation was only accessible through this method. - Some sections seems to be meant to be 'obligatory' for beginners (Essentials or Getting Started) - it would be nice to have next/prev link instead of relaying on back/next button in yelp Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Fri, 2014-08-22 at 17:04 +0200, Tobias Mueller wrote: Hi. On Fri, Aug 22, 2014 at 08:47:50AM +0100, Allan Day wrote: A new version of the HIG is in the works, to be released along with GNOME 3.14 [1]. I'm currently looking for feedback. I've pushed an HTML version here for your convenience: http://people.gnome.org/~tobiasmue/hig3 Please note that this a one-shot effort and will likely not see any updates. Do we have automatically compiled versions somewhere? I don't know much about yelp but it looks like no compilation is necessary - git clone and direct opening of page worked for me. % git clone git://git.gnome.org/gnome-devel-docs --depth 1 % yelp gnome-devel-docs/hig3/C/index.page Cheers, Tobi Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Fri, Aug 22, 2014 at 4:50 PM, Maciej Piechotka uzytkown...@gmail.com wrote: On Fri, 2014-08-22 at 08:47 +0100, Allan Day wrote: Hi all, A new version of the HIG is in the works, to be released along with GNOME 3.14 [1]. I'm currently looking for feedback. I'm particularly interested to know if anything is missing, confusing, or incorrect from a technical point of view (like if any of the recommendations are impossible or very difficult to do with current GTK+). To read the latest version, just clone gnome-devel-docs and open hig3/C/index.page with Yelp. Thanks! Allan [1] https://blogs.gnome.org/aday/2014/08/21/new-human-interface-guidelines-for-gnome-and-gtk/ Please note that while I plan to write a small app in near future I have 0 experience with GTK+ and even less with the design so I might simply misunderstood something: - Code samples or links to the GTK+ documentation would be nice as I imagine some UI elements are named for their role rather then the GTK+ widget. Probably the samples are too much work in 3.14 timeframe but links to documentation would be nice (for example should sidebar be implemented by GtkPlacesSidebar?) That's something I was wondering about too. I'm not sure which approach would be best though - would it be better to list the GTK+ widgets required, point to examples, link to API docs, or something else? I'm conscious that, in many examples, the patterns are composites of different widgets. - Sidebar lists image shows primary windows and application menu - I guess different image was intended. Yep, thanks! Fixed. - Possibly middle mouse button should be discouraged as well due to confusion with scroll events some mouses have. I had 'fun' using one application (not in Gnome) where some basic operation was only accessible through this method. I'm not sure about that particular issue, but I'll certainly take another look at that section. - Some sections seems to be meant to be 'obligatory' for beginners (Essentials or Getting Started) - it would be nice to have next/prev link instead of relaying on back/next button in yelp I could certainly do that for the essentials pages. Thanks again! Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
