This is really fantastic. Apple/Google/et al are putting immense resources into surfaces and textures and really subtle animations that are expensive to compute, expensive to design, and expensive to implement. There are usability gains there, but they are rare and usually small.
I love that the Elementary HIG puts emphasis on choosing the scope of what you ask users to do, on writing style, and on a bunch of very basic usability concerns. There's a misconception that because we have Retina displays and silky animations we're somehow in a more advanced state usability-wise than we were decades ago, but many of the interaction design lessons of yore have still not been widely adopted.
I find that both go into the basics, with (focusing on writing style) such phrases as "Use User-Oriented Terminology", "Remove redundant text", "Create Succinct Labels for UI Elements", "When necessary, use bold in the control labels to make the text easier to scan", "Avoid the extremes of the 'machine' voice (where the speaker is removed from the language) and the 'sales rep' voice", and "Avoid large blocks of UI text"
Both text also advice the use of professional text writers for UI text:
"Using text consistently and clearly is a critical component of UI design. In the same way that it’s best to work with a professional graphical designer on the icons and images in your app, it’s best to work with a professional writer on your app’s user-visible text. A skilled writer can help you develop a style of expression that reflects your app’s design, and can apply that style consistently throughout your app."
"Comprehensible text is crucial to effective UI. Professional writers and editors should work with software developers on UI text as an integral part of the design process. Have them work on text early because text problems often reveal design problems. If your team has trouble explaining a design, quite often it is the design, not the explanation, that needs improving."
Could be better, as no accessibility for people with disabilities referenced at a technical conformance level: this needs to be a part of the guidelines.
Keyboard access (e.g., http://www.linuxfoundation.org/collaborate/workgroups/access...) should be a part of the overall guidelines, even without annotation to support of accessibility. This should include visual focus, as well as well defined default keyboard shortcuts, where supported by the operating system, window manager, or application conventions.
At a deeper level, concepts of textual representation of the user interface via Name, Role, State, etc. need to be conveyed. Language used in this guide that is heavily visual centric should be considered and revised if it leads end developers to ONLY think of visual situations, or encourages them to ignore accessibility.
I find it strange that they give measurements in terms of pixels. When pixel density ranges from 96 pixels per inch to 200 pixels per inch and beyond on consumer hardware alone, pixels simply aren't an appropriate measurement for UI purposes. I don't mind display optimization, but it should be exactly that: optimization. Put another way, I prefer appropriately sized, blurry UI elements over crisp UI elements I have to use a magnifying glass to see.
I also take issue with the stance against configuration. The one thing that I've found most frustrating about using computers in recent years is that I am constantly losing control over my programs to the headlong pursuit of "minimalism." Now, I don't mind simple interfaces. I don't even mind defaults geared toward the… technically challenged. What I do mind is being unable to decide how my computer behaves and how I interact with it, being effectively forced to use my computer in whatever way the developers of my current software stack have deemed best for most of their users—or, of course, switch to another software stack entirely. The latter approach doesn't exactly scale.
Now, I suppose there's a third option: dig into the internals of the unconfigurable tools looking for dconf settings or configuration files I can hack at to give me back location bars and the ability to manipulate windows with the Alt key and the mouse. Of course, this is rather difficult when the developers have been actively discouraged from writing the documentation that would make this a relatively straightforward endeavour. Instead, I'm left first trying fruitlessly to Google any and every permutation and phrasing of what I want to accomplish, next hoping that Gnome Tweak or the equivalent has a fix for the recently nerfed functionality, and finally considering for a moment searching manually through the program source for what I want before deciding it's really not worth my time, at which point I usually just throw the program out entirely and install the most bloated KDE-based alternative I can find.
/rant. I realize Elementary is designed to be as functional as possible in the hands of the non–power-user majority, but I wish it didn't come at the expense of power-usability. One can of course substitute in more powerful third-party programs for the simple system defaults, but one then loses system integration. I would love to see a project like Elementary cater to both groups of users, since I (like most self-described power users) belong to both groups, depending on the task at hand, but developers only ever seem interested in targeting one group or the other.
This is my concern as well and I have the same concern when it comes to OS X. I want a system that simplifies common tasks and makes everything look pretty while not compromising customization. That's why I use Linux - I want the power to have it my way.
The only thing that put me off and made me mistrust the quality of the content of a design related how-to, is the typographical choices made for such a text heavy site.
A font size of 14 px and a line-height of 2 em simply don't work in this specific layout. Legibility suffers and could be improved by sticking with a more consvervative line height of, ie. 1.5. - 1.7 em
The content itself I can't wait to evaluate though.
I'm deeply familiar with all the existing HIG; I actually contributed to Gnome's a long long time ago. The reason why I wanted a PDF was so I could read it offline on my tablet and see the differences with existing documents.
I love that the Elementary HIG puts emphasis on choosing the scope of what you ask users to do, on writing style, and on a bunch of very basic usability concerns. There's a misconception that because we have Retina displays and silky animations we're somehow in a more advanced state usability-wise than we were decades ago, but many of the interaction design lessons of yore have still not been widely adopted.