Jest szansa, że ten nowy edytor zostanie dodany do innych pól edycyjnych, przede wszystkim do komentarzy na mikroblogu oraz komentarzy na forum? Brakuje mi w tych miejscach formatowania i dodatkowych funkcji, jakie on oferuje.
2
0
Tak się zastanawiam, czy to ma sens. Może jednak komentarze nie powinny zachęcać do formatowania, a ogólniej – do skupiania się na nich? Zauważ, że usuwanie postów z komentarzami nie jest obwarowane tak samo, jak usuwanie wątków z postami. Podobnie ze wpisami na mikro.
1
furious programming napisał(a):
Jest szansa, że ten nowy edytor zostanie dodany do innych pól edycyjnych, przede wszystkim do komentarzy na mikroblogu oraz komentarzy na forum? Brakuje mi w tych miejscach formatowania i dodatkowych funkcji, jakie on oferuje.
Myślałem o tym już kiedyś, tylko mam parę rozkmin. Jak widać wielkie umysły myślą podobnie. Trzeba by tylko zebrać więcej głosów/opinii.
Po pierwsze, nie wiem dokładnie które feature`y są dostępne w komentarzach, trzeba by to jakoś przeanalizować, bo na pewno nie te same co w poście, np cytat i Nagłówek pewnie nie działa, ale i wiele innych.
Po drugie, zastanawiam się czy komentarze nie powinny czasem być jednolinijkowe, czy może zostawić tak jak teraz że mogą być wielo.
Po trzecie, trzeba by się zastanowić czy te same skróty powinny w nich działać.
1
W komentarzach działają tylko podstawowe znaczniki markdown. Nie ma łamania linii i wielu innych. IMHO edytor nie miałby tu zastosowania.
2
Nieważne czy podstawowe czy nie — liczy się spójność, użytkownik powinien nauczyć się pracy z jednym typem edytora i wykorzystywać umiejętności wszędzie. Tutaj chodzi o wygodę użytkowania (UX), która obecnie jest słaba, bo niejednorodna. Poza tym, edytor dostarcza zestawu funkcji, które mają zastosowanie nawet w jednoliniowych komentarzach do postów — mowa tutaj np. o skrótach klawiszowych do ustawiania pogrubienia, kursywy i przekreślenia tekstu, czy choćby wstawiania znaczników <kbd>, co jest bardzo przydatne.
A jeszcze poza tym, komentarze do wpisów na mikroblogu wspierają pełne formatowanie, łącznie z polami kodu, listami, obrazkami itd. i tam wręcz konieczne jest zastosowanie nowego edytora.
Skoro edytor jest stworzony, to powinno się go wykorzystywać wszędzie gdzie tylko jest opcja pisania z formatowaniem. Jedyne co należy zrobić to napisać jego kod tak, aby dało się wybrać zestaw obsługiwanych funkcji. Dzięki temu łatwo go będzie zastosować w różnych miejscach i wygodnie dobrać zakres funkcjonalności między różnymi instancjami.
IMO tutaj nie ma się nad czym zastanawiać.
1
Zgadzam się z @furious programming do pewnego stopnia. Powinniśmy zachować spójność tam gdzie toć ma sens.
Zgadzam się że dobrze byłoby dodać formatowanie w edytorze wszędzie tam gdzie jest wspierane w Coyote, + skróty klawiszowe.
Jednak nie dodawałbym kontrolek do komentarzy .
0
Nie pisałem o kontrolkach, a o samym edytorze. Mimo wszystko dodałbym te kontrolki, które dotyczą obsługiwanego w danym polu formatowania (ale bez rozwijalnego menu pomocy z formatowaniem). Bo czemu miałoby się dać z nich korzystać w poście, a w komentarzu nie? Jeśli ktoś ich potrzebuje, to potrzebuje ich wszędzie — spójność jest istotna.
0
furious programming napisał(a):
Nie pisałem o kontrolkach, a o samym edytorze. Mimo wszystko dodałbym te kontrolki, które dotyczą obsługiwanego w danym polu formatowania (ale bez rozwijalnego menu pomocy z formatowaniem). Bo czemu miałoby się dać z nich korzystać w poście, a w komentarzu nie? Jeśli ktoś ich potrzebuje, to potrzebuje ich wszędzie — spójność jest istotna.
Ale jak je dodałbyś? W postaci pop-up menu po złapaniu focusa przez pole edycji komentarza?
2
Silv napisał(a):
Ale jak je dodałbyś?
Jakoś tak:
W postaci pop-up menu po złapaniu focusa przez pole edycji komentarza?
Nie. Teraz wciska się przycisk Komentuj (lub ✎ do edycji komentarza) i pojawia się pole edycyjne z możliwością napisania komentarza. Jaki jest więc problem, aby pole edycyjne wyświetlało się wraz z belką zawierającą przyciski do formatowania, identyczną jak w przypadku postów?
Przyciski do nieużywanych w danym edytorze funkcji powinny nie być wyświetlane, tak samo jeśli zakładki do treści i podglądu (w przypadku polca edycyjnego do pisania jednoliniowego komentarza). Przyczym w module mikroblogów, do pisania komentarzy powinne być dostępne wszystkie funkcje, łącznie z podglądem.
0
furious programming napisał(a):
Teraz wciska się przycisk Komentuj (lub [przycisk z ikoną ołówka] do edycji komentarza) i pojawia się pole edycyjne z możliwością napisania komentarza. Jaki jest więc problem, aby pole edycyjne wyświetlało się wraz z belką zawierającą przyciski do formatowania, identyczną jak w przypadku postów?
Zauważ, że komentarz edytuje się "w miejscu". Co za tym idzie, takie menu musi być gdzieś w okolicach tego komentarza, musi pojawiać się po rozpoczęciu edycji i znikać po jej zakończeniu. Jak w przypadku pierwszego komentarza do postu miejsce zajmowane przez takie niewielkie menu nie ma większego znaczenia, tak wydaje mi się, że w przypadku kolejnych ma znaczenie. Stąd pojawił mi się w głowie pomysł pop-up menu, które byłoby "pływające" (floating) nad komentarzem wyżej czy niżej.
PS Oczywiście może ono pojawiać się wraz z polem edycji i cały czas być wyświetlone, a niekoniecznie wtedy, kiedy łapie ono focus. Nawet byłoby spójniej.
0
Tylko pamiętajmy ze komentarze na forum miały raczej być na małe podpowiedzi o właśnie komentowanie postu. Czy takie pokazanie kontrolek nie zachęci ludzi do dłuższych wypowiedzi tam, i pisanie komentarzy które powinny być postem?
@furious programming: tylko że "spójne" to nie znaczy "identycznie takie same".
Pomiędzy różnymi elementami mogą być różnice, a mogą nadal być spójne.
1
TomRiddle napisał(a):
Tylko pamiętajmy ze komentarze na forum miały raczej być na małe podpowiedzi o właśnie komentowanie postu.
Nie rozumiem, co ma piernik do wiatraka? Nieważne jest przeznaczenie komentarzy, ważne jest to, że od początku jest możliwość ich formatowania i użytkownicy z tego korzystają — najczęściej z linków, znaczników dla kodu inline oraz <kbd>, ale też z pogrubienia i kursywy. A skoro tak, to dajcie im przyciski do formatowania.
Czy takie pokazanie kontrolek nie zachęci ludzi do dłuższych wypowiedzi tam, i pisanie komentarzy które powinny być postem?
Serio myślisz, że ikonki cokolwiek zmienią? Do tej pory ich nie było, a mimo to mnóstwo użytkowników wolało pisać komentarze zamiast postów. Wg mnie powodem jest mylne przeświadczenie, że jeśli mają do napisania jedno czy dwa zdania, to że odpowiednim na to miejscem jest komentarz, a nie post. Tak jakby napisanie posta z jednym zdaniem było przestępstwem.
@furious programming: tylko że "spójne" to nie znaczy "identycznie takie same".
Pomiędzy różnymi elementami mogą być różnice, a mogą nadal być spójne.
Pisząc o zachowaniu spójności, miałem na myśli spójność funkcjonalności, nie wygląd elementów na ekranie. Pomiędzy różnymi edytorami muszą być różnice, ze względu na różne zakresy funkcjonalności — w poście można wszystko, we wpisie na blogu również, ale w komentarzu do posta niewiele, tak samo w komentarzach ofert pracy oraz do artykułów w kompendium. IMO to raczej oczywiste.
Przy czym do stworzenia belek z przyciskami w przypadku komentarzy, pasuje skorzystać z istniejących stylów, aby zachować spójność interfejsu i nie dokładać sobie roboty. Nic nie stoi na przeszkodzie, aby skorzystać z takich samych belek i takich samych przycisków — wystarczy jedynie usunąć te zbędne i zmienić kierunek wyrównania z prawego na lewy.
0
furious programming napisał(a):
TomRiddle napisał(a):
Tylko pamiętajmy ze komentarze na forum miały raczej być na małe podpowiedzi o właśnie komentowanie postu.
Nie rozumiem, co ma piernik do wiatraka? Nieważne jest przeznaczenie komentarzy, ważne jest to, że od początku jest możliwość ich formatowania i użytkownicy z tego korzystają — najczęściej z linków, znaczników dla kodu inline oraz
<kbd>, ale też z pogrubienia i kursywy. A skoro tak, to dajcie im przyciski do formatowania.
No ale ja jestem jaknajbardziej za dodaniem nowego edytora do komentarzy, z formatowaniem, dekoracjami, etc.
Tylko nie chciałbym UI'em dawać do zrozumienia userom że to jest dobre miejsce żeby się rozpisywać.
Czy takie pokazanie kontrolek nie zachęci ludzi do dłuższych wypowiedzi tam, i pisanie komentarzy które powinny być postem?
Serio myślisz, że ikonki cokolwiek zmienią? Do tej pory ich nie było, a mimo to mnóstwo użytkowników wolało pisać komentarze zamiast postów. Wg mnie powodem jest mylne przeświadczenie, że jeśli mają do napisania jedno czy dwa zdania, to że odpowiednim na to miejscem jest komentarz, a nie post. Tak jakby napisanie posta z jednym zdaniem było przestępstwem.
No, myślę że mogłyby pogorszyć sprawę.
0
Zaryzykuję twierdzenie, że równorzędnymi wartościami w dodaniu nowego edytora do komentarzy są spójność dla dewelopera oraz spójność dla użytkownika. Pamiętajmy, że źródła Coyote są publiczne – i że 4p może reklamować się zarówno interfejsem webowym, jak i tymi źródłami. Dzięki dodaniu niektórych funkcji nowego edytora do komentarzy, myślę, 4p będzie postrzegane jako bardziej spójne, a tym samym bardziej profesjonalne – zarówno przez deweloperów Coyote, jak i użytkowników strony 4programmers.net.
Także – jestem za dodaniem nowego edytora do komentarzy zarówno na forum, na mikroblogach, w ofertach pracy oraz w Kompendium. Natomiast nie dodawałbym kontrolek (ani żadnych innych nowych elementów interfejsu). Jeśli chodzi o funkcje dotyczące formatowania, dodałbym wszystkie odnoszące się do formatowania w jednej linii wraz ze skrótami klawiaturowymi.
0
@Silv: Ja bym problemy implementacyjne zostawił na drugorzędny tor.
Moim zdaniem opinia @furious programming jest warta uwagi i rozważenia; czy faktycznie kontrolki nad polem edycyjnym to dobry pomysł czy nie.
Implementację już zostaw mi ;)
0
TomRiddle napisał(a):
@Silv: Ja bym problemy implementacyjne zostawił na drugorzędny tor.
Implementację już zostaw mi ;)
Ależ OK, nie chcę wchodzić w Twoje buty. :) Miałem na myśli, że wprowadzenie edytora do komentarzy może być umotywowane zarówno tym, żeby było spójniej w interfejsie webowym, jak i tym, żeby było spójniej w źródłach. Każdy przecież może źródła przeglądać, a także dodawać PR-y.
0
Silv napisał(a):
Ależ OK, nie chcę wchodzić w Twoje buty. :) Miałem na myśli, że wprowadzenie edytora do komentarzy może być umotywowane zarówno tym, żeby było spójniej w interfejsie webowym, jak i tym, żeby było spójniej w źródłach. Każdy przecież może źródła przeglądać, a także dodawać PR-y.
Tak czy tak to będą dwie osobne API, także wiele się nie uspójni przez to w kodzie.
W komentarzach nie będzie podglądu, pomocy, uploadu obrazków, masy innych rzeczy. Probowanie tego uwspólnienia na siłe by tylko zrobiło szkody.
@furious programming: W ogóle wydaje mi się, że kolejnym powodem czemu ludzie piszą w komentarzach; to chęć pogadania na inny temat; off-topic; ale nie chcą odciągać głównego wątku od tego, więc toczą rozmowę w komentarzu.
1
TomRiddle napisał(a):
Tylko nie chciałbym UI'em dawać do zrozumienia userom że to jest dobre miejsce żeby się rozpisywać.
Przecież to się nazywa Komentarz, więc nie da się go pomylić z postem. Poza tym, sam fakt istnienia ograniczenia długości wpisu do 580 znaków oraz znikoma liczba przycisków do formatowania (w stosunku do edytora posta) jasno informuje, że komentarz nie służy do udzielania długich odpowiedzi.
0
furious programming napisał(a):
TomRiddle napisał(a):
Tylko nie chciałbym UI'em dawać do zrozumienia userom że to jest dobre miejsce żeby się rozpisywać.
Przecież to się nazywa
Komentarz, więc nie da się go pomylić z postem. Poza tym, sam fakt istnienia ograniczenia długości wpisu do 580 znaków oraz znikoma liczba przycisków do formatowania (w stosunku do edytora posta) jasno informuje, że komentarz nie służy do udzielania długich odpowiedzi.
No dla mnie i dla Ciebie tak.
Ale nie wiem czy dla innych również.
1
Ten placeholder jest mylący — powinien informować, że komentarze służą do off-topu. Zmiana na sensowniejszy powinna pomóc użytkownikom zrozumieć, że nie są one przeznaczone do głównej dyskusji (a teraz to właśnie sugeruje).
0
furious programming napisał(a):
Ten placeholder jest mylący — powinien informować, że komentarze służą do off-topu. Zmiana na sensowniejszy powinna pomóc użytkownikom zrozumieć, że nie są one przeznaczone do głównej dyskusji (a teraz to właśnie sugeruje).
Czy ja wiem czy służą? Chyba nie. Jak ktoś chce Off-Top to chyba powinien założyć nowy temat, nie?
Przydałoby się narzędzie do tego, coś w stylu: "Zamień wątek komentarzy na wątek", czy cóś.
2
Marooned napisał(a):
Pojawił się jakiś dziki kolor
.cm-editor .cm-line.cm-activeLine { background-color: hsla(0,0%,94.1%,.2); }
Naprawione ;)
0
@Silv: Wrzuciłem dzisiaj poprawkę, co do oznaczników kodu - tego co się pojawia jak wpiszesz ``` w autocomplete.
Powinno być teraz tak, że każdy jeden oznacznik teraz wybrany sprawia że kod jest kolorowany, wcześniej tak nie było.
Wcześniej było tak że był np tsx w autocomplete w edytorze, ale jak się go wybrało to Coyote i tak go nie kolorował. Teraz to powinno działać dla każdego jednego oznacznika, rónież .net, c++, c#, f# etc.
Jeśli chcesz nadal QA'ować, to to byłby dobre miejsce.
1
Melduję, że podpowiadanie już działa na iOS, dzięki za fixa ;) co to było? Faktycznie któryś z atrybutów?
0
Charles_Ray napisał(a):
Melduję, że podpowiadanie już działa na iOS, dzięki za fixa ;)
glad I could help.
co to było? Faktycznie któryś z atrybutów?
Tak
3
Ten nowy edytor próbuje być mądrzejszy niż user. Nie pozwala kliknąć na ikony formatowania, typu pogrubienie co powoduje, że mimo ikonek trzeba jednak pamiętać składnię i dodawać ją ręcznie, co wypacza sens ikon.
Oraz... dlaczego [3] jest pogrubione w edytorze? Hmm
1
Cześć! Dzięki za zgłoszenie.
Marooned napisał(a):
Oraz... dlaczego [3] jest pogrubione w edytorze? Hmm
Pozwól że odpowiem na to pytanie najpierw. Otóż zapis [3] to jest link.
W Markdown są dwa zapisy linków, jeden:
Napisz do [Marooned], dlatego że [Marooned] jest najlepszy i na pewno [Marooned] by wiedział co zrobić.
[Marooned]: /Forum/1837310
oraz zapis skrócony
Napisz do [Marooned](/Forum/1837310), dlatego że [Marooned](/Forum/1837310) jest najlepszy i na pewno [Marooned](/Forum/1837310) by wiedział co zrobić.
Ta [3] to jest ten pierwszy rodzaj linka, również nazywany "reference link". I dlatego jest pogrubione, bo jest linkiem, a linki są pogrubione.
Marooned napisał(a):
Ten nowy edytor próbuje być mądrzejszy niż user. Nie pozwala kliknąć na ikony formatowania, typu pogrubienie co powoduje, że mimo ikonek trzeba jednak pamiętać składnię i dodawać ją ręcznie, co wypacza sens ikon.
Faktycznie, pogrubienie powinno być tutaj możliwe, ale przez brak czasu to jeszcze nie jest zaimplementowane.
No właśnie ironicznie to edytor właśnie nie próbuje być mądrzejszy niż user. Nie każda akcja jest jeszcze zaimplementowana, jeśli akcja nie jest zaimplementowana to moglibyśmy zrobić dwie rzeczy:
- jasno pokazać userowi że edytor nie może czegoś zrobić (jeszcze - to jest to co się dzieje).
- pokazać userowi że może, a potem spróbować zrobić coś czego jeszcze nie umie - może się uda może nie (to jest to co robił stary edytor, po prostu otaczał zaznaczenie
**nie ważne co było zaznaczone).
Jedną z takich rzeczy jest pogrubianie tekstu w których znajduje się link (twoja [3]).
A odpowiadając na pytanie czemu edytor nie umie jeszcze pogrubiać tekstu z linkiem, otóż mogłoby się wydawać że takie zaznaczenie można ogarnąć:
To prawda, można. Ale edytor jeszcze nie umie sobie poradzić z takim zaznaczeniem
Więc to co edytor zrobił, to zrobił tak: "w zaznaczeniu jest paragraf oraz link", "nie umiem", "pokaże że nie umiem".
Tekst który pokazałeś składa się z trzech elementów: paragraf, tytuł linku, nawiasy kwadratowe [, sam link URL, oraz nawiasy okrągłe (. Zaznaczenie może zawierać się w dowolnej kombinacji tych elementów - jedne będzie się dało dobrze pogrubić (i wtedy edytor powinien pokazać że się da), innych nie - i wtedy edytor powinien pokazać że się nie da.
Na razie cała ta funkcjonalność nie jest ogarnięta, więc zapobiegawczo edytor pokazuje że się nie da. Dodamy ten feature, tak że będzie to działało tak jak mówisz (jednocześnie też dla pochylenia, przekreślenia i innych styli inline), ale jeszcze nie było na to czasu.
Nie próbuje tutaj zabierać komuś feature'ów - dodamy wszystkie jakie będą potrzebne; ale chce dodać cały feature na raz, a nie po kawałku.
2
1
Marooned napisał(a):
TomRiddle napisał(a):
Otóż zapis
[3]to jest link.otóż nie ;-)
W Markdownie to jest link. To czy faktycznie zostanie wyrenderowany jako link w HTML'u, to sprawa drugorzędna, pomijając to że Coyote to nie jest taki pure Markdown.
Markdown:
Render:
2
Czyli w edytorze nie działa pogrubienie bo nie wie jak otaczać linki których tam nie ma, bo edytor błędnie myśli że coś może być linkiem chociaż nie jest? Seems legit
A nie mogłoby po prostu otaczać tekst gwiazdkami i zostawić userowi czy się coś popsuje czy nie? To nie microsoft word tylko proste podpowiadanie składni