Про модельеров выше верно подметили. Занимаясь дизайном интерфейсов 10 лет, я вижу как ui/ux дизайнеры на ресурсах Dribble, Behance и т.п. потихоньку ушли от пользовательских реалий и потребностей в сторону «Вау!» эффекта. Печально то, что глядя на это «Вау!», клиенты думают, что так и должен выглядеть их UI. В топе 9 из 10 работ — бутафория и концепты, это порождает моду, подиумы, показы, часто забывая о физике и людях. Так же это убило конкуренцию стилей. Минимализм стал править везде (хотя все опросы говорят о том, что нравится он далеко не всем)
ИМХО концепты тоже важны, но Дизайнер, это в первую очередь инженер, а уже потом картинки, анимации и прочее.
Хм… Интересно, можно ли установить в существующие автомобильные глушители это?
Если да и заработает, я бы хотел, чтобы такое в обязательном порядке на все мотоциклы поставили.
(живу с окнами на дорогу)
этот код был написан несколькими годами ранее сторонней компанией, и никто в Microsoft никогда не понимал, как он работает (ещё меньше до сих пор это понимают), и бóльшая часть кода была полностью без комментариев. Поэтому мы просто не могли понять, почему детектор столкновений не работает. Чёрт, мы даже не могли найти детектор столкновений!
Кстати я бы тоже посмотрел на код игрушек MS, пусть даже бы и только новых, последний сапер на UWP был неплох.
Вот я бы и правда хотел иметь Windows-совместимую ОС, которая не жрёт тонну памяти, не занимает по 30 гигов из коробки и не решает за меня, когда ей обновиться на новую версию с нескучными обоями.
Боюсь, это утопия. Если реакт будет гнаться именно за совместимостью с Windows ПО, то в итоге они превратятся в еще большего монстра. Т.к. все без исключения Windows компоненты используются в каком-нибудь ПО под эту ОС.
К слову о «нескучных обоях», этот пост начался с показа именно «красивой анимации загрузочного экрана», ничего не утверждаю, просто как бы намекаю, что React тоже, несмотря на пласт других проблем, хочет, чтобы в продукте было «нескучно»
Согласен, возможно, я погорячился, от части потому, что статья «пестрит» картинками, которые ну уж совсем очевидно с плохими кнопками дизайна 90х.
Я согласен с тем, что важные кнопки должны быть заметнее.
Но всё же, я считаю, что обсуждать дизайн кнопок в отрыве от контекста, контента и дизайна страницы в целом — неверно.
Всё слишком индивидуально. В прикреплённом мной скриншоте — нельзя утверждать что кнопки (необъемные, не в форме кнопки, синим текстом, без выделение главной и «фантомной») — плохие. На черном фоне под большим белым текстом в 3 строки, наоборот они яркие, заметные, их всего 2 и они суперпонятны.
Вообще — любой пользователь кликнет «купить» вне зависимости от вида кнопки, если товар его устраивает. Никакие скругленные углы на кнопках не спасут от убогой картинки товара, от высокой цены, от плохого описания, и прочих более важных факторов. В дизайне — самое важное это контент, и это нигде не упоминается в статье. Порой даже надпись на кнопке — важнее внешнего вида кнопки (т.к. надпись — это контент кнопки)
Представьте, что вы звоните по какому-то вопросу в колл-центр банка и получаете один ответ.
Действительно, хотелось бы, чтобы я звонил в колл-центр банка и получал ОДИН ответ, а не отфутболивание от одного «специалиста» к другому по кругу, где у каждого свое мнение насчет моего вопроса.
Никогда не понимал, что вообще мешает реализовать конференцию разговора с несколькими специалистами одновременно, дабы я не повторял информацию сказанную минуту назад еще раз? Это же супер-удобно, когда ты просто слушаешь, как к проблеме подключаются новые люди, обсуждают твою проблему и РЕШАЮТ! её сообща. А ты, слушая их диалог, дополняешь информацией по необходимости. Удобно — да. И что важно — по человечески, а не превращая call-центр в роботов, где все друг друга ненавидят.
А, да, и при обрыве связи, хочу чтобы меня возвращало к тому, с кем я только что говорил (например код специалиста в смс приходил, чтобы напрямую звонить, актуально не только для обрыва связи, а при необходимости донесения данных например, либо повторении проблемы), а не заставляло проходить всю цепочку «девочек» до нужного спеца, заново объясняя подробности.
Люблю читать про различные узкие направления в IT.
В Яндексе на каждом сервисе свой UX-редактор? Если так, то здорово наверно под рукой иметь армию коллег по цеху.
Проблема «Фрилансим», изначально была в том, что он не был создан ни для заказчиков, ни для фрилансеров. Администрация создала его «для себя» и так как видела его сама. Если бы в самом начале была собрана статистика, были опрошены люди занимающиеся фрилансом уже давно (и люди, давно работающие с фрилансерами) им стало бы ясно, что в действительности нужно пользователям. Тогда бы проект расцвел, ведь время старта было выбрано самое удачное — кризис на топовом Fl… там творилась полная вакханалия, и можно было просто буквально за пару месяцев слить всех его пользователей себе, дав им именно то что они хотели и о чем 100500 раз писали в блогах и комментариях. И монетизировать проект нужно было позже, а не сразу вводить «Фантики» чтобы «стричь». Но, к сожалению, проблемы фрилансеров, так и небыли решены, а сегодня уже поздно. Люди приспособились.
Думаю проблема в том, что среди создателей, просто нет фрилансеров, поэтому они и биржу свою толком протестировать не могут на жизнеспособность.
Могу лишь подтвердить фактом: уже 7 лет пишем различное ПО на WPF (в основном субподряд на интеграцию дизайна, но и под ключ решения тоже), и в последний год со стороны заказчиков крупного корпоративного сектора интерес большой к технологии, как никогда.
Уточните пожалуйста дату окончания приема заявок.
— тут указано 21 апреля
— на сайте регистрации: events.techdays.ru/MAAC/2014-04
28 апреля.
— в документе что скачивали после регистрации, вообще 25 марта
Кому верить?
Вы меня неправильно поняли.
Я имел ввиду создание дизайна в целом, а не только его реализацию в XAML.
Да, все простые элементы с несложным дизайном (кнопки, текстовые блоки, списки и т.п). — бленд для них идеален и с ними все просто, И тут без разницы, где работал дизайнер, я как интегратор повторю все так же в бленде. Мы тут как раз о звездочках и прочих свистелках говорим и о быстрой сборке сложных дизайнов, и о взаимодействии дизайнера с интегратором.
Если дизайнер рисует в AI например, то, чтобы выдрать от туда звездочку-шестеренку, нужно сначала подготовить исходник, а потом как-то экспортировать нужные элементы, потом вставить в бленд, потом причесать XAML(+ресурсы выставить, адаптивность и пр..)
Inkscape позволяет просто открыть исходник как он есть — > Ctrl+ C — > Ctrl+V в бленд, где уже подготовлено все для вставки этой шестеренки., те я выкинул 2 промежуточных шага. При реализации больших проектов и сложных интерфейсов, это существенно
Это верно, когда первый раз видишь Path и примеры от майкрософт, первый вопрос — а как нарисовать что-то свое, на который нет ответа нигде, в примерах уже готовые объекты, Blend — не для рисования, Expression Disign — убог и поддерживает только Canvas и при экспорте — простите, говнокод, а графика как правило — адаптивная.
Мы даже думали над собственным редактором Path на панелях компоновки WPF, но сделать его — полбеды, как на него пересадить дизайнеров и научить работать хотя бы только с цветовыми ресурсами — вот где проблема, а иначе так же как и с Inkscape и Svg2Xaml половину кода руками переписывать.
Inkscape конечно решает большинство проблем, но не все, кое какие рутинные операции приходиться делать вручную. И все же он в разы облегчил работу над исходником дизайна, по крайней мере, там нельзя нарисовать того, чего нельзя «зазамлить» в WPF
У нас сейчас основная проблема, то что в XAML Windows 8 многого, что было раньше, просто нет. Нет триггеров, нет радиальных градиентов, опций рендара… Вот и приходиться иногда извращаться комбинируя растровые объекты с векторными. НО опять же Win8 в плане производительности на пару порядков выше и «мыла» в ней меньше чем в WPF.
Svg2Xaml штука все же глючная. В итоге я руками быстрее и качественнее все перевожу, кисти в любом случае в ресурсах, поэтому они мне как правило не нужны, и там проблема с группировкой объектов, из чего вытекает что SVG сначала нужно «подготовить» к экспорту, потом утилита, потом правки в XAML, я же работаю напрямую с исходником и кодом обновременно, поэтому лично для меня мой путь проще.
Совет
InkSkape может координаты представлять как в относительных, так и в «прямых» точках
первые начинаются с маленькой «m» вторые с большой «M», по умолчанию все в относительных, XAML с ними работает, но к сожалению иногда криво, чтобы перевести в «прямые» — выделяем объект и жмем в InkSkape CTRL + "+" — эта комбинация для объединения объектов, но так же она преобразовывает координаты если объект один.
А вообще в настройках выставляем не использовать относительные координаты и радуемся жизни.
Спасибо, статья отличная.
Сам давно занимаюсь интеграцией дизайна в XAML, все это уже пройденный этап.
От себя хочу добавить несколько моментов:
1) Использовать рендеринг текста Display — нужно очень аккуратно, тк в этом случае отключается рендер текста и контейнера, где он лежит, видеокартой, что приводит к глюкам и иногда еще большим артефактам чем размытие. Зачастую эффект плавающий.
2) Мы сейчас почти полностью отказались от растровой графики как таковой в XAML интерфейсах.
большинство иконок и графики рисуем в InkSkape и портируем графику и иконки прямо в XAML(объекты Path)
Почему InkSkape — потому что его родной формат SVG, он почти идентичен XAML и InkSkape позволяет рисовать вектор, привязываясь к пикселям сразу — для этого жмем Shift+«3» и видим пиксельную сетку, далее можно включить все привязки. тем самым никогда не попадаем на «полпикселя»
Ну и самый главный лайвхак — в InkSkape есть встроенный XML-Editor (Shift+Ctrl+X) — там просто копируем координаты объектов и вставляем в Data у Path в XAML.
Плоские иконки так делать пара пустяков и благодаря целочисленным координатам они всегда встают идеально в WPF, но можно делать очень сложную, и даже игровую графику, по сути полностью копируя стопку объектов в XAML, но там отдельной статьи материал о том как это делать эффективно.
Чтобы не быть голословным вот видео проекта что у меня сейчас в разработке, вся графика рисовалась в InkSkape и потом XML-Editor + прямыми руками вставлялась в проект и анимировалась. В проекте все векторное на 95%
Вопрос по теме монетизации.
У нас InApp покупки, скоро новый год, можно как-то в центре разработки реализовать скидку на праздник?
Ели просто понизить цену на пакет на время праздника а потом поднять обратно, не будет ли проблем с балансом в минус, как было описано в конце этой статьи habrahabr.ru/company/microsoft/blog/197798/?
ИМХО концепты тоже важны, но Дизайнер, это в первую очередь инженер, а уже потом картинки, анимации и прочее.
Если да и заработает, я бы хотел, чтобы такое в обязательном порядке на все мотоциклы поставили.
(живу с окнами на дорогу)
Кстати я бы тоже посмотрел на код игрушек MS, пусть даже бы и только новых, последний сапер на UWP был неплох.
Боюсь, это утопия. Если реакт будет гнаться именно за совместимостью с Windows ПО, то в итоге они превратятся в еще большего монстра. Т.к. все без исключения Windows компоненты используются в каком-нибудь ПО под эту ОС.
К слову о «нескучных обоях», этот пост начался с показа именно «красивой анимации загрузочного экрана», ничего не утверждаю, просто как бы намекаю, что React тоже, несмотря на пласт других проблем, хочет, чтобы в продукте было «нескучно»
Я согласен с тем, что важные кнопки должны быть заметнее.
Но всё же, я считаю, что обсуждать дизайн кнопок в отрыве от контекста, контента и дизайна страницы в целом — неверно.
Всё слишком индивидуально. В прикреплённом мной скриншоте — нельзя утверждать что кнопки (необъемные, не в форме кнопки, синим текстом, без выделение главной и «фантомной») — плохие. На черном фоне под большим белым текстом в 3 строки, наоборот они яркие, заметные, их всего 2 и они суперпонятны.
Вообще — любой пользователь кликнет «купить» вне зависимости от вида кнопки, если товар его устраивает. Никакие скругленные углы на кнопках не спасут от убогой картинки товара, от высокой цены, от плохого описания, и прочих более важных факторов. В дизайне — самое важное это контент, и это нигде не упоминается в статье. Порой даже надпись на кнопке — важнее внешнего вида кнопки (т.к. надпись — это контент кнопки)
Всё абсолютно обратно сказанному в статье )
Действительно, хотелось бы, чтобы я звонил в колл-центр банка и получал ОДИН ответ, а не отфутболивание от одного «специалиста» к другому по кругу, где у каждого свое мнение насчет моего вопроса.
Никогда не понимал, что вообще мешает реализовать конференцию разговора с несколькими специалистами одновременно, дабы я не повторял информацию сказанную минуту назад еще раз? Это же супер-удобно, когда ты просто слушаешь, как к проблеме подключаются новые люди, обсуждают твою проблему и РЕШАЮТ! её сообща. А ты, слушая их диалог, дополняешь информацией по необходимости. Удобно — да. И что важно — по человечески, а не превращая call-центр в роботов, где все друг друга ненавидят.
А, да, и при обрыве связи, хочу чтобы меня возвращало к тому, с кем я только что говорил (например код специалиста в смс приходил, чтобы напрямую звонить, актуально не только для обрыва связи, а при необходимости донесения данных например, либо повторении проблемы), а не заставляло проходить всю цепочку «девочек» до нужного спеца, заново объясняя подробности.
В Яндексе на каждом сервисе свой UX-редактор? Если так, то здорово наверно под рукой иметь армию коллег по цеху.
Думаю проблема в том, что среди создателей, просто нет фрилансеров, поэтому они и биржу свою толком протестировать не могут на жизнеспособность.
Начал читать статью — не ошибся )
Я классный! именно потому, что сижу за этим занятием чуть дольше… а вы лентяи не смогли сделать так же
Знайте себе цену.
— тут указано 21 апреля
— на сайте регистрации: events.techdays.ru/MAAC/2014-04
28 апреля.
— в документе что скачивали после регистрации, вообще 25 марта
Кому верить?
Я имел ввиду создание дизайна в целом, а не только его реализацию в XAML.
Да, все простые элементы с несложным дизайном (кнопки, текстовые блоки, списки и т.п). — бленд для них идеален и с ними все просто, И тут без разницы, где работал дизайнер, я как интегратор повторю все так же в бленде. Мы тут как раз о звездочках и прочих свистелках говорим и о быстрой сборке сложных дизайнов, и о взаимодействии дизайнера с интегратором.
Если дизайнер рисует в AI например, то, чтобы выдрать от туда звездочку-шестеренку, нужно сначала подготовить исходник, а потом как-то экспортировать нужные элементы, потом вставить в бленд, потом причесать XAML(+ресурсы выставить, адаптивность и пр..)
Inkscape позволяет просто открыть исходник как он есть — > Ctrl+ C — > Ctrl+V в бленд, где уже подготовлено все для вставки этой шестеренки., те я выкинул 2 промежуточных шага. При реализации больших проектов и сложных интерфейсов, это существенно
Мы даже думали над собственным редактором Path на панелях компоновки WPF, но сделать его — полбеды, как на него пересадить дизайнеров и научить работать хотя бы только с цветовыми ресурсами — вот где проблема, а иначе так же как и с Inkscape и Svg2Xaml половину кода руками переписывать.
Inkscape конечно решает большинство проблем, но не все, кое какие рутинные операции приходиться делать вручную. И все же он в разы облегчил работу над исходником дизайна, по крайней мере, там нельзя нарисовать того, чего нельзя «зазамлить» в WPF
У нас сейчас основная проблема, то что в XAML Windows 8 многого, что было раньше, просто нет. Нет триггеров, нет радиальных градиентов, опций рендара… Вот и приходиться иногда извращаться комбинируя растровые объекты с векторными. НО опять же Win8 в плане производительности на пару порядков выше и «мыла» в ней меньше чем в WPF.
Совет
InkSkape может координаты представлять как в относительных, так и в «прямых» точках
первые начинаются с маленькой «m» вторые с большой «M», по умолчанию все в относительных, XAML с ними работает, но к сожалению иногда криво, чтобы перевести в «прямые» — выделяем объект и жмем в InkSkape CTRL + "+" — эта комбинация для объединения объектов, но так же она преобразовывает координаты если объект один.
А вообще в настройках выставляем не использовать относительные координаты и радуемся жизни.
Сам давно занимаюсь интеграцией дизайна в XAML, все это уже пройденный этап.
От себя хочу добавить несколько моментов:
1) Использовать рендеринг текста Display — нужно очень аккуратно, тк в этом случае отключается рендер текста и контейнера, где он лежит, видеокартой, что приводит к глюкам и иногда еще большим артефактам чем размытие. Зачастую эффект плавающий.
2) Мы сейчас почти полностью отказались от растровой графики как таковой в XAML интерфейсах.
большинство иконок и графики рисуем в InkSkape и портируем графику и иконки прямо в XAML(объекты Path)
Почему InkSkape — потому что его родной формат SVG, он почти идентичен XAML и InkSkape позволяет рисовать вектор, привязываясь к пикселям сразу — для этого жмем Shift+«3» и видим пиксельную сетку, далее можно включить все привязки. тем самым никогда не попадаем на «полпикселя»
Ну и самый главный лайвхак — в InkSkape есть встроенный XML-Editor (Shift+Ctrl+X) — там просто копируем координаты объектов и вставляем в Data у Path в XAML.
Плоские иконки так делать пара пустяков и благодаря целочисленным координатам они всегда встают идеально в WPF, но можно делать очень сложную, и даже игровую графику, по сути полностью копируя стопку объектов в XAML, но там отдельной статьи материал о том как это делать эффективно.
Чтобы не быть голословным вот видео проекта что у меня сейчас в разработке, вся графика рисовалась в InkSkape и потом XML-Editor + прямыми руками вставлялась в проект и анимировалась. В проекте все векторное на 95%
http://youtu.be/gg8XmABwzkM
Если тема сообществу интересна, как завершу проект, могу написать статейку о процессе.
У нас InApp покупки, скоро новый год, можно как-то в центре разработки реализовать скидку на праздник?
Ели просто понизить цену на пакет на время праздника а потом поднять обратно, не будет ли проблем с балансом в минус, как было описано в конце этой статьи habrahabr.ru/company/microsoft/blog/197798/?