Если я хоть что-то понимаю в колбасных обрезках, то с обратной стороны платы, ровно под разъемом для камеры, есть место для разъема, очень похожего на USB. Что это за разъем, интересно? Судя по фотографии, на него выведены часть проводников от разъема камеры. Какой-нибудь micro-HDMI? И почему они развели его на плате, а сам не распаяли? Интересно, интересно...
Еще в 1999 году, т.е. более 20 лет назад, американец Алан Купер выпустил первое издание своей книги «Психбольница в руках пациентов». В этой книге он прекрасно рассказал и показал все те противоречия и проблемы, про которые уважаемый автор топика попытался сказать своими словами.
Если кратко, то сейчас параллельно, изредка пересекаясь, существуют два мира: мир программистов и мир пользователей. Купер чётко на примерах показывает, почему когда программист делает продукт в соответствии со своими представлениями о правильности и целесообразности, этот продукт оказывается совершенно неприемлим для обычных пользователей.
Более того, Купер даёт читателю понимание как эти проблемы и противоречия между программистами и пользователями нужно преодолевать, чтобы создавать восстребованные на рынке продукты.
Отвечая на вопрос, вынесенный автором в заголовок своего топика, скажу: Linux в любых модификациях — это инструмент, созданный программистами в соответствии с их собственными представлениями о нужности, удобности и целесообразности. И эти представления зачастую не пересекаются такими же представлениями простых пользователей. Hint: натянуть графическую оболочку на коммандный интерпретатор, это самое начало пути.
Автор приподзабыл упомянуть в тексте, что ставит он не просто Windows 10 IoT, которая суть — обычная «десятка», но с лицензионными ограничениями, а Windows 10 IoT CORE, которая «совсем другое дело». И она бесплатна, да…
Ну просто какой-то бред… Что трщмайор хочешь услышать и узнать о целом парке датчиков, измерителей и сенсоров на предприятии? При том, что по LoRaWAN все передается в зашифрованном (дважды!) формате от ноды к серверу… Удалённо пролистывать базу данных в каком помещении когда был выключен свет? Или кто когда форточку в здании открыл? Он и так эту информацию получит, если запрос офрмит должным образом. Или ему лень оформлять запрос, поэтому компания должна ставить шлюз и тянуть к некоему «подвалу» всю информацию? На многих предприятиях эти самые IoT-Networks вообще изолированы не то что от Public Internet, а даже от собственных Intranet, ибо нефиг замусировать сеть непонятными пакетами.
Какой-то просто бред…
И как трщмайор предлагает поступать с самоорганизующимися безсерверными сетями типа ZigBee или той же LoRa?
В решении ГКРЧ по поводу работы в нелицензируемом диапазоне 866-869 МГц нет ни слова о конкретном типе протокола, но зато четко указано, что вести постоянное вещание нельзя никому. И в малюсеньком частотном диапазоне, где вроде бы разрешено вещать чуть плотнее (10%, а не 1%) — 868,7 — 869,2 (500 КГц) вы сможете разместить всего два канала с полосой 125 КГц, и все равно с ограничением на время работы. Как говорится «Это не спасёт Отца Русской Демократии», т.к. прикрыться казуистикой «Это не LoRaWAN, это наша чистая, посконная LoRa!» всё равно не получится.
А значит, по-любому, ваш проект с его основным требованием он-лайн мониторинга невыполним.
Вооот!.. Ради этого признания и перечитал всю кучу комментов.
Ибо то, что вы тут пишите, никакого отношения к LoRa не имеет. Я имею ввиду, что описываемый вами проект не имеет решения на базе LoRa — эта технология не позволяет вести мониторинг множества объектов в реальном времени «на пульте оператора». Вы, похоже, и не слышали, что девайс LoRaWAN должен вещать не более 1% времени, т.е. не более 15 минут в сутки. Вы будете получать только статусы с определенной задержкой — от одной до нескольких минут, ну и всякие алармы, а уж пока сообщение от оператора дойдет до конечного модуля — грузовик человека уже в лепешку раскатает.
И когда вы указали формат сообщения, стало совершенно очевидно, что сеть LoRa вы даже и не пытались развертывать. Идентификатор каждого из LoRaWAN модулей — DevAdr — передается не в составе сообщения, а отдельно, в служебной его части; и БС его всегда знает. Расходовать под него драгоценные байты payload message — дилетанство. Эти 5 драгоценных бит гораздо важнее израсходовать под TimeStamp — временную отметку измерения, ибо оператору будет очень важно понимать, когда именно были зафиксированны текущие координаты, ну и номер пакета, т.к. пакеты имеют свойство теряться.
Откуда взялась цифра в 37 бит для сообщения — мне тоже не понятно, т.к. по стандарту длинна PayloadMessage может меняться в зависимости от скорости передачи и по региональному стандарту для Европы (которого мы вроде бы придерживаемся) составляем минимум 51 байт. Байт. Bytes =/= bits.
В общем, искал по хабру больше информации про LoRa, а в результате сам читаю лекцию…
Странная методология преподавания: вместо классического «от простого — к сложному» модерновая «выкинем посреди озера: захочет — выплывет».
«Чем больше трудностей — тем лучше» — это гарантированный способ навсегда отвадить от предмета 99% обучаемых.
Ардуино по своей сути, по идеологии задумывалась как система, ОБЛЕГЧАЮЩАЯ освоение микроконтроллеров, как наиболее простой и лёгкий путь вхождения в эту очень большую и объёмную область знаний. Да, с огромными ногами, чтобы чуть-шо — можно было к ним подпаяться домашним паяльником. Да, с очень простой IDE, чтобы не пугать новичка кучей не совсем понятных действий по наладке. Да, с отнюдь не идельным кодом и с очень мягкой проверкой синтаксиса — всё для того, чтобы было проще начать работу.
Но нет! «Мы простых путей не ищем!» Правильно выше написали — надо было пример моргания лампочкой сразу для Целерона ваять!
Первое, с чего следовало бы начинать — не с обзора цен (взятых, прямо скажем, с примерно непонятно какого потолка), а с обзора производительности различных микроконтроллеров. Показать главное преимущество этой экосистемы: что под разные задачи можно выбирать совершенно разные кристаллы. Поморгать светодиодиком — и Аттиньки 8-ой хватит, Лору запустить (с правильным AES-ом) — уже и 328-ой ардуинки может не хватить. Дисплей красивый нарисовать — уже ES32 может не хватить. Ну и т.д. И показать в конце, почему под контроллер Умного Дома нужен именно STM32F. Это было бы системно.
А так получилось слишком алогично, а потому непонятно и спорно. «Моргать светодиодиком через STM32? Я вас умоляю!..»
99,99% пользователей вообще не заметят смены логотипа, если вы их в этот свой новый логопит носом не ткнете. Ну, и для кого тогда вы вообще затевали смену лого? Для себя любимых? Тогда зачем об этом трубить? Отделу маркетинга надо было бюджет освоить? Освоили, молодцы… Тёму подкормили нехило.
По хорошему, ребрендинг делается только тогда, когда надо разорвать ассоциации у пользователей с одним сценарием, с одними привычками и ассоциациями, и задать другие. В вашем случае — частичного украшательства логотипа, «подгибания уголков» — не поменилось ничего, кроме суммы на счете у самой фирмы (в минус) и у Темы (в плюс). И раз большинство пользователей это изменение не заметит, то и выхлоп на рынке — нулевой. Вот если бы поработали с экспертами по юзабилити, переработали сайт под различные сценарии использования, кардинально сменили позиционирование на рынке, а попутно, со всеми этими изменениями еще и логотип поправили — вот это было бы другое дело. А так получилась тема «Как со студией Артема Лебедева правильнее отмывать маркетинговый бюджет».
И за всю статью — НИ СЛОВА про сценарии использования, про профили пользователей… Одни свистелки и перделки нафиг никому не нужные украшательства.
Да, и за слово «айдентика» вам уже приготовлено отдельное место в лингвистическом отделении ада.
> 75% пользователей касаются экрана только одним большим пальцем.
> Меньше 50% держат телефон одной рукой.
Необходима привязка этой статистики к физическому размеру корпуса устройства или хотя бы диагонали экрана. Сейчас устройств очень много и они очень разные. От фаблетов с размером экрана 7" до китайских смартфончиков с экраном в 4,3". Разумеется, сценарии использования таких устройств будут совершенно разными.
Странно читать подобные статьи. Настолько странно, что приходится писать комментарий.
1. Подобные системы многоязычного полу-автоматического перевода существуют по всему миру в количестве, которое не передается словом «много». Их очень много. И чем крупнее компания, тем на большее число языков они могут предложить подобный перевод. Так что идея стара, как… ладно, не будем. Лично мне приходится мучится с Lionbridge.
2. Весь автоматизм перевода в этих системах базируется на Translation Memory: базе данных, как какое слово нужно переводить. Так вот, для русского языка такой подход работает очень плохо. Наш язык очень слабо коррелирует с английским по своей структуре и правилам образования слов и фраз. Даже на простых, отдельных словах, нет 100% верного перевода, т.к. у нас слишком много значений для слов и терминов. А уж во фразах… Как-то что-то более-менее срабатывает на стандартных фразах типа «Для завершения настройки нажмите „Далее...“», но в тексте общеболтологического свойства такой подход уже дает сбой, а уж на маркетиновых фразах — не работает вообще. И тут мы переходим к следующему пункту.
3. Необходимость использования корректора. Человека, обладающего должной компетенцией как в языковых познаниях, так и в технических вопросах верстки текста на сайте и, главное, в той теме, которой посвящен сайт. Т.е. полного автоматизма все равно не получается. Причем, по поему опыту, даже если переводчик совершенно правильно и корректно набил Translation Memory, корректору все равно зачастую приходится переводить бОльшую часть текста практически с нуля. А зачастую «переводчиком» у нас (точнее — у них, на Западе) считается любой русскоговорящий эмигрант, даже если тройку по Русскому языку в школе ему поставили просто ради того, чтобы не оставлять «эту наглую рожу» на второй год. И ведь ничего не докажешь! Менеджер Lionbridge видит, что процент исправлений перевода для русского языка просто зашкаливает, пытается выяснить, почему так происходит — ты отвечаешь «Мы по-русски так не говорим!» — менеджер подключает к беседе «нашего специалиста по переводу Vasiliy Pupkin», а Вася на голубом глазу заявляет: «Я все делаю ко гайдлайнам системы! Какие ко мне претензии? Это у вас завышенные требования! Вы требуете художественного редактирования!» Слова «завышенные требования» ласкают слух менеджеру, т.к. они показывают, что мяч не на его стороне поля. Но с другой стороны, вроде бы как от клиента отрицательный фидбек, но и своего работника вроде бы как третировать не за что. Настырный менеджер делает несколько телодвижений, в результате которых ты пишешь подробную записку с объяснением основных ошибок переводчиков и правил перевода, после чего тебе дают слово, что обязательно учтут эти замечания… Но если Vasiya в школе учиться не хотел, то зачем ему сейчас что-то менять? В результате менеджер либо забивает на проблемы с русским языков, либо меняет позицию. Приходит новый — и все с начала…
4. Ну и главная беда всех этих систем — не видно контекст. Нет возможности посмотреть начальную верстку, увидеть на ней тот кусок, который ты сейчас переводишь, и хотя бы приблизительно оценить получающийся результат.
Все пока…
За статью спасибо. Главную мысль, что пользователю должно быть ОЧЕВИДНО, что от него хотят и что ему надо делать при первом приближении к любому устройству, я разделяю целиком и полностью! И тут можно было бы в очередной раз уйти в пинание ногами современных веяний типа Matherial Design, но я все же ограничусь высказываниями по поводу приведенных примеров.
Начнем с кружек. встречал достаточно примеров очень изысканного дизайна, когда ручка имела небольшой выступ внизу дуги. В результате палец упирался в этот выступ, и удерживать чашку оказывалось очень удобно. Да и примеров разных чашек с держателями для чайных пакетиков, с лоточком для печенек и т.п. — миллион по всему интернету. Так что имеет смысл просто говорить о недоработках или находках в определенной модели.
По поводу манометров — в дайвинге этот прибор имеет важнейшее значение для самой жизни дайвера (показывает объем оставшегося воздуха в баллоне), поэтому там подобные вещи давно маркируют так, чтобы было понятно даже при замутненном состоянии разума (а это, кстати говоря, вполне обычное состояние при пребывании на глубине — все реакции организма заторможены, человек соображает медленнее). Стрелочка в красной зоне — «ПОРА ВСПЛЫВАТЬ!»
http://www.diskus.ru/media/2013/11/07/minimanometro_me%5B800l600%5D.jpg
По поводу английских розеток. Там не все так просто. Там целая система и идеология, которую продумали и реализовывали после Второй Мировой войны. Там и кольцевая система прокладывания проводки по квартире, и гарантированное положение фазы в розетке, и раздельные предохранители под квартиру/конкретного потребителя, и цветовая маркировка этих предохранителей. Так что говорить, что это было непродуманно — нельзя. Громоздко на сегодняшний момент — да. Требует переработки — возможно да, а возможно и нет. Пока англичан все устраивает.
А вот по поводу английских раковин — это, я считаю, архаизм. Когда-то это, может, и имело смысл, но сейчас явно является устаревшим. Слишком сложно и неоправданно. Часто в каком-нибудь баре видишь два таких крана в раковине и полное отсутствие затычки… вот и думай, как выкрутиться.
Со специализированными телефонами — теперь хороший пример в Московском Метрополитене, где на каждой станции размещены колонны экстренного вызова и информации.
http://www.msk.kp.ru/share/i/12/3706421/
Хотя тут тоже пример своеобразный. Во-первых, они попытались убить двух зайцев: SOS и info. Это разные сценарии, за которые отвечают разные службы, но не разводить же два вида колонн? В результате получился такой вот страшный гибрид, который еще надо весь прочитать, чтобы понять, как им правильно пользоваться.
Я бы понатыкал простейших коммуникаторов SOS по несколько штук вдоль каждого перрона — в случае ЧП счёт идет на секунды, разбираться некогда. Зачастую важно просто нажать Большую Красную Кнопку. А стойка с информацией — она и есть стойка с информацией… Пусть стоит себе одна посреди зала.
Дело в том, что сама операционная система бесплатна, да. Но в качестве «платы» Google требует у разработчиков аппаратных платформ под Android размещать на рабочем столе смартфонов и планшетов приложения, которые связаны с сервисами Google, включая Gmail, YouTube и прочие. И вот это засилье «родных» сервисов-приложений корпорации Google, по мнению группы Fairsearch Europe, делает практически невозможной конкуренцию с данной компанией в сфере мобильных приложений.
Вольный перевод оригинала, который ни к оригинальной статье, ни к реальному положению вещей отношения не имеет.
Та версия OS Android, которую производитель получает по бесплатной лицензии, не имеет в себе никаких сервисов Google. Это всякого рода электронные книжки, плееры и т.п. электроника, в которой вы никогда не найдете Google Play, Gmaps, Gmail и т.п. Если OEM хочет поставить на устройства сервисы Google, то ему надо оплачивать Google Apps suite.
Претензии у перечисленных компаний не к процессу оплаты, а к тому, что иконки на эти приложения «обязаны размещаться ключевых местах интерфейса телефона», а так же к тому, что стоимость лицензионных отчислений, собираемых Google, настолько мала, что остальные игроки не могут с ним (с ней?) состязаться.
И вот тут у меня возникают вопросы… А что, собственно, мешает той же Microsoft, для которой, как и для Google, мобильное подразделение — далеко не основной источник доходов в рамках глобальной корпорации, перераспределить финансы, обеспечив конкурентную стоимость лицензий для своей мобильной ОС, так же как это сделал Google? Я без наезда, я просто интересуюсь… Или гораздо проще натравить ловеров, чем ломать внутренний финансовый план?
Да, дизайн хорош!
Хотел было спросить: «А к чему процессор?» Ибо чуть на других индикаторах, но тем не менее точно такие же по функциональности часы делал лет 20 назад на простой россыпухе микросхем, но потом увидел фразу у автора:
>А если честно, то при изготовлении этих часов акцент ставился не на схемное решение.
… и все вопросы отпали.
Нисколько не хочу приуменьшить роль Ивана и Елены в их компании, но просто по факту статья отражает положение дел в отдельно взятой фирме с конкретным распределением ролей и организацией бизнес-процессов.
В реально крупных компаниях, занимающихся программными продуктами, все обстоит совсем по-другому. Как и положено, чем крупнее фирма, тем более раздробены роли каждого.
Например в той фирме, где работаю сейчас я, всё ПО и вся документация к нему изначально создаются на английском языке (а не на русском, как в ABBYY). По мере создания ПО те строки, которые отмеченны, как подлежащие переводу, попадают к переводчикам (в каждой стране и в каждом регионе — свои партнёры по переводу). При этом переводчики зачастую переводят «в слепую», ибо продукт вообще не готов и его нельзя ни поставить, ни как-либо посмотреть. Параллельно с этим создаётся вся необходимая документация (разумеется, включая User Manual) — создаётся именно Техническими Писателями, но создаётся она опять-таки только на английском языке и для той первоначальной версии, которая соответствует техническому заданию. Еще одна особенность — документация верстается так, чтобы все термины и названия элементов интерфейса подтягивались автоматически при вёрстке из DB переводов. Затем, когда продукт выходит на стадию тестирования, помимо команды тестировщиков, его смотрит и региональный технический менеджер в каждом из регионов.
И вот тут-то и начинается самое интересное. В зависимости от региона, требования к продукту могут меняться (например, в РФ запрещён импорт криптостойких несертифицированных решений, поэтому для РФ такой код должен исключаться из ПО). Да, подобные вещи, разумеется, должны бы учитываться на этапе проектирования, но мы помним, что фирма очень крупная, и не всегда все можно решить заранее. Вот и приходится «резать по живому». Но это самая малая из возможных бед. В разных языках длинна слов — различна. Не мне рассказывать, что русские фразы в большинстве своём длиннее английских. Региональному менеджеру приходится при этом играть роль и корректора (исправлять кривой перевод), и технического писателя (подбирая наиболее подходящий по смыслу, но более лаконичный перевод), и дизайнера интерфейсов (писать письма ДИ типа: «А нельзя ли здесь расположение кнопок поменять, снять „bold“ с комментария и чуть расширить текстовый блок, т.к. при любом раскладе нам нужно минимум 3 строки, а не 2»). Очень часто, после того, как проходит этап review, на котором локальные менеджеры должны были исправить перевод, вся документация ребилдится заново, дабы подхватить внесенные в перевод интерфейса исправления. И эта документация проверяется менеджежером еще раз, уже на предмет соответствия интерфейсу.
Так что в рамках нашей фирмы вот этот региональный менеджер и правит документацию, и исправляет перевод, и корректирует интерфейс, и разумеется, параллельно еще и тестирует продукт по ходу дела.
Но если вернуться к теме топика и заданному в его начале вопросу — «Кто лучше всех знает продукт?» — то я не буду утверждать, что это именно многорукий и такой универсальный локальный менеджер. Во-первых, он не в курсе происходящего в других регионах, а во-вторых, он видит только текущую версию, которую ему передали для проверки и тестирования. Я бы сказал, что лучше и полнее всех знает продукт только его Системный Архитектор. Это тот, кто отвечает не только за реализацию текущей версии (это, как мы помним, делает DM), а кто изначально составлял техническое описание продукта для выработки из него ТЗ, кто сейчас по информации, поступающей от аналитиков, корректирут Product Strategy, кто взаимодействуя с PM, определяет текущую конфигурацию продукта с прицелом и «на сейчас», и на длительное будущее.
>а отсутствие информации о вертикальном расположении буквы и неизбежные неточности довольно легко компенсировать с помощью словарей и алгоритмов распознавания
Привычные для всех других языков компьютерные словари для автозамены нервно курят в сторонке, когда речь заходит про русский язык. У нас слишком высока вариативность слов. Русскоязычную систему проверки орфографии невозможно построить, не создав перед этим алгоритм анализа морфологии (образования словоформ из исходного слова). А создание такой морфологии для русского языка — это сама по себе задача аховая. Я только одну фирму знаю, где с этой задачей более-менее справились (фирма есть на хабре, не буду называть, дабы не упрекнули в пиаре), во всех остальных случаях, насколько мне известно, делаются попытки тупо набить словарь, что неизбежно приводит к казусам и ошибкам (как в истории с Win8).
Автору — спасибо из за статью, и за программу!
Одно замечание, чисто из любопытства: как так получается, что код 4636 на устройстве HTC работает, а в программе — не находится и не отображается? Программа не находит его в манифестах? Любопытно… Если она не находит этот код, то, может, она не находит и какие-то другие?
Если я хоть что-то понимаю в колбасных обрезках, то с обратной стороны платы, ровно под разъемом для камеры, есть место для разъема, очень похожего на USB. Что это за разъем, интересно? Судя по фотографии, на него выведены часть проводников от разъема камеры. Какой-нибудь micro-HDMI? И почему они развели его на плате, а сам не распаяли? Интересно, интересно...
Если кратко, то сейчас параллельно, изредка пересекаясь, существуют два мира: мир программистов и мир пользователей. Купер чётко на примерах показывает, почему когда программист делает продукт в соответствии со своими представлениями о правильности и целесообразности, этот продукт оказывается совершенно неприемлим для обычных пользователей.
Более того, Купер даёт читателю понимание как эти проблемы и противоречия между программистами и пользователями нужно преодолевать, чтобы создавать восстребованные на рынке продукты.
Отвечая на вопрос, вынесенный автором в заголовок своего топика, скажу: Linux в любых модификациях — это инструмент, созданный программистами в соответствии с их собственными представлениями о нужности, удобности и целесообразности. И эти представления зачастую не пересекаются такими же представлениями простых пользователей. Hint: натянуть графическую оболочку на коммандный интерпретатор, это самое начало пути.
Какой-то просто бред…
И как трщмайор предлагает поступать с самоорганизующимися безсерверными сетями типа ZigBee или той же LoRa?
Только вот поправить надо современные требования ГКРЧ к диапазону 868.
А значит, по-любому, ваш проект с его основным требованием он-лайн мониторинга невыполним.
Ибо то, что вы тут пишите, никакого отношения к LoRa не имеет. Я имею ввиду, что описываемый вами проект не имеет решения на базе LoRa — эта технология не позволяет вести мониторинг множества объектов в реальном времени «на пульте оператора». Вы, похоже, и не слышали, что девайс LoRaWAN должен вещать не более 1% времени, т.е. не более 15 минут в сутки. Вы будете получать только статусы с определенной задержкой — от одной до нескольких минут, ну и всякие алармы, а уж пока сообщение от оператора дойдет до конечного модуля — грузовик человека уже в лепешку раскатает.
И когда вы указали формат сообщения, стало совершенно очевидно, что сеть LoRa вы даже и не пытались развертывать. Идентификатор каждого из LoRaWAN модулей — DevAdr — передается не в составе сообщения, а отдельно, в служебной его части; и БС его всегда знает. Расходовать под него драгоценные байты payload message — дилетанство. Эти 5 драгоценных бит гораздо важнее израсходовать под TimeStamp — временную отметку измерения, ибо оператору будет очень важно понимать, когда именно были зафиксированны текущие координаты, ну и номер пакета, т.к. пакеты имеют свойство теряться.
Откуда взялась цифра в 37 бит для сообщения — мне тоже не понятно, т.к. по стандарту длинна PayloadMessage может меняться в зависимости от скорости передачи и по региональному стандарту для Европы (которого мы вроде бы придерживаемся) составляем минимум 51 байт. Байт. Bytes =/= bits.
В общем, искал по хабру больше информации про LoRa, а в результате сам читаю лекцию…
«Чем больше трудностей — тем лучше» — это гарантированный способ навсегда отвадить от предмета 99% обучаемых.
Ардуино по своей сути, по идеологии задумывалась как система, ОБЛЕГЧАЮЩАЯ освоение микроконтроллеров, как наиболее простой и лёгкий путь вхождения в эту очень большую и объёмную область знаний. Да, с огромными ногами, чтобы чуть-шо — можно было к ним подпаяться домашним паяльником. Да, с очень простой IDE, чтобы не пугать новичка кучей не совсем понятных действий по наладке. Да, с отнюдь не идельным кодом и с очень мягкой проверкой синтаксиса — всё для того, чтобы было проще начать работу.
Но нет! «Мы простых путей не ищем!» Правильно выше написали — надо было пример моргания лампочкой сразу для Целерона ваять!
Первое, с чего следовало бы начинать — не с обзора цен (взятых, прямо скажем, с примерно непонятно какого потолка), а с обзора производительности различных микроконтроллеров. Показать главное преимущество этой экосистемы: что под разные задачи можно выбирать совершенно разные кристаллы. Поморгать светодиодиком — и Аттиньки 8-ой хватит, Лору запустить (с правильным AES-ом) — уже и 328-ой ардуинки может не хватить. Дисплей красивый нарисовать — уже ES32 может не хватить. Ну и т.д. И показать в конце, почему под контроллер Умного Дома нужен именно STM32F. Это было бы системно.
А так получилось слишком алогично, а потому непонятно и спорно. «Моргать светодиодиком через STM32? Я вас умоляю!..»
По хорошему, ребрендинг делается только тогда, когда надо разорвать ассоциации у пользователей с одним сценарием, с одними привычками и ассоциациями, и задать другие. В вашем случае — частичного украшательства логотипа, «подгибания уголков» — не поменилось ничего, кроме суммы на счете у самой фирмы (в минус) и у Темы (в плюс). И раз большинство пользователей это изменение не заметит, то и выхлоп на рынке — нулевой. Вот если бы поработали с экспертами по юзабилити, переработали сайт под различные сценарии использования, кардинально сменили позиционирование на рынке, а попутно, со всеми этими изменениями еще и логотип поправили — вот это было бы другое дело. А так получилась тема «Как со студией Артема Лебедева правильнее отмывать маркетинговый бюджет».
свистелки и перделкинафиг никому не нужные украшательства.Да, и за слово «айдентика» вам уже приготовлено отдельное место в лингвистическом отделении ада.
> Меньше 50% держат телефон одной рукой.
Необходима привязка этой статистики к физическому размеру корпуса устройства или хотя бы диагонали экрана. Сейчас устройств очень много и они очень разные. От фаблетов с размером экрана 7" до китайских смартфончиков с экраном в 4,3". Разумеется, сценарии использования таких устройств будут совершенно разными.
1. Подобные системы многоязычного полу-автоматического перевода существуют по всему миру в количестве, которое не передается словом «много». Их очень много. И чем крупнее компания, тем на большее число языков они могут предложить подобный перевод. Так что идея стара, как… ладно, не будем. Лично мне приходится мучится с Lionbridge.
2. Весь автоматизм перевода в этих системах базируется на Translation Memory: базе данных, как какое слово нужно переводить. Так вот, для русского языка такой подход работает очень плохо. Наш язык очень слабо коррелирует с английским по своей структуре и правилам образования слов и фраз. Даже на простых, отдельных словах, нет 100% верного перевода, т.к. у нас слишком много значений для слов и терминов. А уж во фразах… Как-то что-то более-менее срабатывает на стандартных фразах типа «Для завершения настройки нажмите „Далее...“», но в тексте общеболтологического свойства такой подход уже дает сбой, а уж на маркетиновых фразах — не работает вообще. И тут мы переходим к следующему пункту.
3. Необходимость использования корректора. Человека, обладающего должной компетенцией как в языковых познаниях, так и в технических вопросах верстки текста на сайте и, главное, в той теме, которой посвящен сайт. Т.е. полного автоматизма все равно не получается. Причем, по поему опыту, даже если переводчик совершенно правильно и корректно набил Translation Memory, корректору все равно зачастую приходится переводить бОльшую часть текста практически с нуля. А зачастую «переводчиком» у нас (точнее — у них, на Западе) считается любой русскоговорящий эмигрант, даже если тройку по Русскому языку в школе ему поставили просто ради того, чтобы не оставлять «эту наглую рожу» на второй год. И ведь ничего не докажешь! Менеджер Lionbridge видит, что процент исправлений перевода для русского языка просто зашкаливает, пытается выяснить, почему так происходит — ты отвечаешь «Мы по-русски так не говорим!» — менеджер подключает к беседе «нашего специалиста по переводу Vasiliy Pupkin», а Вася на голубом глазу заявляет: «Я все делаю ко гайдлайнам системы! Какие ко мне претензии? Это у вас завышенные требования! Вы требуете художественного редактирования!» Слова «завышенные требования» ласкают слух менеджеру, т.к. они показывают, что мяч не на его стороне поля. Но с другой стороны, вроде бы как от клиента отрицательный фидбек, но и своего работника вроде бы как третировать не за что. Настырный менеджер делает несколько телодвижений, в результате которых ты пишешь подробную записку с объяснением основных ошибок переводчиков и правил перевода, после чего тебе дают слово, что обязательно учтут эти замечания… Но если Vasiya в школе учиться не хотел, то зачем ему сейчас что-то менять? В результате менеджер либо забивает на проблемы с русским языков, либо меняет позицию. Приходит новый — и все с начала…
4. Ну и главная беда всех этих систем — не видно контекст. Нет возможности посмотреть начальную верстку, увидеть на ней тот кусок, который ты сейчас переводишь, и хотя бы приблизительно оценить получающийся результат.
Все пока…
Начнем с кружек. встречал достаточно примеров очень изысканного дизайна, когда ручка имела небольшой выступ внизу дуги. В результате палец упирался в этот выступ, и удерживать чашку оказывалось очень удобно. Да и примеров разных чашек с держателями для чайных пакетиков, с лоточком для печенек и т.п. — миллион по всему интернету. Так что имеет смысл просто говорить о недоработках или находках в определенной модели.
По поводу манометров — в дайвинге этот прибор имеет важнейшее значение для самой жизни дайвера (показывает объем оставшегося воздуха в баллоне), поэтому там подобные вещи давно маркируют так, чтобы было понятно даже при замутненном состоянии разума (а это, кстати говоря, вполне обычное состояние при пребывании на глубине — все реакции организма заторможены, человек соображает медленнее). Стрелочка в красной зоне — «ПОРА ВСПЛЫВАТЬ!»
http://www.diskus.ru/media/2013/11/07/minimanometro_me%5B800l600%5D.jpg
По поводу английских розеток. Там не все так просто. Там целая система и идеология, которую продумали и реализовывали после Второй Мировой войны. Там и кольцевая система прокладывания проводки по квартире, и гарантированное положение фазы в розетке, и раздельные предохранители под квартиру/конкретного потребителя, и цветовая маркировка этих предохранителей. Так что говорить, что это было непродуманно — нельзя. Громоздко на сегодняшний момент — да. Требует переработки — возможно да, а возможно и нет. Пока англичан все устраивает.
А вот по поводу английских раковин — это, я считаю, архаизм. Когда-то это, может, и имело смысл, но сейчас явно является устаревшим. Слишком сложно и неоправданно. Часто в каком-нибудь баре видишь два таких крана в раковине и полное отсутствие затычки… вот и думай, как выкрутиться.
Со специализированными телефонами — теперь хороший пример в Московском Метрополитене, где на каждой станции размещены колонны экстренного вызова и информации.
http://www.msk.kp.ru/share/i/12/3706421/
Хотя тут тоже пример своеобразный. Во-первых, они попытались убить двух зайцев: SOS и info. Это разные сценарии, за которые отвечают разные службы, но не разводить же два вида колонн? В результате получился такой вот страшный гибрид, который еще надо весь прочитать, чтобы понять, как им правильно пользоваться.
Я бы понатыкал простейших коммуникаторов SOS по несколько штук вдоль каждого перрона — в случае ЧП счёт идет на секунды, разбираться некогда. Зачастую важно просто нажать Большую Красную Кнопку. А стойка с информацией — она и есть стойка с информацией… Пусть стоит себе одна посреди зала.
Вольный перевод оригинала, который ни к оригинальной статье, ни к реальному положению вещей отношения не имеет.
Та версия OS Android, которую производитель получает по бесплатной лицензии, не имеет в себе никаких сервисов Google. Это всякого рода электронные книжки, плееры и т.п. электроника, в которой вы никогда не найдете Google Play, Gmaps, Gmail и т.п. Если OEM хочет поставить на устройства сервисы Google, то ему надо оплачивать Google Apps suite.
Претензии у перечисленных компаний не к процессу оплаты, а к тому, что иконки на эти приложения «обязаны размещаться ключевых местах интерфейса телефона», а так же к тому, что стоимость лицензионных отчислений, собираемых Google, настолько мала, что остальные игроки не могут с ним (с ней?) состязаться.
И вот тут у меня возникают вопросы… А что, собственно, мешает той же Microsoft, для которой, как и для Google, мобильное подразделение — далеко не основной источник доходов в рамках глобальной корпорации, перераспределить финансы, обеспечив конкурентную стоимость лицензий для своей мобильной ОС, так же как это сделал Google? Я без наезда, я просто интересуюсь… Или гораздо проще натравить ловеров, чем ломать внутренний финансовый план?
Хотел было спросить: «А к чему процессор?» Ибо чуть на других индикаторах, но тем не менее точно такие же по функциональности часы делал лет 20 назад на простой россыпухе микросхем, но потом увидел фразу у автора:
>А если честно, то при изготовлении этих часов акцент ставился не на схемное решение.
… и все вопросы отпали.
В реально крупных компаниях, занимающихся программными продуктами, все обстоит совсем по-другому. Как и положено, чем крупнее фирма, тем более раздробены роли каждого.
Например в той фирме, где работаю сейчас я, всё ПО и вся документация к нему изначально создаются на английском языке (а не на русском, как в ABBYY). По мере создания ПО те строки, которые отмеченны, как подлежащие переводу, попадают к переводчикам (в каждой стране и в каждом регионе — свои партнёры по переводу). При этом переводчики зачастую переводят «в слепую», ибо продукт вообще не готов и его нельзя ни поставить, ни как-либо посмотреть. Параллельно с этим создаётся вся необходимая документация (разумеется, включая User Manual) — создаётся именно Техническими Писателями, но создаётся она опять-таки только на английском языке и для той первоначальной версии, которая соответствует техническому заданию. Еще одна особенность — документация верстается так, чтобы все термины и названия элементов интерфейса подтягивались автоматически при вёрстке из DB переводов. Затем, когда продукт выходит на стадию тестирования, помимо команды тестировщиков, его смотрит и региональный технический менеджер в каждом из регионов.
И вот тут-то и начинается самое интересное. В зависимости от региона, требования к продукту могут меняться (например, в РФ запрещён импорт криптостойких несертифицированных решений, поэтому для РФ такой код должен исключаться из ПО). Да, подобные вещи, разумеется, должны бы учитываться на этапе проектирования, но мы помним, что фирма очень крупная, и не всегда все можно решить заранее. Вот и приходится «резать по живому». Но это самая малая из возможных бед. В разных языках длинна слов — различна. Не мне рассказывать, что русские фразы в большинстве своём длиннее английских. Региональному менеджеру приходится при этом играть роль и корректора (исправлять кривой перевод), и технического писателя (подбирая наиболее подходящий по смыслу, но более лаконичный перевод), и дизайнера интерфейсов (писать письма ДИ типа: «А нельзя ли здесь расположение кнопок поменять, снять „bold“ с комментария и чуть расширить текстовый блок, т.к. при любом раскладе нам нужно минимум 3 строки, а не 2»). Очень часто, после того, как проходит этап review, на котором локальные менеджеры должны были исправить перевод, вся документация ребилдится заново, дабы подхватить внесенные в перевод интерфейса исправления. И эта документация проверяется менеджежером еще раз, уже на предмет соответствия интерфейсу.
Так что в рамках нашей фирмы вот этот региональный менеджер и правит документацию, и исправляет перевод, и корректирует интерфейс, и разумеется, параллельно еще и тестирует продукт по ходу дела.
Но если вернуться к теме топика и заданному в его начале вопросу — «Кто лучше всех знает продукт?» — то я не буду утверждать, что это именно многорукий и такой универсальный локальный менеджер. Во-первых, он не в курсе происходящего в других регионах, а во-вторых, он видит только текущую версию, которую ему передали для проверки и тестирования. Я бы сказал, что лучше и полнее всех знает продукт только его Системный Архитектор. Это тот, кто отвечает не только за реализацию текущей версии (это, как мы помним, делает DM), а кто изначально составлял техническое описание продукта для выработки из него ТЗ, кто сейчас по информации, поступающей от аналитиков, корректирут Product Strategy, кто взаимодействуя с PM, определяет текущую конфигурацию продукта с прицелом и «на сейчас», и на длительное будущее.
Привычные для всех других языков компьютерные словари для автозамены нервно курят в сторонке, когда речь заходит про русский язык. У нас слишком высока вариативность слов. Русскоязычную систему проверки орфографии невозможно построить, не создав перед этим алгоритм анализа морфологии (образования словоформ из исходного слова). А создание такой морфологии для русского языка — это сама по себе задача аховая. Я только одну фирму знаю, где с этой задачей более-менее справились (фирма есть на хабре, не буду называть, дабы не упрекнули в пиаре), во всех остальных случаях, насколько мне известно, делаются попытки тупо набить словарь, что неизбежно приводит к казусам и ошибкам (как в истории с Win8).
Одно замечание, чисто из любопытства: как так получается, что код 4636 на устройстве HTC работает, а в программе — не находится и не отображается? Программа не находит его в манифестах? Любопытно… Если она не находит этот код, то, может, она не находит и какие-то другие?