W jaki sposób edytor kodu może skutecznie sugerować na poziomie zagnieżdżania kodu - bez użycia wcięć? [Zamknięte]

Napisałem edytor tekstowy XML, który oferuje 2 opcje widoku dla tego samego tekstu XML, jeden wcięty (praktycznie), drugi wyrównany do lewej. Motywacja dla widoku z wyrównaniem do lewej strony ma pomóc użytkownikom „zobaczyć” znaki białych znaków, których używają do wcięcia tekstu jawnego lub kodu XPath bez ingerencji w wcięcie, które jest automatycznym efektem ubocznym kontekstu XML.

Chcę podać wskazówki wizualne (w nieedytowalnej części edytora) dla trybu wyrównanego do lewej, który pomoże użytkownikowi, ale nie będzie zbyt skomplikowany.

Próbowałem po prostu użyć linii łączących, ale wydawało mi się to zbyt zajęte. Najlepsze, jakie do tej pory wymyśliłem, jest pokazane na fałszywym zrzucie ekranu edytora poniżej, ale szukam lepszych / prostszych alternatyw (które nie wymagają zbyt dużego kodu).

[Edytować]

Biorąc pomysł Heatmap (z: @jimp) otrzymuję to i 3 alternatywy - oznaczone jako a, b i c:

W poniższej sekcji opisano zaakceptowaną odpowiedź jako propozycję, łącząc pomysły z wielu innych odpowiedzi i komentarzy. Ponieważ to pytanie jest teraz wiki społeczności, prosimy o aktualizację.

NestView

Nazwa tego pomysłu, który zapewnia wizualną metodę poprawy czytelności zagnieżdżonego kodu bez użycia wcięć.

Linie konturowe

Nazwa różnie zacienionych linii w NestView

Powyższy obraz pokazuje NestView używany do wizualizacji fragmentu kodu XML. Chociaż do tej ilustracji użyto XML, w tej ilustracji można by zastosować inną składnię kodu, która wykorzystuje zagnieżdżanie.

Przegląd:

1. Linie konturu są zacienione (jak w mapie termicznej), aby przenieść poziom zagnieżdżenia

2. Linie konturu są ustawione pod kątem, aby pokazać, kiedy poziom zagnieżdżenia jest otwierany lub zamykany.

3. Linia konturu łączy początek poziomu zagnieżdżenia z odpowiednim końcem.

4. Połączona szerokość linii konturu daje wizualne wrażenie poziomu zagnieżdżenia, oprócz mapy cieplnej.

5. Szerokość NestView może być ręcznie zmieniana, ale nie powinna się zmieniać wraz ze zmianą kodu. Linie konturu można kompresować lub obcinać, aby zachować ten efekt.

6. Puste wiersze są czasem używane w kodzie do dzielenia tekstu na bardziej przyswajalne fragmenty. Takie linie mogą wyzwalać specjalne zachowanie w NestView. Na przykład mapa termiczna może zostać zresetowana, może zostać użyta linia konturu koloru tła lub jedno i drugie.

7. Można zaznaczyć jedną lub więcej linii konturu związanych z aktualnie wybranym kodem. Linia konturowa powiązana z wybranym poziomem kodu zostałaby najbardziej podkreślona, ​​ale inne linie konturowe mogłyby również „świecić” dodatkowo, aby pomóc podświetlić zawierającą zagnieżdżoną grupę

8. Różne zachowania (takie jak zwijanie kodu lub wybór kodu) mogą być powiązane z klikaniem / podwójnym klikaniem linii konturu.

9. Różne części linii konturu (krawędź wiodąca, środkowa lub końcowa) mogą mieć różne zachowania dynamiczne.

10. Podpowiedzi mogą być pokazywane podczas najechania kursorem myszy na linię konturu

11. NestView jest aktualizowany w sposób ciągły podczas edycji kodu. Tam, gdzie zagnieżdżanie nie jest dobrze wyważone, można przyjąć założenia, gdzie powinien się kończyć poziom zagnieżdżenia, ale powiązane tymczasowe linie konturu muszą być w jakiś sposób podświetlone jako ostrzeżenie.

12. Zachowanie przeciągania i upuszczania linii konturowych może być obsługiwane. Zachowanie może się różnić w zależności od części przeciąganej linii konturu.

13. Funkcje powszechnie spotykane na lewym marginesie, takie jak numeracja linii i wyróżnianie kolorów pod kątem błędów i stanu zmiany, mogą nakładać się na NestView.

Dodatkowa funkcjonalność

Wniosek dotyczy szeregu dodatkowych kwestii - wiele z nich nie wchodzi w zakres pierwotnego pytania, ale jest użytecznym efektem ubocznym.

Łączenie wizualne początku i końca zagnieżdżonego regionu

Linie konturowe łączą początek i koniec każdego zagnieżdżonego poziomu

Podświetlanie kontekstu aktualnie wybranej linii

Po wybraniu kodu można podświetlić powiązany poziom gniazda w NestView

Rozróżnianie regionów kodu na tym samym poziomie zagnieżdżenia

W przypadku XML można zastosować różne odcienie dla różnych przestrzeni nazw. Języki programowania (takie jak c #) obsługują nazwane regiony, których można użyć w podobny sposób.

Dzielenie obszarów w obszarze zagnieżdżenia na różne bloki wizualne

Dodatkowe wiersze są często wstawiane do kodu, aby poprawić czytelność. Takich pustych linii można użyć do zresetowania poziomu nasycenia linii konturowych NestView.

Widok kodu wielokolumnowego

Kod bez wcięcia sprawia, że ​​użycie widoku wielokolumnowego jest bardziej skuteczne, ponieważ zawijanie słów lub przewijanie w poziomie jest mniej prawdopodobne. W tym widoku, gdy kod osiągnie dolną część jednej kolumny, przechodzi do następnej:

Wykorzystanie wykraczające poza zwykłą pomoc wizualną

Jak zaproponowano w przeglądzie, NestView może zapewnić szereg funkcji edycji i wyboru, które byłyby zasadniczo zgodne z oczekiwaniami względem kontrolki TreeView. Kluczową różnicą jest to, że typowy węzeł TreeView ma 2 części: ekspander i ikonę węzła. Linia konturowa NestView może składać się z 3 części: otwieracza (nachylenie), łącznika (pion) i zamknięcia (nachylenie).

Wgłębienie

NestView prezentowany wraz z kodem bez wcięcia uzupełnia, ale raczej nie zastąpi konwencjonalnego widoku kodu z wcięciem.

Jest prawdopodobne, że wszelkie rozwiązania przyjmujące NestView zapewnią metodę płynnego przełączania między widokami kodu z wcięciem i bez wcięcia bez wpływu na sam tekst kodu - w tym na białe znaki. Jedną z technik dla wcięcia jest „Formatowanie wirtualne” - gdzie zamiast znaków tabulacji lub spacji stosuje się dynamiczny lewy margines. Te same dane na poziomie zagnieżdżenia użyte do dynamicznego renderowania NestView mogą być również wykorzystane do bardziej konwencjonalnego widoku wcięcia.

Druk

Wcięcie będzie ważne dla czytelności drukowanego kodu. W tym przypadku brak znaków tabulacji / spacji i dynamicznego lewego marginesu oznacza, że ​​tekst może się zawijać na prawym marginesie i nadal zachowywać integralność wcięcia. Numery linii mogą być używane jako wizualne znaczniki wskazujące miejsce, w którym kod jest zawijany, a także dokładne położenie wcięcia:

Nieruchomość ekranowa: wcięcie Flat Vs

Odpowiedź na pytanie, czy NestView wykorzystuje cenne nieruchomości ekranowe:

Linie konturu działają dobrze z szerokością taką samą, jak szerokość znaków edytora kodu. Dlatego NestView o szerokości 12 znaków może pomieścić 12 poziomów zagnieżdżenia, zanim linie konturu zostaną obcięte / skompresowane.

Jeśli wcięty widok używa 3 szerokości znaków dla każdego poziomu zagnieżdżenia, wówczas przestrzeń jest oszczędzana, aż zagnieżdżenie osiągnie 4 poziomy zagnieżdżenia, po tym poziomie zagnieżdżenia płaski widok ma zaletę oszczędzania miejsca, która wzrasta z każdym poziomem zagnieżdżenia.

Uwaga: W przypadku kodu często zalecane jest minimalne wcięcie o szerokości 4 znaków, jednak XML często radzi sobie z mniejszą liczbą znaków. Ponadto formatowanie wirtualne pozwala na stosowanie mniej wcięć, ponieważ nie ma ryzyka problemów z wyrównaniem

Porównanie 2 widoków pokazano poniżej:

W związku z powyższym należy prawdopodobnie stwierdzić, że wybór stylu widoku będzie oparty na czynnikach innych niż nieruchomości ekranowe. Jedynym wyjątkiem jest sytuacja, w której przestrzeń ekranu jest na wagę złota, na przykład na netbooku / tablecie lub gdy otwartych jest wiele okien kodu. W takich przypadkach NestView, którego rozmiar można zmienić, wydaje się wyraźnym zwycięzcą.

Przypadków użycia

Przykłady rzeczywistych przykładów, w których NestView może być przydatną opcją:

1. Gdzie nieruchomości ekranowe są na wagę złota

   za. Na urządzeniach takich jak tablety, notatniki i smartfony

   b. Podczas wyświetlania kodu na stronach internetowych

   do. Gdy wiele okien kodu musi być jednocześnie widocznych na pulpicie

2. Tam, gdzie spójne wcięcie białych znaków w kodzie jest priorytetem

3. Do przeglądania głęboko zagnieżdżonego kodu. Na przykład, gdy podjęzyki (np. Linq w C # lub XPath w XSLT) mogą powodować wysokie poziomy zagnieżdżania.

Dostępność

Należy zapewnić opcje zmiany rozmiaru i koloru, aby pomóc osobom z wadami wzroku, a także by dostosować się do warunków otoczenia i osobistych preferencji:

Kompatybilność edytowanego kodu z innymi systemami

Rozwiązanie zawierające opcję NestView powinno idealnie być w stanie usunąć wiodące znaki tabulacji i spacji (zidentyfikowane jako mające tylko rolę formatującą) z importowanego kodu. Następnie, po usunięciu kodu, można go bez problemu renderować zarówno w widokach wyrównanych do lewej, jak i wcięciach. Dla wielu użytkowników polegających na systemach takich jak narzędzia do łączenia i porównywania, które nie są świadome białych znaków, będzie to poważny problem (jeśli nie kompletny program zatrzymujący wyświetlanie).

Inne prace:

Wizualizacja nakładających się znaczników

Opublikowane badania Wendella Pieza , datowane na rok 2004, dotyczą problemu wizualizacji nakładających się znaczników, w szczególności LMNL . Obejmuje to grafikę SVG o znacznych podobieństwach do propozycji NestView, dlatego są one tutaj potwierdzane.

Różnice wizualne są wyraźne na obrazach (poniżej), kluczowe rozróżnienie funkcjonalne polega na tym, że NestView jest przeznaczony tylko dla dobrze zagnieżdżonego XML lub kodu, podczas gdy grafika Wendell Piez jest zaprojektowana tak, aby reprezentować nakładające się zagnieżdżenie.

Powyższe grafiki zostały odtworzone - za uprzejmym pozwoleniem - z http://www.piez.org

Źródła:

1. Ku Hermenutic Markup
2. Pół kroku w kierunku LMNL

Próbowałem tutaj odpowiedzieć na własne pytanie, ale zawiera on pomysł mapy cieplnej z @jimp, a także pomysł „zrób to bardziej XML” z @Andrea:

Mamy nadzieję, że kolory na mapie ciepła wraz z liniami kątowymi pomagają przyciągnąć uwagę między znacznikami początkowym i końcowym; usunięcie poziomych separatorów linii poprawia „przepływ” od początku do końca. Gdy użytkownik wybiera za pomocą elementu, pasującą część na mapie ciepła można w jakiś sposób wyróżnić - być może świecącą ramką (jak pokazano).

Edytuj Zdecydowałem się pójść z tym, prawdopodobnie będą musiały być opcje użytkownika dla kolorów. Zrzut ekranu „gotowy do produkcji”:

I dla porównania ... alternatywny widok wcięcia:

Edytuj teraz, dla bardziej zagnieżdżonego przypadku - testowanie moich umiejętności rysowania ...

Jednym z pomysłów może być próba dodania 3D do tekstu. Zwiększ / zmniejsz rozmiar czcionki w zależności od poziomu.

Na przykład ten kod:

Wyglądałby tak:

Praca z tym może być denerwująca, ponieważ traci ustalone wyrównanie rozmiaru tekstu na różnych poziomach. Inny pomysł; zmień nasycenie każdego poziomu:

Jak dobrze to wytrzymuje coś naprawdę głębokiego? Niepewny...

Bardzo podoba mi się twój pomysł wizualizacji rynny; łatwo jest grupować rzeczy razem. Może w połączeniu z jednym z tych pomysłów będzie wyglądał jeszcze lepiej lub znacznie bardziej crappier. ;)

Jakiś czas temu zrobiłem mapę termiczną pokazującą zakres w C. Może być fajnie patrzeć na burzę mózgów:

Wyrównany do lewej:

Po prostu popraw swój oryginalny pomysł i przełącz się z kwadratów na kapsułki. Myślę, że te wersje (w tym oryginalna) są łatwiejsze do odczytania, ponieważ są mniej złożone niż ta, która pokazuje zagnieżdżanie poprzez zagnieżdżanie elementów wyświetlanych. Myślę, że elementy drzewa przekazują informacje w prostszy i bardziej intuicyjny sposób.

Myślę, że lewica jest świetna do bezpośredniego pokazania wcięcia, podczas gdy prawica jest lepsza w przekazywaniu zagnieżdżonego związku.

Mój pomysł:

Zagnieżdżanie wygląda bardziej jak zagnieżdżanie. Pozioma szerokość każdej warstwy nie musi być tak szeroka.

Uwielbiam ten pomysł. Moją sugestią, aby utrzymać „zajęty” na dole, byłoby użycie gradientów zamiast kwadratów. Zmniejszy to linie. Być może różne kolory dla skrajnego wcięcia.

Powiedziałbym, że wszystko, co masz, jest świetne, choć trochę blokujące jak na mój gust.

Moje komentarze: Ciągle zmagam się ze sposobem, w jaki Visual Studio IDE robi wcięcia. Chciałbym użyć czegoś takiego lub tej odmiany.

Wyobraź sobie więc ten link bez linii i zgodny z bieżącym kodem xml /.

Ponieważ powiedziałeś, że wizualizacja musi istnieć na marginesie nieedytowalnym (po lewej?), Uważam, że oznacza to, że wizualizacji nie można przeplatać ani kryć za kodem.

Być może mapa ciepła w lewej kolumnie z jaśniejszymi kolorami wskazującymi głębsze wcięcia? Ustaw margines na stały rozmiar, z wizualizacją taką, jaką masz (spodziewaj się przejścia od lewej do prawej tak, jak zrobiłoby to wcięcie), która dynamicznie wykorzystuje całą podaną przestrzeń zgodnie z maksymalnym wcięciem określonym przez głębokość DOM.

Jeśli chciałbyś przejść do regionu edytora, sugerowałbym coś bardzo podobnego, ale jako tło dokumentu. Zacieniony obszar byłby tam, gdzie byłyby białe znaki , gdyby włączono wcięcia. W tym przypadku użyłbym jednolitego, jasnego koloru, który kontrastuje z podświetlaniem tekstu.

jGRASP robi to za pomocą markera wizualnego na marginesie:

Rozpoznaje nawet, kiedy używasz pętli i używa innego rodzaju linii do reprezentowania tej wewnętrznej pętli.

Pomyślałem, że zwrócę uwagę na to, jak robi to istniejący edytor.

Nie jest to zły pomysł, ale konieczność odniesienia się do lewego marginesu, aby wyraźnie zobaczyć, że moje bloki mogą być trochę denerwujące. To nawet nie myśli o nieruchomościach ekranowych ani o tym, jak mogą wyglądać rzeczy, gdy struktura się bardzo zagłębi.

Ponieważ motywacją jest pomóc użytkownikom „zobaczyć” białe znaki, których używają do wcięcia, możesz po prostu pokazać im białe znaki.

Nie mówię o specjalnych znakach wizualnych, takich jak znaczniki akapitów, tylko wyróżnienia. Spacje w kolorze żółtym, tabulatory w kolorze zielonym (lub cokolwiek innego)

W przypadku problemu z marginesem / zagnieżdżeniem można po prostu przesunąć margines dla każdego bloku. Nic nie mówi, że margines musi być linią prostą.

Jestem pewien, że to nie jest nowy pomysł.

Coś takiego:

Dlaczego nie otwierać i zamykać nawiasów?

1. Wcięcie oznacza ograniczenie: (i) oznacza dokładnie to dla programistów.
2. (i) są pojedynczymi znakami: lewy pasek pozostanie bardzo cienki.
3. Puste elementy można łatwo dostrzec: użyj () w tym samym wierszu.
4. Zawartość elementu nie wymaga wizualnej wskazówki: puste miejsce jest znacznie lepsze.
5. Pozycja kursora po prawej stronie może być dopasowana do bloku zawierającego po lewej stronie: dynamicznie dodaj kolor do znaków w kolumnie za pomocą (i)
6. Możesz uczynić go bardziej XML-owym, używając <i>, które wyglądają lepiej z dystansu.

Vim może już zrobić coś podobnego, choć nie tak ładnie.

Istnieją różne sposoby wykonywania „zwijania kodu” w Vimie. Jedna z nich oparta jest na regułach składania składni. Po wykonaniu tej czynności kod można złożyć za pomocą zagnieżdżonej struktury konspektu, a „FoldColumn” można wykorzystać do przedstawienia graficznej (w rzeczywistości „opartej na znakach” z „|” i „-” znakami) „foldlevel” .

Kolumna foldowa może przedstawiać reprezentację zagnieżdżania niezależnie od metody fold, ale metoda oparta na składni jest prawdopodobnie taka, która byłaby odpowiednia do tego, czego chcesz. Nie jestem pewien, czy istnieją gdzieś gotowe reguły składania oparte na składni dla xml, chyba tak.

Myślę, że jesteś na dobrej drodze z opcjami B i C: uwzględnij zarówno szerokość, jak i kolorystykę mapy cieplnej. W tej chwili podoba mi się opcja B bardziej niż C, ponieważ jest mniej ingerująca (albo szeroka i rozcieńczona, albo wąska i intensywna, a nie bardzo ciężki blok w środku C). Jedną wadą jest to, że z tą opcją musisz odbuduj cały wykres, jeśli gdzieś wstawisz poziom. Myślę, że możesz zmniejszyć bloki, prawdopodobnie wystarczy 1 lub 2 piksele. Nie musi to być wiele, wystarczy je odróżnić. Zwłaszcza, gdy ludzie mają wiele razy korzystać z edytora, dyskretne, bardziej subtelne efekty są łatwiejsze w obsłudze, ponieważ nie rozpraszają tak bardzo.

Jedną z rzeczy, która jest ważna podczas korzystania z edytora rodzajów, jest podkreślenie bieżącego zakresu: wybierając linię w edytorze, musisz dokładnie zobaczyć, jakie elementy zawiera i gdzie się kończy. Możesz nawet podświetlić drzewo (z jakich elementów jest ono potomkiem). Myślę, że to osobny problem, który wymaga rozwiązania i przemyślenia, i będzie miał większy wpływ na to, jak użytkownicy ocenią swoje wrażenia z pracy z edytorem.

Jednej rzeczy, o której nie wspomniałem, to to, co możesz zrobić z odcieniem oprócz efektu nasycenia, na którym się wydajesz. Moją sugestią jest zmiana koloru gniazda, w którym znajduje się wskaźnik. Ułatwi to użytkownikowi rozróżnienie, które linie są częścią gniazda, w porównaniu z rodzeństwem po drodze.

Wdrażając rzeczy oparte na odcieniach, należy pamiętać o ślepocie kolorów i albo wybrać kolory, które są powszechnie rozpoznawalne, albo zaoferować kilka opcji do wyboru.

Jedną z opcji, która mogłaby być użyta w połączeniu z innymi dotychczasowymi sugestiami, byłoby użycie podpowiedzi na lewym marginesie, która pokazuje ścieżkę do linii za pomocą notacji XPath. Narzędzia „sprawdzające element” przeglądarki (np. Firebug, ten wbudowany w Chrome) często robią coś podobnego, ale na pasku stanu.

Możliwe, że możesz mieć zwinięty widok mapy termicznej (z oryginalnego postu) z tylko jedną kolumną kolorów i liczbami głębokości. To pozwoliłoby im dowiedzieć się, jak głębokie są i dać im więcej nieruchomości na ekranie dla xml. Wydaje mi się, że wygrana wygrana.

Martwię się, czy różnice w kolorach będą wystarczające, aby głęboko zagnieżdżać rzeczy.