Идеи
Съдържание
Задължително посочване на имейл
Идеята в едно изречение
Трябва задължително всеки потребител да си е посочил e-mail за връзка.
Пълно описание
Тази идея има отношение, както към раздел „Връзка с екипа“, така и към това, че комуникацията между потребителите ще се улесни значително.
Необходими умения за реализацията й
Достъп до административната част на сайта, както и придобиване уменията на Борислав. :)
Приоритет: 1
Причини: Изпуснати потенциални помощници и зависване на записи в ателието заради неосъществена комуникация с потребителите.
Забележки
Не е сигурно, че при въвеждането на тази възможност ще има 100% осъществена комуникация, но е крайно време да бъде въведена.
- Коментар: Предлагам следната корекция: „Всеки потребител, който използва страницата „Връзка с екипа“ или желае да се включи в обработката на текстовете, трябва да е посочил валиден имейл за връзка.“ Излишно е да се задължава всеки потребител да регистрира имейл; в крайна сметка базата ще се напълни с [email protected], което на практика ще е същото. Според мен не е необходим достъп до административната част на сайта, просто трябва да се модифицират съответните модули. — Mandor 12:42, 11 април 2011 (EEST)
- Коментар (2): Подкрепям вариантът на Борислав за напомнящо съобщение при липса на имейл в страницата „Връзка с екипа“. Между другото, смятам за много полезно, че „Връзка с екипа“ е достъпна и за нерегистрирани потребители. — Mandor 12:55, 11 април 2011 (EEST)
Отписване на потребители от ателието
Идеята в едно изречение
Премахване на записани потребители в ателието от някой запис на произведение.
Пълно описание
Включвайки се потребител, който частично е направил обработка на качените изображения в ателието и заявявайки, че текстът е готов за добавяне в библиотеката, е недопустимо. По този начин друг доброволец има възможност да се подлъже и да започне обработката на частично разпознатия текст вместо да разпознае изображенията. Това ще е голяма загуба на време за всички. Идеята ми е да има възможност от няколко потребителя с повече права да премахват файла и въобще псевдонима на потребителя от записа в ателието, така че пак записа да се върне в изходно положение (напр. „Очакват се коректори“).
Необходими умения за реализацията й
Да си програмист разбиращ php и бази от данни. :)
Приоритет: 5
Причини: Подобряване на работния процес в ателието.
Забележки
Преди изтриването на потребителя, от дадения запис, е задължително да се осъществи комуникация с него.
- Коментар: Струва ми се излишно. 1. Наистина е недопустимо текстът да се маркира като очакващ проверка, но е напълно възможно някой потребител да разпознае текста и да направи начална корекция (като vens), а друг да извърши същинската, пълна корекция. Изображенията така или иначе ще останат (от първия потребител). 2. Хората, които ще вземат решение дали текстът е достатъчно готов, така или иначе имат право да променят статуса на записа в ателието. Освен това такива случаи са сравнително редки и ще е по-практично да обезпокоим Борислав за 10 мин веднъж на месец, отколкото да се добавя такава функция. Да не говорим, че така се отваря възможност за бъдещи проблеми. — Mandor 12:50, 11 април 2011 (EEST)
„Олекотяване“ на SFB
Идеята в едно изречение
Премахване на излишни маркери от SFB-парсера.
Пълно описание
Да се премахнат следните маркери:
- S (знак) — в блоковия и едноредовия му вариант. Вместо него да се използва например
- M> frame
- L (писмо). Вместо него да се използва само цитат (C).
Необходими умения за реализацията й
Уеб-програмиране (PHP)
Приоритет
Висок (не изисква много ресурси)
Промяна вътрешния формат на текстовете
Идеята в едно изречение
Замяна на сегашното представяне на текстовете (SFB) с XML.
Пълно описание
В момента текстовете в Читанка се съхраняват във формат SFB. Това налага средно сложен анализ на файла, преди да се конвертира към някой от крайните формати (TXT, FB2, ePub), като този анализ се извършва винаги, когато исканият краен формат не съществува в кеша на сайта. Предложението е текстовете да се съхраняват в XML-блокове; дори не е необходимо да е пълноценен XML-файл. Това дава следните предимства:
- Еднократен (сложен) анализ на изходния SFB-файл;
- Възможност за (почти) директно конвертиране на вътрешния XML файл в някой от изходните формати, например чрез XSLT.
- Възможност за усложняване на SFB-парсера по такъв начин, че да улавя повече невалидни конструкции; в момента това е непрактично.
При тази организация на текстовете SFB-форматът ще се превърне в още един от изходните формати за конвертиране, който е интересен само за коректорите.
Необходими умения за реализацията й
Уеб-програмиране (PHP, MySQL); познаване на модулите за конвертиране.
Приоритет
(направо не искам да предполагам :-)
Забележки
- „Пакетните“ файлове, които описват книгите и сборните издания, също ще се представят чрез XML.
Добавяне на метаданни към SFB-формата
Идеята в едно изречение
Добавяне на пълен набор от метаданни за произведението/книгата в реализацията на SFB-формата.
Пълно описание
В началото всички метаданни бяха добавяни „на ръка“ при качването на текста в сайта. В последствие функционалността на информационния блок се разшири така, че да обхваща базовите метаданни (предположение: които в момента се поддържат от базата данни) — оригинално заглавие, поредица, номер, преводач и т.н., — реализирани чрез двойка „променлива“=„стойност“. Предложението е наборът от метаданни да се разшири до по-пълноценно множество (за основа може да се използва FB2-спецификацията и да се допълнят евентуалните липси), което да се добавя в началото на SFB-файла, или да се използва отделен файл (FBI: Fiction Book Info — информация за художествена книга). За представянето отново може да се използват двойки „променлива“=„стойност“, но е желателно имената да са на кирилица и да са групирани по предназначение („Информация за произведението“, „Информация за изданието“ и т.н. — по аналогия с FBS-формата). Този набор ще се записва в базата данни и ще помага за генериране на по-пълноценни изходни файлове, както и при евентуално разширяване на функционалността на сайта.
Необходими умения за реализацията й
Уеб-програмиране (PHP, MySQL); познаване на модулите за конвертиране.
Приоритет
?
Представяне на издателски поредици
Идеята в едно изречение
Възможност за разглеждане на книгите, групирани по издателски поредици.
Пълно описание
В момента книгите могат да се разглеждат само по азбучен ред според заглавието. Предложението е да се реализира нова функция, която да предоставя възможност за разглеждане на книгите по издателски поредици („Галактика“, „Приключения и научна фантастика“ и т.н.).
Необходими умения за реализацията й
Уеб-програмиране (PHP, MySQL); познания за структурата на базата данни.
Приоритет
Нисък.
Две нива на проверка на текстовете
Идеята в едно изречение
Трябва проверката на текстовете да се раздели на две нива - начална проверка (първо ниво) и валидация (второ ниво).
Пълно описание
В първото ниво на проверка на текста да се извършват всички възможни проверки (правопис, пунктуация, форматиране на текста, качество и правилна обработка на изображения, които трябва да са заедно с обработения текст). Задължително преди започването на проверката на текста той се връща на статус „Коригира се“ и в коментара се написва, че текста в момента се проверява. В скоби може човека, който извършва проверката да си напише псевдонима. Този вариант е за настоящата ситуация, ако се променят някои функции в ателието може да се прави и по друг начин - система, чрез която да се отчита всеки какво е направил за дадения запис в ателието. След като главният коректор отстрани грешки, за които е сигурен, се свързва с доброволеца и подробно му обяснява с примери какви грешки е допуснал. Описват се грешките, които се срещат 5-10 пъти в текста, а не за някоя инцидентна грешка (изключение прави неправилното форматиране в SFB формат). След това променя статуса от „Коригира се“ на статус, указващ, че текста е готов за второ ниво - валидацията.
Във второто ниво се извършва валидиране на текста, което се изразява в проверка на SFB формата. При желание от страна на валидатора, той може да направи и останалите проверки на текста. Идеята е, че след първата проверка на текста ще има много по-малко грешки, което ще облекчи валидатора. След като валидаторът приключи с окончателното валидиране на текста, той трябва да се свърже с главния коректор и да допълни списъка с допуснатите грешки. Накрая валидаторът променя статуса на записа на „За добавяне“.
Необходими умения за реализацията й
Използване уменията на Борислав за добавяне на новите функции.
Приоритет: 1
Причини: Обработка на всички зависнали записи със статус „Чака проверка“ и възможност за включване на нови доброволци в проверката на текстовете.
Забележки
Независимо, че част от екипа имат правата да пускат произведения със статус „За добавяне“, според мен е задължително всеки текст да минава проверка поне през двама човека.
Ето защо при приключването на корекцията на даден текст, то той да се пуска със статус „Чака проверка“, след което някой друг отново да го провери.
Практиката показва, че при текстове обработени само от един човек винаги има грешки.