<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 1, 2014 at 12:04 AM, David Edmundson <span dir="ltr"><<a href="mailto:david@davidedmundson.co.uk" target="_blank">david@davidedmundson.co.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">From a developer using the HIG perspective, I want to add a few things.</span></div>

</div></blockquote><div><br></div><div>Thanks much for taking the time to look at this David!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb">

<div class="h5"><br></div></div>
<br>
There is a user setting for setting the smallest readable font and the<br>
menu font and the window title font. We should be using these.<br>
(<a href="http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKGlobalSettings.html" target="_blank">http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKGlobalSettings.html</a><br>
)<br>
<br></blockquote><div>That's why I called out the "Small", "Menu" and "Window Title" in the third column. I'm happy to remove the relationships between these system fonts and the General font if it causes confusion. That or replace it with a parenthetical em scaling.</div>

<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's a bit confusing as Plasma have diverged into their own thing<br>
(<a href="http://api.kde.org/4.x-api/plasma-qml-apidocs/Heading.html" target="_blank">http://api.kde.org/4.x-api/plasma-qml-apidocs/Heading.html</a>)<br>
<br>
We should probably unify these, even if it means adding code somewhere<br></blockquote><div><br></div><div>The trend on a few other platforms appears to be in the direction offering fonts for each typographic category, makiing it a little easier for developers to satisfy typography guidelines without the additional layer of "translation" between the HIG and the api provided system fonts. In that sense I think the Plasma Heading offering coincides well with this trend. For now though, I'm content that devs have *some* guidance on how to do the right thing regardless of whether a convenient API is currently available.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>Limit line length to between eight and ten words per line. For typographic categories that use an all caps typeface, limit to between three and four words per line.<br>
<br>
Do we ever encourage all caps?<br></blockquote><div><br></div><div>All caps have been used quite successfully in graphic design generally and various UIs in particular. What's important is understanding the impact of their use and knowing how to use them appropriately. I don't see reason to discourage their use, as much as provide guidance on how and when (not) to use them.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not sure this line length this is particularly do-able. Especially<br>
with i18n.<br></blockquote><div><br></div><div>The eight to ten words per line or the three to four word per line for all caps? </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
>Layouts with dynamic type resizing should be carefully considered<br>
<br>
Does this whole paragraph mean "don't randomly scale your text to fit spaces"?<br></blockquote><div><br></div><div>Haha! Well, yes kinda. I think resizing text to fit spaces *can* be done sensibly, as long as the text doesn't get so big/small/heavy/light that it's bigger/smaller/heavier/lighter than other text we're relying on to establish the visual and information hierarchy. For example, don't resize body text till it's bigger than the heading text. Or don't resize the section heading text to fit more words until it's smaller than the body text for which it provides a heading. Or don't resize text of relatively less importance till it's bigger than text that should be relatively more important. Sure, one way to solve this by *never* resizing text. But I also don't want to pretend that there is never a legitimate reason to re-size text.</div>

<div><br></div><div>Hope this helps answer your questions and thanks for taking the time to review and provide feedback,</div><div>Andrew</div></div></div></div>