slazav ([info]slazav) wrote in [info]slazav_news,
@ 2006-11-03 12:53:00
Идеи о сайте и каталогах
Уже несколько человек мне высказывало, что надо что-то такое сделать... Может быть, оно и вправду надо...


сейчас сайт slazav.mccme.ru состоит из следующих частей:
- лента новостей, сделанная с помощью livejournal
- каталоги с разными файлами (отчеты, gps-данные, фотоальбомы и т.д.)
- оглавления к этим каталогам

При таком устройстве возникает проблема: многие полезные вещи проходят только через ленту новостей, либо в виде ссылок на другние сайты, либо в виде отдельных текстов, и совершенно теряются. Более того, по одному походу может появиться, например, несколько отчетов, иногда с большим временным интервалом, а ссылки на них никогда не будут собраны вместе.

Хочется с этой проблемой как-то побороться. Основная идея -- работать с ссылками на разные объекты, лежащие на разных сайтах, упорядочивать их по походам. Сделать одно большое оглавление для ссылок на все-что-только-можно. А все остальные оглавления - похерить.

Например, самой для меня понятной и простой для редактирования структурой является список походов (прошедших и будущих) по датам, например такой:

2007/01/01 - 2007/01/10 Лыжный поход на Олонецкую возвышенность
* К.Шрамов: приглашение http://www.livejournal.com/community/slazav_news/100.html
* К.Шрамов: заготовки геоданных http://slazav.mccme.ru/gps/20070101pr.zip
2006/12/30 Поход группы Дмитриева Березки-Морозки
* план ГД: http://super-dmitriev.narod.ru/plan...
2006/28/09 - 2006/29/09 Марш-бросок
* сайт соревнований: http://...
* впечатления такого-то: http://...
* геоданные такого-то...

и т.д. То, что раньше называлось "план-отчет".

Очень важно, чтобы такую структуру могли редактировать многие. Поддерживать план-отчет в одиночку я пробовал - надоедает быстро. :)

Другая проблема - такой "план-отчет" будет очень быстро расти и, конечно, захочется его упорядочивать по районам или как-то еще... Причем делать это надо (полу-)автоматически. То есть, каждый поход в такой системе должен иметь уникальный идентификатор и, может быть, набор тэгов.

Кроме того, очень уж заманчиво рассматривать такой "план-отчет", как выборку из некоторой общей "библиотеки ссылок", подобной tll.

Возникает вопрос, как это реализовать. Можно попробовать сделать это средствами, например, npj. Здесь, мне кажется, большие минусы - избыточность разных сервисов, и необходимость для каждого похода заводить отдельную страницу (иначе не будет уникального идентификатора и тэгов) - в такой системе, кажется, запутаются все.

Можно попробовать написать что-то самому. Задача, кажется, вполне несложная, и я вполне готов к такому. Но надо продумать общую идеологию, понять, кто еще готов этим заниматься, где это разместить, надо ли оно такое и т.п...

Общая идея, например, такая:

Иерархия объектов, как в приведенном выше примере: "раздел"/"подраздел"/"поход"/"ссылка" (названия не слишком удачные, так как не всегда могут отражть суть объекта)

"раздел" - грубо говоря, это html-страница, на которой лежат ссылки

"подраздел" - какое-то упорядочение внутри страницы

"поход" - основной объект, с которым мы работаем. Пользователи могут создавать, редактировать, удалять "походы". При этом можно явно указывать, к каким разделам и подразделам они относится. Для каждого похода заполняются некоторые (необязательные) поля: "заголовок", "дата начала", "продолжительность", и т.п. и, возможно, несколько "ссылок".

"ссылка" - url и описание. А можно и без url :)

Примеры "разделов" могут быть самые разные: уже упомянутый "план-отчет", отдельные разделы-районы, и разделы-виды туризма... (например при создании или редактирования "похода" его можно положить в разделы "план-отчет", "Карелия", "велопоходы" - вот вам и что-то вроде тэгов). А у какой-то другой компании может быть свой план-отчет в этой системе :)

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

Внутри раздела или подраздела "походы" могут упорядочиваться по разным полям: по названию (как в случае с автостанциями :)), по дате начала похода (как в случае с планом-отчетом), по дате последнего редактирования (так может быть устроен раздел "Новое", куда автоматически попадают всё)

Все "походы" хранятся где-то в базе данных, из них достаточно тривиальным способом строятся страницы-разделы - система получается очень простая.

Интересно, стоит ли затевать это?



(Post a new comment)

Wiki
(Anonymous)
2006-11-03 09:04 am UTC (link)
> Очень важно, чтобы такую структуру могли редактировать многие. Поддерживать план-отчет в одиночку я пробовал - надоедает быстро. :)

Тогда посмотри в сторону wiki (http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8). Она как раз примерно для подобных целей разрабатывалась. Может на базе неё получиться.

(Reply to this) (Thread)

Re: Wiki
[info]slazav
2006-11-03 09:10 am UTC (link)
Про вики вообще и про npj в частности - у меня есть большие сомнения, что здесь нужна такая "просторная" система. Наоборот, хочется чего-то очень простого и жесткого. Но может быть, я и не прав.

(Reply to this) (Parent) (Thread)

Re: Wiki
[info]slazav
2006-11-03 09:12 am UTC (link)
Сейчас попробую сделать примерчик - посмотрим.

(Reply to this) (Parent) (Thread)

Re: Wiki
[info]slazav
2006-11-03 09:41 am UTC (link)
Нет, все-таки не очень мне нравится. Либо надо совсем простой список делать, вроде такого:
http://npj.ru/slazav/pohody

А так - ну, насоздавал я страничек с походами.
http://npj.ru/slazav/ll/
минусы:
- надо самому думать про уникальный идентификатор - название страницы
- непонятно, как выводить разные страницы с походами, по-разному упорядоченные... (Подобные действия в npj есть, но нужных я пока не нашел)
- много всякого лишнего оформления. А нужное - не вставишь (например, ссылки в корень на все странички с походами)

(Reply to this) (Parent)

Re: Wiki
(Anonymous)
2006-11-03 09:22 am UTC (link)
Ну если ты считаешь, что можешь относительно быстро и легко написать удобную для всех (иначе ей будут пользоваться немногие) систему управления данными с веб интерфейсом, то прав :)
Просто, wiki уже готова, отлажена, вылизана так, что пользоваться ей удобно и легко, так что прописав правила добавления и редактирования данных можно быстро получить работающую систему.
Просто мне кажется, что заточить готовую "просторную" систему всяко проще чем писать и отлаживать свою. У тебя среди требований нет ничего, что выходило бы за пределы wiki.
Но если хочется писать, то задача довольно интересная :)

Фёдор

(Reply to this) (Parent) (Thread)

Re: Wiki
[info]slazav
2006-11-03 09:51 am UTC (link)
Все-таки, здесь нужно 1/1000 от Вики - то есть, очень мало. Насчет "уже готова, отлажена, вылизана" - в смысле actions и стилей - мне так не показалось, а мне это кажется очень важным, именно, чтобы скрыть 999/1000 :).

Может быть, ты в этом разбираешься лучше меня - посмотри, пожалуйста http://npj.ru/slazav/ll
Как в эту страницу встроить все страницы раздела, упорядоченные по названию / по имени файла / выбранные по какому-то тэгу? Я пока только такое оглавление осилил...

(Reply to this) (Parent) (Thread)

Re: Wiki
(Anonymous)
2006-11-05 06:46 pm UTC (link)
Все-таки, здесь нужно 1/1000 от Вики - то есть, очень мало. Насчет "уже готова, отлажена, вылизана" - в смысле actions и стилей - мне так не показалось, а мне это кажется очень важным, именно, чтобы скрыть 999/1000 :)

Скрыть будет сложно. Полагаю, придется писать куски самому, благо она открытая. Думаю, что это не сильно сложнее, чем правка кода какого-нибудь форума на php...

Может быть, ты в этом разбираешься лучше меня - посмотри, пожалуйста http://npj.ru/slazav/ll
Как в эту страницу встроить все страницы раздела, упорядоченные по названию / по имени файла / выбранные по какому-то тэгу?

Неа, не разбираюсь :) Про НПЖ вообще первый раз услышал :))) Исключительно мысли вслух на основании своего опыта общения с википедией и прочими сайтами, использующими вики :) Судя по тому, что действия можно дописывать самому, полагаю, что проблема решаема. Надо оценить трудозатраты, и принять решение о целесообразности использования готовой универсальной системы :)))

Фёдор

(Reply to this) (Parent)

Re: Wiki
[info]elentin
2006-11-03 12:45 pm UTC (link)
НПЖ очень большое, и для таких задач слишком громоздкое :)
(я немножко принимала участие в обсуждении НПЖ, ещё когда его не было. Правда, не написала ни строчки кода.)

Уж лучше какую-нибудь вики (если хочется класть какие-то страницы под замок, то можно Wacko, но она тоже на php и здоровеееенная, а если таких наворотов не надо, то можно какую-нибудь самую маленькую и лёгкую типа AwkiAwki)

(Reply to this) (Parent)


[info]vdots
2006-11-03 09:45 am UTC (link)
Интересно, сознательно ли ты перепутал Костю и Колю? :)

(Reply to this) (Thread)


[info]slazav
2006-11-03 09:52 am UTC (link)
Я не перепутал :) Костя тоже бывает :)

(Reply to this) (Parent) (Thread)


[info]vdots
2006-11-03 09:54 am UTC (link)
Костя, заготавливающий проектный трек? Ну-ну :-)))

(Reply to this) (Parent) (Thread)


[info]slazav
2006-11-03 11:48 am UTC (link)
Еще есть время - может быть, и заготовит :)

(Reply to this) (Parent)


[info]leonid_fishkis
2006-11-03 10:53 am UTC (link)
Мне показалось, что задача слишком общая и расплывчатая.
Каталог отчётов, планирование походов, поиск попутчиков - по-моему требуют разных решений.
Зачем подменять собой поисковик? Можно оставить slazav_news для новостной ленты, а
план-отчёт, делать в отдельном ЖЖ сообществе с более строгими правилами оформления сообщений.

(Reply to this) (Thread)


[info]slazav
2006-11-03 11:46 am UTC (link)
Задача очень конкретная. Сейчас геоданные идут в директорию с геоданными, отчеты идут в директорию с отчетами, фотоальбомы идут в директорию с фотоальбомами. Для каждой из них есть каталог, который надо поддерживать отдельно, руками. И есть лента slazav_news - где тоже много такого рода вещей проходит.

Хочется вместо всех этих каталогов устроить один (или не один, но чтобы остальные получались автоматически). Хочется, чтобы в нем могли быть ссылки на другие ресурсы. Хочется, чтобы поддерживать его могли несколько человек.

Кажется, это гораздо более простая и универсальная схема.

(Reply to this) (Parent) (Thread)


[info]leonid_fishkis
2006-11-05 09:29 pm UTC (link)
Тогда я бы предложил поставить для начала MySql - это пригодится и для большинства готовых решений (wiki и т.п.). Поставить phpMyAdmin и дать к нему доступ тому, кому надо. Если хотим своё - разработать БД (см. ниже сообщение [info]ivanaxe), а уже потом писать web интерфейс для упрощения работы с БД.

(Reply to this) (Parent)

И так всё хорошо
[info]mish_a
2006-11-03 11:02 am UTC (link)
По-моему, и так всё достаточно удобно.
Главный бонус ЖЖ - возможность просматривать slazav_news в ленте друзей, а не на отдельной странице.

К существующей системе, по-моему, стоить добавить выкачивание комментов в "Архив сообщений slazav_news" и поиск по архиву.

(Reply to this) (Thread)

Re: И так всё хорошо
[info]slazav
2006-11-03 11:47 am UTC (link)
лента в ЖЖ - останется, конечно. Предлагается все остальное заменить одним каталогом, более простым и универсальным.

(Reply to this) (Parent)


[info]ivanaxe
2006-11-04 07:15 pm UTC (link)
Если хочешь взять что-то готовое --- действительно, посмотри в сторону вики.
Если хочешь что-то свое, то банальная sql-табличка событий
id|f_name|f_datebegin|f_dateend|f_class|f_category|f_region|f_subregion
И к ней табличку отчетов
id|f_name|f_eventid|f_eventname|f_url|f_autor|f_cdate|f_edate
Или что-то типа этого. Кстати, некоторые сильно обрадуются, если разрешить им работать с этим на низком уровне минуя веб-морду ;)

(Reply to this) (Thread)


[info]ivanaxe
2006-11-04 07:27 pm UTC (link)
Да, если что-то а-ля вики : ну будет оно юзаться на один процент (полпроцента), ну и что?
Большинство нормальных людей тоже далеко не полностью использует возможности своей, к примеру, операционки, будь то линь, винда, бсд али еще что. Ничего предрассудительного имхо в этом нет

(Reply to this) (Parent)


[info]leonid_fishkis
2006-11-05 09:37 pm UTC (link)
Если исходить из того, что написал Слава, то структура будет всё-таки сложнее. У похода одни типы подкатегорий (подготовка-обсуждение, gps данные, отчёт, фотоальбом), у списка магазинов - другие (видимо, один - магазин) и т.п. В принципе, мне тоже кажется правильной идея с БД.

>если разрешить им работать с этим на низком уровне
Весьма вероятно.

(Reply to this) (Parent) (Thread)


[info]slazav
2006-11-05 10:26 pm UTC (link)
Не, Ваня правильнее мою мысль понял! Но я даже еще проще все себе представлял: таблица "походов" с минимумом полей (по которым мы можем представить себе разумную сортировку) + генерирующиеся из нее страницы-разделы + возможность редактировать/добавлять записи.

Таблица, например, такая:
id - название - дата начала - дата конца - список разделов/подразделов - ссылки (просто текст!!) - дата последнего исправления - кто правил.

(Reply to this) (Parent) (Thread)


[info]leonid_fishkis
2006-11-07 08:40 am UTC (link)
>Не, Ваня правильнее мою мысль понял!
Извини, я, видимо, торможу.

>Таблица, например, такая:
Всё, что в исходном примере выделено "*", засовывается в одно поле "ссылки (просто текст!)"?

(Reply to this) (Parent) (Thread)


[info]slazav
2006-11-07 09:55 am UTC (link)
У меня есть общая идея: распределить всю информацию по жестко заданным полям - невозможно. Исключения будут находится всегда, причем чем больше будет полей - тем они будут находиться реже и обрабатывать их будет сложнее.

Например, Афанасенков хочет сортировать треки по длине. А кто готов про все треки, лежащие на сайте указать их длину? Это ведь довольно творческая работа. И что писать, если длина неизвестна - 0км? И будет ли какая-то польза от всей этой штуки, если у половины треков длина не будет указана? То же самое с категорией похода, с руководителем, со всем прочим... В плане-отчете можно оставить дату - по ней придется сортировать. В разделе-районе уже и дату не нужно требовать (не на все отчеты-описания можно указать дату).

Мне действительно, очень нравится подход, примененный в tll: каждая запись - это описание похода в произвольной форме и ссылки на посвященные ему ресурсы - в произвольной форме. Хочется добавить сюда сортировку по дате и ключевые слова-разделы.

Все, что выделено * - можно засовывать в один текст, а можно в таблицу: "url-описание". Очевидно, что для пользователей это почти неважно, да и при автоматической обработке url легко вычленить.

(Reply to this) (Parent) (Thread)


[info]leonid_fishkis
2006-11-07 12:31 pm UTC (link)
Посмотрел tll, идею понял.
Теперь хочу понять, как привязано к структуре таблицы:

"название" - то, что в tll идёт первой строчкой, например: "р.Худу - р.Зун-Мурин, август 1995 г., 3кс, катамараны, каяк, Лурье В.А. (Москва)"

"список разделов" - содержит ключевые слова, например: "Тункинская долина,катамаран,водный поход"

"ссылки" - содержит описание, маршрут, отчёты и т.п., например: "текст отчета http://www.lib.ru/TURIZM/zunmurin2.txt, фотоальбом http://www.nnn.ru/"

Так?

(Reply to this) (Parent) (Thread)


[info]slazav
2006-11-09 10:56 am UTC (link)
Ага, так.
Список разделов - это именно список разделов - тех страниц, куда распихивается данная запись.
и еще "Дата" - необязательная запись, по которой кое-где может производиться сортировка.

(Reply to this) (Parent)

Re: "Афанасенков хочет сортировать треки по длине"
[info]afanasm
2006-11-09 07:16 am UTC (link)
>>>А кто готов про все треки, лежащие на сайте указать их длину? Это ведь довольно творческая работа.

Да не смеши... По сравнению с указанием ПРОМЕЖУТОЧНЫХ пунктов (а без этого идея теряет смысл) это дело пяти секунд. Загружаешь в Ози самую грубую карту (типа "вся Россия"), подцепляешь трек, нажимаешь кнопку и сразу видна его длина. Стираешь, загружаешь следующий и так далее. Для подмосковных походов длина примерно понятна из названия, поэтому грубые ошибки сразу будут очевидны (типа не стёрты "московские" точки или точки из предыдущего похода)

Кстати я согласен что для ТВОЕЙ задачи (ВСЕ записи-дневники-отчёты-приглашения-фотографии-треки-советы) создание базы совсем нетривиальный, неочевидный, и, возможно, НЕНУЖНЫЙ выход. Уж больно разнородный материал. Одни фотографии чего стоят.

Я-то предлагаю отдельную специализированную базу только по ТРЕКАМ, причём только по ПВД-шным. Они более менее однородны по свойствам. У них достаточно узкий набор параметров. Но это вроде обсуждается уже в другой ветке :)


(Reply to this) (Parent) (Thread)

Re: "Афанасенков хочет сортировать треки по длине"
[info]slazav
2006-11-09 11:40 am UTC (link)
> Да не смеши... По сравнению с указанием ПРОМЕЖУТОЧНЫХ пунктов

Не все так просто, я думаю. Тот кто выкладывает трек, может указать промежуточные пункты, длину, какое-то общее название ("катание на велосипеде вокруг дачи") - и ты вынужден именно это вставлять в каталог. А изыскивать какую-то дополнительную информацию (кроме может быть, даты) в самом треке - дело творческое и потому гнилое :)

Сходу - такие примеры:

- "проект похода по Олонецкой возвышенности" (несколько вариантов с разными пунктами и длинами)
- "пеше-водный поход на р.Уда" (записан трек только пешей части и заброски - и трек дороги кажется очень важным, а измерить длину сплава тебе тяжело - карты под рукой нет)
- Часть трека. Недостающую часть ты не можешь восстановить - будешь писать примерную длину?


(Reply to this) (Parent) (Thread)

Re: "Афанасенков хочет сортировать треки по длине"
[info]afanasm
2006-11-16 03:46 pm UTC (link)
>>>Сходу - такие примеры:

Я ж говорил - ПВД, подмосковье. Там всё проще. Горные и особенно водные не в счёт.
Вообще особо на длине можно не заморачиваться, это просто удобный КОСВЕННЫЙ показатель, насколько близка организация архива к базе и далека от свалки текстовых файлов.



Что до основного вопроса темы - я наконец "причесал" сайт Сафронова до более менее унифицированной структуры.
Посмотреть можно на прежнем месте, вот тут: http://aisafronov.100km.ru/

(Reply to this) (Parent)



[ Home | Update Journal | Login/Logout | Search | Viewing Options | Site Map ]