Funkcjonalność części redakcyjnej systemów typu CMS budzi od zawsze
dylematy: czy udostępniać edytor treści WYSIWYG, czy nie. Padają
argumenty, że za pomocą takiego edytora psujemy kod HTML (zarówno
czystość, jak i semantyka a także rośnie ryzyku "uszkodzenia" layoutu
strony przez redaktora). Z drugiej strony jeśli nie udostępnimy takiego
narzędzia, to klient narzeka, że w darmowych narzędziach takie
rozwiązania są w płatnych nie. Czy jest gdzieś złoty środek?

do góry

On Wed, 08 Dec 2010 12:05:08 +0100, Marek wrote:

> Funkcjonalność części redakcyjnej systemów typu CMS budzi od zawsze
> dylematy: czy udostępniać edytor treści WYSIWYG, czy nie. Padają
> argumenty, że za pomocą takiego edytora psujemy kod HTML (zarówno
> czystość, jak i semantyka a także rośnie ryzyku "uszkodzenia" layoutu
> strony przez redaktora). Z drugiej strony jeśli nie udostępnimy takiego
> narzędzia, to klient narzeka, że w darmowych narzędziach takie
> rozwiązania są w płatnych nie. Czy jest gdzieś złoty środek?

Wyłączyć w WYSIWYGU wszystko poza podstwowymi elementami i, przede
wszystkim, szkolić, szkolić, pracować z klientem. Zaglądać co pewien czas
na jego stronę, patrzyć czy czegoś nie psuje.


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-12-08 12:12, Michał Gancarski pisze:
> Wyłączyć w WYSIWYGU wszystko poza podstwowymi elementami i, przede
> wszystkim, szkolić, szkolić, pracować z klientem. Zaglądać co pewien czas
> na jego stronę, patrzyć czy czegoś nie psuje.

Jak znam życie, to niewielu klientów będzie chciało być kontrolowanymi
jeśli będą musieli za to płacić... Można to jednak uznać za opcję w
rozliczeniach.

Bardziej istotnym zagadnieniem jest to co jest "podstawowym elementem".
Bold i italic? Coś jeszcze? Jeśli tak, to sprawa się komplikuje.
Wyobraźmy sobie, że klient będzie chciał coś pokolorować na czerwono lub
zielono (bo innych kolorów w danym projekcie nie wolno mu stosować aby
nie zepsuć layoutu). W CSS będziemy mieli klasy "red" i "green". Skąd
taki edytor "ma wiedzieć", że należy zastosować:

<span class="red">tu tekst wklepany</span>

Należy brać pod uwagę, że w innych projektach będą inne kolory dostępne
i inne klasy. Wtedy taki edytor musiałby być konfigurowalny dla każdego
projektu indywidualnie.

Przykład kolorów jest najbardziej trywialny. Sprawa jeszcze bardziej
komplikuje się gdy dojdą np. listy punktowe. Jeśli zdefiniujemy sobie
parę jej wariantów w danym projekcie to i w tym względzie trzeba nauczyć
taki edytor jak budować taką listę. Jakie klasy można do <ul> przypisać
i jakie do <li> i to zależnie od projektu.

Więc jak to jest z tymi "podstawowymi elementami"?

do góry

On Wed, 08 Dec 2010 17:56:37 +0100, Marek wrote:

> W dniu 2010-12-08 12:12, Michał Gancarski pisze:
>> Wyłączyć w WYSIWYGU wszystko poza podstwowymi elementami i, przede
>> wszystkim, szkolić, szkolić, pracować z klientem. Zaglądać co pewien czas
>> na jego stronę, patrzyć czy czegoś nie psuje.
>
> Jak znam życie, to niewielu klientów będzie chciało być kontrolowanymi
> jeśli będą musieli za to płacić... Można to jednak uznać za opcję w
> rozliczeniach.

Niech sobie zepsuje to wróci. A jeśli nie przeszkadza mu pstrokacizna to
niewiele da się chyba zrobić. Na początku wyjaśniasz, że strona to nie jest
Word i dlaczego, a potem jeśli się klient uprze, to niech psuje. To
przecież jego sprawa i jego strona. Do portfolio wrzucasz screenshoty
sprzed zepsucia, najlepiej ze startu strony i jest OK.


> Bardziej istotnym zagadnieniem jest to co jest "podstawowym elementem".
> Bold i italic? Coś jeszcze? Jeśli tak, to sprawa się komplikuje.
> Wyobraźmy sobie, że klient będzie chciał coś pokolorować na czerwono lub
> zielono (bo innych kolorów w danym projekcie nie wolno mu stosować aby
> nie zepsuć layoutu). W CSS będziemy mieli klasy "red" i "green". Skąd
> taki edytor "ma wiedzieć", że należy zastosować:

Szczerze mówiąc to nie rozumiem czemu redaktor miałby w ogóle mieć taką
możliwość jak "kolorowanie". Redaktor tworzy strutkturę, a wygląd elementów
jest już zdefiniowany. I nie "bold" tylko "podkreślenie", załatwiane
STRONGiem albo EMem.


> <span class="red">tu tekst wklepany</span>
>
> Należy brać pod uwagę, że w innych projektach będą inne kolory dostępne
> i inne klasy. Wtedy taki edytor musiałby być konfigurowalny dla każdego
> projektu indywidualnie.

Kolory w ogóle nie są dostępne. Style są zdefiniowane dla elementów. Strona
jest jak element stylebooka i klient albo to rozumie albo nie. Można mu
pomóc zrozumieć ale jeśli się upiera, to niech psuje. Po prostu będzie miał
brzydszą stronę. Jeśli to klient, który nie chce zapłacić komuś za dbanie o
stronę, to nie ma problemu - i tak na nim już nie zarobisz, rozstajecie
się.


> Przykład kolorów jest najbardziej trywialny. Sprawa jeszcze bardziej
> komplikuje się gdy dojdą np. listy punktowe. Jeśli zdefiniujemy sobie
> parę jej wariantów w danym projekcie to i w tym względzie trzeba nauczyć
> taki edytor jak budować taką listę. Jakie klasy można do <ul> przypisać
> i jakie do <li> i to zależnie od projektu.
>
> Więc jak to jest z tymi "podstawowymi elementami"?

Listy, dwa poziomy nagłówków, em, strong, link, cytat.


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

On 2010-12-08 18:06, Michał Gancarski wrote:
> Szczerze mówiąc to nie rozumiem czemu redaktor miałby w ogóle mieć taką
> możliwość jak "kolorowanie". Redaktor tworzy strutkturę, a wygląd elementów
> jest już zdefiniowany. I nie "bold" tylko "podkreślenie", załatwiane
> STRONGiem albo EMem.

Ja Ci k^%$a dam podkreślenie, wyróżnienie jak już ;)
Podkreślone mają prawo być tylko linki.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

On Wed, 08 Dec 2010 18:35:44 +0100, Paweł Piskorz wrote:

> On 2010-12-08 18:06, Michał Gancarski wrote:
>> Szczerze mówiąc to nie rozumiem czemu redaktor miałby w ogóle mieć taką
>> możliwość jak "kolorowanie". Redaktor tworzy strutkturę, a wygląd elementów
>> jest już zdefiniowany. I nie "bold" tylko "podkreślenie", załatwiane
>> STRONGiem albo EMem.
>
> Ja Ci k^%$a dam podkreślenie, wyróżnienie jak już ;)
> Podkreślone mają prawo być tylko linki.

Przepraszam, szukałem słowa, które nie zawiera wskazówek co do wyglądu i
nie znalazłem :-)


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-12-08 18:06, Michał Gancarski pisze:
> Niech sobie zepsuje to wróci. A jeśli nie przeszkadza mu pstrokacizna to
> niewiele da się chyba zrobić. Na początku wyjaśniasz, że strona to nie jest
> Word i dlaczego, a potem jeśli się klient uprze, to niech psuje. To
> przecież jego sprawa i jego strona. Do portfolio wrzucasz screenshoty
> sprzed zepsucia, najlepiej ze startu strony i jest OK.

Sam sobie bicz kręcę w ten sposób. Klient coś zepsuje a ja będę
diagnozował gratis. Jeśli wspomnę o kasie za każde grzebanie, to
przypuszczam, że drugiego zlecenia od niego nie dostanę...

> Szczerze mówiąc to nie rozumiem czemu redaktor miałby w ogóle mieć taką
> możliwość jak "kolorowanie".

Dlatego właśnie spytałem co znaczy "podstawowe elementy" Twoim zdaniem
(odpowiedź znalazłem na końcu). Kolorowanie teoretycznie mogłoby za taki
podstawowy element uchodzić i w związku z tym pokazałem jakie to
problemy stwarza.

Tak na marginesie: skoro już o tych kolorowankach mówimy, to średnio w
50% przypadków klienci chcą coś kolorować prędzej czy później. Szczerze
mówiąc sam zacząłem mieć wątpliwości czy nie dać takiego narzędzia.
Wiesz... jest parcie ze strony ludu a ja podobnie jak Nokia w swoich
telefonach: niby daję coś ale na pół gwizdka w ich mniemaniu. Trudno mi
argumentować, że tak jest lepiej. Dla nich to brak funkcjonalności.

> Redaktor tworzy strutkturę, a wygląd elementów
> jest już zdefiniowany. I nie "bold" tylko "podkreślenie", załatwiane
> STRONGiem albo EMem.

Tylko tego brakowało! Czy sądzisz, że klienci wiedzą czym strong od
bolda się różni? :-D Boldem niewiele zepsuje, strongiem może znacznie
więcej. Mimo iż on to zepsuje to gromy mogą na mnie polecieć.

> Kolory w ogóle nie są dostępne. Style są zdefiniowane dla elementów. Strona
> jest jak element stylebooka i klient albo to rozumie albo nie. Można mu
> pomóc zrozumieć ale jeśli się upiera, to niech psuje. Po prostu będzie miał
> brzydszą stronę. Jeśli to klient, który nie chce zapłacić komuś za dbanie o
> stronę, to nie ma problemu - i tak na nim już nie zarobisz, rozstajecie
> się.

Może masz rację, że więcej asertywności powinienem wykazywać...

> Listy, dwa poziomy nagłówków, em, strong, link, cytat.

A jak załatwiasz kwestię - nazwijmy umownie - cenników? Opis pozycji w
lewej kolumnie wyrównany do lewej (albo prawej) potem cena w prawej
kolumnie wyrównana do prawej. Bardzo często widuje się taką potrzebę. W
HTMLu tabele od tego są. W edytorze to niezła funkcjonalność musiałaby
być zaimplementowana aby zrealizować zarządzanie takimi strukturami
(formatowanie komórek, może pakowanie stylów inline'owych w nie - horror).

do góry

On Wed, 08 Dec 2010 21:08:06 +0100, Marek wrote:

> W dniu 2010-12-08 18:06, Michał Gancarski pisze:
>> Niech sobie zepsuje to wróci. A jeśli nie przeszkadza mu pstrokacizna to
>> niewiele da się chyba zrobić. Na początku wyjaśniasz, że strona to nie jest
>> Word i dlaczego, a potem jeśli się klient uprze, to niech psuje. To
>> przecież jego sprawa i jego strona. Do portfolio wrzucasz screenshoty
>> sprzed zepsucia, najlepiej ze startu strony i jest OK.
>
> Sam sobie bicz kręcę w ten sposób. Klient coś zepsuje a ja będę
> diagnozował gratis. Jeśli wspomnę o kasie za każde grzebanie, to
> przypuszczam, że drugiego zlecenia od niego nie dostanę...

Hm, to IMHO warto postawić w sposób jasny jeszcze na poziomie rozmów
wstępnych - że kwestie, które nie są związane z naprawą Twoich błędów
załatwiasz wedle stawek godzinowych (na przykład). Wady produktu załatwiasz
darmowo.

Potem w trakcie przypominasz tylko klientowi, że im więcej dostanie
możliwości schrzanienia strony, tym większe ryzyko, że coś odpłatnie
naprawisz :-) Masz inne projekty, masz inne rzeczy na głowę, nie jesteś
gościem na telefon. Przynajmniej nie za darmo. Chyba, że bardzo klienta
lubisz, co się przecież zdarza :-) Niemniej ktoś kto ma własną firmę z
pewnością rozumie wartość swojego czasu. Powinien więc zrozumieć wartość
czasu innych. Wiem, że tak nie jest zawsze ale warto postawić jasne
warunki.


>> Szczerze mówiąc to nie rozumiem czemu redaktor miałby w ogóle mieć taką
>> możliwość jak "kolorowanie".
>
> Dlatego właśnie spytałem co znaczy "podstawowe elementy" Twoim zdaniem
> (odpowiedź znalazłem na końcu). Kolorowanie teoretycznie mogłoby za taki
> podstawowy element uchodzić i w związku z tym pokazałem jakie to
> problemy stwarza.
>
> Tak na marginesie: skoro już o tych kolorowankach mówimy, to średnio w
> 50% przypadków klienci chcą coś kolorować prędzej czy później. Szczerze
> mówiąc sam zacząłem mieć wątpliwości czy nie dać takiego narzędzia.
> Wiesz... jest parcie ze strony ludu a ja podobnie jak Nokia w swoich
> telefonach: niby daję coś ale na pół gwizdka w ich mniemaniu. Trudno mi
> argumentować, że tak jest lepiej. Dla nich to brak funkcjonalności.

Jeśli klient chce zapłacić za możliwość psucia sobie strony, to proszę
bardzo. Twoim zadaniem jako wykonawcy jest albo stawić opór i wyjaśnić
dlaczego nie jest to właściwe albo po prostu wykonać. To zależy w jakiej
pozycji się stawiasz - zwykłego wykonawcy czy doradcy.


>> Redaktor tworzy strutkturę, a wygląd elementów
>> jest już zdefiniowany. I nie "bold" tylko "podkreślenie", załatwiane
>> STRONGiem albo EMem.
>
> Tylko tego brakowało! Czy sądzisz, że klienci wiedzą czym strong od
> bolda się różni? :-D Boldem niewiele zepsuje, strongiem może znacznie
> więcej. Mimo iż on to zepsuje to gromy mogą na mnie polecieć.

Co może zepsuć "strongiem"? Na poziomie edytora klient nie musi widzieć co
powstaje pod spodem. Ma ikonkę "B" ale w kodzie pojawia się STRONG.
Szkolenie jest ważne, tak samo jak wyjaśnienie od czego są wszystkie te
elementy. Dopóki redaktor nie przestawi się z myślenia wordowego, dopóty
będą problemy. Popatrz na Onet czy choćby New Yotk Timesa. Odnoszę
wrażenie, że tam wrzucacze są albo dobrze przeszkoleni albo nie mają
możliwości psucia. W artykułach nie ma nic ponad linki, wyróżnienie i jeden
poziom nagłówka.


>> Kolory w ogóle nie są dostępne. Style są zdefiniowane dla elementów. Strona
>> jest jak element stylebooka i klient albo to rozumie albo nie. Można mu
>> pomóc zrozumieć ale jeśli się upiera, to niech psuje. Po prostu będzie miał
>> brzydszą stronę. Jeśli to klient, który nie chce zapłacić komuś za dbanie o
>> stronę, to nie ma problemu - i tak na nim już nie zarobisz, rozstajecie
>> się.
>
> Może masz rację, że więcej asertywności powinienem wykazywać...

Oczywiście bez bucówy :-) Ja jedynie wyjaśniam ryzyko. Czasem wychodzi,
czasem nie. Podejrzewam, że wraz z doświadczeniem będzie mi łatwiej
przekonywać.


>> Listy, dwa poziomy nagłówków, em, strong, link, cytat.
>
> A jak załatwiasz kwestię - nazwijmy umownie - cenników? Opis pozycji w
> lewej kolumnie wyrównany do lewej (albo prawej) potem cena w prawej
> kolumnie wyrównana do prawej. Bardzo często widuje się taką potrzebę. W
> HTMLu tabele od tego są. W edytorze to niezła funkcjonalność musiałaby
> być zaimplementowana aby zrealizować zarządzanie takimi strukturami
> (formatowanie komórek, może pakowanie stylów inline'owych w nie - horror).

To zależy od sytuacji. Do prostych tabel można stworzyć style. Natomiast
jeśli to jest cennik np. ze sklepu internetowego to generowałbym go pewnie
z bazy. Jak? Nie wiem, musiałbym mieć pod ręką konkretny projekt, znać
narzędzia i wiedzieć, że potrafię ich użyć.


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2010-12-08 17:56, Marek pisze:
> Bardziej istotnym zagadnieniem jest to co jest "podstawowym elementem".
> Bold i italic? Coś jeszcze? Jeśli tak, to sprawa się komplikuje.

Tabelki?

artur

do góry

W dniu 2010-12-08 21:47, Michał Gancarski pisze:
>>> Redaktor tworzy strutkturę, a wygląd elementów
>>> jest już zdefiniowany. I nie "bold" tylko "podkreślenie", załatwiane
>>> STRONGiem albo EMem.
>>
>> Tylko tego brakowało! Czy sądzisz, że klienci wiedzą czym strong od
>> bolda się różni? :-D Boldem niewiele zepsuje, strongiem może znacznie
>> więcej. Mimo iż on to zepsuje to gromy mogą na mnie polecieć.
>
> Co może zepsuć "strongiem"?

Pozycjonowanie.

> Na poziomie edytora klient nie musi widzieć co
> powstaje pod spodem. Ma ikonkę "B" ale w kodzie pojawia się STRONG.

To chyba bardzo zły pomysł. W kodzie powinno być <b>. <strong> ma inne
znaczenie semantyczne niż <b>. No i tu rodzi się dylemat - czy dawać
drugi sposób boldowania? Klient tego nie zrozumie lub zrozumie a potem
zapomni. Np. biorę kasę za pozycjonowanie a klient redagując treść w
sposób nieodpowiedni psując mi całą robotę. Dlatego tak prosta czynność
jak boldowanie może też powodować straty dla mnie. Również i stąd moje
dylematy co do udostępniania edytora.

> Szkolenie jest ważne, tak samo jak wyjaśnienie od czego są wszystkie te
> elementy. Dopóki redaktor nie przestawi się z myślenia wordowego, dopóty
> będą problemy. Popatrz na Onet czy choćby New Yotk Timesa. Odnoszę
> wrażenie, że tam wrzucacze są albo dobrze przeszkoleni albo nie mają
> możliwości psucia. W artykułach nie ma nic ponad linki, wyróżnienie i jeden
> poziom nagłówka.

Chyba właśnie tam ktoś przemyślał od w/w strony temat.

> To zależy od sytuacji. Do prostych tabel można stworzyć style. Natomiast
> jeśli to jest cennik np. ze sklepu internetowego to generowałbym go pewnie
> z bazy. Jak? Nie wiem, musiałbym mieć pod ręką konkretny projekt, znać
> narzędzia i wiedzieć, że potrafię ich użyć.

Edytor to nie jest konkretny projekt tylko narzędzie uniwersalne. Jeśli
tabela miałaby być z bazy ciągnięta, to jak ją redaktor wstawi w treść
(lub w kilka miejsc w treści)? Jakimś znacznikiem specjalnym? Jeśli
zaczniesz ich używać, to rośnie stopień złożoności takiego edytora bo
wtedy nie tylko znaczniki HTML musi analizować. Z kolei nie wyobrażam
sobie aby redaktor z palca wklepywał kod tabeli.

Nie trzymaj się wyrażenia "cennik" jako faktycznie cennika. To mogą być
takie elementy jak tu:

http://www8.hp.com/pl/pl/contact-hp/phone-assist.htm
l

do góry