Советы по стыковке окон для Mac

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

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

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

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

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

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

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

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

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

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

Вы можете использовать анонимную функцию в matlab (аналогично лямбда-функциям в других языках):

u = 1.2;
[t y] = ode45(@(t, y) ypdiff(t, y, u), [to tf], yo);

Звучит как перебор (если я правильно понимаю) - это создание моделей на лету. Вы не используете основное преимущество наличия моделей; компилируйте проверки времени.

Я бы попытался использовать объекты, специфичные для задачи (например, класс UserForm, который будет иметь список классов UserFormFields и так далее) в руках и не создавать их на лету.

Изменить: Я предлагаю не использовать проверку на основе атрибутов и проектировать модель с учетом проверки. Такой дизайн, как ниже, может объяснить мою точку зрения лучше:

interface IUserValidation
{
    bool IsValid();
}

class RequiredUserValidation : IUserValidation
{
    public bool IsValid()
    {
        // ....
    }
}

class UserFormField
{
    List<IUserValidation> _validations;

    public IEnumerable<ValidationResult> Validate()
    {
       // ...
    }
}

(работает в замедленном режиме, тянется в панике) Nnnoooooooo!!!!!

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

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

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

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