Sviluppatori e web designer ASP.NET Webform: come interagire?


17

Sono uno sviluppatore di moduli Web ASP.NET e ho problemi con i designer.

I designer si lamentano sempre del asp.net server controls. Preferirebbero solo avere un file html e creare cssfile con le immagini richieste per andare con quelli. A volte, se la fase di progettazione viene eseguita in anticipo, ottengo file html con i relativi file css, ma poi incontriamo molti problemi di integrazione della progettazione con i aspxfile (controlli sever e controlli telerik ... ecc.).

Quello che voglio chiedere è:

  • Come posso superare questi problemi? I progettisti preferiscono gli sviluppatori php e mvc a causa dei problemi con i controlli del server .net. Devo sapere come interagire con i designer nel modo corretto.
  • Esistono strumenti o applicazioni per fornire ai designer il rendering (pagina html) delle pagine .aspx? Con questo intendo la pagina in runtime piuttosto che l'aspx in Visual Studio. Usano Web Expression ma vogliono anche la pagina renderizzata in HTML.

5
Pipistrelli con cavallo nerf.
Joel Etherton,

3
Qualche strumento per fornire la pagina html di runtime renderizzata? Un web server dovrebbe funzionare per questo.
psr

6
questo è il motivo per cui non avrei mai usato i controlli del server APT.NET, se dovessi usare ASP.NET, utilizzerei in modo diffuso APT.NET MVC.
Ryanzec,

3
@ryanzec esattamente. Le visualizzazioni di rasoio sono davvero interessanti anche per questo, solo piccole piccole direttive dinamiche e il resto è un semplice HTML. Gli sviluppatori trovano facile svilupparsi e usarlo, ai designer piace perché è quasi puro HTML
Earlz

3
@Ryathal: mostrando loro i file Skin li spediranno correndo verso la porta. Temi e skin sono assolutamente inutili per la maggior parte dei designer front-end. Sono un'astrazione .NET dello stile (principalmente) che non è naturale per i web designer.
Graham,

Risposte:


29

L'ex designer qui, ha trasformato Dev, e io ero solito pisciare e lamentarsi anche dei controlli Web. Onestamente, è MOLTO più economico per un progettista adeguare le proprie pratiche che per uno sviluppatore .NET di approfondire un'impelmentazione personalizzata di GridView perché il progettista ha insistito sul fatto che ogni TD ha un tag 'rel' (o qualsiasi altra cosa).

Come Arseni Mourzenko ha sottolineato molto saggiamente, la decisione di utilizzare Webforms è una scelta aziendale che limita parte del controllo sull'HTML garantendo al contempo una certa efficienza nella codifica. A meno che la società non sia disposta a riconsiderare (cosa che NON dovrebbero fare solo per soddisfare i progettisti), i progettisti devono accettare questa realtà. Ecco alcune cose che possono fare:

1) Fermati a seconda degli ID per qualsiasi cosa . Anche se all'inizio mi è sembrato sbagliato, ho scoperto che la vita era in realtà molto più semplice quando ho disegnato tutto con le classi (e l'eredità, ovviamente). Prima di tutto, ha equalizzato tutti i pesi dei miei selettori. In eredità CSS, ID supera CLASS. In realtà è stato un po 'bello avere tutto come un bambino e / o un selettore di classe, e ha reso un po' più semplice capire l'ordine di specificità. Stessa cosa nel livello JS, mi ha dato dolore ZERO per sostituire i selettori basati su ID con quelli basati su classe.

2) Insegnate loro in cosa trasformano RadioButtonLists e CheckboxLists , insieme a Label = span, Panel = div e le altre cose non ovvie di controllo in html. Il modo in cui .NET li rende in HTML è stato un po 'più strano di quanto mi aspettassi, ed è stato molto più facile per me creare schermate quando ho saputo come l'HTML sarebbe uscito da quei controlli.

3) Fagli fare i loro progettisti IN ASPX DIRETTAMENTE , non in HTML non elaborato ( ! Importante ). Insegnare ai progettisti le basi di GridView, ListView, ecc. Fornire loro alcuni frammenti di codice per inserire una raccolta di oggetti anonimi in un controllo Grid / ListView. Se riescono a imparare i CSS, possono imparare a copiare e incollare questo codice. Possono usare la versione gratuita di VS Web Express, che ora funziona abbastanza bene con CSS e JS. Questi progetti Web fittizi daranno ai progettisti la possibilità di inserire alcuni controlli, quindi Visualizza sorgente per vedere come vengono visualizzati.

4) Spiegare come viene utilizzato il tag FORM in .NET . Dimenticato questo prima, ma un'altra cosa a cui il designer deve abituarsi è che di solito un singolo tag FORM avvolge l'intera pagina. Ciò altera il comportamento dei controlli del modulo e non è possibile nidificare i tag FORM senza effetti collaterali davvero strani. Assicurati che i progettisti comprendano questo oppure il loro modulo HTML sarà un incubo da trasformare in WebForms.

5) Stai lontano da temi e skin . Anche se il framework .NET ha questi strumenti per aiutare i controlli di stile in un'applicazione, sono goffi e strani per i normali Web designer e non li ho mai trovati degni del mio tempo. Sembrano uno strumento piacevole per gli sviluppatori che non sono esperti di CSS, ma rallenteranno solo i designer. Lascia che i designer lavorino nel loro ambiente naturale (file html e css) e saranno più felici e più produttivi.

6) Mantenere progetti "prototipo" nelle soluzioni del sito . Per assicurarsi che gli sviluppatori abbiano sempre un obiettivo su cui codificare, chiedi ai progettisti di creare un falso progetto Web nella tua vera soluzione per mantenere le loro pagine solo ASPX preservate e non toccate dai veri sviluppatori. Ciò significa che i progettisti possono guardare indietro ai loro prototipi nella stessa soluzione del progetto reale per verificare come hanno fatto gli sviluppatori, e gli sviluppatori possono eseguire il prototipo in qualsiasi momento per assicurarsi che il loro lavoro corrisponda alle intenzioni dei progettisti.

Infine, resisti a qualsiasi reclamo da convertire in MVC, a meno che tu non sia pronto a riqualificare i tuoi sviluppatori. Adoro MVC personalmente, ma se hai una squadra con un sacco di conoscenza di WebForms, non andare via senza motivo. Se le tue applicazioni presentano problemi ViewState, SEO o problemi di accessibilità, dai un'occhiata a MVC. Ma ci vorrà MOLTO più tempo per addestrare gli sviluppatori WebForms su MVC che non per addestrare i progettisti su come utilizzare i controlli Web.

Alla fine della giornata, NON C'ERA NESSUN DESIGN CHE SONO STATO ATTRAVERSO, che non potrei fare personalmente lavoro in WebForms, anche se ho finito per imprecare su quel maledetto GridView per un'ora prima di capirlo.

Esistono strumenti o applicazioni per fornire ai designer il rendering (pagina html) delle pagine .aspx?

Dimentica l'espressione (non mi è mai piaciuta). Ottieni loro la versione gratuita di Visual Studio (Web Developer Express). Può collegarsi a qualsiasi soluzione di controllo del codice sorgente e consentirà ai progettisti di eseguire le loro pagine ASPX e visualizzare l'HTML renderizzato in un browser. Gli strumenti CSS e JS sono molto meglio di prima, e ci sono alcuni fantastici strumenti integrati in estensioni come Web Essentials. Trasformazione in un clic delle regole CSS in tutte le loro deviazioni, selettori di colori e tavolozze specifiche del fornitore direttamente nell'interfaccia VS, incorporamento in 1 clic di immagini in file CSS, trasformazioni CSS "MENO" (puoi "codificare" in CSS), F12 "Naviga verso" su JavaScript, oltre alla vera intelligenza e molto altro. È un vero tesoro per i designer ora, FYI,


3
La tua ultima linea ... Quindi la soluzione a lungo termine è semplicemente soffrire e adattarsi, piuttosto che risolvere la causa principale? (dove la causa principale sta trattando un'applicazione web come se fosse un'applicazione desktop)
Earlz

3
@Earlz - Può avere senso per il business se hai uno staff di dipendenti dello sviluppo che non hanno la larghezza di banda per raccogliere un nuovo paradigma (MVC) solo perché 1-2 altri progettisti non vogliono adattarsi a WebForms. Ti sto dicendo, NON è così difficile per un designer adattarsi a WebForms, se sono disposti a lasciar andare alcune cose (semantica tra ID e classe, controllo preciso sui tag delle etichette, ecc.). Guarda, io stesso ero quel designer che si lamentava costantemente del markup .NET fino a quando non mi sono reso conto che (a meno che tu non sia nel gioco SEO) la fonte html REALMENTE NON È IMPORTANTE. Mi dispiace, ma è vero.
Graham,

1
@Earlz: la causa principale è che i progettisti non possono effettivamente lavorare sul supporto. Fornire loro di lavorare nel mezzo è probabilmente la soluzione di maggior successo là fuori a lungo termine.
Wyatt Barnett,

3
Per non parlare anche del fatto che un Designer a volte costa meno all'ora di uno sviluppatore, quindi un Designer a $ 30ph sarebbe meglio cambiare qualcosa di uno sviluppatore a $ 60ph cambiando qualcosa perché il designer è un matto per questo.
TheMonkeyMan,

La mia prima taglia vinta, woot!
Graham,

8

C'è una soluzione ai tuoi problemi ma comporta una modifica del modello di progettazione a MVP . Si tratta di un investimento iniziale di tempo che richiede una seria considerazione prima di iniziare.

Fondamentalmente, i problemi che riscontri non sono nuovi. In breve, è necessario introdurre un'astrazione della vista tramite l'interfaccia che identifichi il modello di dati supportato dalla vista.

È un argomento molto completo che ha senso vedere lo schema come un esempio di vita. Troveresti questo esempio piuttosto informativo per il tuo caso: i migliori moduli Web con il modello MVP .

Modifica: se il suggerimento sopra è troppo costoso (in termini di tempo e risorse) da seguire, consiglierei sicuramente di lavorare con il tuo designer più vicino . Credo che comunicare i tuoi problemi all'interno di un team dovrebbe aiutare notevolmente a risolvere gli impedimenti nel tuo lavoro (progettista e sviluppatore). Questo è un lavoro di gruppo e una buona collaborazione di problemi per rimuovere tutti gli ostacoli all'esecuzione del lavoro è il modo per avere successo in un progetto come squadra ! Questo è qualcosa che facciamo nel nostro progetto.


1
+1: Questa è una soluzione decente dati i vincoli del problema (ASP.NET Webforms), ma come fai notare, questo può essere molto costoso perché richiede molta disciplina e tempo (il che implica denaro). Direi che se l'OP è interessato a una soluzione all-inclusive, dovrebbe prendere in considerazione la possibilità di passare ad ASP.NET MVC (anziché a Webforms MVP). Il PO trarrebbe molti altri vantaggi come TTM e fidelizzazione degli sviluppatori oltre a una migliore comunicazione con il progettista.
Jim G.

6

ASP.NET è un framework che estrae il codice HTML generato. Ciò significa che non è possibile che venga richiesto di riprodurre esattamente un determinato codice HTML in un'applicazione ASP.NET, a meno che non si disponga di budget sufficiente per riscrivere qualsiasi cosa generata dai controlli ASP.NET .

Spetterebbe agli stakeholder decidere: o utilizzare i controlli ASP.NET con i loro punti di forza e svantaggi, o passare all'HTML manuale (o ad ASP.NET MVC), aumentando il costo del progetto corrente di migliaia di dollari .

L'incapacità di personalizzare l'HTML in questo contesto è un vincolo come qualsiasi altro. I progettisti dovrebbero considerare questo vincolo tecnico nel loro lavoro. Il caso è molto simile a se il progettista ti dicesse che un testo dovrebbe essere visualizzato nel carattere esatto con dimensioni esatte: è un supporto web, non stampa, il che significa che le dimensioni del testo varieranno.

Per quanto riguarda gli strumenti, non sono a conoscenza degli strumenti che convertiranno il semplice HTML in un modello ASP.NET. Come potrebbe indovinare che una tabella specifica debba essere convertita in un controllo ASP.NET specifico?


1
+1 per la segnalazione spetta allo stakeholder decidere. Una volta che il firmatario della busta paga ha preso la sua decisione, tutti gli altri devono mettersi in linea con esso.

Non lo dirò troppo forte, ma penso che altri framework siano più flessibili. Secondo me l'incapacità di personalizzare (facilmente) l'HTML è una ragione sufficiente per iniziare a pensare di passare a un altro framework (come le rotaie).
ostroon,

6

Nel mio ultimo lavoro, gli sviluppatori avrebbero creato l'applicazione e poi l'avrebbero passata ai progettisti in modo che potessero farla sembrare un gruppo di programmatori di software che non ce la facevano. :)

Quando abbiamo iniziato questo processo, c'erano molti avanti e indietro tra sviluppatori e designer. Non capivano le pagine che venivano date. Il cielo proibirebbe se stessimo costruendo una pagina in modo dinamico! Era molto simile alla situazione che stai descrivendo qui.

Mi sono seduto con ogni designer e ho insegnato loro come installare l'applicazione web sulla loro casella locale. Ho mostrato loro come eseguirlo e tutto il resto. Ho spiegato come venivano visualizzati i controlli asp sullo schermo. E poi l'abbiamo aperto nel browser e abbiamo usato firebug per vedere il collegamento tra i controlli asp e ciò che è stato reso.

Questo li ha aiutati molto. Una volta che hanno potuto vederlo ed eseguirlo sulle loro scatole e utilizzare i loro strumenti di progettazione per modificare e giocare con gli stili, ha reso le loro vite più facili.

Dopo averlo fatto, ho avuto un incontro con gli sviluppatori e ho fatto loro sapere che avrebbero dovuto usare il tag CssClass e assicurarsi che gli stili fossero definiti. E tutto ciò che è stato messo sullo schermo in modo dinamico deve avere una classe css collegata ad esso in b / c che i progettisti non sarebbero in grado di aggiungere.

È stato un processo. Ci è voluto del tempo per entrambe le parti per abituarsi all'accordo. Ma ha aperto le linee di comunicazione. Invece di lamentarsi dei controlli utilizzati, i progettisti sono stati in grado di richiedere che gli stili fossero aggiunti a vari elementi.

Quindi il mio suggerimento sarebbe di sedermi con i designer e mostrare loro come viene visualizzata la pagina. Usa firebug per sezionare la pagina e passare attraverso il modo in cui la pagina è formata.


4

Ecco alcuni approcci utili che ho adottato in passato con i progettisti quando devono lavorare su un progetto ASP.NET WebForms in fase di sviluppo.

  1. Distribuisci localmente: gli sviluppatori forniscono una versione intermedia del progetto distribuito localmente. Ciò consente di risparmiare tempo per entrambi. Il designer richiede un aspx ma interagisce con l'HTML renderizzato anziché con il codice del server. Questo approccio estrae il codice del server dal progettista. Non ha bisogno di sapere come viene generato l'HTML o come i file javscript e cssvengono consegnati al client. Questo ovviamente presuppone che i progettisti siano esperti con i debugger del browser / ispettore DOM. Il designer può applicare tutte le sue cssmodifiche all'interno del browser e successivamente applicarle ai cssfile.
  2. Fornire modelli: per rendere più sensato che i progettisti lavorino con HTML, fornire loro un modello dell'HTML reso dal controllo del server. Possono modificare quel codice HTML al punto in cui gli piace e proporre le modifiche da applicare nell'implementazione lato server. Questo deve essere fatto presto e spesso , perché non si desidera finire con una struttura HTML su cui si basa l'implementazione lato client e quindi per il progettista di proporre modifiche su quella struttura.

In generale, i progettisti dovrebbero avere il minor numero possibile di punti di contatto con il codice lato server, quindi allontanalo il più possibile da loro.


2

Come sviluppatore ibrido, io stesso (avendo svolto molto lavoro sia in ruoli back-end che front-end, spesso insieme), ho una antipatia di vecchia data anche per il modello ASP.NET WebForms ... mentre è iniziale l'impulso progettuale consisteva nel fornire strumenti di progettazione facili da trascinare e rilasciare per democratizzare lo sviluppo web (allo stesso modo in cui Visual Basic rendeva la programmazione delle app accessibile al non CS-major), i metodi utilizzati per provare a forzare lo stato su un gli ambienti senza stato (il web) sono forzati e forzati (oh ViewState, come ti odio!).

Inoltre, violano alcuni dei principi fondamentali dello sviluppo e dello stile del markup, proprio per il fatto che, per impostazione predefinita, ASP.NET assume l'attributo ID, costringendo i progettisti CSS a utilizzare le classi nello stesso modo in cui gli ID dovevano essere utilizzati, elementi di stratificazione in profonde pile di div e tag nidificati che possono rendere lo styling dei controlli un incubo in tutti i sistemi tranne quelli più semplicistici.

Date queste cose, il tuo percorso non è facile, dato che presumo che una riscrittura per MVC sarebbe proibitiva in termini di costi o tempo.

Esiste un modo per fornire al designer un ambiente in cui eseguire l'applicazione Web, in modo che possano vedere le modifiche CSS in tempo reale? Quando eseguo lavori di progettazione in ASP.NET WebForms, trovo inestimabile essere in grado di avviare l'app Web sul mio computer, apportare modifiche al CSS ed eseguirlo localmente per vedere come influisce sull'app.

Un'opzione potrebbe essere quella di impostare una macchina virtuale su misura specificamente per lo sviluppo ASP.NET che il progettista può eseguire dalla propria workstation, quindi non devono mescolare i loro due set di strumenti e se capita di rovinare qualcosa nel dev- spazio, può sempre essere ricaricato da un'immagine funzionante.

Sì, questo significa che il designer dovrà imparare a premere F5 per eseguire l'app. (O semplicemente concedi loro l'accesso all'FTP alle directory in cui CSS, JS e immagini sono, persino, in un ambiente di test!) Significa anche che vedranno un sacco di codice di back-end, anche se se gli dici di ignora solo i tuoi file .cs o .vb, che faranno molto per impedirgli di andare nel panico ... Naturalmente, ciò significa che devi essere sicuro che non stai facendo cose come impostare gli stili dai tuoi file codebehind .. (ma non lo faresti, legheresti i dati e li visualizzerai troppo da vicino, giusto?).

Se il tuo sito è ben strutturato, con distinti file CSS e JS e non molto stile in linea forzato sul markup, è possibile che possano svolgere la maggior parte del loro lavoro semplicemente evitando loro le aree <%%>. D'altra parte, potrebbe anche dare al designer un po 'più di apprezzamento per quello che devi passare, quando cerca di tradurre il loro HTML / CSS statico in qualcosa che funzioni per un'app dinamica.


Per vedere le modifiche CSS in tempo reale, utilizzo Firebug. Funziona ovunque ... Probabilmente potresti anche usare Spidermonkey poiché Firebug tende a non ricordare le tue modifiche su diverse pagine
Earlz

Stavo supponendo che qualsiasi sviluppatore web che valesse la pena (anche quelli che funzionano solo con HTML e CSS statici) avrebbe usato qualcosa come Firebug, ma questo è un buon punto da considerare ... accoppiare Firebug (o persino la finestra Developer di Chrome) con l'accesso a un server di prova o eseguendolo localmente e utilizzando Firebug in aggiunta, crea la cosa più vicina a un ambiente "ideale" per abituare un progettista alle modifiche che devono apportare ai siti dinamici.
Jason M. Batchelor l'

1

Devi farli parlare insieme, capire gli altri bisogni e preferenze. È un "problema" che non può essere risolto da software e strumenti. Non cercare di compiacere entrambe le parti, non funzionerà mai. Devono scendere a compromessi - è come un matrimonio.

Un modo è organizzare f.ex. seminari in cui ciascuna delle parti ha la possibilità di spiegare perché è così che preferiscono ciò che preferiscono. Una buona comunicazione è sempre la chiave in situazioni come questa. Raccogliere come questi può essere visto come un investimento.

O semplicemente detto, il problema è orientato all'organizzazione, non tecnico ed è qui che devi fornire una soluzione.

L'altra opzione è aumentare la retribuzione e dire loro di stare zitti (di solito una soluzione a breve termine ...).


Ultima riga = scherzo
epistemex,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.