Category: дизайн

Category was added automatically. Read all entries about "дизайн".

star

Путь кинестетика

Напишу про наболевшее. У меня в программировании экспериментальный и итеративный подход. Он как помогает мне, так и мешает мне жить. Помогает он тем, что я с энтузиазмом берусь за задачи, которые непонимаю, как решать - всё, что нужно, выяснится по ходу дела. В принципе это важнейший скилл для корпоративной карьеры инженера для уровня выше джуниора. Мешает мне жить тем, что мне очень трудно делать значимый вклад в design discussions, когда я о проблеме не подумал заранее и не провёл выходные, играясь с прототипами. Когда я работал в относительно слабой или средней группе, мне это не мешало, потому что я успевал "потрогать все руками" и даже написать прототип быстрее, чем остальные успевали придумать хоть что-нибудь. В сильной группе я могу только помогать brainstorm'ить какие-то фичи по уже готовой идее, но вот изначальный каркас - как разбить задачу на абстракции и как организовать dataflow - я не способен придумывать в реальном времени. Вернее так: мои коллеги способны это делать куда чаще, чем я.

Обычно процесс решения задачи у меня протекает так:
1. Понять requirements и изо всех сил постараться их упростить до MVP (minimum viable product). Отбросить все требования по performance, и отбросить/упростить все фичи, которые можно отбросить, чтобы продукт всё ещё мог делать хоть что-нибудь end-to-end. Как правило, начинаю со структур данных и data flow, и упрощаю их.
2. Как можно быстрее написать прототип, работающий end-to-end, написать к нему юнит тесты и end-to-end тесты, и наладить среду разработки так, чтобы можно было очень быстро делать маленькие изменения и отлаживать. Длина итераций критична. В идеале - секунды. Плохо, но терпимо - несколько минут. Неприемлемо - более 5 минут. Т.е. если итерации занимают более 5 минут, я буду всё рефакторить и редизайнить до тех пор, пока не смогу делать изменения быстрее.
3. Уже имея прототип, занимаюсь рефакторингом - делаю много итераций. Зачастую кардинально меняю абстракции, разделение на компоненты, нередко меняются структуры данных и data flow. Обычно это происходят по мере того, как валятся свежие тесты или как обнаруживается неспособность их написать из-за плохого дизайна.
4. Добавляю немножко фич - это всё равно почти MVP, но обычно добавление первых нескольких фич к чему-то уже работающему помогает понять слабые места в дизайне.
5. Уже имея вылизанный и красивый прототип для MVP плюс немного больше, я способен заниматься настоящим дизайном - т.е. рассуждать про requirements в целом, делать какие-то proof of concept, в общем делать какой-то осмысленный дизайн для задачи целиком.

Похоже, что люди, способные генерить дизайн сходу, весь этот процесс проделывают в голове. Мне не очень понятно, как. Ну, наверное, понятно - для несложных задач или для задач, которые я уже делал раньше, или видел код, я могу наваять что-нибудь сходу, но реальные задачи, как правило, сложные. Я не понимаю, как люди могут целый месяц что-то рисовать на доске, не попробовав написать прототип. Мне трудно думать, когда нельзя "пощупать", а "пощупать" это значит "написать и запустить". В общем, кинестетик.

Таким образом, первая проблема - это возможность полноправного участия в design brainstorming на ранних этапах, когда времени на кодинг нет вообще, а задач по дизайну много.

Вторая - это процесс development'а. Для меня куда более естественно добавлять end-to-end вертикали по-простому, а потом постепенно рефакторить. Коллеги, которые лучше подкованы в том, чтобы делать всё в уме, пишут много фидбека, который сводится к тому, что "сделай прямо сейчас то, что ты собирался сделать на 2-й, 3-й и т.д. итерации" (ну, вернее, писали бы, если бы я к ним не подстраивался и делал бы в том порядке, в котором мне комфортнее... конечно же, я подстраиваюсь, чтобы фидбека было мало). При этом итеративный девелопмент, разделённый горизонтально (по комнонентам, когда какие-то компоненты вообще no-op), людьми воспринимается нормально. А вертикальное деление (добавить маленькую фичу, протащив её везде, и зарефакторив) люди не любят. Причём не из-за merge conflict'ов (если изменения небольшие, то merge это ерунда), а именно из-за различий в мышлении, в подходе. Может, у них вызывает отвращение заведомо throw-away код, когда понятно, что вот это уйдёт, когда я добавлю вон то. Может, для них мой подход сложен, примерно так же, как для меня сложен их подход. Точно не знаю причин.

Ещё одна проблема - это споры за то, как надо делать. Скажем, типичная ситуация: двое ожесточённо спорят, каким способом решить одну проблему - первым или вторым. Я видел в жизни разное, и мне кажется, в обоих способах могут выплыть неожиданные вещи, которые куда "дешевле" узнать, быстренько попробовав реализовать любой из этих двух способов (или даже оба), чем ведя вот эти теоретические обсуждения на пальцах. В общем, эта абстрактная информация, без эксперимента, у меня в голове частенько вообще не регистрируется как весомая. Со стороны выглядит, что у меня нет своего мнения, т.к. на этих ранних этапах, где люди обсуждают, я соглашаюсь с любым из способов, лишь бы поскорее перестать спорить и сделать хоть что-нибудь.

Ещё одна проблема - это то, что народ не ценит важность возможности быстрых итераций, поэтому если я своими руками не делаю какие-то улучшения (как в продукте, так и настраивая свой environment, полезные скрипты и прочее), чтобы было быстро, то чьими-то другими руками почти наверняка будет медленно. Будет рождён монстр, который компилируется 10 минут, ещё 10 минут ждать integration test'ов, и ещё минут 5 продираться с помощью десятка third party tools, чтобы собрать всё состояние системы, необходимое, чтобы разобраться, что именно сломалось и почему. Но для большинства это приемлемо, потому что у них натренирован вот этот умственный подход. Они сразу делают всё в уме, или рисуют на доске, и эти эксперименты им вроде как и не нужны.

Есть подозрение, что причина различий ещё в том, что мой подход фундаментально bottom-up, а люди вокруг натренированы использовать в top-down. Я могу воспринимать top-down либо в режиме рефакторинга, либо когда я размышляю вообще очень-очень high-level, либо когда я размышляю только над data flow. А вот в режиме top-down придумывать софтовые абстракции - с этим туго.

У меня вот эта кинестетичность и желание экспериментировать доходит до того, что если я давно не писал код (больше 3-5 дней), у меня вообще пропадает желание работать. Зная это, я придумываю себе coding задачи, которые, может, и не нужны, но помогут мне вернуться в продуктивный режим и держаться в нём.

Расскажите, есть ли у вас похожие проблемы с подходом к дизайну и к решению задач.
moth

Timezones explained

Хорошее видео, про временные зоны (на английском).


Я знал про это уже давно. У меня был проект в 2013 году, система для прогнозирования роста количества продуктов по категориям, объёмов трафика и других метрик. Она агрегировала метрики из разных источников, вычисляла различные статистики. Проект наудивление живуч, ещё используется по сегодняшний день. Помню, что я настоял на design decision, что вся дата и время будет в UTC, и в сутках 86400 секунд, no matter what. Причём я даже не делал перевод в локальное время для отображения. Все тулы выдавали UTC даты и брали в качестве входа даты в UTC. Агрегация суточных метрик начиналась в 00:00:00 каждого UTC дня, вне зависимости от страны, рынка и прочих деталей. Я прикидывал, что дешевле будет один раз объяснить пользователям, что все даты в UTC, и что день такой-то в североамериканском регионе представлен двумя UTC днями, чем заниматься сексом с переводом дат. Пользователи привыкли, а все, кто поддерживали систему после этого, были довольны этим решением :)
moth

Несовершенство этого мира

Если бы голос с неба мне вдруг сказал: "Дим, назови любую одну вещь, которую ты хочешь починить в этом мире, и я немедленно это сделаю; но времени на раздумье я тебе не дам, называй немедленно", то я бы сказал "уничтожь скроллинг!" Весь скроллинг, как горизонтальный, так вертикальный. Пусть все интерфейсы всегда влезают в отведённое количество пикселей, а за дополнительной информацией нужно кликать внутрь, а не скроллить. Если бы дали возможность сказать ещё одну вещь, я бы попросил уничтожить нотификации и pop-up диалоги (да и вообще всякую возможность неактивного приложения перехватывать фокус ввода).
moth

Сайт для фотографа

У меня друг-фотограф хочет сделать себе сайт, и есть некоторые вопросы, на которые хочется обратиться за "помощью зала". Это вопросы и к пользователям фото-услуг и к другим фотографам (а также к веб-разработчикам и дизайнерам). На некоторые из этих вопросов я смог ответить сам, но хотелось бы всё равно собрать больше мнений. Речь идёт про Россию, но большинство вопросов, по-моему, не специфичны для региона.

1. Допустим, вы ищете фотографа. Нашли поиском, открыли сайт.
Что конкретно вы ожидаете увидеть?
Чего вы видеть не хотите?

2. Что главное в принятии решения?
Как вы будете выбирать одного фотографа из нескольких?

3. Что вас раздражает настолько, что вы точно уйдёте с сайта сразу же?

4. Вы хотите сразу видеть цены на услуги на сайте? Если нет - почему?

5. Если вы художник или дизайнер, какой совет вы можете дать?
Чего стоит избегать при постройке сайта?
Что обязательно добавить?

6. Какая должна быть платформа для разработки сайта? Почему?
Есть ли принципиальная разница, на какой платформе строить сайт, чтобы он корректно отображался на разных мобильных устройствах?
Прошу ответить тех, кто в курсе, как выглядят сайты на разных платформах.

7. Пользуетесь ли вы кнопками соц.сетей на сайтах, чтобы перейти в Facebook или Instagram, к примеру?
Нужны ли эти кнопки или они только загромождают?

8. Имеет ли смысл подбирать шрифты особой красоты или нужно обойтись стандартными, но стопроцентно читаемыми?

9. Кто-нибудь может это расшифровать нормальным языком? Или ткнуть носом, где об этом прочитать? Определитесь с ключевыми словами, пропишите заголовки и описания страниц, добавьте описания фотографий, так называемые Alt-тексты, чтобы поисковики понимали, что изображено на снимке, и, наконец, подтвердите права на сайт через Googlе и «Яндекс.Вебмастер».
moth

Купальник

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

Я не художник, поэтому нарисовано криво. Полоски, наверное, должны быть тоньше. Общая идея дизайна - края сисек видны по всей окружности, и купальник не поддерживает висящие сиськи, а немного придавливает. Полоски натянуты в разные стороны, как показано стрелками на схеме. Enjoy.

DSC02915a
blue

ello

Заджойнился в ello.
https://ello.co/morfizm
Могу поделиться инвайтами, если кто-нибудь тоже хочет попробовать (есть 5 штук).

Меня привлёк ello тем, что это новый проект, хочется немного последить за развитием.
Ещё - мне понравился манифест и идеи. Они позиционируют себя как анти-фейсбук.
Ещё - мне понравился "дух" дизайна - достаточно минимально и fixed-width (на самом деле, я для своего блог движка именно об этом и думал совсем недавно).
Во всём остальном ello отвратителен, ужасно похож на твиттер, и, вероятно, быстро умрёт. Причём, я считаю, что он должен умереть по причине своего же манифеста (бесплатно, без рекламы и с этичным отношением к пользователям), не совместимого с нуждами инфраструктуры для нагрузок, сравнимых с твиттером. Им придётся с позором перекраивать манифест, после чего сдаваться инвесторам.


Upd.: Инвайты разошлись как горячие пирожки. Тут столько желающих, что, похоже, надо просить участников делиться инвайтами с остальными :)
Можете и дальше оставлять запросы на инвайт, кто-то, кто уже получил вам его даст (если они вообще будут в наличии). Соответственно, с вас social responsibility - поделиться дальше.
Если вы шлёте инвайт другому, пожалуйста, сначала напишите коммент о том, что вы это делаете, выждите несколько минут, сделайте рефреш, и убедитесь, что кто-то другой не делает того же самого. Такой вот кустарный collision resolution, но должно сработать.

Upd.: Я попрошу, чтобы дали инвайтов тем, кто уже отписался до 09/30, остальные уже пусть самоорганизовываются, больше не могу на это тратить время, извините.
moth

Вещи, вроде бы, ненужные, но созданные в помощь пользователю

Originally posted by laikka at Вещи, вроде бы, ненужные, но созданные в помощь пользователю
Два друга-дизайнера из Барселоны веселятся, как хотят! А ведь практичные вещи придумывают! Есть у них туника с дырками на груди для солнечных очков или кофта с карманами на спине, чтоб любимый, когда обнимает на прогулке, в этих карманах руки грел.

Вот пара керамических объектов от Entresuelo 1a
, удовлетворяющих вполне конкретные потребности:

entlo_04
Чашка, в которую можно окунать большие овсяные печенья.
entlo_05

Collapse )
moth

Если бы кошки были шрифтами

Originally posted by k_poli at Если бы кошки были шрифтами
Все популярные шрифты уникальны в своём дизайне, но какой предпочитаете именно вы — беззаботный Comic Sans или строгий Helvetica? Часто используемые человеком шрифты, являются отражением его характера. А что если бы шрифты были кошками? Именно на такой забавный вопрос и решили ответить иллюстраторы с популярного сайта icanhascheezburger.com.



Collapse )




moth

Буквы на холодильнике





Сложил из магнитиков неокуба цепочку, хотел её разместить на холодильнике. В виде окружности она не влезла. В результате попыток её разместить, получилась буква. Надеюсь, я не обругал кого-нибудь на каком-нибудь языке =)

Кстати, мысль: интересный тул для дизайна букв. Можно шевелить руками, ну и, так как магнитики, они тянутся - сохраняется линия.