При таком ЧП времени подумать, будет там гидрак крутить не будет — нету в принципе, всё делается на рефлексах. Я вполне допускаю, что обученные профи, или у кого подобная ситуация уже возникала — будут действовать по другому. Но, эта не та вещь, которой учат «обычных» водителей.
Всё событие уложилось секунд в 5, наверное.
Обрезало. Рывок. 1-2 секунды — понять что вообще за нах (вся приборка потухла). Начать «уход» с полосы — еще 1-2 сек. Понять, что просто не уеду, встану раньше, да еще «почуять» что сзади «накатывают» (движение в зеркале фиксируется «само собой» — его не видишь, а «жопой чуешь»). Отжать сцепуху — и убраться наконец на обочину — еще пара секунд.
Уф. А вот теперь — можно еще и выдохнуть…
И! Важно! Я не утверждаю, что я был прав! Вполне возможно, что надо было действовать по другому. Кто-б еще научил — как…
Кстати, на современных машинах (привет электроусилителю руля) — расклад тоже будет другой… Выжимай, не выжимай, если «упало» всё питание — руль как на камазе сразу.
В теории — вы правы.
А на практике — я шел на 4-й или даже еще 3-й передаче (только вышел на трассу — разгонялся еще), и на скорости порядка 90, рывок торможения был ого какой, и если бы не выжал — я-б просто встал на полосе, а сзади мне точно прилетело бы, поток был довольно плотный. А торможение-то без стопарей, тормоз же не нажат!
Вообще, рывок был неожиданно сильным. Все-таки работающий двигатель, даже при полностью брошенном газе тормозит гораздо слабее чем заглохший, видимо даже «холостое» количество бензина сильно облегчает вращение, выяснил, так сказать, опытным путём…
К слову — в горах, даже небольших, про нейтралку надо вообще забыть, если жить охота. И на спусках тормозить лучше двигателем (или 50/50 — двигатель + тормоза). Потому что:
а) на затяжном спуске спалить тормоза — как нефиг делать, особенно если в грузу
б) при отказе тормозной — на нейтралке можно просто тупо не успеть воткнуть скорость/ручник, особенно в повороте
Да и не в горах — я на нейтралке вообще не езжу. Никогда. Потому что в любой момент по любой неожиданной причине может понадобиться тяга для маневра — и можно просто не успеть воткнуть передачу.
Как минимум, при вертикальном монтаже резисторов, очень вероятно, что из за вибраций он своим выводом до чего нибудь дотронется. Да и транзисторы не мешало бы закрепить.
Это маловероятно. А вот обломиться или потерять нижний контакт от усталостных трещин — вполне реально. Не быстро, но лет через 5 — вполне. Сильно зависит от ориентации платы относительно земли.
Плохого — нет.
Но технология не стабильна. И может давать скрытые дефекты (частично перетравленые дорожки, с истончившейся фольгой), окончательно рвущиеся при термоциклировании и вибрации.
Вероятность такого события все-таки не шибко высока. И, главное, такое может произойти и на «нормальной» машине. Говорю уверенно — ибо было у меня самого. Старый Пассат, обычный замок зажигания. Были проблемы с запуском (просто выгоревший контакт, да) — съездил в сервис, типа сделали.
Еду домой — на трассе (правда не на обгоне а в правом ряду) — и тут движок «обрезало». Б… ь. Ощущение — супер просто.
На пассате, к слову, — гидрак на рулевом. Т.е. мало того — что довольно резко «тормознул двигателем» (это быстро решилось отжатым сцеплением — рефлекторно, чтобы не въехали сзади) — так еще и рулем ворочать стало совсем не айс.
К слову, проблема была в том, что сервисники, собаки, заменив контактную группу в замке «недовоткнули» разъем, и он тупо выпал.
Статья интересная, да.
Но я-б не рискнул ездить с такой доработкой. Во всяком случае — за город и зимой точно.
Все-таки ардуина и ЛУТ — не самые годные компоненты для авто.
Вибрации и дикий диапазон температур (-40 — +80 под капотом) могут доконать девайс в самый неподходящий момент. И если летом и в городе варианты от «убить бендикс» до «не завестись и ждать эвакуатор» просто неприятны, то зимой те же упражнения где-нито в поле ночью — уже печаль.
Как минимум — оставил бы штатные механические цепи + возможность отключения приблуды.
Делаем Х пусков на низкие орбиты. И последний пуск без возврата, на максимум. Вполне себе неплохо будет.
На самом деле — во всём этом супе критическим моментом является реальное снижение надежности для повторных пусков.
Не расчетное, а именно реальное. А его могут выявить только испытания.
Вот, когда налетает 30-40 взлет-посадок — тогда будут ясны реальные перспективы.
Вот только, нам уже догонять тогда будет поздновато…
С одной стороны — реклама — это плохо. Но с другой — поиск хорошего поставщика — та еще задача…
Я думаю, можно убрать под спойлер, кому надо — развернет. А кому не надо — глаза мозолить не будет.
Хинт как по ховеру, так и по тапу (помним про тачи)
А вот про «пальцами расдвигайте, сдвигайте» это вам надо немного почитать про touch events. Если коротко — сейчас это нереализуемо. Т.к. мультитач события пока поддерживаются… не очень. А «сдвигать — раздвигать» перехватываются самим браузером. Есть способы это блокировать. Но, там, опять-же, проблемы совместимости.
В общем — можно — но сложно. Но! Главное не нужно так делать.
Потому что вы забыли, что пользователю еще надо догадаться что у вас есть такая фишка — навести курсор на колонку — покрутить колесо (ну или «пораздвигать» для тач-устройств)
Так что с точки зрения практического применения — вариант сделать сокращение + сноску оформленную как ссылка и обрабатывать тап/клик на ячейку является лучшим. Поясню почему.
Можно (и это проще всего) сделать просто обработку тапа/клика на саму ячейку заголовка. По клику — заменять на полный текст или показывать балун или выводить пояснение выше/ниже — масса вариантов.
Но! Тут есть засада из-за которой и появляется "+ сноску оформленную как ссылка " — засада в том, что на десктопе у вас есть ховер, и есть курсор, меняющийся при ховере. И есть высокая вероятность, что юзер хотя-бы и случайно протащит курсор по заголовкам и увидит что там что-то есть интерактивное.
А вот на таче — юзер как-то должен догадаться что надо ткнуть на заголовок.
Вот, чтобы ему такую догадку дать — мы и ставим вот такую 1 сноску, оформленную как ссылка.
Тут уже у пользователя с большой долей вероятности возникнет желание в нее потыкать — и он увидит вашу красоту с расшифровкой колонки (как бы она ни выглядела).
Кстати вот идея: крутишь колесико мышки и длинная по горизонтали таблица сжимается и остаются только начала слов, затем подводишь мышку к тому столбцу, который тебя интересует, крутишь колесико мышки обратно и таблица расжимается. удобно? или sarcasm> Вы мышкой без колесика пользуетесь</sarcasm
<sarcasm Ну и правда, куда мне с моим убогим безколесным планшетом до вашего ээээ… Хм.., колесного айфона?/sarcasm>
Вообще-то именно поэтому я продолжаю с Вами дискуссию. Вы никак не хотите остановиться на 5 минут и подумать «а что в моей замечательной идее может пойти не так?»
Поймите, критический взгляд на вещи — это основа образа мышления хорошего программиста.
Ибо хороший программист тратит только 20% времени на код который делает то что надо и 80% времени тратит на код — который не позволит пользователю выстрелить себе в ногу ни при каких условиях.
Скажите, а почему Вы пользуетесь интернетом вообще? Ведь книжки читать именно Вам намного приятнее, не так ли? Наверное потому что удобно.
Уважаемый, не надо переходить на личности и, хм, абстракции к теме статьи слабо относящиеся. Право слово, оно того не стоит.
Я видел ваш коммент про транспонирование. Но и вы могли бы обратить внимание на акцент «данная таблица» и «выделил отдельно, ввиду важности». Я постарался конкретно указать почему в данном случае этот метод применим и хорош.
К слову, крутить можно и по горизонтали. Иногда это даже лучше. Скорее даже изредка. Но такие случае в практике мне встречались. Чаще всего это применимо — когда присутствует временная шкала. Она хорошо воспринимается по горизонтали.
нужно заняться оптимизацией данных — абсолютно согласен, так и сделаю, устроюсь разработчиком интерфейсов, мне дадут какую-нибудь таблицу, а я и скажу — что Вы мне тут подбрасываете, нужно оптимизировать данные и сразу перейду на вакансию по проектировке БД.
Хм. Вообще-то взаимодействие между фронтэнд и бэкэнд разработчиками должно быть всегда. Равно как и с постановщиками задач и заказчиком. И, если вы видите явный косяк в данных — вы не просто можете, а должны принять меры к его устранению.
И, да, не всегда получится. Могут и «послать». Но, позиция «я не я, корова не моя», «это не моя проблема — сказали копать отсюда и до обеда — я и копаю» это не есть гут.
Нужен реальный пример, дайте реальный пример из реальной жизни, и я постараюсь показать Вам, как это можно сделать.
Вот, не дам я вам примера. Ни в одном проекте у меня такого нет, чтобы подписи не лезли горизонтально.
Приведенных мной мер по оптимизации всегда хватало.
Есть еще один «трюк» — специфичный, потому не упомянул в общем списке — использование «раскрывающихся» строк. Когда в таблице видны основные данные, а по клике на строку — открываются детали с бОльшим числом колонок. Тут нюанс в том, что это применимо когда «дополнительные» данные не требуют визуального сравнения между строками, а нужны для уточнения.
Пример:
А еще есть «многоэтажные» строки (привет 1С). Это когда каждая строка разбита на две и более подстроки. Подписи, в шапке, повторяют эту структуру. Ааа… Щас сделаю, короче картинку. На словах сложно. Вот:
В общем, этот ваш «полосатый рейс table» это круто. Но, эм, как произведение искусства. Но не не как инструмент для реального использования. ИМХО, конечно.
Продолжение на тему Кстати а Вы что предлагаете? Во первых — используем возможности html — применение сокращений + хинт + сноска на расшифровку. Хинт как по ховеру, так и по тапу (помним про тачи). Клик на сноску — показ балуна с расшифровой — дабы не скролить и не угонять фокус внимания. Во вторых — нужно заняться оптимизацией самих исходных данных. Рассмотреть, нельзя ли сократить длинные подписи. Оценить длину данных в колонках. В третьих — данная таблица отлично транспонируется (меняем колонки на строки и наоборот). Обратите внимание — длина «2014г» практически равна цифрам. И число колонок и столбцов почти равно тоже. Да, не всегда это применимо. Но конкретно тут — сработает отлично. Вообще, это относится к п.2 (оптимизация данных) — но выделил отдельно, ввиду важности. Почему-то забывают про этот метод часто. В четвертых — вспоминаем правила оформления таблиц для научных работ. Все уже украдено изобретено до нас. Группировка, вынос общих частей, нумерованные столбцы с расшифровкой и т.д.
Головка состоит из слова или короткого предложения, описывающего содержание столбца. При необходимости в нее помещают принятые единицы измерения через запятую после слова или предложения, описывающего содержание столбца.
Иногда нет необходимости приводить в головке описательные сведения; в подобных случаях в ней размещают единицы измерения.
В головках столбцов символы, обозначающие переменные величины, следует применять с осторожностью, если сами переменные не названы. Читатель, ознакомившись с названием таблицы и сопровождающим его примечанием, должен сразу же понять, что обозначает символ. Следует, в частности, избегать применения символов “N” и “n” без разъяснения. Вместо этого следует писать “Число больных” или “Больные (n)”.
Поскольку ширина страницы (полосы) ограничена, в головках столбцов следует широко использовать аббревиатуры и символы. В то же время следует иметь в виду, что сокращения слов (например, забол., б-ные, дн., средн., продолжит., положит. и т.п.) недопустимы; в данном случае слова пишутся целиком. Все аббревиатуры и символы, которые использованы в таблицах, должны быть расшифрованы в примечаниях к ней. Если такие аббревиатуры встречаются в таблицах, расположенных на одной и той же полосе или на развороте, их достаточно расшифровать только в первой из таблиц.
Для экономии места на полосе общие элементы расположенных рядом столбцов можно объединить в блок; при этом элементы головки, общие для каждого из столбцов, становятся головкой блока.
Если используется блок, то каждый входящий в него столбец должен иметь собственную головку (подзаголовок).
Единицы измерения располагают в головке столбцов, если они относятся только к одному них. Если единицы измерения — элемент, общий для двух столбцов или более, их следует вынести в головку блока. При этом единицы указывают через запятую после названия головки (подзаголовка).
Следует стремиться использовать не более двух уровней подзаголовков.
Если блок объединяет данные, помещенные во всех столбцах таблицы, в нем нет необходимости; его роль переходит к названию таблицы.
В блок никогда не входит столбец боковика.
(цельнотянуто отсюда чутка порезал выделив актуальное для нашего случая — по ссылке посмотрите целиком)
Вариант с вертикальными заголовками не плотнее, он занимает столько же места по ширине, что и вариант с горизонтальными заголовками.
Места — в смысле ширны таблицы — столько же. Но вот свободное место распределено по разному. В первом варианте — равномерно и нормально читается. Во втором — у вас справа огромное белое поле, а в колонках данных паддинги зажаты. Еще слева-вверху пусто. Это тоже следствие самого принципа.
Я не дизайнер. Я смею предположить, что Вы — не верстальщик. Код как раз таки тривиальный и работает под Netscape 4.7 от 2000 года (можно сделать, если подумать), потому что это colspan и rowspan, эти аттрибуты знает любой верстальщик.
Я не верстальщик, я ведущий инженер-программист. И я говорил не про html код, а про код формирующий html, прочтите внимательно.
Нормальным «foreach($columns as $column){}» для вывода тут ни разу не обойтись. От слова совсем.
Вам под каждую новую таблицу придется или писать новый код, или втыкать заголовок статикой (и править руками для каждого нового случая, для любой перестановки колонок, изменения подписей и т.п.)
Хуже того, для многоязычной системы внешний у вас вообще все будет «ползти» самым непредсказуемым образом (длина переводов на разных языках разная, и даже соотношение между длинами будет меняться). Также будет беда при сильно разной длине как данных, так и подписей (там вообще все плохо — сами попробуйте)
Разумеется, я не обсуждаю вопрос школьного сайта со статическими html страницами-же написанными в блокноте на одном языке…
Пронумеруем номера столбцов:
Я имел ввиду — пронумеровать подписи колонок. Расставьте там номер. Что будет? Будет пила причем снизу вверх что для Русского не характерно, мы таки не китайцы. Можно, наверное поменять и сверху-вниз, один черт — пила, будут возвраты вверх.
Там, ниже, критикуют, «чего мол доколебался до юного гения». Да, как-бы, мне жалко как программистов, которые рискнут это сделать не в «образцовой» статике, а в реальном коде, с переменным числом столбцов, меняющимися подписями, переводами и т.п. Так и пользователей, попытающихся скопировать, например, такую табличку в Еxcel (ага, ага, ваши полоски при этом — того… пропадут, и понять куда какая колонка относится — станет совсем легко, да)
Понимаете в чем засада? Оценивая любое такое новшество / предложение хороший программист должен в первую очередь думать «а что тут может пойти не так?
Это не попытка докопаться. А попытка спрогнозировать дальнейший жизненный цикл изобретения.
Черт. Длинно. Предложения „а как бы вы“ ниже напишу отдельно.
Я пока не встречал минификаторов делающих алиасы для системных функций. Видимо вот поэтому
И, я не говорю, что это невозможно — я вообще-то попросил ссылку на такой умный минификатор.
И, да, еще потерял, справа от последней колонки данных остается дофига много свободного места. И тем больше — чем длиннее подпись к последней колонке (ну или очень длинно у любой предыдущей).
Т.е. «масштабируемость» решения (применимость к другому набору данных/подписей) — тоже никакая
Использование цвета как основного носителя информации о чем-либо (в данном случае — для сопоставления данных и подписей) — категорически плохая идея. В градациях серого или, еще хуже, у людей с нарушениями восприятия цвета всё будет печально.
Далее — цветовые (контрастные серые при выводе в монохроме, что еще хуже) полосы пересекающие текст подписей (особенно нижнего ряда, по 4 штуки!) это вообще жесть. Общая читабельность текста из-за такой визуальной «нарезки» подписей — ниже плинтуса.
Для формирования такого мега-заголовка (в html) нужен совсем нетривиальный код, вставка, добавление перемещение колонок — реальная попоболь. Даже просто понять «потом» где в коде данные от нужного заголовка или где заголовок от нужных данных — оооой…
Визуальный порядок следования подписей нарушен. Да. Определить где подпись от конкретного столбца — можно. Но, просто попробуйте выписать названия столбцов по порядку (как вариант — пронумеровать столбцы — это чуть проще) — сразу поймете о чем я.
В общем, типичный «дизайнерский подход». Главное — чтобы было красиво. Ага.
Уже много недостатков отметили выше, добавлю еще пять копеек.
Самая большая лажанечестность тут:
Отсутствие движущихся частей раскрывает еще одно серьезное преимущество такой технологии – минимальную потребность и стоимость техобслуживания.
Движущихся частей тут более чем достаточно. Это и компрессоры и турбины.
Более того, и сами мешки и их крепления — тоже испытывают знакопеременные механические деформации, очень нехорошие по своей природе, вызывающие усталостное разрушение.
Также, есть проблема обрастания (подводной флорой и фауной) — а это то самое техобслуживание.
Подбор материала устойчивого одновременно ко всем этим факторам — особенно биологическому — это реальная попоболь. Т.к. это всё нельзя проверить быстро, и т.к. будут радикальные различия для разных водоемов и климата.
Добавить к этому годовые циклы. То самое тепловое загрязнение, о котором уже говорили и которое само по себе будет менять флору и фауну в районе мешков…
При таком ЧП времени подумать, будет там гидрак крутить не будет — нету в принципе, всё делается на рефлексах. Я вполне допускаю, что обученные профи, или у кого подобная ситуация уже возникала — будут действовать по другому. Но, эта не та вещь, которой учат «обычных» водителей.
Всё событие уложилось секунд в 5, наверное.
Обрезало. Рывок. 1-2 секунды — понять что вообще за нах (вся приборка потухла). Начать «уход» с полосы — еще 1-2 сек. Понять, что просто не уеду, встану раньше, да еще «почуять» что сзади «накатывают» (движение в зеркале фиксируется «само собой» — его не видишь, а «жопой чуешь»). Отжать сцепуху — и убраться наконец на обочину — еще пара секунд.
Уф. А вот теперь — можно еще и выдохнуть…
И! Важно! Я не утверждаю, что я был прав! Вполне возможно, что надо было действовать по другому. Кто-б еще научил — как…
Кстати, на современных машинах (привет электроусилителю руля) — расклад тоже будет другой… Выжимай, не выжимай, если «упало» всё питание — руль как на камазе сразу.
А на практике — я шел на 4-й или даже еще 3-й передаче (только вышел на трассу — разгонялся еще), и на скорости порядка 90, рывок торможения был ого какой, и если бы не выжал — я-б просто встал на полосе, а сзади мне точно прилетело бы, поток был довольно плотный. А торможение-то без стопарей, тормоз же не нажат!
Вообще, рывок был неожиданно сильным. Все-таки работающий двигатель, даже при полностью брошенном газе тормозит гораздо слабее чем заглохший, видимо даже «холостое» количество бензина сильно облегчает вращение, выяснил, так сказать, опытным путём…
К слову — в горах, даже небольших, про нейтралку надо вообще забыть, если жить охота. И на спусках тормозить лучше двигателем (или 50/50 — двигатель + тормоза). Потому что:
Да и не в горах — я на нейтралке вообще не езжу. Никогда. Потому что в любой момент по любой неожиданной причине может понадобиться тяга для маневра — и можно просто не успеть воткнуть передачу.
Это маловероятно. А вот обломиться или потерять нижний контакт от усталостных трещин — вполне реально. Не быстро, но лет через 5 — вполне. Сильно зависит от ориентации платы относительно земли.
Но технология не стабильна. И может давать скрытые дефекты (частично перетравленые дорожки, с истончившейся фольгой), окончательно рвущиеся при термоциклировании и вибрации.
Еду домой — на трассе (правда не на обгоне а в правом ряду) — и тут движок «обрезало». Б… ь. Ощущение — супер просто.
На пассате, к слову, — гидрак на рулевом. Т.е. мало того — что довольно резко «тормознул двигателем» (это быстро решилось отжатым сцеплением — рефлекторно, чтобы не въехали сзади) — так еще и рулем ворочать стало совсем не айс.
К слову, проблема была в том, что сервисники, собаки, заменив контактную группу в замке «недовоткнули» разъем, и он тупо выпал.
Но я-б не рискнул ездить с такой доработкой. Во всяком случае — за город и зимой точно.
Все-таки ардуина и ЛУТ — не самые годные компоненты для авто.
Вибрации и дикий диапазон температур (-40 — +80 под капотом) могут доконать девайс в самый неподходящий момент. И если летом и в городе варианты от «убить бендикс» до «не завестись и ждать эвакуатор» просто неприятны, то зимой те же упражнения где-нито в поле ночью — уже печаль.
Как минимум — оставил бы штатные механические цепи + возможность отключения приблуды.
На самом деле — во всём этом супе критическим моментом является реальное снижение надежности для повторных пусков.
Не расчетное, а именно реальное. А его могут выявить только испытания.
Вот, когда налетает 30-40 взлет-посадок — тогда будут ясны реальные перспективы.
Вот только, нам уже догонять тогда будет поздновато…
С одной стороны — реклама — это плохо. Но с другой — поиск хорошего поставщика — та еще задача…
Я думаю, можно убрать под спойлер, кому надо — развернет. А кому не надо — глаза мозолить не будет.
А вот про «пальцами расдвигайте, сдвигайте» это вам надо немного почитать про touch events. Если коротко — сейчас это нереализуемо. Т.к. мультитач события пока поддерживаются… не очень. А «сдвигать — раздвигать» перехватываются самим браузером. Есть способы это блокировать. Но, там, опять-же, проблемы совместимости.
В общем — можно — но сложно. Но! Главное не нужно так делать.
Потому что вы забыли, что пользователю еще надо догадаться что у вас есть такая фишка — навести курсор на колонку — покрутить колесо (ну или «пораздвигать» для тач-устройств)
Так что с точки зрения практического применения — вариант сделать сокращение + сноску оформленную как ссылка и обрабатывать тап/клик на ячейку является лучшим. Поясню почему.
Можно (и это проще всего) сделать просто обработку тапа/клика на саму ячейку заголовка. По клику — заменять на полный текст или показывать балун или выводить пояснение выше/ниже — масса вариантов.
Но! Тут есть засада из-за которой и появляется "+ сноску оформленную как ссылка " — засада в том, что на десктопе у вас есть ховер, и есть курсор, меняющийся при ховере. И есть высокая вероятность, что юзер хотя-бы и случайно протащит курсор по заголовкам и увидит что там что-то есть интерактивное.
А вот на таче — юзер как-то должен догадаться что надо ткнуть на заголовок.
Вот, чтобы ему такую догадку дать — мы и ставим вот такую 1 сноску, оформленную как ссылка.
Тут уже у пользователя с большой долей вероятности возникнет желание в нее потыкать — и он увидит вашу красоту с расшифровкой колонки (как бы она ни выглядела).
<sarcasm Ну и правда, куда мне с моим убогим безколесным планшетом до вашего ээээ… Хм.., колесного айфона?/sarcasm>
Вообще-то именно поэтому я продолжаю с Вами дискуссию. Вы никак не хотите остановиться на 5 минут и подумать «а что в моей замечательной идее может пойти не так?»
Поймите, критический взгляд на вещи — это основа образа мышления хорошего программиста.
Ибо хороший программист тратит только 20% времени на код который делает то что надо и 80% времени тратит на код — который не позволит пользователю выстрелить себе в ногу ни при каких условиях.
Уважаемый, не надо переходить на личности и, хм, абстракции к теме статьи слабо относящиеся. Право слово, оно того не стоит.
Я видел ваш коммент про транспонирование. Но и вы могли бы обратить внимание на акцент «данная таблица» и «выделил отдельно, ввиду важности». Я постарался конкретно указать почему в данном случае этот метод применим и хорош.
К слову, крутить можно и по горизонтали. Иногда это даже лучше. Скорее даже изредка. Но такие случае в практике мне встречались. Чаще всего это применимо — когда присутствует временная шкала. Она хорошо воспринимается по горизонтали.
Хм. Вообще-то взаимодействие между фронтэнд и бэкэнд разработчиками должно быть всегда. Равно как и с постановщиками задач и заказчиком. И, если вы видите явный косяк в данных — вы не просто можете, а должны принять меры к его устранению.
И, да, не всегда получится. Могут и «послать». Но, позиция «я не я, корова не моя», «это не моя проблема — сказали копать отсюда и до обеда — я и копаю» это не есть гут.
Вот, не дам я вам примера. Ни в одном проекте у меня такого нет, чтобы подписи не лезли горизонтально.
Приведенных мной мер по оптимизации всегда хватало.
Есть еще один «трюк» — специфичный, потому не упомянул в общем списке — использование «раскрывающихся» строк. Когда в таблице видны основные данные, а по клике на строку — открываются детали с бОльшим числом колонок. Тут нюанс в том, что это применимо когда «дополнительные» данные не требуют визуального сравнения между строками, а нужны для уточнения.
А еще есть «многоэтажные» строки (привет 1С). Это когда каждая строка разбита на две и более подстроки. Подписи, в шапке, повторяют эту структуру. Ааа… Щас сделаю, короче картинку. На словах сложно. Вот:
В общем, этот ваш «полосатый
рейсtable» это круто. Но, эм, как произведение искусства. Но не не как инструмент для реального использования. ИМХО, конечно.Кстати а Вы что предлагаете?Во первых — используем возможности html — применение сокращений + хинт + сноска на расшифровку. Хинт как по ховеру, так и по тапу (помним про тачи). Клик на сноску — показ балуна с расшифровой — дабы не скролить и не угонять фокус внимания.
Во вторых — нужно заняться оптимизацией самих исходных данных. Рассмотреть, нельзя ли сократить длинные подписи. Оценить длину данных в колонках.
В третьих — данная таблица отлично транспонируется (меняем колонки на строки и наоборот). Обратите внимание — длина «2014г» практически равна цифрам. И число колонок и столбцов почти равно тоже. Да, не всегда это применимо. Но конкретно тут — сработает отлично. Вообще, это относится к п.2 (оптимизация данных) — но выделил отдельно, ввиду важности. Почему-то забывают про этот метод часто.
В четвертых — вспоминаем правила оформления таблиц для научных работ. Все уже
украденоизобретено до нас. Группировка, вынос общих частей, нумерованные столбцы с расшифровкой и т.д.(цельнотянуто отсюда чутка порезал выделив актуальное для нашего случая — по ссылке посмотрите целиком)
Места — в смысле ширны таблицы — столько же. Но вот свободное место распределено по разному. В первом варианте — равномерно и нормально читается. Во втором — у вас справа огромное белое поле, а в колонках данных паддинги зажаты. Еще слева-вверху пусто. Это тоже следствие самого принципа.
Я не верстальщик, я ведущий инженер-программист. И я говорил не про html код, а про код формирующий html, прочтите внимательно.
Нормальным «foreach($columns as $column){}» для вывода тут ни разу не обойтись. От слова совсем.
Вам под каждую новую таблицу придется или писать новый код, или втыкать заголовок статикой (и править руками для каждого нового случая, для любой перестановки колонок, изменения подписей и т.п.)
Хуже того, для многоязычной системы внешний у вас вообще все будет «ползти» самым непредсказуемым образом (длина переводов на разных языках разная, и даже соотношение между длинами будет меняться). Также будет беда при сильно разной длине как данных, так и подписей (там вообще все плохо — сами попробуйте)
Разумеется, я не обсуждаю вопрос школьного сайта со статическими html страницами-же написанными в блокноте на одном языке…
Я имел ввиду — пронумеровать подписи колонок. Расставьте там номер. Что будет? Будет пила причем снизу вверх что для Русского не характерно, мы таки не китайцы. Можно, наверное поменять и сверху-вниз, один черт — пила, будут возвраты вверх.
Там, ниже, критикуют, «чего мол доколебался до юного гения». Да, как-бы, мне жалко как программистов, которые рискнут это сделать не в «образцовой» статике, а в реальном коде, с переменным числом столбцов, меняющимися подписями, переводами и т.п. Так и пользователей, попытающихся скопировать, например, такую табличку в Еxcel (ага, ага, ваши полоски при этом — того… пропадут, и понять куда какая колонка относится — станет совсем легко, да)
Понимаете в чем засада? Оценивая любое такое новшество / предложение хороший программист должен в первую очередь думать «а что тут может пойти не так?
Это не попытка докопаться. А попытка спрогнозировать дальнейший жизненный цикл изобретения.
Черт. Длинно. Предложения „а как бы вы“ ниже напишу отдельно.
поэтому
И, я не говорю, что это невозможно — я вообще-то попросил ссылку на такой умный минификатор.
И, насчет «видел» — чтобы далеко-то не ходить… С текущей страницы скрипт, минифицированный:
http://habracdn.net/habr/javascripts/1450359574/assets/global_main.js
Эм. Дайте
двассылку плиз. Видимо я динозавр совсем дремучий…дофигамного свободного места. И тем больше — чем длиннее подпись к последней колонке (ну или очень длинно у любой предыдущей).Т.е. «масштабируемость» решения (применимость к другому набору данных/подписей) — тоже никакая
Далее — цветовые (контрастные серые при выводе в монохроме, что еще хуже) полосы пересекающие текст подписей (особенно нижнего ряда, по 4 штуки!) это вообще жесть. Общая читабельность текста из-за такой визуальной «нарезки» подписей — ниже плинтуса.
Для формирования такого мега-заголовка (в html) нужен совсем нетривиальный код, вставка, добавление перемещение колонок — реальная попоболь. Даже просто понять «потом» где в коде данные от нужного заголовка или где заголовок от нужных данных — оооой…
Визуальный порядок следования подписей нарушен. Да. Определить где подпись от конкретного столбца — можно. Но, просто попробуйте выписать названия столбцов по порядку (как вариант — пронумеровать столбцы — это чуть проще) — сразу поймете о чем я.
В общем, типичный «дизайнерский подход». Главное — чтобы было красиво. Ага.
Самая большая
лажанечестность тут:Движущихся частей тут более чем достаточно. Это и компрессоры и турбины.
Более того, и сами мешки и их крепления — тоже испытывают знакопеременные механические деформации, очень нехорошие по своей природе, вызывающие усталостное разрушение.
Также, есть проблема обрастания (подводной флорой и фауной) — а это то самое техобслуживание.
Подбор материала устойчивого одновременно ко всем этим факторам — особенно биологическому — это реальная попоболь. Т.к. это всё нельзя проверить быстро, и т.к. будут радикальные различия для разных водоемов и климата.
Добавить к этому годовые циклы. То самое тепловое загрязнение, о котором уже говорили и которое само по себе будет менять флору и фауну в районе мешков…