I’m now using Drupalgardens, visit me at http://rossnunamaker.drupalgardens.com/node
We pulled the password and sent an internal employee email and will send out a customer note on Monday along with a press release prior to redirecting. We had great partners in Door 3 and Drupal Connect, for usability and configuration, plus Limelight for CDN and Acquia for 24/7 enterprise support.
Herding cats would be an understatement, multiple departments, four vendors, 42 content owners, and 488 pages.
Custom mobile to launch by 10/1, then time to build out sites for Canada, Mexico, Brazil, and the balance of Latino America.
So proud of the site and all the work put in by so many people!
In 2005, when Pew reported less than 20% of Americans had read a blog, I had the idea to leverage the new social technologies, like blogs, to build a community news and information site.
When Patch rolled out I was pretty confident it would eventually fail. AOL pumped lots of money into it, but as a publicly held company it would have to produce financial results and during the most recent quarterly earnings call and reporting around it, shows the time has come to shutter many of the sites (Patch’s New Math from Paid Content).
I wrote about Patch’s ability to both provide local news and tap local dollars in this post.
When Patch made a call for unpaid contributors, I knew they were in trouble and explained why in this post. Throughout my five year experience placeblogging, I had a total of three people interested in posting content as a contributor, and while some made it more than a year, most did not.
Two years ago I wrote about Patch following the declaration that they were serving over 50% of the population in the communities they were active. I noted my experience with local advertising and the challenges with the Patch approach.
And again, I explained how Patch’s readership numbers didn’t add up.
I made my last post on my community site on New Year’s Eve of 2011. At that time I read a post on our local Patch about its top stories of 2011 and what it told me was that Patch hadn’t found the pulse of the community yet, you can read why here.
In the Paid Content article noted above, the author misses the point, particularly in making a statement like this, “The fate of Patch is an admission that there is no business incentive to provide news to poor or rural communities. ”
The reality is that a national platform to deliver local news by extracting local dollars from small business using a combination of paid and free contributions from local residents won’t work.
The only reason the above statement was made is because in a community with high wealth, high-end global brands will advertise to reach that market.
This statement is equally flawed:
it’s a policy problem tied to the collapse of newspapers and the market for local news. Alas, the solution, despite recent local news initiatives by Google, seems even more remote than it did 10 years ago.
Newspapers may be hurting, but ours are heavily invested and engaged in online featuring a combination of print content online, breaking news, and blogs by staff and community members. One does a very good job of creating “community” sections on the site and linking to active local blogs.
Couple this with local information sharing that takes place on social and people have greater access to news and information by a wide margin than what they had 10 years ago.
The problem, it appears, is that AOL couldn’t monetize this, nor can anyone else.
Several prominent companies and government agencies are now using Drupal, and Forrester named Acquia a leader in its 3rd Quarter 2013 Social Platform leader for Drupal Commons, so I’m guessing that number will grow.
Two weeks ago, I conducted a test of Medical Device manufacturers’ sites and only Ethicon, a Johnson & Johnson company, was using Drupal. In Pharma, I only checked ten big pharma companies, and two were using the platform, Pfizer and J & J. While I would have liked to have been the first to market in Device, I’m okay with rolling out the second site for Olympus’ Medical Systems Group in the US with future rollouts for the Americas.
This also got me thinking about who else is using Drupal and really, what approach are other companies taking to website platforms. I used the Chrome Plug-In Wappalyzer (and while searching the Chrome store for the link found PageXray which I just installed). Both of these plug-ins will identify what technology is used on a site. Word of caution, some sites use a basic html home page and then leverage multiple installations of a CMS if they have many sites (think big media networks with sites for every channel or show within a channel).
So here are a few of the big ones across some different industries:
The White House – probably not a more high-profile site than this one.
The New York Stock Exchange – another very high-profile site. I had the opportunity to speak with some of the NYSE’s Drupal team this week and while I am concerned with content we post due to FDA regulation, they opened my eyes to their dual concern of content coupled with timing of release, due to SEC regulations.
MIT Media Lab – this group knows something about technology and media.
The University of Arizona – my alma mater, had to include them.
The Linux Foundation – another group that knows a little something about technology and software.
Java.net – a community for Java developers.
Amnesty.org – another high-profile site.
The Grammy’s – I’d imagine this site was built with traffic spikes in mind.
The Emmy’s – ditto.
There are many more and you can visit the Drupal Showcase (which I found in the midst of writing this post) to see which companies in your industry are using the platform.
Since 2000 I’ve been engaged in deploying a range of technologies, databases, and websites. Typically, I’ve been very hands on configuring the solution, building the database, and learning as I go.
My recent experience building a new website for Olympus Corporation of the Americas’ Medical Systems Group has been different. The requirements are more complex, because there are many more required resources, and their are roughly 50 content owners for the US site alone.
I’ve written about the challenges and mistakes made in securing content, now I’d like to speak to three of the configuration aspects I would have done differently.
First, I should have installed Acquia’s Dev Desktop for the purpose of seeing out of the box Drupal vs. our custom configuration. I’ve worked with WordPress, Concrete 5, Zope/Plone, and some non-profit specific solutions including iMIS, but had not worked specifically with Drupal.
Why didn’t I? I had an IT team that was setting up our server, a creative team that was handling design, programmers who did theming, and we had hired an implementation vendor to deliver what we required.
I regularly reviewed functionality, but wasn’t focused on how the functionality was achieved. Later I had to try to figure it out and didn’t have the knowledge to know or experience to do a good job of reverse engineering.
Second, I would have gotten involved in the Drupal community in general and Drupal Association, specifically, much earlier. The NYC Camp by the Drupal Association, I took after I’d been on the project for close to 18 months. I should have attended more events and gotten as hands on as possible.
Third, I addressed this with content, but it goes for all aspects of the site, we should have more closely followed the workflow and processes throughout configuration. By this I mean, we have an approach and process to code control and the development, staging, production file push that is platform agnostic. Had we have been using this throughout, we would have caught some of the nuances that exist within Drupal, earlier.
Why didn’t we follow these? Speed. We worked in production because the site wasn’t live, we were the only ones using it, and it was much faster to work in production rather than be pushing files from one level to the next.
All-in-all, the site build went well and we were fortunate to have some very good partners, but if you are looking at moving to Drupal I’d definitely recommend getting hands on, getting engaged, and utilizing the workflows you build in.
For the past 18 months I’ve been working on rebuilding the website for Olympus of the America’s Medical System Group.
We did a reasonably good job in discovery and define (four months) and configuring our Drupal based site (four months), but we haven’t yet launched.
This week I had official Regulatory approval (it had been previously reviewed, but not submitted through our compliance process).
With the ability to go live I had people say, wait, I never approved this content.
This one threw me for a loop. It also upset me, alot.
Without question the biggest challenge on this project was people and more specifically, people recognizing that this was an important project that needed their time and attention. I think we were good on the first half, but not so much on the second.
We tried requesting information. When that failed we tried populating information for them (taking from any sources we had available including from our European counterparts). When they saw that we had grabbed content from elsewhere some were not happy, because the markets and regulations are very different between here and there.
Finally we sat down and edited pages in real-time. Over two eight hour days we met with four business groups in four hour blocks. Three of us sat down with product teams in each group and edited pages on our laptop, while showing the refreshed updates on another. Once the team told us the page was good, we would move on to the next one.
We did the same with three more teams in another location.
Since we didn’t complete all the pages during the sessions, I held ten follow-up meetings either in person or via WebEx to finish the review of the pages.
This work concluded at the end of April at which time Regulatory reviewed every page on the site.
I was then told that we had to conduct usability testing, which had originally been taken off the table at the beginning of the project due to costs. This delayed the launch by another month.
Then we had the official submission to our Regulatory review process and this also took an additional month.
When we were ready to launch, two months after the last person reviewed content and now nearly five months after some finalized their review. I had people saying they never approved content.
I don’t understand how someone can say they never approved content when they had reviewed a page, said it was good and moved on to the next one.
I was asked for documentation showing that each content owner had signed off on each page. I didn’t have it. I had meeting dates and invites, but no sign-off per URL.
I was not happy.
Yesterday, a Friday, we had summer hours. I left at 3 and despite the high heat and humidity in the northeast, I went out to my garage and began painting the wood for the Adirondack chairs I was making.
As I painted and the sweat poured off of me, my mind was free to drift. It was during this time that I realized my biggest mistake on this project was failing to utilize the built in content workflow of the web CMS during the site build.
We built the site to have different content states and different user types with access to different states depending upon their role. During the build we by-passed this process to get work done quicker.
We were able to get things done quicker, but we had no record of why we made which change and who initiated it. Had we have used the built-in workflow, we would have had it.
Now I have to go back to the beginning and assign each page to an owner, have that owner go into the system, review content, approve and or edit said content and submit to a publisher if there are no changes and re-submit to regulatory if there are.
I’m hoping this doesn’t take too much time, but I’m afraid I’m probably looking at another 6 to 8 weeks.
So if you are engaging a website project with many content owners (I have about 50) be sure to utilize your workflow in order to hold individuals accountable and document the hard work you are doing.