Statical analyzer for HIG compliance

Registered by Sergey "Shnatsel" Davidoff on 2012-09-23

Develop an automated tool that checks source code for HIG compliance.

For example, it could analyze dialiogs for compliance with http://elementaryos.org/docs/human-interface-guidelines/ui-toolkit-elements/windows/dialogs - check padding, presence of "Cancel" button, complain about "OK" or "Yes/No" buttons or dialog having a window title, etc.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Munchor created something similar for checking coding style coherency, see https://github.com/elementary/vala-analyzer

===== Move this to full specification (link above) =====

##Sounds quite useful - specially so if coupled with the app center submission process. The developer could have automated feedback on what is good and what isn't, allowing one to quicky fix it.

List of parameters to check (not all mandatory but all useful to know):
-If it is coded in Vala. If not, which language it is coded in.
-Speed to start the application ("First-Launch Experience")
-If the application asks the user for configuration ("First-Launch Experience")
-If the application auto-saves it's last state ("Normal Launch")
-If the application auto-saves it's file ("Closing")
-If the application provides undos for it's operations ("Undo" - not sure if this is even possible to check for)
-If the application handling of MIME types (part of the HIG yet to be written)
-If the application interfaces with contractor (not something that should be demanded out of an app but would be useful to know)
-If the application uses the granite framework
-If the application interfaces with the dock with quicklists and/or badges and/or progressbar
-If the application has icons ranging from 16px upwards to 128px ("Icons")
-If the application uses system indicators
----if yes, check if the icon used for it are monochrome (not in the HIG but would go a long way to not making the top panel a clusterfuck of colors)
-Padding of buttons and other UI elements
-If the application uses an AppMenu ("AppMenu")
-Button placement & order ("Dialogs")
-If there are buttons using "Ok" or "Yes/No" ("Dialogs")
-If the application has a Welcome screen ("Welcome Screen")
-If the window has a title ("Window Title")
-If the window title changes according to the task/file ("Window Title")
-If title case and sentence case are properly used ("Capitalization") --this would probably require the developer to somehow flag what is what. Made me think of using some metadata that does not inflate the code but allows such HIG-Analyzer to read it? Not even sure if that is possible.
-If the application is translatable ("Language") - Perhaps check against Launchpad or other systems to even see 'where' it is translated. Could be useful to have translation links from within the app center.

Perhaps there could be a score for how close to the HIG the app is, which could be helpful when the app center is established and we want to promote the best, most coherent apps for eOS.
## ottorobba

All of this looks far too obvious to me. IMHO what would be useful is locating e.g. GSettings schemas with inconsistent paths, unlocalized UI strings and other such things that can easily slip through.
Also, such things don't belong to whiteboard - please kick off a specification in google doc or something and link it as specification URL --shnatsel

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.