[Petermechanic]

12. C - Dlaczego? Pisałem DSF-a i skórka PA była zmienna, w zależności od używanej na forum (wbudowana w katalogu danego stylu). Potem były przez to same problemy. A tak, możesz zrobić dobrą skórkę dla PA i osobną dla stron użytkownika

[Asdef]

moim zdaniem PA, pownien mieć swoje menu i nie zawracac sobei glowy skórkami w panelu

[WebCM]

Ostatnie wyniki: 12 A (tak zdecydowali użytkownicy i problem zniknął), 13 (niski priorytet)

14. Kanały RSS
Nie mam jednej koncepcji, która okazałaby się najlepszym wyjściem. Może pomożecie w dokonaniu słusznego wyboru. Nowa wersja CMS będzie obsługiwać kanały RSS, tylko właśnie... nie chcę skomplikować kodu ani interfejsu, ale zaoferować korzystne rozwiązanie.

A. Niech będzie tylko 1 kanał RSS dla każdego języka, zawierający określoną ilość nowości.

Admin może wyłączyć tworzenie RSS-ów w ustawieniach systemu. Nie będzie oddzielnego modułu RSS w panelu admina.

B. Niech admin tworzy tyle kanałów RSS, ile chce, ale tylko dla nowości.

Panel admina zawiera dodatkową podstronę - RSS. Można tworzyć dowolną ilość kanałów. Tutaj znowu są różne warianty:

B1. Admin może wybrać tylko 1 kategorię, z której newsy będą trafiać do plików RSS albo opcję "wszystkie nowości" (wszystkie newsy trafią do RSS).

Zalety:
+ uproszczony interfejs
+ w bazie danych będzie tylko 1 wartość liczbowa
Wady:
- nie można wybrać np. 2 określonych kategorii

B2. Admin może wybrać wiele kategorii lub opcję "wszystkie nowości"

Zalety:
+ możliwość wyboru wielu kategorii (tylko określonych przez admina)
Wady:
- nie można w bazie zapisać wartości numerycznej - trzeba oddzielić ID kategorii przecinkami, co jest sprzeczne z zasadami normalizacji; ewentualnie stworzyć nową tabelę dla powiązań ID-RSS | ID-Kategorii

C. Podobnie jak w B, ale dla wszystkich typów kategorii.

Zalety:
+ więcej możliwości
Wady:
- więcej operacji podczas tworzenia RSS (np. wyciąganie informacji o typie kategorii, dołączanie types.ini), gdyż każdy typ ma własną tabelę, np. arts, files, links, news...

W przypadku C2: Jeżeli admin wybierze kilka kategorii RÓŻNYCH typów... Taka sytuacja jest też możliwa. Chyba trzeba to umożliwić i bardziej skomplikować kod.

(podpunkty takie same jak w punkcie B)


15. Statusy komunikatorów

A. Ikony statusów jako tło w CSS zamiast <img> - TAK / NIE
B. Link GG powinien prowadzić do serwisu MojaGeneracja - TAK / NIE / ZALEŻY

Odpowiadajcie.

[Petermechanic]

14. Nie wgłębiałem się, ale admin może wybrać do RSS wszystkie najnowsze newsy (oczywiście każdy dostępny język) lub poszczególną kategorię.
15B - NIE!! Dlaczego? Pomyśl, dlaczego przesiadłem się na Jabbera

[GhostX]

1. C
2. A
3. B / D
4. Czytane newsy - przedstawione na wykresach; które arty są na TOP, itd?
5. A (niech będzie wybór w PA)
6. B (jak ktoś chce sobie zdjęcie trzymać to niech trzyma u siebie na serwerze)
7. A (lub A i B - w zależności od typu witryny)
8. B (jak ktoś chce awatar to sobie wrzuci)
9. B
10. TAK
11. A (jeżeli dotyczy to TYLKO rozszerzenia)
12. A
13. ~ ?
14. B2
15. A TAK; B NIE

[WebCM]

Wynik:
* 14 - rozstrzygnie się niebawem
* 15 A (TAK - przynajmniej na razie) B (NIE - ostatecznie wprowadzę opcję, gdy będzie popyt)

Już być może ostatnie pytania do ankiety - tym razem otwarte.

16. RSS - ciąg dalszy
Pisałem już o tym na forum KŚE. Mam jeszcze inne wizje. Przedstawię je tutaj:

A. Użytkownik decyduje, co chce otrzymywać w czytniku RSS. Może tworzyć swoje prywatne kanały (albo ma tylko 1). Pliki .xml NIE są zapisywane na dysku przy dokonywaniu zmian w treści (nawet dla 1000 userów wygenerować 1000 RSS-ów - to może chwilę potrwać), lecz generowane w locie. Ewentualnie można tworzyć cache na serwerze. Informacje o preferencjach RSS użytkowników są trzymane w bazie danych.

Zalety:
+ Użytkownik sam wybiera interesujące go tematy (czyt. kategorie)
+ Zawsze aktualne dane (albo trochę nieaktualne, gdy jest cache)
Wady:
- Większe obciążenie serwera - każde żądanie prowadzi do pliku .php
- Wygenerowanie XML i odczyt danych z bazy może chwilę potrwać przy dużym ruchu (choć i tak krócej niż wygenerowanie całej strony, np. strony głównej, widoku kategorii, profilu użytkownika...)

B. Każda kategoria ma swój kanał RSS. Może też istnieć ogólny RSS z wszystkimi newsami. Wtedy dodatkowa podstrona RSS w panelu admina jest niepotrzebna (admin nie tworzy własnych kanałów). Są jedynie ogólne ustawienia RSS-ów (można je też w ogóle wyłączyć).

B1. Czytniki kierują żądanie do gotowego pliku .xml, który jest odświeżany po zmianach treści
B2. Czytniki kierują żądanie do pliku .php, który generuje XML lub wczytuje go z cache

C. Admin sam tworzy kanały RSS i decyduje, z których kategorii mają pojawiać się newsy (lub inne typy zawartości). RSS-y są odświeżane po zmianach, więc czytnik kieruje żądanie bezpośrednio do pliku .xml. Więcej informacji w pytaniu nr 14.

Jak widzicie implementację RSS w systemie CMS? Co sądzicie o powyższych wizjach?
Czyli walka między obciążeniem serwera a innowacjami. Wariant A przyda się w praktyce tylko w rozbudowanych serwisach, w których pojawia się dużo treści, ale przycisk "Subskrybuj kanał RSS użytkownika" jest raczej niespotykany Za to w przypadku C pliki .xml można pobierać błyskawicznie, nie męcząc serwera.

17. Data urodzenia
Wprowadziłem pole JABBER do profilu użytkownika. Może jeszcze brakować daty urodzenia. Czy rzeczywiście przyda się w praktyce? Na razie nie ma powiadamiania o urodzinach, a stron 18+ nie będzie. Jednak wiedząc, ile kto ma lat, można zawrzeć bliższe znajomości (a może skutek będzie przeciwny), zorientować się, w jakim wieku najwięcej internautów odwiedza serwis (chociaż lepiej przeprowadzić ankietę, bo zagłosują też goście). O przydatności pola DATA URODZENIA zdecydujcie sami:

A. Zdecydowanie TAK - pole jest potrzebne
B. TAK - ale po włączeniu opcji w panelu admina
C. NIE - pole jest niepotrzebne

Nie spotkałem jeszcze forum lub serwisu, w którym jest powiadamianie o imieninach. Może wprowadzić taką funkcję?

[Petermechanic]

bezsens, to nie NK - zarówno profilu jabbera jak gg oraz skype jest wiek - jak ktoś jest ciekawski to i tak do tego dojdzie

[GhostX]

Co do RSS to nie wiem, ale zrobić tak żeby było dobrze zarówno dla użytkowników jak i serwera na którym stoi witryna

17. Data urodzenia
Moim zdaniem pole totalnie zbędne.

[WebCM]

18. Nowy system skórek
Czy podoba ci się nowy system skórek? Cechy:
- wykorzystuje język szablonowy zamiast kodu PHP
- pozwala na modyfikację wyglądu wszystkich podstron
- zawiera dużo plików, obecnie 50 plików, w tym 45 szablonów

Przykład: http://code.google.com/p/...S/style/default

A. TAK - wszystko mi się podoba
B. Jest zbyt dużo plików - niektóre trzeba usunąć lub przenieść (które?)
C. Język szablonowy jest za trudny lub kod zbyt nieczytelny
D. NIE podoba mi się - inaczej bym to zrobił (jak?)

19. Czy Panel Redaktora powinien być oddzielony od Panelu Administratora?
Wyjaśnijmy pojęcia. W wersji 2009 wprowadziłem Panel Redaktora z dostępem dla redaktorów. Można dodawać / edytować artykuły, pliki, obrazy, linki i newsy, a także moderować komentarze. Panel Admina z dostępem dla administratorów umożliwia zmianę ustawień, kategorii, ankiet, rozszerzeń, użytkowników, grup, RSS, wolnych stron...

Panel Admina: http://dhost.info/compmaster/img/zrzuty/bloki.png
Panel Redaktora: http://yfrog.com/j930784871p

A. TAK - jest dobrze. Panele powinny być rozdzielone.
B. NIE - zarządzanie treścią powinno odbywać się w panelu admina jak w wersji 2.1
C. Mam inny pomysł - jaki?

20. Pytanie powiązane - czy podczas edycji lub dodawania treści chcesz widzieć panele menu (które są włączone w serwisie), aby mieć łatwy dostęp do kategorii i innych artykułów, newsów, itd?

A. TAK - chcę widzieć bloki menu z linkami (czyli edytować treść z poziomu serwisu)
B. NIE - wolę edytować treść w odizolowanym środowisku (czyli z panelu admina)
C. Mam inny pomysł - jaki?

21. Czy adresy URL powinny zawierać słowa kluczowe (tytuły obiektów)?
Bez słów kluczowych: strona.pl/art/99
Ze słowami kluczowymi: strona.pl/art/99-jak-zainstalowac-linuksa

A. TAK - powinny zawierać słowa kluczowe
B. NIE - adresy będą za długie
C. W zależności od ustawień

--- pytania nieobowiązkowe dla tych, którzy nie testowali F3Site ---

22. Czy aktualny układ panelu administracyjnego dezorientuje nowych użytkowników?
Napisz, co należy zmienić, aby poprawić użyteczność i prostotę obsługi.

A. TAK
B. NIE

23. Flagi i górne menu - aktualnie trzeba je modyfikować ręcznie w body.html

A. To mi odpowiada, a niepotrzebne języki usunę przed instalacją CMS-a
B. Wolałbym edytować górne menu w panelu admina
C. Wolałbym wybrać w panelu admina języki, które chcę używać
D. Mam inny pomysł - jak byś to rozwiązał(a)?

Mimo wszystko zachęcam do wypełnienia ankiety o F3Site. Jest 20 pytań, ale wszystko potrwa tylko kilka minut, gdyż większość pytań jest zamknięta (ABCD), zaś opisowe są nieobowiązkowe.