I morges lå der en mail og ventede på at blive læst af 3.500 modtagere. Den var fra designnetværket Link-Up.

Uhmm – forventning om designerupdates, nyheder og indlæg havde allerede sat ind hos mange af os. Men nej. Nyheden var enkel. Link-Up stopper efter syv års tro tjeneste.

Det er ikke til at fatte, at vi skal undvære dette eminente designnetværk. Link-Up formåede at samle designbranchen – og især den yngre del, som hurtigt tog de digitale medier til sig.

Link-Up har markeret sig på mange måder. Med priser, udstillinger, samarbejder, debatter, arrangementer og meget andet. Link-Up blev hurtigt det første online community herhjemme, hvor alle nyheder om designfaget blev bragt og debateret.

Link-Up har heller aldrig været bleg for at stikke næsen frem og har fået mange slag for det, men uanset var værdierne intakte og stolte. Det kunne den samlede designbranche blot beundre – og mange ærgede sig over ikke at have samme mod og attitude. Link-Up blev derfor et vigtigt talerør for mange.

Stor og uforbeholden tak til både initiativtagerne, som tog fat for syv år siden i Sofiekælderen – og endnu større tak til jer, som holdt fanen højt gennem finanskrisen. Vi kommer til at savne jer.

I stopper med stil og respekt fra alle dele i designbranchen. Gid vi kommer til at se flere designpersoner med samme mod, energi, dedikerethed og vilje som jer, hvor det handler om at gøre en forskel.

Vi byder de dygtige kræfter bag Dansk Dynamik velkomne (de har jo været her i flere år), men det lader til, at dynamit-drenegene har større planer. Og det glæder vi os meget til!

I dag opdagede vi noget interessant – og hamrende irriterende – ved Facebooks “Like”/”Synes godt om”-funktion for Administratorer af Sider.

Helt præcist fandt vi ud af, at selvom man er logget ind som en privat person vil man, når man trykker “Synes godt om”, på en historie der er lagt ud på en side hvor man er Administrator, automatisk synes godt om historien som Siden, og ikke privatpersonen.

Forvirret? Her er en forklaring, og hvordan man ændrer det:

Jeg (Mark) er logget ind på Facebook som mig selv med min private profil. Jeg er samtidig administrator på 1508′s Facebook-side, så hvis jeg trykker på “Synes godt om” en historie der er publiceret på 1508-siden, vil det som standard ikke være min bruger – Mark Jensen – der synes godt om historien – det vil være 1508 som Side. Altså en halv-narcissistisk tilkendegivelse af at det jeg som Side har skrevet er vildt fedt, i stedet for at jeg som privatperson der er ansat i 1508 synes det var et godt indlæg en kollega skrev som værende 1508.

Det komplicerede i situationen er at Facebook vælger at skrive “You like this”, altså “Du synes godt om dette”, men hvem er “du”? I dette tilfælde, Siden 1508 – og ikke Profilen for privatpersonen der er logget ind:

Som bruger er det vel nærliggende at tro at det er privatpersonen der trykker “Synes godt om”, og ikke siden – især fordi Facebook har fået en funktion der gør at man kan bruge Facebook som en side, og ikke en privatperson:

Den var ikke slået til i dette tilfælde, så det er som privatperson jeg trykkede “Synes godt om”, og ikke som Side.

Det hele kan give lidt mere mening hvis du klikker på “Edit Page”-knappen, vælger “Your Settings” og krydser af i “Posting preferences” så følgende ikke er sat til: “Always comment and post on your page as 1508 even when using Facebook as [dit navn]“. Her er et screenshot:

Forklaring kan findes i at man som Adminstrator af en Side muligvis skal ind at kommentere på hvad ens Fans har skrevet, eller man skal skrive et nyt indlæg på Siden. Der hvor forvirringen opstår er i valget af standard-funktionen der samtidig har en forvirrende ordlyd (i dette tilfælde “You”).

Derfor er det i tilfælde som dette vanvittigt vigtigt at før man ændrer funktioner sørger for at brugerne er klar over hvad der er nyt – og give dem en mulighed for at sige fra, hvis den nye indstilling ikke passer dem. Der er kæmpe forskel på opt-in og opt-out; og i dette tilfælde snød det mig at der var opt-out, når jeg havde forventet opt-in. Der er tilmed en knap (“Use Facebook as 1508″) der gør at jeg forventer opt-in, og ikke omvendt.

Forrige onsdag, 9. februar, modtog vi i 1508 en pakke med et par mobiltelefoner:

De i alt 17 iPhones blev uddelt dagen efter i en storstilet workshop til en fantastisk gruppe studerende ved sygepleje-, bioanalytiker- og radiografuddannelserne som et led i kampagnen “Hvid Zone“. De studerende kom forbi 1508 hvor de blev instrueret i brugen af en række sociale medier samt fotograferet til en plakat der kommer op på uddannelsesinstitutioner over hele landet i de kommende uger.

Rationalet for at søsætte projektet har været at give kommende studerende, der er i tvivl om hvad dagligdagen på et af de tre studier egentlig går ud på, et indblik i livet som studerende. Nu vil de kunne følge de studerende på Twitter når de har undervisning, går til fredagsbar eller er i praktik. Der er allerede godt gang i opdateringer som alle kan følge på en liste oprettet på Hvid Zones Twitter-profil her: Hvid Zone Ambassadører.

Personligt synes jeg de billeder de studerende lægger op i særdeleshed er interessante. Det giver det helt rigtige billede af hvad hverdagen går ud på – uanset om det er instruktioner i hjertemassage på en interaktiv dukke, baktierievækst eller undervisning i CT-scanninger:

Alle statusopdateringerne, billederne og – i snarlig fremtid, forhåbentligvis – videoerne de studerende lægger op vil kunne følges på Hvid Zones mobilsite der mangler de sidste justeringer inden det er helt klar til præsentation for verden.

Indtil da synes vi alle burde se hvad de studerende laver på Twitter, Flickr og YouTube.

Kom og hør DDAs bestyrelses visioner for designbranchens fremtid og medlemsvirksomhedernes egne visioner. Vær med til at diskutere og kvalificere branchens visioner og vær sammen med dine kollegaer.

Inden selve DDA BARen har du som ikke-medlem mulighed for at møde DDAs sekretariat og bestyrelse til pre-visionsbar kl. 15.30-16.30, hvor du kan høre mere om, hvad din virksomhed kan få ud af et medlemskab af foreningen. Vi byder på kaffe og kage undervejs.

Tag et par kollegaer med og vær en del af debatten om visionerne for den danske designbranche!

Efter DDA BARen vil der være rig mulighed for at møde resten af branchen over et glas vin & tapas.

Tidspunkt | Torsdag d. 24. februar 2011 kl. 16.30

Sted | Wilders Plads 13 A, 2., 1403 København K

Tilmelding | Tilmelding til pre-visionsbar og/eller DDA BAR senest d. 22. februar her.

Hvem sagde du behøver købe en smartphone for at være social på farten?

Gemalto has managed to get Facebook running on a SIM chip, making every GSM phone a Facebook phone and bringing social networking to the dumbest of handsets.

Det mest interessante ved historien (foruden det er udviklet i samarbejde med Facebook selv) er et unavngivet teleselskab der udtaler at Facebook står for halvdelen af alt anvendt båndbredde på deres netværk. Når man tænker på hvor meget video fylder i forhold til tekst og billeder viser der sig et tydeligt billede af betydningen Facebook har for brugerne.

Det skal blive interessant at følge med i udviklingen for de brugere der ikke er på 3G/4G i store dele af Afrika, Sydamerika osv. når de også får adgang til medier de ikke før kunne komme i nærheden af.

via Gemalto squeezes Facebook onto a SIM • The Register.

Nokia har i lang tid forsøgt at leve op til egne forventninger om at være førende på markedet for mobilsoftware, men, som Nikolaj Sonne fortalte Nokias eget team til CES i Las Vegas, så er det ikke lykkedes. Overhovedet.

Forleden dukkede et overraskende ærligt brev op fra Stephen Elop, den nye CEO i Nokia. Heri gennemgår han bl.a. hvordan Apple har taget en kæmpe del af markedet for high-end mobiltelefoner, hvordan Android startede i high-end- men er ved at bevæge sig ned i “sub-€100″-markedet, og sidst, men bestemt ikke mindst, hvordan Shenzen-markedet er ved at løbe Nokia fuldstændig over ende. (Læs også Jan Chipchase – tidligere ansat i Nokia – fortælle meget mere om kinesiske kopier på sin blog.)

Stephen Elop afslutter sin mail med følgende:

The burning platform, upon which the man found himself, caused the man to shift his behaviour, and take a bold and brave step into an uncertain future. He was able to tell his story. Now, we have a great opportunity to do the same.

I dag præsenterede han så sammen med Microsoft CEO, Steve Ballmer, den nye strategi: Nokia laver sin egen hardware og Microsoft leverer software.

Det der bliver mest interessant at følge i den situation, er hvordan Nokia halvvejs har erkendt at de ikke kan følge med når det kommer til software. De bløder i forvejen ansatte der kunne være med til at sætte kursen for hvordan Nokia ser ud om 5-10 år (foruden Jan Chipchase forlod Adam Greenfield også sit job for få måneder siden), og med den ros der er kommet til Windows Phone 7 skal det blive mere end almindeligt interessant at se hvordan styrkeforholdet mellem iOS, Android og Nokidows/Winkia udspiller sig de kommende år.

I går kom 20 studerende (radiografer, bioanalytikere og sygeplejersker) forbi for at hente hver sin iphone. Telefonerne bruger vi i Hvid Zone kampagnen. De studerende skal poste om deres hverdag på studiet, så kommende studerende kan læse om livet på studiet. Et godt bud på, at kommunikation ikke skal styres, når autencitet er det vigtigste budskab.

“¦ removing manual operations related to Sitecore releases.

For the last year we have been focusing on integrating our Sitecore solutions in a Continuous Integration environment. We now have two larger Sitecore solutions and many smaller ones in the environment, where we can build, test and deploy environments, including Sitecore Items. We have gone through some iterations of the environment and find that we are ready to share some of our experiences.

Continuous Integration

The main purpose of continuous integration is to have an environment where code is build and tested at every commit, secondarily the build can be pushed to TEST or QA environments. The ultimate goal, for us, is to be able to test, validate and push Sitecore Sites from development to production, without any manual steps.

Continuous Integration and Sitecore

A Sitecore solution is composed of three parts, 1) the code 2) the database build by the developers (templates, layouts etc) and 3) the user content that is stored under sitecore/content and sitecore/media. The code is easy to integrate in a automated build, tests and deployment since this is the main goal of most CI setups, but where it gets more challenging is when the Sitecore Items get involved. Without the Sitecore Items in the CI setup there remains several manual parts for a release cycle.

Automating Sitecore builds and release cycle

CruiseControl.NET has been chosen as build server platform and custom NAnt tasks are used in the build scripts for search and replace, robocopy and Sitecore Item control.

Item Versioning and (Auto)Serialization

Sitecore Items is a big part of a solution and the first requirement is that the Items can be put under Source control and versioned correctly, the native implementation from Sitecore is based on a manual “œdump” of what the developers choses to save to disk.

In a multi-developer environment this lead to developers dumping the whole sitecore database at each checkin, and reverting the full database takes over 10 minutes sometimes 30 so this was not done before each development session.

When renaming and deleting Items, this setup lead to Items being re-added to the tree after they had been deleted by another developer, because the other developers had not removed them before they themselves made a item dump and checked in.

What was needed was a synchronization model for keeping the file system up to date with Sitecore without user involvement, thereby the only files the developer checks in are the ones he has made changes to. This has been done by developing an auto serialization that attaches to the Item events and e.g. deletes the file if the Item is deleted, or serializes content items if there releted template is changed. We do not yet import file changes fully automated to Sitecore, for the fear of loosing work in case of merges and conflicts, but it would be a natural way to go.

This module means that we now have a stable model for versioning our sitecore item development, this was a base requirement for moving forward.  We have full traceability on the system development since every developer runs his own Sitecore code and database and both code and items are versioned.

Build Flow

We have done several iterations of the build scripts. Our latest iteration pushes the files before changing the configurations, and performs testing directly on the target system.

Repository Branching Strategy

Our latest project phmetropol.dk sometimes involved up to 8 developers, and 60+ change requests in some releases. For controlling this we created code branches in our repository for UAT and PROD. UAT had the latest code that was for final customer validation (UAT = User Acceptance Testing) and PROD contained the latest released code. This setup gave us the possibility to keep active development in the main trunk (incl. Sitecore Items) and releasing well tested code+Items in the UAT branch with a potential fix or two, and finally being able to hot fix (incl. Items).

Without version control on the Sitecore Items, we believe, such releases would have had major risks for errors.

that needed testing and We have also tried where the test was done locally before the files where moved, where items where separated from the build files but we had the need to introduce repository branching for adding a UAT and PROD build, and the configuration management when involving staged setups made the model complicated.

Configuration Management

The Sitecore solutions we have build in our environment have all involved staged setups, we have found two strategies for controlling the configuration under automated build.

Staged build and environment creation

genvej.nu is created with two websites in the Visual Studio project, one site for CMS and a site for the Front site, config files for both environments are checked in and most of the rest is copied from the Visual Studio build process from bin/ressources/layouts etc. to front. The only things the build script had to change was the environment elements in each web.config.

Staged and environment creation

phmetropol.dk was our next project we wanted to create the staged files based on the cms files only, for keeping the development environment more streamlined. This means that we, from the NAnt build file, first created a staged copy of the source, changed the config to match a staged setup (using include files for overriding where possible) and last customized based on the target environment.

This worked well in our development stage but when we saw the need to introduce the UAT environment and build this setup has become a bit complicated to maintain.

Sitecore Items

Controlling Sitecore Items in the build process required that we had them under version control and branched. Once this is in place the next step is to push them around on our different environments.

For reverting and packaging a Sitecore context is required, we have therefore implemented a web service in the Sitecore admin level, that gives us access to reverting, serializing and packaging features. Combined with a NAnt task we can control items deserialization or packing from the build script.

We have initially implemented a full revert or partial, that we can control through a web service on the Sitecore environment to give us Sitecore context. In a default cycle the only path we revert are template and layouts, but we can also revert all of Sitecore in both core and master, the problem is that this takes up to 30 minutes, so our default behavior is only the main elements.

After some iterations, we are currently looking at a model where we push the items to the target using robocopy and use the change log to revert only the affected items on Sitecore, we have done a proof of concept and this feature is in active development. This will mean we can revert sitecore items on each build because it will be done very fast. In the process we har also evaluating ideas for partial reverts on the developer machines but in that area we have yet to find the best model.

Once reverted and tested we can package e.g. template and layouts, and save a package that is then used for deployment to production, or backup.  When deploying we never take items related to Content or Media, every other Item is excepted to come from our controlled builds and packages. We have had some surprises with Web forms for marketers and Sitecore/system in this context but we will keep that for another post.

Testing

Basic code test is implemented with NUnit and could be run after the build is done on the build server. We have chosen to deploy the site first so we can run functional tests involving page clicks and search results for tests. For allowing tests on the Site we have used WatiN.

For making functional tests on controlled data and not client content we have introduced two parallel sites in development, one used in the building of NUnit tests that validate main functionality and the other used by the client to build their content. In the development phase we let the clients build up data on the qa environment and we actually fetched data with our tool web service that we pushed to our test server so we could see more real content in the test environment and still have a semi stable environment for client qa.

Other levels of testing and quality control have been implemented using FxCop, StyleCop and TotalValidator and NArrange in the development cycle.

Conclusions

We have used a reasonable amount of time building this setup. We are now able to construct larger Sitecore solutions, with tests, branching and a release cycle with full source control and minimal manual processes.

In our next project we hope to take the last step and implement continuous deployment, so production is updated straight from our build server. We also expect to implement Web Config Transformation now available with Visual Studio 2010.

We see a Continuous Integration environment as a natural part of a large Sitecore solution and an important move towards a release process.

We would like to know about your expirences on Continuous Integration, so please leave a comment or blog post.

Jan Hebnes, Head of .Net development

I sidste uge lagde vi et link til vores foreløbige prototyper til det kommende 1508.dk på Twitter. Interessen var stor. Mere end 200 har efterfølgende været inde og se nærmere på vores work in progress.

Og hvorfor nu begynde at linke til ufærdige stregtegninger over et kommende website? Det er der flere grunde til.

For det første: Why not! Prototyper over vores kommende website kan ikke siges at være vores største forretningshemmelighed. Derimod tænkte vi, at det måske ville være interessant for andre at følge med i, hvordan vi selv udvikler web. Specielt bliver det interessant at se, hvor stor udviklingen fra de første skitser til den færdige løsning bliver.

Feedback. Måske vi kunne få gode input fra dig. Fx, hvorfor er der ikke et videounivers? Hvor er Feedback-funktionaliteten? Hvor er prototypen over den mobile udgave osv”¦ Det kunne jo tænkes, at vi ikke havde overvejet alt og kunne blive klogere. Hermed ikke sagt, at det bliver brugerne som kommer til at definere vores kommende site.

Test-trial for vores kunder. Vi har længe tænkt på, at vores kunder løbende skal tweete eller blogge om processen med at udvikle eller relancere websites. Det er vores erfaring, at en af de største udfordringer ifbm. nye webprojekter for større organisationer er at skabe intern opbakning og opmærksomhed. Kun på den måde kan websitet (og den totale online tilstedeværelse) få den centrale placering i organisationen, som det i 9 ud af 10 tilfælde fortjener. Her er det oplagt løbende at være i dialog med både interne og eksterne interessenter, så gode råd, fordomme, irritationer o.l. kan tages i opløbet. Vi oplever dog også en vis frygt for denne åbenhed. “Vil det ikke blot medføre unødig brok?”, “Afdelingscheferne bliver jo sure, hvis ikke deres forretningsområde bliver en del af globalnavigation” osv. Min holdning er dog, at denne involvering i processen er det, der skaber gode resultater.

Nu tager vi vores egen medicin og glæder os til at evaluere, hvordan det kommer til at spænde af.

<

p class=”MsoNormal”>Projektchef Rasmus Rudolf Christiansen

//Designkonceptskitse//