Изучение дизайна для UI и [закрытого] дизайна веб-сайта

Обязательно прочтите: Не заставляйте меня думать

Я бы посмотрел на A List Apart и Сигналы против шума , чтобы получить хороший совет, но изучение дизайна - это очень многое. хорошего и плохого дизайна - посмотрите на действительно хорошо разработанные веб-сайты (например, созданные HappyCog , SimpleBits или Airbag Industries ). Посмотрите на всех людей, которые там работают, их блоги, их работы, их книги - вдохновляйтесь, но никогда не копируйте.

Я также с осторожностью относился бы к сайтам, посвященным исключительно дизайну «пользовательского опыта» или «юзабилити», многие из которых принципы дизайна не имеют ничего общего с пользовательским тестированием, исследованиями или HCI, и сосредоточение большого внимания на этих вещах может привести к разработке методологий, а не смысла. Я бы рекомендовал пройти курс коммуникационного дизайна и узнать о шрифтах. Хороший дизайн начинается с шрифта и иерархии - Thinking With Type - отличная вводная книга. Также читайте о сеточных системах и гештальт-психологии.

Удачи!

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

Тем не менее, мой опыт проектирования пользовательского интерфейса был в основном сосредоточен на веб-приложениях. Я считаю работу Дэна Седерхольма наиболее поучительной в разработке превосходных пользовательских интерфейсов для Интернета. Одним из наиболее важных аспектов веб-дизайна является обеспечение семантически корректных доступных сайтов, и Седерхольм отлично описывает, как это сделать, в Web Standards Solutions , за которым последовал также отличный Bulletproof Web Design .

Хотя CSS Zen Garden не может быть посвящен непосредственно дизайну пользовательского интерфейса, он является выдающимся примером того, что может быть достигнуто визуально с помощью дизайна на основе CSS.

Наконец, часто упускаемая из виду часть дизайна пользовательского интерфейса. доставляет эффективные сообщения об ошибках. В то время как Защитный дизайн для Интернета подчеркивает, что дизайн веб-ошибок, многое из того, что описано, применимо к другим средам. Авторы книги 37Signals ведут отличный блог Сигнал против шума .

Практически все, что вам нужно знать о UX и о том, как стать его частью: http://whitneyhess.com/blog/2009/06/30/so-you-wanna -be-a-user-experience-designer-step-1-resources /

Smashing Magazine (новые статьи ежедневно) охватывает множество тем, в том числе множество статей о дизайне хорошего качества. Сообщение об удобстве использования также содержит некоторые качественные материалы, хотя он не так часто обновляется.

Якоба Нильсена Useit.com . Там много работ, и в основном речь идет об инженерии юзабилити (то есть не об эстетической стороне дизайна), что вызывает споры у многих веб-дизайнеров.

Отдельный список предоставляет множество советов и приемов. а также статьи по веб-верстке и дизайну.

Один из лучших способов улучшить дизайн пользовательского интерфейса - это осмотреться. Взгляните на дизайн веб-сайтов / приложений критически.

Посмотрите, что вам нравится и что не нравится в различных элементах этих сайтов. Со временем это сделает вас гораздо лучшим веб-дизайнером.

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

Разработка интерфейсов Дженифер Тидвелл - хорошая идея.

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

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

1 - Связывание и прослушивание
Ваш код мне подходит, лично я использую:

serverSocket.Bind(new IPEndPoint(IPAddress.Any, 4444));

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

1.5 - Принятие клиентских подключений
Просто упомяну об этом для полноты картины ... Я предполагаю, что вы делаете это, иначе вы не дойдете до шага 2.

2 - Получение данных
Я бы сделал буфер немного длиннее 255 байт, если только вы не можете ожидать, что все сообщения вашего сервера будут иметь размер не более 255 байт. Я думаю ты' если формат вашего сообщения (порядок его компонентов) спроектирован таким образом, чтобы в любой момент клиент мог определить, должны ли быть следующие следующие данные (например, код 0x01 означает, что следующим будет int и строка, код 0x02 означает, что следующим будет 16 байт и т. д. и т. д.). В сочетании с подходом NetworkStream на стороне клиента это может быть очень эффективным подходом.

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

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

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

6 - Неизвестные отключения
Я бы не доверял даже статусу сокета ... соединение может умереть где-то на пути между клиентом / сервером без клиент или сервер замечают.

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

Более продвинутый
Если вам нужна высокая масштабируемость, вам придется изучить асинхронные методы для всех операций сокета (Accept / Send / Receive). Это варианты «Начало / конец», но они намного сложнее в использовании.

Я не рекомендую пробовать это, пока у вас не будет работать простая версия.

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

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