WHY BLOG?

• Blogs are about STORYTELLING
• Blogs are PERSONAL and PASSIONATE
• Blogs are your organization’s editorial page
• Blogs let you cover yourself - your actions, your events, your work - in the way YOU want to
• Blogs let you cover/applaud/condemn/call out others without a major campaign or action or huge effort
• Blogs are a way to incorporate and highlight the voices of many people in your org/movement - not just staff

QUESTIONS TO CONSIDER

• What is the point? Is there a point? “Everyone’s doing it” doesn’t cut it.
• Does blogging fit with your organizational culture? Blogging when done right is more anarchic, less controlled, whether in content or comments.
• What will you blog? What’s considered on topic or off topic?
• Who will write on your blog?
• What will the editorial process be? How will you regulate what people post without making people feel silenced, reined in or censored?
• Who are your audiences - intended? Who do you hope to reach with your blog? Who do you think you’ll reach with your blog?
• Who are your unintended audiences? Who will unfortunately reach your blog? How will you deal with them?
• What is your tone? How do you want to engage with people on your blog? Do you want to preach to the choir / rally your allies / screw the people who disagree with you? Do you want to change people’s minds, speak more gently to people who may disagree with you? Do you want to convince people of your politics, simply put them forth, or shout them from the rooftops… of your blog?
• Comments - will you allow them at all? If you do, how will you moderate? Will people be required to register in order to comment, or will you allow for anonymous comments from unregistered users? Will you put forth a detailed comments policy? What comments will you delete? How will you deal with people who claim you’re censoring them? Will you feed the trolls (or allow them to be fed) or will you adamantly not do so/ask people not to? When is it time to shut down comments on a thread? Will you set your blog to automatically close comments after a certain amount of time so you don’t have to deal with stale comments for eternity?
• How will comments affect the people writing on your blog? The rest of the people in your organization? Your members, your constituencies?

TIPS

• Great resource: Nonprofit Blog Carnival Roundup: How to Create a Juicy Nonprofit Blog
• sharethis/addthis button - make it as easy to share entries as possible
• capacity - honestly assess your capacity to keep it fresh
• many people = many styles = many more chances that someone might like what you say
• identyfing info for bloggers? protecting bloggers
• timeliness - keep it current, don’t blog about things that are stale
• guest bloggers - try them out, you don’t have to commit to bringing them on permanently
• Integrate your blog into your main site - blog as part of main site, feeds, featured blog entry, etc.
• Free tools if you can’t blog directly on your site: WordPress.com, DrupalGardens.com (probably overkill), Blogger
• READ OTHER BLOGS - other blogs in your field, allied organizations, big blogs, enemy blogs. Get a feel for the “blogosphere” and become a part of it.
• Keep it short! (Especially at first)
• If it’s long, put it “behind the cut” - show a shorter teaser on the main blog page
• Use visuals - photos, graphics, maps, videos
• Have good bios for your contributors - let people get to know them, care about them, like them, trust them
• Link out to get links back
• Regular themed features - e.g. book review Tuesdays, great news articles Fridays
• Get hooked into blogging carnivals on your topic to reach a much wider, already interested audience. You can even try to host one round of a carnival, thus reaching an even larger audience.
• Connect with the “big” blogs that are related to your organization’s work. Make sure they’re aware of your blog; hopefully they’ll pick up stories from your blog and expose them to a wider audience. Once you’ve established your blog and have built a rapport with them you might also ask for a guest blogger spot on their blog (writing posts on their blog that you can also cross-post on yours) or ask them to guest blog at yours.

• Actions and Triggers - ways of creating automated functions (actions) when a certain condition is met (trigger)
• Without writing code to refine what the trigger was, couldn’t get specific enough
• Rules module gives more fine-grained control through the web interface (e.g. when someone creates a node of type x, send an email with this specific text to users of y role.)
• As with Views, it looks like Rules will be widely adopted because module developers are hooking into Rules or exposing their modules to Rules

Looking at Rules

• You can import and export rules, put rules into a module or features to store it as code under revision control
• “Content is going to be saved” event - when content is being added to or updated, happens in that moment in between hitting save/submit and it actually being updated
• (watched a demo of a rule being set up)
• There is more than just AND logic available for Rules; can configure OR and ELSE as well
• Performance issues are present; best way to avoid them is to put your most important condition at the very top, e.g. if a rule only applies to members of a certain role, put role membership check is happening as early as possible so the other steps don’t have to run

Centralized Version Control

• Requires a central server where the repository lives
• In order to interact with the repository, you must have network access and contact the central server
• Actions must be communicated to the central repository in order to be recorded and versioned; can’t commit remotely
• Once a change is committed, it cannot be safely edited; a second commit must be made to undo it
• Once you commit, everyone else can download your changes… even the bad ones
• These issues with centralized version control discourages people from using version control, committing frequently, etc

Decentralized Version Control

• No central server is required. Changes can be sent to or received from any repository at any time, or not sent or received at all.
• Most actions are local; changes only need to be shared with remote repositories as desired and when convenient
• As long as a commit hasn’t been shared with anyone else, you can edit it or undo it at will
• Others have access to your changes only after you share them; your local history is therefore separate from the remote history.
• This is more conducive to using version control heavily, making frequent commits

Git Basics

• Getting Started
  • After installation, introduce yourself to git: git config –global user.name “Your Name”; git config –global user.email “youremail@here.com”
  • Download some GUI helpers like GitX or SmartGit
  • Referring to revisions: “ebc344db0404f0ee3a634d4889c101e869a8b419″ is the full commit number but can be abbreviated to “ebc344″; HEAD is most recent commit in current branch, HEAD^ is commit before most recent one, HEAD^^^ or HEAD-3 are three commits back
• Working on your copy
  • The working copy is the files and folders in your project. It represents your project at a specific point in time.
  • But in Git, your working copy is also a full repository; this is where the magic happens, you have every single change that’s been made right there within the history of your working copy.
  • git init - create your repository in the current directory; creates the .git folder within the current directory where your repository lives.
  • git add . - add all of the files in your working copy to your git repository
  • git commit -a -m “Your message here” - Commit all files to your git repository along with an explanatory message describing the commit.
  • git clone [url] - clone the entire specified repository
• Be committed
  • With Git, it’s best to work in small bits
  • Rule of thumb: if you can’t summarize your changes in a sentence, you’ve gone too long without committing
  • Think of your local git repo as YOURS, you can clean it up before sharing, meticulously document your work in small chunks
  • git status - what’s been changed since your last commit
  • git diff
  • git commit -a - commit all updated files (already being tracked in your repository)
• Your Repository
  • Your local repo is yours and yours alone
  • You decide when and what to push to another repo
  • Commit early and commit often; you can always clean up your commit history before pushing
  • However, once a commit has been shared (especially with a central repository) it should be considered sacrosanct since someone else might have pulled down that commit already
• On Stage
  • The staging area (also referred to as the index) is a temporary holding area for changes
  • When a file or changeset is added to the staging area, it is not yet committed to the repository
  • The staging area allows you to build up your commit file by file or even line by line
  • git add file1 newfile folderA/file3 newfolder8 - fine-grained specification of what you want to add to the git repo for this commit
  • Demonstration of staging changes line by line using GitX; look into git add -p to do that from the command line
• Branching
  • Branching is one of Git’s killer features, not because it’s new but because it’s so easy and cheap
  • Branching is a database, another path that we’re working down
  • When working on features, always create a topical branch for the particular thing you’re working on
  • Always working in your trunk/master branch is not a good idea
  • git branch <branch> - creates the branch
  • git checkout <branch> - switch to that branch
  • git checkout -b <branch> - create and switch to that branch
  • Branches aren’t directories in Git; the working copy always contains the state of the active branch
  • Branches are really just pointers to a commit, as are tags
  • Branches let you separate out your work on a particular issue or feature from the master branch; you can do all of your work there, if it turns out to be worthwhile you merge it back into master, if it’s not worthwhile you can blow it away (git branch -d <branch>) and get rid of all those commits entirely
• Out on a Branch (Remote Branching)
  • Remote branches are similar to local branches, except that they can be shared across repositories
  • Remotes are referred to by [repo]/[branch]
  • Most collaborative open source software uses forked repos and shared branches
• Merging
  • Many merges can be done automagically by Git
  • git merge <branch>
  • Some merges will require human intervention with git mergetool
• Rebasing (All Your Rebase Are Belong To Us)
  • Rebasing is a primary function of Git: “redo my changes using another revision as a new base”
  • git rebase
  • In some ways it’s similar to merging, but instead of adding your changes at the end of the stream, it puts them in place in the midst of a stream
  • Rebasing is done automatically every time you pull changes from another repository
  • Interactive rebasing (git rebase -i) allows you to alter your local commits, squash them into one for merging or pushing, etc
• Fetch and pull
  • When you want to get changes from another repo you fetch - git fetch or git fetch origin or git fetch [repo]
  • After fetching you merge the new commits into your local tree - git merge [repo]/branch
  • Pulling is a shortcut; fetch followed by an automatic merge - git pull or git pull origin or git pull [repo]
  • Pushing sends commits to a remote repo; should only be done with canoncial repos (if you want to share with other users’ repos, usually you’ll have them pull from yours instead - git push or git push [repo] [branch]
• Reset (didn’t get covered)
• Gitify your Subversion
  • Git includes a built-in Subversion client
  • Use Git to control your local commits, then push them to a central SVN repo
  • A couple of things work differently, but you still have the full power of Git within your local repository
  • git svn clone [url] - check out SVN repo and put it in a new git repo on your machine
  • git svn dcommit - effectively a push to the SVN repo
  • git svn fetch - works like normal git fetch
  • git svn rebase - a fetch and then an apply (like git pull)
  • git config –global alias.spull ‘!git-svn rebase’ (handy alias to make life easier)
• Git intermediate
  • Stash away your work for now - git stash or git stash –save “short note” - not a real commit
  • git cherry-pick [revision] - bring one commit from another branch into this one
  • Hashes everywhere - everything in Git is referenced by a SHA1 hash; tags, branch names, etc are really just shortcuts to them
• Git tools and resources displayed very quickly, guessing they’ll be in slides or notes online!

• In the beginning, Drupal was very code centric
• if you wanted to make something you coded a module, relied in hooks API, etc
• Content ruled the land (the database), but modules still stored many settings in the database
• Content in Drupal - nodes, friends, comments, votes, users, messages
• Then came the GUI-la Monsters - Flexinode, Views, CCK, Contemplate, Rules, Context - things you’d normally do with code, but now could do through the UI
• Config settings include variables, CCK, permissions, views, contexts, panels, blocks, and rules
• Why should this stuff be in code and not the DB?
  • How do you track changes within the database?
  • How do you revert back when you make a mistake?
  • How do you reuse configurations?
  • How can you work as a team?
  • How can you update settings across sites?
• If your settings/config are in code, you can use version control to handle those thing
  • take your pick, but pick something! CVS (going out of use though), Subversion, Git, Bazzar, Mercurial
• How do we get stuff into code?
  • Some modules provide their own custom export and import functionality - views migrate rules
  • some are leveraging ctools export api (paenls, context, etc)
  • some are adding exportables to other modules or tables (Input Formats and Strongarm)

Ctools exportables

• Tool attempts to solve the common problem of handling exportables.
  • Defining exportables structure
  • Getting the data from the DB and creating the xportable object
  • importing the data from either db or code
• Ctools exportables
  • Need a persistent, unique identifier in the table that contains the object you want to export (the machine name)
  • Implement a few lines into hook_schema() or hook_schema_alter() to get ctools functionality
• So what the heck is Features?
  • Features is basically an exportables manager
  • It creates “features” modules, which are really just normal modules (features is not a hard dependency
  • allows for a gui interface to choose what things you want to export per feature
  • it provides drush integration to easily update and revert changes from the CLI
• What should a feature consist of?
  • Look for logical sections and atomic functionality
  • Examples: Blog, Gallery, Users, Content Type X - these are features on the site that are comprised of content types, views, blocks, etc that come together to create one complete feature on your site
  • Can be traditional code as well: stuff that used to go in helper modules, additional theming, etc. All of Drupal’s hooks are available to Features.

• In the beginning, Drupal was very code centric
• if you wanted to make something you coded a module, relied in hooks API, etc
• Content ruled the land (the database), but modules still stored many settings in the database
• Content in Drupal - nodes, friends, comments, votes, users, messages
• Then came the GUI-la Monsters - Flexinode, Views, CCK, Contemplate, Rules, Context - things you’d normally do with code, but now could do through the UI
• Config settings include variables, CCK, permissions, views, contexts, panels, blocks, and rules
• Why should this stuff be in code and not the DB?
  • How do you track changes within the database?
  • How do you revert back when you make a mistake?
  • How do you reuse configurations?
  • How can you work as a team?
  • How can you update settings across sites?
• If your settings/config are in code, you can use version control to handle those thing
  • take your pick, but pick something! CVS (going out of use though), Subversion, Git, Bazzar, Mercurial
• How do we get stuff into code?
  • Some modules provide their own custom export and import functionality - views migrate rules
  • some are leveraging ctools export api (paenls, context, etc)
  • some are adding exportables to other modules or tables (Input Formats and Strongarm)

Ctools exportables

• Tool attempts to solve the common problem of handling exportables.
  • Defining exportables structure
  • Getting the data from the DB and creating the xportable object
  • importing the data from either db or code
• Ctools exportables
  • Need a persistent, unique identifier in the table that contains the object you want to export (the machine name)
  • Implement a few lines into hook_schema() or hook_schema_alter() to get ctools functionality
• So what the heck is Features?
  • Features is basically an exportables manager
  • It creates “features” modules, which are really just normal modules (features is not a hard dependency
  • allows for a gui interface to choose what things you want to export per feature
  • it provides drush integration to easily update and revert changes from the CLI
• What should a feature consist of?
  • Look for logical sections and atomic functionality
  • Examples: Blog, Gallery, Users, Content Type X - these are features on the site that are comprised of content types, views, blocks, etc that come together to create one complete feature on your site
  • Can be traditional code as well: stuff that used to go in helper modules, additional theming, etc. All of Drupal’s hooks are available to Features.

Notes from Features Demo

• When you look at your list of features with diff module enabled, you can see how a feature has been overridden within the current configuration
• Turning on Strongarm allows you to export variables (from the variables table) into a feature

Command-line features

• Features exposes many commands to Drush that can then be used from the command line
• features revert - revert a feature from the command line; this reverts changes made within the UI to settings that you’ve configured within a feature

Features/Exportable Gotchas

• Some exportables can’t be exported more than once (e.g. can’t re-export a default view)
• Features-revert-all can be dangerous, blow away work
• Not everything is exportable yet
• Revert-all doesn’t work if there’s no diff (fixed recently in dev)
• Dependencies can be tricky.

Developments to watch out for

• Better core exportability in Drupal 8
• Use of UUIDs as unique IDs
• More end-product modules that implement a fully featured user experience
• hook_features_alter() - allow partial overrides that are exportable as well
• Easy Features = Better Install Profiles

Additional Things to See

• http://drupal.org/project/features
• All features enabled modules

• Introduction to HTML 5 book is a primary reference during this conversation
• Is it a good ideal to add a bunch more options, fields, and decisions for what to HTML5ize or not throughout Drupal? This might create some big UI/UX problems.
• Might be better to have all Semantic HTML5 settings on one big page, rather than have the configuration distributed throughout Drupal
• Doing all the config in one place will also give us a really easy way to set all the defaults more manageable.
• However, having all the config in one place AWAY from the creation/edit pages for these entities could be cumbersome
• Can we have the same settings in two places? The Semantic HTML5 module settings page AND the individual settings pages for menus, blocks, etc?
• We’re going to start out in Drupal 6, it’ll be difficult and messy, but we’ll learn as we go and then know how to tackle this in Drupal 7
• If we build an API for this and collaborate with creators of Semantic Views, Semantic CCK, Mothership, etc, might be a great way to go for Drupal 7
• Might never be an API because in Drupal 7 this is going to be done by drupal_render
• We’ll need to include JavaScript to include semantic tags on non-HTML5 compliant browsers
• Our goal is to make Drupal work for HTML5, not to make HTML5 work in all web browsers

Forms and Fields

• Form API gives us a big advantage and many abilities to make changes to any form field
• right now we can primarily work with core and CCK fields
• we can provide support moving forward, but we can’t completely anticipate what other fields will be used for; we can’t inspect backwards
• we can also work with modules like Date, Email
• use the Elements allows module developers to use Form API to get HTML5 form elements into their modules; a separate module would be used to transform core and CCK fields to HTML5 elements
• want to be able to switch fields from “text” field to “email” field; Elements module lets you do some of that already
• we’d need a different module that does what Elements does to core fields
• other things to support with the other module - search (core)
• these modules will override the markup for CCK widgets
• we need to figure out how to override markup for all the fields with HTML5 elements; then we need to figure out how to implement that within the module, allow people to specify which fields they want to override, etc.
• Could also consider getting this stuff into modules (CCK, Date, etc) themselves anyhow to avoid having to develop an entirely separate module

$header and DOCTYPE

• DOCTYPE has to be changed but that’s relatively easy
• Header elements are also done differently in HTML5
• In Drupal, $header is spit out by Drupal
• In Drupal 6, $header is populated by both core and by the drupal_set_html_head function - anything can be put into the $header using that function
• We can tackle this on the module level, but would then need to ensure that the module gets executed last (and other modules are already jockeying for that position)
• In Drupal 7 what you’re adding to headers is much more structure
• Other option - handle it at the theme level using a preprocess function - wind up with an amorphous blob of text that we could regex to replace tags with HTML5, but it’s not foolproof
• A module seems like a headache; a starting point in a base theme might be a better way to go
• If an edge case uses the old HTML ways, the page/site will still work
• If this is done with a module, anyone can do their own HTML5 theme, $header is still printed normally, instead what you get out of $header is now HTML5 instead of the old way to do it
• drupal_add_http_header and drupal_add_html_head are used in Drupal 7, so getting stuff into $header will be much more structured
• We could backport that from Drupal 7, but contrib modules might not work with that backport
• We could implement the backport and append on whatever else was set in the header that isn’t handled by the backport at the end, though that could result in double info
• Are there concerns about the order of tags in the header? Probably tags that have to come after everything else will be appended on the theme layer anyway, and if not it would work if we appended things at the end of the D7-backported $header
• Agreement is coming in this discussion that this should be done in the module level; create a wrapper function that overrides drupal_set_html_head and is a backport of what’s in Drupal 7; modules can use our function if they provide needed information that they want in the header; and if any modules are not using our function to set header tags those are just appended at the end of the $header
• possible module names: HTML5 API, HTML5 tools
• might have implications for limitations on script and styles tags (e.g. IE limitation of number of CSS files)
• The syntax has only been simplified in HTML5, but how do we get in there and alter those variables?

Document Layout Tags

• The new HTML5 document layout tags include article, header, footer, nav
• Much of this is a theming layer issue
• A group needs to get together, figure out best practices, and rewrite node.tpl.php and page.tpl.php for a base D6 theme
• However, some tags come out of core, CCK, and Views
• Some of the HTML that core spits out has theme functions, some doesn’t (e.g. comments)
• We can create a theme function that rewrites and fixes core HTML that doesn’t already have a theme function
• Mothership theme might be a good place to look for existing fixes or a list of possible problems to look at
• Views and CCK - do we fix Views and CCK, or do we tell people to use Semantic Views and Semantic CCK instead?
• Can we wrap our solutions up as Features, perhaps including Semantic Views and Semantic CCK
• One possibility - require Semantic Views and Semantic CCK modules as part of this feature, add a lot of HTML5 documentation to the top of the Semantic CCK form (and Semantic Views too?). We should also prepopulate as many predictable HTML5 settings in Semantic CCK and Views as possible, just like what happens in Semantic Views and Semantic CCK already; in both we’ll be using HTML5 markup.

Menus and other Drupal entities

• there’s a nav tag in HTML5
• Not every menu is a nav, but there are some we know are navs, e.g. primary links and secondary links
• Stuff that only shows up for administrators are second-tier issues for us
• there is some debate about what menus might qualify as navs and what might not
• consider creating a Semantic Menus module
• Though we’re not sure of the way we’ll do it, we do have a goal of altering the menu creation form so that a user can choose to make a menu HTML5 or not
• Other Drupal entities that we need to tackle similarly: blocks, comments
• Config page for the module(s) we create could turn HTML5ing on for particular entities; turning HTML5 on for those entities will turn on

(Got here a bit late, but caught the very beginning of drush command overview)

Handy drush commands

• drush - listing of all the drush commands available to you
• drush status - basic info on your site
• drush sqlc (drush sql-cli) - takes you into MySQL console using the credentials of the site you’re accessing with drush right now
• drush dl <projectname> - downloads code for module (project) into sites/all/<projectname>; can list multiple projects at once
• drush dl <projectname>-<version> - download a specific version of a module, e.g. drush dl filefield-6.x-3.x-dev
• drush en <projectname> - enable <projectname>
• drush up - upgrade code and database for Drupal core and third-party modules
• drush sql-dump - Performs a dump of the current Drupal site’s database. This will vomit it all over the screen, so instead you’ll want to direct the SQL dump to a file using drush sql-dump –result-file=filename.sql or drush sql-dump > filename.sql (and then
• drush cc - clear the cache that you then specify from the menu, or specify within the command as drush cc theme or drush cc all etc
• drush help <command> - get help on the given drush command

Random Notes

• You can use drush in conjunction with other shell commands, wrap drush commands in shell scripts, etc
• Other modules can also expose functionality and add commands to drush, e.g. devel module
• Drush supports the ability to remotely connect to a server - open an ssh connection, run a drush command, and bring it locally
• http://dgo.to/ - Drupal URL shortener AND smartener with quick paths to projects, issue queues, nodes by number, users, etc

Starting Out

• look to other existing shops to get insights into the business of selling Drupal
• Define the type of Drupal/web shop you are. Are you just a Drupal firm? Do you provide other services/products? What are you selling?
• Good to write up a mission statement, followed by a business plan - take the time to look at the market, the other players in the market, assess the cost and payout of the business
• Small Business Association - many resources that you can tap into when starting out, even just as a freelancer
• Cash flow is a tricky thing to handle; need to know how much money you need to get started. Do you need investors? Loans? Are you going to bootstrap it?
• Money comes in through accounts receivable; goes out through payroll, accounts payable, and taxes. Need to have it coming in faster than it’s going out.

Partners

• Who are you looking to partner with? Why? Do you want to stop doing certain parts of the work? Does your shop need skills that you don’t have?
• Define roles for each partner
• Split tasks and responsibilities up
• Keep partners accountable
• Seth - the perfect partner is someone who you don’t agree with all the time, to be challenged

Management

• Remote vs office
  • Being in the same room can help facilitate quick communication
• Managing teams of developers
  • can be like herding cats
  • if your shop sells hours
  • who ends up being a project manager? is that a separate role or can other people take on that role in addition to development?
  • Sometimes developers don’t have good project management skills; sometimes it’s based on scale and you just get to a size where it won’t work
• Fixed bids vs retainers/hourly
  • “If you want a good way to bankrupt your company, do a fixed bid.”
  • Zivtech either sells buckets of time (e.g. 100 hours to be used within a certain amount of time) or estimated costs (here’s the top of what we think it’s gonna cost, if it gets to where we think it’s going to be 10% over that we come back and check in)
  • push back from others in the audience (Liza, Seth) about fixed bids working if projects are managed well, clients not being willing to go for non-fixed bids
  • Zivtech bills based on who’s working on the project; different levels of skill
  • Liza - can be important to have a client manager (not necessarily the same as the project manager)
  • someone else in the room - gives clients deadlines for giving feedback
  • Zivtech uses unfuddle for ticketing, time tracking, etc - has git and svn repositories
  • suggestion: multiply the number of hours you think a task will take by three and you’re more likely to be on target!
• Juggling more and longer term engagements
  • Tricky to figure out how to juggle how many projects you’re taking on at once
  • A key thing is to overbook yourself
• Balancing contribution and business development with client work
  • balance the non-billable hours well
  • make sure you’re charging enough to withstand the time that folks are doing non-billable work
  • Drupal is something of a publish or perish business; you’ve got to put yourself out there, contribute to the community
• Outsourcing
  • a more flexible way to pay people for work than payroll; accounts payable is “pay when you can” whereas payroll happens every two weeks no matter what

Sales and Marketing

• Sales cycles
  • understand how long clients will take to make decisions, sign contracts, send initial deposit and later payments
  • understand how clients’ fiscal years work and how that will affect the work you’re getting
• RFP, estimates, and proposals - understand how your internal cycle works
• MeetUps, Camps, Local community sites and conferences - good sources for new clients
• Contribute!!! in open source! Publish or Perish!
• Develop or claim modules in desired verticals (e.g. mapping, media, mobile, etc) - focus your contributions in the area you’re trying to work with

Basic Roadblocks to Growth

• Cash flow is king!
  • you can demand a certain amount up front from many clients, though some clients will tell you how they’re going to pay; they generally ask for 40-50% up front
• Taxes
• Accounts Receivable/Collections
  • gently but consistently remind clients to pay you
  • make sure you get into your clients payment system ASAP - contact billing right away
  • do regular billing, biweekly or monthly
  • try to avoid being a hard-ass to collect; you’re building relationships, so you want to communicate the need to pay as gently as possible
• Talent
  • can be a huge impediment to Drupal shops
  • you need to aggressively train smart people, not just expect to find all the highly-developed talent you need

Get Help!

• SCORE (Service Corp of Retired Executives), SBA, Business Schools
  • some business schools have programs where they place interns with you for a period of time to assist you in the startup stage
• Collaborate with other shops
• Consultants email list

Questions

• is client acquisition a “hard marketing” expense? As in, something that can be written off?

Admin Themes

• clients/users appreciate a clear visual division between the public front-end view of the site and the admin view
• Garland: out-of-the-box theme that can be used to easily create that visual separation; it’s the easy choice, but there are others that are specifically tailored to be admin themes
• Root Candy: specifically focused on being used on the administrative side; creates tabs at the tops for “root-level” admin items, emphasis on readibility, good table structures
• comes with built-in slide-out control panel that you can drop any block on the site into
• Rubik: another admin theme designed for clear, clean admin with a keen eye to styling messaging, help text

Tools, Toolbars

• Admin module; little wrench in the corner that expands out into an administration
• admin_menu module: gives you a nice dropdown menu across the top of your site (front-end and back-end), a number of functions under the Druplicon dropdown menu

Administrator != Developer

• A menu of quick-links specially created for client administrator can be very helpful
• Modules to build an admin interface:
• Views bulk operations - lets you build a view of content (eg nodes, files, comments) and provide checkbox-style operations on all of the nodes
• Draggable Views - lets users drag and drop lists of content into a completely arbitrary sort
• Nodequeue - one step beyond Draggable Views, does the drag and drop sorting but also controls specific pinpointing of what content is included in what queue, e.g. take ten completely unrelated nodes and put them into one queue
• Panels - you can use it to create a dashboard view of content for your administrators, e.g. a dashboard just for users who are comment moderators

Developer tools & APIs

• Ctools - suite of modules that exist to support other modules
  • includes AJAX library - ideas behind it are foundation for AJAX libraries in Drupal 7
  • Wizard - multi-step forms
  • Non-volatile Object Caching
• Dialog API - merges jQuery UI Dialog widget with Ctools AJAX - do simple form submissions through a dialog
• Features - bundle up all the views for admin interfaces, just like with the front-end stuff

WYSIWYG

• they’ve gotten better at outputting valid (if not entirely efficient) output
• WYSIWYG API is the way to go now; editor specific modules are deprecated
• input_formats - new module that allows you to export input formats as Features code (!!!)
• better_formats - module that attempts to improve the input format specifications of Drupal, default input formats per role (!!!)
• Insert - works in conjunction with imagefields and filefields - get an insert button next to each imagefield, throws it into the body of the node, works with all major Imagefields (!!!)

Random

• Check out http://www.sequelpro.com/ - MySQL management for Mac OS X

• Looked at a non-Drupal site, cnn.com - cramming as much information on one page as possible - they throw as much on the page as possible to appeal to as many different people as possible
• observer.com - a Drupal site that does something very similar
• How do you standardize the display of each piece of content on your site (e.g. pictures in proper sizes, providing all essential data, formatting it)
• economist.com and globalpost.com - more content-rich sites built in Drupal

Imagefield

• let users upload images in a CCK node
• lets users upload multiple images, sort the list to select which is going to be featured on the front page, the others get inserted into the content appropriately and in a consistent way by Drupal
• bulk uploader available

Imagecache

• resizes/crops images on the fly according to your preset dimensions
• helps standardize image sizes across the site
• Imagecache is included in Drupal 7 core, hurrah!
• Imagecache presets stop large images from breaking your layout

Quicktabs

• allows you to combine multiple items into one Quicktabs block with tabs on the top
• Nice jQuery action to allow users to switch from one section to the next, loaded all at once, or via Ajax on the fly
• Plays nicely with Views, individual Nodes, and multiple Blocks

Views Slideshow

• the recommended solution (”best of the breed” according to Seth) for rotating carousel type things

Panels

• Provides a drag and drop interface for units of content on the site to be added, deleted, and arranged in a layout on the fly
• “is all sorts of insane magic”
• pros for Panels - great Views integration, user friendly for non-techie users
• Negative - spans between modules and theme layer, so it’s slower, performance hit on your site, takes a lot of liberties
• If you’re a themer, you might be able to do without panels

Composite Layout

• could be called Panels Light
• gives you the Panels approach but does it on a node by node basis - you can choose predesigned layouts on a node by node basis, e.g. a different layout for each individual blog entry, on the fly.
• Display Suite is another alternative

Vertical Tabs

• for the content adding and editing side of the site - much easier
• divide your node add/edit forms into sections with vertical tabs on the side, collapsed along with a summary of the collapsed settings.
• Makes large content types easier for content producers to maintain
• Drupal 7 includes this in core, Drupal 6 module mostly works well

Arrange Fields

• http://drupal.org/project/arrange_fields
• First commit was 5 weeks ago as of 7/24/10 so is early on, but lots of potential
• “This module lets you drag-and-drop the fields of any CCK content type, Webform, or almost any other form in Drupal into the positions you would like for editing. This makes it super simple to have forms with inline fields, which you can change at any point. Tab indexing is also updated, so no matter how you arrange the fields, the users can still tab through them easily. And, you can now add arbitrary bits of HTML markup– labels, images, HR’s, etc.”

CCK Fieldgroup Tabs

• separate CCK fields onto a completely separate tab to break down long node creation forms

Random Notes

• check out Nodequeue again for arbitrary lists of nodes, drag and drop
• you can feed Nodequeues through views
• Imagefield Insert module
• get good at Views theming - so much can be done!
• My question: what’s the best practices approach to fine-grain tuning of everything via node-whatever.tpl.php files vs doing as much as possible within the CSS. Answer: there are a lot of different philosophies; have to consider how custom and how specific this content type needs to be displayed. If it can be done through CSS fairly easily, go for it; there’s a performance hit to loading bunches of node-whatever.tpl.php vs using already loaded & cached CSS. Theresa says her philosophy is to keep the number of files down as much as possible.
• Omega theme (Theresa: “If Zen and 960gs had a baby, it would be Omega”