Replies (61)

  • @ugnich, лучше оставить все как есть
  • @ugnich, фейсбучно
  • @Shumaher, верхнюю панельку только зафиксировать при скроле
  • @sergey-klay, удваиваю. Алсо не надо орать, я не заметил, что не залогинен.
  • @ugnich, У меня там только сайдбар. Это нормально?
  • @skobkin-ru, Клик по ссылкам из сайдбара творит чудеса. ;)
  • @ugnich, К слову, приваты... Зачем они занимают одно из основных мест в интерфейсе?
  • @skobkin-ru, В начале следующей недели будет подробный пост на эту тему.
  • @ugnich, Ох. Уже начинаем бояться.
  • @skobkin-ru, не-не, прогресс в принципе нормальное явление. @ugnich а можно где нибудь на будущую сетку в полной реализации посмотреть?
  • @sergey-klay, Прогресс жуйка часто очень спорный. Надеюсь, в этот раз будет хорошо.
  • @sergey-klay, Что такое "сетка"?
  • @sergey-klay, Зачем?
  • @ugnich, ну ты же начал показывать "что будет", почему бы не продолжить, раз начал?
  • @sergey-klay, На будущее можно посмотреть в будущем. А здесь я показываю прогресс на текущий момент, настоящее.
  • @ugnich, настоящее тут juick.com, а тут juick.com/dev то, что станет настоящим в будущем
  • @ugnich, Рановато показывать, явно.
  • @borman, почему? может человек хочет показать процесс с самого начала
  • @borman, Алсо интересно посмотреть на статистику использования приватов, а то в моем представлении они нужны только чтобы ответить на короткий вопрос или обменяться jid-ами.
  • @borman, Да, да, да.
  • @borman, приват можно вообще сделать вплывающим списком контактов в левой колонке и содержимым переписки в основной
  • @sergey-klay, Показывать стоит тогда, когда есть, что показывать. Такое можно показать коллеге ("смотри, бекенд работает, сделал заглушку за пять минут на коленке, можешь пилить интерфейс").
  • @borman, принципиальной разницы как и за какое время это сделано нет. если человек показывает Такое значит он преследует Такие цели. логично? :)
  • @sergey-klay, С учетом того, что я им почти не пользуюсь, для меня самый крутой дизайн — чтобы было спрятано и не мешалось, например. Поэтому вопрос про статистику.
  • @sergey-klay, логично?логикой здесь и не пахло
  • @borman, по этому я и говорю всплывающим списком. нажал на заголовок писка контактов в левой колонке — он, без перезагрузки страницы развернулся в левой колонке, возможно даже со свои скролом, ты там выбрал контакт, кликнув по нему, и чат с этим контактом появился в центральной колонке. нажал ещё раз на заголовок списка контактов, он свернулся в полоску вниз (вверх). разве не удобно?
  • @borman, докажи :)
  • @sergey-klay, Пожалуйста, где-нибудь в другом месте.
  • @ugnich, а сейчас у меня там справа кто отображается? если честно не совсем очевидно. список тех с кем у меня была переписка, друзья онлайн, приват — ?
  • @sergey-klay, С кем общались в последнее время.
  • @ugnich, а можно какие нибудь интерактивные переключалки списка того, кого я хочу там видеть — с кем общался недавно, или весь список друзей, или список моих приватов, или белый список, или черный список и т.д. и т.п.? короче чтоб это дело настраивалось а конфиг писался бы в кукисы например
  • @ugnich, эх ребята, скажите, когда уже будет календарь в моём блоге? ведь писец облысеет, пока доберёшься до треда, в котором общался ну хоть с месяц назад..
  • @ugnich, фу! опять ойфонность!
  • @datacompboy, почему? о_О
  • @ugnich, К Гудвину обращались?
    Вы постоянно "улучшаете", обновляете, но у вас в текущей версии куча недоработок. Понимаю, что чешется. Может быть, пора сделать одну стабильную, без косяков, версию.
  • @proctolog, Самые умные слова за весь пост!
  • @ugnich, Я обычно не пишу в комментариях к этому блогу, но @proctolog в /40 очень прав.
  • @proctolog, Какие недоработки?
    Чтобы действия типа "подписаться" или "удалить" выполнялись через API, а не через отправку команды со страницы /post?
    Чтобы отправка комментария не перезагружала страницу?
    Чтобы новые комменты сами приходили в браузер и не нужно было жать F5?
    Ну так этим и занимаюсь.
  • @ugnich, Чтобы если подписан, но не WL, то посты с *public приходили всё-таки в jabber, а не только в вебе были.
    Чтобы для личных сообщений был свой отдельный уголок, чёрт возьми. Хоть я ими и не пользуюсь.
    Почему от удаленных тегов в вебморде остаётся звёздочка?
    Люди не могут заново залогиниться, пока куки не удалят.
    Неужели нельзя пофиксить проблему, когда комментарии в вебморде отправляются два раза?
    Чтобы не видеть BL и в общей ленте.
    Регулярно отваливается комментирование и постинг из вебморды — тоже вещь нездоровая.
    Нововведения появляются втихомолку — "сюрприз будет!".
  • @proctolog, 1. Будет исправлено заодно с приватными сообщениями.
    2. Этим и занимаюсь.
    3. Не знаю, первый раз слышу, никто не жаловался.
    4. Этим и занимаюсь.
    5. Нажимайте кнопку один раз — будет отправляться один раз.
    6. Это не баг.
    7. Этим и занимаюсь.
    8. Через пару дней будет подробный пост.
  • @ugnich, 3. Я жаловался и жалуюсь, как видите.
    5. Со мной такого не случается, зато регулярно, каждый день, вижу дубли. Насколько я понимаю, это происходит потому, что при отправке комментария страница подвисает, и жмут ещё раз. Плюс не видят отправленный комментарий. Криворукость пользователя здесь, в общем, тоже не первична.
    6. Знаю, что не баг. Такое "видение" того, как должно быть. Да, не предмет спора.
    Вы, видимо, где-то прочитали умную статью про минимализм и избыточность — убрали кнопку назад, в браузере же есть. Спорить бесполезно. Но сделайте тогда хотя бы очень удобное перелистывание по Ctrl+← и Ctrl+→.
    Кто придумал странное ?before=2462002, чем плох ?page=1 ? Календаря нет, поиск не всегда справляется, сразу пролистать на 50 страниц — нельзя.
    С арабами худо-бедно почти справились, но есть же ещё спамеры-сеошники-рекламщики, уйма их. Пользователи, разумеется, ленятся сигнализировать на ugnich@jabber.zp.ua(и удобно ли вам?), пишут жалобы под различными тегами *juick, *spam и пр. А по сути, получается тот же самый мусор, ничем не лучше спама, которого быть не должно.
  • @proctolog, 3. Жаловаться не надо, надо писать баг-репорт.
    Функция "Отметить спам" в списке приоритетных задач.
  • @proctolog, Кто придумал странное ?before=2462002, чем плох ?page=1 ?Нумерация страниц относительно последнего поста — зло. Видимо, поэтому сделали абсолютную нумерацию. Почему так, а не опять же номерами страниц — скорее всего во имя упрощения реализации.
  • @borman, блин, номера страниц же плывут... отошел на часик, продолжил листать, а тебе уже прочитанные мессаги.
  • @SannySanoff, Да, ты хорошо изложил мысль моего коммента. А еще, если первая страница — это та, на которой твой самый первый пост, ВНЕЗАПНО нумерация оказывается абсолютной и никуда не плывет.
  • @borman, тогда она плывет, если кто-то удаляет свои старые мессаги (мы ведь говорим о том, что мы например смотрим общую ленту, да? или там сабскрипшн), стало быть нам надо как-то в БД хранить как страницы матчатся на мессаги, да?
  • @SannySanoff, Я не вижу смысла обсуждать такие подробности, не зная структуры существующей базы.
  • @borman, но, Ватсон, знание основ плюс дедукция же!

    1) страницы никогда не будут перманентно (в базе) матчиться на номера первой мессаги на странице, потому что для каждого юзера этот матчинг свой (см. subscriptions) и таковой матчинг едет с любым удалением мессага.

    2) динамически считать страницы от самого раннего мессага накладно каждый раз, ибо это сканирование всей базы на каждый чих

    Вывод — никто тебе не будет считать страницы в меняющемся контенте с другой стороны (с начала начал), ни в каком случае.

    Нынче же страницы считают по возрастанию страниц по меер убывания даты мессаг: отсчет страниц идет во время получения (fetch), и чем больше номер страницы, тем дольше она получается (больше fetch). Но это неудобно по причинам описанным выше (динамический контент плывет по мере листания), поэтому естественно придуман before=, который вдобавок и улучшает перфоманс, а номера страниц оставались только для search results, и то, кажется уже угнич и там от такого отказался.
  • @SannySanoff, Спасибо, кэп. Но я не верю, что не бывает такого дизайна базы, в котором нельзя сделать такой запрос дешевым.
  • @borman, На чем основывается твоя вера/невера?
  • @SannySanoff, осмелюсь предположить, что в бд не надо хранить страницы с n-ным числом постов, чтобы выводить их по запросу пользователя. Посты имеют ключи номер и юзернейм, наверняка же имеют. Запрос первой страницы генерирует страницу с n последними постами, запрос второй страницы генерирует n-следующих постов, т.к. n известно, то никаких проблем с формированием страниц нет. С т.з. поиска — это лучше, чем ?before=2462002 , потому что пользователю не надо помнить/высчитывать номера своих постов или постов в ленте подписок — можно примерко прикидывать сколько страниц пролестать. Как делать запросы в бд на последние десять постов юзернейма + n я расписывать не буду, потому что я не работал с бд, только читал.
    Алсо подобный способ навигации есть везде: в жж, на форумах, во вконтактиках. И никто не жалуюется, что что-то плывет из-за удаленных постов. И тут не поплывет. Добавить сюда еще календарик и вообще счастье станет. Почему было изначально сделано иначе и без календарика — не понятно.
  • @SannySanoff, еще можно кэшить страницы, не целиком разумеется, а по содержащимся в ней номерам постов, например.
  • @tuenut, 1) В жж нету листания по живому быстрому потоку, кроме френдов, а там плывет 2) в жж плывет и по одному юзеру, если он строчит посты достаточно быстро. 3) в форумах есть длинные топики, да, но там треды максимум единицы тысяч страниц, страницы да растут вперед, но удаления редки, и не сложно пересчитать страницы после этих удалений, и нету персонализированных проекций (subscriptions), так что нумерация вперед там вполне оправдана. 4) вконтактик не смотрю, поэтому не знаю как там.
  • @tuenut, я этого не понял, но нет, нельзя.
  • @SannySanoff, да, я не говорю что угнич нынче перфектен — он перфектен с т.з. производительности, но не юзабилити. Для юзабилити ему не хватает календаря, естественно. С календарем система идеальна.
  • @SannySanoff, есть еще способ листания: &before=XXXX&page=10, там ничего плыть не будет, но тогда понадобилось бы это как-то осторожно ввести в обиход. Возможно, после перехода по календарю можно ставить якорь (before) а листать страницами, но и то это лишь для очень редкого use case.
  • @SannySanoff, а я не понимаю почему нельзя. Я еще раз перечитал #2460610/49 и так и не понял, что мешает подменить ?before= на ?page= ? Опять же, если число постов на странице не меняется, а могут меняться только сами посты. Т.е. сервак для себя пусть считает ?before, а юзер видит ?page.
    Алсо я что-то плохо соображаю и могу нести полную околесицу.
  • @tuenut, &page=20 некруто, потому что в subscriptions и в all_messages 1) плывет 2) по производительности хуже чем before.
    Сервак не может считать себе тайком before, т.к. тайком никакого before в случае с &page= нету. Абсолютно все сервера — кроме самых убогих key/value хранилищ — и nosql, и sql, все имеют операцию fullscan, и скан индекса вверх или вниз, и доступ по ключу, и все возвращают результаты порциями. Другого ничего не изобрели, и в терминах в основном только этих операций и производятся все оптимизации бд. Если я чего-то пропустил, добавьте.