PINGV Creative Blog Feed

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.

Our virtual team toolbox

Laura Scott — Mon, 11 Jul 2011 17:40:42 +0000

Everyone does virtual differently. Having worked in bricks-and-mortar previously, setting up a virtual work system as been something of a mix of experimentation with solutions recommended by others. Here are some of the ways we manage as a virtual company.

Client communications

Email is a place to lose things. We don't depend upon email for critical project communications. We have our own Open Atrium intranet set up for all of our clients. Here we post research documents, wireframes, flow charts, use cases, design mockups, questions, general messages, and the ever essential support tickets. Our clients can post, comment on and otherwise interact with all of these items, and all the archives are there for review later. No spam filters or non-inbox-zero obstacles!

Team communications

What can I say? We like Skype. It's stable, it's pretty much peer-to-peer, it is very good at drilling through firewalls, it's encrypted, it stores archives, we can do conference calls, share screens, etc. That said, we are eyeing other possible solutions, including google+. The main need is to have robust real-time chatrooms, with encryption, and easy voice communications.

Ticket/time tracking

Like most design and development companies, we've been pretty frustrated with a lot of the project management software solutions out there. We use Liquid Planner (affiliate link), which provides ticket-level time tracking, high/low estimation, schedule and cost projections, and some nice graphs. And unlike some other systems, we've had no problems with performance slowdowns — it's a fairly consistently moderately fast web app, given its complexity. Having tried Basecamp, Harvest, Unfuddle, Freshbooks, ActiveCollab, Trac, Jira, Rally and several desktop apps over the years, I think Liquid Planner is the closest thing to the bee's knees.

Design process

We meet with the client if at all possible. We talk. We draw pictures. We point at things. We work to understand the client as best we can. This means travel, if there's room in the budget. It ends up paying off in the end through implementation of a project better aligned with the client's needs. When not in person, we communicate through Atrium.

As for amongst ourselves, we use Dropbox (affiliate link for extra GBs of space) as an easy way to share physical files that are not suited for version control. And we talk in Skype. Sometimes we'll do mark-up on artwork or wireframes, but most of the creative collaboration happens via voice. It's somehow more human that way.

Code repository

Like many, we use GitHub. Can I just take a moment here to say how much I love Git? Escaping from Subversion was transformative. (Drupal.org's escaping from CVS will be even more so.) The biggest problem with svn is all those hidden folders. They're like pox riddled throughout your code, buried in each folder, lurking. Replace a folder with a fresh one and svn freaks out, "What did you do with my hidden folder, you malfeasant!" Git doesn't do this. Git is nice. Swap out things in your code and Git doesn't mind. Git loves it when you do things like that. Go ahead, swap out a folder, swap out 10 folders! Tell Git and Git says, "Got it!" Shiny!

Development and staging

Configure globally, code locally. As soon as we start the first development sprint for a project, we set up a staging server on a VPS. Right now we are really liking Linode (affiliate link) for the smaller sites and AWS for the bigger ones requiring more flexibility on resources. Each of us codes locally, on our own machines, merging our code changes with Git. We deploy committed changes several times a day to the staging server using Git pulls from GitHub, which serves as our canonical central repository. Configuration changes, with the exception of Featurized configurations, are all done on the staging site, so that we don't have to mess with database conflicts. (Bricks-and-mortar teams can all connect to one canonical database on the same network, but that just won't work for virtual teams. The latency is not just fatal, it's fatal on a mass extinction scale.) We periodically pull database backups from the staging site to use locally, so we're all referencing the same basic configurations.

The exceptions to this relate to Features and exportables. We love Features, but find that they can get in the way at times. We use them for special cases, especially when doing iterative development, where it's nice to be able to deploy code and configuration changes through version control. On the other hand, exportables (e.g., Views and Contexts) are nice ways of moving sometimes extensive configuration work from one machine to another.

Sales pipeline

Here I'm afraid we're amateurs. We have our inquiry form. We have phones. We have email. We do things the old fashioned way. That means that, no doubt, our sales process is probably woefully inefficient at times. We're not huge, not even big enough to have a dedicated sales person, so a robust CRM really does not seem to make sense — in fact, it would probably just make everything harder to manage, spending all our time trying to get the CRM to record things in ways that are findable. If you fill out our inquiry form, or call us, or email us, it's we at the other end who are fielding your inquiry, no salespeople or account managers. Consider it the personal touch.

Drupal community communications

Anyone in the community can tell you, the ways to communicate are: on the *.drupal.org websites, in IRC, and on the email lists.

And at Drupal events!

Smooth coordination can be a challenge for any team. The Blue Angels set the standard. Photo by Joshua Davis Photography (Creative Commons).

The common thread through all of this is communication. It's not everything, but it's the most important thing.

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.

Announcing Apache Solr Pages

Robin Monks — Tue, 05 Apr 2011 12:47:06 +0000

Ever needed to produce functionality in Drupal that multiple modules came really close to providing — but none of them seemed to get it quite right? We recently experienced this issue when needing to create an advanced search page in Drupal 7 for a client. We needed the ability to create pre-filtered result pages from essentially an empty query, displaying everything in a default result that the user could then continue to filter or search within, as needed. This was a strict UI requirement we faced, so we had to rule out what otherwise might have been reasonable alternatives, such as using normal Views with exposed filters. That Solr-like experience was essential.

We knew we needed facets, and we knew that Apache Solr would fit that bill nicely. But we also needed a way to make our own pre-filtered pages as a starting point. Search API would fulfill that need, but to use Search API would require working with entities for the results — and Search API is also facing some refactoring that we wanted to avoid having to compensate greatly for.

Well, if Views alone wouldn't match the interface requirements, what about Views in Apache Solr? Sadly, Views support isn’t in Apache Solr for Drupal 7 yet. So we had to go back to the drawing board and, keeping simplicity in mind, find a way to solve our client's basic requirements.

After having the opportunity to meet with Peter Wolanin, one of the co-maintainers of Apache Solr, it became apparent that we may not even need to port, or integrate into the main Apache Solr project, Apache Solr Views to solve our issue.

Apache Solr Pages extends Apache Solr pre-filtered result pages, displaying everything in a default result, with exposed facets.

Applying the logic of creating the simplest solution to fulfill our needs in several hours of late-night development I was able to repurpose another Search API feature, the searchapi_page module, and use it in the context of Apache Solr. This gains us a few distinct advantages:

We are able to create the multiple pre-filtered pages we need for our use case.
We don’t have to rely on the overhead and complexity of using views to build our Solr query.
We’re indirectly able to provide an extension use case in Drupal 7 for Apache Solr module.

The Apache Solr Pages module [corrected URL] is still in need of additional work and a lot of cleanup to remove all of the legacy bits that were carried over from Search API; however, it is presently working for our basic use case. The following features actively need additional help to bring the module to a product-ready release:

Apache Solr’s “Current Search” block needs to receive proper integration, with the pre-defined filters being hidden or locked in with disabled fields per the administrator’s choice.
This also provides a chance to look into ways to better allow the Current Search block to be extensible by other modules upstream in Apache Solr.
View modes that were in Search API’s rendition of pages aren’t supported here; Search API code that allowed this is still in the module but needs refactoring to work.
Paging is currently broken due to the difference in how Search API and Solr return results.
Need to apply Apache Solr’s “on empty” effect, or allow it to be overridden on a page-by-page basis.

The Drupal 7 branch of Apache Solr Pages is available for download today, and I look forward to seeing more input from the community not just around this module, but around search in the future of Drupal in general.

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.

Grok Drupal 7 Theming - update

Laura Scott — Sun, 20 Feb 2011 23:53:44 +0000

Earlier this month at Drupal Design Camp Los Angeles 2011, I presented an update on Grok Drupal (7) Theming, which I had originally presented last year at DrupalCon San Francisco.

A lot has changed since March 2010.

The presentation is for people who are new to Drupal theming, as well as those who want to get a better sense of what's new in Drupal 7 theming.

I expanded on the previous presentation, clarified some points, and replaced a few slides with better ones.

A video of my slide presentation is available on the DDCLA Blip TV site. The slides are kind of fuzzy because the recording app captured my presentation notes screen instead of my presentation screen. My sincere gratitude goes out to John Romine for taking care of all the session videos, including the cropping of my session to just the relevant slides.

The video should be legible enough, but I've also posted higher resolution slides up on Slideshare.

Grok Drupal (7) Theming - 2011 Feb update

It was great meeting various folks at Drupal Design Camp LA. Big thanks to Christefano and Lee Vodra for their wonderful hospitality!

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 Blog Feed

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...

Our virtual team toolbox

Client communications

Team communications

Ticket/time tracking

Design process

Code repository

Development and staging

Sales pipeline

Drupal community communications

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

Announcing Apache Solr Pages

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.

Edit `/etc/apache2/ports.conf`

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

Configure the `php.ini` settings.