我已经编写了一个XML文本编辑器,该编辑器为相同的XML文本提供2个视图选项,一个缩进(虚拟),另一个向左对齐。左对齐视图的动机是帮助用户“看到”他们用于纯文本或XPath代码缩进的空白字符,而不会受到缩进的干扰,缩进是XML上下文的自动副作用。 >
我想为左对齐模式提供视觉线索(在编辑器的不可编辑部分),这将对用户有所帮助,但又不会太复杂。
我尝试过仅使用连接线,但这似乎太忙了。到目前为止,我所提出的最好的结果显示在下面的编辑器的模拟屏幕快照中,但是我正在寻找更好/更简单的替代方法(不需要太多的代码)。
[编辑]
以热图的想法(来自:@jimp)我得到了这3种选择-分别标记为a,b和c:
下一节将接受的答案作为建议进行描述,将来自其他许多答案和评论的想法汇集在一起。由于此问题现在是社区Wiki,请随时进行更新。
NestView
这个想法的名称提供了一种视觉方法来提高可读性。
等高线
NestView中不同阴影线的名称
/>上图显示了NestView,用于帮助可视化XML代码段。尽管此插图使用XML,但是使用嵌套的任何其他代码语法也可以用于此插图。
概述:
轮廓线是着色(如在热图中)以传达嵌套级别
等高线会倾斜以显示嵌套级别是打开还是关闭的时间。
等高线将嵌套级别的起点链接到相应的级别结束。
等高线的组合宽度除了提供热图外,还给人以嵌套层次的视觉印象。
NestView的宽度可以手动调整大小,但不应随代码的更改而改变。可以压缩或截断等高线以保持这种效果。
有时用空白行代码将文本分解为更易于消化的块。这些行可能会在NestView中触发特殊行为。例如,可以重设热图或使用背景色轮廓线,或同时使用两者。
可以突出显示与当前所选代码关联的一个或多个轮廓线。与所选代码级别关联的轮廓线将得到最大程度的强调,但是其他轮廓线也可以“点亮”,以帮助突出显示包含嵌套组的嵌套行为。不同的行为(例如代码折叠或代码选择)可以可以与单击/双击轮廓线相关联。
轮廓线的不同部分(前缘,中间或后缘)可能具有不同的动态行为。
可以在鼠标悬停时显示工具提示等高线发生事件
随着代码的编辑,NestView会不断更新。在嵌套不均衡的情况下,可以做出以下假设:嵌套层应该终止,但是必须以某种方式突出显示关联的临时轮廓线,以作为警告。
可以支持轮廓线的拖放行为。行为可能会随所拖动轮廓线的不同而有所不同。
在左边距中常见的功能(例如行号和错误突出显示的颜色和更改状态的颜色)可能会覆盖NestView。
附加功能
该提案解决了一系列附加问题-许多问题超出了原始问题的范围,但具有有益的副作用。
直观地将开始和结束联系起来嵌套区域的轮廓
等高线连接每个嵌套层的起点和终点
突出显示当前选定行的上下文
选择代码后,NestView中关联的嵌套级别可以突出显示
在代码区之间进行区分相同的嵌套级别
对于XML,可以将不同的颜色用于不同的命名空间。编程语言(例如c#)支持可以类似方式使用的命名区域。
将嵌套区域中的区域划分为不同的可视块
通常会插入多余的行代码以提高可读性。这样的空行可用于重置NestView轮廓线的饱和度级别。
多列代码视图
不带缩进的代码使用了多列视图效果更好,因为不太需要自动换行或水平滚动。在这种情况下,一旦代码到达一列的底部,它就会流入下一列:
用途不仅是提供视觉辅助
如概述中所建议,NestView可以提供一系列的编辑和选择功能,这些功能与TreeView控件的预期大致相符。关键区别在于,典型的TreeView节点分为两部分:扩展器和节点图标。 NestView等高线最多可以包含3个部分:打开器(倾斜),连接器(垂直)和闭合(倾斜)。
在压痕上
与非缩进代码一起显示的NestView是对传统缩进代码视图的补充,但不太可能取代。
任何采用NestView的解决方案都可能会提供一种在缩进和非缩进代码视图之间无缝切换而又不影响任何代码文本本身(包括空格字符)的方法。缩进视图的一种技术是“虚拟格式”-使用动态左边界代替制表符或空格字符。用于动态呈现NestView的相同嵌套级数据也可以用于外观更传统的缩进视图。
打印
缩进对于打印的可读性很重要码。在这里,没有制表符/空格字符和动态的左边距意味着文本可以以右边距换行,并且仍然保持缩进视图的完整性。行号可用作可视标记,指示代码在何处进行换行以及缩进的确切位置:
屏幕实状态:平面Vs缩进
解决NestView是否用完宝贵的屏幕房地产的问题:
轮廓线的宽度与代码编辑器的字符宽度相同,效果很好。因此,在截断/压缩轮廓线之前,NestView宽度为12个字符的宽度可以容纳12个嵌套级别。
如果缩进视图为每个嵌套级别使用3个字符宽度,则将保留空间,直到嵌套达到4个嵌套级别,在此嵌套级别之后,平面视图具有节省空间的优点,并且随着每个嵌套级别的增加而增加。
注意:对于代码,通常建议最小缩进4个字符宽度,但是XML通常管理较少。另外,虚拟格式允许使用较少的缩进,因为没有对齐问题的风险
下面两个视图的比较如下所示:
基于以上所述,很可能可以得出这样的结论:视图样式的选择将基于屏幕不动产以外的因素。一个例外是屏幕空间非常宝贵,例如在上网本/平板电脑上或打开多个代码窗口时。在这些情况下,可调整大小的NestView似乎是一个明显的赢家。
用例
NestView可能是有用选项的实际示例示例:
屏幕房地产十分珍贵
a。在平板电脑,记事本和智能手机等设备上
b。在网站上显示代码时
c。当需要在桌面上同时显示多个代码窗口时
优先考虑代码中文本的空白空格缩进
用于查看深层嵌套的代码。例如,在某些子语言(例如C#中的Linq或XSLT中的XPath)可能导致高度嵌套的情况下。
可访问性
必须提供调整大小和颜色选项以帮助那些具有视觉障碍,还适合环境条件和个人喜好:
编辑后的代码与其他系统的兼容性
理想情况下,NestView选项应该能够从导入的代码中删除前导制表符和空格字符(标识为仅具有格式化作用)。然后,一旦删除,就可以在左对齐和缩进视图中整齐地呈现代码,而无需更改。对于许多依赖诸如合并和差异工具之类的系统的用户来说,这不是空白的,这将是一个主要的问题(如果不是一个完整的显示停止器)。
其他作品:
重叠标记的可视化
Wendell Piez于2004年发表的研究报告着眼于重叠标记(特别是LMNL)的可视化问题。其中包括与NestView建议书非常相似的SVG图形,因此在此得到认可。
图像中的视觉差异十分明显(下图),主要的功能区别是NestView仅用于用于嵌套的XML或代码,而Wendell Piez的图形旨在表示重叠的嵌套。
/www.piez.org
资料来源:
走向诠释标记法
迈向LMNL的半步路
/>
#1 楼
我试图在这里回答我自己的问题,但这是结合了@jimp的热图思想和@Andrea的“使它更具有XML风格”的思想:希望,热图上的颜色以及角度线有助于在开始和结束标签之间吸引眼球;删除水平线分隔符可以从头到尾改善“流程”。当用户选择元素时,可以通过某种方式突出显示热图中的匹配部分-可能带有发光的边框(如图所示)。
编辑
已决定使用此元素,可能必须有颜色的用户选项。 “生产就绪”屏幕截图:
为了进行比较...另一种缩进视图:
立即编辑,以便处理更多嵌套的案例-测试我的绘图技能...
评论
看起来不错 !做得好。但是,当缩进更多时,它将如何显示?
–Loïc Lopes
2011-6-28 9:27
@Louhike谢谢!是的,它在4个级别上已达到最大值,并且我不想在左侧增加更多的余量-因此我将在较高的嵌套级别上逐渐压缩垂直条的宽度-希望有点像轮廓图。
–pgfearo
2011年6月28日13:50
@Louhike。我添加了一张额外的图像,以显示9级嵌套时的外观-在大约15级嵌套之后,可能有必要合并中间的条,也许使用渐变填充。
–pgfearo
2011年6月28日15:16
这简直太神奇了。 +1使代码编辑和用户界面更上一层楼。拥有帐户的人应将其发布到Hacker News,/。或r /编程。
–康拉德·鲁道夫(Konrad Rudolph)
2011年6月28日15:31
想知道侧边栏水平翻转时的样子... imgur.com/u5mNi
– chanux
2011年6月29日在3:30
#2 楼
一种想法可能是尝试在文本中添加3D。根据其级别增加/减小字体大小。例如,此代码:
看起来像这样:
使用它可能很烦人,因为它失去了跨不同级别的固定文本大小对齐方式。另一个想法;更改每个级别的饱和度:
对于真正深奥的东西,它的效果如何?不确定...
我实际上非常喜欢您的装订线可视化想法;将事物组合在一起很容易。也许结合这些想法之一,它看起来会更好,或更糟糕。 ;)
不久前,我做了一个热图,显示了C语言的作用域。脑力激荡可能会很有趣:
左对齐:
评论
它很想对文本做些事情,但这很难在不打扰开发人员输入文字或输入文字之后分散注意力的情况下进行。影响字体高度的更改会引起问题-可能我们可以容忍看到代码的上下浮动甚至更少。我喜欢您对代码进行着色的想法,但这必须微妙,因为我想尝试使事情看起来整洁。
–pgfearo
11年6月28日在20:18
但这对于教学环境将是非常好的!
– jcolebrand
2011年6月28日在20:31
字体大小的建议令人信服-尽管我可以看到它的缺点。为什么不将字体缩小,因为作用域是更深层的嵌套-这将有助于阻止深层嵌套(尽管在深层嵌套实际上是一个明智的解决方案时会引起问题)
–彼得
2011年6月28日23:17
实际上,热图在可视化范围上要比左对齐范围的可视化效果好得多(@pfgearo的解决方案)
–山迪普
2011-6-29 at 2:54
@Sandeep。我同意在许多情况下这是一个更好的解决方案-尤其是在检查代码而不是对其进行编辑时。技术上的限制(如希望在问题中解释的那样)使我很难用我正在使用的当前控件来修改背景颜色。实际上,我在此答案中使用了热图的左侧-但边缘朝着编辑区域倾斜以帮助吸引人的眼球。彩色文本背景的一个问题是,较高的位置会失去可读性/对比度嵌套级别。
–pgfearo
2011年6月29日在8:37
#3 楼
只需调整您的原始想法,然后从正方形切换为胶囊。我认为这些版本(包括您的原始版本)更易于阅读,因为它们比通过嵌套显示元素来显示嵌套的版本更简单。我认为树元素以更简单,更直观的方式传达信息。我认为左侧非常适合直接显示缩进,而右侧则更适合传达嵌套关系。
评论
我更喜欢您的胶囊的柔软性,但是它们似乎与文字太过分离,我需要一些更具凝聚力的东西,并且可以更清楚地了解其中包含的成分。
–pgfearo
2011年6月28日22:25
#4 楼
我的想法:嵌套看起来更像是嵌套。每层的水平宽度不必太宽。
评论
我认为您的建议与我给出的答案(受到其他人的启发)基本相同,但没有倾斜的线条。我认为倾斜的线条有助于更好地在打开和关闭之间吸引眼球。宽度不是真正的问题,因为(如9级图像所示)垂直线的宽度与倾斜线的宽度无关,因此可以压缩垂直线。
–pgfearo
11年6月28日在17:47
是的,pg-发布后我注意到了。它们在地形上是相同的-值得一看。我想这是一个品味问题,但是我的版本只是以您的版本没有的方式对我高喊。也许此功能可以兼顾两者并允许用户选择。
–broc7
2011年6月28日19:14
该答案与OP答案之间的视觉差异远远超过了该解决方案的独特性。而且,IMO,这种样式看起来更好,并且更清晰地传达嵌套效果。
– jdk1.0
4月11日11:26
#5 楼
我喜欢这个主意。我建议保持“忙碌”状态应该是使用渐变而不是正方形。它将减少线路。可能有不同的颜色用于极端压痕。
我想说的是您拥有的一切都很棒,尽管对我的口味来说有点块状。
我的评论:我一直在努力地努力解决Visual Studio IDE的工作方式缩进。我很乐意使用类似这样的东西或变体。
因此,请想象该链接没有任何行,并与您当前的xml /代码内联。
评论
是的,这些想法还在不断发展。我提交的答案(而不是我的问题)中的图像不那么块状,因为它们具有前导/尾随的斜率,我正在考虑使用渐变(但略有不同)也可以使事物变浅。我与您一起使用不同的颜色,以获得较高的缩进,同时也突出显示注释或错误之类的内容。然后是动态突出显示,用于显示当前上下文/调试...困难在于判断何时停止。
–pgfearo
2011-6-28 18:34
#6 楼
既然您说可视化必须存在于不可编辑的位置(左侧?),我相信这意味着该可视化不能与代码混合或隐藏在代码的后面。在左栏中也许有一个热图,颜色越亮表示压痕越深?将边距设置为固定大小,并使用类似于您的可视化效果(期望像缩进一样从左到右),根据DOM深度确定的最大缩进动态地使用给定的所有空间。
如果您愿意进入编辑器区域,我建议您提出一些非常相似的内容,但以文档为背景。如果启用了缩进,阴影区域将是空白。在这种情况下,我将使用与文本突出显示形成对比的纯色,浅色。
评论
@jimp是的,可视化不能出现在代码的后面或后面-尽管我很想尝试一下,但我的编码技能/平台会使它变得太复杂了。编辑器本身的背景色仍然很困难,但这使我有了可以尝试使用不同前景色色调的想法。我也会按照您的建议尝试从左到右的栏和热图。
–pgfearo
2011年6月25日21:29
对于热图想法(Y)+1。我可能建议嵌套层次在具有视觉特殊需要(例如色盲)的人的颜色内部。
– M.Sameer
2011年6月25日在21:51
@jimp。更新了我的问题以说明您喜欢的热图想法,但是我认为从左到右的事情是错误的...
–pgfearo
2011年6月25日22:49
@pgfearo我很高兴我的想法很有帮助!根据您看到的情况,我认为我更喜欢从右到左的L&F。很抱歉,我现在之前(繁忙的周末)没有机会再回来查看。由于您已经取得了很大的进步,所以我只对您在上面发布的答案发表评论。
– jimp
2011年6月28日在20:05
@pgfearo糟糕,我没有足够的声誉来评论您的答案!获得特权后,我会在您的答案上发表一些想法,希望很快!
– jimp
11年6月28日在20:08
#7 楼
jGRASP通过在边缘使用视觉标记来实现此目的:它甚至可以识别何时使用循环,并使用不同类型的线表示该内部循环。
我只是想指出现有编辑器是如何做到的。
评论
我认为太吵了,但还是个好主意。
–康拉德·鲁道夫(Konrad Rudolph)
11年6月29日在6:48
我进行了查找,该站点的文档暗示该屏幕快照来自代码查看器,是图表,而不是代码编辑器。同样,没有填充字符,但它仍然是一个缩进视图。出于问题中给出的原因,我正在寻求不需要代码缩进的简单解决方案。就是说,JGrasp看起来是改善代码可理解性的出色工具。
–pgfearo
2011年6月29日23:29
JGrasp应该是我学校的代码编辑器,我们在计算机科学课程的介绍中使用了它,它是推荐的代码编辑器。它具有帮助编译和运行程序的工具,但不像Eclipse或Netbeans那么花哨。但是它与您所说的并不是真正的通用目的略有不同,并且仅真正了解Java的语法。
–灰
2011年7月6日4:58
#8 楼
这不是一个坏主意,但是必须参考左边距以清楚地看到我的方块可能会有些烦人。甚至都没有考虑屏幕的房地产,或者如果结构变得很深的话看起来会是什么样子。由于动机是为了帮助用户“看到”他们用于缩进的空格字符,因此您只需向他们显示空格字符即可。
我不是在说特殊的视觉字符,例如段落标记,只是突出显示。黄色的空格,绿色的制表符(或其他符号)
对于边距/嵌套问题,您可以只移动每个块的边距。没有什么可以说边距必须是一条直线。
我确定这不是一个新主意。
像这样的事情:
评论
使用缩进视图,计划是照亮您的想法,动态地照亮空白。另外,请记住,在平面视图中,嵌套的30层空间与1层空间占用的空间相同,以缩进方式排列,这将超出屏幕边缘,这就是为什么开发人员可以选择视图的原因之一。
–pgfearo
2011年7月1日在18:30
是的,这就是为什么我说这不是一个新主意。但是,如果缩进级别基于我当前正在编辑的级别是对数级别或动态级别,则不会出现您要讨论的问题。即使只是将其固定为1个空间,它也不会在屏幕外。即使是老式的80字符显示屏,您也不会半途而废。是的,对于其中的某些想法,30个级别占用的空间与1个级别相同,但是当您看其中的某些级别时,仅缩进不会节省空间,它们只是缩进整个内容并添加一些精美的图形。
–贾斯汀·欧姆斯(Justin Ohms)
2011年7月1日在18:40
哦现在,问题中的屏幕房地产部分(这是社区Wiki和所有),其中包括屏幕截图比较。如果您可以使用自己的观察来更新本节,那就太好了。请接受我非常喜欢缩进视图(在XML世界和所有领域都工作),这就是为什么我在过去的6个月或更长时间里一直在完善由系统管理缩进的虚拟格式技术的原因。如果我了解到一件事,那就是开发人员喜欢选择-因此是平面视图。
–pgfearo
2011年7月1日在20:58
初读时,我想念您关于动态缩进宽度的想法-这可能是一个强大的功能。即使在其余部分是平坦的情况下缩进一些代码,这也增加了可能性,不确定它在实践中如何工作,但是很容易测试-在我的项目中,即使对于平坦视图,缩进逻辑仍然被调用,它只是乘法器设置为0。因此它只是这个需要调整的乘数。好决定。
–pgfearo
2011年7月2日在16:13
#9 楼
为什么不打开和关闭括号?缩进意味着包含:(和)对程序员来说完全相同。
(和)都是单个字符:左小节将保留非常薄。
很容易发现空元素:在同一行上使用()。
元素的内容不需要直观的提示:空白更好。
光标位置在右边的内容可以与左边的包含块匹配:使用(和)
动态地向列中的字符添加颜色。您可以使用<和>使它更像XML,从远处看起来更好。
评论
一些有用的想法-将尝试合并它们,尤其是XML风格的东西。此外,还有很多动态的地方,我可能还可以添加更多-而不至于太霸道。
–pgfearo
2011年6月25日23:34
您是说喜欢Lisp吗? Lisp是迄今为止发明的最糟糕的样式之一。除非我误解了你的答案,否则它很快就会失控。
– jdk1.0
4月11日14:56
#10 楼
Vim可以做类似的事情,尽管还不那么漂亮。Vim中有多种方法可以进行“代码折叠”。其中之一是基于语法折叠规则的。完成此操作后,可以使用嵌套的大纲结构折叠代码,并且可以使用“ FoldColumn”给出“ foldlevel”的图形化表示(实际上是“基于字符的” |”和“-”字符) 。
foldcolumn可以给出嵌套表示,而与foldmethod无关,但是基于语法的方法可能是适合您所需的方法。我不确定是否存在针对xml的基于语法的预制折叠规则,我想可能会有。
评论
我正在设计的编辑器将通过GUI集成到一个更大的系统中,出于技术和许可方面的考虑,其中不考虑Vim或任何第三方工具。但是,我对Vim如何解决此问题感兴趣,因此将对此进行调查-希望他们在文档中有屏幕截图。是的,基于字符的图形可以在某种程度上起作用-我已经模拟了一个用于研究。可以从左边距完成代码折叠,但是还提供了同步的大纲树视图。
–pgfearo
2011年6月28日在21:53
@pgfearo:您可能会看一下Vim的NetBeans协议。它旨在用于将Vim嵌入IDE中,而没有任何许可问题。
– Greyfade
2011年6月28日22:33
@greyfade-至少在我当前的项目中,我担心至少存在许可问题,因为它的源代码是封闭的,我需要方便(即使没有使用它)来修改Vim源代码,而无需担心GPL。除此之外,该协议看起来确实很有趣。
–pgfearo
2011年6月29日下午6:57
#11 楼
我认为您在使用选项B和C的方向正确:同时包括宽度和热图着色。我现在比B更喜欢选项B,因为它的干扰性较小(要么宽而稀,要么狭窄而密集,而不是C中间的沉重障碍)。缺点是,使用该选项时,您必须如果在某个位置插入一个级别,则可以重新构建整个图形。我认为您可以使块小得多,1或2 px可能就足够了。不必太多,只需要区分即可。尤其是当人们期望人们多次使用该编辑器时,不易打扰,更微妙的效果会更易于使用,因为它们不会分散您的注意力。
使用某种编辑器时很重要的一件事尽管突出显示了当前范围:在编辑器中选择一行时,您需要确切地看到它包含哪些元素以及在哪里停止。您甚至可以突出显示树(它是什么元素)。我认为这是一个单独的问题,需要解决和思考,并且将对用户如何评价编辑器体验产生更大的影响。
评论
我现在已经提交了一个答案,我认为该答案与您的答案交叉,但恰巧与您突出显示当前范围(带有发光的边框)的想法有关。我同意这些块应该不太引人注目,这里夸大了效果以帮助我的绘图,因此它们在缩小的屏幕截图上可以正常显示。
–pgfearo
2011年6月26日上午11:09
#12 楼
我未曾提及的一件事是,您可以在似乎已确定的饱和效果之上使用色调进行处理。我的建议是更改指针所在巢的颜色。这样一来,用户就可以更轻松地分辨出哪些行是嵌套的一部分,而不是它的同级兄弟。实现基于色相的东西时,请注意色盲,并且选择可以普遍区分的颜色,或者为人们提供一些选择。
评论
我认为,这凸显出,要为该模式的实现添加更多细节,还有很多工作要做。是的,我更愿意使用色调来避免颜色意识问题,但是只要有可用的选项,我同意它将有助于增加尺寸。由于此问题现在是社区Wiki,因此我将尝试提交线框,以查看其他人是否愿意提供主题主题不同的图像-首选项可能会在用法,语言语法和动态上下文的不同类别中有所不同。
–pgfearo
2011年6月30日下午5:25
#13 楼
到目前为止,可以与其他建议一起使用的一个选项是在左边距上使用工具提示,该提示使用XPath表示法显示行的路径。浏览器的“检查元素”工具(例如Firebug,Chrome内置的工具)通常会在状态栏中执行类似的操作。评论
我只是专注于此控件,但是带有“ breadcrumb”导航器的“ XPath位置栏”确实可以正常工作,并且与同步元素树状视图一样被合并到编辑器中。
–pgfearo
2011年6月26日9:48
#14 楼
可能有一个热图的折叠视图(来自原始帖子),其中只有一列颜色和深度编号。这将使他们知道他们有多深,并为他们提供更多的xml屏幕资源。对我来说似乎是双赢。我担心是否会有足够的颜色差异来深深地嵌套事物。
评论
支持高层嵌套是当务之急。但是,在任何时候,眼睛都只需要看到(并且可以进入)那么多的东西,因此,在某个级别之外,我正在考虑将颜色混合在一起,以给人深刻的印象,并且仅突出显示关键级别。因此,当嵌套级别较高时,我将检查您的想法。
–pgfearo
2011-6-28在22:03
评论
我没有真正的答案给你,只是意见。查看您的示例,B是我的首选。它对我来说很突出,因为“热图”实际上遵循缩进,而不是像第一个示例和C那样镜像它。 A也遵循实际的缩进,但是B更像是将实际的xml缩进时所看到的。第二个例子对我来说太简单了。我希望自己缩进代码。不确定这样做的好处是什么?我是否缺少明显的东西? (真的不希望这听起来是负面的。)
我看不出在100%的行上占据巨额利润比仅在每行需要的利润上占据优势要好得多。
@约翰·吉岑(John Gietzen)。目的不是保存屏幕不动产(尽管在许多情况下可能会产生影响)。重要的是,它允许对空格字符进行更严格的控制-仍将提供缩进视图(但为虚拟视图,不使用填充字符)。
我投票关闭此问题作为离题主题,因为这是一个UX问题,但是太旧了,无法迁移。