ASP.NET Webforms开发人员和Web设计人员:如何进行交互?


17

我是ASP.NET Webforms开发人员,在与设计师打交道时会遇到一些问题。

设计师总是抱怨asp.net server controls。他们宁愿只拥有一个html文件,并创建css文件以及所需的图像以将它们随身携带。有时候,如果设计阶段是提前完成的,我会得到带有相关css文件的html文件,但是随后我们将设计与aspx文件集成在一起会遇到很多问题(严重控制了telerik控件……等等)。

我想问的是:

  • 我该如何克服这些问题?由于.net服务器控件存在问题,设计人员更喜欢php和mvc开发人员。我需要知道如何以正确的方式与设计师互动。
  • 是否有任何工具或应用程序可为设计人员提供.aspx页的呈现(html页)?我的意思是说运行时中的页面而不是Visual Studio中的aspx。他们确实使用Web表达式,但是他们也希望使用html呈现页面。

5
Nerf rot蝙蝠。
乔尔·埃瑟顿

3
有提供渲染运行时html页面的工具吗?Web服务器应该可以工作。
PSR

6
这就是为什么我永远不会使用APT.NET服务器控件的原因,如果我不得不使用ASP.NET,我会差别地使用APT.NET MVC。
ryanzec

3
完全是@ryanzec。剃刀视图对此也非常有用,只有很小的小动态指令,其余的都是纯HTML。开发人员发现易于开发和使用它,设计师喜欢它,因为它几乎是纯HTML
Earlz 2012年

3
@Ryathal-向他们显示皮肤文件将使它们运行正常。主题和外观对于大多数前端设计师来说绝对没有用。它们是样式的.NET抽象(主要是Web设计师不自然)。
格雷厄姆(Graham)

Answers:


29

Dev曾经是这里的前设计师,我曾经对Web控件感到不满和抱怨。坦率地说,对于设计师来说,调整其实践要比让.NET Developer深入研究GridView的自定义实现便宜得多,因为设计师坚持认为每个TD都有一个“ rel”标签(或其他任何东西)。

正如Arseni Mourzenko非常明智地指出的那样,决定使用Webforms是公司的选择,它限制了对HTML的某些控制,同时还提高了编码效率。除非公司愿意重新考虑(他们不应该只是为了取悦设计师),否则设计师需要接受这种现实。他们可以做的几件事:

1)停止根据ID进行操作。尽管起初觉得这是错误的,但我发现当我用类(当然还有继承)来样式化所有内容时,生活实际上要容易得多。首先,它均衡了我所有选择器的权重。在CSS继承中,ID胜过CLASS。让所有内容都成为孩子和/或类选择器确实很不错,并且使确定特异性的顺序更加简单。在JS层中也是如此,这让我很痛苦,无法将基于ID的选择器换成基于类的选择器。

2)教给他们RadioButtonLists和CheckboxLists转换成什么,以及Label = span,Panel = div和其他非显而易见的HTML控件。.NET将这些内容呈现为HTML的方式比我预期的要怪,而且当我知道HTML将如何从这些控件中提取出来时,对于我来说创建屏幕要容易得多。

3)让他们直接在ASPX中做设计师,而不是原始HTML(!important)。教给设计人员GridViews,ListViews等的基础知识。给他们一些代码片段,以将匿名对象集合推送到Grid / ListView控件中。如果他们可以学习CSS,那么他们可以学习复制粘贴此代码。他们可以使用VS Web Express的免费版本,该版本现在非常擅长CSS和JS的工作。这些虚拟Web项目将使设计人员有机会输入一些控件,然后单击“查看源代码”以查看它们的呈现方式。

4)解释.NET中如何使用FORM标签。早些时候忘记了这一点,但是设计人员必须习惯的另一件事是,通常,单个FORM标记会包裹整个页面。这改变了表单控件的行为方式,并且您不能嵌套FORM标签而没有真正奇怪的副作用。确保设计人员理解这一点,否则他们的表单HTML将成为WebForms的噩梦。

5)远离主题和皮肤。尽管.NET框架提供了这些工具来帮助跨应用程序进行样式控制,但它们对于普通的Web Designer而言既笨拙又怪异,我从来没有发现它们值得我花时间。对于不精通CSS的开发人员而言,它们似乎是一个不错的工具,但只会减慢设计人员的工作速度。让设计人员在自然环境中工作(html和css文件),他们将更快乐,更高效。

6)在您的站点解决方案中保留“原型”项目。为了确保开发人员始终有针对的目标,请设计人员在您的实际解决方案中创建一个虚假的Web项目,以保留他们的仅ASPX页面,而不让真正的开发人员使用。这意味着设计人员可以在与真实项目相同的解决方案中回顾他们的原型,以检查开发人员的工作方式,并且开发人员可以随时运行原型以确保其工作符合设计者的意图。

最后,除非准备好重新培训开发人员,否则请抵制所有投诉以转换为MVC。我个人很喜欢MVC,但是如果您有一个拥有大量WebForms知识的团队,请不要无缘无故地扔掉它。如果您的应用程序存在ViewState问题,SEO问题或可访问性问题,那么绝对可以使MVC看上去更加困难。但是,在MVC上培训WebForms开发人员比培训设计人员如何使用Web控件要花费更多时间。

归根结底,即使我最终在那个令人毛骨悚然的GridView上发誓要花一个小时再弄清楚它,但我仍然无法进行跨设计的工作,我无法亲自在WebForms中进行工作。

是否有任何工具或应用程序可为设计人员提供.aspx页的呈现(html页)?

忘了表情(我从未喜欢过)。为他们提供Visual Studio的免费版本(Web Developer Express)。它可以连接到您拥有的任何源代码控制解决方案中,并使设计人员可以运行ASPX页面并在浏览器中查看呈现的HTML。CSS和JS工具比以前要好得多,并且有一些很棒的工具被嵌入到Web Essentials等扩展中。一键式将CSS规则转换为所有特定于供应商的偏差,在VS界面中进行颜色选择器和调色板,一键式将图像嵌入到css文件中,“无需” CSS转换(您可以在CSS中进行“编码”), F12在JavaScript上“导航至”,再加上真正的智能,还有更多。现在,FYI是设计师们的宝库,


3
您的最后一行...因此,长远的解决方案是承受和适应,而不是解决根本原因?(根本原因是将Web应用程序当作桌面应用程序一样对待)
Earlz 2012年

3
@Earlz-如果您有一群开发人员没有带宽来接管新的范式(MVC),这仅仅是因为另外1-2名设计人员不想适应WebForms,这在商业上是有意义的。我要告诉您的是,如果设计人员愿意放弃某些东西(ID与类语义,对标签标签的精确控制等),对于设计师来说,适应WebForms并不难。瞧,我本人就是那个不断抱怨.NET标记的设计师,直到我意识到(除非您在SEO游戏中)html源代码真的不重要。对不起,这是真的。
格雷厄姆(Graham)

1
@Earlz:根本原因是设计师实际上不能在媒介中工作。从长远来看,让他们在中等水平上工作可能是最成功的解决方案。
怀亚特·巴内特

3
更不用说一个事实,即设计师有时每小时的费用要比开发人员少,因此,每小时30美元的设计师要比每小时60美元的开发商更好地改变某些东西,因为设计师对此有些pussy贬。
TheMonkeyMan 2012年

我的第一笔赏金赢了!
格雷厄姆(Graham)2012年

8

有一个解决您的问题的方法,但涉及将设计模式更改为MVP。这是时间的前期投资,在开始之前需要认真考虑。

基本上,您遇到的问题不是新问题。简而言之,您需要通过可识别视图支持的数据模型的接口引入视图抽象。

这是一个非常全面的主题,可以将模式视为生活的例子。您会发现此示例对您的案例很有帮助 - 带有MVP模式的Better Web Forms

编辑:如果上述建议太昂贵(就时间和资源而言)无法遵循,我绝对建议与您的设计师更紧密地合作。我确实相信,在团队中交流您的问题应该极大地帮助您解决(设计人员和开发人员)工作中的障碍。这是团队合作和问题的良好协作,可以消除执行工作的所有障碍,这是团队成功项目方式!这是我们在项目中所做的事情。


1
+1:考虑到问题的限制(ASP.NET Webforms),这是一个不错的解决方案,但是正如您所指出的那样,这可能非常昂贵,因为它需要大量的纪律和时间(这意味着金钱)。我认为,如果OP对全包解决方案感兴趣,那么他应该考虑切换到ASP.NET MVC(而不是Webforms MVP)。除了与设计人员更好的沟通外,OP还可以带来许多其他好处,例如TTM和保留开发人员。
Jim G.

6

ASP.NET是一个框架,用于抽象生成的HTML代码。这意味着除非您有足够的预算来重写由ASP.NET控件生成的任何内容,否则就不会要求您在ASP.NET应用程序中完全重现给定的HTML代码

由利益相关者决定:要么使用具有优点和缺点的ASP.NET控件,要么切换到手动HTML(或转到ASP.NET MVC),从而使当前项目的成本增加数千美元。 。

在这种情况下,无法自定义HTML是任何其他约束。设计师应在工作中考虑这一技术限制。这种情况与设计人员告诉您应该以确切的字体以正确的大小显示文本非常相似:这是Web支持,而不是打印,这意味着文本的大小会有所不同。

至于工具,我不知道将纯HTML转换为ASP.NET模板的工具。如何猜测必须将特定表转换为特定ASP.NET控件?


1
+1表示要由利益相关者决定。薪水签名者做出决定后,其他所有人都需要与之保持一致。

我不会说得太大声,但是我认为其他框架更加灵活。在我看来,无法(轻松)自定义HTML是足以开始考虑迁移到另一个框架(如rails)的充分理由。
ostroon,2012年

6

在我的上一份工作中,开发人员将构建该应用程序,然后将其传递给设计人员,以便使它们看起来像一群软件程序员没有设计的。:)

当我们刚开始这个过程时,开发人员和设计师之间来回频繁。他们不明白他们给出的页面。如果我们动态地构建页面,天堂禁止!这与您在此处描述的情况大致相同。

我与每个设计师坐下并教他们如何在其本地机器上安装Web应用程序。我向他们展示了如何运行它以及所有内容。我解释了如何在屏幕上呈现asp控件。然后,我们在浏览器中将其打开,并使用firebug来查看asp控件和渲染内容之间的链接。

这对他们有很大帮助。一旦他们看到它并在盒子上运行并使用他们的设计工具进行调整和使用样式,就可以使他们的生活变得更加轻松。

完成此操作后,我与开发人员开会,让他们知道他们应该使用CssClass标记并确保已定义样式。动态地放到屏幕上的任何东西都需要有一个css类附加到其上,设计人员无法添加它。

这是一个过程。双方花了一些时间来适应这项安排。但这打开了交流的渠道。设计人员不必抱怨所使用的控件,而是可以要求将样式添加到各种元素中。

因此,我的建议是与设计师坐下来,向他们展示页面的呈现方式。使用Firebug剖析页面,并查看页面的形成方式。


4

这是我过去与设计师在必须处理正在开发的ASP.NET WebForms项目时所采用的一些有用方法。

  1. 本地部署:开发人员提供本地部署的项目的中间版本。这样可以节省时间。设计器请求一个.aspx,但与呈现的HTML交互而不是与服务器代码交互。这种方法从设计者那里提取服务器代码。他不需要知道如何生成HTML或将javscriptcss文件传送到客户端的方式。当然,这是假定设计人员精通浏览器调试器/ DOM检查器。设计人员可以css在浏览器中应用所有更改,然后将其应用到css文件。
  2. 提供模型:为了使设计人员更容易使用HTML,请向他们提供由服务器控件呈现的HTML模型。他们可以将该HTML调整到他们喜欢的位置,并提出要在服务器端实现中应用的更改。这需要尽早经常地完成,因为您不希望最终获得客户端实现所依赖的HTML结构,然后让设计者提出对该结构的更改。

设计人员通常应该尽可能减少与服务器端代码的接触点,因此请尽可能从它们中提取出更多信息。


2

作为一个混合开发人员,我自己(在后端和前端角色中经常做很多工作,经常一起做),我也长期不喜欢ASP.NET WebForms模型...虽然它是最初的。设计的推动力是提供简单的拖放式设计工具来使Web开发民主化(与Visual Basic使非CS-major可以访问应用程序的方式相同),该方法曾尝试将状态强制置于非CS上。无状态的环境(网络)是无用的和强制的(哦,ViewState,我讨厌您!)。

它们还违反了标记开发和样式设计的一些中心原则,就这一事实而言,默认情况下,ASP.NET接管ID属性,从而迫使CSS设计人员以与使用ID相同的方式使用类,在div和嵌套标签的深层堆栈中分层元素,这会使控件的样式成为除最简单系统之外的所有内容的噩梦。

有了这些东西,您的路就不容易了,因为我认为重写MVC可能会浪费成本或时间。

有什么方法可以为设计人员提供一个运行Web应用程序的环境,以便他们可以实时查看其CSS更改?当我在ASP.NET WebForms中进行设计工作时,我发现能够在自己的计算机上启动Web应用程序,对CSS进行调整并在本地运行它以查看其对应用程序的影响是无价的。

一种选择可能是设置一个专门为ASP.NET开发量身定制的虚拟机,设计人员可以从其工作站运行该虚拟机,因此他们不必混合使用两个工具集,并且如果它们碰巧在开发中造成了麻烦,空间,则始终可以从正常运行的图像中重新加载。

是的,这意味着设计人员将必须学习如何按F5来运行该应用程序。(或者只是让他们访问FTP,甚至可以在测试环境中访问CSS,JS和图像所在的目录!)这也意味着他们会看到很多后端代码,即使您告诉他们,只需忽略您的.cs或.vb文件,这将使它们免于惊慌……当然,这意味着您必须确保您没有在执行诸如从代码隐藏文件中设置样式之类的事情。 (但是您不会那样做,因为那样会束缚数据并紧密查看,对吗?)。

如果您的网站结构合理,具有不同的CSS和JS文件,并且没有在标记上强加很多内联样式,则很可能他们只需避开<%%>区域即可完成大部分工作。另一方面,当尝试将他们的静态HTML / CSS转换为适用于动态应用程序的内容时,它也可以使设计人员对您必须经历的事情有更多的了解。


为了实时查看CSS更改,我只使用Firebug。它可以在任何地方使用...您可能还可以使用Spidermonkey,因为Firebug往往会忘记您在不同页面上
所做的

我有点假设任何值得其开发的Web开发人员(甚至那些只使用静态HTML和CSS的开发人员)都将使用Firebug之类的东西,但这是考虑的好点...耦合Firebug(甚至是Chrome的Developer窗口)可以访问测试服务器,或者在本地运行它并在其上使用Firebug,可以创建与“理想”环境最接近的东西,以使设计人员习惯于他们必须对动态站点进行的调整。
杰森·巴切洛

1

您需要让他们一起交谈,了解彼此的需求和偏好。这是软件和工具无法解决的“问题”。不要试图取悦双方,那将永远行不通。他们需要妥协-就像婚姻。

一种方法是安排f.ex。研讨会,各方可以借此机会解释原因,以便他们喜欢自己喜欢的东西。在这种情况下,良好的沟通始终是关键。这样的聚会可以看作是投资。

或简单地说,问题是面向组织的,而不是技术性的,这就是您需要提供解决方案的地方。

另一种选择是提高工资并告诉他们闭嘴(通常是短期解决方案...)。


最后一行=笑话
epistemex 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.