The gist of the talk was that Drupal's flexibility for theming and interacting with other software (through its API and Services like JSON) in combination with its modular scalability really empower software designers to test hypothesis' through rapid prototyping using Drupal. Additionally, now that cloud hosting solutions like Pantheon exist, which is tailored for Drupal specifically, you don't have to worry too much about implications of growing userbases - prototypes can become actual customer-facing offerings from day 1.
As an example of how we've used Drupal at Design Guru to power SaaS offerings, I talked briefly about the architecture powering a project called GetFilmi (subscription video on demand service for South Asian cinema) which uses Drupal to act as a central content publishing hub which displays video assets from Kaltura and then pushes content to native mobile and tablet apps using Services. From the lessons learnt in developing GetFilmi's architecture we've created a white label SVOD service and I spoke to our vision for the future which would be a truly turn-key offering (taking some queues from another Drupal powered SaaS service called introduction.io we run for creatives around the world to host portfolios.)
Considering the best hosting environment for Drupal projects has always involved the following questions:
What is your budget for hosting?
Who will be responsible for maintaining the hosting environment and what is their technical familiarity with LAMP (Linux Apache MySQL and PHP)?
How much physical space does the site actually need?
What is your expected site traffic and how can you expect that to grow over time?
Of course, there are many more things to weigh in when a project entails higher-than-average server loads due to multimedia encoding and streaming, complex database calls for large dynamic lists, custom data visualizations etc... But these typically frame the task of choosing the best hosting vendor and then package for the project, based ultimately on cost, server space and bandwidth.
In the past few years Cloud hosting infrastructure has emerged to make answering these a little easier - storage space and traffic have become scalable costs that grow with the needs of the project and there is a great range of hosting packages which cater to almost any type of customer; cloud hosting can be used by people who want to hand-off the role of server manager to the vendor or hard-core tweakers who want to manage their own custom environment.
Currently, it seems to us that there are three main vendors for scalable cloud based hosting solutions which best suit Drupal.
Acquia Cloud makes site versioning quite easy; whereby development, staging and production enviromnents can be individually and files or databases can be moved between by dragging and dropping in their web based admin panel. Their site backup tool is very usefull for rolling back a Drupal site to an earlier captured version - something otherwise needs to be configured per project on other hosting environments using tools like the Backup & Migrate module. The site versioning functionality is available through a web based GUI tool, drush command line and an API - the last two making it an excellent choice for Drupal based app projects which require frequent versioning to facilitate large functional development and testing.
Pantheon is a cloud hosting infrastructure which has been developed specifically for both Drupal and Wordpress sites. Its very interesting for focusing on scalability and automation - their platform allows automated updates for Drupal modules and more in attempts to let its customers focus less on managing their hosting environment and more on content etc... Their versioning system seems to be comparable in flexibility to Acquia's but load content a little faster thanks to their load balancing and caching systems which are specific to their platform. Of course, the entire platform is running on Rackspace's Cloud (Pantheon is supposedly one of their largest customers); so reliability is fantastic as well. On the whole it looks like Pantheon is a great solution for teams who want to spin up versions of their pre-existing Drupal projects to create as independant sites which all share the same hosting setup. Particularily useful for Agencies who bear the responsibility of hosting client projects or even single projects entailing site versioning for sign-off from multiple stakeholders, Pantheon seems to fit into Acquia Cloud's pricerange but offer a more feature-rich user experience for non-techies and great service (especially if you want them to help make your sites faster and scale better.)
Rackspace Cloud is the only solution in this comparison which takes a cloud approach to conventional hosting, whilst being somewhat platform and CMS agnostic. Their offering takes conventional hosting setups into the cloud with scalable resources and pricing and they offer managed hosting, which gives you amazing support resources which ultimately saves developer time through doing server optimization and software installations for you. Rackspace's servers will cost about 1/4 of Patheon and Acquia Cloud if you don't want managed hosting, and about 1/2 of them if you want it and this makes for a great option if your developer is able to setup your hosting scenario for you, and then is on retainer to manage software upgrades to Drupal post launch. Using Rackspace means that you can customize your server and allocate larger storage and RAM allotments per dollar spent on hosting; though it also means that there is a more technical know-how required in setting up dev/staging/production environments and a backup scheduling system - once all of that is setup though (assuming you need it) we've found uptime amazing and their service available by phone or email 24hrs a day.
In summary, Rackspace is the best solution to save money on hosting whilst making sure you have the best support in the business - which is important when figuring out how to scale with increased traffic over time etc... However, if your budget is a little larger, both Acquia and Pantheon offer flexible infrastructures that remove the need to ancticipate scaling, and can give you the peace of mind of not needing to worry about hosting infrastructure - that is of course, until you run out of the allotted system resources - at which point for any of these solutions it seems you'll need to purchase an upgraded hosting package.
Our WhyDrupal? RSS feed just got published to the main Planet Drupal feed aggregator and it made me answer a question I've had for years - "How can I easily override the relative links in wysiwyg editor textareas and replace them automagically with absolute links?"
For the most part I usually try and use Drupal's Media module to embed images in posts but thats not always the easiest workflow for quickly throwing images into copy areas.... and its not a sustainable solution to use absolute links within nodes (say you have to move URLs one-day when you forget to renew your domain, or are moving from a development server to the live client-URL?)
Well, it appears that there's a super easy solution - just install the "Relative Path to Absolute URLs" module and then add the filter (shown below) to the specific input filter you're using (d7 = "Text Format") et voila, the problem is taken care of on the public/display side whilst not over-writing your relative urls within the site database ;)
As Drupal software is increasingly used by more people around the world to power a varied array of projects - from simple online publishing tools to complex web applications, defining the sense of community drupal.org facilitates becomes more relevant.
At base, the term ‘community’ can be applied to the meta group of people and organizations using Drupal around the world purely by the fact that they share this use in common. Taking the definition a step further, a more ideal ‘community’ would also imply a sense of fellowship between members which could result in common goals.
As the Drupal community grows, a greater importance must be placed on encouraging a strong sense of community whereby drupal.org can serve as a platform for achieving common goals of all members. This brief post attempts to highlight some key areas of opportunity for encouraging such engagement.
Better leveraging the power of our network
Problem - Almost all professional firms and contractors using Drupal software are registered members of drupal.org yet the ‘Marketplace’ listing at https://drupal.org/drupal-services is limited and biased.
To better represent the wealth of professional service vendors working with Drupal, Marketplace listings need to become better integrated with member profiles; when registering at drupal.org and/or filling in a profile, members should be prompted to fill out a professional services description, which auto-lists in the Marketplace and collapses the anemic member directory at https://drupal.org/profile into a better functioning Marketplace/community listing (perhaps making commercial vendors a filter of the larger community list.)
There should be no distinction between ‘Featured’ and non-featured providers in the Marketplace; this confuses anyone coming to drupal.org looking to procure a vendor - instead, to establish vendor credibility we can offer tools such as ratings, testimonials/endorsements (as used on linkedin, for example) by previous customers to leave feedback on each vendor, and represent that information on their Marketplace listing.
Given that we work in a global context, and most Drupal professionals take on international client work, it seems redundant to only offer ‘Browse by country’ as a filter in the current Marketplace. Instead, filters would be more relevant if they related to skill-sets/services each vendor offer.
Problem - Lost opportunities for collaborative work.
Based on how members tag their profile/marketplace-listing (listed services etc...), drupal.org should recommend other members to them; complimentary skill-sets need to be made obvious to members to encourage collaborative approaches to commercially working with Drupal.
Drupal vendors working together should be able to express their relationship publicly. Like the ‘Connections’ functionality on linkedin, vendors could ask each other to approve a simple flag (ideally with an annotation to explain how they work together) to display on each of their profiles.
Problem - Job Listings are too static.
Though the main drupal.org job post/listing interface (https://groups.drupal.org/jobs) is hosted on drupal.org it is not integrated with marketplace functionality - so posters aren’t automatically recommended vendors (through their service offering etc...) and vendors are not notified about the availability of postings unless they have been targeted to groups a member may belong to.
Tightening up the recommendation and notification cycle around procurement would encourage communication between posters and vendors and better humanize the procurement process.
As well, the current interface uses reverse-chronological listing; which buries older posts, even though they may not be filled. Instead, it would be worth considering alternate types of sorts which visually group listings by relevance to the person looking at them. Additional information at-a-glance should be offered through hover-tips to relate a summary of the position to the vendor looking through listings (often job descriptions are almost synonymous; who is looking for what is more important than the title they want to call the position which is available.)
Problem - Difficult to price procurement of Drupal vendors.
Without standards for pricing varying tasks and quality of work, it will always take longer for procurement to sort through job listing responses etc... Vendors should easily be able to post case-studies formatted within set guidelines (to maintain congruency) with optional pricing; the case-studies should be available when viewing a vendor profile (individually and possibly through a simplified interface when looking at the marketplace.)
To allow customers of vendors to offer insightful feedback on the value of the service they experienced, a rating criteria should be offered to them so that the accuracy of pricing is maintained. For example, if vendor X posts case study Y with a guideline pricing/budget of $100 and their client, Mister Z, rates the value of X’s service as 80%, it is obvious to the case study reader that the project may have been better priced at $80. As a large data set is auto-generated through submitted case studies and customer feedback, pricing recommendations can be automated as messages sent by drupal.org to vendors to suggest augmenting their price to better service customers (we could possibly have standards emerge as the aggregate pricing based on service per case study across the whole community.)
A simple pricing guideline can also help procurement; explaining how the community chooses to charge for their services. This could be tied to a set of standard methods which each vendor flags as their preferred pricing format. For example, ‘Hourly rate’ vs ‘Monthly retainer’ vs. ‘All-inclusive per-project’ etc...
Problem - Issue queues are support silos and IRC is abstract.
Currently live communication online between members of the Drupal community happens on Internet Relay Chat - in a myriad of channels (listed at https://drupal.org/irc) per specific topic of interest (e.g. accessibility vs commerce etc...) IRC is a great way for people to chat with each other but requires a separate client application; which non-technical community members may not want to install; further, newer Internet users may not be familiar with command prompt conventions of IRC and thus feel inhibited from communicating with the rest of the community using IRC. Asides from the learning curve of using IRC, it is further restrictive in not being contextual - because it requires a separate-from-browser application, communicating about information on drupal.org may feel discordant.
An integrated web-based chat facility on drupal.org (e.g. https://drupal.org/project/drupalchat) which displays to logged-in members of the community and features chat rooms per topic would be a huge improvement. If possible, this could just be a web client to an IRC server so that the existing conversations are not buried but instead brought right onto the drupal.org website. As members browse drupal.org and have immediate questions which may not warrant posting an issue queue, they should be able to simply type a chat message and be able to reference whatever they are looking at on their screen. A web-based chat system would also serve to better introduce members of the community to one-another as their on-site profiles would be linked to their chat IDs/handles (as opposed to the general anonymity of IRC handles.)
Problem - There is no direct way for members to sponsor development of modules which do not exist.
There needs to be a marketplace by the community for the community - where module development can be proposed and answered by parties interested in working on specific modules. This would rely on better member profiling and need some automated notification whereby members can type in a time (or other resource) commitment of availability to work (for the community) and the type of work they can offer.
Ideally drupal.org would notify members with related availability when a project has been proposed, and then voted for with a certain minimum weight by the community. In addition to being able to create a floated list of top-priority module development projects, an integrated crowd-funding system would ensure that adequate resources could be allocated to developing whatever modules the community needs. So, based on availability and remuneration needs, community members could actively work on module development and be paid for their time and effort.
Problem - When module development stalls, vendor credibility suffers.
Many Drupal modules have been created to integrate Drupal software/websites with 3rd party services (such as Mailchimp for email newsletters or Kaltura for video.) Some of these are actually sponsored or even published by the 3rd party service but the majority are created out of needs specific client projects present to developers. A common phenomena seems to occur on drupal.org where a lot of work is put into creating an integration module and then its developer will not have adequate time or will to support its development; leaving modules out-dated as their integrated service adds features etc in time.
Often in these cases the 3rd party service vendor isn’t aware that the lack of support for their Drupal integration is causing drop-off to their service use within the Drupal community, or unsure as to what extent that drop-off or dissatisfaction has reached. Ultimately drupal.org relies on issue queues per module to provide forum for discussing Problems of all kind with modules. As issue queues grow and developers become weary of supporting modules they’ve created out of lack of time/money to do so, it would be helpful if they can flag a module for additional support; this could be facilitated as a formal request to the integrated service (sent on behalf of drupal.org - lending brand equity and stature) and/or a request for support to the community.
Again, integrating a crowd-funding mechanism with drupal.org could allow not only new modules to be sponsored by the community but existing modules - so when a developer can’t afford to work on their module, the community can help buy the time required for them to fulfill issue queue requests/feature-advancement etc...
(Written by Qasim - Principal/Founder @ Design Guru)
Here is the deck I presented at DrupalCamp Toronto 2013 this past weekend; a video of the presentation should be made available soon.
The overview of the talk:
Whether Drupal is used to create simple online publishing solutions or more robust web applications, developers often focus on implementing whatever a 3rd party designer has specified for the' front end' user interface and ignore the need for well designed interfaces to administer sites.
This session will take a macro perspective look at how Drupal out-of-the-box comes with general work-flow problems by relying on implementers to develop custom user experiences, and then jump into simple ways these can be facilitated through modules available from drupal.org