Розробники веб-форм ASP.NET та веб-дизайнери: як взаємодіяти?


17

Я розробник веб-форм ASP.NET, і стикаюся з деякими проблемами, коли маю справу з дизайнерами.

Дизайнери завжди скаржаться на asp.net server controls. Вони краще просто мати файл html та створювати cssфайли разом із необхідними зображеннями, які йтимуть із ними. Іноді, якщо фаза проектування виконана заздалегідь, я отримую html-файли із відповідними файлами css, але тоді ми стикаємося з багатьма проблемами інтеграції дизайну з aspxфайлами (серйозний контроль, керування telerik ... тощо).

Я хочу запитати про це:

  • Як мені подолати ці проблеми? Дизайнери віддають перевагу розробникам php- та mvc через проблеми з керуванням сервера .net. Мені потрібно знати, як правильно взаємодіяти з дизайнерами.
  • Чи є інструменти чи програми, щоб надати дизайнерам відображену (html-сторінку) сторінки .aspx? Під цим я маю на увазі сторінку під час виконання, а не aspx у Visual Studio. Вони використовують Веб-експресію, але хочуть також відредаговану сторінку в HTML.

5
Кажани Nerf Crotch.
Джоель Етертон

3
Будь-які інструменти для надання html-сторінки, що надається для виконання Для цього повинен працювати веб-сервер.
psr

6
саме тому я ніколи не використовував APT.NET серверні керування, якби мені довелося використовувати ASP.NET, я б різко використовував APT.NET MVC.
ryanzec

3
@ryanzec точно. Перегляди бритви дуже хороші і для цього, лише невеликі динамічні директиви, а решта - це прямий HTML. Розробникам легко розробити і використовувати, дизайнерам подобається, що це майже чистий HTML
Earlz

3
@Ryathal - показ їх шкіряних файлів надсилатиме їх до дверей. Теми та Скіни абсолютно непридатні для більшості дизайнерів. Вони являють собою .NET абстракцію стилів (в основному), які не є природними для веб-дизайнерів.
Грехем

Відповіді:


29

Колишній дизайнер тут перетворився на Dev, і я теж мовчав і стогнав над веб-контролями. Чесно кажучи, його МНОГО дешевше для дизайнера, щоб скорегувати свою практику, ніж для .NET Developer, щоб заглибитись у користувацьку імпементацію GridView, оскільки дизайнер ВСТАНОВЛЕНО, щоб кожен TD мав тег "rel" (або що завгодно).

Як дуже розумно зауважив Арсеній Мурценко, рішення про використання веб-форм - це вибір компанії, який обмежує деякий контроль над HTML, надаючи деяку ефективність кодування. Якщо компанія не готова повторно розглянути (що вони НЕ повинні робити тільки для того, щоб догодити дизайнерам), тоді дизайнерам потрібно прийняти цю реальність. Ось декілька речей, які вони можуть зробити:

1) Зупиняйте залежність від ідентифікаторів для чого завгодно . Незважаючи на те, що спочатку це було неправильно, я виявив, що життя насправді було набагато простішим, коли я стилював все з класами (і спадщиною, звичайно). Перш за все, це вирівняло всі мої селекторні ваги. У спадщині CSS ідентифікує козир КЛАСУ. Насправді це було приємно, щоб все було дитиною та / або селекціонером класу, і з'ясовувати конкретний порядок трохи простіше. Те саме, що і в шарі JS, це дало мені біль ZERO підміняти мої селектори на основі ідентифікаторів на класи на основі.

2) Навчіть їх, у що перетворюють RadioButtonLists та CheckboxLists , поряд із Label = span, Panel = div та іншими не очевидними елементами керування в html. Те, як .NET робить це HTML, було дещо дивнішим, ніж я очікував, і мені було набагато простіше створити екрани, коли я знав, як HTML вийде з цих елементів управління.

3) Нехай вони роблять своїх дизайнерів НА ПЕРЕГЛЯДНОМУ ASPX , а не в сирому HTML ( важливо ). Навчіть дизайнерів основ GridViews, ListViews тощо. Надайте їм фрагменти коду, щоб підштовхнути анонімну колекцію об'єктів до елемента Grid / ListView. Якщо вони можуть вивчити CSS, то вони можуть навчитися копіювати та вставляти цей код. Вони можуть використовувати безкоштовну версію VS Web Express, що досить добре працює в CSS & JS зараз. Ці підроблені веб-проекти дадуть дизайнерам можливість ввести деякі елементи керування, а потім переглянути джерело, щоб побачити, як вони відображаються.

4) Поясніть, як використовується тег FORM у .NET . Забули про це раніше, але інша справа, до якої дизайнер повинен звикнути, - це те, що зазвичай один тег ФОРМУ загортає всю сторінку. Це змінює спосіб поведінки елементів управління, і ви не можете вкладати теги FORM без дійсно дивних побічних ефектів. Переконайтесь, що дизайнери розуміють це, інакше їх форма HTML буде кошмаром для перетворення у WebForms.

5) Тримайтеся подалі від тем і шкіри . Незважаючи на те, що в .NET-платформі є ці інструменти, які допомагають керувати стилем у програмі, вони незграбні та дивні нормальним веб-дизайнерам, і я ніколи не вважав їх вартим свого часу. Вони здаються гарним інструментом для розробників, які недостатньо добре розбираються в CSS, але лише сповілять дизайнерів. Нехай дизайнери працюють у своєму природному середовищі (файли html та css), і вони будуть щасливішими та продуктивнішими.

6) Зберігайте "прототипові" проекти у своїх рішеннях на сайті . Щоб упевнитись, що розробники завжди мають на меті кодувати, запропонуйте дизайнерам створити підроблений веб-проект у вашому реальному рішенні, щоб зберегти свої сторінки ASPX лише для збереження та недоторканості реальних розробників. Це означає, що дизайнери можуть повернутися до своїх прототипів в тому ж рішенні, що і реальний проект, щоб перевірити, як це робили розробники, і розробники можуть запустити прототип у будь-який час, щоб переконатися, що їх робота відповідає намірам дизайнерів.

Нарешті, протистоять будь-яким скаргам для переходу на MVC, якщо ви не готові переквалифікувати ваші Devs. Я люблю MVC особисто, але якщо у вас є команда, що володіє безліччю знань WebForms, не намагайтеся відкидати це без причини. Якщо у ваших додатках виникають проблеми з ViewState, проблемами з SEO або проблемами з доступністю, то MVC абсолютно серйозно роздивиться. Але для навчання веб-форм розробників на MVC піде набагато більше часу, ніж це буде для того, щоб навчити дизайнерів користуватися веб-елементами управління.

Зрештою, НЕ БУЛО ДИЗАЙН Я Я БУДУТЬ БУДИ БІЛЬСЯ, Я не міг особисто заробляти роботу в WebForms, навіть якщо я в кінці кінця лаявся в цьому проклятому GridView протягом години, перш ніж з'ясувати це.

Чи є інструменти чи програми, щоб надати дизайнерам відображену (html-сторінку) сторінки .aspx?

Забудьте про вираз (мені це ніколи не подобалося). Отримайте їм безкоштовну версію Visual Studio (Web Developer Express). Він може підключитися до будь-якого рішення управління джерелом, яке у вас є, і це дозволить дизайнерам запускати свої сторінки ASPX і бачити виведений HTML в браузері. Інструменти для CSS та JS набагато кращі, ніж раніше, і є деякі дивовижні інструменти, розроблені у розширеннях, як Web Essentials. Трансформація правил CSS в один клік у всі їхні відмінні відхилення від продавця, підбір кольорів і палітри прямо в інтерфейсі VS, вбудоване зображення в файли css в 1 клік, "МЕНШЕ" перетворення CSS (ви можете "кодувати" в CSS), F12 "Перейти до" на JavaScript, а також реальна інтелігенція та багато іншого. Зараз це скарбниця для дизайнерів, FYI,


3
Ваш останній рядок ... Отже, довгострокове рішення - це просто страждати і адаптуватися, а не вирішувати першопричину? (де першопричиною є лікування веб-програми, як-от настільний додаток)
Earlz

3
@Earlz - Це може мати сенс для бізнесу, якщо у вас є співробітники розробників, які не мають пропускної здатності, щоб вибрати нову парадигму (MVC) тільки тому, що 1-2 інших дизайнерських співробітників не хочуть адаптуватися до WebForms. Я кажу вам, що НЕ так складно дизайнеру адаптуватися до WebForms, якщо вони готові відпустити якісь речі (семантика ID проти класу, точний контроль над тегами міток тощо). Подивіться, я сам БУДУ того дизайнера, який постійно скуготів про розмітку .NET, поки я не зрозумів, що (якщо ви не в грі SEO) html-джерело дійсно НЕ МАТЕРИ. Вибачте, але це правда.
Грем

1
@Earlz: Першопричиною є те, що дизайнери насправді не можуть працювати в середовищі. Підготовка їх до роботи в середовищі - це, мабуть, найуспішніше рішення там, на довгостроковому рівні.
Wyatt Barnett

3
Не кажучи вже про той факт, що Дизайнер часом коштує менше за годину, ніж розробник, тому Дизайнеру в $ 30ph краще буде щось змінити, ніж розробник на $ 60ph що-небудь змінити щось, тому що дизайнер - це кицька про це.
TheMonkeyMan

Мій 1-й щедрий виграв, вут!
Грем

8

Вирішення Ваших питань є, але воно включає зміну структури дизайну на MVP . Це випереджальна інвестиція часу, яка потребує серйозного розгляду перед початком.

В основному, проблеми, з якими ви стикаєтеся, не нові. Коротше кажучи, вам потрібно ввести абстракцію подання через інтерфейс, який визначає модель даних, яку підтримує представлення даних.

Це дуже всебічна тема, яка має сенс розглядати зразок як життєвий приклад. Ви знайдете цей приклад досить інформативним для вашого випадку - Кращі веб-форми з MVP-шаблоном .

Редагувати: Якщо вищезазначена пропозиція є надто дорогою (з точки зору часу та ресурсів), я б напевно радив ближче співпрацювати з вашим дизайнером . Я вважаю, що спілкування з вашими проблемами в команді має сильно допомогти вирішити перешкоди у вашій роботі (дизайнера та розробника). Це командна робота, і хороша співпраця з питаннями для усунення всіх перешкод для виконання роботи - це спосіб досягти успіху в проекті як команда ! Це те, що ми робимо в нашому проекті.


1
+1: Це гідне рішення, враховуючи обмеження проблеми (ASP.NET Webforms), але, як ви зазначаєте, це може бути дуже дорогим, оскільки вимагає багато дисципліни та часу (що означає гроші). Я заперечую, що якщо ОП зацікавлена ​​у всеосяжному рішенні, тоді він повинен розглянути можливість переходу на ASP.NET MVC (замість MVP веб-форм). ОП отримає багато інших переваг, таких як TTM та утримання розробників на додаток до кращого спілкування з дизайнером.
Джим Г.

6

ASP.NET - це фреймворк, який резюмує згенерований HTML-код. Це означає, що від вас не може бути запропоновано відтворити вказаний HTML-код у додатку ASP.NET, якщо у вас не вистачить бюджету, щоб переписати все, що створюється елементами управління ASP.NET .

Зацікавлені сторони вирішуватимуть: або ви використовуєте елементи керування ASP.NET з їхніми сильними сторонами та недоліками, або переходите на ручний HTML (або на ASP.NET MVC), збільшуючи вартість поточного проекту на тисячі доларів .

Неможливість налаштувати HTML у цьому контексті є обмеженням, як і будь-яке інше. Дизайнери повинні враховувати це технічне обмеження у своїй роботі. Випадок дуже схожий на те, якщо дизайнер сказав би вам, що текст повинен відображатися в точному шрифті з точним розміром: це веб-підтримка, а не друк, а це означає, що розмір тексту буде змінюватися.

Щодо інструментів, я не знаю про інструменти, які перетворять звичайний HTML в шаблон ASP.NET. Як можна припустити, що певна таблиця повинна бути перетворена на певний елемент управління ASP.NET?


1
+1 для вказівки на те, що вирішувати питання має зацікавлена ​​сторона. Після того, як підписант зарплати прийме своє рішення, всі інші повинні привести його у відповідність.

Я не збираюся говорити це занадто голосно, але думаю, що інші рамки є більш гнучкими. На мою думку, неможливість (легко) налаштувати HTML - це достатня причина, щоб почати думати про перехід до іншого фреймворку (наприклад, рейки).
ostroon

6

На моїй останній роботі розробники створили б додаток, а потім передали його дизайнерам, щоб вони могли зробити його схожим на купу програмних програмістів. :)

Коли ми вперше розпочали цей процес, між розробниками та дизайнерами було багато назад і вперед. Вони не розуміли сторінок, які їм дали. Нехай бог, якщо ми будували сторінку динамічно! Це було так само, як ситуація, яку ви тут описуєте.

Я сів з кожним дизайнером і навчив їх встановлювати веб-додаток на їх місцевому вікні. Я показав їм, як це запустити і все. Я пояснив, як керування asp відображалися на екрані. А потім ми відкрили його у браузері та застосували firebug, щоб побачити зв’язок між елементами управління asp та тим, що було надано.

Це їм дуже допомогло. Як тільки вони змогли побачити це і запустити його на своїх коробках і використовувати свої інструменти дизайну, щоб налаштувати та грати зі стилями, це полегшило їх життя.

Після цього я провів зустріч з розробниками і дав їм знати, що вони повинні використовувати тег CssClass і переконатися, що стилі визначаються. І все, що динамічно виносилося на екран, повинно мати клас css, приєднаний до нього b / c, дизайнери не змогли б його додати.

Це був процес. Минуло певний час, щоб обидві сторони звикли до домовленостей. Але це відкрило лінії спілкування. Замість того, щоб скаржитися на використовувані елементи управління, дизайнери змогли вимагати додавання стилів до різних елементів.

Тому моя пропозиція буде сісти з дизайнерами і показати їм, як відображається сторінка. Використовуйте firebug для розсічення сторінки та перегляду способів її формування.


4

Ось кілька корисних підходів, які я використовував у минулому з дизайнерами, коли їм доводиться працювати над проектом ASP.NET WebForms, який розробляється.

  1. Розгортання локально: розробники надають проміжну версію проекту, розгорнутого локально. Це економить час для обох. Дизайнер запитує .aspx, але взаємодіє з виведеним HTML, а не з кодом сервера. Цей підхід абстрагує код сервера від конструктора. Йому не потрібно знати, як генерується HTML або як файли javscript і cssфайли доставляються клієнту. Звичайно, це передбачає, що дизайнери вміють налагоджувати браузер / інспектор DOM. Дизайнер може застосувати всі його cssзміни всередині браузера, а потім застосувати їх до cssфайлів.
  2. Надання моделей. Для того, щоб дизайнерам було більш розумно працювати з HTML, надайте їм модель HTML, надану серверним управлінням. Вони можуть налаштувати цей HTML до того місця, де їм це подобається, і запропонувати зміни, які будуть застосовані в реалізації на сервері. Це потрібно робити рано і часто , тому що ви не хочете, щоб утворити HTML-структуру, на яку покладається реалізація на стороні клієнта, а потім дизайнер запропонує зміни в цій структурі.

Загалом, дизайнери повинні мати якомога менше точок дотику з кодом сторони сервера, тому абстрагуйте їх від них якомога більше.


2

Як гібридний розробник, сам (зробив багато роботи як в бек-енді, так і в передній ролі, часто разом), маю давню неприязнь до моделі ASP.NET WebForms ... в той час як її початковий Імпульсом дизайну було надати легкі інструменти дизайну, що перетягуються та падіння, щоб демократизувати веб-розробки (так само, як Visual Basic зробив програмування додатків доступним для не-основних CS), методи, якими він намагався примусити стан на Середовище без громадянства (Інтернет) піддаються і змушують (о, ViewState, як я ненавиджу тебе!).

Вони також порушують деякі центральні принципи розробки та стилізації розмітки, саме тим фактом, що за замовчуванням ASP.NET переймає атрибут ID, змушуючи дизайнерів CSS використовувати класи таким же чином, як і призначені для використання ідентифікатори, елементи шарування в глибоких стосах divs та вкладених тегів, які можуть зробити стилі управління кошмаром у всіх, окрім самих спрощених систем.

Враховуючи ці речі, ваш шлях не з легких, оскільки я припускаю, що перезапис для MVC був би непомірним за витратами чи часом.

Чи є спосіб надати дизайнеру середовище, в якому запускати веб-додаток, щоб вони могли бачити свої зміни CSS в режимі реального часу? Коли я займаюся дизайнерськими роботами в ASP.NET WebForms, мені здається, що це безцінне можливість запускати веб-додаток на власній машині, робити налаштування на CSS та запускати його локально, щоб побачити, як це впливає на додаток.

Одним із варіантів може бути налаштування віртуальної машини, спеціально розробленої для розробки ASP.NET, що дизайнер може запускати зі своєї робочої станції, тому їм не доведеться змішувати два набори інструментів, і якщо вони трапляються щось накручувати у розробці, простір, його завжди можна перезавантажити з функціонуючого зображення.

Так, це означає, що дизайнеру доведеться навчитися натискати F5, щоб запустити додаток. (Або просто надайте їм доступ до FTP до каталогів, де CSS, JS та зображення є навіть у тестовому середовищі!) Це також означає, що вони побачать багато резервного коду, хоча якщо ви скажете їм просто ігноруйте ваші .cs або .vb файли, що дозволить уникнути паніки… Звичайно, це означає, що ви повинні бути впевнені, що ви не робите таких речей, як встановлення стилів з вашого коду за файлами .. . (але ви б цього не робили, чи не так, як ви пов’язуєте дані та переглядаєте занадто близько, правда?).

Якщо ваш сайт добре структурований, з різними CSS-файлами та JS-файлами, і не багато вбудованого стилю, примусового до розмітки, можливо, вони можуть виконати більшу частину своєї роботи, просто уникнувши областей <%%>. З іншого боку, це може також дати дизайнеру трохи більше вдячності за те, що вам доведеться пройти, намагаючись перевести їх статичний HTML / CSS в те, що працює для динамічного додатка.


Для перегляду змін у CSS в режимі реального часу я просто використовую Firebug. Він працює скрізь ... Ви, ймовірно, також можете використовувати Spidermonkey, оскільки Firebug прагне не пам’ятати про ваші зміни на різних сторінках
Earlz

Я начебто припускав, що будь-який веб-розробник вартує своєї солі (навіть ті, що працюють лише зі статичним HTML і CSS) використовує щось на зразок Firebug, але це хороший момент, щоб розглянути ... з'єднання Firebug (або навіть вікно розробника Chrome) з доступом до тестового сервера, або запускаючи його локально, і використовуючи Firebug поверх цього, створює найбільш близьке до "ідеального" середовище для залучення дизайнера до коригувань, які вони повинні внести для динамічних сайтів.
Джейсон М. Батчелор

1

Вам потрібно змусити їх спілкуватися разом, розуміти потреби та вподобання один одного. Це "проблема", яку неможливо вирішити програмним забезпеченням та інструментами. Не намагайтеся догодити обом сторонам, що ніколи не вийде. Їм потрібно йти на компроміс - це як шлюб.

Один із способів - влаштувати f.ex. семінари, де кожна зі сторін отримує можливість пояснити, чому це так, що вони віддають перевагу тому, що їм подобається. Гарна комунікація - це завжди ключ до таких ситуацій. Збір таких, як це, можна розглядати як інвестиції.

Або просто сказано, проблема орієнтована на організацію, а не технічну, і саме там потрібно надати рішення.

Інший варіант - підвищити зарплату і сказати їм закрити (зазвичай це короткострокове рішення ...).


Останній рядок = жарт
epistemex
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.