О каких функциях должно заботиться любое хорошее приложение "By-Design"

Ведение журнала и обработка ошибок

Безопасность. Довольно забавно, но неудивительно, что это четырнадцатый ответ, который поднялся выше.

Пользовательский интерфейс / дизайн интерфейса Многие технологические инновации полагаются на дизайн пользовательского интерфейса, чтобы повысить свою техническую сложность до уровня полезного продукта. Сама по себе технология [обычно] не способствует признанию пользователей и последующей конкурентоспособности.

Из IBM:

В разработке программного обеспечения часто неправильно понимают и недооценивают дизайн. Часто явный дизайн пользовательского интерфейса не выполняется отдельно от кода. Итеративное проектирование становится перекодированием. Это недальновидная стратегия, поскольку в конечном итоге она приводит к написанию значительно большего количества кода. Поскольку дизайн неизбежен, реальная проблема заключается в том, остается ли он неявным в разрабатываемом программном обеспечении или делается явным и фиксируется отдельно. Полезные дискуссии касаются того, как сделать дизайн работоспособным и как уловить его в оптимальной форме для общения с теми, кто его реализует.

Интернационализация.
Добавлять это в качестве размышлений может быть дорого.

Возможные подводные камни:

• неанглийские ОС (например, не предполагайте имя каталога "Program Files")
• справочные данные (перевод отображаемого текста)
• изображения (текст в изображениях необходимо перевести)
• Макет пользовательского интерфейса (отступ для более длинного текста после перевода)
• многоязычные установщики, лицензионные соглашения и т. д.
• жестко закодированные строки!
• без указания средств форматирования, специфичных для языка и региональных параметров
• валюта, локализация времени (например, использование запятой и точки в валюте)
• подход к проектированию: встроенные ресурсы против вспомогательных сборок (то есть "языковых пакетов")
• дизайн базы данных: как хранить / искать значения, специфичные для языка

Лично я хотел, чтобы у него была отличная особенность:
Расширяемость.

Это помогает моему сообществу приложений расти - что хорошо с точки зрения маркетинга и техники, а также помогает мне сосредоточиться на моем основном бизнесе и оставить интересные функции, которые будут созданы его пользователями.

Удобство использования. Независимо от того, насколько расширяемым и безошибочным является наше приложение, его успех обычно зависит от того, насколько оно понравится конечным пользователям. Его можно было бы закодировать как мусор, но если он прост в использовании и интуитивно понятен в освоении, он все равно будет победителем.

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

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

В этом посте вряд ли хватит места для этого. Я настоятельно рекомендую Не заставляйте меня думать Стива Круга в качестве отправной точки для любого человека, озабоченного удобством использования.

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

Поиск. Текстовое поле поиска должно быть легко найти, а результаты должны быть как можно более хорошими.

Дизайн на основе пользовательских историй, намеренно откладывая принятие решений по дизайну базы данных до тех пор, пока не будет создан хотя бы первый фрагмент историй верхнего уровня. Слишком часто компоненты различных пользовательских процедур искажаются требованиями реляционной целостности и процедур обслуживания таблиц. Как часто мы все видели, как вводится новый заказ на продажу, и пользователю требуется перемещаться по нескольким формам для заполнения сведений о клиенте (иногда требуются телефонные звонки и / или поддельные данные для неизвестных), обязательные поля, которых на самом деле нет, кредит информация, которая действительно поступает из другого отдела, аннулированные записи из-за неполной информации, обнаруженной на нескольких страницах, и т. д.

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

Уровни сложности интерфейса, при котором наиболее распространенные и желательные действия чрезвычайно просты и очевидны для выполнения, в то время как менее распространенные и менее желательные действия достигаются за счет большей сложности.

* Последние действия / Горячие действия *

Мне нравится эта функция везде, где я ее вижу:

• Википедия - Что только что изменилось?
• Переполнение стека - Где действительно активные вопросы (где действие!)
• Блоги / Входящие - Почти в каждом блоге такая сортировка есть по какой-то причине.

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

Например, я бы хотел, чтобы это был ответ по умолчанию, потому что этот ответ будет проигнорирован! :)

Работа без мыши: насколько это возможно, приложение должно облегчить пользователю взаимодействие с ним без использования мыши. (Файл находится в разделе «Удобство использования», «Доступность».)

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

Сочетания клавиш (ctrl-f и т. д.)

Простота. Делайте то, что пользователи хотят и ожидают, с минимальным количеством кликов.

Stackoverflow - прекрасный тому пример. Интерфейс не загружен хромом. Размер самого большого изображения на сайте составляет около 3к.

Отменить

Каждое приложение (за исключением таких, как компиляторы, без интерактивного пользовательского интерфейса) должно отслеживать каждое пользовательское событие (навигация, изменение документов и настроек и т. Д.), Чтобы пользователь мог вернуться к своему текущему состоянию.

Даже приложения без изменяемых данных обычно позволяют пользователю перемещаться. «Кнопка возврата» в браузере - отличный пример функции отмены.

Автоматизация - если приложению не требуется пользовательский интерфейс для работы, включите возможность выполнения с помощью командной строки или скрипта. Обнаружено много хороших инструментов FTP (также инструментов архивирования), которым принципиально не нужен пользовательский интерфейс для выполнения намеченной работы, но которые не поддерживают сценарии или не имеют возможности командной строки.

Самоанализ: способность системы программно делать прогнозные определения своей собственной структуры и поведения. (Аналогично отражению на уровне языка и является ключевым элементом расширяемости.)

Фокус ввода по умолчанию: в любой презентации интерфейса, где ожидается, что пользователь будет вводить текст, фокус ввода должен по умолчанию находиться в том месте, где они, скорее всего, захотят начать ввод. (Это особенность области юзабилити.)

В случае веб-форм, к сожалению, необходимо отметить, что установка фокуса по умолчанию также не должна мешать пользователю, если он уже начал вводить текст при проверке установки фокуса по умолчанию.

(Бесстыдный плагин: я поддерживаю некоторый обобщенный Javascript, который решает эту проблему для веб-форм.)

Входящие
хотя кажется, что упоминать о нем очень мало, но он действительно сильно влияет на удобство использования приложения и производительность. Представьте, если пользователь может запросить тяжелый отчет, который может занять несколько минут на создание,
вместо «нажмите и подождите» он может выбрать «отправить мне последний отчет, когда он будет готов»

Производительность (читайте это как задержку, если хотите).

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

В мире нет других проектов, требующих переоснащения в большей степени, чем решение, подобное виртуальным машинам, на Java и CLR. Это явный артефакт каждого продукта, технологии, редакции и, конечно же, раздувания под названием: .NET 3.5 и, скажем, клиент Oracle 200MB (смеется).

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

Масштабируемость - это совершенно другая история, но люди просто не будут использовать приложения с высокой задержкой, и большинство из них CLR (кроме веб-материалов, которые просто просты и неприменимы в 60% случаев, как этот сайт / приложение) просто тот. Загрузите что-нибудь серьезное, и вы будете работать в неуправляемом офисе, неуправляемой среде IDE, неуправляемой базе данных, неуправляемой игре, неуправляемом браузере и так далее.

Кто-то должен ударить любителей GC битой и сказать им, чтобы они проснулись ..

Модульность - Производительность - Расширяемость

Это общие цели дизайна - скажем - Smart Client Software Factory. И это работает.

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

Комментарии. Внедрите внутреннюю стандартную систему комментариев (сначала задокументируйте ее!) - автоматическая система документации комментариев может быть правильной, или просто набор стандартных комментариев заголовков программы и соглашений о комментариях. Заранее сообщите программистам, как вы ожидаете комментирования кода. Проводите кросс-программистские обзоры кода, проверяйте читаемость / понятность с прицелом на будущие модификации: если вы следующий человек, который будет работать над этим кодом, будет ли это иметь для вас смысл?

Отчетность
потому что всегда больно запускать один отчет, который считывает данные почти из каждой таблицы в базе данных
Однажды я видел презентацию (которую я больше не могу найти) говоря о шаблоне проектирования базы данных для хранилищ данных, с демонстрацией amazon
одним из решений было создание специальной денормализованной базы данных, отчеты которой публикуются для нее каждый определенный период

Пометка

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

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

Поддержка Unicode, поскольку кодировка уровня представления ISO-8859-1 и кодировка уровня сохраняемости UTF-8 бесполезны.