Comments 70
Спасибо за замечательную программу.
Можно тут попросить о функционале?
Не могли бы вы обучить hfpager работать в режиме socks proxy сервера?
Связать приложения умеющие общаться по tcp/ip по радиоканалу, используя радиостанцию как радиомодем, затруднительно из-за задержек. Если использовать канал между двумя рациями как модем (физический уровень модели osi), поверх которого будут гулять канальный, сетевой, транспортный ... из-за задержек нельзя, то можно подняться выше по модели osi. И ближайшее подходящее - socks proxy. Если бы ваша программа могла быть таким socks proxy сервером - это было бы решение...
На одном девайсе, без подключения к сети, ваша программа принимает запрос по протоколу socks, отправляет другой версии вашей программы на другом устройстве. Там уже есть выход в сеть или работающий сервер слушающий какой-то порт...
Вопрос не ко мне, я разработчик документации КВПейджера, а не разработчик самого КВПейджера. Но передать вопрос по адресу не проблема, передам. :)
По существу вопроса спрошу: какую задачу это всё должно решить? Пейджер — это ведь концептуально законченный продукт, предназначенный для решения своей узкой задачи. Неужели всерьёз рассчитываете, что пробросить какой-нибудь телеграм через socks-proxy со скоростью 5,87 бод (не бит в секунду!) — это порадует?
А, ну и кстати: там же есть ещё решение — FSKChat. Его протокол открыт, и хотя гарантированной доставки на физическом уровне не предполагает, сам по себе хорош вполне, и с разработчиком можно договориться предметно.
По существу вопроса спрошу: какую задачу это всё должно решить?
Самые разнообразные задачи. Например картографическое ПО, когда нужно обмениваться информацией об объектах с привязкой к координатам.
hfpager изначально позиционировался как туристическое ПО.
Очень многие нужные вдали от цивилизации программы общаются с сервером по http. Ну вот XyGrib например - умеет работать через socks proxy.
Если подключить к какому-нибудь баофенгу, и работать в vhf допустим, то возможно там будет и 1200 бод. Уже в браузере можно будет куда-нибудь залезть через proxy.
HTML слишком неоптимален для таких скоростей. Лучше передавать нужные данные более упаковано. Передавать только нужные, изменившиеся данные и уж точно без форматирования. Если это и будет HTML через SOCKS, то нужен ещё JS движок, который будет обновлять странички, если вдруг они изменились и создавать максимально компактные запросы к бэкенду.
Пейджер как чистый транспорт использовать не очень рационально: по задумке он самодостаточен, а на стационарном конце радиоканала легко развёртывается шлюз в телеграм или электропочту. Как чистый транспорт он неизбежно вынужден будет тащить метаданные, в итоге скорость передачи для большинства мыслимых практических приложений будет запредельно низкой. Мы же не можем игнорировать ни ощущение времени пользователем, ни его объективные ограничения.
Картографическое ПО, которого куча и еще маленькая тележка, получение метеоданных из определенных сервисов (винди, зигриб) - есть куча всего помимо телеги и почты, что возможно кому-то понадобиться вдали от цивилизации. Ну невозможно для всего предусмотрительно написать шлюз. Должно быть путь менее эффективное, но универсальное решение. HFpager это не только пейджер, это еще и протокол обмена данными, причем протокол позволяющий гибко настроить параметры и скорость связи. Чем выше по диапазону - тем больше возможная скорость, а диапазон передачи определяется используемыми рациями. Где-то будет очень узко, а где-то будет возможность пропихнуть более толстый трафик. У вас не единственная программа, которая умеет пропихивать данные по радиоканалу, но уникальная своей проработанностью и гибкостью настроек. Если к ней прикрутить еще socks proxy - будет только лучше, не хуже.
Вы так говорите будто есть возможность переписать кучу уже готовых приложений, которые хочется использовать вне покрытия операторов связи. Есть большая разница в затруднительности использования чего-то в результате низких скоростей и невозможностью использования.
КВ Пэйджер - программа для обмена короткими адресными законченными сообщениями с контролем целостности и опционально - контролем доставки.
Поэтому естественным образом сюда ложатся шлюзы в SMS/E-mail/мессенджеры, которых уже написано некоторое количество :-)
"Персональный SMS-шлюз" входит прямо в состав обсуждаемого андроидного пэйджера.
Когда-то socks соединение будет реализовано, если действительно потребуется подключение сторонних программ к обмену сообщениями.
Главное понимать, что сообщения должны быть очень короткими, десяток другой байт.
Например, так может быть выгодно передавать платежи в какой-то крипте, например что-то типа helium, майнинг которой основан на предоставлении доступа, но на КВ.
Очень интересно, где и и зачем применять такое сочетание устройств как смартфон и УКВ радиостанция.
По задумке (и практике) полезно применять в профессиональной связи, например, на диапазоне Low Band (в районе 40 МГц) в лесу. Смысл в том, что так делается цифровая надстройка над аналоговой радиостанцией, и можно не голосом докладывать, а текстовыми сообщениями. Или вообще присылать координаты, которые не надо надиктовывать и записывать. Ещё таким образом можно оценивать зоны радиовидимости по маршруту при помощи маяка.
по сути, это радиолюбительская игрушка, к которой "Радиал" пытается приклеить бОльший смысл, чем туда можно заложить
Как раз не радиолюбительская. Задумывалось всё для туристической радиосвязи, потом разрослось до современного состояния. Многие решения спорные (потому и документация потребовалась), но уж чего в пейджере точно нет — это радиолюбительства.
на основании какой лицензии физ.лицо может проводить радиосвязи на КВ?
Частоту вполне можно и купить, опыт есть. Делается это сравнительно несложно, и стоит вполне доступных денег. Другое дело, что для работы на территории всей страны частоту почти не купить — но условному оленеводческому совхозу и не надо на такой большой территории, хватит и зоны с радиусом 300-500 километров вокруг точки. Не помню, может ли именно физлицо купить частоту (надо спрашивать), но ИП точно может — а он и есть физлицо. Так что любителем быть не обязательно.
Ну и если на то пошло, для любительской связи пейджер ну прямо вот очень неудобен.
у вас есть опыт получения лицензии именно на КВ? На нижний диапазон, где доступны NVIS связи? Сколько это стоило, если не секрет?
У меня лично — нет, но я знаю тех, кто получал. Стоило порядка десятков тысяч рублей. Точнее вспомнить пока не смог, но узнаю — скажу. Помню, что деньги там были какие-то не запредельные.
Узнал. Порядка 26 тысяч разовых вложений и потом 700 рублей в год за одну частоту.
на какой частоте?
А вот это надо с РКН договариваться. На нижнем КВ вполне реально договориться, примеры тому есть.
Приведите, пожалуйста, конкретный пример выделенной частоты ИП/физлицу в NVIS участке КВ диапазона
Спросите лучше здесь. Там точно есть люди, причастные к покупке/аренде.
Интересный способ уйти от ответа. Давайте вернёмся к началу разговора - я выдвинул тезис, что, несмотря на то, что фирма "Радиал" позиционирует "КВ пейджер" как программный комплекс, которым будут пользоваться в условном лесу, по факту это будет игрушка для радиолюбителей. Очень хочется получить не ссылку на РКН или телеграмм чат, а хоть какой-то документ, который подтвердит наличие юридической возможности пользоваться этой технологией физлицами и малыми/индивидуальными предпринимателями.
Комментарием ниже я приложил ссылку на сайт РКН, в котором описан порядок присвоения (назначения) радиочастот или радиочастотных каналов. Это — документ, он подтверждает наличие юридической возможности пользоваться любой радиосвязью физлицами на той частоте, которую они смогут себе организовать.
Ну и кстати, ничто не препятствует работать и с любительской лицензией, просто будут известные неудобства.
Почему уйти? Там Слодкевич (гендир Радиала) вам от первого лица ответит, сколько и каких частот он зарегистрировал в Карелии. Насколько я помню, у него несколько номиналов между 1.7 и 4.0 МГц. Но я помню неточно :-)
Тестовая радиосеть вне РЛ диапазона действует в Карелии, р-н Костомукша. Подробнее см. на сайте, там же можно связаться с владельцем и договориться о тестировании.
https://radio-telegraph.ru/?page_id=29
радиосеть вне РЛ диапазона
Я вижу по ссылке 9 шлюзов, из них 7 - РЛ диапазон (7175 и 3745 кГц) и 2 шлюза самого "радиала" (некие 38ХХ и 48ХХ)
да, это именно оно (и лично я не знаю набора частот в Карелии, когда-если соберусь туда, свяжусь с Е.Я.Слодкевичем и получу инструкции, как работать голосом/пейджером). Обратите внимание, что 4800+ КГц уже близко не радиолюбительский диапазон, 62+ метра.
Если Вас интересует эта тема - свяжитесь с Евгением Яковлевичем лично и задайте вопрос. Есть статьи на сайте КВП и на youtube канале Радиала есть видео об использовании этой радиосети.
Странно, что минусы наставили на этот вполне резонный вопрос.
Как я себе вижу такое сочетание можно применять там, где нет сотовой связи, голос по радиосвязи уже не слышно, а передать сообщение хочется. В основном это используют на КВ, но можно и на СиБи.
Просьба к разработчикам: сделайте пожалуйста поддержку FBBS c чтением ньюсов и личной почты. Я провозился некоторое время с этой темой в поисках решения для местного МЧС и радиолюбителей и на мой взгляд FBBS это то что нужно. Вот только удобного мобильного фронтенда к ней не завезли, а пожарной бригаде в лесу топтать команды FBBS в tenet-е просто некогда.
Идея была следующая. На пожарной машине (или на машине радиолюбителя выехавшего "в лес на прогулку") устанавливается RPi4 подключенная к возимой КВ или УКВ радиостанции. На нём поднимается FBBS которая обслужает бигаду - получает от них сообщения через мобильного клиента (по WiFi, у FBBS есть фича - оно может работать и по TCP соединению) и пакетом отправляет "по маршруту". И наоборот, принимает сообщения из эфира для бригады и отдает мобильным клиентам.
А шлюзы в почту и телеграм — не подходят? Они уже реализованы.
Какой телеграм, какая почта ? В лесу нет связи кроме КВ и УКВ.
Если решается задача диспетчеризации ПСР, диспетчера вполне можно пересадить в то место, где связь и интернет есть. При наличии помехоустойчивого канала не обязательно тащить всю инфраструктуру в лес. Пробрасывать веб-интерфейс мобильным отрядам тоже не обязательно, если мы отталкиваемся от инфраструктуры Пейджера.
Решается задача оперативной двустронней пейджинговой связи бригады с диспетчером (и между бригадами) в условиях когда никакой связи нет вообще. Никакой инфраструктуры в лес не тащится. В лесу (на машине) устанавливается FBBS для того, чтобы пожарные не заморачивались с ожиданием отправки и получения подтверждений своим сообщениям. Более того, каждому пожарному на спину не повесишь КВ радиостанцию с антенной на 14 метров, а на машину такой сетап устанавливается без проблем. Пожарные используя свои мобильники подключаются по WiFi к этой FBBS и с помощью мобильного клиента сгружают сообщения на неё, а она далее работает пакетом (FX.25) с базой/диспетчером и/или другими бригадами по КВ/УКВ радио. Скорость передачи по FX.25 в лучшем случае 1200 бод, IP поверх такого канала возможен, но совершенно не пригоден для ипользования. FBBS сообщения агрегирует и сжимает, после чего отправляет "по маршруту". Если Вы застали эпоху Fidonet или UUCP, то вопросов быть не должно.
В этой затее я лично места для КВПейджера вообще не вижу, если только как транспорт для FBBS — но если по FX.25 всё работает, зачем там КВПейджер?
но если по FX.25 всё работает, зачем там КВПейджер?
Рискну процитировать самый верхний комментарий:
"Связать приложения умеющие общаться по tcp/ip по радиоканалу, используя радиостанцию как радиомодем, затруднительно из-за задержек".
AX.25 со присными - транспорт для ip, вернее для tcp/ip. tcp/ip плохо работает при тех задержках которые дает радиоканал. О чем вам и пытается сказать @checkpoint
Тут дело даже не в скорости - дело в задержках.
Это именно то, почему я буду очень рад увидеть в hfpager функциональность socks proxy сервера. Ибо, возвращаясь снова к самому верхнему комментарию: "Если использовать канал между двумя рациями как модем (физический уровень модели osi), поверх которого будут гулять канальный, сетевой, транспортный ... из-за задержек нельзя, то можно подняться выше по модели osi. И ближайшее подходящее - socks proxy".
Как-то так.
Тут дело даже не в скорости - дело в задержках.
Вот насколько я знаком с TCP/IP (а я хорошо знаком), задержки — это всегда проблема прикладного уровня. Я сам жил какое-то время с GPRS и пингами по паре секунд, и не скажу, что это прямо вот очень сильно мешало эксплуатировать TCP/IP.
"Если использовать канал между двумя рациями как модем (физический уровень модели osi), поверх которого будут гулять канальный, сетевой, транспортный ... из-за задержек нельзя, то можно подняться выше по модели osi. И ближайшее подходящее - socks proxy".
Ну если приложение готово подождать ответ от сокс-прокси минут десять, то и слава богу. Убеждать в необходимости реализации сокс-прокси меня полностью бесполезно, я разработчик документации, а не продукта.
Да я понимаю, что вы хотели про документацию поговорить, а мы вас замучили всякой ерундой.
Я не так хорошо знаком с tcp/ip, но насколько я в курсе, дело в дело в параметрах ядра линукса определяющих таймауты при установке tcp соединения. И в частности, в значениях этих таймаутов установленных в андроиде. Переключение радиостанции с приема на передачу в некоторых случаях может превышать эти значения. Во всяком случае так мне объяснили уверенные пользователи tcp/ip которые пытались поднять ip трафик на таком радиоканале, но не смогли.
Не то что замучили ерундой, я подобные обсуждения уже несколько лет наблюдаю в предметном чатике. Однако я ожидал несколько иного направления дискуссии в комментариях. :)
Честно говоря, не вижу нужды вообще отталкиваться от реализации TCP/IP в андроиде, поскольку по этому стеку если и имеет смысл общаться, то между приложениями на общем железе. А вот "модем" я бы проектировал исключительно как источник данных вроде почтового сервера: пользовательское приложение постучалось с вопросом "Есть чё?", "модем" ответил, проглотил от приложения запрос в сеть, и в своём темпе по своему же протоколу и отправил. То есть городить заведомо асинхронный обмен данными внутри смартфона и между ними.
Это конечно если эту вашу FBBS можно научить работать через прокси. Если нет - се ля ви - пишите для нее специальный шлюз или ковыряйте эту FBBS чтоб прикрутить к ней работу через прокси. Но есть большое число программ которые через прокси работать таки могут искаропки и для них всех это будет решением. Поскольку сами понимаете, на каждую всякую FBBS, и иже с ними, отдельный шлюз писать не вариант. А много кому эта его FBBS вот прям до зарезу нужна и у каждого она разная и все страждущие даже не знают как вам об этом сказать... Вот случайно вы на хабре засветились и к вам сразу хлынул поток с одной и той же просьбой. Это жжжж неспроста! Была бы в вашем пейджере галочка "включить socks proxy сервер" вы бы могли каждому жаждущему поюзать его архинужную FBBS ткнуть в документацию где красиво нарисовано как правильно на эту галочку тыкать чтоб стало сразу СЧАСТЬЕ.
Извините за некий сумбур, я надеюсь вы поняли что я пытался сказать. :-)
Примерно понял, что вы пытались сказать. :)
Если в приложении нет такой функциональности, упоминания её в документации тоже не будет. Я, к сожалению, ненадлежащий собеседник для переговоров о функциональности. Словами передать могу (кстати, разработчик тут засветился тоже и вроде комментарии читает), а вот будет это кто-то руками реализовывать или нет — я не в курсе.
Нужен фронтэнд (клиент) к FBBS для Андроида. По сути это и будет "КВ Пейджер", только транспортировкой данных будет заниматься не мобильник пользователя, а FBBS, незаметно для пользователя (для нескольких десятков пользователей на самом деле). Клиенты общаются с FBBS по локальному WiFi по TCP соединению (telnet) набором текстовых команд. Пользователю же клиент представляется как набор папок с тематическими переписками + личная почта + разные другие фичи, в том числе геолокация (эдакий Телеграм). Я пробовал даже небольшие фотографии отсылать, JPEG до 50кб пролазит нормально, но много ретранзмитов и долго (FBBS все это берет на себя). Проблема в том, что общаться с FBBS телнетом могут не только лишь все и по этой причине вся затея сдулась.
И еще. В APRS по сей день используется AX.25, в котором не предусматривается коррекция ошибок. Это жуткая беда на КВ. Почему не пошло внедрение FX.25 я не понимаю. К тому же FX.25 совместим вниз с AX.25.
Собственно, идея КВП + шлюз (на "большой земле", с доступом в Инет) это и есть основная вкуснятина. Второй, важнейший момент - относительная простота интерфейса и незамысловатость сетапа (устройств, антенного хозйства, смартфона) для использования данного способа не упертыми радиолюбителями (которые досконально раскопают и освоят любой метод, просто по приколу), а самыми обычными людьми, имеющими необходимость организовать связь в ненаселенке, и получившими ради этого третью категорию. Ибо - закон есть закон.
Если хочется в такое поиграться, то winlink в помощь. Но, вообще, конечно, это всё то ещё препперство
К сожалению, winlink проприетарный продукт построенный на деньги правительста США. Для нормальной работы winlink требуется проприетарный модем. Можно конечно и через звуковую карту, но будет доступно ограниченное количество протоколов с очень низкой помехозащищенностью. Нужен свой аналог, на открытых протоколах.
чуть выше написал: заслуга проекта КВП (имхо) простота интерфейса и сетапов, доступная любому пожарному или леснику. Без иронии в адрес последних, и с крайним уважением к их работе.
Проблема КВП в том виде как это представляется у автора статьи состоит в том, что к мобильнику будет подключена куча проводов, будет занят аудио интерфейс радиостанцией, что делает сам мобильник непригодным к использованию для основных целей (я уже не говорю, что процесс fine tuning-а всего этого сетапа весьма не прост). Такой сетап пожарных и лесников категорически не устраивает! Моя идея состоит в том, что бы радиопередающую часть вынести и оставить в "пожарной машине", а леснику или пожарному оставить мобильник с приложением и без проводов. Т.е. у лесника есть возимая радиостанция, с хорошей антенной, установленная на автомобиле, рядом с ней смонтирована коробочка с RPi4 и всё! Он берете свой мобильник, подключается к RPi4 по WiFi, запускает андроидного клиента и шлет/принимает корреспонденцию. Он даже может находиться на некотором расстоянии от машины, в пределах видимости WiFi (150-200 метров если WiFi антенну поднять на крышу машины). Все это относится и к радиолюбителям, которые часто выезжают на природу поработать в эфире с редких мест.
Будем объективны: автор статьи про пейджер вообще ни слова не сказал за исключением того, что писал к нему руководство пользователя. ;)
В основном сценарии использования пейджера мобильник — это просто карманная ЭВМ, поскольку в основном сценарии предполагается, что никакой сотовой связи на точке нет.
То, что вы сейчас описываете — в сущности, тот же шлюз. Как его реализовать — вопрос не ко мне, увы. С этим надо идти в чат приложения, там сидит разработчик, с ним обо всём можно договориться. Собственно, большинство кастомных шлюзов как раз самописные.
Да, прошу прощения за оффтоп, сбился с темы. Дело в том, что я совсем недавно посвятил изучению этой проблемы некоторое существенное время, я перепробовал неколько разных "пейджеров", "APRS клиентов", и несколько шлюзов, и лучшее к чему я смог прийти это FBBS на RPi + андроидный клиент.
Шлюз разрабатывать не надо, так как FBBS это шлюз, в том числе в IP. FBBS была популярна среди радиолюбителей в 90-х и начале 2000-х, когда всепроникающей сотовой связи не было. Это open source проект, есть под все платформы, даже под MS-DOS. Очень сильно напоминает по сути FTN или UUCP, но только для HAM радио (в качестве адресов используюся радиолюбительские позывные + SSID).
Тут уже упоминали еще одну классную штуку - winlink. Работает офигенно если у вас есть купленный специальный модем. В интернетах пишут, что winlink-ом повально пользуются мореходы и яхтсмены, так как КВ связь самая надежная связь в мире! :)
А вы могли бы тезисно описать что он умеет и для чего юзается?
Вы про winlink спрашиваете ? Это сеть шлюзов связанных между собой по IP. Есть удобный виндовый клиент позволяющий пересылать электронную почту как между пользователями сети, так и в глобальную сеть, можно обмениваться файлами (фотографиями). Доступ в сеть winlink осуществляеться по радио (КВ/УКВ). Для этого используются специализированные модемы, но есть и решение на базе обычной звуковой карты, которую подключают к радиостанции. Использовение передовых методов модуляции с коррекцией ошибок позволяет иметь оперативную текстовую связь почти в любой точке Земли. Сеть поддерживается радиолюбителями, но финансируется из Американского бюджета. Линк: https://en.wikipedia.org/wiki/Winlink
Ошибка (точнее, три ошибки: лишняя точка в конце заголовка и два подчеркивания):
Велик ли объем руководства? Как планируете поддерживать в актуальном состоянии?
По мне так очень трудоемкий процесс получается, но если все ради "жрать кактус", то вопросов нет, идеальный набор ПО получился, каждая более-менее серьезная правка - БОЛЬ!
Объём получился 24 страницы с обложками.
Поддерживать в актуальном состоянии технически проблемы не представляет. Продукт разрастается медленно, вставить ещё страницу в нужное место легко. Некоторые сложности представляет только референс по интерфейсу, но если вдруг выкатят версию, в которой интерфейс значительно обогатился функциями, я просто переверстаю просторнее, вплоть до функции на страницу. Это недолго.
Насчёт трудоёмкости не соглашусь: если стоит задача сделать именно печатное руководство, этот пайплайн как раз видится оптимальным. Можно быстрее — я упоминал выше gostdown-pandoc для этого — но по ГОСТу не надо ни заказчику, ни мне. Тут ещё надо понимать вот что: значительную часть затрат времени на вёрстку составила не сама вёрстка, а поиск её оптимального варианта. Нарулить непротиворечивые наследуемые стили, найти ширину колонок, размер кегля, учесть преобладающие размеры картинок — всё это отняло время. Теперь же, когда основные решения найдены, вписать в них новый контент — дело техники.
Взял бы я ворд, каждая правка была бы такой же болью: вставил новое слово → появилась новая строка → картинка уехала вниз → сжал размер, получил неконсистентный вид документа. В ворде никогда и ничего нельзя сделать хорошо.
Ну смотрите, на документ из 24 страниц с картинками (допустим их не очень много, четверть) ушло 3 недели чистого рабочего времени...я бы сказал, что это уже на грани разумного, если заказчика устраивает, все в порядке, не мне считать чужое время, но для себя я бы за такое не взялся. Поддерживать в таком формате документ 100+ страниц уже невозможно, а значит сборка довольно таки нишевая и ситуативная.
В ворде можно сделать очень хорошо, если уметь им пользоваться. Это очень мощная по своим возможностям программа.
А что значит поддерживать в таком формате документ 100+ страниц? Внести в середину ещё главу? Так это не вопрос. Перебрать порядок изложения? Да в общем тоже не сложнее чем в ворде. Добавить ещё по паре предложений в каждую формулировку? Обновить все картинки в отдельной версии документа? Ну, чуть посложнее, но не принципиально.
Обусловленные технологией затраты времени не пропорциональны объёму работы. Чуть сэкономить можно было на каждом из этапов, в совокупности до приемлемых 3 часов на страницу. И если бы не печатная форма, можно было бы вовсе чего-то не делать. Например, я не засёк, сколько времени заняла инструкция по оригами, на глаз — 2 или 3 часа с тестированием. Именно для стоящей задачи она нужна, и она не обошлась бесплатно. Никакой техпис не станет отрисовывать в иллюстраторе изображения интерфейсов, логотипы и буллиты, а это тоже время. И таких мелочей много.
Что касается ворда. Он действительно мощная штука, пользоваться которой по-настоящему мало кто умеет из тех, кто думает, что умеет. :)
Но.
По возможностям управления текстом и картинками он и рядом не стоял с DTP-системой, и нет, в ворде нельзя сделать ничего хотя бы так же хорошо, как это позволет сделать DTP-система, а тем более индизайн. Хранить текст и управлять его версиями несопоставимо удобнее в гите. Готовить иллюстрации — всё равно нужен отдельный редактор, даже если это Визио. Ну и какой смысл использовать ворд?
По возможностям управления текстом и картинками он и рядом не стоял с DTP-системой
Ну тут можно и поспорить, конечно, но если честно лень, пусть будет так.
Готовить иллюстрации — всё равно нужен отдельный редактор, даже если это Визио.
Визио ни в каком виде не является редактором графики вот от слова совсем, в самом ворде больше инструментария по работе с изображениями, чем в висио (кстати интересный вопрос - почему у мелкомягких нет приличного графического редактора...).
Ну тут можно и поспорить, конечно, но если честно лень, пусть будет так.
Навскидку ещё в одних только стилях абзаца: оптический кернинг, настройка трекинга и интерлиньяжа, настройки подчёркивания и зачёркивания, отточий в стиле параграфа, тонкую настройку переносов, сглаживание рваного края при выключке влево. И это только то, что можно напечатать, и это только про стили абзаца. Да что далеко ходить, обыкновенную рамку по ГОСТу в Индизайне сделать и проще, и лучше: на мастер-странице берёшь и рисуешь рамку, в неё нужные вертикальные надписи, и всё. Тут и правда лень спорить. :)
Визио ни в каком виде не является редактором графики
Солидарен, хотя схемы в визио рисуют только в путь. Я, впрочем, с 21 года пользовался для схем не визио, а инкскейпом.
Однако соглашусь: сборка нишевая и ситуативная, обусловленная печатной формой документа. Писал бы по госту, взял бы гостдаун вместо индизайна. Писал бы для веба, вообще взял бы маркдаун или рест.
Спасибо за увлекательный и полезный материал. Особо ценным считаю, что Вы не просто поделились своим подходом и инструментарием, но и указали, какие сложности у Вас возникли в процессе. Массив работы в рамках подготовки документа впечатляет.
НЕ согласна с комментарием о том, что 105 часов на 24 страницы — это на грани разумного. Во-первых, в данном случае речь идет о целом проекте по разработке документа, так как объединяет разноплановую работу: аналитику, подготовку текста, выработку структуры, дизайн, верстку, редактирование. Можно за 105 часов написать 100 страниц, только какой в этом смысл, если пользователь в них просто потеряется из-за воды, плохой структуры, неясных и расплывчатых формулировок.
Мне понравилось, что Вы делаете акценты на актуальных и наболевших вопросах для технического писателя. Одним из таких для меня оказался вопрос о том, какую дополнительную информацию включать в руководство пользователя, а какую нет. Понравился ваш подход и отработка замечаний от пользователей по этой теме. Возьму на вооружение.
Только вот боюсь, Adobe InDesign для неопытного пользователя может оказаться сложноватым и потребует дополнительных сил и времени на начальных этапах использования. Но внешний вид документа от его использования определенно выигрывает. А внешний вид также влияет на читабельность, легкость использования и на пользовательское впечатление об описываемом продукте.
Спасибо за статью, читала с большим интересом!
Сказ о том, как для андроидного приложения бумажное руководство писали