I. Перечислю имеющиеся сформулированные в статье «фичи».
1. Кнопка «Х» в поле ввода.
2. Непрыгание поиска вверх в Хроме (наверное, отдельным расширением возможно).
3. Более контрастный текст на 2 кнопках. (надо ли?)
4. В общем-то, можно убрать кнопку «Поиск в Google», потому что скрипт делает видимой кнопку с лупой. Плюс её можно сделать широкой.
5. Модная анимация при переходе со стартовой — сложновато и затратно будет это всё сделать — происходит смена страницы, поэтому прыжок при смене всё равно будет. Сделать без смены — скорее, не получится — в Гугле масса внутренней кухни в скриптах как на главной, так и на результатах. И нарушится показ в тщательно тестируемых как ими, так и Яндексом старых браузерах, а мы знать не будем (возможно, для расширений это несущественно).
II. Что бы я добавил от себя:
* Экстра-кнопки из имеющегося юзер-скрипта.
* поиск по ссылке на фотографию (среди картинок) сразу со стартовой или с результатов поиска.
* нескрывание кнопки «показать локальную копию результата поиска».
* убирание редиректов на результаты через Гугл (люто не понравится фирмачам, но очень нравится пользователям).
*
Пояснение к “I’m feeling lucky” («Зачем они вам?» — спрашивалось в статье.) Это — старая фишка Гугла — переходить на первый результат поиска сразу. Потом они подсчитали, что несут убыток на рекламе из-за этой кнопки и 1) убрали автопереход по ней из настроек; 2) возможно, именно поэтому сделали малоконтрастной эту и заодно, основную кнопку.
III. Вы написали, что есть ещё столько же замечаний к этому интерфейсу. Давайте и их разберём и внесём в список на правку.
Плюс, говорят, в 53-й версии вводят Material Design и могут вскоре добраться и до поиска. Но, думаю, и тогда будет что подправлять, поэтому не стоит по этой причине отказываться идеи сделать от расширение.
У Гугла всегда было наплевательское отношение к дизайну стартовых продуктов первые 3-4 года (Гугл-почта в пример, если кто помнит её начало.) Но некоторые наплевательства растягиваются на десятилетия — поиск и те же Гугл-группы, как выше успели отметить. И подобное, надо заметить было присуще и Microsoft с интерфейсом её системы, пока не появилось уж очень много хороших конкурентов.
В оправдание поиска можно подумать, что тут у Гугла есть философский смысл: «вся наша сила — в одном поле ввода». Значит, и поиск можно прикрутить к любому полю ввода, что и делают зависимые разработчики.
(И такое же — на странице результатов.) Действительно, зачем 2 раза кликать, чтобы перейти к специальным условиям поиска с пустой страницы, если выбрать их можно сразу же?
В связи с этим — предложение: подумалось, что скриптами можно подправить и описанные в статье и комментариях «косяки» реализации поиска. Напишем в Issues Гихаба этого скрипта пожелания? Лично я вижу актуальным добавление 2 вещей: поиска по фотографиям (сразу) и метапоиска по 1-4 поисковикам, что очень хорошо ляжет в этот скрипт.
Даже кнопка «Х» в поле ввода, как правильно заметили в комментах, актуальна для мобильных устройств с тач-интерфейсом. Сделать можно, но кажется избвыточным. А что, по мнению читателей, наиболее важно для подправки интерфейса? Может быть восстановить, непрыгание поля ввода вверх? (Это, кстати, есть и в IE11 (казалось бы, зачем?), но нет в Vivaldi.) Наверное, расширением Хрома в Хроме это можно «исправить».
Таким образом, создадим скрипт с исправленным интерфейсом Гугл-поиска и сможем оценить как удобство, так и число поклонников.
На рынке крупных систем всегда так было: Windows 95-2000-XP имела массу интерфейсных неудобств, говоря: нам не до этого, мы гораздо более серьёзными вещами занимаемся, это всё утилитами исправляется. Пока не придёт какой-нибудь Apple или KDE и не сделает как надо.
Потому что для «фишек» приходится открывать страницу результатов (следующую). А для некоторых (поиск по фото) и третью страницу подряд со всё равно какой строкой запроса ).
Автор (в ЛС 2 дня нет ответа про искажение смысла перевода): в конце статьи у вас:
Чтобы прийти к идеям, мыслям и решениям, отражённым на нашем сайте, не требуется большого опыта, если вы всегда делаете то, что говорят другие.
В оригинале:
Чтобы прийти к идеям, мыслям и выводам, отражённым на нашем сайте, не требуется большого опыта, если вы просто сосредоточены на этой теме, в которой отдельные вещи всегда делаются традиционно (или: «так, как говорят другие»).
А у Вас по смыслу «говорят другие» перенеслось на человека, автора. Да и ещё почему-то «всегда». Другими словами, грубо: «если у вас никогда своих решений не было, вы придёте к этим идеям и мыслям, что на сайте». Вот эта бессмысленность фразы и заставила меня взглянуть в оригинал: ).
(The ideas, thoughts, and conclusions expressed on this website doesn’t take much experience to reach if you just stay focused on the main theme which is to always do a particular thing because other people says so.)
Потому что сказанное в статье грамотно, всё это можно найти по разным статьям в интернете, но тропинка протаптывается в направлении троллизма в плане «не надо пользоваться фреймворками». А авторы неизвестны. Об их уровне можно сказать, что он не начальный, стадию отрицания ООП они прошли самостоятельно. Но отсутствие конструктивности, что все отмечают, говорит, что до этой стадии ещё не дошли (обычно приходят или к паттернам, или к ФП. Но паттерны они тоже отрицают почему-то (цитаты подходящие попались от Пола Грэма про макросы? так это он про Си, скорее) — говорит как раз о недлинном пути).
В общем, да, по статье всё читается. Посмотрите других критиков ООП — там хорошо видно, что они что-то предлагают вместо него (прототипы, примеси, ФП). Ближайших примеров на Хабре можно найти очень много, вот, например, за 5 августа. Или эти 2 статьи: http://frontender.info/the-two-pillars-of-javascript/
Если так, то, действительно, наличие условных инструментов модификации DOM постоянно требуется. Но как в DiffHTML напишется аппенд к любому содержимому (innerHTML) блока $temp? Наверное, надо вводить метасимволы типа "*" и дальнейшие правила разбора шаблона (второго параметра).
Не проще ли написать сразу плагин к jQuery для условной манипуляции DOM? Преимущество в том, что не создаётся новый инструмент, а расширяется давно известный, дополняются лишь правила. Не будет, например, перестановки параметров. Если смущает увесистость jQuery, то у меня есть функция на 1.5K, которая делает элементы условной манипуляции и при этом заменяет основные функции jQuery (аналогичные микролибы — $dom.js, balalaika и другие).
И объём DiffHTML — 80К, что подсказывает, что туда вошли много правил, парсер шаблонов, частично исполняющие роли jQuery. Плагин был бы легче. Другими словами, хотел бы сказать, что оформленные идеи, работающие в коде — конечно, хорошо, но описанное в Гитхабе API наводит на мысли, что к частичным целям можно идти другими и более спрямлёнными путями.
Они же о себе всё сказали в конце — что они — безымянные тролли, и на Гитхаб даже выложили не код, а свою единственную статью из корня доменного имени сайта. В основе которой — цитаты известных людей против парадигм, сказанные по разным случаям. Отсутствие контрпримеров подсказывает, что авторы только что прошли стадию понимания недостатков слепого следования фреймворкам и сами думают, что же делать дальше.
Автор: с какими СМИ Вам ещё приходилось работать, чтобы Вы могли рассказать об удобствах-неудобствах работы и популярности в глазах читателей в сравнении с Хабром? Получилось бы интересное сравнение, наподобие того, какое Вы привели с Охлобыстиным.
Но это же не всё.
13. Он должен умело писать, чтобы хорошо доносить свои мысли до других, как в этой статье.
14. Он должен хорошо торговаться, чтобы умело продать свою работу и идеи.
15. Он должен уметь поддерживать светский разговор, когда попадёт на ужин с инвесторами.
16. Он должен иметь вкус в одежде, чтобы не шокировать окружающих.
17. Он должен уметь готовить, чтобы создать уютную обстановку при романтической встрече.
18. Он должен виртуозно работать в любой OS, в том числе и в мобильных.
19. Он должен говорить на международном бизнес-языке, чтобы первым улавливать музыку далёких гонгов.
20. Он должен быть материалистом, чтобы отличать ошибочные идеи от выполнимых.
21. Он должен быть в курсе постановлений правительства, чтобы знать, куда бежать.
22. Он должен думать о бекапах имеющих к нему отношение работ.
23. Он должен иметь под рукой компьютер и связь, чтобы рационально использовать своё время.
24. Он должен излучать оптимизм, чтобы быть своим в доску в компании.
25. Он должен иметь нюх на ещё не озвученное решение руководства стартапа о его закрытии.
Альбатросы не удержатся на канатах — тело тяжёлое, а лапы слабые. Сравните с воробьиными или куриными. Для сочетания «ветки и перепонки», вам, скорее, подошли бы гоголи. Да и то, им это нужно, чтобы гнездоваться в дуплах, а не высоко на ветке сидеть. Вот максимум:
Не нашёл ответа в статье о том, почему не рассматриваете загрузку через JS (document.styleSheets, insertRule, addRule)?
Ведь она соответствует требованиям модульности, имеет максимальную гибкость (можно выбрать место расположения правил (приоритет их), а не делать appendChild к группе уже подгруженных правил). Загрузка текстов полностью контролируется в Require или подобными механизмами, если файл не смог загрузиться.
Понятно, что тут написать надо побольше кода, но будем иметь самую суть управления стилями.
(Более того, меняя rules, получаем нетипичную гибкость манипулирования страницей в реалтайме, но этим в библиотеках и просто в приложениях никогда не пользуются, рассматривая правила как что-то статичное. Но это — другая тема.)
В самом же деле, что делать, как обороняться, если пришельцы выберут тактику нападения с разных направлений из соседних звёздных систем? Тогда каждый кластер обороны будет знать о нападении лишь части армии, а нападающие уже заранее согласовали план о направлении главного удара? Может быть, нам надо сделать передовую линию обороны на дальних подступах, в а.е. 300 примерно? Давайте подумаем о перестройке всей стратегии обороны ресурсов.
Но что, если они уже тут, а мы в зоопарке в обезьяньей клетке, в которой нам дадут развиваться до некоторых пределов, а потом ограничат, потому что ресурсы всем нужны, а сильным — нужнее? Тогда надо побольше урвать ресурсов у окружающих, пока те внешние нас всех не остановят. И ведь не просто так, а ради высокой цели, мобилизовать всех на защиту всей цивилизации и её будущего.
Оптимизации нет. Если спидометром предполагается пользоваться для многократного изменения значения, 4 функции из 5, очевидно, вызываются избыточно, их стоит применить один первый раз. Далее, чтобы это выглядело не как Boilerplate code, надо обернуть в объект с методами init() и setValue(). А если учесть, что эксперименты (со снежинками на Canvas) показывают, что нарисовать один слой Canvas в браузерах затратнее, чем нарисовать или повернуть один DOM-элемент стрелки спидометра, то решение, очевидно, будет просто во вращении (css transform rotate, а лучше matrix) стрелки по setValue().
> Без омниколес не обойтись в любом случае. В каком положении не ставь обычные колеса, будет возникать большое трение и проскальзывание
---вот тут неверно — можно (и нужно) сделать такие допустимые движения, чтобы трения и проскальзывания не было. Как этого достичь — легко представить. Представьте для простоты, что вы на 3 колёсах, расположенных по линиям равностороннего треугольника, катаетесь по плоскости. Как повернуться, чтобы не было проскальзывания? Остановите одно колесо, двигаясь только двумя другими. Они поведут бота по кругу вокруг точки стоящего колеса. Точно так же можно представить и движения сразу тремя колёсами, если мёртвую точку (точку вращения бота) надо переместить. Строго говоря, трение будет, но только «вращательное», для всех 3 колёс, если их скорости подбирать. Но на то и процессор на боте, чтобы подбирать. И вся специфичность такого бота будет в том, что все его движения не должны быть скольжениями, а только поворотами вокруг некоторой требуемой точки.
> Можно пробовать управлять по скорости…
---Верно — и при отсутствии проскальзываний, которые в модели с омни-колёсами как раз допускаются, а с новой моделью можно избежать — скоростей или положений с датчиков поворотов колёс будет достаточно, а погрешности будут компенсироваться корректировками из других датчиков (гироскоп)
> про какие два проекта вы говорите
---ваш и Rezero (темой не занимался, прочитал только Вашу статью; да, спасибо, на вопросы ответили полностью). Ну, значит, как я понял, мат-моделей для обычных колёс для движений без проскальзываний нет. Значит, есть, что изобретать дальше: )
А дальше придумалась ещё одна простая конструкция, которая будет на той же модели без проскальзываний и при этом держать шарик — поставить 3 колеса на выдвинутых осях, чтобы прикасались к шару ниже его центра масс, а сверху шар зафиксировать 4-й пассивно крутящейся точкой
(К сожалению, не нашёл ни одной иллюстрации своего описания в https://www.google.ru/search?tbm=isch&sa=1&q=ball+balancing+robot — везде 3 колеса лишь сверху. Суть накидал в своём рисунке.)
1. Кнопка «Х» в поле ввода.
2. Непрыгание поиска вверх в Хроме (наверное, отдельным расширением возможно).
3. Более контрастный текст на 2 кнопках. (надо ли?)
4. В общем-то, можно убрать кнопку «Поиск в Google», потому что скрипт делает видимой кнопку с лупой. Плюс её можно сделать широкой.
5. Модная анимация при переходе со стартовой — сложновато и затратно будет это всё сделать — происходит смена страницы, поэтому прыжок при смене всё равно будет. Сделать без смены — скорее, не получится — в Гугле масса внутренней кухни в скриптах как на главной, так и на результатах. И нарушится показ в тщательно тестируемых как ими, так и Яндексом старых браузерах, а мы знать не будем (возможно, для расширений это несущественно).
II. Что бы я добавил от себя:
* Экстра-кнопки из имеющегося юзер-скрипта.
* поиск по ссылке на фотографию (среди картинок) сразу со стартовой или с результатов поиска.
* нескрывание кнопки «показать локальную копию результата поиска».
* убирание редиректов на результаты через Гугл (люто не понравится фирмачам, но очень нравится пользователям).
*
Пояснение к “I’m feeling lucky” («Зачем они вам?» — спрашивалось в статье.) Это — старая фишка Гугла — переходить на первый результат поиска сразу. Потом они подсчитали, что несут убыток на рекламе из-за этой кнопки и 1) убрали автопереход по ней из настроек; 2) возможно, именно поэтому сделали малоконтрастной эту и заодно, основную кнопку.
III. Вы написали, что есть ещё столько же замечаний к этому интерфейсу. Давайте и их разберём и внесём в список на правку.
Плюс, говорят, в 53-й версии вводят Material Design и могут вскоре добраться и до поиска. Но, думаю, и тогда будет что подправлять, поэтому не стоит по этой причине отказываться идеи сделать от расширение.
В оправдание поиска можно подумать, что тут у Гугла есть философский смысл: «вся наша сила — в одном поле ввода». Значит, и поиск можно прикрутить к любому полю ввода, что и делают зависимые разработчики.
А ещё я, по возможности, облагораживал поиск Гугла (затем и Яндекса) дополнительными кнопками — "Google Search Extra Buttons".
(И такое же — на странице результатов.) Действительно, зачем 2 раза кликать, чтобы перейти к специальным условиям поиска с пустой страницы, если выбрать их можно сразу же?
В связи с этим — предложение: подумалось, что скриптами можно подправить и описанные в статье и комментариях «косяки» реализации поиска. Напишем в Issues Гихаба этого скрипта пожелания? Лично я вижу актуальным добавление 2 вещей: поиска по фотографиям (сразу) и метапоиска по 1-4 поисковикам, что очень хорошо ляжет в этот скрипт.
Даже кнопка «Х» в поле ввода, как правильно заметили в комментах, актуальна для мобильных устройств с тач-интерфейсом. Сделать можно, но кажется избвыточным. А что, по мнению читателей, наиболее важно для подправки интерфейса? Может быть восстановить, непрыгание поля ввода вверх? (Это, кстати, есть и в IE11 (казалось бы, зачем?), но нет в Vivaldi.) Наверное, расширением Хрома в Хроме это можно «исправить».
Таким образом, создадим скрипт с исправленным интерфейсом Гугл-поиска и сможем оценить как удобство, так и число поклонников.
В оригинале:
А у Вас по смыслу «говорят другие» перенеслось на человека, автора. Да и ещё почему-то «всегда». Другими словами, грубо: «если у вас никогда своих решений не было, вы придёте к этим идеям и мыслям, что на сайте». Вот эта бессмысленность фразы и заставила меня взглянуть в оригинал: ).
В общем, да, по статье всё читается. Посмотрите других критиков ООП — там хорошо видно, что они что-то предлагают вместо него (прототипы, примеси, ФП). Ближайших примеров на Хабре можно найти очень много, вот, например, за 5 августа. Или эти 2 статьи: http://frontender.info/the-two-pillars-of-javascript/
Если так, то, действительно, наличие условных инструментов модификации DOM постоянно требуется. Но как в DiffHTML напишется аппенд к любому содержимому (innerHTML) блока $temp? Наверное, надо вводить метасимволы типа "*" и дальнейшие правила разбора шаблона (второго параметра).
Не проще ли написать сразу плагин к jQuery для условной манипуляции DOM? Преимущество в том, что не создаётся новый инструмент, а расширяется давно известный, дополняются лишь правила. Не будет, например, перестановки параметров. Если смущает увесистость jQuery, то у меня есть функция на 1.5K, которая делает элементы условной манипуляции и при этом заменяет основные функции jQuery (аналогичные микролибы — $dom.js, balalaika и другие).
И объём DiffHTML — 80К, что подсказывает, что туда вошли много правил, парсер шаблонов, частично исполняющие роли jQuery. Плагин был бы легче. Другими словами, хотел бы сказать, что оформленные идеи, работающие в коде — конечно, хорошо, но описанное в Гитхабе API наводит на мысли, что к частичным целям можно идти другими и более спрямлёнными путями.
13. Он должен умело писать, чтобы хорошо доносить свои мысли до других, как в этой статье.
14. Он должен хорошо торговаться, чтобы умело продать свою работу и идеи.
15. Он должен уметь поддерживать светский разговор, когда попадёт на ужин с инвесторами.
16. Он должен иметь вкус в одежде, чтобы не шокировать окружающих.
17. Он должен уметь готовить, чтобы создать уютную обстановку при романтической встрече.
18. Он должен виртуозно работать в любой OS, в том числе и в мобильных.
19. Он должен говорить на международном бизнес-языке, чтобы первым улавливать музыку далёких гонгов.
20. Он должен быть материалистом, чтобы отличать ошибочные идеи от выполнимых.
21. Он должен быть в курсе постановлений правительства, чтобы знать, куда бежать.
22. Он должен думать о бекапах имеющих к нему отношение работ.
23. Он должен иметь под рукой компьютер и связь, чтобы рационально использовать своё время.
24. Он должен излучать оптимизм, чтобы быть своим в доску в компании.
25. Он должен иметь нюх на ещё не озвученное решение руководства стартапа о его закрытии.
Ведь она соответствует требованиям модульности, имеет максимальную гибкость (можно выбрать место расположения правил (приоритет их), а не делать appendChild к группе уже подгруженных правил). Загрузка текстов полностью контролируется в Require или подобными механизмами, если файл не смог загрузиться.
Понятно, что тут написать надо побольше кода, но будем иметь самую суть управления стилями.
(Более того, меняя rules, получаем нетипичную гибкость манипулирования страницей в реалтайме, но этим в библиотеках и просто в приложениях никогда не пользуются, рассматривая правила как что-то статичное. Но это — другая тема.)
Но что, если они уже тут, а мы в зоопарке в обезьяньей клетке, в которой нам дадут развиваться до некоторых пределов, а потом ограничат, потому что ресурсы всем нужны, а сильным — нужнее? Тогда надо побольше урвать ресурсов у окружающих, пока те внешние нас всех не остановят. И ведь не просто так, а ради высокой цели, мобилизовать всех на защиту всей цивилизации и её будущего.
2) периодически проверяйте наличие ответа во втором пункте.
---вот тут неверно — можно (и нужно) сделать такие допустимые движения, чтобы трения и проскальзывания не было. Как этого достичь — легко представить. Представьте для простоты, что вы на 3 колёсах, расположенных по линиям равностороннего треугольника, катаетесь по плоскости. Как повернуться, чтобы не было проскальзывания? Остановите одно колесо, двигаясь только двумя другими. Они поведут бота по кругу вокруг точки стоящего колеса. Точно так же можно представить и движения сразу тремя колёсами, если мёртвую точку (точку вращения бота) надо переместить. Строго говоря, трение будет, но только «вращательное», для всех 3 колёс, если их скорости подбирать. Но на то и процессор на боте, чтобы подбирать. И вся специфичность такого бота будет в том, что все его движения не должны быть скольжениями, а только поворотами вокруг некоторой требуемой точки.
> Можно пробовать управлять по скорости…
---Верно — и при отсутствии проскальзываний, которые в модели с омни-колёсами как раз допускаются, а с новой моделью можно избежать — скоростей или положений с датчиков поворотов колёс будет достаточно, а погрешности будут компенсироваться корректировками из других датчиков (гироскоп)
> про какие два проекта вы говорите
---ваш и Rezero (темой не занимался, прочитал только Вашу статью; да, спасибо, на вопросы ответили полностью). Ну, значит, как я понял, мат-моделей для обычных колёс для движений без проскальзываний нет. Значит, есть, что изобретать дальше: )
А дальше придумалась ещё одна простая конструкция, которая будет на той же модели без проскальзываний и при этом держать шарик — поставить 3 колеса на выдвинутых осях, чтобы прикасались к шару ниже его центра масс, а сверху шар зафиксировать 4-й пассивно крутящейся точкой
(К сожалению, не нашёл ни одной иллюстрации своего описания в https://www.google.ru/search?tbm=isch&sa=1&q=ball+balancing+robot — везде 3 колеса лишь сверху. Суть накидал в своём рисунке.)