Webkafeen

[Haraldson]

Her er det innholdet som skal presenteres da. Og ifølge kunder så MÅ det se likt ut i editor som på nettsidene.

NSN har en merkverdig 'bend over'-holdning overfor kunden. Visse ting går det an å si til kunden, «sånn er det bare». «Du har begrensninger fordi du ikke skal kunne f*kke designet på siden». «Ønsker du å lage noe med så avansert utseende, må vi lage en dedikert mal til deg».

[Bolson]

Her er det innholdet som skal presenteres da. Og ifølge kunder så MÅ det se likt ut i editor som på nettsidene.

 

Må det se 100 % likt ut. Her er jeg enig med Hein og Arve, det er lov å forklare litt hvorfor verden er og bør være slik den er.

 

Ellers er det etterhvert mange publiseringsløsninger som begynner å få til dette på en god måte, slik at det er svært enkelt for brukere å legge inn og plassere innhold. Direkte på nettsida.

[Steinmann]

Vel, selgerne sitter å selger det!

-

Kommer forøvrig rett fra Electroworld messen.

Ikke dra dit, var veldig dårlig. Ingen tilbud, og veldig mange store var ikke der.

Fikk ikke kjøpt ps3 spill etc engang. Kunn en greie med filmer.

Endret 13. november 2008 av Steinmann

[OlafG]

Om det er et krav at ting skal se 100% likt ut, så kan vel in-place-editing være en tanke?

[Bolson]

Er ikke det typisk selgere, de selger det man har (systemet kan) og så selger de 20 % i tillegg.

 

Er det da ikke bedre å lære opp selgere til ikke å selge noe som ikke fungerer akkurat slik. Jeg tror man får mer fornøyde kunder ved å ikke overselge seg.

 

Så finanskrisen har drept Electroworld også.

 

@OlafG. In-place-/inline editing er sjelden så perfekt at det ser 100 % likt ut, men det nærmer seg svært mye.

Endret 13. november 2008 av Bolson

[Steinmann]

De krever faan meg at settninger skal brytes på samme steder... Ganske hat å jobbe med noen ganger.

Men somregel ser det likt ut i editoren også da.

 

Henrik: Da må man jo skrive noe som tester å sette produktene sammen på x antall måter og velger den mest optimale?

Har du mange produkter i forskjellige størrelser kan de pakkes lurt å få alt inn i en eske for eksempel.

[jorgis]

Det er ingenting som hindrer utviklerne fra å sette krav på hvilke plattformer kunden kjører løsningen deres på, så at dere bruker en kjent plattform in-house er ikke et gyldig argument. Det er heller ikke noe som hindrer dere fra å levere løsningen deres uten samtidig å frigi kildekoden. At kildekoden er levert med applikasjonen (som den må i PHP) er ikke ensbetydende med at kildekoden er fri, det finnes mange PHP-applikasjoner som ikke er fri kildekode. Hele dette forumet kjører på en ufri PHP-basert løsning.

Siden forumet er så fantastisk stabilt, så tenkte du at det var et godt eksempel? Nå tror jeg de aller fleste bedrifter, enten med lock-in-løsninger eller konkurranseutsatte, har langt høyere oppetid enn dette forumet.

 

Shitware er mulig å lage uansett teknisk løsning, forretningsmodell eller lisensforhold. Kanskje et dårlig eksempel med IPB, men poenget mitt var bare å vise at et produkt skrevet i et scriptspråk (eg. et produkt du kan selv se kildekoden til) ikke nødvendigvis må være åpen kildekode.

 

Når det gjelder å levere fra seg kildekoden, er jo det en risiko som med all annen programvare. Om noen har tilgang til alt sammen blir det (nesten) garantert misbrukt.

 

Hva så om det blir misbrukt? Dere leverer et enterprise-produkt, hvor hosting/service/tilpasninger uansett vil utgjøre en helhetlig pakke 99% av deres kunder vil være interessert i å ha. Men det bør være mulig å lage en fleksibel nok løsning til at en kunde som av ulike årsaker ønsker å hoste selv/hos andre kan gjøre dette, og at en kunde kan gjøre nødvendige modifikasjoner selv eller av tredjepart. Dette vil tjene kunden best, men sett fra deres standsted er det nok ikke det mest økonomiske grepet å ta..

 

Det er forøvrig ikke noe problem å vannmerke kildekoden, for å kunne spore den opp "in the wild" og fort finne den som har lekket den.

[qualbeen]

Såklart er det ikke noe likhetstegn mellom utleverte produkter og åpen kildekode. Det er ei heller vanskelig å finne eksepler på "ufri" programvare hvor kildekoden medfølger. Men uansett hvordan man vrir og vender på det, så har man en helt annen kontroll på produktet hvis det aldri forlater husets fire vegger.

 

Men såklart: hvorvidt en slik løsning tjener markedet er jo noe hver enkelt bedrift må vurdere. Og jeg regner med at noen kloke hoder mener dagens forretningsmodel til Keyteq fungerer tåelig greit. Men joda: det er slettes ikke en dårlig idé å levere Keypublisher ut til kunder hvis sitter på kompetanse og ressurser til å håndtere det. Men jeg tviler på at det skjer med det første

 

Vannmerking er kjekt det - men man får ikke gjort annet enn å straffe vedkommende som lekket koden. Når skaden allerede er gjort, hjelper små erstatninger lite.

[Bolson]

Men såklart: hvorvidt en slik løsning tjener markedet er jo noe hver enkelt bedrift må vurdere. Og jeg regner med at noen kloke hoder mener dagens forretningsmodel til Keyteq fungerer tåelig greit.

 

Fra bedriftens side vil en modell der de ulike elementene bundles (programvare, konsulenttjeneste og service/support) i sammen i en "lukket" løsning med klare innelåsningstrekk som oftest være å foretrekke. I sum gjør disse at mer av det man kaller konsumentoverskuddet (differansen mellom produktets kostnad og hva markedet er villig til å betale) ende hos bedriften.

 

Derfor er innelåsing, lukkede systemer og bundling kjent som "strategisk" gode virkemidler for bedriften. Særlig i asymmetriske markeder, dvs der selger sitter med lang mer kompetanse enn kjøper, og prissammenligning er vanskeligere er dette effektivt.

 

Men normal tjener det ikke markedet på sikt, kan svekke konkurranse og innovasjon. Og det gjør produktene i snitt dyrere for kunden. Faren er også at når markedet modnes, dvs asymmetrien mellom kunde og selger minskes, kan en slik strategi slå tilbake, særlig for de aktørene som egentlig har levert et for dyrt og dårlig produkt.

 

Det er også eksempler på områder der bedrifter har økt sine økonomiske resultat ved å frigi kildekode og endre forretningsstrategi. Ikke minst har man sett at slike løsninger øker konsumentoverskuddet.

 

Nå er dette en helt generell betraktning, og har intet med Keytec og NSN sine produkter å gjøre.

Endret 13. november 2008 av Bolson

[tom waits for alice]

Har sittet i Tyskland denne uken og jobbet med vårt CMS, og CSS for et par kunder. Vi tok et krafttak denne uken og laget template CSS'er for de mest typiske layout'ene våre kunder ønsker (eller rettere sagt som deres designere lager.) Prøvde det på et par nye kunder, og det ganske nøyaktig halverte tiden det tar å lage en "90%" CSS, i forhold til metoden med å ta noe som ligner og tilpasse det. Så det var vel anvendt tid. (En 90% løsning er en som har alt kunden ba om opprinnelig. Som vi vet skal de alltid ha "litt til" eller endringer når de får se resultatet.)

 

Ser ellers dere har hatt en interessant diskusjon om innelåsning og åpne systemer.

 

Vårt CMS er proprietært og lukket, i hvert fall enn så lenge. Det har flere grunner, det viktigste er å ha kontroll med utviklingen. Våre kunder har ikke datakompetanse, deres designere har det som regel heller ikke, og vi føler at vi sikrer kundene best resultat og stabilitet ved at kildekoden ikke endres av hobbyprogrammerere. Vi føler vi har mer å tape på at sluttbrukere får dårlige erfaringer med produktet på grunn av tilpasninger vi ikke har kontroll med, enn vi har å vinne på å gå inn i et åpent marked - riktignok voksende, men der det finnes flere slike løsninger. At vi dermed går glipp av innsatsen til en stor gruppe med dyktige utviklere er baksiden av medaljen.

 

Vi host'er ikke selv, til det bruker vi en kommersiell host, men vi har alt på "vår" host. Vi innser at vi nok på et tidspunkt må la kundene få velge hvor systemet skal host'es, inklusive in house, men enn så lenge føler vi at både kundene og vi er best tjent med dette. Det gir oss kontroll med versjoner og når ulike kunder flyttes fra en versjon til en annen. Igjen, våre kunder ønsker at noen tar totalansvar for løsningen, slik at alt de trenger å bidra med er innhold. Vi har valgt å levere vår løsning som "software as a service", og retter oss derfor mot den delen av markedet som ønsker dette. Det finnes kunder som ikke gjør det, de får pr. idag velge andre produkter. Jeg tror på å finne seg en nisje, i denne som i andre bransjer. Det er bedre å være god på en ting enn dårlig på alt. (Ingen kan være gode på alt.)

 

Og ja, det hele er en pakke med månedspris. Det er ikke negativt i seg selv, et sted skal pengene komme fra. I vår situasjon er det selvsagt en fordel med en slik løsning, fordi det gir forutsigbare inntekter. Ja, det fordrer selvsagt en viss asymmentri, som Bolson påpeker, ellers kunne kundene gjort det selv. Det er derfor vi henter våre kunder i et marked som hverken er data eller web-eksperter, og i de fleste tilfeller heller ikke ønsker å være det. De vil drive sin bedrift, og synes det er gelt greit å leie inn tjenester de ikke har noen åpenbar fordel av å ha på huset. Akkurat som Rema-butikken ikke har en egen kjølemontør og budfirmaet ikke har eget bilverksted. Denne asymmetrien vil finnes i store deler av markedet fremover også.

 

Og det er ikke åpenbart at det ville vært noen økonomisk fordel for kundene med en egenutviklet løsning basert på åpne systemer. Det ville i langt større grad veltet kostnadene som i dag tas i fellesskap av hele kundebasen over på den enkelte kunde. Det er ikke mye mer komplisert for oss å flytte alle våre kunder til en ny versjon enn det ville være for en av dem å oppgradere bare seg selv. Vi nyter opplagt godt av "economies of scale" i forhold til kundene på dette og andre områder. Det skal være en nokså stor bedrift før dette ikke gjelder.

 

Det endres ikke om vi senere skulle bestemme oss for å frigi kildekoden til CMS'en. Det er mulig at det på et gitt tidspunkt ville være en lønnsom strategi for oss, men det er ikke åpenbart at det er det for alle kundene. Vi opererer åpenbart - så lenge det finnes åpne løsninger i vårt marked - ikke i et monopolistisk klima, og kan ikke prise oss ut i sammenligning med konkurrentene. Jeg tviler på at kunder flest ville komme billigere ut ved egeninnsats enn de gjøre ved å leie tjenestene fra oss.

 

Om det svekker konkurransen og innovasjonen at ikke alle systemer er åpne er jeg ikke sikker på. Men det blir en litt annen diskusjon. Vi har ikke - og føler ikke - noe ansvar for oppmuntre til konkurranse, den er et faktum som vi lever godt med, men som vi egentlig skulle ønske vi ikke hadde. Å si noe annet enn at vi gjerne skulle vært enerådende ville være uærlig. Men nå er vi ikke det, og vi var heller ikke først ute med denne type løsninger, så i så måte har vi bidratt til konkurransen gjennom vår etablering. At den bidrar til at vi forbedrer oss og vårt produkt er opplagt, så for markedet er det en god ting at det finnes konkurranse.

 

Innovasjon vil oppstå i CMS-markedet, fordi etableringskostnaden er lav. Dermed drives innovasjonen primært av etterspørselen, og den er som kjent stigende i dette markedet. Det er ikke som å skulle konkurrere med Intel - hvor behovet for risikable milliardinvesteringer i R&D og produksjon stopper nyetablering - vi startet dette som en bigesjeft for en håndfull kunder og tar ett skritt av gangen. Og derfor vil også markedet bestå av en fornuftig mix av åpne og lukkede systemer. Jeg tror faktisk på at det er det beste jeg. Det er opplagt at Microsoft og Apple har godt av konkurranse fra open source løsninger i sitt marked, men jeg er ikke helt overbevist om at vi med bare open source løsninger ville vært kommet like langt. Innovasjon drives ikke sjelden av mennesker med et ønske om å bli rike. Det er ingen dårlig motivasjonsfaktor.

 

Når det gjelder spørsmålet om flytting: Det problemet har vi diskutert ofte. Vi låser ingen kunder til vårt system. Designerne har full FTP-tilgang til alle kundens bilder og andre filer, inkludert CSS, og kan når som helst flytte ting om en kunde ønsker det. Kunder som vil forlate oss får også en full databasedump om de ønsker det, eller eksport i et fornuftig format, og vi oppretter også en statisk side med informasjonen slik den er idet de sier opp kontrakten, så de går ikke i svart. De får selvsagt kostnaden med å implementere sidene på et nytt system. Men det ville de strengt tatt fått om systemet var åpent også, hvis det var systemet de ikke var fornøyd med. En annen sak er det selvsagt om det er oss som leverandør de ikke er fornøyd med, hos oss er de låst i så måte, mens med et åpent system kunne de beholdt systemet men byttet tjenesteleverandør. Jeg liker dog å tro at det setter press på oss til å være gode nok.

 

Nå har vi ikker opplevet - ennå (bank i bordet) - at sluttkunder har ønsket å si opp avtalen, annet enn ved opphør av firmaet. Men vi har hatt tilfeller av at designere har ønsket å ta kontrollen over også denne delen av web-utviklingen, og har anbefalt sine kunder å gå over på en åpen løsning som designeren kunne bruke (og putte også den delen av inntektene i egen lomme. Våre partnere får riktignok provisjon på inntektene vi har på deres kunder, uten forpliktelser, så egentlig tror jeg ikke der er noe å tjene på). Disse er dog unntak, designere flest er slik jeg oppfatter det mest opptatt av å drive med sitt - altså design - og er glad for å slippe å programmere.

 

De oppdager antagelig snart at akkurat som de er fagfolk på design, er vi fagfolk på programmering. Det betyr ikke at ikke en god designer også kan ha en programmerer i seg, akkurat som jeg har en designer i magen, og har tatt sjansen på å lage design for et par kunder. Men stort sett er alle parter - og spesielt sluttkunden - tjent med at skomakeren blir ved sin lest.

 

Bare noe tanker dette. Jeg har bare skumlest de foregående postene, så om jeg bommet på "temaet" så får dere ha meg unnskyldt.

 

Geir

[Bolson]

@Geir:

 

Du bommer nok ikke, men du har som de fleste litt tendens til å blande hummer og kanari når innelåsing er temaet.

 

* For det første har ikke innlåsing som jeg har gjentatt flere ganger direkte noe med closed/kontra open source å gjøre. Hadde dere f.eks. valgt å gjøre som Episerver og Sitecore, dvs i utgangspunktet bare utvikle systemet og latt i hovedsak tredjepart selge, implementere, hoste og supportere systemet, samt la tredjepart utvikle tillegg, hadde det ikke vært særlig mer innelåsing enn de fleste Open Source systemer. Eneste forskjellen er at skulle dere droppe videreutvikling er "partnerene" litt stuck, men i realiteten kan de faktisk klare å drifte systemet videre (dårlig med utvikling dog). Men det er nesten umulig å låse inn med open source, selv om det faktisk går til en viss grad det også.

 

* Det å måtte bytte system uansett grunn har omtrent samme kostnad uansett.

 

* At kunder er fornøyd er ikke et tegn på at innelåsing er bra. Flertallet er svært godt fornøyd med Windows eller Apple, men det er få som har dratt innelåsing lengre, og utnyttet det økonomisk. Det er nemlig umulig å oppnå de resultatene økonomisk som MS og Apple har uten innelåsing.

 

* Det er heller ingen problemer med å levere åpen kildekode CMS-er som SaaS, og ta totalansvar for løsningen.

 

Du har eller helt rett at mange aktører, og ingen monopoltilstand gjør at effekten av innelåsing økonomisk blir mindre. Men den er der.

 

Ellers er det å tro at hobbyprogrammere får endre kildekoden i Open Source tydelig tegn på manglende kunnskap om hvordan det arbeides med disse systemene. Klart at man har useriøse implementører som gjør mye rart, men de fleste Open Source CMS har meget klare og strenge rutiner for hvordan ny funksjonalitet og patcher skal legges inn.

 

I Tyskland er det faktisk et åpen kildekode CMS som er et av de større CMS-er i markedsandel.

[Haraldson]

Mange veldig gode poenger som ikke har kommet fram tidligere her, Geir. God lesning.

 

Jeg antar du ikke vil oppgi hvilket firma du jobber i? Kunne kanskje til en viss grad vært interessant — se referansekunder og mer.

 

 

Bolson: Kunder driter i (må unnskylde fransken min) mye rart, og når de også får råde over koden på løsningen du har levert kan det skje mye rart, til tross for alle slags retningslinjer som måtte foreligge. En kunde forholder seg ikke til SVN eller hvilke rutiner som måtte være etablert for tillegging av kode/moduler for å sende koden inn sentralt så den kan godkjennes og eventuelt distribueres ut (og tilbake) — de gjør det direkte i løsningen sin. Jeg tror det var dette Geir mente. I disse tilfelle går det ofte galt.

 

Når det gjelder poenget du flere ganger har påpekt, tror jeg de fleste tenker på en lukket løsning som holdes inhouse. Har du en tredjepart som et mellomledd mellom leverandøren og kunden, kan du per definisjon fortsatt fint ha en lukket løsning, men det er mange som ikke betegner den som lukket da. Jeg tror det er mest semantikk.

 

Dette med innelåsing i systemet til Geirs arbeidsgiver ble for øvrig kommentert, i og med at en kan eksportere det meste av data i fornuftige formater. Samtidig ble det spesifisert at systemet er lukket, så jeg tror ikke motsetningene i 'vår leir' hva dette temaet angår er stå store som jeg får inntrykk av at du mener.

Endret 15. november 2008 av Haraldson

[tom waits for alice]

* For det første har ikke innlåsing som jeg har gjentatt flere ganger direkte noe med closed/kontra open source å gjøre. Hadde dere f.eks. valgt å gjøre som Episerver og Sitecore, dvs i utgangspunktet bare utvikle systemet og latt i hovedsak tredjepart selge, implementere, hoste og supportere systemet, samt la tredjepart utvikle tillegg, hadde det ikke vært særlig mer innelåsing enn de fleste Open Source systemer.

Det er et mulig valg for oss på sikt. Men det krever at vi bygger opp et betydelig antall partnere som er interessert i den type aktivitet. Vi har i tråd med vår forretningsmodell valgt å fokusere på designere som partnere, og de er nok interessert i å selge inn systemet til sine kunder, men ikke i noen betydelig grad å hoste eller utvikle det.

 

Men det er ikke noe primært mål for oss å unngå innelåsing. Det er et mål for oss å være så effektive på det vi lager og det vi leverer at kundene ikke føler behov for å bytte. Vi gjør vårt for å minimalisere problemene med "innelåsingen", men vi er ikke rede til å bytte ut vår modell for å gjøre kundene mere "frie", hvis det også gjøre dem mer sårbare for de nevnte problemer. Dette er ingen teoretisk bekymring, vi har fått flere kunder nettopp fordi vi tar totalansvaret. Enkelte av dem har hatt andre løsninger tidligere og endt opp som offer for ansvarsfraskrivelser der partneren skylder på utvikleren og omvendt.

 

Eneste forskjellen er at skulle dere droppe videreutvikling er "partnerene" litt stuck, men i realiteten kan de faktisk klare å drifte systemet videre (dårlig med utvikling dog). Men det er nesten umulig å låse inn med open source, selv om det faktisk går til en viss grad det også.

Siden vi allerede har våre systemer liggende på en uavhengig host, vil systemene uansett kjøre videre dersom vi skulle legge inn årene uten at noen overtok. (Og da i teorien "gratis", så lenge kundene betaler for hostingen og domener.) Jeg har tidligere jobbet med andre systemer og verktøy (det var ikke CMS-systemer) hvor vi vurderte en form for escrow, det vil si at dersom vi stopper utviklingen av systemet har partnerne/kundene rett på tilgang til kildekoden slik at det kan utvikles videre et annet sted. Det har vi ikke vurdert her ennå, men det er en idé.

 

* At kunder er fornøyd er ikke et tegn på at innelåsing er bra. Flertallet er svært godt fornøyd med Windows eller Apple, men det er få som har dratt innelåsing lengre, og utnyttet det økonomisk. Det er nemlig umulig å oppnå de resultatene økonomisk som MS og Apple har uten innelåsing.

Poenget mitt var at Apple og MS har bidratt til innovasjon, og at innelåsningen ikke i betydelig grad kan sies å ha skadet kundene. (Derom strides selvsagt de lærde.) Jeg hevder at MS tvert om har gjort data til allemannseie gjennom priser og produkter man bare kunne drømme om før den tid. At de ikke har oppfunnet dem alle selv er ikke viktig, det viktige er at de har brukt sin posisjon til å gjøre datamaskiner billigere, ikke dyrere. (Det er sikkert en vanskelig påstand å svelge for de av dere som bare har de siste 5 årene som erfaringsgrunnlag, og som sammenligner med "gratis" programvare,) At MS har blitt rike på det skyldes kvanta, ikke overprising. Og ja: Jeg synes det er helt greit at folk tjener penger...

 

* Det er heller ingen problemer med å levere åpen kildekode CMS-er som SaaS, og ta totalansvar for løsningen.

Selvsagt ikke. Men hvis har enerett på dette totalansvaret, er nytten av å ha åpen kildekode antagelig marginal. Hvis vi ikke har enerett er vi tilbake til problemstillingene jeg nevnte.

 

Du har eller helt rett at mange aktører, og ingen monopoltilstand gjør at effekten av innelåsing økonomisk blir mindre. Men den er der.

Ja, det blir en avveining mellom ulike goder og onder. Jeg tror på at valgfrihet er et gode, men det må gjelde leverandørene også.

 

Ellers er det å tro at hobbyprogrammere får endre kildekoden i Open Source tydelig tegn på manglende kunnskap om hvordan det arbeides med disse systemene. Klart at man har useriøse implementører som gjør mye rart, men de fleste Open Source CMS har meget klare og strenge rutiner for hvordan ny funksjonalitet og patcher skal legges inn.

Jeg er ikke redd for at vi ikke skulle kunne kontrollere hvordan ny funksjonalitet blir lagt inn i produktet. Jeg er - som Haraldson ganske riktig opfattet - redd for den funksjonaliteten som aldri kommer oss for øre, men som gjøres direkte på kundens servere i en situasjon hvor kildekoden er åpen og hvor vi ikke har kontroll fordi hostingen ikke skjer hos oss.

 

I Tyskland er det faktisk et åpen kildekode CMS som er et av de større CMS-er i markedsandel.

Ja. Jeg antar at du snakker om Typo3. Det er et kraftig verktøy, men kraften kommer med en pris. En del av den prisen er nettopp at det krever programmering (TypoScript) for å konfigurere den. De store kundene til Typo3 aksepterer det, i bytte med fleksibilitet. Men en del av de mindre havner i situasjonen hvor systemet ikke virker som lovet fordi deres leverandører (Typo3s partnere) ikke klarer å konfigurere det hele riktig. Et par av dem er kunder hos oss.

 

Hos oss er designerens/partnerens konfigurering begrenset til noen sjekkbokser og radioknapper, pluss noen til som er webmasters ansvar. Og så må det selvsagt lages en CSS. Resten ordner vi. Ønsker ikke partneren å konfigurere systemet eller lage CSS gjør vi med glede det også.

 

Vi kan ikke konkurrere med Typo3 på funksjonalitet, ennå, men det vi har er nok for de fleste i vårt segment. "Lykkelig som liten", og alt det der...

 

Geir

[Arve Systad]

* At kunder er fornøyd er ikke et tegn på at innelåsing er bra. Flertallet er svært godt fornøyd med Windows eller Apple, men det er få som har dratt innelåsing lengre, og utnyttet det økonomisk. Det er nemlig umulig å oppnå de resultatene økonomisk som MS og Apple har uten innelåsing.

 

Men at kunden er fornøyd er jo i seg sjølv ein bra ting, det tyder jo på at noko har blitt gjort riktig. Så lenge firmaet som tilbyr tjenesten til kunden er av den sorten som har levert ei løysing av kvalitet, så ser eg ikkje noko negativt i det. På samme måte kan du seie at fornøyde kundar ikkje er eit teikn på at "non-innelåsing" er bra.

 

Om vi utelukkar møkkafirma som overhodet ikkje veit kva dei driv med, så ser eg ikkje noko fryktelig ille i innelåsing så lenge kunden får det han vil ha og er fornøyd med det. Uansett blir dette ei vurderingssak frå firma til firma og situasjon til situasjon, så eg vil igjen poengtere at ein fasit på temaet ikkje fins.

 

Edit:

 

Er forresten einig med Geir - eg trur konkurranse mellom Open Source og lukka løysingar er godt for dagens programvaremarked. Ofte er det to ulike tankegangar involvert i dei to "metodane" å gjere ting på, og begge fører med seg både positive og negative sider. Begge vil truleg stjele idear frå kvarandre, og (blant anna) på den måten utvikle seg vidare til noko betre.

Endret 15. november 2008 av Arve Systad

[tom waits for alice]

Mange veldig gode poenger som ikke har kommet fram tidligere her, Geir. God lesning.

Hyggelig å høre at jeg ikke sitter opp om natten og fabulerer forgjeves.

 

Jeg antar du ikke vil oppgi hvilket firma du jobber i? Kunne kanskje til en viss grad vært interessant — se referansekunder og mer.

Jeg vil helst ikke komme i den situasjon at jeg oppfattes som firmabruker, med alle de regler og begrensninger som det medfører ifølge retningslinjene, eller beskyldes for å drive med reklame. Alt jeg sier her om de ulike problemstillingene - spesielt når det kommer til hva vi kunne eller burde gjort - er mine egne subjektive oppfatninger, og ikke nødvendigvis firmaets offisielle policy, og slik vil jeg det skal være.

 

Våre kunder er i hovedsak små og mellomstore, og ikke så mange av dem er norske, så det er kanskje ikke så interessant uansett.

 

Geir

[Steinmann]

Det eneste jeg ikke har sett blitt tatt opp her er kundens sikkerhet ved å tilby SaS.

Når man har et slikt system der alle deler samme kodebase, og database har utviklerene full kontroll på å fikse bugs, eller legge til ny funksjonalitet.

 

Dette vil ikke kunden kunne få nyte dersom da en tredjepart kom inn og oppdaterte systemet dems.

-

Fordelen med å kjøre applikasjonen som en enkelstående applikasjon mot en delt kode- og data-base må alltid veies opp mot hverandre.

 

-

For å kommentere på det Geir begynnte på. Altså 90% av css ferdig, hvis jeg ikke missforsto:

Jeg har lagt til css for det jeg alltid må ha med. Buttons vil jeg alltid ha cursor: pointer på etc.

Enkel typografi har jeg faktisk også lagt inn.

 

Men den koden jeg kanskje somregel skriver inn, kan jeg ganske godt uansett, så det går raskt. Men skulle jeg overstyrt all den koden på en mal det absolutt ikke passer i ville det tatt lenger tid.

[tom waits for alice]

Men den koden jeg kanskje somregel skriver inn, kan jeg ganske godt uansett, så det går raskt. Men skulle jeg overstyrt all den koden på en mal det absolutt ikke passer i ville det tatt lenger tid.

 

Nå er jeg ikke sikker på om jeg forstår deg. Vitsen med en mal er jo at den passer. Hvis malen ikke passer, er det jo ikke noe poeng å bruke den. Våre maler er ikke ferdige sider med masse marger og paddinger og det ene med det hitt. De er ikke som malene i Word, for å si det sånn. De er i utgangspunktet maler for struktur og basic menyoppsett, samt basisdefinisjoner for standardelementer (slike som alle sider har om man bruker vårt CMS) og placeholders for andre elementer.

 

For å beskrive hva disse malene gjør litt nærmere: Vår CMS har av naturlige grunner et antall faste moduler som brukerne kan velge blant. Rent praktisk betaler de for ferdigsydde pakkeløsninger som inneholdet ulike kombinasjoner av disse modulene, for å gjøre valget enklere.

 

En typisk side er kanskje bare et banner, en meny, en main section, en artikkel-liste og en footer. Så kan de ha alt fra medlemspålogging til webshop. Men selv på den enkle siden kan menyen ligge øverst under banneret eller til venstre for main. De har en "normal" struktur og for åtte av ti sider er denne strukturen valgt blant en håndfull standard-layouts.

 

Det vi har gjort er å dele opp CSS'en i flere filer som inneholder typiske deler:

* En default CSS som i grunnen bare inneholder font-familier og -størrelser for body og enkelte standard elementer som h1 og h2. Og så har den include-definisjoner for alle de andre CSS-filene, som man så kan kommentere inn og ut etter behov.

 

* Den neste definerer strukturen (flyt og posisjonering) på hovedelementene. Altså om menyen skal havne under banneret eller til venstre. Her har vi laget ulike versjoner for de mest typiske layout'ene, med riktige floats for hovedlementene og placeholdere for mer spesielle elementer. Vi har satt hoved elementene i primærfarger, slik at en partner/designer (husk, det er ikke bare vi som skal bruke disse CSS'ene) lett skal kunne laste opp en CSS og se hvor ting havner i forhold til hverandre. Så kan han ganske enkelt legge på farger og eventuelle bilder fra sitt design. Ønsker man en litt annen layout tar man den som er nærmest og tilpasser den. Siden de i utgangspunktet bare inneholder struktur, kan man lett endre dem.

 

* Noen hoved elementer, sånn som menyene, finnes også i flere utgaver. Vi har for eksempel en for en hierarkisk vertikal meny og en inline horisontal en, "ferdig til bruk" i den forstand at de virker uten endring. Brukeren oppdaterer den ønskede med marger og paddinger, bullet-settinger og så videre og kommenterer include-setningen inn i default CSS.

 

* Så har vi en håndfull til. Det kan være for standardelementer som impressum og footer, for moduler som webshop, og egne for billedflyt og for linker.

 

Ingen av dem er stort mer enn en side lange (på en stor skjerm), bortsett fra struktur-CSS'ene som er rundt to. Og ingen av dem inneholder noe "unødvendig" som man må fjerne, men inneholder i enkelte tilfeller ting man kan kommentere inn. Du har flyten på menyelementene, men ingen marger eller paddinger.

 

Gevinsten ved å gjøre det sånn er at man etter å ha kommentert ut og inn hovedelementene i default har en funksjonell side, om enn med rød main og grønn footer. Man kan allerede i grove trekk se hvor alt havner, det er bare å legge inn et par menypunkter og litt lorem ipsum i CMS'en. Så kan partnere - eller vi- konsentrere oss om å tilpasse dette til designet.

 

Alternativet er enten å skrive dem fra bunnen, eller å ta en CSS for en lignende side og endre den. Å skrive fra bunnen tar kanskje ikke så mye tid, men det tar tid, og hvorfor gjøre det når resultatet blir det samme hver gang? Livet er mer enn å skrive CSS-kode for standard-div'er. Og siden CSS-biten gjerne er fastprisoppdrag hos oss, betyr kortere tid brukt høyere timelønn. Det er en god ting.

 

Å endre et eksisterende design betyr alltid at du får med unødvendig skrap, spesielt hvis alt ligger i samme CSS, og det er lett å begynne å fikse på ting istedet for å skrive dem riktig fra grunnen av. Hadde våre templates vært så detaljerte hadde du fått samme problemet, men det er de altså ikke.

 

Ulempen er selvsagt at det tar spenningen ut av CSS-programmeringen. (Nå liker jeg ikke å kalle det programmering, siden det bare er struktur og definisjoner og ikke logikk.) Men de fleste websider er ikke akkurat Zen Garden-kandidater i utgangspunktet. Om det er kundene som er konservative eller designerne som ikke har Snøhetta-vyer kan man spørre seg. Man kan dog argumentere for at websider er bruksting, og at substans og nytteverdi er viktigere enn stil. Websider er Toyota pickuper, ikke Ferrarier. Men det er en annen diskusjon. Litt har vi sikkert skylden selv også. En CMS er en nytteapplikasjon, og det er ikke sikkert temaet oppmuntrer til kreativitet.

 

Men nå får vi noen morsomme sider innimellom da, hvor CSS'en blir en utfordring.

 

Geir

Endret 15. november 2008 av tom waits for alice

[Bolson]

Det eneste jeg ikke har sett blitt tatt opp her er kundens sikkerhet ved å tilby SaS.

Når man har et slikt system der alle deler samme kodebase, og database har utviklerene full kontroll på å fikse bugs, eller legge til ny funksjonalitet.

 

Dette vil ikke kunden kunne få nyte dersom da en tredjepart kom inn og oppdaterte systemet dems.

-

Fordelen med å kjøre applikasjonen som en enkelstående applikasjon mot en delt kode- og data-base må alltid veies opp mot hverandre.

 

Det er galt, system som EpiServer, SiteCore, TYPO3 etc kan alle kjøres som SaaS, og der alle kunder kan kjøre mot samme kodebase og samme databaseinstallasjon om ønskelig. Forskjellen er at det er en "leverandør/partner" som tilbyr dette og ikke selve firmaet/miljøet som utvikler core system.

 

eZ Publish vil leveres som Saas løsning gjennom Mamut. Andre vil trolig komme etter.

[tom waits for alice]

Jeg skjønte ikke helt hva som var galt med Steinmanns utsagn. At de nevnte produkter kan kjøres som SaaS, forandrer ikke på problemstillingen. Spørsmålet er ikke hvor systemet host'es, men hvem som har ansvaret for kodebasen.

 

Om en tredjepart har sin egen kodebase i en Saas-løsning, har man ingen garanti for versjons-kompatbilitet. Det finnes ikke noe garantert minste felles multiplum. Og utover en tenkt "kjerne" har man ingen garantier for at forbedringer vi gjør i funksjonalitet kommer brukerne tilgode i de ulike satelitt-SaaS'ene, fordi de kan ha sine egne skreddersydde versjoner av ulike moduler som ikke uten videre kan erstattes. Det har ikke noe med om SaaS-biten kjøres distribuert, men at kodebasen ikke er felles mellom satelittene.

 

Så lenge vi sitter med kontrollen over hele produktet er ikke dette et problem. Vi utvikler en felles kodebase, og all ny funksjonalitet legges til i standardmodulene eller som nye standardmoduler, og kommer alle kunder tilgode. (Bare avhengig av hvilken pakke de abonnerer på. Det gjelder selv om modulen/funksjonen er ønsket av en bestemt kunde.) Det samme med alle feilrettinger.

 

Så kunne vi selvsagt godt opprette flere distribuerte host'er og gi partnere ansvaret for å være SaaS-provider, og allikevel være garantert en felles kodebase. Men den dagen vi tillater kodebasen å være ulik har vi gitt slipp på et viktig fortrinn ved vår måte å gjøre tingene på. Den ulempen må veies opp mot fordelene med en slik løsning.

 

Geir

Endret 15. november 2008 av tom waits for alice

[sparks]

jQuery corners, da snakker vi divmania. Endret 15. november 2008 av sparks