En CMS-byggers weekend!!!

Jeg er en del af CloudSprout, som er ved at udvikle en et forhåbentligt revolutionerende CMS! Grund ideen er at vi ville gøre det sådan, at man kan springe programmøren over, når der skal laves professionelle websites. I kort træk betyder det at de sites der i dag bliver lavet i Joomla, Umbraco, Magento etc. Af teknikere, i fremtiden skal kunne laves i CloudSprout.

Nu har jeg siddet og arbejdet hele weekend (ja i hvert fald i dagtimerne), men i stedet for bare at være tilfreds med min egen indsats, så har jeg lavet en lille video, der viser værket, så håber jeg du vil komme med noget konstruktiv feedback.

Du kan se den her: http://www.cloudsprout.dk/videoer/WeekendWork.html (Videoen varer under 5 min.)

Hvad synes du ser det ud til at vi er på rettet vej?

Lundsby:

 I kort træk betyder det at de sites der i dag bliver lavet i Joomla, Umbraco, Magento etc. Af teknikere, i fremtiden skal kunne laves i CloudSprout

Hej Lundsby,

Det lyder jo fantastisk - men du tror ikke det er en smule urealistisk eller i det mindste markedsført markant over målet?

Hvis du mener selve design delen så kan du jo bare hente artisteer til Joomla det koster vist en 40-50 dollars så kan du lave en færdig grafisk joomla website på 5 minutter.

Men hvis du mener alt funktionaliteten så er det vel nok en anelse skudt over målet at at du mener at CloudSprout, som pt. ligner en ny form for frontpage eller dreamweaver, skal kunne udkonkurrer alene 4700+ funktionalitetsudvidelser til Joomla, for slet ikke at nævne resten af systemerne.

Hele pointen, med Joomla er vel at hvis ens funktionalitetsbehov er så simple som det kan der kan opfyldes i jeres demovideoer så kan de fleste jo sagtens gøre det selv i forvejen - det er jo først når man har behov for at lave en masse ekstra funktionalitet at der skal nogle programmører til - og nu så jeg da jeres demo i onsdags hvor jeg også selv var ude og præsentere redSHOP her i Odense og der var der da lagt op til at man selv kunne programmere nye "widgets" eller ekstra funktionalitetsudvidelser - præcist som i alle andre systemer skal man altså programmere sig til det der ligger ud over dreamweaver / frontpage / artisteer osv.

Men du mener måske at i vil programmere  10.000 forskellige små widgets i systemet som folk så kan tegne i photoshop og sidde og trække egenskaber og funktionalitet ned på (hey vent - er det ikke sådan flere visuelle udviklingsværktøjer fungere i forvejen?).

Jeg synes det var meget interessresant at se jeres præsentation af jeres system lige som vi har valgt at gå i en bestemt retning ved at fokusere på massive værktøjer til markedsføring og funktionalitet indbygget i vores system så er det da også forfriskende nok at i går sådan en visuel vej - men jeg tror nu aldrig vi nogensinde kommer til at konkurrer om de samme kunder.

Hej Allan

Tusing tak, for opbakningen, fedt at du kan se perspektivet!

Den html der genereres idag, bliver lavet med adskilt markup og style, den er enligt okay pæn, men vi har nogle grimme id og klassenavn som vi skal havde luvet ud i. Jeg tror næsten det validerer, det har vi ikke gået så meget op i, men inden vi ud af beta er det 100% validt.

Ronnikc > Jeg mener ikke der er nogen grund til at hverken programmører, cms leverandører eller andre bør være bange for at miste arbejde pga. dette produkt.

Jeg har fulgt en del med på sidelinien, og det er da ganske interessant, men målgruppen er efter min mening en helt anden. Skulle man tage udgangspunkt i de fleste webløsninger jeg selv har programmeret på, så er den del der hedder html/slicing og integration til CMS (som dette værktøj erstatter / forbedrer), en meget lille del af budgettet.

Der er selvfølgelig CMS'er derude, som gør at integrationsprocessen af unikke designs kan blive en dyr fornøjelse, der er også programmører og webdesignere der ikke er særligt effektive, hvilket gør at udarbejdelse af slicing og html/css tager meget tid og bliver dyrt. Men der er allerede værktøjer og arbejdsprocesser på markedet, som gør at dette oftest er en lille post i det samlede web-udviklingsbudget (ihvertfald hos os og mange af de kolleger jeg er i dialog med i CMS og webdesign-branchen).

Den seneste webløsning jeg eksempelvis lavede et tilbud til her i weekenden, løb op i omkring kr. 25.000,- ex moms, hvoraf 2.200,- gik til html/css + integration til CMS. Vel at mærke for et unikt design og diverse markedsførings bistand. Det skyldes at det i vores CMS (og mange andre), kan integreres og bygges op ganske hurtigt.

Det var en lidt længere historie, men når alt kommer til alt, så er det her helt sikkert at fedt værktøj til webbureauer, grafiske bureauer og grafisk designere, som ikke lige har supergodt styr på det med integration til CMS eller ikke er særligt gode til at udarbejde html/css.

Som jeg ser appellerer systemet til grafikere og er en fordel for disse, men for slutkunden og på bundlinien rent økonomisk, er ser jeg ingen synderlige besparelser i budgettet, kontra de effektive CMS'er hvor det er nemt at integrere designs i.

Hej Ronni

Ronnikc:

Det lyder jo fantastisk - men du tror ikke det er en smule urealistisk eller i det mindste markedsført markant over målet?

Jo, sådan tænkte jeg også i starten, men efterhånden som vi er begyndt at lade kunder arbejde med systemet, er utroligt hvor ekstremt få tilfælde der var behov for ekstra funktionalitet. Men de tilfælde hvor der er skal vi selvfølgeligt også kunne løse.

Så der kommer også en extension markedsplads og samt mulighed for at programmere udvidelser til systemet. Her har jeg blandt andet kigget på Joomlas markedsplads, for inspiration!

I forhold til Joomla, får vi en række fordele. I mine og mange andres øjne er et af Joomla's helt store problemer, at man kun kan skrive udvidelser til det i PHP. Jeg og mange andre gider simplethen ikke lærer PHP, der er rigtigt mange andre sprog og platforme som er langt mere spændende. Det er nok også en medvirkende årsag til at selvom Joomla har flest extension, så er der "kun" ca. 5000 Joomla extensions, mens der er en 500.000 facebook applikationer.
I forhold til Joomla's infrastruktur extensions imellem, er vores væsentligt mere kraftfuld, hvilket betyder at de forskellige extensions i højere grad kan sættes mere fleksibelt sammen, det er lidt teknisk at forklarer, men konsekvens er, at platformens funktionalitetsrum bliver meget større pr. extension.
Når man skriver extensions til vores platform, så beskriver man ikke hvordan den opleves! Det gøres senere af designeren, der skal bruge den. Det bliver igen lidt teknisk, men det betyder reelt set at udvikleren skal lave mindre arbejde og at designeren kan få lov, at gøre det han er bedst til.

Tilgengæld har Joomla den fordel at deres markedsplads eksisterer :-)

Jeg ved ikke om vi kommer til at konkurrere om de samme kunder, men med det design-forløb jeg har været igennem, er det blevet tydeligt for mig, at den måde vi bygger dynamiske websites på snart bliver forældet. Det er helt klart at programmørens rolle i rigtigt mange tilfælde er unødvendig eller kan commodiseres.

Det der kommer til at ske, er lidt det samme som der skete for typografer, der DTP kom.

Spørgsmålet er vel egentlig også hvorvidt det er programmøren dette produkt sparer på. Det er nok nærmere grafikerens / web-integratorens tid der spares her, da ingen programmør med respekt for sig selv sidder og laver slices, html/css osv. medmindre de prygles til det.

Og nu har slicing, html og css jo heller ikke noget med programmering at gøre, så det giver jo meget god mening :) For de programmører der sidder derude og laver den slags, så tror jeg nok de vil være lykkelige for at slippe for den slags.

Hvis et CMS kræver en programmør for at få et givent unikt design til at virke, så er der enten noget fundamentalt galt med CMS'et :)
Men så er der selvfølgelig altid alle de dynamiske ting som SKAL programmeres uanset hvad, der kommer programmøren selvfølgelig ind i billedet, for jeg formoder ikke at man med CloudSprout kan lave et amino-site i photoshop og så dragNdrop lidt og så kører det?

Jeg tror helt sikkert at CloudSprout bør markedsføre sig til grafikere og små web-bureauer som ikke nødvendigvis er så stærke i disse integrations opgaver som jeg nævner tidligere.

Hej Lars

Det du ser på videoen er kun en meget lille del af det samlede produkt, men det der sker når man bygger sites i CloudSprout, er at man også designer selve datamodellen og opsætter funktionaliteten.

For de kunderne vi har bygget sites til på systemet, er mængden af udviklertimer ekstremt reduceret, på størstedelen var der slet ikke nogen.
En meget spændende ting, vi opdagede var at nogen af kunderne selv efter sitet var færdigt. Begyndte at checke Google Analytics og blive ved med at optimerer deres sites. Det bliver rigtigt spændende, når vi får implementeret A/B splittest, så bliver der rigtigt noget at arbejde med :-)

Hvis du har lyst kan du se et lille interview med Martin Moos her: http://www.cloudsprout.dk/Eksempler/Designere/Interview+med+Martin+Moos.html (ca. 30 min. men loader langtsomt)

Det er slet ikke utænkeligt, at lave et forum som Amino med CloudSprout. Faktisk var vi for lidt siden igang med at lave en job-portal med det, men kunden blev nødt til at stoppe projektet. Det giver en masse fleksibilitet, som kunden kan trække på uden at involverer udviklere.

Men det kan ikke lade sig gøre 100% uden programmør, medmindre man kan finde en eksisterende extension. Selvom man skal involverer en programmør, så bliver hans arbejde meget mindre, fordi han ikke skal beskæftige sig med oplevelsen, det er nærmest kun forretningslogikken, der skal kodes.
Det jeg tror kommer til at ske, er at extension og færdige applikationer, i høj grad vil overtage markedet for konsulent-ydelser på platformen.

Hvis du har lyst kan du hører en længere smøre om CloudSprout her http://www.builder.dk/post/cloudsprout.aspx (ca. 1 time varighed, men alt tiden værd!)