Civi Updates & Announcements:

• first public alpha this Friday, code is pretty stable
• good changes in UI, features, functions
• CiviCRM book is “officially” coming out after book sprint in April, though it’s already up on en.flossmanuals.net - it’s bigger than Harry Potter! Includes broken out sections with step-by-step guides for everyday tasks
• Check out http://civicrm.org/groups/nyc for more info on the meetup group
• DrupalCampNYC 8 - coming up in July, already 2/3 sold out after one day! http://groups.drupal.org/nyc

Case Study: Phillip Bien - NYS Coalition of Social Workers

• NYS Coalition of Social Workers - formed by a handful of social workers to work directly at teh legislative level
• needed a new website to support advocacy costs, needed raise cash to do effective work to change the laws
• needed powerful professional website, membership benefits & incentives to join - all on a shoestring budget
• CiviCRM 3.1.3, Drupal 6, Dreamhost Private Server (LAMP) with PayPal
• wanted to build a longterm solution
• needed lower fees than a managed SaaS
• open source, strong track record
• Drupal ACL based on membership, abundant Drupal modules, CiviCRM better & better
• current site features: public site, memberships join and create site login, permissioned content types, downloads & docs archive, register for events, self-service contact info updating
• using entirely out of the box solutions for membership, events, etc
• Drupal modules in use: CiviCRM, CiviMember Roles Sync, CCk, content permissions, filefield, text, color, help, taxonomy, pathauto, string overrides, google analytics, views, views UI
• You could do this all without Terminal/CLI, cash, php, html, css, but you should get some help if you can!
• Future: want classified ads, membership cards, CiviMail, member and nonmember pricing for events and purchases, find someone else to work on the site, expire memberships on the first of the month instead of 365 days after join date
• Accomplishments: their legislation is on the Gov’s desk for signature, got lots of new paid members, love the new site for aesthetics, ease of use for site visitors, org members, and administrators
• “NYC CiviCRM meetup provided critical direction to pull this off”

CiviCase Overview and Demo

• track interactions between your organization and constituents
• related to activities built into CiviCRM constituents
• CiviCase ties activities together to create work flows for activities related to constituents
• can create rigorous workflows with requirements for what needs to be done by whom in order to close a case
• good example of a feature developed for a particular group’s needs and contributed back to the larger Civi community
• Right now there is no UI; need to configure an XML file to set up CiviCase, though there’s good documentation online
• You can write import/export interfaces to import anything into CiviCRM, so case information can probably be imported (e.g. from Act) though entire cases can’t be exported from Civi
• Rayogram created email inbox processing script to parse and create new cases in CiviCase via email
• Cases are made up of individual activities in relation to a CiviCRM contact
• When you open a case for a contact, you can describe the details of the case, assign a subject, select a case type, set a status, and create a start date and duration
• opening and closing a case is an activity; you then create new activities within the case
• Jack’s thoughts about specific use cases for clients: CiviCase for grant application processes? safe space cultivation? pen pals?

CiviRelate

• created by FatherShawn
• Drupal module that allows logged-in users to create relationships to a new Civi contacts when they enter that new contact’s information through a profile
• First using CiviRegister, another Drupal module which allows someone to fill out a Civi profile and create a Drupal login at the same time
• Does a dupe check and merge for the contact being entered
• Shawn used Coder to check his code
• module is currently in the Drupal.org CVS queue, but in the meantime you can find it on the CiviCRM wiki

Random Notes

• Check out Boost module for sending an entire Drupal site to static pages that are presented to anonymous users

Kyle Jaster from Rayogram

• http://civicrm.org/blog/3711
• Rayogram planned and developed features with the intent to contribute them back to the larger Civi community
• When approaching projects like that, you need to think about how you can abstract your requirements so that they fit more use cases than just yours
• Tackled all of the core-related work first, so that bug fixes got into CiviCRM svn and can be easily pulled to facilitate the more customized aspects of dev for the project

NYSS Use Case

• typical contact tracking with a few custom profile fields
• extensive use of CiviCase and Activities
• integration with legacy mass mail solution (for now, CiviMail possible in the future)
• nearly standalone - very few Drupal features used
• big database, lots of records!

Optimization

• did a lot of testing & improvements to make sure it would work for NYSS
• many of these improvements will be part of CiviCRM 3.2 release
• worked with core
• memcache support
• Apache Solr search

Front End

• usability improvements, new features, increased “themeability” of CiviCRM
• usability improvements
  • formalized the workflow in the UI - built in ways to go about the work (search, view, edit, repeat) - make that implicit in the UI
  • pulled out nav bar to avoid confusion for end users
  • consistent styling of forms
  • clean up look and feel, reduce visual clutters
  • restyled Contact Summary to reduce visual noise
  • unbolded field labels so that content is more prominent and easily scanned rather than focus on labels
  • when clicking on help links, help pops up consistently in one spot (for them, bottom right corner of the screen)
  • looks like they somehow implemented vertical tabs?
  • increased quality of page titles - things that you’re doing are laid out in the page title for better context
  • buttons: added semantic icons to buttons
  • themeability and design tweaks
  • separate out structural CSS, eases dev work in refining UI, prep future “custom css” directory
  • vertical tabs that are shown in demo aren’t going to be in CiviCRM core yet, but Kyle will publish the CSS
• New Features
  • context-sensitive Actions module
  • ability to edit contact info from any screen, not just returning to Summary
  • Summary Overlay - as of 3.2, when you hover over a contact in search results, it pulls up basic profile info
  • Free-Tagging Contacts, Cases, and Activities
  • reserved = not editable by a general user
  • CiviCase dashboard elements as dashlets on Contact dashboard

What is a module?

• allows you to extend Drupal without touching Drupal core code
• wraps related code into packages that can be used in other projects or shared with the entire community
• allows collaboration with the community with common standards

Different types of modules

• Glue modules: put little changes that you need to make to the way that Drupal is processed - not things shared on d.o, but created to achieve specific small things on particular site(s)
• Input filters: take input from users and convert them into something more fantastic (e.g. PHP Filter, Markdown)
• Module plugins: extend established modules that have their own APIs (e.g. Filefield, Views Custom Field)
• Utilities: provide tools for other modules (e.g. token)
• Navigation (e.g. admin menu, teleport)
• Administration (e.g. Admin Menu, Dashboard)

What to ask yourself before you start coding one

• Why am I doing this? Is it really needed? Are you just scared of looking for other modules, installing them, and still not getting what you want?
• Reasons to conquer fear-driven module creation:

1. Time is important
2. Forks suck - can’t split resources, dev time, user base with multiple solutions
3. Your reputation is at stake - people will call you on duplicating existing modules

• Reduce risk progressively. You can’t know everything about every project out there, but every time you think you need custom code, do this first:

1. Do a Google site search of Drupal.org to try to find something that does what you want to do
2. Start talking to real people on Drupal User Groups, groups.drupal.org, and IRC to see if they know of an existing solution.
3. Install a few modules and play with them, exhaust what they can do so you can learn more and more about existent tools
4. Grep an entire contrib repository for what you might need

A few more things before you start…

• Assume your code will be shared and follow Drupal coding standards
• Negotiate the time you’re going to put into this - make sure you have enough time to make it look good!

Methods for starting

• Gut (copy and empty) another module
• Frankenstein (copy and paste from other modules)
• Cheat (use templates)
• Ninja (compose from scratch/memory)

Let’s pick a name

• Check out contrib from CVS and scroll to make sure your name doesn’t exist
• Or do a Google search of Drupal.org
• You’re going to be using the module name in all of your functions, so choose your name accordingly (not too long, not too funky)
• Using module name in core files, so keep it short
• Use all lower case letters and underscores rather than dashes

Start building

• Put your module in /sites/all/modules
• create .info file in your folder; your module will now show up in admin/build/modules
• create .module file in your folder; when you enable your module, code in there will execute
• Add other files to your module: JS, CSS, and module broken down into .inc files if necessary

How do modules add or extend functionality?

• Through hooks, which hook in processes
• You don’t need to start from scratch because of hooks
• Example Goal: redirect user to appropriate taxonomy term page after submitting a recipe. To do this we’ll use hook_form_alter(), use the Devel module, and Drupal API reference.
• Form API - simplifies working with forms. Forms described consistently as PHP arrays, have control over access, validation, and submission, and provide added security

Demo, watched but did not take notes

Changes in Drupal 7

Breakout conversation: CiviCRM and the Drupal Community

notes started partway into the conversation

• How does a person contribute in bite-sized chunks to a code base that is monolithic?
• You can write Drupal modules for CiviCRM - that’s the best way to extend CiviCRM and is a recent development with added hook support
• Drupal has Form API, CiviCRM has Quick Form - you have to be willing to make that leap and learn something new
• there’s a big gap between the users and the developers
• there seems to be a Drupal/CiviCRM PR problem
• CiviCRM can either be broken down into smaller modules are not; just have to make a strong decision and stand behind it.
• Need to put projects out there that’s well defined for people to work on. Give people more concrete ways to get involved. Give specific points of contact for the work.
• CiviCRM is changing. In recent years the concepts of components have appeared, making things more modular; the API and hooks are better developed
• The thoughts that are going on internal to CiviCRM developers that might please Drupal folks need to be publicized better
• Thoughts about having Minimal and Standard installations (maybe Custom too) similar to Drupal 7 installation
• Could have a packged up Drupal/CiviCRM installation to make things easier
• more training videos and materials
• aesthetic differences between Drupal and CiviCRM can also be challenging when going from the former to the latter
• Large CSS and templates cleanup is underway for CiviCRM
• idea to develop a guide to CiviCRM for Drupal developers to ease transition, point out parallels
• modularize WYSIWYG so that people can choose to either use CiviCRM-bundled WYSIWYG or Drupal WYSIWYG API module

There were about 12 participants in the conversation; folks who were here and who were not are encouraged to add their thoughts, fill out these notes, say “I was there,” etc!

(notes starting partway into the session)

• There’s an opportunity to grow Drupal if we can start to get at the diversity conversation
• definition of Drupal community is problematic - very technical requirements, but there’s a vast community that aren’t people who aren’t on D.o or have cvs accounts, implementers and users. Developer-centric approach is limiting. Rise of “themer pride” and project management props makes a difference.
• The “do-ocracy” is so spread out that there’s never going to be a technical definition of degree of participation in Drupal; makes it easier to inherit biases in society
• Power is still based on very developer centric values, e.g. webchick was nominated to make the LGBTQI g.d.o group because she wouldn’t get messed with because of her high stature as a dev in the community
• in any community it’s important to create a sense of openness - not just inclusiveness but many paths to involvement, recognize importance of other roles that extend platform to a broader audience
• primary problem of Drupal community is creating a platform that is usable, extensible, etc - this problem benefits from a diversity of perspectives on all levels, will result in better solutions
• there’s definitely “#notadeveloper” scoffing attitude in the community
• Drupal as an entity is not in the position of building on-ramps. While within the community there are real tensions along lines of identity and privilege - same as larger society - don’t see a specific on ramp barrier to people with lack of privilege
• do-ocracy isn’t a problem when
• problem is who’s going to do anything about this? Drupal Association is the only official entity, could they espouse values of diversity, inclusion, non-discrimination and “enforce” by vocally disapproving when things like the image on the Drupal Card Game goes down
• class is another big vector of power and privilege, but not always as visible a marker as race/gender/sexuality - might be a foothold
• we might have more success with stopping nasty things (i.e. sexist comments/images) from happening than trying to get buy-in for proactive diversity
• what’s the process for handling when “bad things” go down in the community? what recourse to people have if things are going on in the community that are outside of the spirit of Drupal?
• there has to be individual accountability
• some distrust of looking to higher authorities for enforcement
• is it possible to charter local groups?
• false notion that safe spaces organized within Drupal Community like groups.drupal.org will not actually result in better technical products, code, etc
• demonstrating ability for Drupal to be more accessible, egalitarian, open is important
• q: have people ever recruited others to Drupal, especially others who don’t look like others in Drupal?
• a: HopeFoundry - taught non-programmers Drupal, 1/3 of them are becoming active with Drupal, some of them have provocative stories that need to be told, a model that can be replicated. Do it at an application level, you can choose to be diverse
• “Drupal = a big building with no doors on the ground floor; if you go around back and up the stairs to the IRC channel you can find a way in”
• In any community, the most influential people are the most invested. As communities grow the core group starts to expand as well. Community can occur organically if more people buy in and do something about it, build on-ramps to Drupal, on small-scale/individual levels, makes the community evolve.
• Do we feel comfortable bringing people in to Drupal who are not part of the majority/privileged classes in Drupal?
• Bringing people like me (in this case queer, poc, politically left) would not go so well, afraid they’d just get pissed and never come back
• Some people are activated by getting pissed off, some people are turned away - they deal with this throughout their lives, don’t want to deal with this
• Encouragement for people to write blog posts, public thoughts on what we discussed here, get it out there
• The people in the room have it in us to change things
• Focus on ground up, grassroots response and action on these issues
• We need more models for training and curriculum to bring more, different people into Drupal

Starting Out

• going from contractor to shop = making a lot of mistakes and surviving them

defining the type of shop you are - what are you selling, what is your market?

• identify your team’s strengths and go with them, but also be adaptable in case your market shrinks
• CivicActions - thought they’d be leading shop for political campaigns and candidates and nonprofits - they’re a mission-driven, values-based company and choose clients accordingly. Quickly dropped notion of working for political candidates & shifted to large international nonprofits. Also use Agile project management, so they have ramped up competency around working with clients and bringing in projects on time and on budget
• figure out what you really enjoy doing and what you’re good at, focus on that

Mission Statement & Business Plan

• you should have both of those early on, but those should be changeable and adaptable
• these help you create your website content, in your proposals, etc
• think about the value proposition that you bring to your clients
• do what you do best and outsource the rest - the skills necessary to build websites are not the same skills you need to run a website-building business

Partners?

• Find people who fit good roles. If you’re a dev, find a business person, or vice versa.
• Define roles for each partner
• Partners need to help boost each other, split tasks
• CivicActions started by 3 partners, were at 13 partners at peak, now at 9. Transitioning from LLP to C-corp. Business structure impacts liability, ability to raise capital, tax structures, and decision making structures. Need to be really clear about corporate structure, decision making, and responsibilities. Don’t need to be set in stone, can rotate or swap tasks.
• Sometimes partners are more affordable than employees.
• Good idea to have a business-focused partner and a tech-focused partner.
• Have to have clear expectations for each partner - clear responsibilities, make sure they’re aligned.

Management

• Remove vs office - sometimes being remote takes too much time to communicate, for some people it works better to work together in person.
• CivicActions: intentionally remote, no office, let people live wherever they want to live. Business units or teams called “pods” will get together to sprint for a week at the beginning and ends of projects. Face time is important early on and throughout. Get together at DrupalCon, other conferences, video conferencing, phone calls
• If you’re a “virtual” or distributed company, the overhead you save on rent, office, etc can be devoted to getting the team together in person
• Have people who are willing to be flexible, work across timezones, are responsible and dedicated

Bids, Juggling Projects, etc

• Advice = don’t do fixed bids! Irresponsible to your shop and to your clients, especially when working with unpredictable open source.
• Juggling more and longer term engagements - you need a business person to juggle all the moving pieces internally and externally
• Balancing contributions to the community vs client work - balancing internal business dev with client work is also very difficult (building biz, website, documentation, etc)
• share back with the community - write up what you’re doing, share your products, write up case studies and white papers. build personal brand.

Investors & Growth

• investors and loans? CivicActions bootstrapped the company, never took out loans or got investors. Advice: if you can’t do this without capital, you might not want to do this now
• Another company did take out loans to facilitate staff growth
• CivicActions project estimating worksheet - very useful
• get advice from other shops, open source community, get advice from friends and family
• if someone’s trying to pressure you into doing a fixed bid, you can give a “best estimate” range, do best to come in the middle
• educate clients so they’re okay without fixed bids - provide estimates with an asterisk,
• prioritize the important pieces from the RFP first, do things in order of priority, if you hit the end of the budget it won’t be such a big deal to leave the little details off
• get a lawyer, get an accountant! start out with good contracts revised by
• CivicActions doesn’t employ people, they have contractors

Sales and Marketing

• create reusable templates for RFPs, Estimates, and Proposals
• demonstrate & publicize community participation and contributions - meetups, camps, local community sites, conferences
• contribute! in open source as in academia, publish or perish
• develop or claim modules or other products in desired markets (e.g. mapping, media, mobile, etc)
• make friends with the “competition”

Basic Roadblocks to Progress

• Cashflow is King! Especially once you get employees, since partners don’t necessarily get on payroll.
• Get upfront money on projects. CivicActions does a monthly upfront; you can ask for half up front for the project, things like that.
• Charge finance fees on late bills
• Don’t get too excited about the high points, don’t get too scared about the low points
• Have a clearly defined payment schedule in proposals and contracts
• Taxes - very hard to anticipate, have to anticipate
• Accounts Receivable = what you’ve got invoices out for that you haven’t gotten paid for yet, have to stay on top of this and do your best to collect

Get Help

• SCORE - Service Corps of Retired Executives, SBA, Business Schools (sometimes they can give you interns)
• Collaborate with other shops
• Consultants email lists

My questions

• pacing growth (staff AND projects)
• speak to the shift from contractors to full-time employees
• if you don’t use fixed bids, what do you tell your clients, ESPECIALLY nonprofit clients?

Panel of the people on this page, also listed below. Sorry for lack of attribution for each comment!

How has managing a Drupal firm changed over the years?

• the focus of a firm is often inward; as Drupal has changed they’ve had to shift to focus outward. As Drupal grows, community grows and you have to be a part of it in order to be successful. Volacci has a partner program where they form relationships with other shops, build and nurture relationships as communities grow
• Used to have to sell Drupal to clients harder, but that’s eroded and changed over time - people started calling them
• As Drupal shops start to appear & Drupal gets higher profile, more competition forces shops to innovate and do things better

What are some of the best decisions you’ve made in your shops?

• working with Drupal is the obvious one
• team relocated from small town in Virginia to a larger city - able to attract and maintain good talent more easily
• a different attitude towards telecommuting
• process is important, but it’s also important to show your clients how your internal processes add value for them
• focus a lot of time on getting team to dance well together - it’s expensive, but everyone who comes into Development Seed gets Getting Things Done and Made To Stick. It’s very difficult if you don’t create a culture, have a consistent base within your organization, creating a GTD culture and having a common lexicon. Two other books for management specifically: Good to Great (prevent burnout!) and Getting to Yes (help decision making process as a team)

Context

• Eric Gunderson, Development Seed: 17 people
• Dave Terry, MediaCurrent, 12 employees, started focusing on Drupal in Fall 2007
• Jon Clark, design group, 6 member team, denver, 4 years in Drupal
• Ben Finklea, Volacci, 60 person firm in Austin
• Jeff Walpole, Phase 2, 32 people, founded in 2001, Washington DC
• Glenn Hilton, ImageX, 12 full time, founded 2001, started Drupal in 2005

Where do you go to recruit good people?

• As an owner, start with culture and vision of the company
• Get a lot of great people from Craigslist - Volacci finds lots of people who do good stuff that’s not Drupal specific well and teach them Drupal
• determine what percentage of management time is appropriate to dedicate to recruitment
• get the wrong people off the bus, get the right people on the bus.
• Always be recruiting, always on the look out
• Keep feeding work to freelancers and look for people to bring onto your team
• Read a book called Who
• call up colleagues & other companies to see if they have good leads on new talent

How to retain employees over time?

• find good fits, self-motivated communicators
• foster a good work culture & environment
• client work is training; product work can be more rewarding. Product culture is essential for staying sane.
• Need to find good structure early on for crafting contracts
• Development Seed basically fix prices solutions that they deliver, which is terrifying.
• Figure out a way to fix scope and be stubborn with clients
• It’s your job as a manager to facilitate your team; crazy client stuff will break down your team
• key to keeping employees is the direct relationship with owner or supervisor - that’s what will make them stay or leave. That comes down to communication. High salaries won’t do it.
• One perk: $2500 per year tuition or education reimbursement. Continuing education is a bigger perk and advantage than money. Send people to DrupalCamps and DrupalCons, get books, etc. Ask for knowledge share in return - e.g. 15 minute debrief at staff meeting.
• Culture of open communication and truly open debate. Not just token opinions, but real debates that change the way company works fosters ownership.
• Hire slowly, fire fast - don’t keep people who don’t work well.
• Volacci has no vacation policy - don’t track vacation, yet to have anyone abuse that. Go as long as you want to, but don’t drop the ball and get your work done. Have a weekly Volacci University - someone teaches a 30 minute course to the company on anything they want. Every Friday is WIFLE - What I Feel Like Expressing - each person has an opportunity to express anything they feel like expressing. No one can talk while you’re talking, everyone thanks each other for sharing, opportunity to get issues out and off chest. Rule that you leave it in the WIFLE. Also have weekly kudos meeting. When you get a kudo, you get to take a Pez dispenser from anyone in the room white elephant style

What’s the most useful technique for getting/increasing sales?

• Must create relevant, fresh content - blogging, white papers, whatever
• Form partnerships and alliances. Some of your best projects will come from other Drupal firms. Outreach to larger firms, ask for their leftovers, work on smaller projects which lead to bigger engagements and form alliances
• Contribute back to the Drupal community
• Blog posts take time, need to be strategic. You can make concrete, specific posts about technical problems and how they’ve been solved
• Errant volume in sales is as destructive as errant volume in recruiting. Better to grow slowly to get the right sales and the right clients, otherwise you’ll lose focus and go where they want to go and not where you want to go.
• Find a niche and be the best possible firm in that niche

Presented by Jeff Miccolis of Development Seed

(missed most of the beginning, talking about features and exportables)

• Ctools is special
• Strongarm gives you access to the variables table — start to capture values from variables table
• these components are the configuration that descirbes how your site behaves - Strongarm lets you bring out and safeguard those important decisions
• Features should be used throughout the development process - not intended to come up later, meant to be there the entire time.

Creating a Feature

• Create a feature through the Features UI - add in various components
• Once you’ve built the feature, Features module gives you a way to see the status of the feature; lets you track whether any elements have been changed or overridden from what you set in your feature. Click Overriden, gives you a diff
• Using the Features web UI you can create a new feature, make updates to existing features, or revert the changes made from the prior iteration of the feature
• Drush has many Features commands - features (list all available features), features-export (export a feature from your site into a module), features-update (update a feature module on your site), features-revert (revert a feature module on your site)

Example of Features in development:

• Alex makes a feature
• Jeff pulls it down from version control, adds a couple of views to the features, updates the feature and commits in version control
• Young adds theme overrides
• Alex fixes Jeff’s and Young’s bugs
• Alex rolls the feature out
• Jeff makes views adjustments - when he clears his cache all of everyone else’s changes to the feature reappear on his site
• Rolled out.
• Alex makes views adjustments to fix Jeff’s…
• Young makes adjustments
• Roll out again
• Views changes are only made once. No need to manually copy stuff down, make changes on production AND staging, etc. Each change has a commit log within version control because everything is done in code.
• Process helps you avoid dumb errors; provides more accountability (making sure what you do is properly there; less likely for someone else to screw it up later; easy to enforce what’s been done and figure out who did it.
• Overhead of staging goes away; go straight from dev to production.
• Not having a distinction between configuration and code is bigger than just this: you’re able to maintain something like Open Atrium

Features for exporting Features as modules

• First: sequential IDs on configuration is the enemy. Use a machine name as the primary idea
• Second: when in doubt, use Ctools (http://civicactions.com/blog/2009/jul/24/using_chaos_tools_module_create_exportables)
• Your job: database schema, UI
• Ctools’ job: loading and exporting your configuration
• What’s left: dependency detection, which is optional but useful
• hook_features_export() - lets you add modules, add components, allows for delegation

Best Practices around building Feature modules

• Kit - the goal is to offer a straightforward base package for building state-of-the-art Drupal sites while specifying how Features built on top of Kit can be compatible
• Kit includes Feature and Theme specifications
• kitf (feature specs): unique namespaces, user roles & permissions, variables, paths & menu items, block visibility & theme regions, dependencies, problematic components
• kitt (theme specs): regions, page template variabls, element attributes
• these are currently working documents based on developer feedback

Distributing Features

Presented by Larry Garfield (Crell) of Palantir.net

The Views Stack

• Views are a three-part stack - how Crell explains to clients
• bottom of the view is the What Level - what data am I looking at - narrow down your entire database to what you want using filters, args, fields, sorts, and relationships
• middle is How level - how data is displayed - styles, flows, pager, and area
• top is Where Level - Display (e.g. block, page, panel content pane, RSS feed) - also now includes Access and Exposed Form
• this maps to the Views UI

Views Plugins

• themable: display, style, row style, pager, exposed form
• non-themeable (logic and functionality): access, argument default, argument validator, caching, query

Types of Handlers

• Fields (Views fields, not CCK fields) - SELECT part of query
• Filters - WHAT part of query - condition that’s hard coded into the view, though users can change the conditions
• Arguments - a contextual filter, the value of which is built dynamically by something in the environment. By default on a page display that’s pulled from GET but doesn’t have to be in other display plugins.
• Sorts
• Relationships - essentially a JOIN to grab fields from a variety of different base entity types, lets you do a lot of amazing queries more prettily than you can do with your own SQL queries
• Area “plugins” - new in Views 3, should be plugins but handlers - replaces Header and Footer text from Views 2, but now this is pluggable

(left session)

Presented by Michael Morris and Dave Leonard of Phase 2 Technology

How to work with stakeholders

• give people a proper introduction to Drupal - lots of weird terminology, figure out how to explain it clearly and properly
• explain open source - talk about the community, understanding what free means (as in speech, not just beer), make sure they understand that you might share the work you do for them with the community
• expalin that Drupal isn’t magic - takes time, work to get a good site
• Set expectations properly - make sure you present realistic timeline, 3-5 month timeline is reasonable for most Drupal sites from start to true finish - QA, testing, fixes, content posted, etc
• Communicate effectively - recommend using tools like Basecamp or Open Atrium, have a project portal to communicate within team and with client. Supply status reports with regular updates about tasks completed, pending, late, to be started or completed. Have regular meetings with clients.
• Drupal can be difficult to grasp at times.
• Train stakeholders properly. In-person training is the best solution. Give administration guides, though find the balance; want to avoid too much documentation that will get stale. Minimalistic starter guides are a good approach. Short screencasts are also useful and can be linked up within admin interface itself.
• Encourage early stakeholder testing. Are the details right? Does it actually meet their needs? Want to find this stuff out earlier rather than later. No substitute for having site owners/users actually using it. “If you have a site launch in two weeks and your site owners haven’t used it yet, you’re probably in trouble.” Does it look great (to the stakeholders)?
• Hard projects need stakeholder involvement. Make them part of the team, help them help themselves, hold them accountable for their own success - they’ll be working hard on this site, too.

Executing on difficult Drupal projects

• Understand the Drupal learning curve. There’s a wall you hit when you get into Drupal really deep; need to understand this so it doesn’t surprise you mid-project. Prepare yourself for mistakes, learn from them.
• Put the right project team mix together: project manager involved through the entire course of the project - risk negation, status checks, accountable for stakeholder satisfaction; analyst to define requirements and do testing, transform needs into defined, achievable tasks; designer; web producer; developers (maybe 1-3, someone primary)
• Encourage role flexibility. Don’t be a baseball team (each person only covering the immediate area around your position). Be more like a soccer team - follow “the ball” around, don’t be afraid of taking on other areas
• Be agile and manage scope effectively. Look into actual Agile workflow. Set sprints, iteration goals and planning meetings, work through the project like that. Don’t have to necessarily define everything up front; try to do it in chunks while managing scope effectively. Be firm on scope but flexible on features; prioritize properly, get the right things in first and push others into the backlog. Open backlogs up to your clients.
• Foster intra-team communication. Consistently use good task management tools (Phase2 uses Jira). Use real time communication.
• Insist on quality from team members: not buggy, not sloppy, everything covered.
• Hard projects need right team and good processes; have a multi-disciplined team that understands the Drupal ecosystem and an agile approach that allows for flexibility.

Defining scope and requirements

• Start digging! What are the site’s goals? Who is the audience? What is the focus of the content? How do your editors work? What are other sites you like?
• Requirements toolbox: site map, wireframes, specs, system diagrams, design comps, user surveys, user stories, style tiles
• Create a site map to define the breadth of a site, navigation (primarily good for visualizing hierarchical navigation, not so much contextual navigation)
• Brainstorm and sketch layout ideas as a team
• Create detailed wireframes with detailed annotations; someone can look at them and really understand how their site is going to function.
• Don’t neglect the details. Get all the way into the nitty-gritty in the upfront planning process to save time during the build out.
• Document integrations with system diagrams - how the site you’re building integrates with the entire ecosystem of the organization (e.g. CRM tools, syndication, content import or export)
• Document the specifications somewhere where internal team and client can see it.
• Meet design expectations; wireframes often aren’t enough to ensure client satisfaction with end results.
• Hard Drupal projects make defining requirements even more challenging. Use proven analysis techniques. Don’t neglect details. Don’t focus on just the website - think about the whole system.

Addressing common challenges

• Replace (clients’) bad habits with good ones. Don’t get surprised by old, leftover expectations about workflow.
• Structure content properly.
• Pay attention to permissions; sort out who is allowed to do what.
• Use taxonomy effectively.
• Present a clean admin interface and give clients a good editing experience. Use a WYSIWYG that works smoothly and properly.
• Allow editors to curate and innovate on their website, e.g. editors’ choice features on the site that can be implemented easily by site editors.
• Provide for editorial workflows that work well, smoothly, allow for fine-grained control. Implement presets that anticipate how things will appear on the site.
• Represent content relationships correctly.
• Differentiate between authors and users as necessary. There might be multiple authors or non-user authors that the default Author field can’t necessarily handle.
• Improve search with Apache SOLR - lots of big improvements, allows for great filters, bias search results
• Pay attention to roles and permissions.
• Migrate content accurately. Have a solid understanding of what they were doing in their old system so that you can carry legacy items over when they’re needed. Check out Migrate and Table Wizard for as much of the heavy lifting as possible, but you may need to do some more cleanup work; the earlier you can evaluate the complications there, the better.
• Hard Drupal projects have a more diverse set of challenges to solve. Use Drupal features and functionality the right way. Meet the needs of editors and content writers. Solve problems with the right techniques.

Q&A

• Q: How much discovery in the sales process, pre-contract and payment? A: Learn as much as you can at the outset though set boundaries, sometimes need to charge for it. The more info you know, the better an estimate you can give your client for the project (timeline and cost)
• Q: Firm on scope, flexible on features? A: Give a budget estimate and try to stick with it; sometimes they do fixed price, sometimes they do time and materials. Have to bound the problem; be firm on scope so that if big huge things are introduced you can say no
• Implicit Q and A: site maps, wireframes, etc are packaged as deliverables, artifacts are visible to clients
• Q: How does training work? A: Usually build in training time; minimally do two big training sessions (2-3 hours) for each project, along with lots of preparation. Usually throw in 3-4 working days of training prep and delivery. Alpha release, training, then hand the keys over to clients for initial use and testing. No one gets site use access before the training session.
• Implicit Q and A: build analysis and discovery into the paid process of the site building, hope you made good estimates in the proposal process. If the estimates are off, gently ask for more money, try to reprioritize, slow down expectations so that they have a chance to see how a Drupal site works before adding on more features.