Square Grid responds for Drupal 7

Laura Scott — Tue, 13 Sep 2011 13:27:53 +0000

From the get-go, Square Grid has been intended to offer less. Sometimes less is more, especially so when it comes to front-end web development.

Square Grid is a Drupal 7 base theme* leveraging the design and implementation power of Square Grid, combined with principles of responsive design. It's been in active development, with new features and the odd bug fix pushed live periodically over the past several months. Here's where the theme stands now.

More options, still lightweight

Since its first incarnation, Square Grid has grown a bit – not so much in code but rather in flexibility. It's still pretty lightweight.

Configurable tools

Square Grid configuration options are inherited and available to your child theme's settings page. These include:

Configurable responsiveness options

Responsive support has been part of the theme since April. Now you can configure whether you want it, and if so how much.

You can turn the responsive support on and off.

However, it's not just a matter of turning responsive support on or off: You have various options.

If responsive support is enabled, you can choose what grid sizes to utilize in the theme.

If you do not want responsive support, you can choose a universal grid size for all screens.

The theme does only what you've planned for.

Internet Explorer options

You can decide how to handle Internet Explorer up through version 8, which does not recognize media queries.

IE support options can be configured as well.

Options include one static grid size, or no special handling (in case you want to use a JavaScript-based solution such as Respond.js).

Simple built-in development aids

Grid-based theme development sometimes can get quite involved when working on an actual Drupal codebase, not just mockups or prototypes.

From Square Grid-enabled theme configurations.

With these seettings, you can toggle on/off display of the actual grid and rebuilding the theme registry on every pageload.

Behind the scenes, what you get are:

A grid for most occasions

As illustrated here, Square Grid framework facilitates a wide variety of design grids, from 4-column to 12-column to Golden Ratio, all from one grid schema.

The lightweight Square Grid Theme builds off of the powerful flexibility of Square Grid framework by Avraham Cornfeld. See http://thesquaregrid.com for more on Square Grid concepts, templates and more.

Lightweight CSS

The styles predefined in the theme are as minimal as possible, focusing only on page layout. The idea is that you, the themer or front-end developer, will want to control the rest.

Mobile first architecture

The theme styles for single-column, optimized-for-smaller-screens layout first, and adds multi-column grid-based layouts in addition for screens 770px and larger.

Content-first page loading

Nothing irks more than loading secondary content before the main content. It makes people wait longer to see what they clicked to see, raising click-aways. This theme loads your main content first, then the secondary content.

Straightforward grid column settings

These can be overridden in your child theme's template.php. No heavy PHP knowledge is required, and all necessary code is provided.

No extra extras

It's tempting to add more bells and whistles, but the goal is not to add complexity or steepen your learning curve with bespoke variables or code concepts.

There's more on these features and characteristics in the official documentation.

Not a fluid grid

Square Grid is not a fluid grid. Why? Because even today browsers do not agree how to render out elements defined with floating decimals. A fluid 35-grid layout would require a grid of %2.857... per grid square, which means that a fluid layout defined by percentages would entail added complexity and possibly some browser hacks, especially when you multiply browser-imposed roundings and truncations by 35.

Some people still prefer 100% fluid layouts, and that can make sense, especially in some use cases, such as an expert-interface dashboard requiring as much screen-estate as possible. However, if the static grid widths adapt to the screen sizes, the marginal benefits of going 100% fluid are somewhat minimized. Therefore, given the floating point issues noted above, Square Grid, as a base theme, supports multiple fixed-grid widths that offer healthy screen-estate usage for the most-commonly used screen sizes. (Count me in the school of thought that it's all responsive.) An added benefit is that, by defining these break points, the theme renders with more predictability for design purposes. The current 770px-, 980px- and 1190px-width break points in Square Grid Theme cover most larger displays, while still providing comfortable, readable layouts. As screens get larger, we can build upon this paradigm. And we're not ruling out fluid grid definitions altogether. (See below.)

Road map items

Here are some things in the works (in no particular order):

An HTML5 version

This is already in the works. [Meta issue]

"Nav last" page structure

Currently, Square Grid loads the main menu before the content — something I always immediately remake in any child theme. While there are still some naysayers, most agree that loading nav last is best practice for mobile display. This means that Square Grid should load the nav last, just before the footer. How this gets styled for proper placement, though, depends very much on the specifics of the design. That's why I have not done this yet, but I may add 3-4 lines of CSS to handle this. [Issue]

Configuable column widths

These would be configurable "sidebar" widths settings, to make it easier for you to just get on with implementing your design. (Column widths are fully workable in the theme currently, but customizing them does involve some code editing to change integer values in the child theme's template.php file.) [Issue]

1400px-wide layout

This has been partially implemented (and disabled in code pending completion) and likely will be in one of the next releases. [Issue]

Fluid layout

Comments above notwithstanding, this could be an option with potential appeal to some themers. Caveats about variable browser support would apply, of course. [Issue]

We hope Drupal users working to implement custom designs on their own sites find the Square Grid Theme useful.

* For most themers and front-end developers, one of the fastest paths to implementing a completely custom design for Drupal is via a base theme. For more about this approach, see the Drupal.org documentation on this architecture.

Upgraded to Drupal 7: Salesforce, Homebox, Stock API, Hierarchical Select

Laura Scott — Wed, 17 Aug 2011 00:17:41 +0000

For us, every project starts with goals. From goals comes strategy, from strategy comes planning (information architecture, interaction design, technical architecture) and from planning comes (a rather agile) implementation.

And for implementation, 2011 so far is the year of Drupal 7 — at least it has been for us, because all of the projects we've started this year have implementation powered by Drupal 7 at the core. In some ways, we love Drupal 7 so much more than Drupal 6, we don't like to look back. It's almost painful to have to deal with Drupal 6 anymore … especially when it comes to theming.

Of course, this means we've had to do quite a bit of wrangling with module bugs, helping with upgrade-related issues, and contributing our own upgrades. Despite the success of the #D7CX initiative, the first several months of Drupal 7 contrib felt like life on the bleeding edge. That's only natural for such a large and robust system as Drupal has become.

Some of the modules we upgraded to Drupal 7 include:

Our view is that the best way to upgrade existing Drupal modules is to contribute the work back to their respective Drupal.org projects. This way the client benefits from having more code supported by the Drupal community. We benefit by having extra eyeballs and keyboards working the challenges, as well as ensuring that the client's project remains on the open source path.

Salesforce

[Ported to Drupal 7, still in active development.]

With a project making very heavy use of quite deep Salesforce integration with Drupal, we had to get the Salesforce Suite into Drupal 7 shape. We've made quite a lot of progress. Yet this is a huge undertaking, and much is yet to be done. Check out the issue queue. For a sense of what's next and priorities, see the Salesforce Suite for Drupal 7 roadmap. (We'll have more on Salesforce integration with Drupal 7 in another post.)

Homebox

[Available now for Drupal 7. Seeking (co-)maintainer(s).]

You may know it as "Your Dashboard" on Drupal.org. It was available in Drupal 6, but we needed it for Drupal 7, so we did the upgrade to a minimum viable product release. Homebox is available for your Drupal 7 project!

We don't have an internal need to push it further, but Homebox has tons of potential, especially for site managers and administrators. If you're interested in extending and improving Homebox, please share your patches, or even help review patches already submitted. Maybe you'd even like to be co-maintainer?

Stock API

[Available now for Drupal 7. Seeking (co-)maintainer(s).]

Need a block to display stock prices? We ported the module from Drupal 6 to 7. It's still a -dev release, but fairly stable at the moment. At this point, we don't need to take it further. Future maintainer(s) interested in building out a cool set of stock-market-monitoring features are welcome to take up the baton from here.

Hierarchical Select

[Available now for Drupal 7.]

Goodness knows this module faces a huge rearchitecting for Drupal 7, but we needed something working right away, so we've been working with maintainer Wim Leers to get a minimum viable product released. There's a lot more that could be done for HS, but at least it's available for Drupal 7 now, and I'm sure Wim would appreciate more loving community attention on this incredibly useful usability enhancer.

Oops, that's a cul-de-sac

One project we did that is now pretty much EOL is Apache Solr Pages. We needed the functionality for a project at the time, and Solr did not have it and there was no clear roadmap as to when or even whether it would have it, so we contributed this simple project. Now Solr itself provides that functionality, so this project turned out to be not needed.

The commons

In fighting the bleeding edge, we discovered a bug in, and rolled a patch to fix, the Aggregator module in Drupal core. (The patch was then adapted/modified by other community contributors to work on Drupal 8 first, for subsequent backporting. As I write this, it's ready to be committed, so it will hopefully be in a Drupal 7 point release very soon. Isn't open source great?) We also offered some small help in the issue queues on a number of contrib projects. It took a lot of work from this great community to bring Drupal to where it is now. We're glad to do our own small part.

That's the way of the commons. We consider it our responsibility to our clients to fix and update modules this way. The whole idea of using open source is that you adopt code that is shared by the worldwide community. If you don't share the fixes, not only is the community diminished as a result, you've also created your own fork that you, or your client, will be stuck maintaining alone. That's what we would call a bad strategy. Share in the commons and everyone benefits — the community, your client, you.

D7 to get you through these dog days

Every time a new major Drupal release hits the interwebs, there's a bit of debate over when that new release is ready for production use by site builders and owners, and it almost always comes down to the state of contrib. This summer, Drupal 7 contrib has really started to stabilize, with solid releases to many of the popular and useful modules out there. From our perspective, it would take some huge convincing to get us to consider Drupal 6 now for any new project, because Drupal 7 is coming of age and ready for its day in the sun. Not only that, compared with Drupal 6, Drupal 7 will have 1-3 years' more community support (barring an unexpectedly short Drupal 9 release cycle).

With such a large Drupal community, and the amazing proliferation of new module and theme projects, thanks to Drupal.org's new Git footing and the easy ability to create project sandboxes, it can be challenging to keep up with what's happening, or to even be aware of things that may be an awesome fit for your needs. There's simply too much Drupal community development activity to keep track of these days. This post is a little highlight of things we've been working on that you may find interesting, useful or even worthy of your support. I hope other shops, freelancers and hobbyists post about their work as well. It's a busy Drupal world. Shine some light on what you're doing!

When will Drupal 8 be released?

Katherine Lawrence — Thu, 21 Jul 2011 17:25:57 +0000

When will Drupal 8 be released?

When will Drupal 8 be out? It's a question that's asked in many forms.

Sometimes it's phrased as: when will I have to upgrade from Drupal 6? Or, how long will Drupal 7 be supported?

Laura Scott and I were reviewing Dries Buytaert's 2010 State of Drupal and the estimates on when the new Drupal release candidate would be virtually frozen. The graph below is his summary graph of the trends in April 2010.

Fig 1 — Dries Buytaert's April 2010 Prediction of Drupal Release.

It turned out that the trends were not linear, and it was Laura who suggested that bug fixes aren't linear: they tend to be hyperbolic or (for fellow math majors) follow "power functions" that have a logarithmic aspect to them.

This got us thinking. What is the history of time between Drupal releases (TBDR)? In the slide below, Dries provided some this data in his slide from the State of Drupal at the March 2011 Drupalcon Chicago.

Fig 2 — Dries' March 2011 graphic showing Drupal's code size historically.

All that was missing were the dates, which Laura looked up from the Changelogs of each Drupal n.0 release, and from this I created the graph below, which is consistent with a power function. That is, geometric!

Fig 3 — TBDR of core size versus release dates. Graph by Kate Lawrence.

What this means is that the more the code, the longer it takes, and in this case (at least thus far) it is obeying a consistent pattern. Interestingly, in the period from of Drupal 4.0.0 to Drupal 4.6.0, the size of Drupal was pretty constant, especially as compared to the recent growth of Drupal core ... and the TBDR was about 6 months! What do today's longer release cycles mean for Drupal? I say this only because we are hearing that Joomla has a 6 month time horizon between releases.

If Developers were Horses...

What would it look like to have 90 developers contributing, only contributing really, really fast? Is there a marginal utility curve, like we learned in Econ 200, in there someplace? That is, at what point do you have so many people involved, that they are tripping over one another? Throwing more people at the problem does not get quicker results, and may in fact, slow things down. cf. The Mythical Man Month.

The Mythical Man Month premise is: Assigning more programmers to a project running behind schedule will make it even later.

So a question to ponder is to what extent can the growth curve in the above slide be changed?

The final slide from Dries that I think is relevant to this pattern appears below.

Fig 4 — 30 contributors were responsible for 50% of D7 Patches. Graphic by Dries Buytaert.

Most of us have heard of the "80/20 Rule." The rule is attributed to the findings of Italian economist Vilfredo Pareto. Sometimes its the 90/10 Rule or 95/5 Rule, or even 920/30 rule (see Figure 4)!

The challenge may be in making the ski-jump curved line more linear (while pinning the line on the y-axis). The more linear it becomes, the steeper the TBDR curve's slope becomes — meaning that releases can be more rapid.

In short, holding the intersection point on the left axis, as the graph becomes more linear, the faster the TBDR. The challenge we face as individuals within the community is helping in making that happen.

Drupal Front-End Developer (Themer)

PINGV Creative — Thu, 21 Jul 2011 17:00:07 +0000

PINGV Creative is seeking an experienced and adept Drupal front-end developer to join our team. Work with our team on various projects, each presenting new and interesting challenges. We focus on strategy and design, with six years' experience and expertise in Drupal. Development is a follow-through of the plan we create with/for the client.

We are a virtual company.

To Apply:

Submit your resume

Open Atrium and Iterations

Laura Scott — Thu, 30 Jun 2011 17:19:56 +0000

Too busy doing the doing to talk about the doing?

As a strategy and design studio, we're all over communications. It's an uninterrupted conversation with our clients, hashing out ideas, working iterations of goals definition, research, wireframes, designs. But when it comes to development, when we put our heads down and get to work, it's all too easy for us in our focused implementation state to just do it and not communicate enough about what we're doing. Of course, this can be disconcerting to the client who has no idea how things are going. And that's a ripe situation for fear, uncertainty and doubt to creep into the relationship, and suddenly a successful project-in-progress can feel troubled, even if it's not.

The simple solution is to give regular status updates, which is something we've always done. Even just saying, "Things are going well" can help. But on long projects, or even in 3-week iterations, repeating that same message ends up being not that helpful. Better to share what you're thinking with regards to planning and project management, and provide updates on development of the various features/backlog items worked out in the strategy and design phases. This transparency in the project management process is even better when updates are more specific.

We have been using Open Atrium, the powerful intranet CMS built in Drupal, developed initially by our friends at Development Seed, now maintained by Phase2 Technology, for our intranet to handle all client-facing communications, documentation, file sharing and issue tracking. It's been a great tool for this. No missed emails lost in the spam filter. No critical documentation lost on someone's hard drive. No mega-emails containing two dozen specific items. (Well, those still happen on occasion, but we now can push those into the intranet to continue discussion.) We love it.

And now we love it even more.

Rethinking Open Atrium

We had been using almost all of Open Atrium's various features: messages, uploads, case tracker, books for documentation, and of course the groups functionality. Almost all of the features. The part that didn't really fit in with our communications strategy was the OA notion of "Projects". Until now.

You see, in Open Atrium, the basic architecture is thus: You have Clients, which are defined by groups, and you have Projects, which are ways of grouping tickets within the group by project. It can make sense for a large organization using OA for internal communications to manage several projects. But for a professional services firm like a strategy and design company, or a software company, or any other kind of company that defines work by time-boxed iterations or sprints, breaking up stuff by "project" may not be that useful. Projects projects projects blah! At PINGV, we rarely have a series of small projects with a client where it would make sense keeping them all together in one group; we tend to do bigger projects, projects that have phases of strategy, design and planning, and iterations of development. And when we have a new large-ish project with an existing client, we just spin up a new Atrium group. Project was that dunsel feature — the thing that for us had no real use. But—

What if we use "Project" nodes to define phases and iterations?

Wash that nomenclature right out of OA

Ignoring nomenclature, and just looking at what "Project" as a functionality in Open Atrium does for us, it provides a way to group tickets into clumps that you can define by anything. If we define those clumps as iterations, perhaps, or phases, we can organize and parse through backlog items, features, questions and other tickets by iteration, while providing some ready clarity as to how and when these items will be taken on. (NB: It's an approach that works only with Tickets, not other node types, but in our mind that's a minor limitation.)

What's really convenient is that Open Atrium provides via UI the means to rename "Project" to whatever you prefer to call it (e.g., "Iteration"). These string replacements, configured in the group feature settings available to site administrators from within each group's space, work almost everywhere in OA. (The "Add Project" button seems to be unaffected even by string replacements defined in settings.php. Something to investigate later.)

Once we saw this potential for grouping issues into iterations, we ran with it.

Defining iterations in Open Atrium

Using "projects" in Atrium, we can define iterations by close date, and assign tickets to iterations.

As you can see, the Iteration title is compressed down to an abbreviation or acronym in the icon in the tickets display. "Iteration 1" becomes "I1", "General" becomes "GENERA", and so on. After briefly considering using iteration numbers, which we rejected as too arbitrary, we opted to name iterations by the Iteration release date, or end date (e.g., 08/17 or even 11/10/23), which can be abbreviated in a meaningful way in the Tickets views. This gives our clients added insight into our timetable planning at a glance.

Adding a sortable Iteration column to the tickets view involves a simple override to the default ticket View. (If ever we need to revert that Feature during a site update, these changes are easily re-implemented in a few minutes. No actual data is affected.)

You can view all of the iterations planned, and see their descriptions. Each iteration is clickable for detailed viewing.

This approach allows us also to focus just on the tickets that are relevant now, without having to sort through all the other tickets that are further down in the timetable, and without having to mark dozens (hundreds?) of individual tickets as "deferred" and then change those as they come available.

Single iterations of backlog items can be viewed as well, and this is stock functionality for Open Atrium.

The bulk of communications still happens in the individual tickets. Questions, information, updates, concerns, notes can be tied to the ticket itself. New questions and bug reports can also be slotted for attention in a scheduled Iteration. So even though we're grouping our backlog items together, we still avoid the one-ticket-for-8-issues kind of communications that can lead to confusion, frustration and missed messages.

On any comment update, you can change the iteration assignment of a ticket.

All changes are tracked in the comment metadata displayed right there in the thread.

We like this system so far because of this fact that all changes are tracked and visible in each ticket's thread. If we move up a backlog item to a higher priority, we simply do it with a comment and change in iteration designation. This flexibility with traceability provides a nice balance for communicating our planning.

And it's all using stock Open Atrium!

Plan before communicating, and vice versa

I should add that this is not how we do our actual project management. Open Atrium is a great tool for project-related communications. We currently use Brian's recommendation, we tried Liquid Planner (disclosure: affiliate link; go to liquid planner dot com to skip it if you like) for our internal planning. Liquid Planner has an API, and we're considering developing an integration with Open Atrium to allow us to push and pull info between the two. Might be a nice convenience. We do the translation manually now, and while it can take up time on occasion, it also provides an occasion to rethink and re-evaluate, so the manual process does have value.

Feature think, Feature do

Now for the road not taken:

When first considering the challenge of better communicating our iterations plans, I imagined up a very simple Features-based solution using nodes and node reference, which resulted in Open Atrium Iterations. This module works as a drop-in extension to Open Atrium. Not touching any existing Atrium Features, OA Iterations defines a new content type with reference fields to call up tickets (cases), messages (blog posts) and documentation (books) that collectively define and describe an iteration of work. A dedicated view restricts the available referenced nodes to the current group's content.

On Friday afternoon, this seemed like a fine way to communicate our iteration planning. Tickets, as well as blog posts and book nodes, could live on their own, with their own revisions and threads, while the Iteration node would group them into an iteration. Done. Time to relax and prepare for a weekend cleaning the garage.

On Monday morning, however, when I sat down to start defining the iterations for one of our projects, I immediately questioned my own game plan. Open Atrium Iterations was an easy way to define iterations, but making changes would be difficult. What if I wanted to move a ticket from one iteration to another? Yes, this project was never intended for iteration planning, just iteration communication, but even just for communications this approach would mean editing at least two Iteration nodes just to "move" one backlog item. What's more, without implementing Reverse Node Reference and adding that block to one or more Contexts (and thus overriding stock Open Atrium Features), there was no way to look at a backlog item and see what iteration it's slotted for. The simple solution was not turning out to be so simple after all.

And that's when the flicker of the idea described above came to mind. In hindsight, I can smack myself for not thinking of this before. I've been working with Atrium for two years. But I think I got stuck on nomenclature.

Contrib status

Meanwhile, despite our not using it as originally planned, Open Atrium Iterations will remain live on Drupal.org to see if it proves helpful to others. If the Feature can be improved upon to make it more broadly useful to serve more use cases, I look forward to suggestions in the issue queue.

The best user interface is the one you don't notice

Laura Scott — Wed, 29 Jun 2011 16:46:13 +0000

We all want beautiful things. A beautiful graphic user interface is no exception. But how do you define beauty? Pretty colors? Balanced composition? Elegant typography? Appealing trimmings? Grid fidelity?

Without diminishing those things, my feeling is that, when it comes to GUIs, the most beautiful are the ones you don't notice. The beautiful GUI is so useful, so understandable, so usable that you don't even think about the inteface — you're totally absorbed in what you're doing via the interface. This is true for simple devices as well as for complex expert apps where, once you get familiar with the tools, you just use them without thinking.

Expert interfaces are for experts

The thing about expert interfaces is that, while they are complex, they are optimized so that a well-trained user can use them efficiently. For example, non-linear video editing systems like Avid Media Composer are rather complex. They have lots of tools that bring great power to the editor. They also have keyboard shortcuts for nearly every function, and ready buttons for commonly needed items. Once the user is practiced on the system, the expert interface becomes much easier to use than the simple interface. For example, a professional video editor would go nuts trying to work in iMovie — it's just too simple!

And yet for the casual user, iMovie is much more useful, much more usable, much more transparent. In other words, the complexity of the interface depends upon the knowledge, experience and needs of the user.

The expert interface requires many many hours of practice. Do you want your website to be as difficult as playing French horn?

Astronauts train every day so that they focus not on their gear but on what they need to do.

This is perhaps one reason why Apple has gotten so much flack for reinventing the UI, among other things, of FInal Cut Pro. Expert interfaces require hours of training and practice. Apple has ripped many tools out, changed much of the rest, and added yet new things. For the casual video editor, Final Cut Pro X may be like manna from heaven, but for video editing professionals it requires retraining, and the missing features may render such training not worth the investment. Meanwhile, if you have to think about how you're doing instead of what you're doing, you're simply not as productive.

The same would be true for a feature-rich community site. Change how everything works and you'll have a riot from the community members. The features don't belong to the website, they belong to the users. "What happened to my sort button?" Suddenly they have to focus on the interface, not on what they are doing with it.

The unnoticed interface

If you can't get a camera to do what you want, your camera's user interface is getting in the way of what you're doing. If you're focusing on your glasses, not the camera settings and the subject through the camera, your glasses are dirty or they are the wrong prescription.

What is the best user interface? I would argue that one example is a very low-tech object: eyeglasses. They are devices that are a means to an end — seeing. If they are dirty — that is, if you notice them — then they suck. All of us who wear glasses probably share the experience at one time or another of searching for the glasses that we were wearing at the time. (One time recently I was tearing the house apart. My glasses are for nearsightedness mostly; I can't see up close with them on. When I went to the couch to see if they got tucked into the cushions, I took off my glasses to see better— *facepalm*.)

The best design is the one you don't notice, you just use.

Other user interfaces we don't notice: doorknobs, the driving controls on our cars, water faucets, dresser drawers. All of these, except for the automobile controls, are simple, and the automobile controls are dependent upon some standardization and all of us sharing some basic training on their use. If a manufacturer came out with a new car that put steering in the pedals and throttle on a lever, never mind what governments would do, the buyers would stay away — their driving training would be of little use.

On websites, most of which cater by necessity to the casual user — even regular visitors don't want to invest hours of training just to be able to post a comment — we're seeing much standardization in functionality, layout, even icons usage. Is this bad? Is this boring? Is this bad design? Or is it making these sites more usable, more transparent so users can focus on what they're doing, be it reading, posting, linking, uploading, liking, tweeting...? And isn't that what we want? Sites that make it easy for users to do the things they (and we) want them to do?

What is a website but a means to an end? If the user is noticing the website, instead of doing what she needs to do, then it's quite possible that the website is non-optimal. Its UI lens is dirty.

Lucidly Drupal: Setting up Ubuntu 10.4 Lucid LAMP stack for your Drupal site

Laura Scott — Wed, 16 Mar 2011 18:59:51 +0000

We're frequently setting up servers for development, for staging, for production. I've lately preferred the Debian flavor of Linux, but up until now that had been something of a problem because Debian and Ubuntu did not include the higher-quality php5-gd library, which meant that you either had to compile your own PHP, pull from an alternative source host, or cope with substandard image resizing with limited processing features.

But now we have Ubuntu 10.4 LTS "Lucid" and life is good. Lucid comes with PHP 5.3.x and the proper GD2 library! (Cheers. Applause.)

Still, there's a lot of little steps to set up to get your server (or virtual private server) up and running and ready for Drupal. It's not hard, just detail-oriented work you don't want to do when you're bleary-eyed at the end of the day. In my repetitions of doing this over and over, I've collected some notes, and I thought I'd post them here for my own reference, and perhaps your reference as well. My thanks to our own Brian Vuyk for guidance on the APC installation.

[Edit: Brian also pointed me to Taskel as another way to go. I've not tried it that way yet, so this post doggedly sticks to the step-by-step for now.]

Drupal requires some things, and likes some other things a lot. Here's how to configure the latest Ubuntu Linux to make Drupal happy.

Assumptions

You already have Ubuntu 10.4 installed on your server.
You know your server's IP address.
You already have root or sudo access.
You want to set up for Drupal. (Of course, many CMSs and blog platforms will have similar requirements, and this post may have some appeal and relevance to people using those tools. But in this post I'm aiming at the particulars for Drupal.)
You have a computer with shell access to your server, or a properly configured *AMP setup on your computer. (This post does not cover MAMP, WAMP, DAMP or commandline bootcamp.)

Step by Step

Initial Preparation
1. Create a public key.
  
  If you do this, you can connect to your server without having to log in. It's also necessary if you want to deploy from a provisioning system or repository like GitHub.
```
ssh-keygen -t rsa -C "yourname@example.com"
```
  Note: For deployment purposes, you need to generate the key as the user who will be executing the checkouts. For example, if you checkout as root, you will need to be logged in as root when generating the key.
  
  To print out the key (to copy and paste into GitHub, for example):
```
cat ~/.ssh/id_rsa.pub
```
2. Install security updates.
  
  FIrst things first.
```
apt-get update
apt-get upgrade --show-upgraded
```
  Note that if you are using a regular shell user account with sudo, you will want to prepend pretty much all commands in this guide with "sudo". For example: sudo apt-get update would be the first command above.
3. Set your hostname
  
  You should give your machine a name. This is a machine name for your server. It does mean anything about your domain or what URL you want to use for your site. For this example, we'll use the name "athena":
```
echo "athena" > /etc/hostname
hostname -F /etc/hostname
```
  Next, edit the file "/etc/hosts". There are a few options for text editor within Linux. I find nano to be easy to use.
```
nano /etc/hosts
```
  [NB: In these instructions, your server's IP address is represented by "12.34.56.78". Every time you see that sequence in the examples here, you should replace them with your server's IP address. Also replace "athena" everywhere it appears with your server's name, and "example.com" with your actual domain.]
  
  127.0.0.1 localhost.localdomain localhost 12.34.56.78 athena.example.com athena
  
  athena.example.com is your "fully qualified domain name" or FQDN. (You will come across this from time to time.)
4. Set your server's base timezone
  
  This part is easy:
```
dpkg-reconfigure tzdata
```
  You will get pop-up prompts for country, etc. and that's done!
Set up VirtualHost stuff
1. Install Apache
  
  First things first.
```
apt-get install apache2
```
2. Edit /etc/apache2/ports.conf
```
nano /etc/apache2/ports.conf
```
  Replace *:80 with your IP address, so it looks like this:
  
  NameVirtualHost 12.34.56.78:80
3. Edit /etc/apache2/sites-available/default
```
nano /etc/apache2/sites-available/default
```
  Edit as such:
  
  <VirtualHost 12.34.56.78:80>
  
  You will also want to update the DocumentRoot value to where you intend to install your Drupal root.
  
  DocumentRoot /var/www/example.com/html
4. Configure name-based virtual hosts
  
  Create a file in
```
/etc/apache2/sites-available/
```
  for each of your sites on the server.
```
nano /etc/apache2/sites-available/example1.com
```
  <VirtualHost 12.34.56.78:80> ServerAdmin admin@example1.com ServerName example1.com ServerAlias www.example1.com DocumentRoot /var/www/example1.com/html/ ErrorLog /var/www/example1.com/logs/error.log CustomLog /var/www/example1.com/logs/access.log combined </VirtualHost>
  
  Repeat this process for each site you are setting up. Note that separate sites will have different DocumentRoot values, while a multisite setup will share the same DocumentRoot value.
  
  Git note: If you are going to deploy using Git (covered in the next step below), you want to define your DocumentRoot to include your Git repository name and any internal paths to your Drupal document root. For example, if you are installing from a GitHub project titled "foobar" and inside of it you have a folder "html" that contains your Drupal installation, your DocumentRoot value would be /var/www/example.com/foobar/html/.
5. Create your website folders
  - First, create the folder for your logs.
```
mkdir -p /var/www/example.com/logs
```
    This command will create your logs folder, and the domain folder containing it.
  - Now create your website html folder(s).
    
    How you do this depends upon how you're going to install your site on the server.
    
    If you are using scp or sftp or otherwise copying your Drupal code files onto the server, you will want to create the folder to hold them. Remember that your DocumentRoot value you entered above must match where your actual document root ends up being on the server.
    
    If you are going to be deploying via Git, you don't need to do that: Git will create it when you git clone the repository onto the server into /var/www/example.com/.
6. Enable the virtual domain
```
a2ensite example.com
```
  Do this command for each domain or subdomain you're configuring here.
7. Reload Apache
```
/etc/init.d/apache2 reload
```
Assuming that you have configured the DNS for your domain to point to your server's IP address, virtual hosting for your domain should now work.

Of course, there's still more server prep to do so you can run Drupal....
Build PHP, MySQL and the goodness Drupal loves
1. MySQL Installation
  
  First install the thing.
```
apt-get install mysql-server
```
  You will be prompted to create the MySQL root password, and re-enter it.
  
  Now we secure the installation.
```
mysql_secure_installation
```
  You will be prompted to set/change the MySQL root password and other things. You won't need to change the MySQL root password, but you probably want to answer "Y" yes to the other questions.
2. Create your database
  
  Log into MySQL.
```
mysql -u root -p
```
  The -u defines the mysql user, which in this case is mysql root user, 'root'. You will be prompted for the MySQL root password. When you get a prompt like this:
```
mysql>
```
  …you're in!
  
  Now create your database. [In this example, the database name is 'foobar', the database user is 'rumpole', and the user password is 'p4ssw0rd'. Change these to the actual database name, database user and passwords you want for your database. Be sure to note these down, because you'll need this info when you set up your Drupal site.]
```
create database foobar CHARACTER SET utf8 COLLATE utf8_general_ci;
```
  [Update: You need to set the CHARACTER SET and COLLATE values, as shown above, or MySQL will default to non-recommended latin1 / latin_swedish_ci.]
  
  Note the ';' at the end of the line. That is required for MySQL to execute the command.
  
  Define the user and permissions for the database. I'll keep it easy here:
```
grant all on foobar.* to 'rumpole' identified by 'p4ssw0rd';
```
  Now wrap this up and quit MySQL:
```
flush privileges;

quit
```
3. Install PHP
  
  Use apt-get to pull down the packages.
```
apt-get install php5 php5-dev php-pear php5-gd
```
  Note that php5-dev is not necessarily required, except you will need it later for the PECL installation of UploadProgress (which is very nice to have for the Drupal user interface). php5-gd is to enable nice image handling.
4. Configure the php.ini settings.
  
  Edit the appropriate php.ini file:
```
nano /etc/php5/apache2/php.ini
```
  This is a big file. You will need to search through the file to find these value configurations.
  
  You will want to boost the default memory limit value.
  
  memory_limit: 128M
  
  (128MB is the default for Lucid. If you're running a lot of modules, or some heavy processes, you may need to increase this memory_limit value even higher.)
  
  Now, while you in php.ini, make sure that the following lines are uncommented and have proper values established.
  
  max_execution_time = 30 error_reporting = E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR display_errors = Off log_errors = On error_log = /var/log/php.log register_globals = Off safe_mode = Off session.cache_limiter: nocache
  
  ~~You will also need to add lines for PDO support. Find the Dynamic Extensions area in the file, and add these lines:~~
  
  ~~extension=php_pdo.dll~~
  ~~extension=php_pdo_mysql.dll~~
  
  [Edit: You don't need to add these in Ubuntu 10.04. As it happens, Lucid comes with PDO extensions already enabled. Thanks to Peter Wolanin for pointing out in comments below what should have been obvious about .dll extensions in Linux. #facepalm]
  
  Refer to http://drupal.org/requirements for details and nuances on php settings.
  
  To have these take effect, restart apache.
```
/etc/init.d/apache2 restart
```
5. Install PHP MySQL and Security Packages
  1. Let's start with MySQL.
```
apt-get install php5-mysql
```
  2. Update your sources.
    
    Now be sure the following lines in /etc/apt/sources.list are uncommented:
```
nano /etc/apt/sources.list
```
    deb http://us.archive.ubuntu.com/ubuntu/ lucid universe deb-src http://us.archive.ubuntu.com/ubuntu/ lucid universe deb http://us.archive.ubuntu.com/ubuntu/ lucid-updates universe deb-src http://us.archive.ubuntu.com/ubuntu/ lucid-updates universe deb http://security.ubuntu.com/ubuntu lucid-security universe deb-src http://security.ubuntu.com/ubuntu lucid-security universe
  3. Update what you have so far.
```
apt-get update
```
  4. Boost security a bit.
    
    Now install the php5-suhosin package to provide additional security.
```
apt-get install php5-suhosin
```
  5. Restart apache.
    
    To have these take effect, restart apache.
```
/etc/init.d/apache2 restart
```
6. Enable mod_rewrite
  
  This is easy peasy in Ubuntu because the PHP module is already installed; you just need to enable it:
```
a2enmod rewrite
```
  And restart apache again:
```
/etc/init.d/apache2 restart
```
7. Install PECL UploadProgress.
  
  This allows you to have that nifty upload progress display when uploading files. It's not required, but is useful user feedback, which I recommend highly.
  1. First, update.
```
apt-get update
```
  2. Run the PECL installation of UploadProgress.
```
pecl install uploadprogress
```
  3. Now save the setting.
    
    Note: This is all one line!
```
echo "extension = uploadprogress.so" > /etc/php5/apache2/conf.d/uploadprogress.ini 
```
  4. Reload Apache to have it take effect.
```
/etc/init.d/apache2 reload
```
  Done!
Optional
1. Install Git
  
  If you want to use Git to deploy your site code, you will need to install Git itself.
```
apt-get install git-core
```
2. Install Drush and Drush Make
  
  Drush installation instructions are in the Drush readme.txt file.
3. Install APC
```
apt-get install libpcre3-dev
pecl install apc
```
  Then edit your php.ini file to add to the extensions area:
  
  ; APC extension=apc.so; apc.shm_size=64M;
  
  Then you can copy over a php file that offers some nice stats:
```
cp /usr/share/php/apc.php /var/www/example.com/html/apc.php
```
  Note that the path of the destination is your webroot.
  
  Then restart apache.
```
/etc/init.d/apache2 restart
```
  And you're done. You will be able to get some nice APC stats at http://example.com/apc.php. (You can always protect that file via .htaccess to put an authentication password on it if you like.)
4. Install fail2ban
  
  Fail2ban is a nice little security addition.
```
apt-get install fail2ban
```
  That's all on that.
5. Install bash-completion
  
  Bash-completion is a new one for me, and is turning out to be very handy. How did I go so long in the dark?
```
apt-get install bash-completion
```

And that's it. Now your system is ready for site deployment to the folder you defined. Note that after you've deployed your site you will also want to set up a cron job.

IANASA

I am not a sysadmin by profession. This is just documentation of what I do for my own projects, or when tossing up a staging server for one of our in-house or client projects. Any tips for improvement, corrections, etc. are most welcome.

Update: Clean URLs problem?

Recently I've run into an added complication with setting up Lucid: clean urls were not working. rewrite_module was enabled, .htaccess was there, but no go. As it turns out, .htaccess was not being read by default. If this happens to you, here's a fix:

Edit the default site configuration in sites-available:

nano /etc/apache2/sites-enabled# 000-default

A few lines down, under the directory pointing to you docroot, you need to change "AllowOverride None" to "AllowOverride all".

<Directory /var/www/[pathtoyourwebroot]>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride all
                Order allow,deny
                allow from all
        </Directory>

Now restart apache.

/etc/init.d/apache2 restart

And you're done. Clean urls should work for you now.

For more information on this, see http://drupal.org/node/945860. To read about other ways to configure Apache and avoid the performance hit of using .htaccess, see http://drupal.org/node/43788.

A New Year. A New Drupal. (A New Era.)

Laura Scott — Wed, 05 Jan 2011 18:27:05 +0000

2010 was an amazing year. But 2011 has come in with such a bang, it's impossible not to look forward.

Drupal 7 is out!

Drupal 7 is a whole new Drupal

It has been a long time coming. Drupal 6 came out some 3 years ago. That in many ways was the time when Drupal emerged from relative obscurity, where it was known only by open source aficionados, PHP geeks and a few untold thousands of independent website owners who knew a good thing when they saw it, to a CMS recognized worldwide as one to be reckoned with. More powerful than Wordpress, more flexible than Joomla!, more affordable (and flexible and, in many ways, powerful) than proprietary systems like Vignette, Drupal 6 came on the scene the quiet hero to many site owners. [Note: I mean no disparagement against Wordpress or Joomla!, which are active open source web software projects, and we like open source software! But each is different; describing how so is something to be left for another blog post another day.]

We here in this shop have had the great fortune of being able to work with Drupal 6 on a number of projects — and each of us individually beforehand — playing a small part in a very large and impressive community.

Drupal 7 promises to step everything up a notch.

Right now, we have a couple of Drupal 7 projects in house that are in the last strategic planning and architecture phases, which means that we — and especially Brian Vuyk, who contributed 33 patches to Drupal 7 and, last year, took over the Primary Term module, while offering up and testing patches for a number of contributed modules — will be bringing a lot of time and attention to some interesting modules needing upgrades, as well as perhaps a new one or two.

Meanwhile, as announced here before, the Square Grid theme and the Floater theme are both available for Drupal 7. (Confession time: They're still not tagged as official stable releases, but Square Grid is actually quite stable currently; Floater has some sprucing up for its 1.0 release. Expect stable releases of each very soon!)

How far we've come in just a few years!

I first discovered Drupal in 2004. I joined the community in November of that year. Back then, Drupal 4.5 was new. Theming was an order of magnitude more difficult than it is today. Modules did not have installation routines, you had to manually execute MySQL commands to add or update tables. PHP 4.whatever was the standard. You had to get into the code quite a bit to set up any kind of site.

Since then, Drupal has grown. Ultimately, the test for Drupal 7 is just beginning. My expectation is that people will respond with enthusiasm and delight, and Drupal will continue its phenomenal growth with every major release.

And yet this is open source, and the drop is always moving. Drupal 8 is coming!

PINGV Creative's DrupalCon Proposals

Laura Scott — Fri, 17 Dec 2010 07:54:00 +0000

DrupalCon Chicago session proposal voting is open. This time around we've proposed a couple of sessions. If they sound interesting to you, please vote for them! To help ensure that DrupalCon is loaded with a nice variety of high quality presentations, the organizing team's curation process for the final slate of sessions is not solely based on the voting:

Once the voting closes the track chairs will use the voting results, limits on number of sessions a speaker can speak at, feedback from previous DrupalCons, input from the team for the track, their experience and expertise in the area to fill the available spots in their track.

…but the votes certainly help!

Client-provider success factors

Over the past five years, Kate has worked with clients of all sizes in the business, educational, non-profit and government/NGO sectors. Prior to that she was on the other side, managing vendors for startups and Fortune 50 companies.

This one is for companies and organizations looking to engage a Drupal design or development shop for a project or projects, as well as for shops still feeling pressed by the client-vendor relationship dynamics. Kate Lawrence talks about success-factors, choices, and pitfalls both the client and provider face during a web development project.

What is an effective RFP? What makes for a good project/vendor match? How do you define and manage scope, especially in projects lasting months? What are some of the best communication strategies? What are common mistakes that can endanger a project's success?

The presentation will focus on real-life situations, not abstract or theoretical ones.

On the Drupal side, it ranges from the solo-shop all the way to one where client relations are handled by a specialist. On the client side, it is from the one-person client all the way to the Fortune-50 firm.

Grok Drupal Theming

Laura has been theming Drupal since 2004. She's presented on theming fundamentals and design at DrupalCon San Francisco, DrupalCon Paris, DrupalCon Boston, OSCMS and DrupalCamp Colorado.

This session is for web designers and front-end developers new to Drupal — it's an overview of how themes work in Drupal. The technical architecture may seem complex, but it's actually quite simple once you grasp the concepts and structures.

What are the core templates, what do they do, and how they work together? What are Drupal design patters to be aware of? What is $content and why does it output different things in different templates? How can specific fields be displayed or suppressed? What happens in template.php? How does the parent-child theming thing work?

And since we're talking about Drupal 7, this might also be of interest to experienced Drupal themers who haven't had a chance yet to dive into Drupal 7.

A lot has changed since my presentation in San Francisco [slides]. Drupal 7 theming may seem incredibly complex, but once you grok the conceptual framework, it all starts to fall into place.

Voting closes soon!

You have until December 24th at 9am ET. So what are you waiting for?

Resolving Door

PINGV Creative — Thu, 02 Dec 2010 23:25:42 +0000

The University of Colorado School of Journalism brings crowdsourced answers to students' pressing questions.

A Web App (not a website)

The new site has streamlined navigation with a user-centric experience as its focus. Added colors add to differentiation of cont

The Challenge

The old site had been running for a while, but had some serious UX and functionality problems.

Rethinking the LAMP stack — Drupal Disruptive Open Source Part 2

Katherine Lawrence — Thu, 02 Dec 2010 22:17:25 +0000

Is Drupal a Disruptive Technology?

What if Harvard College takes on Notre Dame in football. Of course we can beat them; after all, they're only men.

—Professor Harry H. Hansen, Harvard Business School, on understanding the limits of the possible.

There is a lot of talk, some would say hype, about Drupal being enterprise-ready.

Certainly Drupal is no piker system. From a relatively unknown Content Management System (CMS), Drupal has burst on the scene and now accounts for one-percent of all websites, which to some might seems small until we stop to think how big the web is.

Those in the Drupalsphere are quick point out our successes — whitehouse.gov runs on Drupal, as do scores of other sites with brand names that are household words.

My business Partner, Laura Scott, and I have upgraded dozens of existing systems that are undeniably enterprise-level. I say "systems," here, because almost by definition, the enterprise-level clients, for better or worse, have been on the internet for some time prior to seeking our help in the move to Drupal. Enterprise-level clients have grown sites over years. Technologies, like geological layers, have been set down over time, depending on historic decisions that changed as time went on.

In the year 2000, the Y2K problem surfaced when it was discovered that some legacy software was written in a way that did not allow the date to change from 1999 to 2000, since only the last two digits of the year were programmed to change. The programs, written in the 1960s and 1970s was still in use in 1999 running beneath spiffy new interfaces. Who would have thought mid-20th century software would be running in the year 2000, yet it was.

This puts the enterprise-level projects in the category of "most demanding," as we will see, below, in the Disruptive Technology graph.

As a Drupal shop, dealing with legacy systems comes with the territory. For example, in 2007, as pingVision, we migrated Popsci.com from Vignette, a leader in proprietary CMS software, to Drupal 5. The hitch was the Popular Science's Vingnette database was Oracle and not MySQL, the latter which is standard for the LAMP stack. Moreover, legacy features and already-existing third-party applications required integration of (sometimes) vaguely documented and fluid APIs, all of which is to say that it's a "jungle out there," once we get outside of the LAMP Stack.

Linux, Apache, and Bears ... oh my!

The existing LAMP stack elements are seemingly inseparable

Drupal has made impressive inroads and in numerous instances has competitors like Vignette. The plucky open source folks have built some superb software built on the bedrock of Linux and are taking on ever-bigger and ever-better.

The entrenched competitors have heard of us, and they are taking notice. We might not dominate today, but mighty oaks grow from acorns and there are those who wonder if Drupal might be up to turning the market upside down, as is the case of a truly disruptive technology.

In part one of this article, which appeared on the PINGV Creative website in July, 2010 Drupal Disruptive Open Source: Part I — From Brobdingnag to Lilliput, I addressed the rhetorical question posed by Drupal's Founder, Dries Buytaert, in his in his keynote at the 2010 San Francisco Drupalcon: Is Drupal a disruptive technology?

Product improves to serve more demanding markets. Image: Sun Blogs.

The term, "disruptive technology," was coined by Harvard Business School Professor Clayton Christensen and popularized in his best seller, "The Innovator's Dilemma." (ISBN 0-06-662069-4)

In its lowest terms, a disruptor enters a marketplace with an alternative technology and "kills" the leader(s).

The oft-cited classic case-set (one of many examples of disruptive technology) tracks the growth of American minimill steel makers, such as Nucor and Chaparral. Over time steel minimills displaced traditional American steel-makers such as United States Steel and Bethlehem — the integrated mills. The minimills entered the market at the low-end in undemanding applications such as rebar. Over time, and incrementally, the minimills improved their manufacturing technology until they were capable of manufacturing top-quality, high profit, steel. Inasmuch as the minimills had a cost advantage relative to the integrated mills, the traditional steel companies closed their mills and were driven from the market.

LAMP Stack — the Minimill analogy

The LAMP stack is the magic in some Open Source Segments.

David Recordon of Facebook in his keynote at the Open Source Convention (OSCON) in July, 2010, addressed the evolution of the LAMP stack. He traced the name, LAMP, back to an article in magazin für computertechnik by Michael Kunze titled "Let There be Light."

Published in April 1998, an English translation appeared in December of the same year. The tout reads:

Web publishing is hip: Not only the media companies, but also many medium sized and small companies want to make their data available to customers or staff on the net. By choosing freeware components, this can be done in a very budget-friendly way.

The formula is similar to the minimills — it is "budget-friendly" and does not go after the big fish. It pieces together (modular) components that are open source, giving the LAMP stack a cost advantage.

One model of disruption asks us to picture Drupal as the market/technology leader (more integrated) and WordPress as a disruptor (less sophisticated). Such an analysis makes sense inasmuch as Drupal is seen as more complicated and more suited to enterprise-level applications. WordPress is emerging with more sophistication, without the perceived "daunting" learning-curve of Drupal.

Yet, such a view might be somewhat parochial, for these technologies compete within the LAMP-stack "pond," just as the minimill steel makers Nucor and Chaparral battled it out in the early rebar days, making steel with the least demanding performance specifications.

The LAMP stack has been around for over a dozen years. What else happened in 1998?

Microsoft launches Windows 98
Google is founded
Paypal is founded
Apple's iMac is introduced

A lot has happened since then and surely the LAMP stack has evolved, but only now are the limits of the LAMP stack, testing its limits with enterprise systems.

Linux, Apache, MySQL, and PHP … our creed!

"The speed of the whole is the sum of its moving parts."

We all have heard of the Stone Age, the Bronze Age, and the Iron (Steel) Age.

Once ships were moved by paddles, later aided by wind, and finally fully by wind. Then came steam powered by coal and later petroleum. Now many are nuclear — though, looking closer, we see steam, internal combustion, and electric motors are still part of the equation.

The 19th century was the heyday of mechanical engineering. The 20th century was dominated by electromechanical technology. By the 21st century, engineers have tried to minimize the traditional moving parts, preferring to move electrons and/or pieces at the nano-level. The payoff has been speed and reliability.

For the most part, the LAMP stack is rugged and fast, with few moving parts — except for the Tin Man — the servers. This may change as the cost of use of solid-state drives (SSD) declines, but for the time being, even with SSDs, manipulating data remains the rate determining step. That is, in any system, the slowest step determines the over-all speed of the system.

The old mainstay of the LAMP stack, MySQL, is being re-examined, more-so than most of the rest of the stack. At one point, MySQL ceases to scale linearly — not just theoretically, but from a practical standpoint in that the data itself is busting from its digital cabinets.

Sharks and Little Fish

Going from Brobdingnag, where everything is larger than Gulliver, to Lilliput, where everything is smaller than Gulliver, has been the story of the electronics revolution. The large contraption gets miniaturized, requires less power to operate, and yet achieves the same amount of output. Microcircuits and microprocessors are at the core of this example.

On the other hand, this shrinking in processing power has afforded a low-cost means to preserve a lot data. Creating more and more while getting cheaper and cheaper.

My previous article ended with a nod to "big data" and to Enterprise Content Management, ECM. I have linked to the original post for those who are interested, but in short ECM is,

[a] market, with $4 Billion of annual revenue, dominated by a few key players who are acquiring one another through a series of nine- to ten-figure buy-outs. For example IBM paid $1.6 Billion for FileNet. Documentum fetched $1.7 Billion when EMC2 added them to the corporate family. Just recently Open Text gobbled up Vignette to the tune of $321 Million.

It is almost certain that the capitalization of the Drupal ecosystem is small in comparison to the ECM market. Acquia, for example, received $7M of first round financing from North Bridge Venture Partners in 2007 and additional amounts in subsequent rounds. Though a respectable sum, it is dwarfed by the capitalization of the ECM market.

The ECM customers are the Fortune 500 and the Dow-Jones 30, so that the number of instances is small compared to the number of Drupal and WordPress websites. However, the cost per enterprise-level site is large in comparison. The ECM suppliers have extensive SEC filings, not to mention press releases and PowerPoint presentations that give us significant insight into the enterprise market-place — and the conventional LAMP-stack would be hard-pressed to meet the requirements of the client-base.

From the publicly available material, the "budget-friendly" aspect of the LAMP-stack has not excited the ECM market-place, nor has the benefit of an open source code-based maintained by a solid community.

The Enterprise system must address all of the above.

For ECM vendors, the actual sales transaction is small, relative to the what happens before and after.

We as consumers — say, going to the mall — are offered a lot of merchandise, much of which we glance at without a second look. Then — something strikes our eye; the quality is good; the price is affordable; we take the purchase to cash-wrap and head to out next destination.

But the transaction is only a part of the larger process where the mall store management chooses an item, warehouses it, ships it to store, sets up the display, and sells it – not to mention deals with defectives, returns, and items that simply do not "move."

The enterprise-ready system has two tails — pre-transaction and after-purchase. That is, the purchasing transaction is not much more than an inflection point in the cycle, the "knot" of the bowtie.

There is more to the transaction

The ECM customers do not seem particularly bothered that their software is proprietary, or even customized. The key factor for the client seems to be on-going support all along the business transaction.

LAMP stack as disruptor

Historically the LAMP stack has served a market that for the most part does not have extreme performance criteria, but which is price-sensitive. The margins are not there for the kind of intensive customer service, support, and documentation offered by the ECMs.

Briefly, let's compare and contrast the players and who is serving the high-end and how these deals size up.

The ECM client engagement average is $250,000. About a half the revenues are from Customer Support, a quarter of that is for the software license, and a quarter is service. Maintenance contracts are for one to two years with a large majority being renewed.

Annual industry sales in the ECM arena approach $4Billion. With the average deal-sizes of $250,000, that translates into 12,000 deals per year.

Some ECMs are said to be making 25% gross margin. Of every revenue dollar, 15% is spent on software development, another 24% is spent on sales & marketing, while 9% is expended on administration.

If an ECM firm has annual revenues of $250M, this is equivalent to one thousand deals of $250,000 each, or three six-figure deal every day. SEC files indicate that firms of this revenue level employ about 1,000 people. Finance gurus and technical elves who look at these kinds of breakdowns will point out that the revenue-per-person of this hypothetical ECM is $250,000/employee/year. Billing that out over a man-year means that these firms are billing at the gross-equivalent of $125/hour.

Data gathered by the Lullabots in their article "Show Me the Money" suggests the better-known Drupal shops are billing at about the same rate — $125/hour, possibly a bit higher.

The long-standing Drupal shops are making seven-figures, but few are making eight. That is, a few are breaking $10M annually, and there is no evidence that there are any players making $30M per year.

In the Drupal world, the majority, if not all, of the hourly rate will be for implementation — not 15%. A Drupal shop doing $10M annually and billing at $125/hour, would require 38 fulltime coders working 40 hours a week, outside of breaks, lunch, or meetings (that is, 100% billable) to hit that number, which is about 1% of the annual volume of a large player such as Open Text.

Put another way, if Open Text writes a $250,000 deal and only 15% is code-related, the coding "burden" is $37,500. At the $125/hour rate, this is a 300 hour coding assignment, a modest sized job for shops that do projects in the 1,000s of hours.

And there are more ways that the Drupalsphere is different.

There are the vaunted seven-figure-deals, but no shop is getting these on a weekly basis, nor is the Drupal community structured to handle such activity.

Put this another way. Assuming a $4B yearly industry revenue with $125/hour average labor rate. This means 32,000,000 labor-hours are devoted to this sector each year. That's about 15,400 people working 40 hours a week.

The value proposition for an enterprise-level site leveraging 32M labor-hours outside itself, is that the client will save even more, inside.

The Integrated Solution — an investment, not a cost

Firms engaging an ECM justify their decision based on Return On Investment (ROI), which translates into increased productivity or other cost-saving measures.

Throughout the era 1950 – 1975, what today we call the Information Technology (IT) group in most businesses was an offshoot of the Accounting Department or the Controller's office. International Business Machines, IBM, sold hardware with customize software packages to manage unique businesses. As one Harvard Business School classmate explained in Ken Hatten's "Management of Small Enterprises: Operating Problems,"

You could buy an IBM System 360 that would manage a New Zealand sheep ranch and also could buy [a System 360] to handle selling airplane parts in Seattle. The software would address the different products, but underneath it was pretty much the same basic software, customized and tailored to the end-user's product or business.

Starting in the mid-1970s, almost as an act of faith, businesses began to invest in business management hardware and software, especially integrated systems. Up to this point, in terms of workflow, departments within a company were largely self-standing, if not quasi-antonymous. For example, a sales department might received a sales order for a specific type of thing, for a certain amount, at a certain price. This order would be manually transmitted to the fulfillment area — a warehouse, assembly line, production facility, what-have-you — and then the shipping department or traffic department would (again) enter in the name, destination, and delivery information. Also, somewhere along the line, invoicing and collecting payment and replenishing raw materials or inventory also took place, the latter usually handled by the purchasing department.

Integrating the information into a single system made logical sense, but making it all work required more than logic — it required sustained investment into the business infrastructure.

New words entered the lexicon. Some from Japan, like kaizen and kanban. Others, acronyms like JIT — Just In Time — were bandied about. Software, such as ManMan, was introduced by ASK Computers. The lineage of acronyms continued: Material Requirements Planning (MRP) and Manufacturing Resource Planning, (MRP2), which gave way to Advance Planning and Scheduling (ASP) and more recently Enterprise Resource Planning (ERP).

Business economists say that for the first five to ten years of this period, businesses continued to invest in systems, not just hardware or software, that would allow them to increase their productivity. By the 1990s, productivity gains of about 20%, sometimes more, were being realized and the faith in the new systems was finally justified, because the productivity increase tended to fall through to the bottom line.

ECM Players compete in a $4 Billion market. Image: CMS Watch.

The client firms handle a great many transactions of all shapes, sizes, and forms, and the data generated as part of doing business is growing in proportion to the computing power of the microprocessors running the systems.

From jawbones to backbones

Of late there has been a lot of discussion of "Big Data," and how to handle it.

Big data flows mainly from big business. In the 1980s the patient data at a typical medical facility was legion — cabinets full of handwritten notes recording visits, laboratory results, and x-rays — much of how this was handled was a matter of law and statues, filling room after room.

Today a great deal of this information is stored electronically, because it can be.

The information highway might be a great idea, but as we have learned with most highways, they soon get clogged and the information highway sometimes seems more like the information traffic jam.

2001: a Dataspace Odyssey — I think the server's front panel is in the dirt.

We are learning new numbers. In a recent Reuters article, an author tells us the iPv6 standard will allocate a "trillion, trillion, trillion." addresses. Wisely, the author did not use the word "unodecillion."

We have rapidly moved from thinking of data in megabytes to gigabytes to terabytes, and beyond:

1,000 terabytes = 1 petabyte
1,000 petabytes = 1 exabyte
1,000 exabytes = 1 zettabyte
1,000 zettabytes = 1 yottabyte

And these numbers are finding their way into the way we measure — sometimes daily,

Google processes about 24 petabytes of data per day.

AT&T has about 19 petabytes of data transferred through their networks each day.

4 experiments in the Large Hadron Collider will produce about 15 petabytes of data per year, which will be distributed over the LHC Computing Grid.

The German Climate Computing Center (DKRZ) has a storage capacity of 60 petabytes of climate data.

As of June 2010, Isohunt has about 10.8 petabytes of files contained in torrents indexed globally.

The Internet Archive contains about 3 petabytes of data, and is growing at the rate of about 100 terabytes per month as of March, 2009.

World of Warcraft utilizes 1.3 petabytes of storage to maintain its game.

The 2009 movie Avatar is reported to have taken over 1 petabyte of local storage at Weta Digital for the rendering of the 3D CGI effects.

—http://en.wikipedia.org/wiki/Petabyte

In a 1999 website, Roy Williams of Cal Tech, offered that 2 petabytes could hold all US academic research libraries. 200 petabytes could hold all printed material.

Every year the data mass increases 60-percent

Digital Data; Linear Graph

In 2007, the digital universe was 281 exabytes. That is: 281 billion gigabytes, and in that year, for the first time, the data generated exceeded storage capacity. Next year, one prediction says it will be 1,800 billion gigabytes. That is 1.8 zettabytes — a number so unfamiliar that Microsoft Word spellchecker does not recognize it.

A zettabyte is a billion terabytes.

The data universe will have increased 10-fold from 2006 to 2011. Taking the 5th root of 10 (fold) gives just under 60% compound growth — we'll contrast that to Moore's Law, in a later section.

Not all information created and transmitted gets stored, but by 2011, almost half of the digital universe will not have a permanent home.

Fast-growing corners of the digital universe include those related to digital TV, surveillance cameras, Internet access in emerging countries, sensor-based applications, datacenters supporting “cloud computing,” and social networks.

Exaflood of Data — we're talking of millions of terabytes of drive space.

Some call it the Exaflood.

How dire it all is has been debated. Some studies say that data is being generate faster than there is capacity to store it. Others say that this is alarmist, and that there are solution that avert a data storage disaster.

It is a valid concern as to whether there is enough storage space, but focusing only on space, and not on retrievability, let alone what problems are in fathoming the relationship of the various datum, can overshadow what the implications, both good and bad, of having so much data with which to deal.

Moore's Law

In April, 1965, still a relatively unknown physical chemist, Gordon Moore, wrote a three-and-a-half page article in the journal, "Electronics." The tout said the writer "is one of the new breed of electronic engineers, schooled in the physical sciences rather than in electronics."

Hardly 2000 words in length, it gets right to the point,

The future of integrated electronics is the future of electronics itself. The advantages of integration will bring about a proliferation of electronics, pushing this science into many new areas….

Integrated circuits will lead to such wonders as home computers or at least terminals connected to a central computer, automatic controls for automobiles, and personal portable communications equipment.

But then the enduring insight,

The initial picture of Moore's Law, as it appeared in "Electronics Magazine," did not have the grid-lines of the log-log function. A copy of the original graph was overlaid on a log-log graph, with some unanticipated registration issues. The grid-lines add some "drama" to the shrinking of traces-and-spaces as more and more is placed onto less and less.

Machines capable of processing data faster will also generate data more quickly. Moore's Law suggests computer power that grows geometrically will produce data geometrically.

The complexity for minimum component costs has increased at a rate of roughly a factor of two per year

IDC in 2008 provided some data about the growth of data. In a 2008 study, IDC states that from 2006 to 2011 — five years — that data will increase 10-fold.

Digital Information Created, Captured, Replicated, Worldwide Exabytes Log

The venerable LAMP stack

The pressure on the database piece of the LAMP stack is only increasing. The database piece is not only being strained, but it is being rethought.

Pay to attention to the data structure behind the curtain

The LAMP stack is not a monolithic thing, and probably never has been. Andrew Astor in his August, 2005, article, "LAMP's Dark Side," says, in part,

[LAMP's] open source components are well known, readily available, and work well together for many tasks, particularly for serving Web sites without update-intensive database requirements. However, LAMP's role as a merely illustrative stack of open source offerings is hardly ever acknowledged; in reality, each layer of the LAMP stack is fungible. No one layer was expressly designed to work with the others, and neither do any of them work better with the others than do alternatives. For example, the PostgreSQL and EnterpriseDB databases work just as well with "L," "A," and "P" as does MySQL. Similarly acceptable substitutions are, of course, available for each other layer in the stack …

… The danger is that this specific software combination will become so institutionalized that an enterprise finding one layer of LAMP unsuitable will end its inquiry, declaring that "the" open source stack cannot meet its needs. That's bad for Linux, bad for open source software, and bad for enterprises.

David Recordon (Facebook) "Today's Lampstack"

Breaking out of the LAMP stack may be inevitable. In a July, 2010, article titled, "The Next LAMP Stack: Hadoop Platform for Big Data Analytics," author Brett Shepherd writes

Many Fortune 500 and mid-size enterprises are intrigued by Hadoop for Big Data analytics and are funding Hadoop test/dev projects, but would like to see Hadoop evolve into a more fully integrated analytics platform, similar to what the LAMP (Linux, Apache HTTP Server, MySQL and PHP) stack has enabled for web applications.

As Michael Dell, founder and chief executive of Dell, told the Financial Times:

We are still in the early stages of our industry in terms of how do organizations take advantage of, and tap into, the power of the information that they have. The IT revolution is just beginning”, May 19, 2010

As the Hadoop data stack becomes more LAMP-like, we get closer to realizing Jim Gray’s vision and giving enterprises an end-to-end analytics platform to unlock the power of their Big Data with the ease of use of a Lotus 1-2-3 or Microsoft Excel spreadsheet.

The early data systems were built around some captive servers and stored what the IT Department was charged to manage, almost Ptolemaic view where, like the universe orbited Earth, everything revolved around the central computer and was very ordered.

Today that is no longer the case. There is data and lots and lots of it, and with the web, even quasi-Luddites are searching the web and adding to the collective storage.

Moving beyond traditional Relational Database Management Systems (RDBMS) can happen when the data base has non-traditional relationships. Like Ptolemy where the universe orbited Earth, everything revolved around the central computer, rational databases revolving around them, and everything was very ordered. With databases existing outside of traditional scheme of things, we are entering more of a Copernican view of the world.

To many, if not most people working in Open Source, the "M" in the LAMP stack acronym stands for: MySQL — a so-called Relational Database Management Systems (RDBMS).

Traditional RDBMS work well where the data relationships are believed to be well thought out and believed well understood, or at least well-defined.

At one time, it was widely held that the sun, moon, and stars revolved around the Earth, which was the center of the universe; and that system worked. Clocks, seasons, festivals, horoscopes, and navigation all worked with a model of the Earth at the center of all things. The RDBMS related the celestial and physical worlds to a central point of Earth-at-the-center.

Snigger though we might today, setting the Earth at the center worked. Only in 1543, about 50 years after Columbus discovered North America, was Copernicus' "De revolitionibus orbium coelestium" published, and even then, celestial motion was not fully explained. It would be another fifty years, 1598, when Kepler would make his breakthrough and discover planetary orbits were not circular, but elliptical.

One way to think about what these discoverers did was to change the reference frame — the relationships — and for many, this shift did not come easy. In fact, others prior to these individuals, had gone outside of the Ptolemaic system. Yet, something was happening in the world, where things came together and built upon one another — a recurring pattern in technological breakthroughs to the present day.

This isn't a question confined just to the LAMP stack or open source.

Drupal may well end up being a disruptor of ECMs in so far as it can adapt itself to arcane databases and the other "geological layers" of what has come before.

As we saw a decade ago, when Y2K caused consternation and panic in some circles, that what we are given isn't always what's pretty, neat, and tidy, or as Emma, the Regent of Japanese-Buddhist hell complained, a ruler can't always chose his kingdom, meaning every terrain has its immutable rules.

Coming full-circle regarding disruption, the LAMP-stack's next challenge will be the shift from what "plays nice" database-wise, to being an adaptive platform that can interact with large datasets of different types.

This takes us deeper into what databases mean and how open source might uniquely play a role.

This will appear as part 3 of this series.

The National Interest

PINGV Creative — Fri, 17 Sep 2010 01:50:19 +0000

With an archaic website that was virtually non-functional, The National Interest magazine needed to (re)invent its online presence

New home page

The new website was designed to emphasize both daily web content and the print magazine articles.

The Challenge

The National Interest, the Washington, DC foreign policy magazine, needed a new website, one that better spoke to their established brand and that functionally addressed the needs of staff and readers both. The magazine had long since outgrown their previous content management system and each issue's publication made the discrepancy more apparent.

Weavolution

PINGV Creative — Tue, 14 Sep 2010 18:00:29 +0000

A robust online crafts community needed a site with the beauty and functionality to match that of their own work

The New Site

The new Weavolution represented a re-architecting and redesign, as well as refactoring of broken code.

The Challenge

The old site was running a hacked Drupal implementation that posed many problems.

The original site was not serving its community well. Usability and aesthetics were a concern, especially for a community of craftspeople and artists, many of whom spend very little time on the web.

HTML5 + RDFa = time to get rid of that 20th century furniture

Laura Scott — Tue, 24 Aug 2010 03:20:33 +0000

We're entering a new era of the web. To the ignorant masses, this transition will go largely unnoticed; they'll enjoy increased usability and convenience, with more robust functionality and more relevant data at hand. And they'll mostly just take it for granted.

However, for web designers, front-end developers and data system programmers, we have a lot of work to do.

Why HTML5?

Why indeed? As someone who's worked almost exclusively with Drupal since 2004, my nose has been pretty much in xhtml 1.1. Back then, moving to xhtml took some learning and patience on my part, having played with basic HTML since 1995. Now xhtml feels like the familiar friend and HTML the ugly cousin.

But then I started really looking at HTML5. And the more I am learning about it, the more I am appreciating how HTML5 looks to be a real game-changer.

DOMinate the web

Most of the buzz you see online about HTML5 focuses on the particulars — with the plurality of coverage over how HTML5's media tags stand to push most uses of Flash out to pasture. And that's certainly big.

However, there's something more fundamental in the change HTML5 is bringing to the web. I quote from Introducing HTML5 (Voices That Matter), by Bruce Lawson and Remy Sharp:

Many of our current methods of developing sites and applications rely on undocumented (or at least unspecified) features incorporated into browsers over time. For example, XMLHttp-Request (XHR) powers untold numbers of Ajax-driven sites. It was invented by Microsoft, and subsequently reverse engineered and incorporated into all other browsers, but had never been specified as a standard…. So one of the first tasks of HTML5 was to document the undocumented, in order to increase interoperability by leaving less to guesswork for web authors and implementors of browser.

This is big in itself. But it's not even the biggest thing, imho.

It was also necessary to unambiguously define how browsers and other user agents should deal with invalid markup…. The barrier to entry to publishing on the Web was democratically low, but each browser was free to decide how to render bad code. Something as simple as <b><i>Hello mum!</b></i> (note the mismatched closing tags) produces different DOMs in different browsers. Different DOMs can cause the same CSS to have a completely different rendering, and they can make writing JavaScript that runs across browsers much harder than it need be….

…HTML5 specifies new DOM APIs for drag and drop, server-sent events, drawing, video, and the like. These new interfaces that HTML pages expose to JavaScript via objects in the DOM make it easier to write such applications using tightly specified standards rather than barely documented hacks.

In other words, by clarifying specifics — especially in error handling — HTML5 stands to open the doors for much more efficient and effective JavaScript, heralding a new era for robust interactivity with dynamic interfaces and rich user experiences that would be too heavy and difficult, or impossible, to implement in xhtml or HTML4.

Suddenly that existing markup you have is starting to look kind of musty.

With new language comes new ways of thinking

The other thing to consider is how the web, and the nature of websites themselves, will change as the collective creativity of web designers worldwide starts to not just understand the syntax of HTML5 but also grok on an intuitive, subconscious level how websites can really let go of being collections of pages and embrace their web application natures.

There's a lot of old conventional thinking that is suddenly up for question. For example, while a website as a "navigation menu," an application may instead have a "toolbar": Does that change how you think about those links at the top of your page? People may be less interested in browsing, more interested in searching: Does that affect the role the search form plays in your interface layout?

Of course, for those of us who've been working building software-driven sites (you know, the "Web 2.0" things), this kind of thinking may have been percolating for a while.

Hopefully we'll also have learned the lessons taught by the untold numbers of Flash website designers, who gave us splash pages, annoying, gratuitous motion effects (with obnoxious sound effects), and user interfaces more focused on dazzling the user with the creator's cleverness rather than on serving the user with an interface that serves the user's needs. Here's hoping that HTML5 does not bring us into a new age of craptastic blinky poppy wooshy buzzy design.

HTML5 and Drupal

The Manifesto: http://groups.drupal.org/node/82664
HTML5 Tools module: Module: http://drupal.org/project/html5_tools
A base theme: http://drupal.org/project/html5_base
Another effort: http://drupal.org/project/boron
And http://drupal.org/project/html5
The community discussion: http://groups.drupal.org/html5 & in IRC at #drupal-html5

This is a lively and ongoing process that, so far, has ~~few allies — mostly I think because of the relative obscurity of HTML5 and the design affordances it brings in relation to the world of PHP/Drupal developers. Hopefully that's changing~~ a small but rapidly growing core of themers and developers interested in making this happen, especially in the past few days. Very exciting.

Wither RDFa?

The other side of this revolutionary coin (how many metaphors can I mix into this post?) is the growth and real-world application of RDFa.

In case you didn't know it, RDFa is already here. Google is consuming it where it finds it, using it to generate more accurate and relevant search results. Best Buy is now famous for having enjoyed a 30% increase in sales since incorporating RDFa into their online shopping site.

Robots speaking in complete sentences

That's the net effect of RDFa. You see, currently hyperlinks, to robots, are analagous mystery meat navigation. To the human reader, the nature and location of a hyperlink may make total sense in context — even the mouse-over reveal of the hyperlink URL can yield meaning to us cerebral bipeds. But all a plain hyperlink says to a robot is "follow me." The robot doesn't know who made the link (or the destination site), what the destination is, why the link is there — just where the link is going, and that only by its URL.

RDFa changes that by providing syntax, often abbreviated and/or abetted by libraries such as Dublin Core, to add meaning to the link.

Excuse me, did I say something?

One event happening (almost certainly) this year that could make for some very interesting RDFa developments will be the launch of Drupal 7. Historically, the Drupal user base, community and number of downloads have doubled with each major release of Drupal. And there are a number of factors that suggest that Drupal 7 will be no exception.

What's interesting about this is that Drupal 7 core implements RDFa. This means there are going to be umpteen oodles of websites and web apps out there talking RDFa — and, for most of them, without understanding the language. The amateurs are going to be joining the RDFa party. And that could become cacophonous.

This can mean an RDFa-enabled Tower of Babel. And that prospect has prompted some skeptics to argue against the semantic web. As they see it, we should make robots understand how we make the web, rather than try to remake the web so robots understand. It's an interesting topic, and I recommend Kate Ray's short video on the subject:

[Source: Web 3.0, on Vimeo

From where I sit, perhaps the ideal falls somewhere in a combination? There's no question that Open Data, for example, benefits from semantics. But on the other hand, it would be great to develop parsers that can interpret in existing contexts the underlying semantics of existing content, much like HTML5 provides for the kinds of sloppy markup errors that happen in the web (especially with user-generated content).

Nevertheless, it's hard to dismiss the potential of RDFa when there are be thousands of web developers bringing their creativity and initiative to the rave. For example, in Drupal, one project with interesting potential is AutoRDF, a Google Summer of Code project by Tushar Mahajan, that promises to "automatically tag node content. It will find important words and patterns in a node to tag important keyword and Rdf'ing it. It will build a taxonomy tree."

The SPARQLy Views

The fact that Drupal 7 will play a role in this democratized explosion of RDFa-related endeavors is itself very exciting. And that's not just in the RDFa structure on publishing content, but also in reaching out and pulling in structured RDFa data from elsewhere.

In other words, the web can be like one big website. Jane's site could query Joe's site's data without having any direct access to Joe's database.

One example is the a module (still in development) that leverages the power and flexibility of the Views module to consume and present SPARQL query data.

The SPARQL Views module by Lin Clark will likely be a first introduction for many to the kinds of wondrous things RDFa on the web can enable. Its drag-and-drop query builder will empower people with ability to plug SPARQL queries into Views for customized presentation. Awesome! (Disclosure: I am a Google Summer of Code mentor on this project, so feel free to take my enthusiasm with a grain of salt.)

I want my SEO

Ultimately a — if not the — big convincer for adoption of RDFa will be its effectiveness in getting content noticed. Years ago, Drupal seemed natively and naturally to beat other CMSs when it came to SEO. Drupal sites rose quickly to the top. Will it happen again with Drupal 7 and RDFa? We assume so, but the proof is in the results, and those are still many weeks, perhaps months, away yet.

But imagine what the web will be like when so many sites can be queried and polled from the outside. Information is power, shared information is empowering. When the World Wide Web becomes the World Wide Database, watch out. We'll look back at 2010 as the quaint time of horse and buggy.

Out with the old, in with the new

What this all means is that change is upon us. And all of us web designers, programmers, database administrators, information architects, strategists, and front-end developers need to get busy. We have some learning to do. Some new skills to perfect. Some new thinking to explore. Some new best practices to embrace.

The end user may not really notice as these improvements in user experience roll out. But the end user will notice if you're not rolling with these improvements. Just as a "Web 1.0" site from 1999 stands out to us today as an archaic relic, today's "Web 2.0" sites are going to feel very outdated a few years from now. And just as sites with table-based layouts or built in Flash can make for frustrating user experiences (or out and out inaccessibility) on today's delivery platforms like handhelds and tablets, websites built without the front-end affordances made possible with HTML5 may seem limited to end users, and websites without semantic metadata layers on their content may come off as rather opaque.

As a Drupal aficionado, I'm delighted to have Drupal 7 leading the way on RDFa. However, Drupal is still deeply entrenched in xhtml. The HTML5 phenomenon, while a long time coming, really sparked to life only in the last year — too late to be embraced and incorporated into Drupal 7's core.

But perhaps that's a good thing, because things can happen rapidly in Drupal contrib, and HTML5 is still evolving. So there's a new HTML5 working group on g.d.o to drive towards an HTML5 module (to transform all the markup of Drupal into HTML5-valid code) and an HTML5 base theme.

It's all very exciting. We are in interesting times. Don't stand still. The Drop is always moving.

For further reading:

If you're an Amazon shopper, here's a handy link to Lawson and Sharp's excellent book:

Floater Theme to get away from columns

Laura Scott — Sun, 25 Jul 2010 22:15:04 +0000

As a part of wanting to throw out some of the outdated design furniture of the 20th century, I created a new theme to simply float content elements against each other.

Contributed in a stripped-down version to the Drupal community as the Floater Theme, this theme is about embracing the various kinds of devices and resolutions which people use to access the web. After all, your site could be viewed on a little crap handheld or a big screen 2550 pixels wide. And in theory you want everyone to be able to see what you're offering.

This screenshot is from the soon-to-be-launched LauraScott.net

The first Alpha 1 release of this theme for Drupal 7 has just a few basics:

The main content area is a fixed width.
Blocks in the "right sidebar" (as Drupal 7 currently calls the region) are of fixed width and height, so they float cleanly and line up well with the content.
Narrower-resolution screens get an alternative stacked layout of all the content.
Generic styling (assuming the primary use case will be using this theme only as a base theme).

Once Drupal 7 stabilizes into a Release Candidate, I plan to step into the regions definitions and simplify the regions in this theme. I've generally stayed away from all that for now simply because there's still too much change happening in Drupal 7.

I've been working with Drupal nearly six years now, designed and created dozens of Drupal themes, helped people with theming questions in IRC, and presented on Drupal theming at DrupalCons, but only now have I risen to the CVS challenge and contributed a theme (or any project). CVS is that notorious bugaboo (and barrier to entry) for many designers, but even so I don't know why CVS daunted me so much. I used Subversion (which is quite similar) for years. At PINGV we use Git for versioning. Even so, I was tempted to just wait until the Drupal community gets onto the Git footing later this year.

But today I decided I'd waited long enough. Too long. So there it is. I hope people like the theme. At this point, I have no firm plans on where to take it in terms of features and characteristics. I'm open to ideas.

Square Grid responds for Drupal 7

More options, still lightweight

Configurable tools

Configurable responsiveness options

Internet Explorer options

Simple built-in development aids

Behind the scenes, what you get are:

A grid for most occasions

Lightweight CSS

Mobile first architecture

Content-first page loading

Straightforward grid column settings

No extra extras

Not a fluid grid

Road map items

An HTML5 version

"Nav last" page structure

Configuable column widths

1400px-wide layout

Fluid layout

Upgraded to Drupal 7: Salesforce, Homebox, Stock API, Hierarchical Select

Salesforce

Homebox

Stock API

Hierarchical Select

Oops, that's a cul-de-sac

The commons

D7 to get you through these dog days

When will Drupal 8 be released?

When will Drupal 8 be released?

If Developers were Horses...

Drupal Front-End Developer (Themer)

Open Atrium and Iterations

Too busy doing the doing to talk about the doing?

Rethinking Open Atrium

Wash that nomenclature right out of OA

Defining iterations in Open Atrium

Plan before communicating, and vice versa

Feature think, Feature do

Contrib status

The best user interface is the one you don't notice

Expert interfaces are for experts

The unnoticed interface

Lucidly Drupal: Setting up Ubuntu 10.4 Lucid LAMP stack for your Drupal site

Assumptions

Step by Step

Initial Preparation

Create a public key.

Install security updates.

Set your hostname

Set your server's base timezone

Set up VirtualHost stuff

Install Apache

Edit /etc/apache2/ports.conf

Edit /etc/apache2/sites-available/default

Configure name-based virtual hosts

Create your website folders

First, create the folder for your logs.

Now create your website html folder(s).

Enable the virtual domain

Reload Apache

Build PHP, MySQL and the goodness Drupal loves

MySQL Installation

Create your database

Install PHP

Configure the php.ini settings.

Install PHP MySQL and Security Packages

Let's start with MySQL.

Update your sources.

Update what you have so far.

Boost security a bit.

Restart apache.

Enable mod_rewrite

Install PECL UploadProgress.

First, update.

Run the PECL installation of UploadProgress.

Now save the setting.

Reload Apache to have it take effect.

Optional

Install Git

Edit `/etc/apache2/ports.conf`

Edit `/etc/apache2/sites-available/default`

Configure the `php.ini` settings.