The PMoF's Are Happening!

Thank you to everyone who helped us put this together, to the DA (*cough* Holly *cough* Steph) for the fabulous A-V equiped room they're snagging for us, to my fellow PM's for your feedback and ideas and to our presenters who generously offered to show up and do their thang!

Below is the official schedule set for Wednesday 22nd! All those looking for some awesome Project Management content are welcome to join us but it'll be first come first served regarding spots!
 

9am-10:15am     Keynote with Karen McGrane

10:15-10:45am   Coffee Break

10:45-11:45am   Session      The Science of Guessing
                                                       Chris Strahl, Jakob Person and Shannon Vettes

12:15-1:00pm     BoF              Fixed-Bid FAILAPALOOZA: 
                                                       benchmark discussion of failures and solutions!

1:00-2:00pm       Session       How to incrementally integrate QA into Agile 
                                                        Everett Zufelt and Akshay Barve

2:00-3:00pm       BoF               Watergile Pros & Cons
                                                        Round Table Discussion

3:00-3:15pm        BREAK TIME Y'ALL!!!!!!!
 

3:15-4:15pm       Session         Agile + Drupal the Four Kitchens Way
                                                       Todd Nienkerk

4:15-5:00pm        BoF               Agile Workshop & Estimation Techniques
                                                       Teaching your team to do agile

Can't wait to see you guys there, start spreading the word!

on May 16, 2013 //

Lullabot has always had a big presence at DrupalCon and next week's event in Portland, OR is no exception. We're teaching 4 classes and presenting 10 sessions. We've got 2 booths in the expo hall. We're having a big party on Tuesday night. And nearly the entire Lullabot team will be in Portland. For the latest updates, please follow us on Twitter and like us on Facebook.

Here's the breakdown of where we'll be and when:

Exhibit Hall

• Lullabot will be at booth #311 and we'll be hanging out and happy to talk to anyone who wants to stop by. Interested in working for Lullabot? Want to find out more about our services? Stop by! We're super friendly and we'd love to meet you.
• Drupalize.Me will be at booth #408 and the Drupalize.Me team will be there talking to people about all of the great Drupal training we offer. Stop by and become a Drupal superhero! Want a group plan for your organization? Want to find out what's on the horizon for Drupalize.Me? Just want to let them know how much you like the site? Swing by the booth. You'll find more friendly people who would love to hear from you.

“Day Stage”

Tuesday @ 10:15 - room B112
All questions answered! Lullabot's panel of expert Drupal architects, developers, and front-end gurus will answer questions from the audience.

Lullabot's team are some of the best in the business. We've been solving difficult problems for our clients since before most people had even heard of Drupal. Bring your difficult questions and pressing Drupal needs to the Day Stage in room B112 Tuesday at 10:15 am (before the keynote) and our senior Drupal architects will be happy to provide answers, guidance, and support.

Party!

On Tuesday night, we'll be hosting a big party at The Wonder Ballroom not too far from DrupalCon in Portland. Read the full announcement for all the details. Stop by the Facebook event and invite your friends.

Drupalize.Me Sale

Drupalize.Me is celebrating DrupalCon by PAYING for HALF of your annual membership to our training video site. The sale runs from Tuesday, May 21 and through May 28th. Sign up at the Drupalize.Me booth at DrupalCon or online during these dates. Get on the Drupalize.Me mailing list if you'd like us to remind you about this and other discounts in the future.

Training classes

Paid workshops on Monday, May 20th:

• PSD to Theme with Emma Jane Westby, and Kyle Hofmeyer

Friday, May 24th:

Presentations Schedule

Tuesday

• 10:15 a.m. - Greg Dunlap will speak about Making Core Development Sustainable in A105/Pantheon
• 3:15 p.m. - Jeff Eaton will speak about Building for a Post-Mobile World in B113/NewMedia!
• 3:15 p.m. Addison Berry will be speaking as part of the core mentoring team for Running Coaches Wanted! Contribution Sprints and Trainings in Hall A1/Acquia

Wednesday

• 1 p.m. - Seth Brown will speak about the Mistakes Agencies Make in OR 203/Palantir

Thursday

• 1 p.m. - Karen Stevenson will talk about being Remotely Virtual in B113/NewMedia!
• 2:15 p.m. Greg Dunlap will be taking part in the Dries & Company QA in A105/Pantheon. Come and ask the Drupal 8 committers and initiative leads your questions about Drupal 8!

We'll be sending out up-to-the-minute schedule reminders on Twitter, so be sure to follow Lullabot and better yet, make sure you have push notifications or SMS turned on for @lullabot. A simple way of doing this is by texting "follow lullabot" to 40404 on your phone. You'll be one of the best informed people at DrupalCon!

on May 16, 2013 //

Mentorship consulting is one of the many services that Lullabot provides, and is something we’re known for in the Drupal community. When we work with potential clients to describe what we can do for them, it can sometimes be very difficult to explain how a consulting relationship works. This is especially true if they have never participated in consulting engagements with us or another agency. It may seem counter-intuitive, but the success of a consulting engagement depends just as much on how a client approaches an engagement as it does on our expertise. Here’s a few lessons I’ve learned.

Bootstrapping Your Consultant

At Lullabot, when we begin a new project of any kind, we always start with a kickoff call. Everyone who was involved with the pre-sales discussions, and everyone who will actually be on the project is invited to attend. Ideally, there’s some overlap between the groups, especially on the technical teams. This is especially important for consulting engagements where we may be brought into a project mid-stream.

During the kickoff call, set up the lines of communication between your team and your consultant. We recommend that as much as possible be done with text, such as group chat, an online project management tool, or even email. This allows for discussions to be easily captured and turned into documentation as needed. Of course, voice is still useful, especially during screen sharing sessions, so it’s worth figuring out if Skype or Google Hangouts will work, or if everything needs to be done over a conference line.

Also during the kickoff call, you should set some broad goals for the engagement, but be prepared to change them as the engagement progresses. Often, we have clients who come to us to investigate a very specific issue, and we quickly find out that there are unrelated, but more serious problems that are worth addressing first. Much of our team’s expertise is in identifying and tracing issues in code or process.

Finally, once the kickoff is done, try to give your team time in their schedule to ask questions and learn from your consultant. Often, we are brought in for consulting and we find that the client’s team is overloaded or near a project launch. If your team is spending 35 hours a week with heavy development and coding, it leaves very little time for them to actually use the consulting hours that have been contracted. Further, the team won’t have adequate time to review and consolidate their learning. For a 10 hour-per-week consulting arrangement, we usually recommend that you allocate 2-5 hours from your team to be used with conference calls and other communication. If that sounds like it’s not feasible with your team’s current workload, consider clearing some time before the consulting engagement begins.

Distributed Learning

Lullabot is distributed across multiple time zones and countries. We don’t have regional offices that employees work out of, so we are used to communicating and learning online. This is a contrast to most of our clients (and most of the tech industry) where offices and location-oriented teams are the norm. We’ve found that treating co-located teams as if they are distributed ensures that everyone is getting the most out of a consulting relationship. It also helps improve team communication overall.

It’s very important to allow anyone on your team to work with the consultant. We try to encourage discussions to occur in a “group” context. For example, try to use group chat rooms instead of one-on-one instant messaging. This encourages conversation and brainstorming, and prevents segmenting information among individuals on your team. It also means that you’ll be better equipped to utilize your consulting hours.

As you adapt to having one of our consultants on hand, it’s a great opportunity to build a culture of sharing and learning, both within your organization and within your industry. Document what you learn from your consultant for future reference inside your company. Company-wide Wikis or intranet tools are perfect for this sort of documentation. Likewise, if your company has a blog, use it as an opportunity to consolidate and share what your team is learning. Even if “the web” isn’t core to your company’s business, there will always be lessons your team learns through our consultants that are of a non-technical and industry specific nature. Sharing those lessons will help establish your company as a leader among your peers while solidifying the knowledge within your team.

Always assume someone else has solved your problem, and solved it with a better solution than your own. Even though Lullabot is a well-established expert in Drupal, content strategy, and design, we are always looking at other teams inside of Lullabot and other companies for ways to improve a given solution. When you work with Lullabot, you aren’t just hiring a single consultant; you’re hiring an entire company of knowledge and expertise.

The Difficult Parts

A consulting relationship with Lullabot isn’t just about upgrading your development skills and learning Drupal. It’s about getting a new perspective on how your team works and becoming experts in your own specialty. Sometimes, this process can be a bit uncomfortable, especially if your company has a legacy of static processes and resistance to outside expertise.

To start, be open to process improvements as well as technical improvements. Sometimes, technical issues are just a symptom of problems with documentation, project management, or team communication. We’ve worked on many high profile sites as well as our own products. There’s never a single process or solution to project management or communication problems, but our experiences in this area let us contribute a whole range of solutions that your teams may have never encountered before.

Sometimes, working with a consultant means holding your team to a higher standard. Simply saying “we can’t” because of existing processes, a lack of motivation, or knowledge kills team morale. Take the suggestions given to you by your consultant, figure out how and when to implement them, and recognize the effort and results your team achieves through any particularly difficult changes.

Finally, make continuous improvement a core value of your team. Sometimes, clients are discouraged when they realize the gap between their current skills and where they want to be. Instead of trying to change everything all at once, just try to improve each sprint to be a little bit better than before. Not only will this allow your team to focus on one specific area of improvement at a time, but evaluating the changes at the end of a sprint or project will be much simpler.

Wrapping up

Consulting engagements can be one of the most difficult, yet most rewarding, offerings available from agencies. Nothing makes me happier to see a client’s team go from a junior level of expertise to where they are teaching me about what they’ve learned. I know it’s rewarding for our clients to be able to see themselves become our peers, and not just our client. If you put the energy into getting the most out of a consulting engagement, it may well be one of the best decisions you can make.

Andrew Berry

Senior Drupal Architect

Want Andrew Berry to speak at your event? Contact us with the details and we’ll be in touch soon.

Erin Bush  | Business Development

May

16

2013

With Drupalcon now only a few days away, preparations are beginning to ramp up (or maybe starting to die down, depending on how much prep work your company has already done). Drupalcon is *the* Drupal event of the year—and with more than 3,000 attendees and 50+ expert-led sessions, there’s a lot to think about before boarding that plane to Portland.

1. Pack Appropriately - Doug Vann said it best. See his post here. By the way, Mediacurrent is giving away a portable phone charger so be sure come by our booth (139).

2. Know your schedule- When you’re choosing sessions, try to pick a mixture of topics that you already know about (but want to know more) along with topics that are new to you. Choose sessions that focus on where the industry is headed, or on strategies that you’d like to start implementing in your professional life. Keep in mind that certain topics might catch your eye once you get to DrupalCon, so leave a little wiggle room in your schedule to jump into sessions that interest you. One session you don’t want to miss is “Marketing and Selling Drupal” 

3. Network before you get to Drupalcon- We all know that you’re expected to mix and mingle once you get there, but you can lay a lot of groundwork before the event even starts. Connect on LinkedIn with people you’d like to connect with. Join the conversation on Twitter (#Drupalcon) and RT other’s announcements/sessions etc. BTW, Mediacurrent will be posting photos and a daily photo blog on our Facebook page. 

4. Avoid the Drupal Flu- No kidding.

5. Familiarize yourself with the area- Drupalcon is going to be jam packed with action, so you’ll want to make sure you know where you can grab a bite to eat, pick up a quick cup of coffee, and refuel whenever you have any downtime. Finding a few minutes of quiet during those long days can help you rejuvenate, so you’ll be ready to jump back in when it’s time for those after-hours events.

6. Prepare your own elevator pitch- Are you looking for a new gig? Many of the sponsors at Drupalcon are hiring and even doing interviews *at* Drupalcon. So be prepared. Mediacurrent is looking for Project Managers and Solutions Architects—be sure to come by our booth!

7. Plan to attend Mediacurrent and ImageX’s After Party - Join Mediacurrent and ImageX Media at Rock Bottom Brewery for an evening of drinks and networking. Stop by either of our booths for a ticket.

8. Bring Your Business Cards- There are tons of give-a-ways during this event. Mediacurrent alone is giving away t-shirts, hand made tumblers, our latest eBook “Preparing for a Drupal Website Redesign,” a Roku, and a portable phone charger. (Drop off your business card on Tuesday)

9. Study the Floor Plan- At Drupalcon you will meet prospects, clients, partners and peers. Do you know exactly where they will be? At an event as huge as Drupalcon it pays to have a map. Look over the floor plan. Check out where your scheduled sessions will be held. Familiarity with the space now will save you time later. 

10. Plan to meet the Medacurrent team- Below are our teammates that are headed to DrupalCon. 

+ one more tip! Ask Questions-  The conversations can be more valuable than the sessions at a conference like this. Drupal is a great community, and you never know who you’ll meet, so talk to as many people as possible.

If you’ve attended Drupalcon in the past, what other tips can you offer to help prepare? Let us know in the comments below!

På SthlmConnection hjälper vi våra kunder utvärdera sina behov och ta fram en lämplig plan för sin digitala närvaro. Därefter söker vi upp de bästa lösningarna för den tekniska implementeringen, det vill säga de verktyg som är mest lämpliga för projektet. Som ni kanske vet är Drupal vår vanligaste allt-i-ett-lösning – ett kraftfullt open source-publiceringssystem som har hjälpt oss under många år och i många av webbprojekten i vår portfolio.

Samtidigt är det viktigt att vara öppen för olika lösningar och inte välja en plattform bara för att den är mest välbekant. Man brukar säga att om allt man har är en hammare börjar till slut allt att se ut som spikar. Det är anledningen till att vi inleder nya projekt med att definiera mål och koncept, och först därefter börjar göra tekniska överväganden.

Men ibland kommer kunder till oss med en befintlig idé om vilket publiceringssystem de vill använda. Ibland är det Drupal (och vi håller oftast med), men ett annat vanligt önskemål är att vi ska bygga webbplatsen i WordPress. När det händer brukar vi oftast hävda att vad det än är som man är ute efter med WordPress så går det att få det med Drupal lika väl, samtidigt som man får ett antal andra fördelar.

Det här var egentligen ett långt sätt att introducera ämnet för den här artikeln, som är: vad är skillnaderna mellan Drupal och WordPress, vilka är fördelarna med respektive plattform, och hur ska man veta vilken man ska välja för sitt projekt?

Det är också viktigt att förstå att Drupal och WordPress bara är två alternativ bland många andra, och det finns definitivt projekt där det finns alternativ som passar bättre. Två lösningar som vi ibland rekommenderar för enklare projekt är Jekyll och Tumblr (kanske något överraskande). För projekt med väldigt specifika behov eller mer komplex funktionalitet är ofta Ruby on Rails ett bra val. Men mer om dessa senare. (Jag undviker att nämna några fler verktyg för att skydda läsarens sinnesro, men det finns många många fler, och några av er kommer säkert sakna sin favorit bland verktygen jag tar upp.)

Drupal och WordPress – grunderna

Drupal och WordPress har gemensamma drag: de är båda populära, mogna open source-publiceringsverktyg byggda i PHP. De har båda stora communityn med gedigen support och gott om tilläggsfunktionalitet. WordPress är absolut störst, men Drupal är också en av världens mest utbredda publiceringssystem.

Drupal föddes 2001 i form av ett diskussionsforum, medan WordPress släpptes 2003 som ett bloggverktyg. Detta säger något om skillnaderna mellan dem: Drupal har sin bakgrund inom communitybyggande, medan WordPress är optimerat för att publicera artiklar. Sedan dess har båda systemen breddat sitt användningsområde betydligt. Särskilt Drupal marknadsför sig som en generell publiceringsplattform sedan ett antal år tillbaka.

Komplexa och enkla projekt

Den viktigaste aspekten att ta hänsyn till när man ska välja ett publiceringsverktyg är omfattningen och komplexiteten på projektet. Illustrationen ovan visar ungefär vilka verktyg jag ser som lämpliga val för ett antal olika typer av webbprojekt, och resten av den här texten handlar om varför. (Kom ihåg att sådana här frågor handlar mycket om personliga åsikter. Tänk också på att illustrationen ovan ger en förenklad bild av hur det ser ut i verkligheten. Projekt kan vara komplexa på olika nivåer, och en mediesajt kan mycket väl vara mer komplex än exempelvis en communityplattform.)

De projekttyper jag använder som exempel är:

• Brochyrsajt – statiskt innehåll, oftast med en väl utarbetad design.
• Blogg – ett enkelt flöde av inlägg.
• Nyhets/mediesajt – artiklar, sektioner, olika skribenter, bloggar osv.
• Organisationswebbplats – presentationssidor, nyheter, medlemssidor, integration med externa system, flerspråkighet mm.
• Communityplatform – användargenererat innehåll, användargrupper, individuellt anpassat innehåll, integration med sociala medier osv.
• Webbtjänst – unik, skräddarsydd funktionalitet, starkt individualiserat innehåll, integration med e-post/sms/kalender/enheter, projektspecifika APIer, service oriented architecture, flera plattformar såsom mobilappar, osv.

Varför är då Drupal placerat mer till höger än vad WordPress är i illustrationen? Generellt sett är Drupal bättre än WordPress på att hantera komplexa projekt som kräver en hög grad av flexibilitet. Det finns många skäl till det, men i korhet går det ut på att Drupal har en mer generaliserad, abstrakt arkitektur, där olika funktionalitet och innehållstyper använder samma generella byggstenar. Det gör att möjligheterna att anpassa, kombinera och integrera dessa byggstenar i stort sett är oändliga.

WordPress gör det möjligt att anpassa och bygga egen funktionalitet ovanpå kärnan, men standardbyggstenarna är färre och mindre kraftfulla. Det betyder att olika tilläggsfunktioner ofta inte är integrerade med varandra, som i Drupal, om de inte har utvecklats specifikt för att fungera ihop.

Några specifika områden där Drupal har bättre funktionalitet än WordPress är:

• Det kraftfulla systemet för innehållsmodellering
• De flexibla presentationsfunktionerna som tillhandahålls av Views-modulen
• Användarrelaterade funktioner (roller, rättigheter, grupper)
• Flerspråkighet.

Enklare projekt som en broschyr-sajt eller en blogg är vanliga WordPress-projekt, och det är ingen tvekan om att det är ett bra verktyg för det området. Man kan använda Drupal för sådant också, men det kan vara overkill beroende på vad man vill bygga – särskilt om man inte redan kan Drupal.

Alternativen

Jekyll är ett av våra favoritverktyg när det gäller enklare projekt (även om Jekyll-projekt också kan vara komplexa.) Det kan ofta ses som ett alternativ till WordPress. Jekyll är en open source statisk webbplatsgenerator skriven i Ruby. Att den är statisk betyder att live-sajten alltid är snabb, säker, stabil och i stort sett underhållsfri. Nackdelen är att den inte har något onlinegränssnitt för redaktörer (men det finns lösningar – se nedan). Det finns inte heller någon användarinloggning, kommentarer, eller något annat som skulle kräva en serverapplikation. Tänk dock på att man kan göra väldigt mycket i klienten nu för tiden!

Tumblr är egentligen inte ett publiceringsverktyg som man kan ladda ner och installera själv. Det är en gratis bloggtjänst som erbjuder mycket trevliga innehållsfunktioner för sidor, inlägg och media. Den låter dig anpassa frontend-delarna av din blogg på valfritt sätt, vilket betyder att så länge innehållsstrukturen passar dina behov så kan du i stort sett bygga vilken sajt du vill på plattformen – särskilt som Tumblr tillåter att man använder sin egen domän. Fördelarna är lockande: ingen installation, inga utvecklingskostnader, inget underhåll – och gratis hosting. Vad man offrar är ägandet av plattformen. Tumblr skulle i teorin kunna stänga ner eller ändra sina villkor från en dag till nästa – men så länge man litar på dem (vilket många gör) och ifall det inte skulle innebära katastrof att behöva flytta till en annan plattform, så kan Tumblr vara ett mycket bra val.

Ruby on Rails skiljer sig från WordPress och Drupal på så sätt att det inte är ett publiceringssystem i grunden. Rails är ett applikationsramverk som låter dig utveckla skräddarsydda webbapplikationer med hjälp av ett kraftfullt och smidigt API. Man får betydligt mindre från start, men ramverket gör färre antaganden om din applikation, och det hjälper dig att snabbt bygga upp precis de funktioner du behöver. Det betyder att det är ett bra alternativ om man inte vill anpassa sitt projekt till standardbeteendet i någon av de andra lösningarna. Rails fungerar också mycket bra som backend till andra applikationer, såsom mobilapplikationer, applikationer i sociala medier och andra parter om behöver kunna integrera med din plattform.

Budget och utvecklingstid

Flexibiliteten och den relativa komplexiteten hos Drupal jämfört med WordPress betyder att det oftast tar längre tid att komma igång. Man kan starta en WordPress-sajte väldigt snabbt, särskilt om man använder färdiga teman och inte behöver göra någon egentlig egen anpassning. Med Drupal får man inte så mycket på köpet. Man måste oftast installera ett antal tilläggsmoduler, även för enklare sajter, och bygga ett eget tema för projektet. (Det finns dock ett antal Drupal-distributioner som är förberedda för specifika användningsområden. Med dem kan man definitivt komma igång snabbare.) Med ramverk som Ruby on Rails får man oftast räkna med ännu längre utvecklingstid, eftersom det är mer som att börja med ett tomt ark varje gång. Det här är inte en brist hos Drupal eller Ruby on Rails – det är en naturlig följd av de problem som verktygen är tänkta att lösa.

Det är viktigt att förstå att snabbheten med WordPress bara är en fördel om det faktiskt passar för de aktuella behoven. Om man behöver en helt egen design – inga problem. Man kan göra alla möjliga kreativa saker med frontend-utveckling och JavaScript. Att lägga till backend-funktionalitet är också fullt möjligt, men som jag skrev tidigare är det bara sant till en viss gräns. När applikationen växer riskerar den att bli alltmer svårhanterlig i takt med att du utvecklar dig bort från WordPress-kärnan. Som sagt, det handlar i slutändan om projektets behov – och att välja en snabb lösning kan visa sig bli dyrt i längden.

Om man har en tajt budget är det första man bör göra att begränsa projektets omfattning och fokusera på de viktigaste bitarna först. (Kanske är det faktiskt viktigare för ditt projekt med en aktiv närvaro på sociala medier än att bygga en ny webbplats?) Det är mycket viktigare att hitta rätt med de grundläggande delarna än att försöka få med så många funktioner som möjligt när budgeten är begränsad. Förutom det bör man också fundera över hur man vill att projektet ska utvecklas i framtiden. Om behoven är relativt avgränsade, både nu och i framtiden, så kan WordPress mycket väl vara rätt val. Kanske skulle Tumblr kunna funka lika bra, och det kan vara en mycket effektiv lösning. Med Jekyll handlar det oftast (inte alltid) om en mer specialbyggd webbplats, så det behöver inte vara snabbast i början, men när det väl är klart är kostnaderna för underhåll och hosting i stort sett noll.

Användarvänlighet

WordPress hyllas ofta för att det är så enkelt att använda för skribenter. Man har länge pratat om det som WordPress styrka och Drupals svaghet. Skribenter och redaktörer gillar oftast WordPress tack vare det smidiga och välbekanta gränssnittet som man hanterar innehållet med, och tack vare att man när man har lärt sig använda det kan administrera i stort sett vilken WordPress-sajt som helst. Det finns också mobil-appar för iOS och Android som gör det lätt att lägga upp innehåll på en WordPress-sajt när man är ute på språng.

Drupals administrationsgränssnitt för innehåll är habilt från start, men inte fantastiskt. (Drupal 8 lovar många förbättringar på det här området.) En viktig skillnad mot WordPress är att innehållshanteringen i Drupal beror så mycket på strukturen på den aktuella webbplatsen. Drupal gör färre antaganden om vilka typer av innehåll du kommer vilja använda, så innehållshanteringen är mer generaliserad, och ärligt talat lite klumpig ibland. Det är upp till den som bygger sajten att förbättra situationen genom att installera editor-pluginer, skapa egna adminsidor som visar olika typer av innehåll och så vidare. Det positiva är att det här är relativt enkelt att göra. (Det negativa är att det ofta prioriteras ner till förmån för de delar som besökarna ser.)

Tumblr har ett jättebra administrationsgränssnitt, och en snygg mobilapp för att hantera innehållet. Jekyll har inget gränssnitt över huvud taget – tanken är att man hanterar sitt innehåll som vanliga textfiler (vilket faktiskt är ett väldigt effektivt gränssnitt), men det finns ett projekt som heter Prose som erbjuder ett webbgränssnitt för att hantera Jekyll-innehåll via Github. Med Rails är gränssnittet helt och hållet upp till utvecklaren, men i praktiken löser man det ofta snabbt och enkelt med färdiga paket som RailsAdmin som ger ett enkelt, utbyggbart administrationsgränssnitt automatiskt.

Utvecklingsprocessen

Hur kraftfull en publiceringsplattform än är handlar webbygge i slutändan ändå alltid om programmering: att skriva källkod i olika programmeringsspråk för att etablera projektets struktur och funktionelitet. Precis som utvecklare i allmänhet använder webbutvecklare bra verktyg för att strukturera sin kod, förenkla samarbete med andra utvecklare och handskas med projekt som förändras kontinuerligt över tid. Exempelvis gör versionshanteringssystem som Git att team kan jämföra olika versioner av filer, arbeta med samma fil samtidigt oberoende av varandra och trycka ut ändringar till olika miljöer (såsom utveckling, testning och produktion).

Jekyll och Ruby on Rails är båda helt kod-drivna, vilket betyder att det är väldigt naturligt att använda den här typen av utvecklarverktyg. Både WordPress och Drupal bygger däremot på att man gör mycket av utvecklingen genom ett administrationsgränssnitt – utan att skriva någon kod. Webbplatsens struktur lagras i en databas, tillsammans med allt innehåll, användardata med mera.

Det här betyder att de i stor utsträckning går miste om de hållbara arbetsflöden som vanligtvis används inom programvaruutveckling i allmänhet. Det databasdrivna upplägget fungerar bäst när det är en enskild person som bygger en ny webbplats från scratch. Om man är ett team som bygger en sajt på det här sättet måste alla jobba mot en central kopia där slutgiltig konfigurering görs, och man måste samordna det så man inte kommer i vägen för varandra. Ett annat problem uppstår när man redan har en befintlig webbplats som man behöver göra omfattande förändringar på utan att ta den offline. Det är en utmaning eftersom sådana förändringar måste utvecklas och testas på en separat miljö innan man försöker applicera dem på livesajten.

För att råda bot på problemet har Drupal smarta sätt att samla in denna konfiguration och exportera den till kod automatiskt. (Drupal 8 har ett särskilt core-initiativ som jobbar med dessa frågor.) Ihop med manuellt skriven kod kan den sen tas in i versionshantering för att förenkla samarbetet inom team och för att göra det möjligt att snabbt sjösätta ny funktionalitet. Enligt min åsikt är det här en enorm fördel med Drupal jämfört med WordPress. Faktum är att det skulle vara svårt att utveckla stora, komplexa webbplatser utan denna möjlighet. (Å andra sidan lider inte WordPress lika mycket av att vara databascentrerad, eftersom det inte finns lika många byggstenar att jobba med i administrationsgränssnittet som i Drupal.

Det betyder dock inte att Drupal nödvändigtvis kan betraktas som en utvecklarvänlig plattform. Ruby on Rails och liknande system är framtagna med smidig utveckling som främsta mål, medan Drupal, precis som de flesta publiceringsplattformar, i första hand fokuserar på att erbjuda ett kraftfullt webbgränssnitt.

Den här typen av frågor är inget som slutanvändaren eller sajtägaren ser direkt, men de avgör ändå i vilken utsträckning man kommer kunna utveckla en webbplats kontinuerligt med en hållbar projektstruktur och ett bra arbetsflöde.

Drift och underhåll

Drupal och WordPress använder samma serverarkitektur – den mycket vanliga LAMP-miljön. Drupal kräver i allmänhet mer serverresurser, men det beror väldigt mycket på den aktuella webbplatsen. Utbudet av hosting-företag som har stöd för den här arkitekturen är dock enormt, så det går alltid att hitta prisvärda driftlösningar.

Jekyll behöver bara en webbserver som kan publicera statiska filer, vilket gör driften väldigt billig och enkel. Tumblr har gratis hosting. Ruby on Rails har generellt lite högre krav på servermiljön, men det finns många driftlösningar som specialiserar sig på Rails-support.

Att underhålla en webbplats kan inbegripa många olika saker, men de vanligaste arbetsinsatserna är övervakning och prestandaoptimering, samt säkerhetsuppdateringar av grundsystemet och tilläggsmoduler. Underhållsprocessen ser väldigt lika ut med Drupal och WordPress. En skillnad är att WordPress är mer exponerat för säkerhetproblem, så man måste vara särskilt noga med att hålla plattformen konstant uppdaterad med de senaste säkerhetsuppdateringarna. Ruby on Rails har liknande underhållsbehov som Drupal och WordPress, även om det är en väldigt annorlunda plattform.

Jekyll och Tumblr kräver i stort sett noll underhåll, eftersom den första hostas som statiska filer, och den andra sköts om av Tumblr-tjänsten.

Slutsatser

Att välja rätt platform för ett webbprojekt handlar om ett antal överväganden som jag har försökt beskriva i den här artikeln:

• Projektkrav och komplexitet
• Budget och tid för lansering
• Utvecklingsprocess och projektets hållbarhet
• Drift och underhåll

Förutom det måste man ta hänsyn till de färdigheter och den kunskap som man själv och teamet har. Att lära sig nya plattformar är roligt och viktigt, men om det finns budget- och/eller tidsramar är det förmodligen effektivast att använda ett verktyg man redan kan, förutsatt att det faktiskt lever upp till projektets krav.

Jag hoppas att den här genomgången har känts givande, och att den kommer att hjälpa dig att välja plattform för ditt nästa webbprojekt!

Mer läsning

Come meet Drupal.org team in person at DrupalCon Portland!

We’re hard at work upgrading Drupal.org to Drupal 7. DrupalCon is a perfect opportunity for you to find out what is going on with the upgrade, give us feedback on the new issue page layout and, of course, help us in the issue queue.

Where to find us:

• Weekend before DrupalCon - We are taking part in the extended sprints, come and help us close some issues
• Tuesday, May 21, 4:30pm - We’re having a BoF, Drupal.org improvements and D7 upgrade (Room B112)
• Wednesday, May 22 at 6pm - I’m presenting D7 upgrade report at the Drupal Association board meeting
• Thursday, May 23, 10:15am-1:15pm - I’ll be at the Drupal Association booth in the Exhibit Hall’s Community Village
• Friday, May 24 - We'll be closing more issues at the Contribution Sprint

Come and learn how you can help out with development, site building, or QA!

There are currently 99 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...

Module: Subscriptions by Reference

What does it do?

The Subscriptions module allows you to subscribe directly to nodes, but what if you want to subscribe to one node referenced by another? Previously, you could do that with a moderate amount of custom code, maybe with the help of a blog post explaining the process. Now, the Subscriptions by Reference module promises to make that even easier. Just tell it which content types and field you want to use in the subscription and it does the rest.

Look Useful? Review it!

If you would like to see this module readily available on Drupal.org, you should review it and help make that happen.

Pro Tip: If you've never reviewed a project application before, you can find instructions for reviewers on Drupal.org and the Code Review group is happy to help more people get involved.

Everyone planning and building Web solutions with Drupal benefits from understanding what a "hook" is—and why Drupal is not a CMS.

One of the greatest challenges that Drupal adopters face, whether they are new site owners or beginning developers, is figuring out what is easy and what is hard to do with Drupal. As a developer, solution architect, technical strategist and even as the friend who knows stuff about Web sites, 60% of my discussions revolve around three questions: how long will it take, how much will it cost, and can my site do [insert cool new thing]?

Sometimes, these are easy questions to answer. Many content-related tasks can be accomplished simply by logging in to Drupal, visiting the /admin page and clicking on menu links until you land on the necessary administration page.

More often though, there are complicated questions to answer. Some tasks can be accomplished by adding contributed modules that easily "plug in" to Drupal core, as it comes "out of the box", and expand a site's functionality. Contributed modules are created and shared by the Drupal community and can be added to any Drupal site.

Some tasks require writing custom code, and new modules must be built. Layers of potential functionality are involved in custom features. Some features require communicating back and forth with other sites via an application programming interface (API). Bigger Web sites often require the creation of small applications that accomplish tasks in the background, outside Drupal's usual workflow. In many cases, multiple solutions exist, and choosing one involves giving something up to get something else. As a developer or a stakeholder, finding the best solution that meets business goals and stays in scope depends upon cooperative discussions.

That is where communication often breaks down. Developers are speaking one language while site owners, project and account managers, stakeholders and others involved in the decision-making process speak another language. When people first learn about Drupal, their initiation often focuses on what a node is, what blocks, content types and views are, and how to create SEO-friendly URLs. These concepts are important, but they frequently fail to answer the essential "how hard is this to do" question or provide a strong foundation for collaborative planning of more complex functionality. Everyone involved needs to understand that they can architect a Drupal site that offers a more-sophisticated set of features than a WordPress site, because Drupal is not a content management system (CMS); it is a content management framework.

Conceptualizing Drupal as a framework does not require years of programming experience; rather, it simply requires understanding what a "hook" is and finding out whether the one you need exists and already is able to do the thing you want done.

To understand hooks, it's necessary to understand how dynamic Web pages, delivered by Web applications, differ from static pages. Most tech-savvy people take this knowledge for granted, especially Linux aficionados and those whose first desktop computer had a flashing cursor at a C: prompt. But many people don't know how Web sites do what they do. (Why would they?) Here is how I explain the difference in layman's terms.

In the olden days, static pages were single text documents containing everything you saw on the page, except for images, in one text file. The file included HTML tags describing the type of content being displayed—for example, <p> denotes a paragraph, and <h1> is a big headline. Browsers (which took ten hours to download) translated this markup and presented pages with a readable structure at a Web address dictated by the filename. The document would be uploaded to the server and saved in the Web site's primary folder. The filename page.html then could be viewed using the browser at yoursitename.com/page.html.

If you wanted to change the Web page's content, you edited that file. If you wanted to change something in the header that appeared on all of the site's pages, you had to edit every page. Whether linking content together or displaying a similar sidebar, content was laid out individually on each and every page by hand.

Nowadays, most sites are dynamic. Small programs, called Web applications, are uploaded and stored on the server. Instead of delivering a static page to view, the program runs when the browser lands on the page, applying logic to the page creation process. This logic dictates how the page is built each time a page is requested (also called "on page load"). For example: the program gets the header, gets the main menu, gets the page's unique content, gets the footer and delivers the whole page to the browser. As a result, now there can be one editable header, one footer and one menu shared among all Web pages.

What about the page's unique content? How does the application "get" that? Imagine a spreadsheet where each row represents each page's unique content. Dynamic Web sites store content in this way. They use a database, which can be imagined as a collection of spreadsheets, called tables. Each table, like a spreadsheet, has columns and rows. Each row has a unique ID. When a page is displayed, the content associated with that page—an article about container gardening, for example—is retrieved from the database table and output to the page.

In Drupal's case, the programming language PHP supplies the logic and MySQL provides the database. Usually, the operating system installed on the server to power this process is Linux, and Apache is the software that handles the requests for pages and delivers them once they are built. This software bundle is called the LAMP stack.

Without static filenames like about.html, how does a dynamic Web site know which row from the content table to display? Drupal, like other Web applications, uses a query string to match the content to the page address. Query strings look like this: ?q=1234, and they are attached to the end of the URL—for example, yoursitename.com/?q=1234. Drupal uses a modified (no less mystifying) address structure: yoursitename.com/node/1234. In both cases, the unique ID, the row number of the page's content, is there: 1234.

Web pages displaying semantic URLs, like yoursitename.com/growing-a-container-garden, have included logic that pairs the unique ID with the words. But for each page, a unique ID still exists and is associated with the content in a database table.

With the advent of dynamic Web applications, the continual development of the programming languages and databases needed to drive them, and the world's voracious need for more and more content-rich sites, voilà—the Content Management System (CMS) was born. Drupal is a CMS insofar as it is an application that saves content to a database and displays it to a page using logic that is written into its core or added by programmers. But Drupal is not (really) a CMS; it is a framework that does "CMSey" stuff. Drupal provides the structure for Web applications, far more complex than a CMS, that do all the things Web sites can do: expand the functionality (using contributed or custom code), communicate with other Web applications, run applications written in PHP and other languages behind the scenes, provide responsive pages or integrate front-end languages, scale to handle large traffic numbers by making use of server technologies and provide the foundation for other as-yet-unthought-of innovations.

Here's where the process gets ingenious. But, there is one more conceptual step to take before it's clear that hard or easy depends on hooks—bootstrapping. Again, this is a concept that may seem like common knowledge to the tech-focused reader, but it can be tongue-twisting to explain. Here is my layman's version, which is an oversimplification, but a deeper understanding isn't a prerequisite to understanding hooks.

When a browser hits a Web page, Drupal asks a series of questions. The question process is called bootstrapping. The questions (Q) trigger actions (A).

• Q: Who are you (generally) and what do you want? A: Initialize and store general info.

• Q: Can I just give you a stored copy? A: Serve cached data (content stored in memory).

• Q: Can I connect to the database? A: Do so or die.

• Q: Do I need anything from there to work? A: Get it.

• Q: Who are you (specifically)? A: Start a session.

• Q: What are your requirements? A: Create server/browser page headers (the parameters for further relating).

• Q: Where are you? A: Select language.

Finally, Drupal delivers the content:

• Q: Which page? A: Serve up the page.

• 1

Subscribe in iTunes
Or use the special non-iTunes-y feed.

Dave Terry  | Partner, Client Services

May

15

2013

Today, Mediacurrent and Acquia are proud to announce that one of the highest profile websites in the world, Weather.com, based in Atlanta, will be joining the Drupal community!  To my knowledge, Weather.com will be the highest traffic Drupal site in existence. Over the last six months, Mediacurrent and Acquia have been shepherding Weather.com’s on-ramping of Drupal via a proof-of-concept and discovery engagement. 

More than anything, this adoption helps further advance our region's commitment to Drupal and open-source technologies. We are really excited about the positive impact this project will have on our local Drupal ecosystem.

website for the entire story.

Additional Resources

Georgia.gov — first state portal in the country to be powered on Drupal. 

Manhattan Associates turned to Mediacurrent to meet the challenges of an existing Drupal 6 site that lagged in performance and functionality. 

Next week, a gaggle of Palantiri, and more than 3,000 of our closest friends, will descend upon Portland for DrupalCon, an international conference that brings together a worldwide community of enthusiasts, users, developers, designers, fanatics, and many others who in myriad ways support and play nice with the Drupal open-source content management framework.

This year, we're proud to announce that we are supporting the conference in a big way. As Platinum sponsors of the conference (and Supporting Partners of Drupal Association), Palantir builds on our commitment to actively contribute to the Drupal community by educating those who work with Drupal from beginner to advanced, evangelizing audiences for whom Drupal would provide the best content management solution, and helping to support major strategic community initiatives like Drupal 8.

In addition to sending a contingent of Palantiri who will be holding court at our booth and speaking at sessions, we are also sponsoring some special guest attendees. If you're going to DrupalCon, make sure to stop by Booth 333 to say, "Hi," and pick up a little something we made for your downtime in Portland: Palantir's Portable Portland Pocket Planner. And, should you hit any of our suggested destinations, it would be cool if you could Tweet about it using #PalantirPDX.

Who's Going

Palantir is sending a great mix of people to DrupalCon Portland including folks new and old to Palantir and big enough to form a decent a kick line: Robin Barre, Beth Binkovitz, George DeMet, Nancy Essex, Larry Garfield, Steve Persch, Dave Reid, Ken Rickard, John Albin Wilkins, and Rodney. Any one of us would enjoy learning about what's on your mind as we inch toward Drupal 8.

Who's Speaking

Check out the below sessions at which folks from Palantir will be presenting or speaking, and make sure to share your feedback or continue to the conversation with us at our booth.

Larry Garfield answers the question which plagues us: "Is Drupal a CMS?" on Tuesday from 2pm-3pm.

Steve Persch and Commerce Guys' Pedro Cambra take a different approach to plugins with, "Plugin Haikus" on Tuesday from 3:15pm-4:15pm.

The Palantir team gathers at the Day Stage to deliver the goods on the next version of Drupal with, "Drupal 8: The Good, The Bad and The Ugly" on Tuesday from 3:15pm-4:15pm.

Dave Reid talks Drupal 8's file management initiative with, "Throw New\Drupal\Core\Initiative\Filemanagement\Failureexception();," part of Core Conversations on Tuesday from 4:30pm-5pm.

John Albin Wilkins will participate in the "Using Twig: The New Template Engine in D8" roundtable on Wednesday from 3:45pm-4:45pm.

John follows that up with the lip-smacking, "Making D8 Mobilicious" on Wednesday from 5pm-6pm.

Larry Garfield, Sam Boyer and Rob Loach talk integration with, "Composer: There's a Module (or Library) for That"
on Wednesday from 5pm-6pm.

Larry Garfield and John Albin Wilkins will join others at the "Dries & Company Q&A" Core Conversations panel on Thursday from 2:15pm-3:15pm.

Larry Garfield is also speaking at the Symfony Live! conference running concurrent with DrupalCon, where he talks, "Modernizing Drupal with Symfony2" on Thursday from 1pm-2pm.

Building Bridges, Connecting Communities

Inspired by the theme of this year's DrupalCon—Building Bridges, Connecting Communities—Palantir held a DrupalCon Pass Giveaway, offering free conference passes to applicants with an active interest in Drupal but for whom cost was a barrier to attending this year. After receiving dozens of entries, the below deserving winners were selected. Keep an eye out for them at the conference (we're hoping to engage them in our Day Stage session), and share whatever important bits of wisdom you have. (Actually, you might learn a thing or two from them.) Whatever you do, don’t scare them.

Minneapolis' Tess Flynn (socketwench) would like to participate in sprints and is also interested in professional development; Portland's Dalene Bloom (sunslant) wants to gather knowledge to build her first Drupal site; Portland's Ingrid Choy-Harris (quartz45) is interested in mentorship, networking and inspiration; Cleveland's James R. Stone (fndtn357) wants to connect with folks at Commerce Guys and Pantheon; New York's Carl Wiedemann (c4rl) just wants to continue to give every drop of blood he has to Drupal; Reno's Andy Guzman (andyguzman) recently crossed Dries' "I kick ass" threshold and wants to kick more of it; Vancouver's Colin Stone (scolin22) wants to beef up his engineering studies at University of British Columbia; and from Jalisco, Mexico comes engineer Elias De la Torre Aceves (eliasdelatorre) who wants to continue to support the Drupal initiative and strengthen its presence in Latin America.

Related to our pass giveaway, Palantir also donated at pass to Italian Vincenzo Rubano who successfully ran an Indiegogo campaign to raise funds which would allow him to not only attend DrupalCon but also take his first solo trip outside of Italy. Vincenzo has an inspirational story and we’re very excited to have the opportunity meet him in Portland.

All of us at Palantir look forward to seeing our friends, clients and associates at DrupalCon. Reply to this email if you want to try and get together while there, and use #PalantirPDX for tweets about our people, sessions, or if you go to any of the destinations offered up in our Portable Portland Planner!

Jack, my co-themer here at Advomatic, and I will be doing a series of articles about how we use SASS and Compass on our projects. There are plenty of articles out there on what it is and how to get started, so we wanted to dig a little deeper, and share a few tips and ideas.

Today I'll talk about Modernizr, which is a javascript library that will check to see if your browser supports HTML5 and CSS3 features. We use it on every project now to make sure we aren't serving unsupported stuff to browsers that can't handle it. One thing Modernizr does is add classes to your HTML tag, like "cssgradients" or "no-cssgradients," or "textshadow" or "no-textshadow" as the case may be. Combined with SASS, this can be a very simple way to limit your CSS3 work. Here's an example of how we now apply any of our css3 theming, using the way SASS allows you to check for parent classes, and the nice CSS3 includes of Compass.

h1.title {  // A double border, for browsers that support box shadows; single border for those that don't.
  border-bottom: 1px solid #c3c3bf;
  .boxshadow & {
    @include box-shadow($white 0 1px);
  }
}

Here's a slightly more elaborate example:

#footer {
  background-color #114163: // a baseline background color
  .lt-ie10 & { // dirty proprietary filter for IE9 and below
    filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#2074b1', endColorstr='#114163');
  }
  .cssgradients & { // gradient for CSS3-supporting browsers
    @include background-image(linear-gradient(#2074b1, #114163));
  }
}

By the way, that handy ".lt-ie10" class on the html tag is standard now in Drupal's Zen base theme. It's very handy. While we try to avoid it, we also will add in classes for .mac, .pc, .chrome, .firefox and .safari, if we have some extremely browser-specific problems, which is rare. If you are curious, here's the javascript we use to add that information to the html tag.

Drupal.behaviors.targetBrowsersOS = {
  attach: function (context, settings) {
    // Check to see which operating system we're using.
    if (navigator.appVersion.indexOf("Mac")!=-1) {
      $('html').addClass('mac');
    }
    else {
      $('html').addClass('pc');
    }
    // Check to see if the browser is Safari and doublecheck that it is not Chrome.
    if (navigator.userAgent.indexOf('Chrome') > -1) {
      $('html').addClass('chrome');
    }
    if (navigator.userAgent.indexOf('Safari') != -1 && navigator.userAgent.indexOf('Chrome') == -1) {
      $('html').addClass('safari');
    }
    if (navigator.userAgent.indexOf('Firefox') > -1) {
      $('html').addClass('firefox');
    }
    if (navigator.userAgent.indexOf('MSIE') > -1) {
      $('html').addClass('ie');
    }
  }
}

So, as you can imagine, this gives you the ability to customize what css various browsers are served, and leaner, cleaner experience all around. Stay tuned for more SASS/Compass tips and tricks!

Like the ’90s, Drupal really is alive in Portland, the city made popular again from the much-watched TV show, Portlandia. Portland is the homebase for the Drupal Association and host for this year’s DrupalCon, Drupal’s largest North American conference.

This will be Forum One’s biggest presence at DrupalCon since we went to our first conference in Washington, DC, in 2009. We’ll have 17 web developers, project managers, and strategists attending the event from our offices in San Francisco, Seattle, and DC. We can’t wait to meet more Drupalers, share our experiences, and explore Portland!

During our Day Stage session, EPA.gov: Building a Sustainable Drupal Platform, we’re excited to share the challenges and successes we faced in migrating EPA’s large web presence to Drupal. In a “game-show” style session, we’ll investigate how we navigated the unique needs of a large government agency, share project challenges, champion our successes, and provide best practices for other large organizations considering moving to Drupal.

Another highly anticipated session is What Users Want (or Why Webpages are Dead) by Nam-ho Park and Stein Setvik. They’ll dive deep into real questions about the future of websites in the face of the rise of mobile and explore the implications for Drupal.

Each year, it is encouraging to see Drupal growing. With 613 active distributions and more than 25,000 contributors, Drupal is now the largest and most recognized open-source community. It will be interesting to see how keynotes from Dries Buytaert, Karen McGrane, and Michael Lopp address the sheer size of the project and how to get Drupal to even more users.

If you’re going to be in Portland next week, stop by our booth. We’ll have free “Nodetoriusly” awesome T-shirts that will be sure to take you back to the golden age of hip-hop. Plus, we’ll raffle off an iPad mini. And if you have a big heart and bright mind, consider joining our team by checking out our career openings. Come talk to us and help us keep the dream alive at Portland DrupalCon!

The Opportunity (and why you should care about Drupal Commerce)

The eCommerce market by anyone's estimate is huge and growing fast, and implementation services represent a significant part of the total. Today, Merchants want a flexible and scalable platform that supports their unique brand, message, and user experience now, but is also agile enough to quickly take advantage of new ways of selling and future sales channels. The rapid adoption of Drupal Commerce is the result, in part, of its ability to meet these needs. But there are other factors involved.

• Rich content and strong community interaction strongly influences buying decisions, and while there are lots of great eCommerce solutions, only Drupal Commerce offers full and seamless access to the power of Drupal, allowing customers to target their customer base and differentiate themselves in the market.
• The power and maturity of Drupal has made it the top open source CMS for medium and large customers, and a large majority have eCommerce needs. Leveraging Drupal Commerce enables them to gain a greater return on their investment in Drupal technology, resources, and content.

As Commerce Guys transitions this year to more of a product orientation, integrators and agencies who sell and implement commerce solutions play a vital role in our future. As an integrator/agency, growth of your business is important. eCommerce provides one of the strongest growth strategies that you can pursue, and if you are already focused on Drupal, it is a no-brainer. If eCommerce is strategic to your future growth, Drupal Commerce offers a great opportunity to achieve your goals.

Drupal Commerce Delivery Program (an open source approach)

The Drupal Commerce Delivery Partner Program is focused on helping you build strong and successful eCommerce practices by establishing meaningful partnerships focused on joint selling and the successful delivery of Drupal Commerce projects.

The reality is that there are more bad partner programs than good ones, primarily because they are created by the software vendor, with only the software vendor's needs in mind. As we began to formulate our strategy and, most importantly, make it valuable for partners and us, we realized that the fundamentals that make open source software great could also make other parts of the business (like a partner program) great. We spoke to many integrators and agencies and concluded that it was a very valid approach. The reason is simple; openness and transparency, along with the ability for all to contribute and influence direction, drives better ideas and results in better decisions that meet the business needs of all stakeholders, ultimately allowing everyone to collaborate to grow the market and drive success.

With this in mind, Commerce Guys is excited to be launching the Drupal Commerce Delivery Partner Program at DrupalCon Portland. It is intentional that this is NOT the Commerce Guys partner program, but a Drupal Commerce community program where collectively we will shape the future of what it means to "Partner" and focus on the needs of the Drupal Commerce ecosystem. Yes, Commerce Guys will manage the program and help to channel input into a common direction, but every open source initiative requires that to be successful. However, governance, programs, policies, etc. will come from input from and decisions made by the Delivery Partner community. Near term, those decisions will center around;

• Joint business development that will reach new customers and grow our pipelines
• Proper backing, support, training, tools and resources to win and deliver successfully
• Quality standards and ways to measure quality to ensure that customer success is the highest priority
• Partner segmentation to ensure that Partners who make the biggest investment see the biggest return
• Promotion and awareness of Partners to make it easy for customers to find the right partner

How to get involved (looking for Core Contributors)

Like every successful open source project, the Delivery Partner Program is open to all but will be greatly dependent on Core Contributors who will share the following characteristics;

• eCommerce is strategic to their future
• They are committed to growing the eCommerce market around Drupal Commerce
• They are interested in working closely with Commerce Guys to develop the program
• They see value in aligning with the Drupal Commerce experts to help them be successful

How can Commerce Guys Help Me? (what we bring to the table)

Many ask us how Commerce Guys can help. As the recognized Drupal Commerce experts, our priority is to enable Delivery Partners by leveraging our skills, expertise, and knowledge around Drupal Commerce, so that you have the competency and know-how to sell and deliver successfully. Our unique products and services are complementary to you and help you to;

• Pursue and win larger, more complex projects
• Reduce your risk on a project
• Deliver on time or more reliably
• Handle complex customizations and integrations
• Provide guidance and oversight to ensure that a site is successful
• Provide higher assurance of success and greater customer confidence
• Provide ongoing support through Acquia to fix Drupal and Drupal Commerce problems quickly

Rather than think of this as a partner program to join, which is typical and an outcome of bad partner programs, ask yourself how you can use this program as a tool to grow and a resource to win.

Interested?

If any of this sounds interesting and fits with your direction and strategy for growth, we would enjoy talking with you further. Come see us at DrupalCon Portland.

Not going to Portland? Go to our Delivery Partner contact form HERE,  or send me an email at scott@commerceguys.com.

If you missed our Delivery Partner launch webinar, view it HERE. 

The title alone says it all. If you're reading this post, it probably is because you desire an easier way to insert a simple icon into your Drupal site. Many times this involves adding an icon library into your theme and doing some pretty undesirable pre-processing or template overrides to insert them where you want.

What are icons?

They're images right? Well, technically yes. Icons are a visual representation of some intended object or action -  a pictogram essentially (think of a stop sign). What I'm really asking though is:

What file format/method are or should be used for icons?

This question has pretty much been answered for years. Whether it be a single static image or one massive image used for CSS sprites, they're usually a GIF, JPEG or PNG file. Pretty standard stuff and all is happy in the world. Well, guess what world? Meet font icons.

Font Icons

While this concept really isn't new, it probably isn't as widely known and has really changed how some of us themers approach icons in general. Fonts are vector-based in nature so they can be scaled, colored, text-shadowed... pretty much every CSS trick/method you can apply to text can be used for a font icon. This has really changed the game:

While font icons are great, they do have a few limitations. (I only mention this so I don't get a comment about it below.) They are mainly monochromatic in nature, given the limitations CSS text coloring. In theory, it is possible to apply perhaps another secondary color if your font icon provides ligature support (IcoMoon). If you still need full-colored icons though, sprites are still probably the best way to go. Simplistic and flat silhouette icons are "in" right now. So in retrospect, perhaps font icons aren't as "limited" as some may believe, but purposefully and strategically left this way... at least for now.

Regardless of how one might perceive it, fonts icons have simply added to the noise of what "icons" are now considered to be and the markup that comes with it. Ironically, one might think this would complicate matters more, but in reality font icons are typically easier to implement and are overall easier to maintain.

Icons in Drupal

This problematic issue isn't anything new to the Drupal community. In fact, there are issues and discussions that span all the way back to 2007 (if not farther). With a SoC initiative and a couple more attempts to put icons into Drupal, they either didn't gain much traction or have just failed over time, miserably. As a themer, I have noticed that often times the lack of icon support in Drupal has perhaps limited the design or even affected the choices in how we build a site.

Let's take a step back and look at the underlying issue though. It's never really been about the icons themselves, has it? Rather, "How do we get them in the site?", "Do we put them in the theme or a module?" or "Do they need to be interchangeable?". It is no wonder this issue seems to go around in circles and can never really seem to come through to fruition. Often times, we've been more focused on putting the actual icons in Drupal, instead of looking at the bigger picture.

Icon API

We need a framework/API. Period. Something that can manage our wonderful, varied, multi-licensed and different methods approach to icons. We also need a way to list these icons so they can be inserted into many common places throughout Drupal.

Icon bundles (sprites and fonts) are also inherently bandwidth vampires. Often times, we don't need all the icons on the single page request, just a few. This is where services like Fontello and IcoMoon have really soared. Granting us the ability to pick and choose only the icons we need, instead of loading an entire library, most of which we don't use.

Ultimately, my goal is to figure out the best approach for dealing with fully modularized icons. To elaborate and give one possible solution: base64 embed the icon data (image/font glyph) into a separate icon specific CSS file with just that class. This would allow the icon to be aggregated into the page's CSS and loaded only when that specific icon is being used. I'm not sure how useful this would ultimately end up being and further testing needs to be done on it. There are always pros and cons to any idea, especially anytime you consider performance.

So despite the obvious challenges ahead of me, I decided to take on this whole icons in Drupal issue. I spent quite a bit of my time researching the best approach to solve and ended up building the new Icon API. Recently, l released the first public beta:

This API provides the necessary framework for modules and themes to provide icon bundles inside of Drupal. The power really lies within the sub-modules though. Their ability to integrate an icon selector into the key areas of Drupal is really the primary goal of the API. Currently these integrations enhance the block, menu and field systems. There are plans to support content areas in a filter/WYSIWYG sub-module, but given the nature of what this entails, it may be a while.

In reality though, the possibilities are endless! You can integrate icons anywhere you can think of. Please feel free to create new feature requests in the issue queue (and of course submit bugs... there will always be bugs). The icon selector is still very rudimentary at the moment, mainly due to the focus being on the back-end integrations. Future plans also include making this very dynamic in an effort to support things like icon variations (icon sizes, colors, additional classes, etc).

Warning to non-drupal co-workers: Drupal themers and developers may involuntarily and randomly throw their hands up in the air to celebrate this newly and long awaited integration. This is completely normal and to be expected. Do not be alarmed.

Per Dries's post about Drupal 8 release risk, this post outlines a plan jointly developed by the Drupal core maintainers (Dries, webchick, catch, and alexpott) for getting Twig into core safely. See that post for more background information.

What's up with Twig?

The Twig template engine was originally committed to Drupal 8 live on stage at BADCamp in November 2012, to wild fanfare. Since then, the team has been working on converting all templates and theme functions in Drupal core to use Twig. Thanks to valiant effort by numerous contributors, the PHPTemplate conversions currently stand at ~30% RTBC, and another ~45% at needs review. This is great progress!

Why aren’t the core committers committing?

The short answer is release risk. We are in the “clean up” phase of the Drupal 8 release cycle (http://drupal.org/core/release-cycle#clean-up-phase). Each commit we make should take us one step closer to a Drupal release. In effect, committing an individual Twig patch to core takes us one step further into uncharted territory. At the moment all of our templates are PHPTemplate and hence each conversion commit moves us further away from a release. We obviously can't ship with two theme systems, so unless 100% of templates are converted, we leave Drupal 8 in an unreleasable state.

Solution

We plan to merge all the PHPTemplate to Twig conversions into one patch. Once complete, we will commit this patch into the mainline 8.x branch. The patch will convert all the .tpl.php files to .twig and remove the functionality that allows Drupal 8 to run both theme engines at the same time. This means that Twig commits will not take the 8.x branch further away from a release, and it gives us an exit strategy if they are not complete by code freeze.

The Twig team will:

• Finish converting all the templates.
• Provide benchmarking evidence on each issue that the conversion conforms to the acceptance criteria. If other patches are required to be applied in order to meet this requirements then these should added to both the conversion issue and the meta issue.

Core committers will:

• Review each individual patch and
  • Comment: "+1. Ready for [#1987510]"
  • Status: "closed (duplicate)"
  • Title: prepend '[READY] '
• Commit the merged patch once all templates have been converted and acceptance criteria have been met.
• If a Twig patch is isolated to the current Twig code in 8.x then the core committers will commit it immediately. For example: Allow and test for NULL and integer 0 values in Twig templates

Acceptance criteria

The following are necessary in order to perform the final merge of conversions into 8.x:

• 100% PHPTemplate to Twig conversions are completed
• 8.x-twig performance is comparable with 8.x PHPTemplate performance, bearing in mind the issues with D8 performance testing - see https://drupal.org/node/1888424#comment-7345926
• there are no critical Twig follow ups

Once the patch is committed further Twig work should continue on 8.x to:

• Convert theme functions to Twig
• Gain the security benefits on Twig
• Further performance enhancements made possible by moving to Twig
• Preprocess cleanup
• Removal of the entire process layer

Important: It is in everyone’s interest that the conversions are finished as soon as possible. In an ideal world, the merge will take place during Drupalcon Portland.

Rollback criteria

If by 17th June the acceptance criteria are not met, then (with regret) an issue will be created to remove Twig from Drupal 8.x. This gives enough to time to create and test the rollback patch before code freeze on 1st July.

Help wanted!

The Twig team has been doing a tremendous job, and we know the front-end community is very excited about this initiative. The time is definitely here to jump in and help the team push this initiaitve past the finish line! Particularly needed are patch reviews (see http://www.youtube.com/watch?v=Bv4PY_ZEP4Q for a helpful screencast on how to do so!), since most issues have patches but can't be RTBCed by people who worked on them.

So grab an issue to review and/or drop by #drupal-twig on IRC if you'd like to help. It's a great way to learn about Drupal 8, meet awesome people, and vastly improve Drupal for front-end developers at once!

This article will give you the tools to setup fully automated an apache solr multicore localy for drupal.

The advantages: When you have new projects you will only have to create a new apache solr core based on previous configuration. This will save you valuable time.

How does it work? Whatever we have done manualy we can script using bash. This is exactly what we have done to install the apache solr multicore localy.

The script depends on drush, xmlstarlet and curl. The script will detect these dependencies and will try to download them.

Here is the script to install apachesolr and setup the multicore. We will use a second script to setup our cores later.

Install apache solr as a multicore

#!/bin/bash
 
#Validate if the executing user is root
if [ "$(id -u)" != "0" ]; then
   echo "This script must be run as root" 1>&2
   exit 1
fi
 
# ******** #
# Funtions #
# ******** #
 
#Test the connection to the solr installation
function solr_install_test_connection {
  response=$(curl --write-out %{http_code} --silent --output /dev/null <a href="http://127.0.0.1:8983/solr/">http://127.0.0.1:8983/solr/</a>)
  if [ $response != 200 ]; then
    echo -e "\e[00;31m ERROR:Solr installation failed manual intervention needed. Solr reponds at <a href="http://127.0.0.1:8983/solr/">http://127.0.0.1:8983/solr/</a> with http code: $reponse  \e[00m"
  else
    echo -e "\e[00;32m NOTICE:Solr reponds at <a href="http://127.0.0.1:8983/solr/">http://127.0.0.1:8983/solr/</a> with http code:$response  \e[00m"
  fi
}
 
# ****** #
# Script #
# ****** #
 
#Install the needed sources if needed: drush, curl and java
DRUSH=`command -v drush`
if [ -z "$DRUSH" ]; then
  apt-get install drush
  echo -e "\e[00;33m NOTICE:Drush installed \e[00m"
else
  echo -e "\e[00;33m WARNING:Drush already installed at '$DRUSH' \e[00m"
fi
 
 
CURL=`command -v curl`
if [ -z "$CURL" ]; then
  apt-get install curl
  echo -e "\e[00;33m NOTICE:Curl installed \e[00m"
else
  echo -e "\e[00;33m WARNING:Curl already installed at '$CURL' \e[00m"
fi
 
JAVA=`command -v java`
if [ -z "$JAVA" ]; then
  add-apt-repository ppa:webupd8team/java
  apt-get update
  apt-get install oracle-java7-installer
  echo -e "\e[00;32m NOTICE:Java installed \e[00m"
else
  echo -e "\e[00;33m WARNING:Java already installed at '$JAVA' \e[00m"
fi
 
#Download solr sources
SOURCE=apache-solr-3.6.2.zip
FOLDER=apache-solr-3.6.2
FILE=/opt/$SOURCE
if [ ! -e $FILE ]; then
  mkdir -p /opt
  cd /opt
  wget <a href="http://apache-mirror.telesys.org.ua/lucene/solr/3.6.2/">http://apache-mirror.telesys.org.ua/lucene/solr/3.6.2/</a>$SOURCE
 
  echo -e "\e[00;32m NOTICE:Sources downloaded  \e[00m"
else
  echo -e "\e[00;33m WARNING:Source already downloaded skipping \e[00m"
fi
 
#Extraction of the zip file containing the solr sources
DIR=/opt/apache-solr-3.6.2
if [ ! -d $DIR ]; then
  echo -e "\e[00;32m NOTICE:Extracting sources  \e[00m"
  cd /opt
  unzip $SOURCE > /dev/null
  echo -e "\e[00;32m NOTICE:Apachesolr dir created  \e[00m"
else
  echo -e "\e[00;33m WARNING:Apachesolr dir already exists skipping \e[00m"
fi
 
#Create the multicore folder - name it like you want
DIR=/opt/$FOLDER/dropsolid
if [ ! -d $DIR ]; then
  cp -rf /opt/$FOLDER/example /opt/$FOLDER/dropsolid
  echo -e "\e[00;32m NOTICE:Dropsolid dir created  \e[00m"
else
  echo -e "\e[00;33m WARNING:Dropsolid dir already exists skipping \e[00m"
fi
 
#Install and configure multicore solr.xml to the multicore folder
NEW=`grep core0 /opt/$FOLDER/dropsolid/solr/solr.xml`
if [ -z "$NEW" ]; then
  rm /opt/$FOLDER/dropsolid/solr/solr.xml
fi
FILE=/opt/$FOLDER/dropsolid/solr/solr.xml
if [ ! -e $FILE ]; then
  cp -f /opt/$FOLDER/dropsolid/multicore/solr.xml /opt/$FOLDER/dropsolid/solr/solr.xml
  sed -i 's@<core name="core1" instanceDir="core1" />@@g' /opt/$FOLDER/dropsolid/solr/solr.xml
 
  echo -e "\e[00;32m NOTICE:Solr.xml copied multicore setup complete  \e[00m"
else
  echo -e "\e[00;33m WARNING:Solr.xml already installed, skipping \e[00m"
fi
 
#Create the start|stop|restart script /etc/init.d/solr
FILE=/etc/init.d/solr
if [ ! -e $FILE ]; then
echo '#!/bin/sh -e
 
# Starts, stops, and restarts solr
 
SOLR_DIR="/opt/'$FOLDER'/dropsolid/"
JAVA_OPTIONS="-Xmx1024m -DSTOP.PORT=8079 -DSTOP.KEY=stopkey -jar start.jar"
LOG_FILE="/var/log/solr.log"
JAVA="/usr/bin/java"
 
case $1 in
    start)
        echo "Starting Solr"
        cd $SOLR_DIR
        $JAVA $JAVA_OPTIONS 2> $LOG_FILE &
        ;;
    stop)
        echo "Stopping Solr"
        cd $SOLR_DIR
        $JAVA $JAVA_OPTIONS --stop
        ;;
    restart)
        $0 stop
        sleep 1
        $0 start
        ;;
    *)
        echo "Usage: $0 {start|stop|restart}" >&2
        exit 1
        ;;
esac' > /etc/init.d/solr
 
  #Set permissions
  chmod a+rx /etc/init.d/solr
  /etc/init.d/solr start
  sleep 5
 
  #verify the connection
  solr_install_test_connection
 
  echo -e "\e[00;32m NOTICE:Solr installation completed  \e[00m"
else
  echo -e "\e[00;33m WARNING:Solr already installed, skipping \e[00m"
fi
 
#Configure solr for drupal with solr files from search api solr module
#Also download apachesolr modules
cd /opt/$FOLDER/dropsolid
DIR=/opt/$FOLDER/dropsolid/search_api_solr
if [ ! -d $DIR ]; then
  drush dl search_api_solr
  cp -rf multicore/core0/ solr/
  cp -rf solr/conf/* solr/core0/conf/
  cp -rf search_api_solr/solr-conf/3.x/* solr/core0/conf/
 
  #Reduce the time needed strat processing sent documents - we are local so we want to test fast (tip from Nick Veenhof via Nicolas Leroy)
  sed -i 's@<maxTime>120000</maxTime>@<maxTime>2000</maxTime>@g' solr/core0/conf/solrconfig.xml
 
  #Add this for future use of apachesolr instead of search api solr (we can prepare cores using the files from these modules too)
  sudo drush dl apachesolr-6.x --destination=apachesolr-6.x -y
  sudo drush dl apachesolr-7.x --destination=apachesolr-7.x -y
 
  echo -e "\e[00;32m NOTICE:Search api setting installed  \e[00m"
else
  echo -e "\e[00;33m WARNING:Search api settings already there, skipping \e[00m"
fi
 
#Exit output
echo -e '\e[00;32m Use the solr-instance script to install cores for your project. Execute sudo "./create-solr-instance.sh". \e[00m'

How to use it?

Create a file called solr-install.sh and paste the above code in it. Then execute as root:

  sudo ./solr-install.sh

If everything goes as planned you will see this:

Install independent apache solr multicore

Create solr multicore instances with this script

#!/bin/bash
 
#Validate if executing user is root
if [ "$(id -u)" != "0" ]; then
   echo "This script must be run as root" 1>&2
   exit 1
fi
 
PROJECT=$1
 
if [[ -z $PROJECT ]]; then
  echo -e "\e[00;31m please provide a projectname as 1st variable \e[00m"
  echo -e "\e[00;31m please provide an optional var to indicate to use the apachesolr module (type:apachesolrd6 or apachesolrd7) as 2nd variable \e[00m"
  echo ' '
  exit
else
  echo ' '
  echo '*************Solr env creation started**************'
  echo ' '
fi
 
# ******** #
# Funtions #
# ******** #
 
#Test connection to apache solr
function solr_install_test_connection {
  response=$(curl --write-out %{http_code} --silent --output /dev/null <a href="http://127.0.0.1:8983/solr/">http://127.0.0.1:8983/solr/</a>)
  if [ $response != 200 ]; then
    rm /etc/init.d/solr
    echo -e "\e[00;31m ERROR:Solr installation failed manual intervention needed. Solr reponds at <a href="http://127.0.0.1:8983/solr/">http://127.0.0.1:8983/solr/</a> with http code: $reponse  \e[00m"
  else
    echo -e "\e[00;32m NOTICE:Solr reponds at <a href="http://127.0.0.1:8983/solr/">http://127.0.0.1:8983/solr/</a> with http code:$response  \e[00m"
  fi
}
 
# ****** #
# Script #
# ****** #
 
#Install xml starlet if needed
XMLSTARLET=`command -v xmlstarlet`
if [ -z "$XMLSTARLET" ]; then
  apt-get install xmlstarlet
  echo -e "\e[00;32m NOTICE:xmlstarlet installed \e[00m"
else
  echo -e "\e[00;33m WARNING:Xmlstarlet already installed at '$XMLSTARLET' \e[00m"
fi
 
#Variables
SOLR=/opt/apache-solr-3.6.2/dropsolid/solr
 
#Copy a preconfigured core to use as a basis for our (see solr-install.sh)
ENV=local
DIR=$SOLR/${PROJECT}_$ENV
if [ -d $DIR ]; then
  echo -e "\e[00;33m $DIR exists, skipping SOLR env $ENV creation\e[00m"
else
  cp -r $SOLR/core0 $SOLR/${PROJECT}_$ENV
  echo -e "\e[00;32m Solr env $ENV created in $DIR\e[00m"
fi
 
#Add entry to solr.xml for our new core
ENTRIE=`grep -o "${PROJECT}_$ENV" $SOLR/solr.xml | head -n1`
if [ "$ENTRIE" == "${PROJECT}_$ENV" ]; then
  echo -e "\e[00;33m Entry ${PROJECT}_$ENV exists in $SOLR/solr.xml, skipping SOLR env $ENV creation in solr.xml\e[00m"
else
  #add entry
  cd $SOLR
  xmlstarlet ed --subnode "/solr/cores" --type elem -n core -v "" solr.xml > output-solr-${PROJECT}_$ENV.xml
  sed -i 's@<core></core>@<core name="'${PROJECT}_$ENV'" instanceDir="'${PROJECT}_$ENV'" />@g' output-solr-${PROJECT}_$ENV.xml
  cp -f output-solr-${PROJECT}_$ENV.xml solr.xml
 
  echo -e "\e[00;32m Solr env $ENV added to solr.xml $DIR\e[00m"
fi
 
#if apachesolr d6 - this will override solrconfig.xml and schema.xml with version from apachesolr module for D6
if [ "$2" == 'apachesolrd6'  ]; then
  cd $SOLR
  cp -rf ../apachesolr-6.x/apachesolr/solr-conf/solr-3.x/* $SOLR/${PROJECT}_$ENV/conf/
  echo -e "\e[00;32m Core modified to work with apachesolr d6 module \e[00m"
fi
 
#if apachesolr d7 - this will override solrconfig.xml and schema.xml with version from apachesolr module for d7
if [ "$2" == 'apachesolrd7'  ]; then
  cd $SOLR
  cp -rf ../apachesolr-7.x/apachesolr/solr-conf/solr-3.x/* $SOLR/${PROJECT}_$ENV/conf/
  echo -e "\e[00;32m Core modified to work with apachesolr d7 module \e[00m"
fi
 
 
#Restart solr
service solr restart
sleep 5
solr_install_test_connection
 
#Exit output
echo -e "\e[00;32m Now you can use <a href="http://127.0.0.1:8983/solr/"">http://127.0.0.1:8983/solr/"</a>$PROJECT"_local/ as a connection in your drupal installations. Admin: <a href="http://127.0.0.1:8983/solr/"">http://127.0.0.1:8983/solr/"</a>$PROJECT"_local/admin/. Check out all your cores at <a href="http://127.0.0.1:8983/solr/">http://127.0.0.1:8983/solr/</a> \e[00m"

How to use it?

  ./create-solr-instance.sh [projectname] [optinal: apachesolrd6 or apachesolrd7]

Use the second optional parameter if you want to install apache solr multicore for the http://drupal.org/project/apachesolr module (suffix with d6 or d7). By default the settings from the http://drupal.org/project/search_api_solr module will be installed. So dont use the second param if you are using those modules.

  ./create-solr-instance.sh dropsolidsite  

You should get a result like this:

Review

Go through this script piece by piece so you can learn some bash and learn to use this to your advantage. As drupal developers we are more or less php developers but learning some bash can be a great time saver. For example this script saved me countless hours. Everytime I had to install a multicore on a vm or on somebodies installation I m coaching, we are winning valueable time. You could even use this to control your production installation too.

Read the comments carefully and understand what every step does. We can be lazy by letting the automated scripts do the work for us but we can't allow ourselves to become stupid. You still need to understand what happens. You will need to know how it works because automated stuff always breaks sooner or later.

Other advantages

As already told this script just saves time by automating a repetitive task. But there are some other advantages.

I also use this as an instrument to teach junior drupal developers about apache solr without having them loose to much time on the details. They can set up a solr instance quickly and continue to be productive. In their training time and/or spare time they can pick apart the script like we will do now and learn about the details.

Another advantage is: You know by using the script to install an apache solr multicore localy that everyone has the same configuration. There are so much tutorials on how to set up solr on the web it becomes very possible that everyone in the team has a differten version/setup.

Conclusion

Using scripts to automate these tasks like installing apache solr is highly recommended. But you should always know what you are executing. Always be carefully to review things so you know what to do if the automations break down.

Here at Advomatic we've experimented with several approaches to responsive design over the past few years. I think the "mobile first" philosophy became popular right in the nick of time. There was a point when we'd detect if the user was on a mobile device and then deliver a separate mobile theme. This meant two instances of a site to develop for and maintain. I can't imagine doing that now, given the amount of device width/height possibilities and device-specific bugs that exist out there. So, now we work on layout with the goal of accommodating the content rather than the device. To accommodate a responsive and flexible layout, it's best to get your site on a grid. There are tons of options out there, but we've found one in particular helps you quickly get rolling and set up with a column layout that can adjust to whatever device you need your site to display on (and is fun to work with, too). Lately, it's been part of our holy trinity for responsive theming: Sass, Compass and Susy.

First things first: ditch pixels

One big first step to responsiveness in your site is to stop using pixel units for measurements. We use em units because they are proportional to any parent measurement, and therefore flexible and responsive. If we have a base font-size set on the body element of 16px, and our #footer is set to 1.6em, that #footer font-size will automatically scale up or down accordingly if the body's (or any parent element to #footer, for that matter) font-size changes. To manually figure out exactly what em value you should be using for an element, you can use a commonly used formula: target ÷ context = result... or you could do it the easy way with a Sass function:

// Create em() for setting font-sizes in pixels.
@function em($target, $context: $base-font-size) {
   @if $target == 0 { @return 0 }
   @return $target / $context + 0em;
}

// Example usage: font-size: em(21px);
// This will set the font-size to 21px in relation to the browser's base font size if it has not been established in any parent element, or in relation to $base-font-size which is a variable you can set in your Sass.

// Example usage 2: font-size: em(12px, 10px);
// This will set the font-size to 12px in relation to a parent element's font-size of 10px.

Get on the grid

If you're doing front end development these days, you're probably familiar with the concept of grid-based design and translating a comp into a fully fluid or adaptive layout via HTML/CSS. We frequently use Zen 5 as a base theme and have been big fans over the years because it comes loaded with many of the best tools for front end/theme development, while also pretty lean as far as bloat goes. While it's important to be able to build themes for browsers that can handle fancy bells and whistles, we also need to support older browsers that don't. Zen 5 already has Sass and Compass integrated. As far as a grid framework goes, we use Susy instead of Zen Grids... this has just come down to personal preference. Zen Grids is also a great system. Susy is a responsive grid framework/plugin for Compass, and it allows you to build on top of either a "magic", static or completely fluid grid.

• "Magic" grids are the default - they have an elastic container that responds to font sizes when set with em units, and is fluid on the inside. It's container size gets calculated according to the widths of your columns and gutters.
• Static grids are just that - all containers and column widths are not flexible and this is the traditional grid style. As such, it does not collapse when the viewport is smaller than the grid is wide. Even though you may specify pixel values for the column sizes, Susy converts to a percentage of the container size. The container size, like the magic grid, gets calculated according to the widths of your columns and gutters.
• Fluid grids are truly flexible layouts that respond to the width of the viewport. By default the container width is 100%. However, as with any grid type you choose, you can specify this with the $container-width variable (such as "$container-width: 70%").

Set it all up

To add Susy to your theme, there are a few things you'll need to do.

1. If you haven't already, install Sass and Compass.

   sudo apt-get install rubygems
sudo gem update
sudo gem install sass

   sudo gem install compass

2. Set up a Compass project in your theme directory.

   This is already done for you with Zen 5. If you're not using Zen 5 or a contrib theme that has this done already (look for a config.rb file in the theme directory), then set up your Compass project by going to your theme directory in your favorite command line interface and run:
   

   compass create nameofyourtheme

   This will add a "config.rb" file to your theme, and is where the Compass project settings are located.

3. Then, install Susy.

   sudo gem install susy

4. Require Susy in your Compass project.

   Open up the config.rb file and add the following (wherever "requires" are located):
   

   require "susy"

5. @include susy and add grid settings to your _base.scss (or equivalent "global" Sass file).

   We usually stick any of our grid settings in the _base.scss file that comes with Zen so that the grid variables set there are available to any other Sass stylesheet in the theme (because Zen's base gets @imported in them all). You'll also want to place them in whatever Sass file you're using that gets imported into any file where you'll be doing responsive styling/layout. For example:
   

   @import "susy";
$total-columns: 12;             // a 12-column grid
$column-width: 4em;            // each column is 4em wide
$gutter-width: 1em;            // 1em gutters between columns
$grid-padding: $gutter-width;  // grid-padding equal to gutters

After installing Susy, and getting your Compass project set up properly for the theme, you'll want to tweak those default grid settings that you just added (total columns, column width, grid padding, etc...) for the purpose of your own design. Using those settings, Susy will automatically figure out the math and put percentage widths on internal grid elements, as well as a max-width on the container (should you use a non-fluid grid). By default, all Susy grids are "magic." If you want to use one of the other types of grids, you would do that by setting the $container-style variable. For example, to build a 5 column-wide mobile first "magic" layout, we can do something like this:

$total-columns: 5;
$column-width: 3em;
$gutter-width: .75em;
$grid-padding: $gutter-width;

Making things happen at different viewport sizes

Another handy part of Susy is its at-breakpoint() mixin. This can be used in replacement of a long and drawn out media query that targets specific pixel-based min-width or max-width values of the viewport. Something we do frequently for adaptive/responsive layouts (where there are established, comp-determined breakpoints for mobile, tablet, desktop), is set variables for different numbers of grid columns.

$mobile   : 5;
$tablet   : 11;
$desktop  : 16;

So if you're building in a mobile first manner like this, and you want something to happen at a certain breakpoint in your Sass, you can use at-breakpoint() with your column count variables as an argument.

#content {
  @include span-columns(5);
  @include at-breakpoint($desktop) {
    @include span-columns(13, $desktop);
    @include prefix(3, $desktop);
  }
}

In this situation, #content normally spans 5 columns wide, which is the default/mobile width of the grid in this example. When the viewport is at the desktop breakpoint (16 columns can fit in the viewport), the width of #content will change. span-columns(13, $desktop) means "make this 13 columns wide, out of 16 total columns". prefix(3, $desktop) means "add 3 columns of empty space beforehand." So #content becomes 16 columns wide in total, however only 13 columns of space are usable and contain content, since we added 3 columns of padding to the start. A different, non-layout related way of using at-breakpoint() is to maybe change some kind of style at a given breakpoint.

padding-bottom: em(15px);
@include at-breakpoint($desktop) {
  padding-bottom: em(85px);
  background: url("bg-content.png") 162px 100% no-repeat;
}

Having at-breakpoint() at the ready is a great way of releasing yourself of the mindset and clutter of maintaining several pixel-based breakpoints in your site, and helps future-proof things since device sizes are fluctuating so wildly as time goes on. Since Sass supports code nesting, it has become standard operating procedure for us to use at-breakpoint() at the end of things in a selector's nested styles, so that they override any established defaults (which are usually the mobile version styles if we are building mobile-first).

Alternatively, Aurora

While we normally use Zen and add Susy in manually (replacing Zen Grids), some themes have Susy, Sass and Compass (and other front end goodies) baked in already. Aurora is also a Sass & Compass-powered minimalist theme with a focus on best practices for HTML5 and front end development within Drupal. It has a number of cool features like Google Chrome Frame and Typekit integration. Aurora encourages the use of Panels' HTML5 Sections layout instead of using the standard Drupal left/right sidebar block regions for sidebars. Aurora also suggests you use the Blockify module to turn all the little things on the page that normally get rendered in a page template variable into blocks that you can assign to regions via Drupal's block admin page. There are a number of features in Aurora which have been pulled out and put into a separate module, so that any theme can make use of them. That module is called Magic and some of it's best features are the ability to exclude certain CSS/JS from being included, exporting of theme settings, enhancement of CSS aggregation and adding a viewport width indicator - which is very helpful when developing a responsive site to check all your breakpoints and everything in between.

Conclusion

Susy provides a great way of quickly getting your site layout blocked out and can produce any kind of grid you need. What has your experience been like using Susy in Drupal?

Let's face it. Making documentation for end-users (content editors, administrators, etc...) is the most painful process of all the processes when it comes to handing over a project to the client. Hard to estimate, time consuming to create, never up to date, almost impossible to re-use, change one thing and you have to rebuild all the screenshots, realisation that nobody reads it, etc... Sounds familiar?

Five years ago I blogged about an idea I had - Learn as you go concept which was aiming at bringing more interactive help to the Drupal projects, to let users learn by doing the tasks they were instructed to fulfil. This bothered me for some time, we were always struggling with the documentation and giving support to clients. Don't take me wrong, we loved to help our clients over the phone or emails, but it was time consuming and not really efficient. They usually forgot what they were doing month ago.

After the first step 9 months ago, I conducted over 40 interviews with web shops all around the world. One of the major results > everyone was struggling with the documentation! It is a pain! It is a bigger pain than everyone can imagine!

After 9 months of hard work, I am happy to say that we produced something amazing (yes I know, Steve Jobs like words =). We call it Inline Manual and it is in open beta now! A service that allows you to create, re-use, distribute and collaborate on web app documentation with others. The resulting documentation is interactive in a way of using tooltips, thus guiding the users across the whole application on theirs installation.

The concept is quite similar to code sharing websites like github or bitbucket. You can create unlimited amount of public or private topics (tutorials). Topics you will make then available on a site you created for your client either by using 3rd party integration module or exporting the whole player code by just embedding stand-alone version. All topics data are stored locally on yours web-server giving you full freedom.

The best part is that you can re-use public topics that were created by others such as "How to create a user" on all your Drupal sites. With just few clicks you can create and distribute whole documentation and its versions to all of your sites. Or you can copy (fork/clone) existing topic to your account and adjust as needed based on the configuration of your site - add a step or two if you like.

The Drupal module has some specifics and can be found here: http://drupal.org/project/inlinemanual. Like showing topics based on the users role. Feel free to extend it and commit a patch!

Try it now!
If you like, go ahead and try it yourself by clicking the blue icon at the bottom right corner on InlineManual.com.

I believe this will help to streamline the documentation process and allow collaboration and re-usability of docs for web applications!

Have fun!