Dø PSD-til-HTML tjenester DØ! Nu kan designerne selv :-)

Hej Allesammen

Så er jeg nået til video 2 i vores lille serie http://www.cloudsprout.dk/Videoer/OpretSite2.html, her viser jeg hvordan man laver en PSD-fil til et CloudSprout site.

Jeg vil meget gerne høre dit feedback, kan du se videoen, hvad synes du om indholdet og vores produkt ?

Hvis du har lyst til at prøve CloudSprout, så send mig en mail på plu@cloudsprout.dk så sender jeg dig et login indenfor en 14 dages tid. Det er selvfølgeligt 100% at lege og lære med CloudSprout, det er først når man sætter en kundes website live, at det begynder at koste noget.

PS: Du kan se den tidligere video og tilhørende diskussion her http://www.amino.dk/forums/t/103075.aspx?PageIndex=1

Hej Oscar

Tusind tak, for din feedback, jeg nåede lige at sætte linket ind, inden mens jeg stadig fik lov at bruge "Ret", så nu kan du se den.

Mht. mange små billeder, som vi laver har du helt ret i at de hver især giver et http-request. Men hvis vi kommer til at mærke et performance problem, på det så ville der ikke være noget i vejen for at maskinelt sætter billederne sammen og bruger dem som CSS Sprites.
På den længere bane, er jeg overbevist om at det er muligt at maskinelt optimerer css, html etc. bedre maskinelt, end hvad vi mennesker formår.

Det fremgår måske ikke så i de to videoer der indtil videre er lavet, men det man laver er ikke sider, men layout skabeloner, som bruges til at vise alle sider af layout skabelonens type. F.eks. laves et artikel layout, som bruges til at vise alle artikel siderne. Man kan sagtens lave dynamiske effekter hvor etc.

Der er mine øjne meget stor forskel på det vi laver, og de "gamle" html-værktøjer Go-Live, NetFusion etc. vores CloudSprout, er væsentligt mere kraftfuldt, men kommer med en pris, så der er en del mere der skal læres for at man kan bruge CloudSprout end de gamle programmer.

CSS-sprites vil helt klart være en fornuftig vej at gå. Det synes jeg lige så godt i burde overveje allerede nu da det vil være et klart sellingpoint i forhold til de normale slicing metoder.

Der hvor jeg måske bliver i tvivl om hvor meget i kan gøre maskinelt er ting som at benytte rigtige css-borders og baggrundsfarver og lignende i stedet for diverse slicede billeder. Det gælder f.eks. i fleksible designs m.v.

Jeg er slet ikke uening i forhold til maskinel optimering af CSS og html m.v., jeg er måske bare lidt uening i metoden om at starte med et Photoshop dokument i stedet for at bygge en "peg og klik" editor der outputter direkte i html, SVG osv uden at skulle ind over photoshop slicering osv. Jeg forstår dog helt 100% godt hvorfor i er startet ved photoshop for at tage fat i noget de fleste designere allerede kender.

Ved at lægge jer så fast på photoshop som designværktøj som det virker lidt som i gør (igen, ret mig hvis jeg tager fejl, så lang tid har jeg ikke lige kigger jeres ting igennem), så bliver i ret afhængige af at adobe eller andre ikke ender med at bygge en direkte webside "editor" som 100% outputter til HTML, CSS og SVG m.v. Der har været et par spæde forsøg på dette, men der går nok et par år inden der begynder at komme noget interessant.

Hvad jeg måske er lidt i tvivl om er hvor fordelen for mig som designer (jeg har flere hatte på i hverdagen :) er ved at sætte mig ind i jeres værktøj i stedet for selv rent faktisk at lære lidt HTML, CSS og javascript som jeg kan bruge alle steder og som er forholdsvis åbne standarder, med bunker af tutorials og undervisningsmateriale.

Det er nok der min kommentar omkring at kode lidt ligesom i 1999 kommer ind i billedet, for jeg kan huske hvor lang tid jeg brugte på at lære diverse slicing værktøjer, dreamweaver og alt mulig at kende (som skulle gøre mig mere effektiv) og forstå deres metoder og hver eneste gang endte jeg med at lave tingene i hånden fordi det altid endte med at være hurtigere at lære "grundteknikken" og forstå hvad der sker nedeunder motorhjelmen i stedet forat lære et stykke software at kende, som ofte gav mig problemer med at debugge diverse problemer. :-)

Men ok jeg er også lidt farvet af at have været frontend-udvikler siden 1996 og at have set en del rigtig grimme "slicing"-monster-projekter igennem tiden, som ville være faldet så meget bedre ud med en dedikeret frontend-udvikler ved roret i stedet for en designer-reklamemand. Så jeg tillader mig at lade mig provokere lidt af statementet "Nu kan designerne selv" .

1: Er der mulighed for at definere styles, saa man slipper for at saette standard margin, farve, size og lignende paa tekst elementer af samme type? (Hvor typen saa gives af brugeren).

2: Har i nogle almindelig "export to html" funktion.

Det store problem som jeg ser det er at i har 2 helt forskellige produkter, nemlig en html editor, og et cms system. Men i har integreret dem paa en maade der goer at de ikke kan bruges hver for sig.

Jeg kunne muligvis godt bruge selve html editoren hvis den havde support for standard template systemerne saa som Velocity eller Smarty.

Ad 1: Vi har ikke styles som sådan, men vi har noget meget bedre :-) Vi kalder det biblioteks elementer og udskæringer, og i programmeringsverden svarer det mest til usercontroller og masterpages fra ASP.Net.
Grunden til at det i mange tilfælde er bedre end traditionelle styles er at man udover selve det der bliver generet som style også kan genbruge det der bliver generet som markup. Og det er vel og mærket uden, at brugeren nogensinde behøver at vide hvad stil og markup er.
(Jeg laver lige en video om det imorgen)

Ad 2: Det at generer html i sig selv, er for os relativt uinteressant, det spændende er at generer CMS implementationer. Så med CloudSprout kan designere lave det samme som man ellers ville skulle havde en programmør til i f.eks. Joomla eller Umbraco.
F.eks. er http://www.saas-it.net og http://www.thecolorclub.net lavet 100% af designere i CloudSprout, uden at de har skrevet en linie kode. Bagved ligger nøje opsætte CMS implementationer, som gjort det nemt for almindelige brugere er at redigere indholdet. Hvilket der været brug for ColorClub har 1000 sider på 5 sprog.

CloudSprout er ikke bygget til at hjælpe programmører med html, det har vi jo relativt godt styr på i forvejen, nej CloudSprout er til designere, som gerne vil springe programmøren over og leverer hele sitet selv.

Selvfølgeligt skal der stadigt bruges skæddersyet forretningslogik til nogle opgaver, og her kommer man ikke udenom programmører. Men på 9 ud af 10 af de CMS løsninger der levereres kan man sagtens.

Kan det håndtere HTML5, Mootools, Javascript, sIFR etc ?

Ellers ser jeg næsten ikke hvordan det skal kunne bruges fx af undertegnede, der jo må siges at være den primære målgruppe ?

Hej Christian

Jeg er skam super glad for at du reagere!

Du har ganske ret i at der findes ting, som designere ikke kan lave med CloudSprout, men det er faktisk noget færre end man tror, og selvom jeg er arkitekten bag systemet så må jeg da indrømme at jeg nogle gange er blevet overrasket over hvad designerne kan med det.

Mht. funktioner, så har vi idag handels, nyhedsbrev, 50% kontaktformular funktioner, som designerne selv kan bruge. Groft estimeret vil jeg tro at vi pt. har funktionalitet til at dække en 90% af alle websites, men der selvfølgeligt stadig en masse ting, hvor man skal involverer en programmør. Desværre åbner vi først vores API og AppStore i en senere version, men på det tidspunkt vil alle webudviklere relativt nemt skrive en feature til CloudSprout.

Mht. integrationer, så har vi længe understøtte XML import og export, så både som webservice kald, manuel upload fra ftp-sites etc.

Mht. flash er vi en lidt speciel situation, for her er det i princippet muligt at lave udtræk til Flashvars via sproget VTL.

Så nej programmøren bliver ikke arbejdsløs, men der bliver meget mindre af det kedelige opsætningsarbejde. Samtidigt håber jeg også, kommunikationen imellem programmør og designer vil blive meget bedre, fordi designeren i højere grad kan vise programmøren hvad hun mener.