Lately, we have been involved in a project where our clients needed a site capable of serving a large number of anonymous users and a reasonable number of concurrently logged in users. In order to reach these goals, we looked to the cloud. I'll give a quick overview of our configuration using nginx, boost, apc, cacherouter, memcached, and glusterfs. This has allowed us to scale up considerably.
Recently, I've been working on the search interface for McGill University's course catalog. The University wants to allow students to browse courses at friendly URLs like:
Creating a search interface for a website with a lot of content requires providing a variety of filters. Sometimes those filters can take on a life of their own, providing hundreds of options for users to filter by. While building widgets for our Drupal/Solr projects, we looked at a couple non-Drupal examples of search interfaces for content-heavy websites.
Sometimes, we find issues with content that are not anticipated by the planning process since they don't show up by looking at sample content or discussing the major use cases of the site. By looking at real content during the data import phase, these issues can be dealt with at an early stage in the development process.
Building a comprehensive information architecture for a content-heavy website can be a challenge. Luckily, Drupal is great for rapid development and by building content types early on, it's easier to discover issues with either the content, design, or architectural decisions.
Every project we do at Evolving Web has a content import component. Whether the content consists of legacy data sources or a single CSV file with freshly written text, we usually have enough content to consider writing one or several import scripts to import it into Drupal.
