+46.04
361 читатель, 307 топиков

Добавить ссылку описания для скачиваний обновлений в каталоге

Ко мне часто обращаются пользователи с двумя вопросами:

  1. Как получить обновления с каталога и
  2. Как обновить текущий плагин

Как же можно подсказать пользователям как решать эти проблемы?

Читать дальше →

Список доверенных разработчиков

Раз пошли такие темы про кидал:
livestreet.ru/blog/13250.html
livestreet.ru/blog/paidorders/13244.html

Возможно, пора уже на ЛС создать список доверенных разработчиков работающих под заказа, которых бы вносил ort по результатам представленных работ. Потому что не все разработчики выкладывают свои поделки в каталог и не все выкладывающие работают под заказ.

Выделение активного комментария

Всем привет!
Уже сейчас особыми стилями выделяются специфичные комментарии (собственные, администратора, удалённые и т.д.). За это отвечает
<div id="comment_id_{$oComment->getId()}" class="comment {if !$oUserCurrent or ($oUserCurrent and !$oUserCurrent->isAdministrator())}not-admin{/if}

и т.д. в файле comment.tpl (у меня 0.5, разницы с текущей версией особо нету).

Но когда пользователи переходят по ссылкам на определённый коммент (например site.ru/blog/2080.html#comment6041) — почему-то не реализована подсветка выбранного комментария.
С удивлением увидел, что этого нету и на хабре (вроде как достойный пример интерфейса).

Понятное дело, что страница прокручивается до выбранного комментария, но в случае, если он внизу (а последние комментарии чаще будут там) — то страница прокручивается до самого низа, и непонятно какой из 3-5 комментариев, попавших в скрин тот, который я хочу увидеть.

Это недоработка, или есть принципиальная проблема с реализацией?
Я так понимаю, что при переходе внутри темы от site.ru/blog/2080.html#comment6041 к site.ru/blog/2080.html#comment6046 например страница не перезагружается, и соответственно стили можно будет менять только js. Но хотя бы при первичной загрузке отобразить 1 выбранный комментарий очень полезно.

Шаблоны для LS - вырабатываем стандарты верстки (продолжение)

Затравка темы здесь: «Супер-хуки» в шаблонах — вставка кода в любое место
Более четко сформулировано и начало обсуждения здесь: Новые шаблоны для LS — стандарт верстки

По откликам на мой топик по стандартам верстки, я понял, что тема эта актуальна, и есть энтузиасты, готовые участвовать в реализации. Это хорошо.

Хотелось бы услышать еще мнение наиболее активных разработчиков плагинов и самого Макса (ака ort ). А то, может, «проблемы негров шерифа не волнуют» ©… :)

Но я пока не вижу в предложенном подходе никаких минусов, кроме плюсов.

Итак, краткое резюме по результатам обсуждения:
1) нужно структурировать наборы шаблонов к скинам, используя механизм наследования Smarty
2) нужно выработать соглашения по CSS-селекторам, которые в шаблонах используются
3) в обоих направления предлагается опираться на БЭМ-методологию

Важный момент: реализация этого подхода не изменит саму логику движка, и старые скины будут работать, как и прежде!

А теперь, ближе к делу.
Читать дальше →

Новые шаблоны для LS - стандарт верстки

В комментариях к моему топику про HTML-хуки было немало высказываний на тему стандартизации разрабатываемых шаблонов по LS. Хочу высказать свои соображения на эту тему.

Собственно, проблем тут две:
1) Разбивка страниц на отдельные шаблоны (файлы)
2) Именование CSS-классов

Выскажусь пока по первой проблеме.

Разбивка страниц на отдельные шаблоны

Читать дальше →

Предложения на счет Livestreet-шаблонов

Всем доброго времени суток!

Разрабатывая свой пакет, столкнулся вот с какой проблемой: в Livestreet-шаблонах файл header.tpl содержит все все, что только можно, и даже больше, чем надо. В частности помимо <head></head>, уже за его пределами содержится половина самой страницы, вместе с блоками #header, #content, сайдбаром и т.п. Но ведь это не круто. Ведь наверняка не только я сталкивался с задачей оформления пользовательских страниц, на которых шапка, вместе с пользовательским меню, формой авторизации и т.п. вообще могут отсутствовать. При этом мне с большой долей вероятности может понадобиться весь <head>

Я предлагаю в дальнейшем при разработке Livestreet-шаблонов <!doctype html> вместе с <head></head> вывести в отдельный файл head.tpl.
А head.tpl уже инклюдить в header.tpl
Таким образом кому понадобится шапка полностью, со всем плюшками, сделают {include=«header.tpl»}, а кому только <head>, со всеми его CSS-ами и т.п., сделают {include=«head.tpl»}
Читать дальше →

Система подсказок по интерфейсу

Наткнуся на один фреймворк, типа бустрапа, называется Foundation. Понравилась там фишка всплывающих подсказок — смотреть демонстрацию.

Весьма удобно было бы создать подобную систему для ливстрит. Зарегался пользователь, а ему вывелась подсказка вверху типа «Это ваше личное меню, отсюда можно перейти в профиль, сообщения и другие персональные разделы». И ссылки «следующая подсказка» и «закрыть навсегда».

Неопытные пользователи будут рады, что их «ведут», и будут быстрее вливаться в процесс даже не всегда оттого, что они поняли как это работает, а просто потому что хочется попробовать то, о чем рассказывается в подсказке. Типа «ну-ка что тут у вас...». Новички редко голосуют за посты, комменты, т.к. просто не уверены, что значит это голосование и не нажимают на кнопку.
Читать дальше →

Категоризация блогов и еще кое что

Как то я уже писал о подобном, вот решил написать еще раз.

Блогов на сайте может быть достаточно много. Новичку, только что зарегистрировавшемуся на сайте, довольно сложно определить, куда ему писать и есть ли вообще нужный ему блог. Да, в 1.0 есть поиск блогов, но многие ли сразу идут в поиск? По-моему своевременное использование поиска есть одна из самых распространенных проблем на форумах и сообществах.

Вторая проблема — новичку трудно вообще понять, что ему сначала нужно подключится к блогу, только после этого он сможет туда написать. Частично проблему решает плагин BlogAutoconnect, но есть один минус в нем — при публикации топика в списке блогов выводятся ВСЕ блоги на сайте, а их может быть более 50 или 100… что тогда? изучать этот список на два экрана?

Поэтому есть предложение, как усложнить этот процесс в системе и упростить для пользователя.
Читать дальше →

Рейтинг и сила: зависимости на сайте — доходчиво для пользователя

Рейтинг и сила в сообществах, создаваемых на базе LS являются одной из основных социальных составляющих, опрделяющих возможности пользователей на сайте, основными характеристиками «героев».

Все замечательно для адвинистрации сайта и старожителей. Но для нового пользователя нигде не объяснено про зависимости возможностей его действий на сайте от рейтинга и силы. И наоборот.

Обычно, объяснение взаимосвязей рейтинга, силы и возможностей — ложиться на администрацию сайта, и выглядит как статическая страница с описанием правил сообщества, зависимостей рейтинга, силы и тп…
Если по какойто причине администрация не завела эту страничку, и не объяснила доходчиво пользователю о его возможностях, люди, зачастую, впадают в ступор. Данный сайт, к примеру, не исключение.
Не зная лимитов на действия, мне, например, приходится каждый раз кликать по голосам за топик и тп, и видеть красный информер, напонимающий, что я пока не могу оценить пост. Но не говорится ничего о том, что нужно сделать, что бы оценить пост, какое значение силы нужно набрать для этого и тп… с каждым новым баллом, ты опть идешь, и пробуешь — можешь ли проголосовать или нет. Это бесит. Понятно, что в контесте этого информационного сайта, все равно, но представьте реакцию пользователей на своих сайтах… Особенно, пользователей, далеких от IT, Хабра и аналогичных сообществ. Пользователь, если и не уходит, то не реализовывает для себя всю сущьность движка LS, идеологию и фичи. Так не должно быть.

Предложение:

1. На странице профиля указывать не только текущее значение силы/рейтинга пользователя, но и минимально необходимые значения для действий на сайте — голосования за топики, пользователей, создание блога и тп. Это совсем не сложно — всего лишь вывести данные из конфига LS, добавив небольшие текстовые комментарии.

2. При информировании пользователя о том, что он не может произвести действия, в информер добавить поле, разъясняющее о том, какое кол-во рейтинга/силы ему необходимо набрать, что бы он смог осуществить желаемое действие. Возможно, добавить к этому ссылку на то, как ему набрать рейтинг/силу.

Мне кажется, что проедложение абсолютно не сложно в реализации, разработка плагина, реализующего вывод нескольких значений из конфига в пару хуков — займет совсем не много времени. Но, так как мое предложение — не расширение текущего функционала, а, на мой взгляд, более правильно преподнесенный базовый функционал, это должно быть реализованно в движке.

А вы как считаете, разработчики и активные пользователи LS?