Больше чем юзабилити: четыре составляющие User Experience
Некоторые ошибочно считают «User Experience» (UX) и «юзабилити» синонимами. Однако «юзабилити» все чаще используется в более узком смысле как обозначение того, насколько пользователям удобно выполнять требуемые задачи, и ассоциируется с понятием «юзабилити-тестирование». Таким образом, юзабилити воспринимается многими как тактический аспект процесса разработки программных продуктов. User experience, напротив, используется UX-специалистами в гораздо более широком смысле и вбирает в себя самые разнообразные аспекты: удобство в использовании, вовлеченность пользователя, визуальная привлекательность продукта и т. д. Этот термин лучшим образом отражает психологические и поведенческие аспекты взаимодействия пользователей с программными продуктами.
В данной статье представлена схема, описывающая четыре составляющих user experience (см. рис. 1) и то, как их взаимодействие позволяет улучшать конечные продукты. Данная схема поможет определить цели и масштаб деятельности, направленной на создание позитивного пользовательского опыта.
Рис. 1. Четыре составляющие user experience
Для упрощения многочисленные аспекты user experience были сведены к этим четырем составляющим как наиболее фундаментальным. Другие стороны user experience, например, надежность, досягаемость и легкость поиска, описанные Питером Морвилем (Peter Morville), можно рассматривать как компоненты четырех основных составляющих.
Юзабилити: легко ли пользователям решать стоящие перед ними задачи.
Многие подразумевают под «юзабилити» все элементы user experience, хотя на самом деле юзабилити стоит рассматривать скорее как одну из его составляющих.
Юзабилити – это степень удобства, с которой пользователь может выполнять стоящие перед ним задачи, используя программный продукт. Существует множество связанных с юзабилити проблем, которые мешают пользователям достигать желаемого результата. Приведем несколько примеров.
Пользователь iPhone хочет позвонить человеку, которого нет в его списке контактов, и ему нужно ввести номер вручную. Он нажимает кнопку Phone в нижней части экрана. Пока все просто, но что делать дальше? Экранной клавиатуры нет. Какого-нибудь поля, в которое можно было бы ввести номер, тоже нет. Используя термины из области проектирования взаимодействия, можно сказать, что в данном случае отсутствует какой-либо призыв к действию, приглашение или контекстуальный стимул. Какое-то время пользователь внимательно рассматривает экран, пока, наконец, через полминуты не обнаруживает кнопку «Keypad» в нижней части экрана. Проблема решена, но сколько времени пользователю пришлось потратить на банальный ввод телефонного номера! А ведь это одна из основных функций любого телефона. Это яркий пример проблемы из области юзабилити.
Приведем еще один пример. Вспомните, как вам впервые пришлось воспользоваться корпоративным интранетом, чтобы заказать канцтовары, отправить отчет о расходах, отследить собственное продвижение по службе или узнать о начислении зарплаты. Наверняка не обошлось без помощи службы поддержки или кого-нибудь из коллег, не так ли? Юзабилити большинства интранет-сайтов находится на очень и очень низком уровне – до некоторых вещей просто невозможно додуматься самостоятельно.
К сожалению, такие проблемы можно обнаружить в большинстве приложений. Мы приведем всего несколько примеров того, насколько недовольными могут остаться пользователи, поработав с такими программными продуктами.
Юзабилити напрямую не затрагивает вопросы, связанные с такими элементами представленной схемы user experience, как, например, намерения пользователя, его вовлеченность или визуальная привлекательность продукта. К категории «юзабилити» относятся те компоненты user experience, которые так или иначе связаны с удобством использования.
В эту категорию можно включить такие аспекты, как простота освоения продукта; понятность, обнаруживаемость и читабельность контента; а также то, насколько легко пользователю удается распознавать информацию и приглашения к действию.
Юзабилити само по себе является довольно обширной темой, развитию которой посвятило себя целое поколение специалистов в области человеко-компьютерного взаимодействия, стремившихся сделать использование цифровых продуктов более удобным и приятным. Конечно же, user experience не сводится исключительно к способности выполнять задачи, осваивать новые функции или ориентироваться на веб-сайте. Когда речь заходит о коммерческом успехе, на первый план выходят совсем другие аспекты ux.
Ценность: является ли продукт полезным для пользователей
Хотя юзабилити и является важным аспектом дизайна продукта, решающую роль в достижении коммерческого успеха играет не оно. Многие продукты с отличным юзабилити оказываются невостребованными на рынке. В качестве примера можно привести традиционные мобильные телефоны, неумолимо сдающие позиции под натиском смартфонов, притом что пользоваться традиционными моделями куда как удобнее. В чем же причина? Дело в том, что сейчас потребителям нужны разнообразные функции, которые традиционные телефоны, в отличие от смартфонов, не поддерживают: это и веб-серфинг, и мессенджеры, и игры, и GPS, и многое другое. Этот пример прекрасно отражает суть ценностного аспекта пользовательского опыта.
Что же делает продукты ценными для пользователей? Ответ: соответствие функций продукта потребностям пользователя. Пользователь рассматривает продукт как полезный в том случае, если функции продукта удовлетворяют его потребности. Причем под этим подразумеваются не только выраженные потребности, в которых пользователи отдают себе отчет. Здесь учитываются и скрытые потребности, которые пользователи по сути не осознают как таковые. Яркими примерами удовлетворения скрытых потребностей являются продукты компании Apple, такие как iPhone и iPad. Они не только просты в использовании, но и позволяют удовлетворить скрытые потребности пользователей, делая их жизнь значительно комфортней.
Ценность продукта очень близко связана с другими составляющими UX, такими как юзабилити и привлекательность, но в отличие от них она обуславливается функциональностью продукта. Ценность лежит в основе благоприятного пользовательского опыта. Вне зависимости от того, насколько продуман дизайн, если продукт не рассматривается как полезный, то user experience наврядли будет благоприятным.
Доступность (adoptability): начнут ли пользователи работать с продуктом
Браузерная панель инструментов Yahoo! (см. рис. 2) может быть одновременно и удобна, и полезна для рядового интернет-пользователя, но чтобы воспользоваться ее функциями, сперва придется ее установить. Здесь мы сталкиваемся с еще одной составляющей пользовательского опыта – доступностью.
Рис. 2. Панель инструментов браузера Yahoo!
Приведем несколько примеров проблем, связанных с доступностью. Когда какая-нибудь компания выпускает приложение для iPhone, ссылка на это приложение обычно размещается на основном веб-сайте этой компании. Это создает массу проблем для пользователей: как загрузить приложение на iPhone с помощью этой ссылки, если основной веб-сайт предназначен для просмотра на настольном компьютере, а не на мобильном устройстве? Примером данной проблемы может послужить веб-сайт компании Vanguard (см. рис. 3), оказывающей услуги финансового консалтинга.
Рис. 3. Сайт Vanguard.com
Логичнее было бы разместить ссылку на приложение для iPhone на мобильной версии сайта, которая открывается на iPhone по умолчанию. Однако, вопреки ожиданиям, на мобильной версии сайта ссылки на приложение не оказалось. Налицо большая проблема с доступностью. Загрузить приложение Vanguard для iPhone можно, только прибегнув к весьма изощренной процедуре: сперва нужно открыть iTunes Store, в поисковой строке ввести Vanguard, затем выбрать нужно приложение и, наконец, установить его. Такой способ знакомства с программой не назовешь спонтанным.
Из вышеприведенного становится понятно, что доступность тесно связана с планированием рабочих процессов. Вдобавок к этому на доступность влияют такие аспекты, как надежность и восприятие бренда: недостаточно аутентичный или ассоциируемый с непопулярным брендом контент вряд ли привлечет пользователей.
Доступность и юзабилити тесно взаимосвязаны. UX-специалисты прибегают к проверенным методам из области юзабилити, чтобы сделать продукты более доступными и дать пользователям возможность знакомиться с функциями создаваемых продуктов естественным для них образом. Тем не менее необходимо отличать эти две составляющие друг от друга. К вопросам доступности относится то, каким образом пользователи приобретают, загружают, устанавливают продукт и начинают им пользоваться. Доступность связана с тем этапом, когда пользователь еще не успел поработать с продуктом, в то время как юзабилити вступает в игру с началом использования продукта. Подчеркивая это различие, хотелось бы напомнить о часто забываемом аспекте стратегии пользовательского опыта: продукт должен быть легкодоступен.
Также очевидно, что доступность и полезность продукта – это разные вещи. Пользователь может отказаться от использования даже очень полезного продукта, если столкнется с трудностями при доступе к нему или при установке, как было показано выше. Доступность связана с указанием кратчайшего пути к продукту, а полезность – непосредственно с функциями продукта и его контентом. Чтобы избежать проблем, связанных с доступностью, разработчикам необходимо принимать в расчет то, в какой ситуации пользователь впервые сталкивается с их продуктом и как это может повлиять на процесс установки.
На первый взгляд может показаться, что у доступности много общего с маркетингом продукции, так как и то и другое связано с продвижением продукта и стимулированием его использования. Традиционный маркетинг – это рекламные кампании, продвижение веб-сайтов, рассылки по электронной почте и так далее. В отличие от него доступность является составляющей пользовательского опыта, и ее нужно рассматривать как неотъемлемую часть процесса разработки продукта.
Привлекательность: нравится ли пользователю работать с продуктом
До сих пор мы обсуждали только когнитивные, то есть рациональные, аспекты пользовательского опыта. В отличие от них привлекательность относится к эмоциональной сфере. Зачастую удобные и функциональные продукты не находят спроса на рынке просто потому, что они недостаточно привлекательны для пользователей. Такая участь постигла традиционные MP3-плееры в неравной борьбе с iPod, равно как и электроника множества производителей проигрывает продукции компании Sony.
Многие продукты находят спрос, несмотря на недостатки в их юзабилити. Возьмем, к примеру, видеоигры, юзабилити большинства которых далека от совершенства: инструкции противоречивы, навигация запутана, меню настроек спрятаны в самых неожиданных местах, а уж про читаемость контента и говорить не приходится. Но эти игры настолько увлекательны, что все перечисленные недостатки не останавливают пользователей.
Привлекательность в первую очередь связана с инновационным визуальным дизайном. Продуманный внешний вид стимулирует привлекательность продукта (см. рис. 4 и 5).
Рис. 4. Привлекательный внешний вид Bing
Рис. 5. Привлекательный внешний вид iPad
Стоит отметить, что привлекательность всегда определяется в контексте задач, стоящих перед пользователем, и, таким образом, не сводится исключительно к симпатичной графике и приглаженному дизайну. Привлекательность продукта должна быть связана с задачами, которые пользователю требуется решить посредством данного продукта. Один и тот же продукт может быть привлекательным для пользователей, заинтересованных в его функциональных возможностях, и абсолютно не привлекательным для пользователей вне его целевой аудитории. Например, я люблю анализировать данные, и в этом отношении мне очень нравится Excel. Несмотря на то что эта программа не отличается изысканным дизайном, я с удовольствием работаю в ней: ее примитивный интерфейс отлично подходит для анализа данных. Анимированный Excel уже не был бы так привлекателен для меня, поскольку графика отвлекала бы от непосредственного выполнения задач.
Рис. 6. Привлекательность не сводится исключительно к насыщенному графикой интерфейсу, как в случае с Excel
В качестве примеров того, что привлекательность должна рассматриваться в контексте задач пользователя, рассмотрим главные страницы веб-сайтов Nordstrom.com и eBay.com. С точки зрения внешнего вида Nordstrom.com (рис. 7) оказывается далеко впереди, потому что он выглядит гораздо более аккуратно и симпатично. Но с точки зрения user experience главная страница eBay.com оказывается гораздо более привлекательной для основной массы пользователей eBay, покупающих товары на аукционе. Причина проста: покупатели на eBay постоянно находятся в поисках выгодных предложений, и изображения выставленных на продажу подержанных вещей – это то, что им нужно. Дизайн главной страницы Nordstrom.com намекает на то, что здесь продаются отнюдь не дешевые товары, – этим покупателей с eBay не завлечешь. Онлайн-аукционы – ключевое направление деятельности на eBay.com, и чтобы оставаться привлекательным для пользователей, этому сайту как раз и не требуется чрезмерно прилизанный дизайн.
Рис. 7. Сайт Nordstrom.com
Рис. 8. Сайт eBay.com.
Различия между составляющими пользовательского опыта
Мы рассмотрели четыре составляющие пользовательского опыта, и у вас могло возникнуть ощущение, что все они похожи друг на друга. Следующие примеры помогут вам четко различать эти составляющие:
• Проблема, связанная с доступностью: пользователь хотел бы воспользоваться приложением для iPhone, которое расхваливал его знакомый, но не знает, как его установить.
• Проблема, связанная с юзабилити: активно используя продукт, пользователь тем не менее с трудом решает стоящие перед ним задачи.
• Проблема, связанная с привлекательностью: несмотря на то что пользователь с трудом выполняет некоторые задачи, он пользуется продуктом с удовольствием. То есть с привлекательностью у данного продукта все в порядке, а вот с юзабилити есть кое-какие проблемы.
• Проблема, связанная с полезностью: пользователь с легкостью может решать все стоящие перед ним задачи, но не воспринимает функции продукта как полезные.
Заключение
Схема, в которой user experience разбит на четыре взаимосвязанные составляющие (полезность, юзабилити, доступность и привлекательность), может послужить UX-специалистам подспорьем при определении ключевых элементов разработки продукта и их улучшении.
Разумеется, это не единственный подход к осмыслению user experience. Составляющие, включенные в данную схему, не существуют независимо – все они так или иначе пересекаются. Внешний вид зачастую побуждает потенциальных пользователей начать использовать продукт – так привлекательность влияет на доступность. Юзабилити, в свою очередь, влияет на привлекательность: если пользователь постоянно испытывает трудности в работе с программой, привлекательность продукта для него неизбежно снизится.
Для UX-специалистов очень важно понимать суть составляющих user experience. Уделяя внимание всем четырем аспектам взаимодействия пользователей с цифровыми продуктами, можно разработать решения, учитывающие все грани user experience как единое целое. Это важно не только с точки улучшения пользовательского опыта, но и с точки зрения влияния UX-стратегии на коммерческий успех.
Ключевым преимуществом данной модели является то, что в ней достижения в области user experience рассматриваются через призму их влияния на бизнес. Например, раньше UX-специалисты уделяли большое внимание юзабилити, не слишком задумываясь при этом о доступности – аспекте, с точки зрения коммерческого успеха еще более важном, чем юзабилити. В сравнении с остальными тремя составляющими пользовательского опыта юзабилити оказывает наименьшее влияние на бизнес, так как она связана с постоянным использованием продукта, в то время как остальные аспекты – с предоставлением доступа к продукту и тем, как побудить пользователей использовать продукт.
Другие модели, в отличие от представленной выше, не оценивают должным образом степень влияния различных составляющих пользовательского опыта на бизнес. Например, согласно схеме Питера Морвилля, все составляющие пользовательского опыта – легкость поиска, надежность, полезность, юзабилити, досягаемость и т. д. – важны в равной степени. Да, они действительно могут быть равны с точки зрения пользовательского опыта, но с точки зрения бизнес-результатов это далеко не так. В этом и заключается ключевая идея, заложенная в данной модели. Ее эффективное использование для оценки текущих достижений в области пользовательского опыта заслуживает отдельного обсуждения. Последствия применения этой модели для бизнеса будут рассматриваться в последующих статьях.
Источник
“Everything is best for something and worst for something else.
The trick is knowing for what, when, for whom, and why.” —Bill Buxton
The goals for these official Windows User Experience Interaction Guidelines for Windows® 7 and Windows Vista® (or «UX Guide» for short) are to:
●Establish a high quality and consistency baseline for all Windows-based applications.
●Answer your specific user experience questions.
●Make your job easier!
What’s new
The following guidelines have been added since our last update:
● Wizards
UX Guide is downloadable and printable!
By popular demand, we have UX Guide in PDF format.
Feedback
For technical support:
●For assistance with specific tasks, try Windows Help and How-to.
●For general help and support, go to Microsoft Help and Support.
Last updated September 29, 2010
© 2010, Microsoft Corporation. All rights reserved. |
Page 1 of 882 |
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Содержание
- User Experience Guidelines
- UI and user experience guidelines for ads
- General best practices
- Guidelines for banner ads
- Best practices
- Practices to avoid
- Examples of policy violations
- Guidelines for interstitial ads
- Best practices
- Practices to avoid
- Examples of policy violations
- Guidelines for native ads
- Register the container for your native ad
- Required native ad elements
- User experience
- Description
- Call to action
User Experience Guidelines
The primary responsibility of any Control Panel item is to display a window that allows the user to view and manipulate settings. See Control Panels user experience (UX) guidelines for the WindowsВ Vista for the behavior and design of Control Panel items. The guidelines discussed in that topic show a task flow method of organizing a Control Panel item. This places the most important settings on a home page. Less frequently used settings are placed on spoke pages or accessed from links in a side pane.
The WindowsВ Vista Control Panel includes many Control Panel items that follow these guidelines, such as Windows Update, Ease of Access Center, or Network and Sharing Center. Other Control Panel items use the tabbed dialog property sheet format as in earlier versions of Windows. Examples include the Mouse item and Internet Options. Use of the property sheet format should be discontinued. If you create new Control Panel items for WindowsВ Vista, you should follow the task flow guidelines.
In the past, Control Panel items were packaged as .cpl files. That is no longer necessary. New Control Panel items should be implemented as a standalone .exe file or as a command-line flag option for the application’s main executable file.
NoteВ В On 64-bit systems, 32-bit Control Panel items are displayed in the Control Panel when the View 32-bit Control Panel Items folder option is selected. The 32-bit items must be located in the %SystemRoot%SysWOW64 folder to be displayed. They do not require any further registration.
UI and user experience guidelines for ads
As of June 1, 2020, the Microsoft Ad Monetization platform for Windows UWP apps will be shut down. Learn more
This article provides guidelines for providing great experiences with banner ads, interstitial ads, and native ads in your apps. For general guidance about how to design the look and feel for apps, see Design & UI.
Any use of advertising in your app must comply with the Microsoft Store Policies – including, without limitation, policy 10.10 (Advertising Conduct and Content). In particular, your app’s implementation of banner ads or interstitial ads must meet the requirements in Microsoft Store policy policy 10.10.1. This article includes examples of implementations that would violate this policy. These examples are provided for informational purposes only, as a way to help you better understand the policy. These examples are not comprehensive, and there may be many other ways to violate the Microsoft Store Policies that are not listed in this article.
General best practices
Before reviewing our guidelines for different types of ads in this article, first review these general best practices to improve your ad revenue.
The following sections provide recommendations for how to implement banner ads in your app using AdControl and examples of implementations that violate policy 10.10.1 of the Microsoft Store Policies.
Best practices
We recommend that you follow these best practices when you implement banner ads in your app:
Use Interactive Advertising Bureau sizes that fit well with the layout for the device.
Devote most of your app’s UI to functional controls and content.
Design advertising into your experience. Give your designers a sample ad to plan how the advertising is going to look. Two examples of well-planned ads in apps are the ads-as-content layout and the split layout.
To see how different ad sizes will look and function within your app during the development and testing phase, you can utilize our test ad units. When you’re done with testing, remember to update your app with live ad units before submitting the app for certification.
Plan for times when no ads are available. There may be times when ads aren’t being sent to your app. Lay out your pages in such a way that they look great whether they showcase an ad or not. For more information, see Handle ad errors.
If you have a scenario for alerting the user that is best handled with an overlay, call AdControl.Suspend while displaying the overlay and then call AdControl.Resume when the alert scenario is finished.
Practices to avoid
We recommend that you avoid these practices when you implement banner ads in your app:
Don’t bolt advertising into open real estate. Ad space shouldn’t be placed into the first open piece of real estate you can find. Instead, it should be incorporated into your app’s overall design.
Don’t over-advertise and saturate your app. Too many ads in your app detract from its appearance and usability. You want to make money with advertising, but not at the expense of the app itself.
Don’t distract user from their core tasks. The primary focus should always be on the app. The ad space should be incorporated so it remains a secondary focus.
Examples of policy violations
This section provides examples of banner ad scenarios that violate policy 10.10.1 of the Microsoft Store Policies. These examples are provided for instructional purposes only, as a way to help you better understand the policy. These examples are not comprehensive, and there may be many other ways to violate policy 10.10.1 that are not listed here.
Doing anything to interfere with the user’s ability to view the banner ad, such as changing the opacity of the AdControl or placing another control on top of the AdControl (without first calling AdControl.Suspend).
Requiring users to click on a banner ad to accomplish a task in your app, or forcing users to click on banner ads as a result of the design of your app.
Bypassing the built-in minimum refresh timer for banner ads by any means, including (but not limited to) swapping AdControl objects or forcing a page refresh without user interaction.
Using live ad units (that is, ad units that you obtain from Partner Center) during development and testing, or in an emulator.
Writing or distributing code that calls ad services through means other than the Microsoft advertising libraries running in the context of your app.
Interacting with undocumented interfaces or child objects created by the Microsoft advertising libraries, such as WebView or MediaElement.
Placing ads in a viewbox to reduce the size of the ads in order to allow more ads on a page than normal.
Guidelines for interstitial ads
When used elegantly, interstitial ads can vastly increase your app revenue, without negatively impacting user satisfaction. When used improperly, such ads can have the exact opposite effect.
The following sections provide recommendations for how to implement interstitial video ads and interstitial banner ads in your app using InterstitialAd, and examples of implementations that violate policy 10.10.1 of the Microsoft Store Policies. Since you know your app better than anyone, except where policy is concerned, we leave it up to you to make the best final decision. What’s most important to keep in mind is that your app ratings and revenue are tightly coupled.
Best practices
We recommend that you follow these best practices when you implement interstitial ads in your app:
Fit interstitial ads within the natural flow of the app, such as between game levels.
Associate ads with tangible upsides, such as:
Hints towards level completion.
Extra time to retry a level.
Custom avatar features, like a tattoo or hat.
If your app requires that an interstitial video ad be watched to completion, mention that rule upfront so they aren’t surprised with an error message upon hitting the close button.
Pre-fetch the ad (by calling InterstitialAd.RequestAd) ideally 30-60 seconds before you need to show it.
Subscribe to all four events exposed in the InterstitialAd class (Canceled, Completed, AdReady, and ErrorOccurred) and use them to make the right decisions for your app.
Have some built-in experience to use in lieu of a server-matched ad. You’ll find this useful in a few scenarios:
Offline mode, when ad servers can’t be reached.
When the ErrorOccurred event fires.
If you opt to save user bandwidth based on ConnectionProfile, there are APIs in the ConnectionProfile class which can help.
Use the default (30 second) timeout unless you have a valid reason to do otherwise, in which case don’t go below 10 seconds. Interstitial ads take substantially longer to download than standard banner ads, especially in markets that don’t have high speed connections.
Be mindful of the user’s data plan. For example, either don’t show, or warn user, before serving an interstitial video ad on a mobile device that is near/over its data limit. There are APIs in the ConnectionProfile class which can help.
Continuously improve your app after the initial submission. Look at the ad reports and make design changes to improve fill and interstitial video completion rates.
Practices to avoid
We recommend that you avoid these practices when you implement interstitial ads in your app:
Don’t overdo it. Don’t force ads more than every 5 minutes or so, unless the user explicitly engages with an optional tangible benefit, beyond just playing the game.
Don’t show interstitials at app launch, since users may believe they clicked the wrong tile.
Don’t show interstitials at exit. This is bad inventory, since completion rates will be near zero.
Don’t show two or more interstitial ads back to back. Users will be frustrated to see the ad progress bar reset to the starting point. Many will think it’s just a coding or ad serving bug.
Don’t fetch an interstitial video ad more than 5 minutes before calling InterstitialAd.Show. Good inventory will maximize the conversion of pre-fetched ads to billable impressions.
Don’t penalize a user for failures in ad serving, such as no ad available. For example, if you show a UI option to “Watch an ad to get xxx”, you should provide xxx if the user did her part. Two options to consider:
Don’t include the option unless the InterstitialAd.AdReady event has fired.
Have the app include a built-in experience that yields the same benefit as a real ad.
Don’t use interstitial ads to let a user gain a competitive advantage in a multi-player game. For example, don’t entice the user with a better gun in a first-person shooter game if they view an interstitial ad. A custom shirt on the player’s avatar is fine, so long as it doesn’t provide camouflage!
Examples of policy violations
This section provides examples of interstitial ad scenarios that violate policy 10.10.1 of the Microsoft Store Policies. These examples are provided for instructional purposes only, as a way to help you better understand the policy. These examples are not comprehensive, and there may be many other ways to violate policy 10.10.1 that are not listed here.
Placing a UI element over the interstitial ad container.
Calling InterstitialAd.Show while the user is engaged with the app.
Using interstitial ads to obtain anything that may be consumed as a currency or traded with other users.
Requesting a new interstitial ad in the context of the event handler for the InterstitialAd.ErrorOccurred event. This can result in an infinite loop and can cause operational issues for the advertising service.
Requesting an interstitial ad merely to have a backup ad for a waterfall sequence of ads. If you request an interstitial ad and then receive the InterstitialAd.AdReady event, the next interstitial ad shown in your app must be the ad that is ready to be shown via the InterstitialAd.Show method.
Using live ad units (that is, ad units that you obtain from Partner Center) during development and testing, or in an emulator.
Writing or distributing code that calls ad services through means other than the Microsoft advertising libraries running in the context of your app.
Interacting with undocumented interfaces or child objects created by the Microsoft advertising libraries, such as WebView or MediaElement.
Guidelines for native ads
Native ads give you have a lot of control over how you present advertising content to your users. Follow these requirements and guidelines to help ensure that the advertiser’s message reaches your users while also helping to avoid delivering a confusing native ads experience to your users.
Register the container for your native ad
In your code, you must call the RegisterAdContainer method of the NativeAdV2 object to register the UI element that acts as a container for the native ad and optionally any specific controls that you want to register as clickable targets for the ad. This is required to properly track ad impressions and clicks.
There are two overloads for the RegisterAdContainer method that you can use:
If you want the entire container for all the individual native ad elements to be clickable, call the RegisterAdContainer(FrameworkElement) method and pass the container control to the method. For example, if you display all of the native ad elements in separate controls that are all hosted in a StackPanel and you want the entire StackPanel to be clickable, pass the StackPanel to this method.
If you want only certain native ad elements to be clickable, call the RegisterAdContainer(FrameworkElement, IVector(FrameworkElement)) method. Only the controls that you pass to the second parameter will be clickable.
At a minimum, you must always show the following native ad elements provided by properties of the NativeAdV2 object to the user in your native ad design. If you fail to include these elements, you may see poor performance and low yields for your ad unit.
- Always display the title of the native ad (available in the Title property). Provide enough space to display at least 25 characters. If the title is longer, replace the additional text with an ellipsis.
- Always display least one of the following elements to help differentiate the native ad experience from the rest of your app and clearly call out that the content is provided by an advertiser:
- The distinguishable ad icon (available in the AdIcon property). This icon is supplied by Microsoft.
- The sponsored by text (available in the SponsoredBy property). This text is supplied by the advertiser.
- As an alternative to the sponsored by text, you can choose to display some other text that helps differentiate the native ad experience from the rest of your app, such as «Sponsored content», «Promotional content», «Recommended content», etc.
User experience
Your native ad should be clearly delineated from the rest of your app and have space around it to prevent accidental clicks. Use borders, different backgrounds, or some other UI to separate the ad content from the rest of your app. Keep in mind that accidental ad clicks are not beneficial for your ad-based revenue or your end user experience in the long term.
Description
If you choose to show the description for the ad (available in the Description property of the NativeAdV2 object), provide enough space to display at least 75 characters. We recommend that you use an animation to show the full content of the ad description.
Call to action
The call to action text (available in the CallToAction property of the NativeAdV2 object) is a critical component of the ad. If you choose to show this text, follow these guidelines:
- Always display the call to action text to the user on a clickable control such as a button or hyperlink.
- Always display the call to action text in its entirety.
- Ensure that that the call to action text is separated from the rest of the promotional text from the advertiser.
—>
#1
PAUK
-
- Posters
- 3 236 Сообщений:
Guru
Отправлено 23 Октябрь 2010 — 16:17
Руководство по созданию пользовательских интерфейсов для Windows 7
«Microsoft выпустила официальное руководство, в котором подробно описываются принципы построения пользовательских приложений и интерфейсов для Windows 7. Руководство очень большое – 882 страницы, на которых приводятся советы, рассматриваются конкретные примеры, даются рекомендации.
Всего руководство разделено на 10 больших разделов:
•принципы дизайна;
•элементы управления;
•команды (горячие клавиши, меню и прочее);
•текст и его стили;
•сообщения: предупреждения, об ошибках, уведомления;
•взаимодействие пользователя: клавиатура, мыши, сенсоры, доступ для людей с ограничениями;
•окна;
•визуальные элементы: иконки, компоновка, шрифты, цвета и другое;
•пользовательский опыт;
•окружение Windows.
Загрузить Windows User Experience Interaction Guidelines в формате .pdf можно по этой ссылке.»
EN, 46,4Мб
Может кому пригодится.
«объективность» – понятие глубоко субъективное
— Мы здесь все сумасшедшие. Я сумасшедший. Ты сумасшедшая.
— Откуда вы знаете, что я сумасшедшая? — спросила Алиса.
— Ты безусловно должна быть сумасшедшей, — ответил Кот, — иначе ты не попала-бы сюда.
- Наверх
От издателя:
О чем эта книга?
О том, как начать свой бизнес. Если хотите — параллельно с основной работой. И о том, как усовершенствовать ваш имеющийся бизнес, а точнее — ваши взгляды на него. С тем, чтобы обрести невиданную ранее степень свободы.
Книга «Rework» от 37signals — это логичное продолжение предыдущей книги «Getting Real». Она предлагает читателю всё те же принципы и концепции, но с той лишь разницей, что теперь Rework говорит с нами на языке бизнеса, а не на языке веб-разработчика. В этом смысле книга рассчитана на более широкую аудиторию.
Книга Rework — это книга, несущая мощный мотивирующий заряд энергии, способный подтолкнуть читателя к старту своего собственного дела. Она вселяет в людей веру в свои собственные силы и дает практическое обоснование возможности реализации любой коммерческой мечты.
От авторов:
Сегодня каждый может заниматься бизнесом.
Недосягаемые ранее инструменты легко доступны, дорогостоящей технологией можно воспользоваться, заплатив пару долларов или вообще бесплатно. Один человек способен выполнять работу двоих, троих, а в некоторых случаях и целого отдела.
Вам не нужно работать 100 часов в неделю — 40 часов достаточно.
Вам не нужно тратить свои накопления, или брать на себя чрезмерные риски.
Вам даже не нужен офис. Сегодня вы можете работать из дома, или взаимодействовать с людьми, с которыми вы никогда не встречались, и которые живут в тысячах километрах от вас.
Время Rework. Давайте начнем.
Книгу можно прочитать за один вечер. Рекомендую всем.
Купить оригинал — Купить перевод — Купить электронную версию/читать онлайн на русском
Об авторах
Авторы книги — сотрудники небольшой компании 37signals: Джейсон Фрид (Jason Fried), Дэвид Хейнемайер Хансон (David Heinemeier Hansson).
Стандартный
От издателя:
Когда в 1995 году увидело свет первое издание «About Face», идея проектировать продукты исходя из целей людей казалась революционной. Благодаря работам Алана Купера и других первопроходцев, проектирование взаимодействия получило сегодня широкое признание как уникальная и крайне важная дисциплина, однако эта работа далека от завершения.
Авторы полностью обновленного издания, признанные мировые эксперты в вопросах создания интерфейсов, детально описывают разработанный в компании Cooper и примененный во множестве проектов целостный подход к проектированию взаимодействия, ориентированный на цели пользователя. Отличительной чертой книги является ее практическая направленность — значительную часть издания занимает подробный разбор принципов и шаблонов проектирования взаимодействия. Большое внимание уделено новым информационным средам: веб-приложениям, мобильным приложениям, киоскам и т. п.
Книга адресована всем специалистам, по роду деятельности соприкасающимся с процессом создания цифровых продуктов. Проектировщикам взаимодействия и дизайнерам интерфейсов она послужит настольным справочником по организации процесса и повседневным подручным инструментарием.
Монументальная книга в 600 страниц. Библия проектировщика. Книга-справочник, книга-учебник, книга-руководство, книга-философия, книга-методика.
Концентрация полезной информации на один абзац текста просто зашкаливает. Иногда приходится перечитывать некоторые главы по несколько раз, чтобы до конца понять и впитать опыт западных коллег из компании Cooper.
Эта книга посвящена проектированию взаимодействия — практике создания цифровых интерактивных продуктов, сред, систем и служб и проектированию поведения, в частности. В ней описывается конкретный подход к проектированию взаимодействия получивший название «Целеориентированный метод» (Goal-Directed Design, © Alan Cooper), при котором акцент ставится на первоначальных мотивах использования продукта людьми, а также учитываются их ожидания, опыт и способности, — все то, что помогает находить решения, которые люди находят мощными и приятными.
От начала и до конца книги авторы старались более наглядно рассказывать о концепциях, методах и проблемах визуальной части пользовательских интерфейсов, а также о проблемах, возникающих за пределами настольных компьютеров.
В третьем издании сохранено все, что не потеряло актуальности, обновлено то, что изменилось с тех пор, и содержит новые материалы, отражающие не только изменения в отрасли за последние одиннадцать лет, но также и появление новых концепций, созданных авторами с учётом меняющихся требований времени.
— Русскоязычный сайт, посвященный переводу книги на русский язык.
С уверенностью можно сказать, что книгу Алана Купера «Об интерфейсе» стоит перечитывать регулярно, а также держать на рабочем столе в качестве всеобъемлющего справочника.
Купить — Скачать — Содержание и некоторые главы книги
Об авторе
Алан Купер (Alan Kooper)
Руководитель дизайнерской компании, автор книг о том, как сделать программное обеспечение пользовательских интерфейсов более удобным.
Купера иногда называют отцом «Visual Basic», хотя большая часть работы по «Visual Basic» была сделана группой внутреннего развития компании «Microsoft». Купер был ведущей силой за VB 1.0 и инициатором использования IDE для создания GUI через обращение к системе в API.
Оригинальные программы Купера были названы «Tripod», а позднее «Ruby». Они были предназначены как инструмент конечного пользователя, но развитие в «Microsoft» привело к тому, что «Visual Basic» стал инструментом для программистов.
К выдающимся работам Алана Купера можно отнести «Основы проектирования взаимодействия» и «Психбольница в руках пациентов».
Стандартный
От издателя:
Книга эта непростая и подойдет не каждому. Автор анализирует то, к чему мы все давно привыкли до автоматизма, и объясняет, что интерфейс многих современных программ далек от совершенства. Как его улучшить, в каком направлении двигаться дальше? Попробуйте найти ответы вместе с самым известным специалистом в этой области — Джефом Раскиным, создателя проекта Apple Macintosh.
Сейчас много говорят об эффективности современных подходов к разработке интерфейсов. Раскин же демонстрирует, что многие из них ведут в тупик, и для создания компьютеров, с которыми было бы проще работать, требуются совершенно новые принципы разработки. Он объясняет, как осуществить эти необходимые сегодня изменения, и высказывает нестандартные идеи, демонстрируя дальновидность и способность к практическому взгляду на вещи.
Эта книга, рассказывающая о научном подходе к разработке интерфейсов, может быть полезна как для создателей программного обеспечения, так и для руководителей проектов.
Книга Джефа Раскина «Интерфейс» — реальный хардкор. Автор рассматривает интерфейсы сквозь призму как программного обеспечения, так и аппаратного.
В это области редко когда встречается глубокий подход к делу. Напротив, большинство компаний с радостью копируют те конструкции интерфейсов, которые считались удачными в 70-егоды. Книга «Интерфейс: новые направления в проектировании компьютерных систем» — это изысканное блюдо от шеф-повара. На пять с плюсом!
— Якоб Нильсен (Jacob Nielsen)
Эту книгу можно условно назвать «Как я сделал компьютер Canon Cat», поскольку большинство примеров и рассуждений строится именно на этом личном опыте автора. Но, не смотря на это, книга заставляет задуматься об направлении, в котором должен действовать каждый проектировщик интерфейсах, о границах его полномочий и ответственности.
Если вы хотите поближе познакомиться с образом мышления и методологией работы настоящего профессионала в области создания интерфейсов, то для вас эта книга обязательна к прочтению.
Читать онлайн — Купить
Об авторе
Джеф Раскин
Независимый консультант по разработке компьютерных интерфейсов и систем (www.jefraskin.com). Он изобрел компьютеры Apple Macintosh и Canon Cat. Среди его клиентов такие транснациональные компании, как Hewlett-Packard, IBM, Motorola, NCR, Xerox, Ricoh, Canon, McKesson и AT&T. Он опубликовал свыше 500 статей в более чем 40 периодических изданиях, таких как Wired, Forbes ASAP, IEEE Spectrum, Nature, Quantum. Раскин преподавал в Калифорнийском, Стэндфордском университетах и других учебных заведениях. Он часто вел семинары, выступал по радио и телевидению и участвовал в большом количестве конференций.
Стандартный
Сногсшибательно и очень полезно. После прочтения этой книги вы уже никогда не станете прежними.
Книга «Getting Real» была написана по мотивам записей в блоге компании 37signals и за короткое время стала не только бестселлером, но и положила начало целой методологии и культа в сфере разработки веб-приложений.
Среди прочего, в книге рассматривается вопрос проектирования интерфейсов, его роль, место и значение в общем процессе создания качественного продукта.
Дизайн от эпицентра фокусирует внимание на том, что наиболее важно на странице, а затем обращается к менее важному. Это значит, что сначала вы игнорируете то что находится кругом — навигацию, закладки, «подвал» страницы, цвета, логотип и так далее. Вместо этого, вы начинаете с эпицентра и сначала разрабатываете наиболее важную часть страницы.
— Глава 9. «Создание интерфейса»
Мотивирующие тезисы изложены в очень простой и сильной форме.
Getting Real — это отказ от вещей, представляющих реальность (диаграммы, графики, схемы, стрелочки и модели) и создание реальной вещи.
Getting Real — это значит «меньше». Меньше массы, меньше программного обеспечения и его возможностей, меньше бумагомарания — словом, меньше всего того, что является несущественным (а большая часть того, что, как вам кажется, критически важно, на самом деле таковым не является).
Getting Real значит оставаться небольшим и шустрым.
Getting Real начинает с интерфейса, с реальных экранов, которыми будут пользоваться ваши клиенты. Это позволяет получить правильный интерфейс до того, как вы создадите неправильную программу.
Getting Real — это итерации и снижение стоимости изменений.
Getting Real — это запуск и постоянное улучшение. То есть подход, идеальный для веб-приложений.
Getting Real — это создание того, в чём нуждается клиент и исключение того, что ему не нужно.
Книга обязательна к прочтению любому разработчику ПО, вне зависимости от специализации.
Читать книгу онлайн
Об авторах
Авторы книги — сотрудники небольшой компании 37signals: Джейсон Фрид (Jason Fried), Дэвид Хейнемайер Хансон (David Heinemeier Hansson), Мэтью Линдерман (Matthew Linderman).
Стандартный
Еще хуже дело со словом «юзверь». Скажу искренно — если вы его употребляете, вы никогда не сможете сделать хорошего интерфейса. С вами уже всё кончено; ваше сознание безнадежно ущербно. Если на этом месте вы почувствовали горячее желание меня переубедить и доказать мне, что слово «юзверь» вполне приемлемо, воздержитесь.
Онлайн-книга Влада Головача «Дизайн пользовательского интерфейса: искусство мыть слона» относится к числу редких отечественных книг по этой тематике.
В категоричной и оригинальной манере изложения автор пытается научить своего читателя проектной деятельности (дизайну интерфейсов), попутно рассматривая различные методики, эвристики поведения дизайнеров, собственные наработки и многолетний опыт.
По структуре изложения книга представляет собой набор тезисов, обрамленных дополнительными и иллюстрирующими материалами. Вот эти тезисы:
- Ничего готового нету; готовыми вещи становятся вынужденно.
- День, когда вы только добавили что-то хорошее, но не исправили что-то плохое, — потерянный день.
- Всё недостаточно хорошее — плохое. Поскольку улучшить можно всё, всё — плохо.
- Записывайте всё, в частности, совершенные вами ошибки. Нет лучшей гарантии, что вы их не повторите.
- Планируйте как можно меньше, начинайте проектировать интерфейс как можно раньше, зато переделывайте почаще.
- Перед тем, как приступать к работе, узнайте, что хуже всего сейчас и начните с решения именно этой проблемы.
- Если вы не превращаете свои знания в конкретные проектные шаги — это бесполезные знания.
- Не задавайтесь общими, принципиальными проблемами, пока вы хотя бы трижды не нашли их частное решение.
- Занимайтесь только той оптимизацией интерфейса, которая улучшает продукт.
- Лучше принести заказчику приятный сюрприз, чем неприятное открытие.
- Не менее трети всех интерфейсных решений либо работают гораздо хуже ожидаемого, либо вообще неработоспособны.
- Повесьте перед своим рабочим местом табличку «В моих интерфейсах есть проблемы, о которых я ничего не знаю».
- Без тестирования сделать действительно хороший интерфейс можно только случайно и только если интерфейс маленький.
- Интерфейс хорош, если он:
- «удобный», «простой» и «юзаб(и)(e)льный»;
- обладает высокими эргономическими показателями;
- оптимизирован под своих пользователей;
- оптимизирован под задачи пользователей;
- оптимизирован под мотивы пользователей;
- обладает высокими показателями юзабилити;
- адекватен деятельности пользователей;
- коммерчески успешен.
- Полезно составить список мотивов целевых пользователей и просто сравнить их со списком задач. Даже это помогает лучше оценить адекватность и полноту списка задач.
- Хороший интерфейс — это сексуальный интерфейс. Сексуальный интерфейс — это интерфейс, который хочется иметь.
- Проверяйте на оправданность все интерфейсные операции, удаляйте необязательные и исправляйте слишком уж трудоемкие.
- Вы делаете довольным заказчика, для чего вам нужно сделать хороший интерфейс для пользователей.
В заключение автор приводит небезынтересный с практической точки зрения список из 8 вопросов, которыми должен задаваться проектировщик все время работы над проектом:
- Можно ли ускорить взаимодействие пользователя с этим интерфейсом?
- Где в этом интерфейсе места, которые могут продуцировать человеческие ошибки? Можно ли изменить эти фрагменты?
- Что в этом интерфейсе не способствует обучению? Что пользователю нужно знать, чтобы успешно взаимодействовать с этим интерфейсом? Есть ли в этом перечне что-то, чего сам интерфейс не сообщает пользователю? Эти три вопроса нужно задавать себе по очереди. Если после ответов видно, что интерфейс надо менять, остальные вопросы нужно задать себе снова после переделки. Если на все три вопроса удалось дать отрицательный ответ, переходим к следующей порции вопросов из остальных концепций качества:
- Известно ли мне о пользователях что-нибудь, что делает этот интерфейс плохим?
- Удовлетворяет ли этот интерфейс все известные мне мотивы пользователей?
- Совместим ли этот интерфейс со средой, в которой работают пользователи?Если и по этим вопросам всё хорошо, переходим к проверке, как выполняются в интерфейсе задачи пользователей.
- Соответственно, этот вопрос звучит как «Есть ли задачи, которые неэффективно отрабатываются интерфейсом?». Как правило, достаточно проговорить вслух (а ещё лучше написать), как в этом интерфейсе пользователь выполняет все свои задачи (лучше всего писать о себе, а не о абстрактном пользователе, например «Из меню Документ я открываю окно настроек зета-преобразования, ввожу значение 40 в поле Количество человеков, затем открываю…»). Как правило, такая проверка выявляет множество несоответствий или попросту пропущенных кусков. Если это произошло, возвращаемся к самому первому вопросу. Если нет, задаем себе последний вопрос:
- Сексуален ли этот интерфейс и можно ли его сделать ещё сексуальнее?
Эту книгу можно смело рекомендовать всем тем, кто только начинает разбираться в вопросах проектирования интерфейсов. В ней изложены не только основы профессии, но и принципы человеческого отношения к этому делу. Кроме этого, книга будет чрезвычайно полезна списком литературы для самостоятельного изучения, который расположен в самом конце.
Для профессионалов интерес представляют анализ существующих стандартов, методология и оригинальный авторский взгляд умудренного опытом человека.
Скачать или читать онлайн
Об авторе
Влад Головач
Вместе с Александром Белышкиным основал Usethics, первую в России юзабилити-компанию. По всей видимости, спроектировал больше интерфейсов, чем кто-либо другой в России (и руководил разработкой ещё большего числа интерфейсов). Автор первой оригинальной русскоязычной книги о дизайне программных интерфейсов (более недоступна; это её вторая, полностью переработанная версия).
Стандартный
От издателя:
Как противостоять натиску компьютерных технологий, проникающих в нашу жизнь с ужасающей скоростью? Наши телефоны, фотокамеры, автомобили — все, что нас окружает, автоматизируются, программируются, создаются людьми, которые, стремясь получить выгоду от применения микросхем, уклонились от своей прямой обязанности — делать эти продукты простыми в применении.
И это не преувеличение, это реальность. Наша жизнь все больше концентрируется вокруг превратностей, странностей, решений и катастроф индустрии высоких технологий. Разработчики программ, устройств и технологий думают не так, как мы. Облеченные полномочиями исполнительные лица ни на что не влияют в мире высоких технологий — здесь всем заправляют инженеры. Мы разрешили пациентам завладеть психбольницей. Алан Купер предлагает решение проблемы: программированию должно предшествовать проектирование.
Картинка взята отсюда: http://store.artlebedev.ru/books/lebedevs-choice/cooper/
Книга Алана Купера «Психбольница в руках пациентов» одна из тех, что может навсегда изменить ваше представление об окружающем мире. Я бы поставил ее в один ряд с книгой Джима Кемпа «Сначала скажите НЕТ», Алана Карра «Легкий способ бросить курить», Роберта Чалдини «Психология влияния» и другими не менее знаковыми книгами в моей жизни.
Основное предназначение книги — дать бизнес-обоснование необходимости проектирования взаимодействия на самых ранних этапах создания программных продуктов. Автор не только описывает всеобщее сумасшествие, которое творится в мире разработки ПО, но и предлагает излечение от этой болезни. Книга задумана как мотиватор, заставляющий разработчиков всех мастей изменить сложившуюся ситуацию к лучшему.
В книге нет скучных и монотонных описаний алгоритмов или рецептов на все случаи жизни. Она не научит вас проектировать интерфейсы. В этой книге автор легко и иронично наведет порядок в вашей голове, расставит все по полочкам, озвучит то, что вы и так давно чувствуете подкоркой мозга, но не можете высказать.
Благодаря доступной манере изложения и отсутствию лишней зауми книгу можно прочитать за один весьма приятный вечер.
Несмотря на то, что книга была написана десять лет назад в Америке, она как никогда актуальная для современной России и, в частности, Сибири.
Позволю себе привести пару цитат:
На мой взгляд, существует два типа руководителей: инженеры и запуганные инженерами. Первые множат знакомые проблемы, поскольку их точка зрения безнадежно испорчена конфликтом интересов. Вторые множат проблемы, поскольку не умеют говорить на языке программистов. И я не имею в виду языки Java и С#. Я имею в виду, что у деловых людей и программистов нет общих инструментов и общих целей. Человек разумный делегирует человеческие проблемы хомо логикус, не осознавая, что решение могло бы оказаться намного более приятным в случае применения — на исполнительном уровне — уместных финансовых и организационных моделей.
…
В качестве отступного разработчики программного обеспечения всегда выражают готовность изучать проектирование. Меня постоянно просят «научить проектировать». Я приветствую такую открытость, но не верю в эффективность такого подхода. Любой разработчик программного обеспечения, достаточно квалифицированный, чтобы называться профессионалом, слишком погружен в буквальную и детерминированную сущность кремниевой логики. Слишком сильно погружен, чтобы достичь параллельно схожей эффективности в иррациональном, непредсказуемом, переполненном эмоциями мире людей. Я не хочу сказать, что программист неспособен стать проектировщиком, я лишь пытаюсь сказать, что практически невозможно делать то и другое хорошо одновременно.
…
Я обнаружила, что подкуп гораздо эффективнее уговоров. В основном использовала шоколад. Подкуп действовал настолько хорошо, что однажды руководитель группы, пав на колени, публично извинялся передо мной, что забыл уведомить об изменениях в продукте. (Да, свое угощение он все равно получил.) В одной компании пристрастившийся к шоколаду инженер рассказывал мне обо всех изменениях, внесенных его коллегами, чтобы получить и их шоколад. До открытия такого способа подкупа я потратила массу времени сверхурочно, пытаясь выяснить, каким образом изменился продукт. Подкуп же позволил сократить сверхурочную работу раза в два.
В заключение хочется отметить, что некоторые интерфейсные решения, предложенные несколько лет назад Купером в этой книге в качестве простых примеров, относительно недавно были воплощены во множестве продуктов. Например, связанные цепочки писем в популярных почтовых программах и веб-сервисах.
Купить — Скачать — Читать онлайн
Об авторе
Алан Купер (Alan Kooper)
Руководитель дизайнерской компании, автор книг о том, как сделать программное обеспечение пользовательских интерфейсов более удобным.
Купера иногда называют отцом «Visual Basic», хотя большая часть работы по «Visual Basic» была сделана группой внутреннего развития компании «Microsoft». Купер был ведущей силой за VB 1.0 и инициатором использования IDE для создания GUI через обращение к системе в API.
Оригинальные программы Купера были названы «Tripod», а позднее «Ruby». Они были предназначены как инструмент конечного пользователя, но развитие в «Microsoft» привело к тому, что «Visual Basic» стал инструментом для программистов.
К выдающимся работам Алана Купера можно отнести «Основы проектирования взаимодействия» и «Психбольница в руках пациентов».
Стандартный