UDP: Оказывается, давно существует репозиторий с пожеланиеями в виде issues: github.com/limonte/dear-habr/issues
- Групповое редактирование — иногда я пишу сложные статьи, в подготовке которых участвует несколько человек: редактор грамматики и пунктуации, технический редактор, иллюстратор. Сейчас мне приходится копировать для них статью без разметки в какой-нибудь google docs и оттуда возвращать ее на Хабр и заново оформлять разметку. Намного удобнее было бы выдать права на редактирование черновика другому аккаунту внутри Хабра.
- История правок — все привыкли к системам контроля версий, и это касается не только кода, но и любых текстов. Мне необходимо видеть, какие правки внес редактор, не ухудшило ли это читаемость текста. Так же я хочу видеть, как мои статьи без моего ведома и уведомлений правит администрация Хабра!
- WYSIWYG редактор — в целом, я считаю интерфейс редактора Хабра очень хорошим, намного более удобным, чем какой-нибудь Medium.com. Но неудобно постоянно переключаться между редактором и просмотром финальной версии. Особенно когда пытаешься оформить сложную верстку с цитированием, отступами, подсветкой кода.
Ширины экрана вполне хватает, чтобы вместить отрендеренную версию сразу рядом с редактором, например, вот так:
??????????????Просмотр можно показывать в реальном времени рядом с редактором
- Просмотр всей статьи во время редактирования — неудобно смотреть в ЩЕЛЬ нынешнего редактора в который влазит 20 строк. Да, я знаю, что поле ввода можно растянуть по высоте, но окно просмотра увеличить нельзя. Я хочу видеть сразу всю статью во время написания, и ограничиваться только высотой монитора, а не окном редактора. Сейчас для просмотра финальной версии нужно ждать перезагрузки страницы.
??????????????????????????Окно просмотра нельзя увеличить
- Центрирование текста — для центрирования подписей под картинками мне приходится использовать невидимый символ "?" чтобы сдвигать текст вправо. Это очень неудобно.
- Медиаконтент не только oembed — иногда мне необходимо вставить видео, анимацию или аудиозапись.
Для анимации неоправданно использовать формат GIF, так как он весит в десятки раз больше, чем то же видео в H264. Поэтому, вместо разумнее использовать вставку видео, которое будет сразу же проигрываться без звука, как GIF. Сейчас я могу это сделать единственным способом — залить MP4 файл на imgur и использоваться вставку через
<oembed>http://video.mp4</oembed>
Но вместе с видео будут показаны ненужные элементы интерфейса imgur. Это мусор, как мне кажется, и от них лучше избавиться.
Аналогичная ситуация с аудиозаписями.
Намного лучше бы было позволить загружать на habrastorage.org не только изображения, но и видео/аудио одновременно с возможностью настроить проигрыватель: включить автовоспроизведение видео, отключить звук и т.д.
- Сообщить об ошибке автору — была бы полезна возможность быстро сообщить автору о грамматической ошибке, путем выделения и нажатия какой-то комбинации клавиш. Это намного проще чем писать сообщение в личку, как это приходится делать сейчас.
Комментарии (55)
valemak
16.09.2018 21:24Я для центрирования кладу изображение посередине на прозрачный фон шириной 690 пикселей. Вроде бы область статей имеет ширину 700, но закладываю чуть меньше на случай margin/padding в стилях самого Хабра.
valemak
16.09.2018 21:45+2Но этот способ я использую как перестраховочный. На самом деле центрирование изображения можно реализовать и прямо.
В публикации про парадокс Ферми мне захотелось поставить строго по центру большую надпись "Так где же все?":
1)Надпись сделана в виде изображения (обычный текст на Хабре действительно не центрируешь).
2)Для тега img указан атрибут align='center', а также точные ширина и высота картинки.
3)Сразу после тега img указан <br clear='both' /> чтобы избежать дефолтного обтекания текстом справа.
Парсер Хабра картинку обернул в тег <div style='text-align:center;'> (возможно, я мог бы сразу пойти по этому пути, я не проверял). Центрирование изображения работает.
dartraiden
16.09.2018 22:01ненужные элементы интерфейса imgur
Возможно, это требование самого Imgur.zhovner Автор
16.09.2018 22:09Это вполне допустимо когда требуется вставить, например, трек из soundcloud. В этом случае элементы управления нужны. Но когда требуется вставить gif (mp4), то от них никакой пользы.
Можно было бы вполне ограничиться тегом <video> с автовоспроизведением без звука.
Вот, кстати, oembed вставка из soundcloud:
Harrix
16.09.2018 23:44+1А soundcloud по ссылке на трек вставляете или копируете весь html код embed кода с soundcloud?
zhovner Автор
16.09.2018 23:47На soundcloud я копирую ссылку через share и вставляю ее в oembed вот так:
<oembed>https://soundcloud.com/oligarkh_official/01-zemlya</oembed>Harrix
18.09.2018 16:13Интересно, как он он тогда получает id трека по такой ссылке.
zhovner Автор
18.09.2018 16:47Присмотритесь внимательнее, там указан и исполнитель и трек.
soundcloud.com/исполнитель/трек/
Harrix
18.09.2018 20:47-1В embed коде от soundcloud нет упоминания о исполнителе и треке, а есть его id. Например, прямая ссылка на трек https://soundcloud.com/nuclearblastrecords/sabaton-the-lost-battalion, а embed code выглядит так:
<iframe width="100%" height="300" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/268888981&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true&visual=true"></iframe>
То есть если формировать embed код по прямой ссылке, то как-то нужно получать id песни (в примере 268888981). Поэтому в своем велосипеде приходилось код встраивать не через прямую ссылку, а через такую дурацкую ссылку:
https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/268888981. Она работает, но это явно не круто.
zigrus
17.09.2018 08:30Автоматическое проигрывание видео это зло.
Все эти мигающие, прыгающие, скачущие, отвлекающие картинки, очень раздражают.
Можно вставить с кнопкой play, и предпросмотр по наведению мыши. Показывать несколько слайдов. Ну или хотя бы дать пользователю выбор, проигрывать видео автоматически или нет.
valemak
16.09.2018 22:10Ещё не хватает возможности передвигать черновики вверх-вниз относительно других черновиков в списке. Я пишу сериями статей, у меня сейчас в черновиках 20 заготовок разной степени готовности. С одной стороны я хотел бы, чтобы черновики располагались в порядке будущей публикации. Однако этот порядок может сильно варьироваться в связи с изменившимися планами.
tangro
16.09.2018 22:21+2Как по мне, то любая статья вообще должна спустя 3-5 дней переходить в режим «Вики» и быть доступна для редактирования всеми. Ну ладно, пускай не всеми, а только юзерами с положительной кармой или статьями в профильном статье хабе. Критерии можно доработать, но сама возможность нужна. Откройте типичную статью 4-5 летней давности — ссылки умерли, контекст не понятен, многие вещи устарели, другие можно современными инструментами решить проще и т.д. А статья какая была, такая и осталась.
zhovner Автор
16.09.2018 22:22+2Можно, например, предлагать изменения в виде pull request-ов.
valemak
16.09.2018 22:37С одной стороны, действительно, логично оставлять за автором последнее слово — принимать или нет изменения.
С другой — у авторов может не быть времени и желания на вычитку и одобрение предлагаемых правок.MonaGioconda
17.09.2018 13:24А эту проблему можно решить с помощью одобрения правки голосованием за тот или иной предложенный вариант всё теми же пользователями с «положительной кармой или статьями в профильном хабе».
valemak
16.09.2018 22:30+2Идея очень интересная, но с оговорками.
Как минимум должна оставаться в неприкосновенности «авторская версия». Это я как автор говорю.
Также, наверное, было бы неплохо автору предоставлять право — поставить (или не ставить) галочку «создать на основании публикации вики-статью», в результате чего рядом с авторской версией будет существовать редактируемый всеми желающими вариант.tangro
17.09.2018 11:01+1«Авторская версия» всегда будет в истории «первым коммитом». Право откатить правку или забанить доступ к правкам для токсичных пользователей — тоже, конечно, нужно. Но мне кажется что в среде, подобной Хабру, 9 из 10 правок будут по делу.
Scarred
16.09.2018 22:56+4Вот это точно не надо никаких «режимов вики». Для этого есть отдельные площадки с Вики-движками.
Есть что сказать по статье 4-5 летней давности — пишется комментарий к статье.
Слишком много для комментария — пишется новая статья, в начале так указывается «по мотивам статьи такой-то, сейчас задача решается так-то».
«Режим вики» приведет к волне правок. А уж через 3-5 дней — такие баталии будут…
Не говоря уже о том что авторы выкладывает статьи что бы поделится своим виденьем или решением проблемы. Что-то добавляется в комментариях (иногда полезней статьи), иногда появляются статьи-опровержения/подтверждения/расширения от других авторов.
Старые статьи иногда надо именно потому что приходится работать со старым оборудованием, где современные программы/прошивки/приемы не работают.valemak
16.09.2018 23:06+1Хабр понемногу вымирает, войны правок его могли бы заметно оживить :)
Лично мне идея нравится, если наряду с авторской версией (которую может редактировать только автор) параллельно будет существовать вики-вариант.Scarred
17.09.2018 08:06+1С учетом того как сейчас могут слить карму за хороший подробный комментарий, который не соответствует точке зрения даже не оппонента, а сочувствующих оппоненту — страшно представить что будет за исправление статьи…
Разные варианты статей авторская и вики — через некоторое время могут оказаться полностью противоположны по сути. Т.к. автору некогда будет следить за правками в вики-статье (или автор уйдет с хабра), а в вики-войне победит определенная группировка.
У хабра и без этого хватает проблем… Тоже мобильное приложение довести до ума…valemak
17.09.2018 09:05Насчёт кармы согласен, в данной ситуации она будет демотивировать.
Если кого беспокоит потери в карме, он мог бы тогда просто не участвовать в этих процессах.
Честно говоря, мне как автору было бы исключительно интересно понаблюдать, как коллективный разум видоизменит мои статьи (при обязательном условии, что есть основная версия — авторская, редактируемая сугубо автором). При этом вообще не горю желанием модерировать правки вики-варианта и согласился бы, чтобы это происходило без моего контроля и участия.
ИМХО идею с вики-статьями можно было бы внести хотя бы в качестве эксперимента.Scarred
17.09.2018 10:27+1Так проблема с кармой в том что не угадаешь за что получишь слив…
Есть опасные темы — там понятно, не хочешь потерять — не лезь, но не всегда понятно за что карму минусят.
Сколько было примеров коммент в плюсе — карма в минусе…
Поэтому сложно «не участвовать»… Вроде искренне хочешь помочь, данные какие добавить или опытом/наблюдением поделиться, а тебе раз-з-з… и кармы нет…
как коллективный разум видоизменит мои статьи
коллективный разум скорее всего ничего менять не будет, кроме может мелких правок… а вот коллективное бессознательное статьи изуродовать сможет…
tangro
17.09.2018 11:04+1«Режим вики» приведет к волне правок. А уж через 3-5 дней — такие баталии будут…
Что плохого в волне правок или баталиях? Неужели устаревшая статья с битыми ссылками или откровенно неполной/ошибочной информацией — это лучше?Scarred
17.09.2018 12:01А почему считается что правки будут только по делу и правильные? битые (или нормальные) ссылки не заменят на ссылки вирусами, не подменят команды в скриптах и т.д.?
Лучше уж статья с ошибочной инфой где эта ошибочность будет указана в комментах и статья скорее всего будет в глубоком минусе.
Даже на спец вики площадках случаются проблемы хотя там все заточено под вики-режим.
А здесь авторам помимо ответов в комментариях надо будет еще и правки контролировать, притом всегда…
Methos
17.09.2018 10:31+1а вы попробуйте оставить коммент в статье 4 летней давности
удивитесь
вам НИКТО не ответит
вообще
авторы умирают, похоже, даже если живы
KvanTTT
16.09.2018 22:41+4Я уже давно пишу все статьи с помощью VS Code и храню их на GitHub. Перед публикаций конвертирую в формат habr.com с помощью утилиты MarkConv (это из-за того что у хабра неправильный Markdown, смотри баги на гитхабе).
Это позволяет решить такие вышеупомянутые проблемы:
- Групповое редактирование. Можно вносить правки нескольким авторам с помощью механизма Pull Request.
- История правок. Система контроля версий Git с этим хорошо справляется.
- WYSIWYG редактор. В VS Code очень удобный Markdown редактор, который часто обновляется (в отличии от хабра). Дополнительно можно установить расширения для проверки синтаксиса, проверки самого Markdown (линтер), форматирования таблиц и генерации оглавления.
- Просмотр всей статьи во время редактирования. VS Code можно растянуть хоть на весь экран.
- Сообщить об ошибке автору. На гитхабе можно использовать и обычные Issues помимо Pull Request.
Кроме того, на гитхабе эти статьи также можно читать.
Кстати, я пишу статью о том как писать статьи на habr с помощью GitHub. Но пока что не дошли руки ее закончить.
zhovner Автор
16.09.2018 22:45+1Круто, спасибо, буду иметь в виду.
KvanTTT
16.09.2018 22:57+1Более того, это решает проблему с бекапом, т.к. репозиторий можно пушить на GitHub, GitLab и хранить локально. Если не хочется светить статью до пубилкации, можно пушить в приватный бесплатный GitLab репозиторий, а после публикации — уже на GitHub. Я вообще уже забыл как на хабре что-то редактировать, так как без версий, подсветки синтаксиса, нормального превью это кажется очень неудобным.
Пора уже создавать свой GitHabr :)
paul35
16.09.2018 22:49+1Извиняюсь что влезаю к вам, но сейчас заметил очень странный баг в своей статье, после публикации нажимал кнопку «Редактировать», т.к. сообщили об ошибке и после повторной публикации задвоилась голосовалка.
Пользуясь случаем прошу обратить на это внимание администрацию ресурса.valemak
16.09.2018 22:54Помню, пару лет назад у меня было что-то подобное. Ошибка состояла в том, что голосование было с установленным сроком, который истёк на момент редактирования. Отрицательных временных периодов в голосовании Хабр, по всей видимости, не терпит, поэтому, во-первых сообщает об ошибке, во-вторых клонирует голосование с обновлённой (действующей на данный момент) датой окончания голосования.
paul35
16.09.2018 22:59+1голосование было с установленным сроком
У меня не установлено ограничений по сроку )
Спасибо за комментарий, теперь я буду знать что не сошел с ума, и баг существует!valemak
16.09.2018 23:12Я не помню на 100% в чём была загвоздка (уже как пару-тройку лет отказался от голосований в своих статьях), но помню в моём случае задваивающий баг был как-то связан именно со временем.
Тогда кстати, у Украины был 1 час разницы с московским временем, и я заметил, что при каждом сохранении время голосования на этот час сдвигалось… В общем, в любом случае, голосовалки тут глючные, не без того.
Madeas
17.09.2018 09:06Присоединяюсь к автору. Еще хотелось бы иметь возможность встраивания кода напрямую с jsfiddle/codepen. Как это реализовано на тостере. Или добавить возможность вставки скопированного фрейма (не скрипта). На мой взгляд, это удобнее, чем показывать примеры, делая обыкновенные ссылки на код.
Boomburum
17.09.2018 13:21Или я что-то не понял, или чем не подходит oembed-тег, который поддерживает и jsfiddle и codepen и много ещё чего? )
Madeas
17.09.2018 09:20+1Есть еще предложение, правда оно слегка сомнительное и требует более глобального осмысления — это возможность предлагать правки прямо в статье другими пользователями хабра. Как это сделано, например, в открытых гугл доках (там 3 режима) или гитхабе.
Пример, написал я статью, пользователь в комментариях отписался, что есть еще другие полезные ресурсы и/или информация, без которой статья кажется не полной или не интересной. В итоге: из-за отсутствия, по его мнению, необходимой ссылки, статья получает один минус, а карма пользователя падает в минус. Согласитесь, не каждому будет по нраву такой фидбек за свои старания =)
На мой взгляд,
1. во-первых, данная возможность позволит повысить лояльность читателей к той или иной статье и они будут меньше «минусовать», а статья станет более годной. Разумеется, если материал сам по себе нормальный)
2. во-вторых, в будущем, будет проще искать нужную информацию, так как она будет в одном топике, а не разбита на 10 огрызков, от разных авторов.
п.с. Для реализации, можно добавить специальную галочку для топикстартера, которая позволит ему решать, можно ли будет вносить правки пользователям, после публикации, или он считает свою статью окончательной, не требующей изменений.dartraiden
17.09.2018 15:17На Opennet примерно так и сделано. Любой человек, заметив, допустим, опечатку в новости, может нажать кнопку «Правка». Дальше уже автор новости или модератор видят с подсветкой, какие изменения предложены, и могут внести те или иные правки.
andersong
17.09.2018 10:24+1Выскажу свою хотелку: когда смотришь «Лучшие публикации», есть выбор «сутки» и «неделя», а в понедельник не хватает «выходные».
Я обычно на хабр заглядываю в обед, и в понедельник при выборе «сутки» выпадают из вида пол-пятницы и суббота, а при выборе «неделя» выходит 10...15+ страниц постов.ton1
17.09.2018 14:39Ага. Еще бы хотелось в rss ленте чтоб влезали апдейты за все выходные. Умолчальные (с некоторых недавных пор) 20 штук — мало.
Если всем отдавать толстую пачку накладно, сделайте для страждущих по специальному url, по аналогии с ?with_hubs=true: и ?with_tags=true:
Methos
17.09.2018 10:36+1я вот что не понимаю
почему только 100 страниц назад?
где почитать остальные статьи хабра, старее года?
Methos
17.09.2018 10:38+1https://m.habr.com/all/page100 нет ничего
https://m.habr.com/all/page101 вообще 404
https://m.habr.com/all/page99 пусто
что за хрень?
black_semargl
17.09.2018 15:58Во-первых, как правильно сказали — уже 50 (но количество постов на странице удвоили)
Во-вторых — в хабах такого ограничения нетMethos
17.09.2018 18:35я не понимаю, что за хабы
мне хотелось прочитать весь хабр недавно
но ничего не вышло
уткнулся в 404 страницу на 100 странице
как это понимать то?
и так читать нечего, пролистывал все страницы, ибо одна муть рекламная, так ещё и непонятно, как читать старые статьи 10 летней давности?
можно конечно просто по номеру все перечислить habr.com/post/3446, но они не всегда по порядку, будет долго…
так ведь и придётся писать скрипт, создаюший весь хабр
и наверняка кто-то уже сделал? ау?black_semargl
17.09.2018 19:25Вот например под заголовком этой статьи есть ссылка Хабрахабр, вот там все 74 страницы на эту тему видно, до самого начала. (последняя — habr.com/post/1/ )
иногда их несколько, общий список возможных доступен через ссылку «Хабы» вверху (выбирать только основные, habr.com/hub/***/)
Boomburum
17.09.2018 13:38В целом согласен со многими предложениями, что-то уже в работе.
Картинки, как уже написали выше, можно выравнивать атрибутом align=«left» (right/center).
Насчёт коллективной работы. К сожалению, мы вряд ли переплюнем по удобству коллективной работы тот же GoogleDocs или Paper ) Поэтому всё же лучше готовить публикации именно там — и не начинать верстать её, пока статья не будет полностью готова к размещению (включая проверку корректора, иллюстратора итд). Для удобства и скорости можно использовать конвертер, который избавляет от головной боли.KvanTTT
17.09.2018 14:38+1А можно ли просто сделать так, чтобы статьи хранились в виде Git репозитория? Чтобы можно было пушить туда статьи? Средства для коллективной работы в этом случае не понадобятся, особенно если еще Markdown доработайте.
zhovner Автор
17.09.2018 16:11Картинки, как уже написали выше, можно выравнивать атрибутом align=«left»
А как выровнять подпись для картинки по центру?Boomburum
17.09.2018 16:45Текст, к сожалению, пока никак ( Вариантов несколько: пробелы или текст на картинке. В случае с таблицами, можно th сделать — тогда текст будет по середине ячейки (но жирный).
leschenko
«Сообщить об ошибку автору» — это такая оригинальная шутка или просто демонстрация желаемой функции?
valemak
Кстати, эту функция избавила бы авторов от ненужного стресса, когда им комментаторы пишут об ошибках прямо в комментариях.
Juma
Эту функцию просят уже давно (было в подобной статье ранее, возможно не один раз). На многих сайтах (в основном новостных) есть такая функция. Реализованы обычно через Ctrl + что-то там (вроде Enter). IMHO на хабре это нужнее, так как материал важнее и решит сразу несколько вопросов:
— более быстро можно будет исправлять ошибки (многие видя опечатки просто не сообщают о них), а те кто сообщают в личку могут не нароком задеть чувства автора;
— Исчесзнут (надеюсь) комментарии с указаниями на опчатки, которые почти сразу получают несколько минусов.
peresada
ИМХО нужен не функционал «Сообщить об ошибке», а функционал «Внести изменения» на подобие stackoverflow, которые модерируются самим автором. Так и быстрее, и эффективней, и в плане надежности нареканий нет