• In Agile training today…
• Agile is a learning system. Don’t know where to start, not sure how to do it, don’t have a good working system? Use #agile.
• Nothing is sacred in Agile – continually question and re-evaluate the process and change if there’s a better way #agile #kaizen
• Agile and Time Tracking are incompatible; Agile is designed to get faster – TT has no incentive to get faster. #agile via @mberteig
• Face-to-Face communication is best – agile teams work best in the same space with no barriers #agile @mberteig
• The better the communication, the more effective the self-organization #agile @mberteig
• Great ways to build efficient teams: step one let them self-organize #agile #teams @mberteig
• Remove dependencies; let people start at the same time & work independently to work @ their best pace #agile #teams @mberteig
• Check roles and titles at the door; teams need to be skill-sufficent and aspire to being cross-functional #agile #teams @mberteig
• Have a shared queue for all tasks: people work @ best pace by choosing work from pool of available tasks #agile #teams @mberteig
• Beware of confusing commitment and estimation – commitments aren’t a gamble, which makes them discrete and small #agile
• Scrum is good for orgs in crisis, building a new product. Scrum is hard to do, esp. zero defects. #agile @mberteig
• Return on Investment, Time To Market and Client Satisfaction are the foundation of success metrics #agile
• Task switching ++decreases productivity. Having >1 project in-flight at a time sounds good, but trades focus for mediocrity #agile
• If you don’t have crisis early in a new Agile team, you’re probably not doing it right. #agile
• 1 Team. 1 Project. 1 Room. Zero headphones. You’ll have better communication and be more productive. #agile
• Do It Right, and the change comes fast. Get it Done and there’ll be no change at all. #agile

If I have time, I’ll add some of my other notes as well.

Bitcoin is a peer-to-peer currency. Peer-to-peer means that no central authority issues new money or tracks transactions. These tasks are managed collectively by the network.

- http://bitcoin.org/

Bitcoin has the potential to be a hugely disruption technology – changing business, commerce and politics. Here are some hand-picked articles about BitCoin:

• We Use Coins – An introduction to Bitcoin
• Bitcoin – Obligatory Wikipedia Entry
• Online Cash Bitcoin Could Challenge Governments, Banks
• Is The World Crazy For Bitcoin, Or Has The Bitcoin World Gone Crazy?
• Bitcoin Mining: The Free Lottery
• Senator Schumer Says Bitcoin Is Money Laundering

And, thus, I present Drupal Club:

Without having specialized technical knowledge tied to accessibility, do managers have the skills required to assess if their sites are accessible?  In my experience most managers lack the resources to do any accessibility reviews of their sites and so fall back at best reviewing a vendor’s accessibility statement.

Mike makes a very important point here, that we in the Accessibility community need to do a better job of providing information in a broader way and for a more inclusive audience. So in the spirit of moving away from technical information about accessibility, I’d like to provide something of a response or a compliment to Mike’s article, looking at the answer to the question “What is the cost of accessibility?”

Accessibility Is Cheap

The good news about web accessibility is that there are a number of things that limit its cost. Mike’s article lists a number of free, automated tools to provide accessibility testing of websites – auditing your website and comparing it to an accessibility checklist. In addition to these tools, web development best practices can deliver accessibility wins and they don’t cost anything to use, and there are entire organizations dedicated to helping your project identify and implement these types of practices, such as the Web Standards Group.  Examples of these practices, to share with your developers, include separating content from display, using semantic code – such as avoiding the use of tables for layout, and using options such as “alt” tags .  No only will these practices improve your accessibility, but it will also improve your website’s code quality and Search Engine Optimization. Don’t forget, Google is basically a screen reader; what is good for web accessibility is usually good for search engines as well.

Using Content Management System tools such as WordPress or Drupal can provide significant support for web accessibility. By automating code generation and providing workflow elements such as asking for an alt tag each time an image is uploaded to the website, CMS tools can take on much of the heavy lifting for content developers, allowing them to focus on great content and not getting bogged down in the minutia of accessibility coding. Using a CMS provides many other benefits, making websites less expensive to maintain and easier to manage. Keeping in mind the opportunities to support accessibility when selecting a CMS tool is an important accessibility strategy for management.

The most significant way these practices make accessibility cheap is because they “bake in” accessibility into the foundation of all your web projects. Ensuring accessibility is a core value of your organization and your developers, which means planning for accessibility and measuring for accessibility, is essential to manage the cost of accessibility.

Accessibility is Expensive

Ultimately web accessibility is not about validation checklists. Checklists don’t have experiences; People have experiences. This doesn’t mean that checklist tools aren’t useful – they are; I use them in every web development project I work on. However, checklists can provide a false positive – that is to say, just because a website passes a checklist, it doesn’t mean the site is accessible. In fact, even if a website can demonstrate that it meets every requirement set out by every accessibility standard, it might still not be accessible, because if someone can’t access the content…then the site isn’t accessible. This makes accessibility a very demanding element of web development and design.

Building accessibility expertise in your team is not simple, fast or cheap. Web develop and design have matured from a task to give as a side-task to a sysadmin or programmer into full, professional disciplines. Building professional websites is now a craft and one of the skills of crafting a website is accessibility, something which wasn’t even a consideration in the early days of the web. Indeed, accessibility itself is discipline rich enough to fill entire books, conferences and careers. This doesn’t mean everyone who builds your website needs to be an accessibility expert. However, proven accessibility expertise is a valuable skill and takes time and energy to cultivate. And, as recommended by Mike, it may make sense for you to engage an external accessibility consultant, such as Ottawa based Further Ahead.

The most common way accessibility is expensive is when it is a project afterthought. Much like security or information architecture, accessibility is a fundamental part of a high-quality, successful website. As work on the website progresses, it will become progressively more and more expensive to include effective and thorough accessibility. Building the value of and expertise in accessibility in your team, through training, hiring and engaging consultants when necessary, all work to help manage the cost of accessibility.

Planning for the Cost of Accessibility

Bill Graham of Wind River, a subsidary of Intel, write this about the cost of fixing bugs:

We intuitively know that defects in the field are much more expensive than those found in development. In fact, the difference is bigger than you think. If you find a bug in-house you save orders of magnitude in time and money…Take a look at this diagram (from www.agitar.com). Cost to fix bugs rises exponentially as you move down the development timeline. After you’re shipping your product, the cost per defect has increased 640 times!

What if we consider accessibility problems in our websites the same as bugs in our software? If we take this perspective, then we see accessibility problems as something that is a requirement to fix. Data on the cost of fixing bugs shows us the key variable in managing these costs is doing this work as early in the project as possible. The later in the project a bug is identified, that is to say an accessibility problem is identified, the more expensive it will be to fix it. Now, accessibility fixes may not follow this exact pattern – I’m not saying the cost per defect for accessibility issues is 640 times higher after you ship a website. But I do think the general principle we see here holds true for accessibility issues. It is tempting to thing of functional bugs as something different from accessibility bugs, but keep in mind that if someone on your website can’t access a function, it’s no different than that function being broken.

To plan for the cost of accessibility in web project, it is critical to include accessibility in the project plan from the very beginning.

To plan for the cost of accessibility as a competency on your team, it is critical to include it in your talent development and retention strategies. With legislation such as ADA in the US, AODA in Ontario and other laws in other jurisdictions, it is clear that the legal requirements for accessibility are not going anywhere and will become more strict over time. Adding the accessibility dimension of expertise to your organization will take investment, commitment and time.

I hope this article provides a useful and accessible summary of some of the key issues about the cost web accessibility for managers. What insights do you have? What are the most important things managers need to consider when costing web accessibility?

I have found Dries’ State of The Drupal keynotes to be great both times I’ve seen them.  It is fantastic that these presentations, along with all the sessions from DrupalCon are available on Archive.Org.  If you want to skip the intro material, Dries starts his talk at

Below are some notes I made summarizing Dries’ keynote address.

Drupal 7 Highlights

• Drupal is 10 years old
• 1 million+ sites use Drupal
  • Governments, Fortune 500, Universities and Non-Profits
  • 1.7% of all sites on the web
• D7 took 3 years from Feb 08 – Jan 11
• Lead – Dries, Co-Maintainer – Webchick
• Major Initiatives: Fields, Overlay, DB, Registry
• 1000 contributors – 30% more than D6
• Contributions match a long tail curve
• 30 Contributors responsible for 50% of D7 core patches
• 7925 modules, 947 themes, 4322 developers
• Drupal.org relaunch
• In Feb 2011: 5 million visits, 25 million page views, 130k unique visitors/day
• Migrated to Git
• 1 million+ sites use Drupal, Governments, Fortune 500, Universities and Non-Profits
• 1.7% of all sites on the web
• Community of 551 392 people in 228 countries using 186 languages
• 3000 delegates at DrupalCon 2011

•

D7 Successes

• Test Driven Development
• Updated Development Documentation
• Usability Team
• Development Snapshots – Including during Code Freeze
• Accessibility Team

•

D7 Problems

• Empowerment
• Release Cycle Predictability
• High Bandwidth Communication
• Better Priorites
• Too Many Critical Bugs
• Performance First

•

Drupal 8 Process

• Move from CVS to Git
  • incremental work in Git sandboxes
  • Bigger changes moved into core
• 5 Gates to pass to move into core
  • Performance
  • Accessibility
  • Usability
  • Documentation
  • Testing
  • No Critical Bugs
• Larger initiatives will be phased to break into chunks
  • Each chunk must pass the gates
• No more than 15 Critical Bugs in Core
• Move from Co-Maintainer to Initiative Owner
  • May still appoint a Co-Maintainer
  • Initiative Owner is like a Mini Co-Maintainer
  • Dries will work with IO and others – not just IO
  • Designed to provide regular High-Bandwidth meetings with IOs
  • First IOs will be appointed in a few months

Drupal 8 Initiatives

• What is the world Drupal 8 will need to live in?  ”The Future is being anywhere at any time, reaching any information or people needed on any device”
• Clear shift from fixed devices to mobile devices
• “If we were to start Drupal scratch, we would design for mobile first and desktop second”
• Drupal 8 need to output content to a wide range of devices
  • Desktop – HTML
  • Laptop – XML driven Flash
  • TV – XML
  • Tablet – HTML5 & CSS 3
  • Phones – Native App
• 5 Strategic Initiatives for Drupal 8
  1. Multi-Device Publishing will be key – Markup Free Core
  2. Interoperability - Mail, ID, Commerce, Docs, CRM
  3. Drupal needs to deliver a Delightful Experience – Simplicity and Power are Increasing
  4. Configuration Management – Exportables, UUID
  5. Content Staging

• Ecosystem
  • Be careful – The future is not just about features
    • “The battle devices has now become a war of ecosystems.  Our competitors aren’t taking our market share with devices; they are taking our market with an entire ecosystem”  - Stephen Elop, CEO Nokia
  • Between equal platforms, the one with the better ecosystem will win
  • We need to continue to invest in the ecosystem around Drupal
  • Ecosystem is what will matter the most

It’s always great to decide to fix some code and things pretty much work out the way you want.  Tonight I wanted to add a listing of the Tags for each post to Single Post view to the theme I’m using for this site.  Cellar Heat is a great theme and working with it was awesome.  Its a great theme with great code build on the pure awesome of WordPress.

Pretty much the only thing I wanted in the theme that wasn’t already there was the listing of tags for each post.  I don’t mind tags not being included on the post excerpts on the front page and side bar.  I did think that tags should be included with the full post view…so I added them.

First I found the WordPress documentation on the calling the Template Tag “the tags” (a bit of unfortunately confusion naming by WP there…).  Easy and straight forward, I dropped in some code to get the tags in the full post view.

Keeping in mind I’m using the 1.0 version of Cellar Light, I added this div just before the second”<br clear=”all” />”

<div id="tags">
 <?php the_tags('Tags: ',' • '); ?>
</div>

I then added a bit of styling.  I wanted the tags to be visible but not a visual focus.  To accomplish this, I dropped the font size down to 10px, moved it to a right alignment and used the opacity style to soften it’s look.  I started off with just using italics, but it still looked too heavy.  I was delighted that I just assumed there was an opacity feature in CSS, having never used it before, and then found exactly how to do use it on Quirksmode.org.  The article includes important tips on IE compatibility for the opacity effect.  I’ve tested with IE 8 and I’m happy with that.  Here’s the CSS code I added to the stylesheet:

#tags {
      font-size:10px;
      text-align:right;
      opacity: .35;
      -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50)"; // IE(8) opacity magic
      filter: alpha(opacity=50);                    // more IE(7) opacity magic
}

And that’s it!  Good times.  Good Hockey.  And even caught some of The Rockey Horror Picture Show.  All in all, a lovely evening.  I think I might move the dark version of the Cellar Heat…the rounded corners and the look of the footer is tipping the balance.  I expect this code to just work with the dark version, if I do end up making the switch.

You can see the result of the changes I made at the bottom of this post…or any post.  If you like this work, you’re welcome to it – although I would appreciate a comment or email telling me that you found this helpful.

This seemed sub-optimal so I asked Google and a few colleagues and I got the answer, more than once, that you can’t change the ownership of a symlink.  I accepted this and so I deleted the symlink and then I su’ed to the account I wanted to give ownership to and recreated the symlink as that acccount.  Not a Bad Thing, but not a Good Thing either.

A few minutes later I couldn’t stop thinking about how little sense this made.  So I went back to Google and sweet talked her into giving over the goods.  It turns out that what happened the first time I tried to chown the symlink is that chown respected the symlink and I changed the ownership of the referent directory, not the link to it.  That was a Bad Thing.  Especially since I didn’t see that it happened.

Luckily, there is a Good Thing as well, and it’s chown.  Chown has an option (-h) to reference a symlink itself and not its referenced file:

chown --no-dereference user:group symlink

From the Good Thing comes a Happy Ending: I have restored the ownership of the referent directory and successfully changed the ownership of the symlink.  Not to mentioned learned a cool bit of linux trivia.  This would be a terribe(ly awesome) interview questions >:).

Many thanks to the Edmonds Commerce Blog, a Freelance PHP Ecommerce and SEO Developer in the UK for their post explaining this.  Although, if I had just man’ed chown, I would have been able to figure this out on my own <grin>.

update: The man page for chown has a comment that makes it sound like some OS really can’t change the ownership of a symlink.

“-h, –no-dereference
affect  each symbolic link instead of any referenced file (useful only on systems that can change the ownership of a symlink)”

Just thought I’d mention that as well.