Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
>>Алгоритмы*
Где?
Где?
Ломанные линии для связывания меток — это зло, ломающее глаза. Этому учат во всех пособиях о инфографике. У Лебедева в линче на днях было кстати.
Бизнес-линч — 27 ноября
Кстати, дуги:
Линии выносок должны быть максимально незаметными. Они должны указывать на объект и при этом как бы не иметь собственного значимого рисунка. Поэтому — только лаконичные прямые, без изломов и углов, как вверху (но без стрелок). В крайне неудобном случае рисуйте дуги.
Кстати, дуги:
Не стоит тупо следовать правилам, не понимая что стоит за ними.
Правило — максимальная незаметность, поскольку линии сами по себе — второстепенный элемент изображения. То есть должны маскироваться что бы взгляд на них не спотыкался. А вот как именно — зависит от изображения.
Если у нас инфографика, где есть несколько элементов на плоскости по прямоугольному гриду, то линии должны быть идти по линиям грида, что бы мозг автоматом их считал второстепенными элементами, тогда да, никаких ломанных линий. Дуги к стати — вредный совет — они сразу выбиваются и привлекают внимание.
В данном случае простое изображение и поверх него надо минимизировать изломы и простые прямые — лучший способ сообщить что они — второстепенны. Если еще линии будут размещаться по линейке с некоторым шагом, будет вообще хорошо — регулярные структуры хорошо игнорируются.
А вот за изображением вполне уместно и ломанные и дуги и все что угодно.
Правило — максимальная незаметность, поскольку линии сами по себе — второстепенный элемент изображения. То есть должны маскироваться что бы взгляд на них не спотыкался. А вот как именно — зависит от изображения.
Если у нас инфографика, где есть несколько элементов на плоскости по прямоугольному гриду, то линии должны быть идти по линиям грида, что бы мозг автоматом их считал второстепенными элементами, тогда да, никаких ломанных линий. Дуги к стати — вредный совет — они сразу выбиваются и привлекают внимание.
В данном случае простое изображение и поверх него надо минимизировать изломы и простые прямые — лучший способ сообщить что они — второстепенны. Если еще линии будут размещаться по линейке с некоторым шагом, будет вообще хорошо — регулярные структуры хорошо игнорируются.
А вот за изображением вполне уместно и ломанные и дуги и все что угодно.
Хм. На мой взгляд, в первую очередь нужно убрать жирные точки и сделать полупрозрачность линий где-то 50%, а не использовать пунктир. Ну и никаких изломов на самом рисунке.
Сначала надписи по месту, легко и понятно читающиеся, потом связующие указывающие линии.
Причём тут дизайн? Для надписей на чертежах есть стандарты, нас им на уроках черчения обучали. В итоге всё читаемо и даже по какому-то ДИН стандарту, или я не понял проблемы?
Одно из определений графического дизайна:
«Какой-то» стандарт не обязательно окажется к месту, кроме того условие задачи накладывает ряд ограничений: кривые не пересекаются, иллюстрация легко воспринимается и т.д. Именно наличие ограничений делает возможным поиск лучшего решения. Кто-нибудь мог бы сказать примерно следующее: «О чем спор, везде линии используются...». Но вашему глазу скорее не все равно.
Графический дизайн — художественно-проектная деятельность по созданию гармоничной и эффективной визуально-коммуникативной среды.
«Какой-то» стандарт не обязательно окажется к месту, кроме того условие задачи накладывает ряд ограничений: кривые не пересекаются, иллюстрация легко воспринимается и т.д. Именно наличие ограничений делает возможным поиск лучшего решения. Кто-нибудь мог бы сказать примерно следующее: «О чем спор, везде линии используются...». Но вашему глазу скорее не все равно.
Скажем так, стандарт для надписей на чертежах именно для того и придумали чтобы всё легко воспринималось и одновременно было идеально читаемым. Отсутствие пересекающихся линий это один из главных залогов читаемости.
Считайте что стандарт по изготовлению чертежей это такой общепринятый гайдлайн который придумали чтобы не изобретать каждый раз собственный велосипед.
Считайте что стандарт по изготовлению чертежей это такой общепринятый гайдлайн который придумали чтобы не изобретать каждый раз собственный велосипед.
Вопрос «строительства велосипедов», к стати, не настолько прост. Любопытно, почему наши с вами современники все еще продолжают придумывать что-то новое и улучшать старое?
Давайте представим, к Йенсу Шуленбургу (главный конструктор Bugatti) приходит кто-то из АвтоВАЗа и говорит: «Мужик, слушай, ну зачем тебе вся эта возня? Вот, держи ключи и не волнуйся. Только это, прогреть не забудь».
Линии-выноски стандартизированы и выглядят вполне:
— www.pntd.ru/2.109.htm
— vsesnip.com/Data1/38/38724/index.htm
Два момента:
— Вы действительно готовы использовать такой стиль всегда?
— Идея поста показать, что ценой некоторых упрощений можно сделать существенно более простой другую задачу. В данном случае алгоритм расстановки пояснений.
Давайте представим, к Йенсу Шуленбургу (главный конструктор Bugatti) приходит кто-то из АвтоВАЗа и говорит: «Мужик, слушай, ну зачем тебе вся эта возня? Вот, держи ключи и не волнуйся. Только это, прогреть не забудь».
Линии-выноски стандартизированы и выглядят вполне:
— www.pntd.ru/2.109.htm
— vsesnip.com/Data1/38/38724/index.htm
Два момента:
— Вы действительно готовы использовать такой стиль всегда?
— Идея поста показать, что ценой некоторых упрощений можно сделать существенно более простой другую задачу. В данном случае алгоритм расстановки пояснений.
Я не в силах утверждать что это подход верный всегда и везде — абсолютной может быть только глупость. Однако я думаю что есть вещи где отступление от норм не целесообразно. Например в программировании есть гайдлайны. Они сделаны для того чтобы код тоже был читаемым и обозримым (это конечно не все причины для их использования). Конечно бывают случаи где следование гайдлайнам увеличивает объем работы, но это же не значит что их не следует использовать. Я не уверен что смог полностью выразитъ свое мнение на эту тему, правда это не так уж и важно.
В оригинале статьи просто искали алгоритм который максимально читаемо раскидает сноски, в итоге ответ набравший больше всего голосов (генетический алгоритм) упомянут в этой статье чуть более чем никак. Наш с вами спор тоже почти не относится к этой статье и мы ушли от начальной темы.
В оригинале статьи просто искали алгоритм который максимально читаемо раскидает сноски, в итоге ответ набравший больше всего голосов (генетический алгоритм) упомянут в этой статье чуть более чем никак. Наш с вами спор тоже почти не относится к этой статье и мы ушли от начальной темы.
Я не спорю с вами, просто хочу обратить ваше внимание на следующее: слепое следование правилам (отбрасывая область их применимости) может пагубно сказаться на результате. Инженерный чертеж является очень узкой областью, соответственно любое заимствование правил, применимых к нему, требует некоторого внимания и дополнительной адаптации. Смею предположить, что ваше мнение, выраженное правильно и полностью, только улучшит понимание и содержательность любой беседы с вашим участием.
Касательно оригинала: автор вопроса указывает на невозможность или нежелание менять стиль, что вполне понятно. Я лишь пытался продемонстрировать возможность существенно упростить задачу разработчика путем изменения начальных требований к стилю. Прошу отметить, я не называю одно из решений правильным, а другое ложным. Идея проста — показать наличие другого пути.
Давайте представим следующую ситуацию: практически одновременно у двух команд появляется идея создать проект, который бы позволил людям легко аннотировать любые изображения, найденные в сети. Грубо говоря, интерфейс пользователя можно описать как «кликнул — написал». Далее система автоматически генерирует удобочитаемый результат.
Какой вариант вы бы выбрали?
Упрощение стиля, ведущее к стабильному и узнаваемому результату и быстрый выход в публичную фазу?
Безоговорочное следование канонам, но чуть более или существенно чуть более долгую разработку, отладку и последующий выход на публику не имея полной уверенности в том, как будут размещены эти непослушные сноски?
Использование генетического алгоритма, кстати, может привести к потрясающей ресурсоемкости без гарантированного результата. Или, другими словами, ваш новый корпоративный пользователь Василий, после часа ожидания, может увидеть результат, мягко говоря не предназначенный для человека.
Касательно оригинала: автор вопроса указывает на невозможность или нежелание менять стиль, что вполне понятно. Я лишь пытался продемонстрировать возможность существенно упростить задачу разработчика путем изменения начальных требований к стилю. Прошу отметить, я не называю одно из решений правильным, а другое ложным. Идея проста — показать наличие другого пути.
Давайте представим следующую ситуацию: практически одновременно у двух команд появляется идея создать проект, который бы позволил людям легко аннотировать любые изображения, найденные в сети. Грубо говоря, интерфейс пользователя можно описать как «кликнул — написал». Далее система автоматически генерирует удобочитаемый результат.
Какой вариант вы бы выбрали?
Упрощение стиля, ведущее к стабильному и узнаваемому результату и быстрый выход в публичную фазу?
Безоговорочное следование канонам, но чуть более или существенно чуть более долгую разработку, отладку и последующий выход на публику не имея полной уверенности в том, как будут размещены эти непослушные сноски?
Использование генетического алгоритма, кстати, может привести к потрясающей ресурсоемкости без гарантированного результата. Или, другими словами, ваш новый корпоративный пользователь Василий, после часа ожидания, может увидеть результат, мягко говоря не предназначенный для человека.
Не лень вам на stackoverflow отвечать горой кода и рисунков?
Привычка. Я не так много времени трачу на код и рисунки, кроме того задача была интересной. А привычка появилась благодаря:
— заказчикам, которые с трудом дочитывают даже небольшие спецификации
— разработчикам, которым тоже лень читать, соответственно проще подготовить «мурзилку», убедиться что все все поняли, объеденить важные иллюстрации в постер и повесить на рабочий стол для особо забывчивых
— заказчикам, которые с трудом дочитывают даже небольшие спецификации
— разработчикам, которым тоже лень читать, соответственно проще подготовить «мурзилку», убедиться что все все поняли, объеденить важные иллюстрации в постер и повесить на рабочий стол для особо забывчивых
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Алгоритм аннотирования иллюстраций или почему бы программисту не быть немного дизайнером?