Советы по стыковке окон для Mac - PullRequest
12 голосов
/ 13 февраля 2010

Я из среды программирования Windows, когда писал инструменты, но программировал с использованием Carbon и Cocoa в течение прошлого года. Я представился Mac, я признаю это, скрываясь от программирования пользовательского интерфейса. Я в основном вырисовывал свой OpenGL-код в виде, а затем оставался в своей зоне комфорта, как обычно, используя свой независимый от платформы код OpenGL C ++.

Однако теперь я хочу начать перенос одного из моих более сложных приложений на Mac OS.

Обычно я использую стандартный подход MDI для док-станции Visual Studio, который превосходен, но очень похож на Windows. От использования Mac в основном сейчас некоторое время, я не склонен видеть такой метод, используемый для пользовательских интерфейсов Mac. Даже Xcode, к сожалению, не поддерживает идею перетаскивания / закрепления представлений. Я вижу закрепленные виды с разделительными панелями, но это все.

Самая близкая вещь, которую я видел к подходу Visual Studio, - это Photoshop CS4, который довольно хорош.

Так, каково общее согласие по этому вопросу? Есть ли более Mac-подобный способ достижения того же, чего я не видел? Если нет, то я с удовольствием напишу оконный менеджер в Какао, чтобы наконец-то погрузиться в изучение того, что выглядит как отличный API.

Обратите внимание, я не хочу использовать QT или любые другие кроссплатформенные библиотеки. Все дело в том, что я хочу сделать приложение Mac похожим на приложение Mac, оставить приложение Windows похожим на приложение Windows. Я всегда нахожу, что кросс-платформенные библиотеки имеют тенденцию терять этот эффект, и когда я вижу собственный Mac-интерфейс с причудливыми переходами и анимацией Какао, я всегда улыбаюсь. Это также хороший повод для изучения какао.

Как говорится, если для этого есть библиотека Какао с открытым исходным кодом, я бы хотел узнать об этом! Мне бы очень хотелось увидеть, как кто-то еще добивается этого и поможет сгладить кривую обучения какао.

Приветствия

Шейн

ОБНОВЛЕНИЕ : Я забыл упомянуть критическую точку. Я поддерживаю плагины, которые могут иметь собственный интерфейс для отображения различной информации о плагинах. Я не знаю, какие плагины будут загружены, и я не знаю, где будет жить их пользовательский интерфейс, если я не буду поддерживать стыковку. Мне бы очень хотелось услышать мнение людей по этому поводу, а именно: как мне поддержать архитектуру представления плагинов, если пользовательский интерфейс не может измениться? Где я могу разместить плагин просмотров?

Ответы [ 4 ]

10 голосов
/ 13 февраля 2010

Исходя из фона Windows, вы чувствуете необходимость иметь окна стыковки, но действительно ли это важно для приложения? Философия Apple (на мой взгляд) заключается в том, что дизайнер лучше пользователя знает, как все должно выглядеть и работать. Например, iTunes является довольно сложным приложением, но оно не позволяет вам изменять пользовательский интерфейс, менять скины и т. Д., Потому что Apple хочет поддерживать его согласованность. Они предлагают полный просмотр, мини-плеер и несколько различных вариантов просмотра, но они не позволяют вытащить список источников в отдельное окно или закрепить его в других положениях. Они думают, что это должно быть слева, поэтому оно остается ...

Вы сказали, что «хотите, чтобы приложение Mac выглядело как приложение Mac», и, как вы указали, в приложениях Mac нет окон для закрепления. Поэтому реализация собственных окон стыковки, вероятно, является шагом в неверном направлении;)

2 голосов
/ 13 февраля 2010

Одна вещь, которая часто встречается во многих приложениях Mac, - это возможность скрыть весь хром и сосредоточиться на своем контенте. В этом и заключается смысл панели управления «tic tac» в правом верхнем углу многих окон. Серьезным недостатком многих стыковочных интерфейсов является то, что они ожидают, что окно займет большую часть экрана, потому что закрепленные панели могут скрывать содержимое. Даже если закрепленные панели складываются, оставленное ими пространство часто просто теряется и заполняется пустым пространством. Поэтому, если вы встроите панель стыковки в свой интерфейс, вы должны ожидать, что она будет видна большую часть времени. Например, список источников iTunes четко спроектирован так, чтобы его можно было постоянно видеть, но вы можете дважды щелкнуть плейлист, чтобы открыть его в новом окне.

Чтобы привыкнуть к диапазону элементов управления Mac, я бы посоветовал вам попробовать проделать серьезную работу с некоторыми приложениями, которые не имеют кроссплатформенного пользовательского интерфейса; например, приложения iWork, Интерфейсный Разработчик или Предварительный просмотр. Обратите внимание на то, где появляются элементы управления и почему - на панелях инструментов, на нижних панелях, в инспекторах, в списках источников / боковых панелях, на панелях, таких как Библиотека IB или на панели «Шрифт и цвет», в контекстных HUD. Не забывайте и строку меню. Получите представление о чувствах элементов управления - об их отзывчивости, модальности, размерах, группировке и согласованности. Попробуйте выработать вкус - не все идеально; просто попробуйте iCal, если хотите что-нибудь посмеяться.

Обратите внимание, что для элементов управления не существует «одного размера для всех», что может быть проблемой при использовании интерфейса стыковки. Важно подумать о рабочем процессе: насколько часто используется элемент управления, можете ли вы заменить его прямыми манипуляциями, нужна ли видимая индикация его состояния, работает ли он с клавиатуры и мыши, где это необходимо, и так далее. Выясните, как размещение и поведение элемента управления позволяет пользователю работать более эффективно.

В качестве простого примера примера размещения хорошего и плохого элемента управления и поведения в неприличных в других случаях приложениях сравните маскирование изображений в OmniGraffle и Keynote. В OmniGraffle для этого используется инспектор изображений, в котором необходимо сначала нажать на кнопку без метки («Естественный размер»), чтобы включить соответствующие элементы управления, а затем отрегулировать размер и положение с низкой точностью с помощью миниатюры изображения или ввод процентов в поля. Попытка изменить размер кадра ведет себя странным и нелогичным образом.

В Keynote маскирование начинается с явно названного элемента меню или элемента панели инструментов, использует HUD, который выскакивает, как только вы нажимаете на маскируемое изображение, и позволяет осуществлять прямые манипуляции, включая разумное отображение размера изображения, на котором вы находитесь. маскировки. Пока вы тащите замаскированное изображение, оно даже следует за направляющими. Опытные пользователи могут полностью игнорировать HUD, просто дважды щелкнув изображение, чтобы переключить редактирование маски и используя маркеры для изменения размера. Это должно быть легко увидеть, с несколькими предостережениями (например, состояние режима «Edit Mask» должно быть видно в HUD, а не только на изображении; внешняя граница маскируемого изображения должна использоваться более эффективно) Keynote значительно лучше в этом, отчасти потому, что он не использует инспектора.

Тем не менее, если у вас есть огромное количество опций, а стандартный макет инспектора с вкладками не работает для вас, ознакомьтесь с OmniInspector Omni Group. Попробуйте использовать его по-хорошему, и, надеюсь, вы поймете, как одержимы пользовательским интерфейсом так же, как и графикой: -)

2 голосов
/ 13 февраля 2010

+ 1 к ответу Кена.

С точки зрения пользователя, если оно не является неотъемлемой частью приложения, такого как Adobe CS или Eclipse, я хочу, чтобы все было максимально лаконичным, а также все возможные варианты и отображались так, чтобы я мог сосредоточиться на документе.

Я думаю, что для пользователей Mac вы обнаружите, что те, кто обладает "пользовательским навыком", чтобы использовать перестановку панелей, в большинстве случаев выбирают вместо этого горячие клавиши, а те, кто не имеет такого уровня "навыков", вы просто собираюсь запутать.

Я бы рекомендовал сделать это как можно более простым.

1 голос
/ 13 февраля 2010

(работает в замедленном темпе, протягивая руку в панике) Nnnnnoooooooo !!!!!

:-) Серьезно, как я уже упоминал в ответ на превосходный ответ Кена, попытка навязать «Windowsism» в пользовательском интерфейсе OS X - определенно плохая идея. На мой взгляд, самая большая проблема с пользовательским интерфейсом Windows заключается в том, что сторонние разработчики изобретают новые и непоследовательные способы представления пользовательского интерфейса, а не являются последовательными и следуют установленным соглашениям. Для пользователя Mac это признак ужасного приложения. Это так по причине.

Я призываю вас переосмыслить реализацию UI приложения с нуля с учетом Mac OS. Если вы хорошо выполнили свою работу, архитектура и модель (без реализации для конкретной платформы) должны быть четко переведены на любую платформу.

С точки зрения пользовательского интерфейса, вы использовали Mac в течение года, поэтому вы должны иметь довольно хорошее представление о «норме». Если у вас есть сомнения, лучше всего опубликовать вопрос, подробно описывающий то, что вам нужно представить, и ваши мысли о том, как вы можете это сделать (или спросите, как, если вы не знаете).

Только не бейте свое приложение уродливой флешкой, заставляя его вести себя так, как будто оно работает в Windows, когда оно явно не работает. Это поцелуй смерти для приложения для пользователей Mac.

...