Community additions to Apple's Human Interface Guidelines
by sindresorhusLast 12 weeks · 0 commits
4 of 6 standards met
The readme for iOS specifies: What you should definitely not do: “Done” button on the left side. “Cancel” button on either side.** “Dismiss” button on either side. Is this documented anywhere else? A few minutes of looking around and I already found some system apps that do have a cancel button on the left. See screenshots: Clock app Health app Reminders app This makes me believe that a "Cancel" button is OK as long as it's on the left side, meaning destructive action, while the right side means "do some action with the data in this modal". Also note that all of these modals are in the context of adding data or creating an item, which might also be important when it comes to usage.
Would be nice to document some menu bar icon best practices. The bounding box is 22pt. I looked at my apps, and I usually use 18pt. Other people confirmed they use 18pt too. Some tweets from Jeff Nadeau about menu bar icon sizing and design: You get 22pt of height (and wouldn’t want to extend into the margins except for fine details) so that seems fine. In Big Sur a symbol image is ideal. The size, weight, and baseline are chosen to be consistent across menu extras, and it works w/ the “bigger menu text” AX pref One technique is to design within a 22pt bounding box so you can pick the exact vertical bearing of your icon within the whitespace. (We did this for the original Touch Bar icons. We allow “full bleed” content there, so the icons were uniformly produced in a 30pt tall canvas.) — Jeff Nadeau [tweet 1] [tweet 2]
When you have a text field for a number with a stepper on the right side, what’s the recommended distance between the text field and the stepper? Some observations: Xcode Interface Builder: 2 points https://developer.apple.com/documentation/appkit/nsstepper: 8 points "Date & Time system preferences": 4 points “Voice Over Utility”: 6 points in SwiftUI with only time component: 3 points So basically no consistency. I also noticed that the "Screen Time" system preferences put the stepper inside the text field. Not clear in what situations that's recommended. The HIG doesn't say anything about the distance, unfortunately: https://developer.apple.com/design/human-interface-guidelines/macos/selectors/steppers/ Any opinions?
I have noticed that some of Apple’s apps show their preferences window (while it's open) in the “Window” menu and others don’t. Apps where the preferences window shows up in the "Window" menu: Xcode Calendar Reminders Safari App Store Mail Contacts Photos Keychain Access Script Editor Dictionary Apps where the preferences window does not show up in the "Window" menu: Notes Messages Final Cut X Music TV TextEdit Grapher Terminal Preview What's your opinion about this?** Include reasonings. FB: https://github.com/feedback-assistant/reports/issues/111
https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/drag-and-drop/ For example, if my app accepts dropping JPEG files and then converts them, and a user drags in both JPEG and PNG files, should it: 1. Prevent the drag and show an error dialog. 2. Prevent the drag without an error dialog. 3. Accept the drag, but update the drag badge with the amount of supported items. 4. Accept the drag, update the drag badge, and show an info dialog after the conversion about which files were ignored. If or . What should the dialog be like? Include reasoning when commenting on which one you prefer. FB: https://github.com/feedback-assistant/reports/issues/93
https://developer.apple.com/design/human-interface-guidelines/macos/app-architecture/preferences/ Some apps' preferences window closes when you press Escape and others don't. The system apps are very inconsistent about this. For example, Mail.app's preferences window doesn't close when you press Escape, while Xcode's preferences window does. I personally think it should not close on Escape as it should be a normal window and not a panel (). Share your opinion with reasonings either way. FB: https://github.com/feedback-assistant/reports/issues/71
Repository: sindresorhus/human-interface-guidelines-extras. Description: Community additions to Apple's Human Interface Guidelines Stars: 270, Forks: 5. License: CC0-1.0. Topics: apple, human-interface-guidelines, ios, macos, tvos, watchos. Open PRs: 0, open issues: 6. Last activity: 5mo ago. Community health: 71%. Top contributors: sindresorhus.