Vi vil revolutionere webbranchen (Skyd på vores ide)

Har i overvejet integration til de forskellige template systemet. Altsaa Velocity/Freemaker for java, og smarty for php?

Saadan som mit firma laver websites nu saa er processon at en grafiker laver et design i photoshop. Dette bliver saa oversat til en html template, som bare en et html dokument hvor variable markeret der hvor teksten skal indsaettes. Saa det ligner noget ala

$stdHeader('My webpage','some meta tags'); #Call macro to insert standard header

<div style='float:left'>
<img src='images/logo.png'>
<div class='mainText'>$mainText</div>
<div>$topTenList</div>
</div>

$insertFooter()

Paa den maade har vi saa total seperaret teksten fra html saa vi kan lave multi sprog websites uden at aendre htmlen. Samtidig kan vi koere med samme header/footer uden at gentage den paa alle siderne(Vigtigt!!).

Samtidig giver dette mulighed for at vores backend dynamisk kan generer html(Saa som vores $topTenList) hvis det er noedvendigt at genererer html dynamisk fordi htmlen ser forskellig ud alt efter hvordan data ser ud.

Det jeg virkelig savner, er et tool saaledes at vores grafiker kan lave html templates, som han saa bare giver mig, saa jeg bare skal lave min java backend selv :}

Saa mit raad til jer er at dele programmet op i 2 dele, hvor den ene del er selve grafik editerings delen som saa skal have support for at integrerer med diverse html template systemer. Og saa en anden del hvor i selv tilbyder diverse server baserede komponenter, saa man kan lave dynamiske websites.

Har i overvejet hvordan disse websites skal integreres med dynamiske systemer, eller er systemet primaert designet til at haandtere statiske websites?

ps: Hvordan haandtere jeres loesning websites med dynamisk bredde. Proev for eksempel at se http://www.molanta.com hvor den samme html kan ses baade paa en mobil telefon og i en browser. Dette er 'bare' lavet ved brug af en max-width:600px; men jeg syntes stadig det er en rigtigt god loesnig fordi man saa faar et websites som virker ordentligt baade paa en mobil og i en computer browser.

Lundsby:

Vi lavede for snart et par måneder siden, nogle forsøg på at bygge en jobportal, via løsningen. Og de egentligt rigtigt godt, det er ret sej fornemmelse bygge en jobportal via drag-n-drop. Men idag, har vi egentligt ikke nogle specielle planner om f.eks. at blive en god blogging platform. I starten fokuserer vi på firmasites og webshops.

Det kan være lidt farligt. I har valgt at fokusere på dem der laver websitet/shoppen, men at ignorere den besøgende kan være farligt i længden. Det er fint hvis jeres ambitioner er "Slagter Jørgen og hans gode tilbud", men jeg har en mistanke om at I sigter noget højere.

Sitecore har fx. selv siddet i saksen (i hvert fald for et par år tilbage). Problemet var hvordan hele deres arkitektur er bygget op. De bruger meget metadata og har derfor en del database kald. De anvender derfor rigtig mange lag caching for at få (en ret god) performance.

Problemet kom så bare da internettet ikke længere handlede om at en person delte ting med omverdenen, men omverdenen begyndte at skrive tilbage til sitets ejere (via kommentarer på blogs, i fora og diverse smarte web 2.0 tiltag). Sitecore var en publiseringsmotor som skalerede (og skalerer) ud over flere servere. Men hvad sker der når der bliver oprettet en kommentar på een server og cachen på de andre servere ikke tømmes?!

Jeg har ikke arbejdet med SItecore det seneste år, så jeg ved faktisk ikke rigtigt hvad denne endte med (jeg er ret sikker på at de fik løst det, de er jo ret kloge hoveder), men det illustrerer min pointe udemærket. Web 2.0 og brugergenereret indhold kan ikke negligeres. For hvad sker der når Slagter Jørgen pludselig hører at man også skal have en blog?! Nåh... men jeg ved i knokler med det, så I har sikkert tænkt på dette

Og til alle jer ikke udviklere, sorry det lige kammede lidt over med snak om caching og anden sort kode snak....

Sådan som jeg forstår dig, så er det unikke ved jeres system, at det er nemmere og hurtigere for designere at bruge end eksisterende systemer, og specielt at designere kan få det som de vil have det, uden at skulle involvere programmører.

Eftersom jeres målgruppe er designere, vil jeres kunder typisk være mindre reklamebureauer, der ikke har råd til egne programmører, og de skal så sælge jeres produkt videre til deres SMV kunder (dvs. at produktet skal have en ekstremt brugervenlig CMS-del). Eller alternativt kan I starte jeres eget bureau, og selv servicere SMV-kunder.

Jeg tror, det er meget vigtigt, at I holder fast i, at det er dér, jeres forretning skal komme fra. Der er meget stor forskel på at sælge til et bureau, og så at sælge direkte til en SMV, hvor løsningen skal være betydeligt mere brugervenlig og enkel. Skal I sælge til SMV'ere direkte, så skal I kigge på eksempelvis sitebuilder; og udvikle et system, der matcher det i brugervenlighed og enkelhed. Dermed vil der også komme så mange begrænsninger ind, at systemet ikke samtidig kan bruges til designere. Det er den trade-off, der er nødvendig, hvis man vil have fat i helt almindelige ikke-ekspert-brugere. Så det mener jeg, I har fravalgt allerede, gennem jeres fokus på designeren.

Med fokus på designere og reklamebureauer vil relevante spørgsmål være:

Hvad får vi som bureau i avance ved at sælge systemet?

Er CMS-systemet nemt at bruge for slutkunden (dvs. hvor mange support-opkald kan vi forvente at få?)

Kan vi lave designet præcis, som vi vil have det?

Hvilke ekstra features har vi som standard - integration med google-maps, bestillingsblanketter, betaling med dankort osv?

Hvad koster ekstra features, der ikke er standard - hvis kunden vil have en helt speciel feature, hvad skal I så have for at udvikle det?

Hvorfor skulle vi overhovedet gide at sætte os ind i jeres system, i stedet for at holde os til det, vi kender og ved, virker?

Pas på, at I ikke fortaber jer i teknikaliteterne og glemmer, at der er mange andre hensyn, der i sidste ende kan være udslagsgivende for, om et bureau køber jeres løsning.

Glædelig jul

Kristian

Hej Rasmus

Vi har også en del lag caching i vores system, og ligner på mange måder SiteCore rent teknisk. Den store forskel mellem os, er at vi fokuserer på designere, mens SiteCore vil være udviklerens bedste ven. Faktisk lavede jeg den første version af vores system nogenlunde samtidigt med SiteCore omkring 1998.

Mht. SiteCores skaleringen, af brugergeneret indhold, så mener jeg umiddelbart at det kan løses med en CacheDependency, men det er er også noget tid siden, jeg har arbejdet med SiteCore. Mener også samme teknik, virker på en Sharepoint. I vores arkitektur, løses problemet via en intern event model.

Rasmus Lindgren:

Det kan være lidt farligt. I har valgt at fokusere på dem der laver websitet/shoppen, men at ignorere den besøgende kan være farligt i længden. Det er fint hvis jeres ambitioner er "Slagter Jørgen og hans gode tilbud", men jeg har en mistanke om at I sigter noget højere.

 Umiddelbart, så mener vi at de websites man kan lave med systemet, skal være nok til at opfylde de gængse virksomheder i størrelse 0-50 ansatte måtte havde.

Rasmus Lindgren:

For hvad sker der når Slagter Jørgen pludselig hører at man også skal have en blog?! Nåh... men jeg ved i knokler med det, så I har sikkert tænkt på dette

Det har du helt ret i, vi mener helt klart at brugergenereret indhold, blogs etc. er enormt vigtige. Vi kan bare se, at der pt. er en masse ting, på opgave listen, som vi mener er vigtigere. Så Slagter Jørgen, kan godt for sin blog på CloudSprout, men han må være tålmodig.

Kristian Melchior Echwald:

Sådan som jeg forstår dig, så er det unikke ved jeres system, at det er nemmere og hurtigere for designere at bruge end eksisterende systemer, og specielt at designere kan få det som de vil have det, uden at skulle involvere programmører.

Det er fuldstændigt korrekt :-)

Kristian Melchior Echwald:

Eftersom jeres målgruppe er designere, vil jeres kunder typisk være mindre reklamebureauer, der ikke har råd til egne programmører, og de skal så sælge jeres produkt videre til deres SMV kunder (dvs. at produktet skal have en ekstremt brugervenlig CMS-del). Eller alternativt kan I starte jeres eget bureau, og selv servicere SMV-kunder.

Kristian Melchior Echwald:

Det er den trade-off, der er nødvendig, hvis man vil have fat i helt almindelige ikke-ekspert-brugere. Så det mener jeg, I har fravalgt allerede, gennem jeres fokus på designeren

Kristian Melchior Echwald:

Hvad får vi som bureau i avance ved at sælge systemet?

Ingenting, systemet kommer til at koste omkring 20$-30$ pr. måned., hvilket er så lidt at der ikke er noget at give provision af. Grunden til at prisen er så lav, er at det er væsentligt at vi prismæssigt er konkurrence dygtige med Open Source systemer.
Så det primære incitament for at en designer, skal sælge en CloudSprout, er at få lov at lave timerne. Men man skal heller ikke sælge mange timer, før 20-30$ pr. måned virker irrelevant. Alternativt, kan man som designer, selv købe løsningen af os, og så videre fakturerer kunden.

Kristian Melchior Echwald:

Er CMS-systemet nemt at bruge for slutkunden (dvs. hvor mange support-opkald kan vi forvente at få?)

Det er rimeligt nemt at bruge, med udgangspunkt i produktetslave pris, tager vi ikke et support ansvar! Og anbefaler vi heller ikke vores designere gør, i stedet må supporten enten afregnes på timer eller efter aftale.

Kristian Melchior Echwald:

Hvilke ekstra features har vi som standard - integration med google-maps, bestillingsblanketter, betaling med dankort osv?

Betaling med Dankort kan vi klare idag, jeg mener også der er nogle der har brugt Googlemaps, i systemet.

Kristian Melchior Echwald:

Kan vi lave designet præcis, som vi vil have det?

Det helt klart vores ambition! De referencer, jeg nævnte oprindeligt er alle designet uden hensyntagen til systemet. Så vi synes selv, vi er godt på vej.

Kristian Melchior Echwald:

Hvad koster ekstra features, der ikke er standard - hvis kunden vil have en helt speciel feature, hvad skal I så have for at udvikle det?

Vi har tænkt os, at åbne vores API, så eksterne udviklere kan udvide systemet. Ideen er også at der skal bygges en markedsplads a la AppStore, så man slipper for at skulle købe så mange kosulenttimer.

Kristian Melchior Echwald:

Hvorfor skulle vi overhovedet gide at sætte os ind i jeres system, i stedet for at holde os til det, vi kender og ved, virker?

Salgargumenterne er kort: fuld kontrol det kreative værk, salg af flere timer, bedre time-to-market, ingen behov for programmører, potentielt lavere omkostninger for slutkunden.

Kristian Melchior Echwald:

Pas på, at I ikke fortaber jer i teknikaliteterne og glemmer, at der er mange andre hensyn, der i sidste ende kan være udslagsgivende for, om et bureau køber jeres løsning.

Vi er rigtigt heldige der, vi bor i Schillerhuset i kontorfællesskab, med over 100 kreative! Det er ved at lytte til dem, vi håber at holde os på rette spor.

Kristian Melchior Echwald:

Glædelig jul

I ligemåde og mange tak for dit feedback.

Lyder som et spændende projekt. God vind!
Mvh

For at vende lidt tilbage til SEO-delen, har jeg kigget thecolorclub.net igennem på html-niveau og på en tilfældig side finder jeg det første stykke tekstindhold i linie400+ - det er i hvert tilfælde ikke Googlevenligt.

Jeg prøvede for sjov skyld at Google på et link på siden, og var enddog meget venlig mod thecolorclub jeg søgte på termen "Anti hate crime" og satte udtrykke i gåseøjne som vist her, dermed burde det nemt kunne ranke højt, da det er en ankertekst på thecolorclub.

Efter at have rodet Googlesiderne igennem -  i hvert tilfælde de første 11 sider igennem med forslag -, var der ikke dukket et resultat op fra thecolorclub endnu.

Så der er den tilsyneladende heller ikke SEO-venlig.

Jeg tror at Slagter Finn har et ønske efterfølgende, når han har fået sin flotte grafiske side, at den også er synlig på nettet via organiske søgeresultater.

Men jeg er klar over, at I der står overfor en stor udfordring - og du bad jo selv om at "blive skudt på"

Når det er sagt, vil jeres produkt jo nok kunne sælges til nogle niche-emner, men med mindre der tages særlige hensyn til dynamisk indhold (web 2.0) og SEO-venligt indhold som kan rykke siderne frem på de gode pladser, vil det kun være til firmaer uden særlige krav til en hjemmeside andet end et visitkort på nettet, som de selv kan kigge på, og skrive adressen på deres visitkort.