В одном из чатиков поговорили с дизайнерами за висячие предлоги и я там рассказал правило, которого придерживаюсь при переносе предлогов. Ну и заодно вам решил рассказать.
Это правило чуть сложнее, чем «ПЕРЕНОСИМ ВСЕ ПРЕДЛОГИ, ААА!!!», но оно и более логичное. Таким образом у нас правый край текстового блока менее рваный получится.
Звучит правило так:
Если предлог в конце строки и под ним пустота, то его нужно переносить. Если представить, что в типографике была бы гравитация, то предлог бы упал. А значит — переносим.
Если предлог в конце строки и под ним есть другое слово, то под действием гравитации он не упадёт. Потому что под ним есть опора в виде слова на другой строке.
Будет полезно, например, если вы разработчик и выступаете на конференции или демонстрируете команде на очередном стендапе куски исходного кода проекта.
Сань, а что тут вставлять то?! Спросите вы. Казалось бы, что тут сложного, да?
Код вставлен. Но есть проблема: он плохо считывается. Код не похож на код. Можно поменять шрифт на моноширинный.
Ребята выложили презентации всех спикеров, в том числе и с Московской конференции, которая прошла ещё в начале мая. Покопался в них и нашёл ещё одну интересную от Леонида Фейгина, креактивного директора DDVB.
Презентация в комиксовом стиле и с соответствующей подачей. Такую презентацию вряд ли получится подготовить без дизайнера, но выглядит конечно клёво.
Майский дайджест со ссылками на заметки, которые были написаны за месяц:
Женя Белодед спросил, как я оцениваю презентации для клиентов. Ответил настолько подробно, что всё не уместилось в одно сообщение, разбил на несколько частей:
Никита Кулижникова — разработчик, который стал менеджером в дизайн-студии М18 и рассказывает на Дизайн-просмотре о том, как они чуть не потеряли свою студию в кризис и как перестраивали процессы.
Кажется, что в оформлении Никите помогал дизайнер, всё таки в дизайн-студии работает :—)
Мне понравилось несколько моментов. Первый — это списки. Посмотрите 4 варианта в карусели. Все разные и по своему-интересные. Казалось бы — обычный перечень, но сколько способов сверстать их.
Но что делать, когда в работе одновременно несколько задач и ты все время переключаешься с одной на другую?
Если у вас есть практический способ учитывать время работы над конкретной задачей в числе многих, над которыми работаешь параллельно, то это идеальное решение.
Многозадачность — это миф. Нельзя параллельно (читай одновременно) работать над несколькими задачами. Эта иллюзия многопоточного выполнения задач идёт из того, что ты быстро переключаешься между ними. Но в каждый конкретный момент времени мозг работает только над одной задачей. Причем переключение между задачами всегда требует восстановления контекста, на что уходит время.
Как тут быть? Работать над задачами по очереди и не перескакивать хаотично с одной на другую. В этом случае проще фиксировать затраченное время. Например, над одной презентацией посидел 2 часа. Сделал перерыв на 30 минут и сел на 2 часа за другую презентацию.
Как работать над презентациями по очереди? Надо дробить каждую презентацию на этапы. У меня работа над презентацией состоит из 2-3 этапов, каждый из которых согласовываю с клиентом:
Готовлю концепт презентации по стилю на 4-5 слайдов
Раскатываю согласованный стиль на все остальные слайды
Если слайдов в презентации 30-40 или ещё больше, то второй этап дроблю на несколько. Например, раскатываю стиль на следующие 10 слайдов и согласовываю их. Потом приступаю к следующей партии. И так, пока слайды не закончатся. На каждом этапе могут вносится правки, если это необходимо.
Вместо того, чтобы показать клиенту 150 слайдов и получить тонну замечаний — мы с ним уже внесли все правки на соответствующих этапах. И сам факт корректировки слайдов уже не так критично выглядит, как если бы я согласовывал презентацию целиком. А потом хватался за головову и внутри себя ругался бы на клиента.
Таким образом, например, можно подготовить концепт и пока ждешь обратную связь — взяться за раскатывание стиля по другой презентации, по которой уже согласовал стиль.
Ещё важный момент — помимо оценки в количестве рабочих часов учитывать фактический дедлайн. Во второй части писал о том, что клиент может прийти с уже имеющимся дедлайном. В этом случае скорее всего количество рабочих часов = фактическому времени. Но так бывает не всегда.
Бывает, что я оцениваю презентацию в 10 рабочих часов, а клиенту она нужна не прям завтра, а только через неделю. Ну не срочно ему, такое тоже бывает. В этом случае я понимаю, что могу работать над презентацией в перерывах между срочными. Ну и учитывая итеративный подход — первый этап я ему всё равно покажу через пару дней, но за эти пару дней выделю всего 3-4 своих рабочих часа.
Надеюсь система понятна :—)
Для себя вижу идеальным способ оценки проекта по фактическому времени, затраченному на работу, так как сразу снимаются вопросы со сложными и простыми слайдами, авторскими или стоковыми картинками, а главное — всегда больной вопрос с правкой, которой на одной задаче может и не быть вовсе, а на другой — очень много.
Для нас, как исполнителей, такой подход конечно же удобен — не надо париться с точной оценкой и работать с рисками. Сколько отработал столько и получил. Но это не в мире клиента.
Для клиента такой подход к оценке презентации является не предсказуемым. Откуда он знает сколько ты потратишь времени на работу? Да, окей, он знает твой часовой рейт, но это ему ничего не говорит о бюджете, который нужно заложить на задачу. И возможно эту сумму еще ведь надо согласовывать с руководством или партнерами. А сколько это будет часов? 5 или 50? А ты такой «ну хз, там видно будет».
При таком раскладе бюджет невозможно планировать, а клиенту нужно понимать сколько на эту задачу необходимо заложить денег. Соответственно, высока вероятность, что он уйдёт с презентацией к дизайнеру, который выдаст фиксированный прайс — понятный и предсказуемый.
Просто говоришь клиенту, что твой час стоит ХХ руб., а отчет и фактическую сумму в реальном времени можно мониторить по ссылке.
Это называется микроменеджемент. Микроменеджмент — зло. Мне кажется, что клиенту нафиг не упало ещё и за исполнителем следить сколько он там времени потратил на задачу. Ему нужна кайфовая преза с которой можно идти и продавать свой продукт/услуги или договариваться об инвестициях.
Моя задача как исполнителя — снять с клиента головную боль по подготовке презентации. В идеале сделать так, чтобы он отдал черновик, произошла какая-то магия на моей стороне и получилась кайфовая преза. Других деталей ему знать не надо, уж особенно то, сколько я часов и минут сидел за слайдами.
Если я научился выполнять 5 часовую работу за 3 часа — это не значит что теперь буду меньше зарабатывать при почасовой оценке презентаций. Это значит, что пришло время повысить рейт. В дальшейшем я буду брать за 3 часа своей работы столько, сколько раньше брал за 5.
В моем походе ничего необычного: называю клиенту стоимость за слайд после визуальной оценки его материалов и короткого опроса. Всегда оговариваю, что изменение композиции слайда или много правки = новый слайд. То есть, если на слайде 4 блока и меня просят «давайте здесь добавим еще один» — новый слайд. Если «давайте здесь перезальем текст» — новый слайд.
Звучит очень сложно, не представляю как в реальной работе всё это успевать оценивать (понять это новый слайд или нет?) и учитывать (сколько время потратил на эту правку? а сколько это в деньгах?), особенно когда работаешь над 2-3 проектами в моменте. Часть из которых срочные. Чем проще система, тем проще её поддерживать.
Ещё из описанного метода складывается ощущение, что правки — это что-то плохое, но это не так. Черновик презентации — это не статуя отлитая в бронзе, а живой организм.
В процессе работы над презентацией клиент может увидеть оформленный слайд и понять, что вот этот текст там не нужен, а нужна картинка. Или наоборот, не хватает какой-то важной детали — надо дописать текст. Или понимает, что между 9 и 10 слайдами важно добавить слайд с дополнительными финансовыми показателями, которые лучше покажут перспективы продукта.
Все эти изменение — благо для презентации. Она становится лучше. Это не я плохой дизайнер и не учел эти моменты, а «мы команда, мы вместе делаем презентацию лучше».
А ещё не всегда от клиентов исходят адекватные замечания. И тут важно не упустить этот момент и не превратиться из дизайнера в «инструмент по внесению правок». Каждое замечание от клиента нужно критически оценивать и пытаться понять — сделает ли это изменение презентацию лучше. Чем клиент обосновывает необходимость этого изменения?Если обосновать не может, то нужно не править презентацию, а разобраться что не так.
Очевидно, что клиенту что-то не нравится, но совсем не то, о чём он говорит. Моя задача — разобраться в том, что конкретно не удовлетворяет клиента и исправить именно это, а не бездумно вносить правки в слайды потому что двоюрдному брату кузины не нравится синий цвет текста.
Сделал презентацию в PowerPoint и надо было перекинуть слайды заказчику в Google Slides. Делов то, да? Выполняю импорт слайдов, всё ок, кроме одного слайда с таблицей.
Посмотрите картинку, там видно как таблица должна выглядеть на самом деле и как она импортировалась в Google Slides:
Сначала не понял в чём дело. Попытался сделать прозрачный фон для таблицы средствами Slides, но ничего не поменялось. Причем можно было применить белый фон к таблице и всё работало. Но мне нужен был именно прозрачный, потому что я использовал плашки с закругленными углами для выделение нужных строк.
Начал копать в чём дело. Оказалось, что при импорте Google Slides зачем-то берёт стили таблицы не те, что я определил в PowerPoint, а те что были выставлены по умолчанию при создании этой таблицы. Странно конечно, наверное баг.
Как исправить такой баг?
После сохраняем файл и можно импортировать презентацию в Google Slides. Такие дела 🤷♂️
