[WebCM]

1. Komentowanie zawartości

A. Pod komentowaną pozycją
Czyli pod artykułem, newsem, itd... i poprzednimi komentarzami. Zaletą jest to, że nikt nie skomentuje pozycji, jeśli nie istnieje lub jest wyłączona. Uwaga: gdy ADMIN wyłączy element podczas gdy USER będzie go komentował (co nie powinno się raczej zdarzyć, ale może), USER straci treść (można zastosować jakieś alternatywne wyjście).

B. Na osobnej podstronie
Z jednej strony nie trzeba ładować za każdym razem artykułu oraz poprzednich komentarzy, gdy np. klikamy "Podgląd", a z drugiej - trudniej sprawdzić, czy pozycja jest włączona i czy istnieje (rozważmy też to, że rozszerzenia także mogą wykorzystywać moduł komentarzy, a wtedy nie znamy np. nazw tabel i ich struktury).

C. Odpowiedź A + AJAX
Formularz jest pobierany za pomocą AJAX na żądanie. Nie każdy będzie komentował, a gdy obsługa BBCode jest włączona, trzeba załadować edytor: editor.js oraz ikony. A jeśli użytkownik ma wyłączoną obsługę JavaScript? Pozostaje przejść na osobną podstronę (B) lub ładować podstawowy formularz (A) albo... odświeżyć wszystko - np. artykuł + poprzednie komentarze, tylko do tego dołożyć formularz zamiast linku "Dodaj komentarz".

2. Edycja zdjęcia lub awataru w profilu użytkownika

A. Tam, gdzie pozostałe informacje
Na przykład pod informacjami dodatkowymi, a powyżej pola "O sobie". Ewentualnie pod "O sobie" w oddzielnym nagłówku.

B. Na osobnej podstronie
Tylko gdzie umieścić link do tej podstrony?

C. Odpowiedź A, tylko w innej zakładce
Do zrealizowania, tylko dochodzi znów problem użytkowników bez obsługi JS.

3. Zmiana daty artykułów, newsów, itd.

A. Nie potrzeba zmieniać dat
B. Za pomocą kalendarza w JavaScript
C. Za pomocą pola "datetime" albo "date" i "time" (tylko Opera)
D. Pola <select>

4. Statystyki dotyczące treści
Jakieś pomysły?

Wypełnijcie ankietę. Jeśli odpowiedzi są oznakowane literami, podajcie tylko literę.

[Petermechanic]

1. C
2. A

[pim]

1. C
2. A
3. B

[WebCM]

1. Na pewno będzie AJAX, czyli C. W przypadku braku obsługi JavaScript - nie odpowiada ani A, ani B. Prawdopodobnie zostanie tak, jak jest (B), aby nie doszło do konfliktów między szablonami i nagłej utraty treści w przypadku wyłączenia artykułu, zaś problem "bezpańskich komentarzy" rozwiążę w inny sposób.

2. Jeśli wprowadzę galerię emblematów lub galerię zdjęć wysyłanych przez użytkowników, pozostaje B (ew. C). Co o tym sądzicie?

3. Najpowszechniejsza opinia = B. W przypadku braku JS - może D.

Jakieś uwagi, sugestie, opinie? Co jeszcze proponujecie?

[Petermechanic]

WebCM, dzisiaj rzadko kto wyłącza JS! Jeżeli ktoś ma być do przodu, to napewno go nie wyłączy! kiedyś tak było, dzisiaj nikt nie wyłącza, bo internet poszedł do przodu ("Web 2.0")

[pim]

Ale strona powinna być czytelna i hmm... używalna z wyłączonym JS. Pisał o tym kiedyś riddle (Piotr Petrus) - http://perfectionorvanity...cza-javascript/

[WebCM]

Dorzucę jeszcze kilka pytań i liczę na dużą frekwencję.

5. Czy wyświetlać zawsze awatar użytkownika?

A. NIE - to nie ma sensu - dodatkowe żądanie, więcej KB do przesłania...
B. TAK - w menu "Użytkownik"
C. TAK - w innym miejscu (gdzie?)

6. Prywatne galerie użytkowników
Każdy użytkownik miałby prywatną galerię. Wybrane zdjęcie stałoby się znakiem rozpoznawczym. System automatycznie tworzyłby miniaturki. Możliwość dodania zewnętrznych obrazów z URL.

A. TAK - to przyciągnie użytkowników skryptu
B. NIE - to zbędna funkcja

7. Uprawnienia użytkowników (np. do edycji kategorii X lub do panelu admina)
Powinny być:

A. Nadawane poszczególnym użytkownikom
B. Nadawane grupom użytkowników

8. Galeria awatarów

A. TAK - do włączenia w panelu admina
B. NIE - to zbędna rzecz

Odpowiedzcie na pytania - najlepiej z uzasadnieniem odpowiedzi.

Jeśli chodzi o JS to w niektórych instytucjach dla bezpieczeństwa może być wyłączony. Może ktoś korzysta z nietypowej przeglądarki, która nie obsługuje wszystkich funkcji? Albo z tekstowej na starym kompie?

[Petermechanic]

5. B (ale w opcjach profilu możliwość wyłączenia pokazywania awatarów, np. user "x" i "y" mają awatary, a user "z" ma wolne łącze - w UCP może wyłączyć)

6. A - domyślnie wyłączone, zezwolenie na jeden awatar, do włączenia w ACP (żadnych zdjęć, to nie fotogaleria!)

7. A lub B (w ACP ustawienia kategorii: dostęp [radio: dla użytkowników; dla grupy])

8. Inna propozycja: galeria gotowych awatarów, który można sobie wybrać (jak w IPB)

[Asdef]

Sorry, ze od pyt 5 ale tak..

5 – C, niech się pyta podczas instalowania skryptu, jak ktos oszczędny w KB wybierze sobie dla siebie opcie… no i w PA nieh będzie wybor…
6 – A, uzasadniam… bo to jest jak w tej akcji „bo zupa była za słona”, chodzi mi o to, ze ktoś kto chciałby przeznaczyć skrypt na jakis portal dla fotografów, fajna taka opcja.
Tez proponuje w PA dawać taką możliwość wyboru przez admina
7 – C, nie ma takiego wyboru… ale uważam, że dzisiaj Cisy sa na tyle rozwinięte, ze obje opcje są dobre…
8 – A, tak jak w pytaniu 5, uzasadnienie jest podobne

[WebCM]

Ad 2. A - Na razie jest prymitywna obsługa awatarów - tylko upload, ale to chyba wystarczy. W panelu admina można ustawić dowolny obraz.

Ad 5. Są różne opinie. Na razie A.

Ad 6. Różne opinie. Prywatne galerie awatarów raczej nie ma sensu, chyba że ktoś umieszczałby znaczki pocztowe. Zastanowię się nad galerią zdjęć osobistych, ale prawdopodobnie będzie to rozszerzenie, niezwiązane z awatarami.

Ad 8. Chodzi o galerię gotowych awatarów jak w IPB lub PhpBB. Wybór zostawiam na później, chociaż większość wgrywa własne obrazy. Chociaż może być tak, że użytkownicy wybierają z galerii awatar związany np. z ich zainteresowaniami i nie mogą wgrać własnego dla bezpieczeństwa lub z innych powodów. Wracając do implementacji - może nie ma sensu tworzyć osobnej podstrony, aby wybrać zdjęcie z galerii, prawda?

Dodam jeszcze pytanie:

9. Lista zarejestrowanych osób on-line + boty

A. Wyświetlać zawsze
B. Wyświetlać, jeśli włączymy opcję w panelu admina
C. Nie wyświetlać

[Petermechanic]

9. B, chociaż ja mam na stałe zrobioną listę użytkowników

[WebCM]

10. Czy przejść na kodowanie UTF-8?
Aktualnie zawartość jest kodowana ISO-8859-2. Przejście na UTF-8 umożliwi wstawianie znaków specjalnych bez encji (np. ®) i rozwiąże problem z przesyłaniem danych na serwer za pomocą AJAX, lecz znaki alfabetów niełacińskich i diakrytyczne (ą, ś, ć...) zajmują po 2 bajty.
ISO-8859-2
UTF-8

11. Czy rozszerzenia powinny trzymać swoje pliki tylko w swoim folderze?
A. TAK - czyli pliki językowe, szablony, itd. znajdują się w katalogu rozszerzenia, np. plugins/guestbook
B. NIE - czyli szablony mogą znajdować się np. w katalogu style/guestbook, style/admin, pliki językowe w lang...

Znów powrócił problem ścieżek do szablonów. Aktualnie definiuję ścieżkę systemową jako stałą SKIN_DIR oraz ścieżkę opcjonalną $content->dir. Jeżeli pliku szablonu, który trzeba dołączyć, nie ma w $content->dir, wtedy system szuka go w SKIN_DIR. Panel admina ustawia własną (style/admin), więc wyświetlenie szablonów rozszerzeń w PA jest niemożliwe.

Powiedzmy, że rozszerzenie w panelu admina ustawia $content->dir na plugins/guestbook/. System szuka tam pliku guestbookAdmin.html i go znajduje. Potem trzeba wyświetlić szablon panelu admina - szuka w plugins/guestbook - nie ma. Szuka więc w katalogu domyślnym - SKIN_DIR - nie ma. Nie wiem, czy dalej kombinować w klasie Content i stworzyć możliwość ustawiania nieskończonej ilości możliwych katalogów, czy dodać kolejny warunek, aby szukał w katalogu "admin"... Czy po prostu porozrzucać pliki rozszerzenia do różnych katalogów - wtedy problemu nie będzie.

[Petermechanic]

10. tak, jeżeli chcesz skrypt rozpowszechnić, to dobrze by było, żeby można było pisać po chińsku i cyrlicą

[pim]

10. Tak, czas przejść.
11. A. Joomla wykorzystuje wariant B i przez to jakiekolwiek zmiany w kodzie są praktycznie nie do przejścia.

[WebCM]

Przeszedłem na UTF-8. Problem 11 postaram się rozwiązać - większość jest za A.

12. Skórka panelu admina
Aktualnie wszystkie szablony panelu admina trzymam w osobnym katalogu - style/admin, w tym główny szablon admin.html. Jest on uzależniony od wybranej w ustawieniach skórki, np. default (style/default). Korzysta z klas zdefiniowanych w style/nazwa_skorki/X.css. Jeżeli zmienimy skórkę na taką, która ma całkowicie inną budowę, układ graficzny i używa innych klas CSS, pojawia się problem - układ graficzny w panelu admina może rozsypać się.

A. Przenieś pliki admin.html i admin.css do katalogu głównej skórki - style/nazwa_skorki. Style będą mogły zmienić układ graficzny panelu administracyjnego, ikonki w menu i być może inne elementy. Od razu rozwiąże się problem 11, bo w przypadku wyświetlania modułów administracyjnych rozszerzeń nie będą wykorzystywane szablony z katalogu style/admin - nie trzeba definiować wielu ścieżek.

B. Nic nie zmieniaj.

C. Oddziel całkowicie skórkę panelu admina od wybranej skórki głównej. To oznacza, że trzeba zdefiniować osobne style CSS.

W przypadku B i C wciąż pozostaje do rozwiązania problem 11.

13. Graficzne menu

A. Pozwól ustawić ikonki lub klasy dla pozycji menu nawigacyjnego.
B. Niech webmasterzy tworzą niezależne menu od standardowego - będą mieć ikony, jeśli chcą.
C. Zostaw na razie menu tekstowe, a potem stwórz rozszerzenie do tworzenia menu graficznego
D. Zostaw menu tekstowe. Zbyt wiele grafiki obciąża serwer (trzeba pobrać wiele plików).

Użytkownicy domagają się menu graficznego - choć tak w ogóle są gdziekolwiek stosowane osobne ikony dla każdego linku? Zapytam więc Was, jak to widzicie.